The Price Held. The Bill Rose.

Google's newest Flash model costs exactly what the last one did. An independent benchmark ran it and measured about forty percent more cost per task. Both of those are true at once, and the space between them is where your budget quietly goes.

Gemini 3.8 Flash shipped on September 2 at $0.75 per million input tokens and $3.75 per million output. The launch post calls it "the same introductory price as 3.7 Flash" and it is telling the truth.

Note the word introductory, and the footnote marker after it: "Introductory price expires on December 31, 2026. Starting January 1, 2027, $1.50/1M input tokens and $7.50/1M output tokens will apply." The rate doubles in four months, disclosed in small type at the bottom of the same post.

3.8 did not introduce that step-up. Google gave 3.7 Flash the identical footnote three weeks earlier: same December 31 expiry, same $1.50 and $7.50 after it. The schedule was already public. What 3.8 changes is how much work the introductory rate buys before it arrives.

Read four paragraphs further and you find this, in Google's own words:

Nobody buried the token sentence. It sits under a heading, in the announcement itself. It will still not stop a team telling its finance lead the upgrade is free. The number that moves between versions is the price, and it held.

I've watched this gap open on my own bill. In my experience the per-call number is the one that hides.

Somebody did the arithmetic

Artificial Analysis ran their own evaluation suite against both models and published the result themselves. This measures one benchmark suite, not your workload. Gemini 3.8 Flash costs "$0.58 per Intelligence Index task, making it the cheapest model at its level of intelligence." Against $0.40 for 3.7 Flash that is about 40 percent more, "despite unchanged per-token pricing, driven by a 30% increase in output tokens per task and more turns on agentic evaluations."

Both halves are true at once. It is the cheapest of its class and it costs more than what you ran yesterday. They do not contradict; they are measured in different units. Price is per token. Your bill is per task.

Thirty percent is one term, not the number

Artificial Analysis named two causes: average output tokens per task rose 30 percent to 48k, and agentic evaluations took more turns. Those land on different parts of the bill. More output raises output-token cost directly. More turns can also resend or enlarge the context, which raises input cost. Artificial Analysis reports only the combined result. It does not decompose how much came from each, so treat any split you read into it, mine included, as inference.

Be careful with the 30 percent. It is a rise in output tokens, not in the whole call. Your input and cached tokens are unchanged and still in the denominator. So a single call emitting 30 percent more output costs 30 percent more output, and less than 30 percent overall. An agent loop differs: each turn's output becomes the next turn's input, and the loop runs until some condition is met. Make each turn more thorough and every turn costs more. Unless you truncate or summarise between turns, the transcript each later turn carries also grows. If the diligence also adds steps, you pay more per step, across more steps, on a growing context.

That compounding is the likeliest reason "30 percent more tokens" landed nearer 40 percent more spend on an agentic suite. A summarisation job making one call sees something near the token delta. A support agent averaging nine turns sees something else. The only way to know which you are is to count your own.

Output tokens are the expensive side at $3.75 per million, so the sum is small enough to do in your head. Take a workload burning 8,000 output tokens per task, and pick your own task volume. The token counts below are illustrative, the rate is the published introductory one, and this counts output tokens only: your input and cached-context charges sit on top.

Nine tenths of a cent. Nobody audits a number that small against an unmeasured volume.

This shape is older than reasoning models

In my experience the alternative GPU clouds really are cheaper per hour than the hyperscalers, and the trap sits in egress and idle time rather than the hourly rate. Cloud compute was cheaper per instance too, right up until I was running three thousand of them and met the price list for cross-AZ traffic.

What is new is that the quantity is no longer yours to set. When you provisioned an instance you chose the size. Here the model decides, per request, how hard to think. Google is explicit that you can turn this down: lower effort levels, or stay on 3.7 Flash, which they say remains supported for efficiency-first workloads. That escape hatch is real and worth knowing about.

The hatch cuts one way, though. Turning the effort down is something you have to choose; the extra diligence is what arrives if you change nothing.

We have been here before, and we solved it by accident

Metered compute is not new. I learned to program in an era when time-shared mainframe work was billed per CPU-second, and a badly written loop was not an embarrassment, it was an invoice. You estimated cost before running anything, because the feedback came with a price attached.

Then flat-rate hardware arrived and the habit died, deservedly. When the machine on your desk costs the same idle or busy, counting cycles is wasted effort.

