Reconciling a 1.3x Metered Bill Against Provider Sticker Prices on One Aggregator Key

Why reconcile per-backend token counts

When you call multiple models through one aggregator key, your bill is based on the sum of what each backend provider would have charged at list price, multiplied by 1.3. To verify that markup line by line, you need to isolate the token counts that each backend actually processed. This guide shows you how to pull those counts from the aggregator's responses and recompute the list-price equivalent for every call.

Step 1: Capture raw responses with usage data

Every aggregator response includes a usage object that reports token counts. To reconcile later, log the full response body (or at least the usage field) for each call. Store it alongside the request metadata: timestamp, model identifier, and your own request ID. Avoid parsing or transforming the usage data at capture time—keep it raw so you can recompute from the original source.

Step 2: Map each response to its backend provider

The aggregator routes your request to a specific backend (e.g., Claude, GPT, DeepSeek). The response often includes a provider or backend field, or you can infer it from the model name. Create a mapping table that links each model identifier to its backend provider and that provider's published list price for input and output tokens. Use the provider's official pricing page as your reference—do not rely on third-party estimates.

Step 3: Recompute list-price cost per call

For each call, extract the input and output token counts from the usage object. Multiply each by the corresponding list price per token for that backend. Sum the two to get the list-price cost for that call. For example:

• Input tokens × input price per token = input cost
• Output tokens × output price per token = output cost
• Total list-price cost = input cost + output cost

If the provider uses tiered pricing or different rates for cached tokens, apply those rules using the same token counts. Document your pricing assumptions so you can revisit them when providers change prices.

Step 4: Apply the 1.3x markup and compare

The aggregator charges 1.3 times the list-price total. Multiply your recomputed list-price cost by 1.3 to get the expected metered amount for that call. Then compare it to the actual amount deducted from your balance. Do this for every call in your log.

Step 5: Identify and explain rounding drift

Small discrepancies (fractions of a cent) are normal due to rounding at different stages: the aggregator may round token counts, apply markup, or round the final charge. To spot drift:

• Compare expected vs. actual per call and calculate the difference.
• If the difference is consistent and tiny (e.g., less than 0.01 USDC), it's likely rounding.
• If discrepancies grow with token count, check whether the aggregator rounds token counts up or down before applying prices.
• Aggregate the differences over many calls to see if they cancel out or accumulate.

Keep a running total of expected charges and compare to the aggregate deduction from your balance. Any systematic gap beyond rounding warrants a support inquiry.

Step 6: Automate the reconciliation

Write a script that parses your logged responses, applies the pricing table, and outputs a CSV with columns: call ID, model, input tokens, output tokens, list-price cost, expected metered cost (×1.3), actual metered cost, and difference. Run it periodically to catch pricing changes or billing anomalies early.

What about contributor credits?

If you are a key contributor, your credits are calculated as official price × 1.1 (or × 1.2 for premium models). The same per-backend token counts drive both your bill and your credits, so reconciliation ensures you are credited correctly. Use the same list-price recomputation to verify that your credit balance matches the expected 1.1x or 1.2x of the official cost for the calls you referred.

Summary

By logging raw usage data, mapping models to backends, recomputing list-price costs, and applying the 1.3x markup, you can verify your aggregator bill line by line. Focus on consistent rounding differences and automate the process to maintain transparency.