Gemini API overspend — reconstruction & attribution

01Findings

Ordered by how much they change the number. The first two are established by direct evidence; the rest bound what the traces cannot show.

• $14,553.16 (27.4%) was billed to Gemini models this project never configured

  The invoice bills gemini-2.5-flash ($14,489.78) and gemini-2.5-flash-lite ($63.38). All 1,655 run configs under outputs/ were scanned, plus every source file in the repository: no gemini-2.5-* model appears anywhere except unused rate constants in three pricing.py files, and no model id is ever built dynamically. That spend also runs Mar 28 – Jul 12, almost entirely after this project's Gemini activity ended (last configured run 2026-04-27). This is the one figure that does not depend on date alignment — it is a model-identity argument, so no timezone or clock assumption can move it.

• The cost driver is input tokens, not reasoning tokens — $33,451.89 of $38,585.37 (86.7%)

  Of our models' spend, $21,049.39 is fresh input and $12,402.50 is cached input, against only $5,133.48 of output (13.3%). Gemini bills reasoning as output, so even if every billed output token were a thinking token, the ceiling on that explanation is $5,133.48. The actual driver is volume: 15.25B fresh plus 68.29B cached input tokens, which is what repeatedly re-sending retrieved context costs at Gemini 3 Pro's $2–$4 per 1M. ReAct pipelines re-send a growing transcript every step and map_reduce re-sends every chunk, so input is paid many times per query.

• Recorded “token” counts in our traces are whitespace word counts, not tokens

  The fields total_input_tokens / total_output_tokens equal len(text.split()) exactly — verified on 102 of 102 map_reduce queries in a gemini-3.1-pro run (ratio 1.000; a chars/4 estimate gave 0.585). Recording is also inconsistent: the vrag shape records no input tokens at all, and map_reduce records no token fields whatsoever. Any cost figure previously derived from these fields is an undercount.

• Our traces account for only 1 in 24 billed input tokens and 1 in 14 billed output tokens

  Re-tokenizing every prompt and every piece of generated text we stored yields a floor of 3.52B input and 37.01M output tokens, against 83.55B and 530.24M billed. No raw API usage object was persisted in any of the 112 runs, so the gap cannot be decomposed from traces alone. It is some mixture of cached context re-sends, retried and failed calls, runs whose outputs were never saved, and thinking tokens. We can bound but not attribute it.

• $14,752.81 was billed at the long-context premium, which our cost model does not encode

  Gemini prices requests above a per-request input threshold higher. Rates derived from this invoice: Gemini 3 Pro input $2.00→$4.00 per 1M (2.00×) and output $12.00→$18.00 (1.50×). dashboard/pricing.py encodes only the short-tier rates, so it understates every long-context call. This is a context-length tier, not a concurrency charge — Gemini has no concurrency-based pricing.

• The split between matched and unmatched days is sensitive to billing timezone

  Our run timestamps are UTC, but the billing export does not record its own timezone, so an exact-day join can misplace spend by up to a day. Under exact-day matching, $3,111.97 of our-model spend falls on days with no saved run; allowing ±1 day that falls to $654.19, and ±2 days to $37.64. The honest statement is therefore a band: $654–$3,112 unattributed, not a point estimate. The total charged to our models ($38,585.37) is unaffected by this choice.

• The 12 browsecomp_plus runs are our spend but cannot be dated

  Confirmed by the team: a colleague ran this BrowseComp-Plus work on the same project API key. What is stored in outputs/browsecomp_plus/ is only the ingest — all 12 directories are stamped within a 90-second window on 2026-05-06 and carry a source block pointing at browsecomp_results/runs/, which is owned by another uid and unreadable here. The generation billed on an earlier date we cannot recover: the traces carry timestamps: null, and the invoice has no Gemini charges anywhere in May (Apr 27 → May 23 is empty). Its dollars sit inside the our-models total; they are only absent from the run-matched row. Workload floor: 5,736 queries, 896.28M input and 10.03M output tokens, about $544 at short-tier rates.

• 3 OpenRouter runs are correctly absent from this invoice

  Three runs on 2026-07-27 routed google/gemini-* through openrouter.ai, which bills separately. The invoice ending 2026-07-12 with no later Gemini charges independently confirms provider routing was read correctly.

• Repeated judge reports are indistinguishable from judge re-runs

  Each browsecomp_plus run carries three llm_judge_report_*.json files, which reads as three billed judge passes on gemini-3-pro-preview. They are not: the model-generated fields are byte-identical across all three (same decisions, same explanations, same hash), so the evals were copied in and re-stamped, and the extra files cost nothing. The hazard is that nothing on disk distinguishes a copied eval from a real re-run, which would look identical and would silently multiply cost.

02Cost over time

Daily invoiced spend, split by whether the billed model is one this project ever configured. Spend is overwhelmingly concentrated in March 2026 ($48,660.55, 92% of the total); the single worst day is 2026-03-25 at $8,969.91.

03Cumulative spend

The same data accumulated, on its own axis — the March ramp is where the incident actually happened.

04Tokens over time

Billed token volume for our two models, taken from invoice SKUs rather than our instrumentation — these are the only trustworthy token counts available. Each panel keeps its own axis because the three kinds differ by two orders of magnitude: cached input dominates volume while output dominates cost.

05Invoice by model

Invoice SKUs name Gemini 3 Pro as “gemini 3 pro”; our configs call the same model gemini-3.1-pro-preview, and our own run directories use gemini_3_pro_preview, which corroborates the mapping.

06Long-context tier premium

Rates below are derived from this invoice (cost ÷ tokens per SKU), not from a maintained price table.

07Daily detail

Full reconciliation table — the table view backing every chart above.

08Method & limitations