Reasoning models put the meter back, with a difference that matters: on the mainframe, the loop was yours. You wrote it, so you could bound it. Here part of the loop belongs to the vendor. You still choose the model and the effort level; what the model does inside a call is increasingly its decision, revised on whatever cadence they choose.

What this cost me, specifically

I run a reply pipeline that drafts responses to things people write about my work. For comparison purposes it ran a second model alongside the primary drafter, generating a shadow draft that was never shown to anyone. Not to me, not to a reviewer. It existed so the two could be compared later.

Later never arrived. When I pulled one billing period apart, the shadow drafter was $52.76 of a $55.29 Gemini bill. Ninety-five percent of that period's model spend, on output no human had read.

No single call was expensive. That is the whole point. Each one cost a fraction of a cent, and the per-call number was so small that I never went looking for the multiplication. What made it 95 percent of the bill was volume nobody was watching, and volume is exactly the term that "the price is unchanged" leaves out.

The fix was not a cheaper model. It was sampling the shadow drafter at 10 percent, on a stable hash, and capping how many drafts could pile up unread. One thing I tried first did not work, and I only know that because I measured it: raising the quality threshold so fewer drafts got generated. The drafts that go stale score higher than the ones that get used. Filtering on quality removed the wrong ones.

You cannot measure a regression that ships faster than your billing cycle

Buried in the same announcement: this is Google's third Flash release in six weeks. Version 3.7 landed three weeks before 3.8.

Sit with the timing, and mind the condition. A release does not reach into a deployment that pinned a version. Pin 3.7 Flash and you keep 3.7 Flash until you migrate or it is retired. The collision is with a moving target: an alias that tracks the newest release, or a router that does. Follow one and the model underneath your product can change every twenty-one days while your bill still closes every thirty. You never get a clean month attributable to one version. Your September invoice blends two or three models with different token appetites, and the one that caused the rise may already have a successor.

That is not a conspiracy, and pinning is the whole defence. It is a release cadence colliding with an accounting period for anyone who did not pin. The collision breaks the ordinary way you catch a cost regression: you notice the bill rose, you ask why, and the question no longer resolves.

Write down what you are going to compare

Do this before the switch. Afterwards you will not have the old numbers, and the old model eventually goes away.

The line people skip

The fourth is the one most often skipped, and it is the one that found my problem. Cost per task is only half the question. The other half is whether the task was worth doing. A pipeline can be perfectly efficient at producing work nobody consumes, which is its own hidden cost. I was paying a fraction of a cent per shadow draft, which is a fine price. The comparison was worth running. It was not worth running on all of them, which is the distinction the per-call price hid from me.

A calculator multiplies your assumptions. The invoice multiplies reality. Where they disagree is the finding, and an unmeasured number is worth less than it looks.

The upgrade is probably still worth taking. Forty percent more on a workload that was costing you eleven dollars a month is four dollars, and Google reports 54.9 percent on HLE-Verified, which is a vendor-run number rather than an independent one. Reasonable people will pay that.

What costs you is upgrading on the assumption that the price tag told you what would happen, then finding out six weeks later from a number you can no longer decompose.

Before you switch, record tokens per task on the model you are running now. Not tokens per million, and not the price. The count of output tokens your actual workload consumes to finish one actual unit of work. Then switch, measure it again, and multiply the difference by your real volume rather than your imagined volume. If those two numbers differ by more than a factor of two you have found something more valuable than a model upgrade.

When the upgrade is simply right

Plenty of workloads should take 3.8 Flash without hesitating. If your calls are one-shot, the output-token delta is the whole story, and a third more on a small number is still small. If you were routing hard cases to a larger frontier model, a cheaper model that handles more of them itself is a saving.

The upgrade is not the mistake. Assuming the price tag described the change is.

The same post introduced Gemini 3.8 Flash Cyber, tuned for vulnerability discovery and automated patching. It is not generally available. It goes to "a set of trusted defenders" through something Google calls the Fairwind Program.

The gating is the right call. The interesting part is the contrast in how carefully each thing was said. Access to the security model runs through an application process with named participants. The change in token appetite, which reaches everyone already on the model, is a sentence mid-post, and the price expiry is a footnote. Nobody did anything wrong. It is simply easier to be careful about a risk the industry already has words for.

"Price is per token. Your bill is per task."

Cisco Caceres•Coding since the late 1970s. Still learning, still building.