A model may charge less per response and cost more per correct document. If it requires more fields to be reviewed or more errors to be corrected, that difference shows up in the team’s time.
“Flash” is a product name, not a unit of speed or quality. I would not treat it as a guarantee that a small task will be solved. I would compare specific models on the same documents, using the same acceptance criteria.
The bill for calls
I use a hypothetical data-extraction example. In this exercise, A represents the lightweight-model option and B the large-model option. The rates and errors assigned to them are assumptions for the calculation: size does not establish that a real model has that cost or quality. None of the amounts in this table is a current commercial rate and none of the percentages comes from a trial. I assume 1,000 documents a month, one call per document, 2,000 input tokens and 200 output tokens per call. That totals 2 million input tokens and 0.2 million output tokens.
| Assumption | Model A | Model B |
|---|---|---|
| Input rate per million tokens | €0.20 | €2 |
| Output rate per million tokens | €0.80 | €8 |
| Monthly call cost | 2 × 0.20 + 0.2 × 0.80 = €0.56 | 2 × 2 + 0.2 × 8 = €5.60 |
This simplified calculation excludes tax, caching, additional calls, tools, prior document reading and other billable categories. Google’s token documentation explains input counting and usage records, including other token types. To budget for a real service, I would use its records and the chosen model’s terms, without converting words into tokens at a fixed rate.
The cost of getting the document right
Now assume the complete manual process takes four minutes per document: 1,000 × 4 = 4,000 minutes, or 66 hours and 40 minutes a month.
With both models, I keep half a minute of review per document: 500 minutes. I also assume A leaves 50 documents with a detected error, or 5%; B leaves 10, or 1%. Each correction adds three minutes after the ordinary review. These are detected errors; I have not valued damage from any that might go unnoticed.
| Monthly human work | Model A | Model B |
|---|---|---|
| Ordinary review | 500 minutes | 500 minutes |
| Additional corrections | 50 × 3 = 150 minutes | 10 × 3 = 30 minutes |
| Internal maintenance | 60 minutes | 60 minutes |
| Time freed compared with 4,000 minutes | 3,290 minutes | 3,410 minutes |
B costs €5.04 more in calls and frees two additional hours under these assumptions. At €25 per hour of work, that would be €50 of capacity. This comparison would favour B only if the difference in errors and time is confirmed and those hours have a use.
To complete the calculation, I assume €80 a month for tools for both. The balance of valued capacity would be 3,290 ÷ 60 × 25 − 80 − 0.56 = €1,290.27 for A and 3,410 ÷ 60 × 25 − 80 − 5.60 = €1,335.23 for B. Initial implementation cost is still missing. These balances are not guaranteed revenue or cash savings.
What I would measure before choosing
I would test clear and difficult documents and measure from input to reviewed record. I would separate errors by field: confusing a description and confusing a bank account have different consequences. I would also measure long waits, retries and service limits.
If A meets the requirements at a lower total cost, I would choose it. If B reduces enough work or risk, its higher rate may be worthwhile. I do not have that answer without the trial.
Sources
- Google: counting tokens in Gemini — Accessed 10 October 2026. Usage includes input and output; the documentation explains counting and usage records, including other token types. It does not support the example’s rates or results.
If you have already measured a task, you can send me its volume and review times so I can frame a useful comparison.