Reading the Aggregator's Usage and Request Logs to Attribute Spend by Backend

When you use an LLM API aggregator to access multiple models, understanding your spending per backend is essential for budgeting and optimization. The aggregator returns detailed usage metadata with each response, and by logging these fields, you can reconstruct per-backend spend. This guide explains the fields and shows you how to attribute costs from logs alone.

The anatomy of a usage record

Every API call that returns a completion includes usage data. While the exact structure may vary by aggregator, you'll typically find these fields in the response:

• model: The identifier of the model that processed the request (e.g., claude-3-sonnet, gpt-4, deepseek-chat). This is crucial for attribution.
• input_tokens: The number of tokens in your prompt (including system messages and context).
• output_tokens: The number of tokens generated by the model in its response.
• total_tokens: The sum of input and output tokens (sometimes provided directly, otherwise compute it).
• request_id: A unique identifier for the call, useful for deduplication and tracing.
• timestamp: When the request was processed (often in the response headers or body).

Additionally, your aggregator may include fields like provider to indicate the backend provider, or cost if it calculates the price for you. However, even if cost isn't provided, you can compute it using the official price and the aggregator's multiplier.

Calculating cost from tokens

The aggregator charges you the official price of the model multiplied by 1.3. That means if you know the official per-token price for the model you used, you can compute your cost as:

yourcost = (inputtokens * officialinputprice + outputtokens * officialoutput_price) * 1.3

Be sure to use the correct official prices for the specific model and provider. These prices are usually available on the model provider's website or in the aggregator's documentation. Since prices may change, always refer to the latest official sources.

If the aggregator provides a cost field directly, you can use that as a cross-check, but be aware that it may already include the multiplier. In that case, do not multiply again.

Extracting usage from response headers and body

Depending on the aggregator's API design, usage data might be returned in the JSON response body under a usage key, or in HTTP headers (e.g., x-usage-input-tokens). Always inspect the full response to capture all available fields. For streaming responses, usage data is often sent in the final chunk or in a trailing event.

When logging, record the entire usage object along with the model name and a timestamp. This ensures you have all the information needed for later analysis.

Building a log for spend attribution

To attribute spend by backend, you need to log each request with at least:

• The model used.
• Input and output token counts.
• The timestamp (for time-based aggregation).
• Optionally, a user-defined tag or project ID to segment spending.

Store these logs in a structured format (e.g., JSON lines, a database, or a spreadsheet). Then, for each log entry, compute the cost using the formula above. Finally, sum the costs grouped by model to get per-backend spend.

Example aggregation in pseudocode:

for each log_entry:
    cost = (log_entry.input_tokens * official_input_price[log_entry.model] +
            log_entry.output_tokens * official_output_price[log_entry.model]) * 1.3
    add cost to total[log_entry.model]

This approach works even if the aggregator does not provide pre-calculated costs, as long as you have the official prices.

Handling different backends and models

The aggregator supports many models from various providers (Claude, GPT, DeepSeek, Qwen, GLM, Kimi, etc.). Each model has its own official pricing, which may differ not only by provider but also by model variant (e.g., input vs. output tokens, or context length tiers). Always map the model identifier from the usage record to the correct official price. Keep a reference table of official prices that you update regularly.

If the aggregator uses aliases (e.g., gpt-4 might point to a specific version), be sure to resolve aliases to the actual backend model. The usage record's model field should reflect the actual model used.

Accounting for contributor credits

If you are a key contributor to the aggregator (e.g., you've contributed compute or resources), you may receive credits at official price × 1.1 (or × 1.2 for premium contributions) in USDC. These credits are separate from the cost you pay as a user. When attributing spend, focus on what you pay (official × 1.3). Contributor credits are a reward mechanism and do not reduce your cost per call; they are settled separately. However, if you are both a user and a contributor, you might want to track credits as income, but that's outside the scope of spend attribution.

Best practices for accurate attribution

• Log consistently: Capture usage data for every request, including errors (though errors may not incur token charges).
• Use immutable logs: Store logs in an append-only system to prevent tampering.
• Validate token counts: Occasionally cross-check token counts with the official tokenizer for the model to ensure accuracy.
• Monitor for price changes: Official prices can change, so update your reference table and recompute historical costs if needed.
• Segment by project or user: If you have multiple applications, include a custom identifier in your logs to attribute spend beyond just backend.

By following these steps, you can gain clear visibility into your spending across different LLM backends using only the aggregator's logs and usage metadata.