The Price Held. The Bill Rose.

Google's newest Flash model costs exactly what the last one did. An independent benchmark ran it and paid about forty percent more. 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.

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 put the result plainly. I am quoting them via The Verge, which carries the statement in full. This measures one benchmark suite, not your workload: Gemini 3.8 Flash is "the cheapest we've measured at this level of intelligence," and running it cost about 40 percent more than 3.7 Flash, "despite unchanged per-token pricing, driven by a 30 percent 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 the floor, not the number

Artificial Analysis attributed the increase to two things: 30 percent more output tokens per task, and more turns on agentic evaluations. On an agent loop those two compound rather than simply adding, though the reported 30 percent is an average across their tasks and may already absorb some of the turn effect.

A single-shot call that runs 30 percent longer costs 30 percent more, and that is the whole story. 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.

The unit you are quoted is not the unit you pay in

This shape is old and it keeps working. 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 the loop belongs to the vendor, and its length is a product 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. A monthly bill closes every thirty days. If the model underneath your product changes every twenty-one, you never get a clean month attributable to one version. Your September invoice blends two or three models with different token appetites, and unless you pinned a version, the one that caused the rise may already have a successor.

That is not a conspiracy. It is a release cadence colliding with an accounting period. 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.

The failure is not upgrading. The failure is upgrading while believing the price tag told you what would happen, and then finding out in six weeks from a number you cannot 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 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.