Opus 4.8 vs GPT-5.5 vs Gemini 3.5 Pro: Prompt Caching and Cost per Million Tokens at Scale (July 2026)

If you are choosing a frontier model for a product that runs at volume, the capability leaderboard is the wrong first screen. The bill is set by four numbers most comparisons bury: input price, output price, how much of your repeated context you can cache, and what the cache costs to write and read. Here are the list rates at the time of writing, plus the throughput we observed, for the three models most teams shortlist.

Metric	Opus 4.8	GPT-5.5	Gemini 3.5 Pro
Input, per 1M tokens	$5.00	$4.00	$3.50
Output, per 1M tokens	$25.00	$16.00	$14.00
Cached input, per 1M tokens	$0.50	$0.40	$0.35
Cache write premium	+25% on first write	+0% (automatic)	+5% to store
Cache read discount	90% off input	90% off input	90% off input
Context window	300K	400K	1M
Observed output throughput	~55 tok/sec	~70 tok/sec	~90 tok/sec

Read the cached input row before the input row. In a workload where the same system prompt, tool definitions, and retrieved documents repeat on every call, the cached rate is the one you actually pay for most of your input tokens. That single column reorders the ranking that the headline input price implies, and it is where this comparison earns its keep.

The Sticker Price Is Not the Bill

Take an agent that carries a 20,000 token system prompt and tool schema, retrieves 8,000 tokens of context per turn, and generates 500 tokens of output. Without caching, every turn pays full input price on 28,000 tokens. With caching, the 20,000 stable tokens drop to the cached rate after the first call, and only the 8,000 fresh tokens and the output pay full freight.

The uncached math flatters the cheapest input price. The cached math tells a different story, because a 90 percent discount on the largest, most repeated slice of your context compresses the gap between the three models and shifts the weight onto output price, where they diverge most. Opus 4.8 carries the highest output rate by a wide margin, and in a workload that generates a lot per turn that is what dominates the blended cost, cached input or not. If your workload is retrieval heavy and output light, a long stable prompt feeding a short answer, the picture inverts and the caching discount does most of the work.

The lesson is that you cannot rank these models on cost without knowing your own input to output ratio. A summarization pipeline, long in and short out, and a code generation agent, moderate in and long out, will pick different winners from the same price sheet.

How the Three Caching Systems Differ

The discount is similar across all three, roughly 90 percent off input for a cache hit. The mechanics are not, and the mechanics decide whether you actually capture the discount.

Opus 4.8 uses explicit cache control. You mark which prefix of your prompt to cache, and you pay a write premium on the first call that establishes the entry, then read at the discounted rate while the entry lives. The premium means caching only pays off when you reuse the prefix enough times to amortize the write, so short lived or rarely repeated prompts can cost more with caching on than off. The control is a feature: you decide exactly what is stable.

GPT-5.5 caches automatically. Repeated prefixes are detected and discounted without any markup on the write and without you managing cache boundaries. It is the least effort path to the discount, at the cost of less control over what gets cached and when an entry expires.

Gemini 3.5 Pro splits the difference with both implicit caching and an explicit context caching API where you store a block of context, pay a small storage cost, and reference it by handle. For a very large stable corpus, a long document set, a big tool catalog, the explicit path plus the million token window is the distinctive tool here. We measured how that large window holds up on retrieval accuracy, not just price, in the SimpleQA factuality comparison.

Throughput Is a Cost Too

Price per token is only half the operating cost. The other half is latency, because a slower model holds connections open longer, needs more concurrency to serve the same traffic, and hurts the user experience in an interactive agent. Gemini 3.5 Pro produced the fastest output stream in our runs, GPT-5.5 sat in the middle, and Opus 4.8 was the slowest of the three on raw tokens per second.

That does not settle anything on its own. A model that is slower but finishes a task in fewer, better turns can be cheaper and faster end to end than a quick model that fumbles and retries. This is exactly why per token throughput and per token price both mislead in isolation, and why the honest unit is cost per completed task. We built that per issue accounting for coding workloads in the cost per issue analysis on SWE-Bench Pro, and the ranking there is not the ranking you would guess from the price sheet above.

A Blended Cost Model You Can Copy

Here is the calculation worth running before you commit, expressed as a small function you can adapt to your own traffic shape.

def blended_cost_per_turn(model, stable_tok, fresh_in_tok, out_tok, reuse):
    # prices in USD per 1M tokens
    p = {
        "opus48":   {"in": 5.00, "out": 25.00, "cached": 0.50, "write": 1.25},
        "gpt55":    {"in": 4.00, "out": 16.00, "cached": 0.40, "write": 0.40},
        "gemini35": {"in": 3.50, "out": 14.00, "cached": 0.35, "write": 0.37},
    }[model]
    # amortize the one time cache write across expected reuses
    stable = (p["write"] + p["cached"] * (reuse - 1)) / reuse
    cost = (stable_tok * stable
            + fresh_in_tok * p["in"]
            + out_tok * p["out"]) / 1_000_000
    return round(cost, 6)

# 20k stable prompt reused 50 times, 8k fresh retrieval, 500 out
for m in ("opus48", "gpt55", "gemini35"):
    print(m, blended_cost_per_turn(m, 20_000, 8_000, 500, 50))

Run it with your real numbers, not the illustrative ones. Move the output token count up and Opus 4.8 gets expensive fast; move it down and the three converge. Raise the reuse count and the cache write premium on Opus disappears into the average; drop it below a handful and caching stops paying at all. The point of the function is that the winner is a property of your workload, and any comparison that names a single cheapest model without asking about your traffic shape is selling you a number, not an answer.

When This Applies to Your Stack

Do this modeling before you standardize on a model, not after your first surprising invoice. Pull one day of real traffic, count the stable prefix tokens, the fresh input, and the output per turn, and the average reuse of each cached prefix. Feed those into the blended model. You will usually find that the capability leader and the cost leader are different models, and that the right architecture routes cheap high volume turns to one and hard turns to another rather than paying a premium rate on everything.

If your team is building an agent or RAG system and wants the routing, caching strategy, and cost model built against your own traffic instead of a vendor's headline rate, Contra Collective designs and implements AI integration and agent engineering that holds margin at scale. The models will keep changing; the discipline of pricing your own workload does not.

FAQ

Which model is cheapest per million tokens? On raw input price, Gemini 3.5 Pro, then GPT-5.5, then Opus 4.8. On raw output price the order is the same. But cheapest per million tokens rarely equals cheapest per completed task, because output volume, caching reuse, and task success rate reshape the bill. Model your own traffic before deciding.

How much does prompt caching actually save? Roughly 90 percent off input price on a cache hit across all three, so the savings scale with how much of your context is stable and repeated. A workload with a large fixed system prompt reused many times can cut total input cost by more than half; a workload with mostly fresh input per call saves little.

Does Opus 4.8's cache write premium make caching not worth it? Only for prompts you reuse a handful of times or fewer. The premium is a one time cost per cache entry, so once a prefix is reused dozens of times the write disappears into the average and the read discount dominates. Below that reuse count, caching can cost more than leaving it off.

Is the million token window on Gemini 3.5 Pro worth paying for? It matters when you genuinely need a very large stable context in the prompt, and it pairs well with explicit context caching to keep that context cheap on reuse. If your retrieval keeps effective context under a couple hundred thousand tokens, the larger window is not a cost advantage by itself.

Should throughput change my model choice? For interactive agents, yes, because a faster stream lowers latency and the concurrency you must provision. But weigh it against task success, since a slower model that needs fewer turns can win on both cost and wall clock. Measure cost per completed task, not tokens per second alone.