# GPT-6 Astra vs Claude Fable 5.1: same $10/$50, and a 39% cheaper agent bill

> Two flagship models ship at identical $10/$50 stickers and produce different bills. On a 60-turn agent loop the gap is 39%, and all of it sits on one line the price sheet puts last: cache reads, $1.00 against $0.25. The same model also carries five different prices on the provider table, a 4x spread. The arithmetic, the workload shapes where it flips, and what to measure before you switch.

- Published: Sep 5, 2026
- Author: Leo Kaka, Engineering
- Tags: pricing, cost, caching, routing
- Canonical: https://pirouter.ai/blog/same-price-different-bill

---
They do not cost the same. GPT-6 Astra and Claude Fable 5.1 both list at $10 per million
input tokens and $50 per million output, and on a single uncached document call they tie
exactly, at $2.40. Run a 60-turn agent loop through each and the bill is $17.25 against
$10.50 — Fable 5.1 is 39% cheaper for work at the same sticker. Every dollar of that gap
sits on one line: cache reads, $1.00 per million against $0.25. The two numbers on the
front of the price sheet decided nothing.

This post works that arithmetic from the published rates, then does the same for the five
different prices the *same* Astra carries on the provider table — $5/$25 up to $20/$100,
a bill of $8.62 to $34.50 on that identical loop. All rates below were read on
2026-09-05 and every one of them is a moving target; the point is not the numbers but the
line they sit on. If you want the short version: measure your cache-read share first, and
treat model name plus sticker price as roughly half the information you need.

## Why do two $10/$50 models produce different bills?

Because an agent loop does not buy what the price sheet advertises. The two columns that
get compared in every procurement spreadsheet — input and output — describe a shape of
work that agents mostly do not do: send fresh text, get fresh text. What a coding agent
actually does on turn 41 is re-send the same system prompt, the same tool definitions, and
the same chunk of your repository it sent on turn 40, then generate a few hundred tokens.

Those re-sends are cache reads, and they are cheap for a mechanical reason: the provider
kept the processed form of that prefix from last turn, so it charges you for reusing stored
work instead of redoing it. The first turn pays a cache **write** to put the prefix there,
which costs *more* than ordinary input — $12.50 against $10.00 — because storing it is
extra work on top of processing it. That is the trade the whole article turns on: pay a
premium once, then pay a fraction on every turn that reuses it. It only pays off if the
prefix stays stable long enough to be re-read, which is why the ratio between those two
lines matters more than either price alone.

Here is the full sheet for both models, all four lines, standard tier, read 2026-09-05:

| Line | GPT-6 Astra | Claude Fable 5.1 |
| --- | --- | --- |
| Input / MTok | $10.00 | $10.00 |
| Output / MTok | $50.00 | $50.00 |
| Cache read / MTok | $1.00 | $0.25 |
| Cache write / MTok | $12.50 | $12.50 |

Three of the four lines are identical. Anthropic cut exactly one of them, from $1.00 to
$0.25, when it shipped Fable 5.1 on 1 September — a 75% reduction on the line most likely
to dominate an agent bill and least likely to appear in a comparison table
([Anthropic's cache-read cut, and the crossover it creates against Opus 5](/blog/fable-5-1-cache-read-crossover)).
OpenAI's rates for Astra, listed on both
[OpenRouter's model page](https://openrouter.ai/openai/gpt-6-astra) and Microsoft's
Foundry announcement, keep cached input at $1.00.

The share of your re-sent tokens that actually land on a stored prefix is your **cache hit
rate**, and it is the one number in this entire post you can change yourself — the prices
are the vendors' to set, but the hit rate is a property of how your prompts are ordered.
The section on hit rates below is about what happens when it gets high.

So the question "which of these two is cheaper" has no answer until you say what your
traffic looks like. That is not a hedge. It is a computation with one input.

## Three workload shapes, and the bill for each

Technspire's Foundry analysis prices three shapes against each other. Their numbers are
**derived from published rate cards, not measured invoices** — they say so, and the
distinction matters, because a derived figure holds your token mix constant while a real
month does not.

| Workload (Global Standard) | GPT-6 Astra | GPT-5.6 Sol (list) | GPT-5.6 Sol (promo) | Claude Fable 5.1 |
| --- | --- | --- | --- | --- |
| One-shot document job: 200K in, 8K out, no cache | $2.40 | $1.24 | $0.96 | $2.40 |
| 60-turn agent loop: 9M cache reads, 180K cache writes, 120K out | $17.25 | $9.23 | n/a | $10.50 |
| Same loop, 1,000 sessions a month | $17,250 | $9,225 | n/a | $10,500 |

Source: [GPT-6 Astra in Foundry: the price, the gate and the EU gap](https://technspire.com/en/blog/gpt-6-astra-foundry-price-gate-eu-gap),
Technspire, 4 September 2026.

The one-shot row is the tie everyone expects from identical stickers. The loop row is
where the sheet stops predicting the bill. Work it yourself for Astra, using the three
token counts from that row's own description — 9M cache reads, 180K cache writes, 120K
output. There is no input line in the sum because on a loop like this, essentially every
input token after the first turn arrives as a cache read; fresh uncached input rounds to
nothing and Technspire's shape omits it:

```text
                          GPT-6 Astra              Claude Fable 5.1
cache reads   9.00 M  ×  $1.00  = $ 9.00     ×  $0.25  = $ 2.25
cache writes  0.18 M  × $12.50  = $ 2.25     × $12.50  = $ 2.25
output        0.12 M  × $50.00  = $ 6.00     × $50.00  = $ 6.00
                                  -------                -------
                                  $17.25                 $10.50
```

Read down the two columns. The bottom two rows are identical to the cent — same cache-write
price (5-minute TTL on both sides; Anthropic's 1-hour tier is $20 and would narrow the gap
to 31%), same output price. The only line that differs is the first one, and the whole
$6.75 gap is $9.00 − $2.25 on it. That is not "39% cheaper because of caching" as a
summary claim; it is a subtraction with three terms, two of which cancel. Percentages ask
you to trust someone. This asks you to check.

Which is the point of showing it this way rather than as a headline number: put your own
token counts in the left column and the same three lines will tell you whether the gap
survives on your traffic.

Two honest caveats on that table before anyone puts it in a deck. The Sol promo column is
blank on the loop rows because Microsoft published reduced input and output rates for Sol
without a reduced cached-input rate, and you cannot price a cache-dominated session
without one. And the loop shape — 9M reads against 120K of output, a 75:1 ratio — is a
*long-prefix* agent, the kind that re-reads a large stable context every turn. If your
agent re-reads little, the gap shrinks toward the one-shot tie. The shape is the variable.

## One model, five prices: what the provider table costs

The cross-vendor gap is the smaller of the two surprises. The larger one is that "GPT-6
Astra at $10/$50" is not a price at all — it is one row of five. OpenRouter's provider
table for the same model, read 2026-09-05:

| Provider | Input /M | Output /M | Cache read /M | P50 latency | Throughput | Uptime |
| --- | --- | --- | --- | --- | --- | --- |
| OpenAI Flex | $5.00 | $25.00 | $0.50 | 6.88 s | 53 tps | 99.83% |
| Azure | $10.00 | $50.00 | $1.00 | 6.06 s | 49 tps | 99.31% |
| OpenAI | $10.00 | $50.00 | $1.00 | 3.67 s | 35 tps | 99.94% |
| Azure (US) | $11.00 | $55.00 | $1.10 | 3.38 s | 24 tps | 100.00% |
| OpenAI Fast | $20.00 | $100.00 | $2.00 | 2.04 s | 25 tps | 98.68% |

Source: [GPT-6 Astra — API pricing and providers](https://openrouter.ai/openai/gpt-6-astra),
OpenRouter, read 2026-09-05.

Push the same 60-turn loop through every row and the spread is four-fold. These are our
calculations from the rates above, holding the workload shape constant and scaling cache
writes with the input tier:

| Provider tier | 60-turn loop | Against standard |
| --- | --- | --- |
| OpenAI Flex | $8.62 | −50% |
| Azure / OpenAI standard | $17.25 | — |
| Azure (US) | $18.98 | +10% |
| OpenAI Fast | $34.50 | +100% |

One step there is ours, and it checks out where it can be checked. OpenRouter lists a
cache-write rate for the standard tier only ($12.50), so the rows above scale cache writes
proportionally with each tier's input rate. Microsoft's Foundry sheet publishes the cell
that tests this: its US Data Zone tier is $11.00 input with cache write at **$13.75** —
exactly $12.50 × 1.1, the same ratio. The long-context rows hold the ratio too, at $25.00
against $20.00 input and $27.50 against $22.00. Flex and Fast are the two tiers nobody
lists a cache-write rate for, so those two rows carry the extrapolation unverified. Cache
writes are $2.25 of the $17.25 standard bill either way, so the cache-read and output lines
carry the result regardless.

Read those two tables together and the framing changes. Fable 5.1 at $10.50 is cheaper
than standard Astra by 39% — and more expensive than Astra on Flex by 22%. The
cross-vendor comparison that opened this post is real, and it is also narrower than the
spread available inside a single vendor's own catalogue. Anyone deciding between two model
*names* is answering a smaller question than the one in front of them.

What the extra money buys on that table is latency, and it buys it in a strange
direction. Flex is half price at 6.88 s P50; Fast is double price at 2.04 s. Between them
sit two rows at the same $10/$50 with a 2.4-second P50 difference and a 0.63-point uptime
difference — same model, same price, different service. Meanwhile Azure (US) posts the
best uptime on the table at 100.00% over three days and the worst throughput at 24 tps.
There is no row that wins.

And the provider table is not even the complete surface. Microsoft's Foundry listing adds
a third pricing face: a US Data Zone deployment at $11/$55, and a long-context tier whose
threshold is worth its own section.

## The 272K cliff: 30,000 tokens that double the bill

Above 272,000 input tokens, Astra bills at $20 input, $2.00 cache read and $75 output — and
the surcharge applies to *every token in the request*, not just the ones past the line.
That makes it a cliff rather than a slope, and it is the one rule in this post that pays
for itself the moment you act on it.

Technspire works the consequence: a call with 300,000 input tokens and 8,000 output tokens
costs $6.60, and trimming the input to 270,000 costs $3.10. Keep the output side of that
condition when you reuse the figures, because both terms move at once:
`0.300M × $20 + 0.008M × $75` against `0.270M × $10 + 0.008M × $50`. Thirty thousand
tokens either side of an invisible line, and the bill slightly more than doubles.

The practical form of this is a guard that runs before the call, not a line item you find
afterwards. Technspire's own code sample checks at 260,000 rather than 272,000, and the
margin is deliberate: token estimates drift, and the penalty for crossing is a doubled bill
on the whole request. If your document pipeline routinely lands in the 272K–400K band,
chunking or summarising the front half is not an optimisation, it is the difference between
two prices for the same work.

## Cache reads are half the bill, so the hit rate is the price

Go back to the Astra loop arithmetic. Cache reads were $9.00 of a $17.25 bill — 52%. That
share holds across every provider tier in the table above, because the tiers scale all
lines together. On this workload shape, more than half of what you pay is determined by a
line that neither of the two headline numbers describes.

Which means the number that actually sets your unit price is your cache hit rate, and it
moves the price far more than any vendor's discount does. The clearest measurement of that
comes from a longitudinal study of a production coding agent
([Inference Economics of Enterprise Coding Agents](https://arxiv.org/pdf/2607.13080),
Peng, Lin and Lee, July 2026): across a 28-day period on a live monorepo, prompt caching
ran at a **99.3% hit rate and cut realized API cost by 88.6%, to an effective $0.57 per
million tokens**. The paper's own framing is the interesting part — that effective rate
lands *below* the $2.83 per million amortized cost of their shared on-premise GPU slice.
Caching did not just reduce the API bill. It inverted the cloud-versus-self-host
comparison that the sticker prices appeared to settle.

Treat that number with the caution its authors ask for: it is a single-developer,
non-randomized case study over two contiguous 28-day periods, and they scope their claims
to it explicitly. It is one measurement of one team's traffic, not a benchmark. What it
establishes is not "your effective rate will be $0.57" but that the distance between
list price and effective price can be an order of magnitude, and that the distance is a
property of your workload rather than of the vendor.

A third reading of "actual price" is worth putting beside those two. The Silicon Data LLM
Token Expenditure Index — an industry-wide measure of what gets spent per million tokens —
dropped below $1.00 for the first time on 1 September, to $0.97, less than half its summer
peak ([Three labs cut frontier prices in 72 hours: the AI pricing war's dual track](https://forkast.news/three-labs-cut-frontier-prices-in-72-hours-the-ai-pricing-wars-dual-track-emerges/)).
So we have three numbers claiming to describe the price of
a million tokens: $10.00 on the sheet, $0.57 realized in one cache-optimized deployment,
$0.97 as an industry aggregate. They are not in conflict. They are measuring three
different things, and only one of them is on the page you were comparing.

## When is the expensive model the cheap one?

Everything above is denominator work. It prices tokens, and tokens are not what you buy —
completed tasks are. A model that costs 39% more per loop and needs 40% fewer loops is
cheaper, and no amount of price-sheet arithmetic will show it.

Two independent readings point at that gap, and both point away from the billing
conclusion.

CodeRabbit evaluated Astra on actionable bug coverage in code review, and reported it as
four numbers rather than one, which is the useful part
([GPT-6 Astra in code review: gains, privacy, and cost](https://www.coderabbit.ai/blog/gpt-6-astra-code-review-evaluation)):

| Labeled bugs Astra caught, relative to… | GPT-5.6 Sol | Opus 5 |
| --- | --- | --- |
| Overall evaluation | +4% | +22% |
| Harder cross-file subset | +20% | +33% |

These are relative gains, not percentage points of coverage: +4% means Astra caught about
4% more of the labeled bugs than Sol did, not that its coverage was 4 points higher.
CodeRabbit rounds coverage to one decimal and computes the gains on unrounded values.

Read the rows, not the corner. Against Sol the gain quintuples once the evidence is
scattered across files, from 4% to 20% — that jump is the finding. Against Opus 5 the
baseline advantage is already 22% before difficulty enters, so the same 33% on cross-file
means something different. Quoting 33% without the 22% beside it turns a modest
difficulty-driven increase into an apparent landslide. CodeRabbit calls the whole thing an
early, directional result and explicitly declines to turn it into an overall ranking; keep
that attached to every one of the four cells.

Against that, Artificial Analysis — as quoted in Technspire's write-up — reports a **cost
per Coding Agent Index task of $4.72 for Astra against $9.18 for Fable 5.1**, while scoring
Astra at 61 on its Intelligence Index against Fable 5.1's 66.

Put those beside the loop arithmetic and you get a genuinely uncomfortable pair of facts:
Fable 5.1 is 39% cheaper per agent loop, and Astra is roughly half the cost per completed
benchmark task. Both can be true, because they are different quantities — one measures the
price of running a fixed number of turns, the other the price of finishing a fixed piece of
work. Neither is the answer to "which model is cheaper." They are the two halves of it,
and the half that matters depends on whether your agent's loop count is fixed by you or by
the model's competence.

Note also that the $4.72 figure comes from Artificial Analysis's own task mix, not from the
60-turn loop shape this post has been pricing. It cannot be dropped into the three-workload table above;
it is a different workload measured by different people. Everything in this post is
somebody else's evaluation, including the price sheets — which is fine for bounding a
question and useless for settling one. **Decide which quantity your decision is actually
denominated in before you go looking for numbers.** If you are budgeting a fixed pipeline
that runs a known number of turns, the loop arithmetic governs. If you are buying
completed pull-request reviews, cost per successful outcome governs and the loop
arithmetic is a distraction. The capability side of this comparison — what Astra's extra
reasoning does and does not buy — is the subject of a
[separate evaluation of whether Astra earns $10/$50](/blog/astra-eval-worth-the-price);
this one stays on the bill.

## The cheapest request is the one that never reaches the expensive model

Which brings us to the question in the title of every cost thread: what *is* the cheapest
way to route across providers? The most convincing recent answer does not pick a provider
at all. It removes work from the expensive one.

Spotify's engineering team published
[Portal by Spotify cut my Claude Code token usage by 90%](https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90),
on a Claude Code plugin that intercepts file reads above a line threshold and delegates
them to a cheap worker model, returning a structured summary instead of the raw files.
Boilerplate generation goes the same way, written straight to disk so the expensive model
never sees the tokens. Measured across four scenarios on a Java monorepo, **mean bulk-read
savings were around 90%**. The premise is stated bluntly in the first line: most of what a
coding agent does is not thinking, it is I/O — and they note a quarter of engineering
leaders already spend $200–$500 per developer per month on tokens, some well past $2,000.

The write-up is more useful for its stated limits than its headline. Three failure modes,
in their words: you cannot delegate editing, because the worker's summaries lack reliable
line numbers; you cannot delegate reasoning, because the worker missed a thread-safety bug
that the frontier model caught in seconds; and each delegation is a 10–30 second
round-trip, so below the line threshold the overhead exceeds the savings.

That last set of caveats is what makes the arXiv study's routing result compatible rather
than contradictory. Its offline replay of hybrid routing gateways found that **no routing
policy dominated the pure-API baseline** — shifting work to the cheaper local model traded
defect rate for infrastructure savings along a cost-quality frontier. Read carelessly, the
two look opposed: 90% savings against no free lunch. Read properly, they agree and the
agreement is the actionable part. Spotify routed *I/O-shaped* work, where the cheap model's
output is verifiable and a mistake is visible immediately. The paper routed *reasoning-shaped*
work, where a cheap model's mistake is a defect that surfaces later as a fix commit — and
their fix-commit ratio went from 45.9% to 74.9% when it did. The savings are real on one
side of that line and illusory on the other, and the line is not drawn by price.

This is the layer we work in, so the bias is worth stating plainly: a gateway is the
natural place to hold that decision, because it is the only component that sees the price
of every tier, the health of every provider, and the shape of the request at the same
moment. PiRouter is designed to make the tier and provider choice a routing decision
rather than a code change — designed to, not a shipped guarantee, and you should hold any
vendor including us to the difference. The obvious cost of putting anything in that
position is that it sees every request, which is the same residency question the EU Data
Zone gap raises above, pointed at us instead of at Azure; if that matters for your
workload it belongs in the evaluation. What is not vendor-specific is the structural point:
if the routing rule lives in each service, then every service owns a copy of a price sheet
that changed twice this week.

## Why price sheets are getting harder to read

There is a reason this is getting worse rather than better, and it is not incompetence at
the vendors. Two things are happening to frontier pricing at once, in opposite directions.

The commodity tier is compressing hard. Three labs cut frontier prices inside a 72-hour
window at the start of September: Anthropic's cache-read cut on the 1st, Google's Gemini
3.8 Flash at introductory rates on the 2nd, Meta's Muse Spark 1.3 the same day. That is
what put the Silicon Data index under $1.00.

Meanwhile the most capable tier is leaving the public grid entirely. Astra's headline
capabilities sit behind a Trusted Access programme; Anthropic restricted Mythos 5.1 to its
verification programmes; Google gated Gemini 3.8 Flash Cyber behind Fairwind. None are
publicly priced. Forkast's framing is that this is deliberate — commoditize the everyday
tier for volume, wall off the top for margin — and it puts roughly 95% of enterprise usage
in the commodity tier and the remaining 5% behind gates.

The practical consequence lands one layer down, and Technspire documents it: Astra on
Foundry is not a model you select from the catalogue. It ships through the Limited Access
Program, with a 5-to-10-business-day review, registration tied to the use case you
declared, rejection of applications from personal email addresses, and no EU Data Zone at
launch. When the EU zone arrives it carries a 20% premium rather than the previous 10%,
because Astra launched after the 1 September cutover.

So the published price is now the *third* thing you need, after "can I get access" and
"can I get it in my jurisdiction." A price sheet you can read but cannot buy from is a
worse planning document than a slightly stale one, and the gap between those two states is
where most switching decisions quietly go wrong.

## What to measure before you switch

Four things, in order, none of which require you to trust a table in this post:

**1. Your cache-read share.** Pull it from your `usage` fields for the last 30 days and
divide the cache-read spend by the total. Below about 20%, the sticker price is a
reasonable proxy for your bill and you can stop reading here. Above 50% — which is where
the long-prefix agent loop lands — the cache-read line is your price and the headline rates
are decoration. There is a 30-day self-audit procedure in
[the Fable 5.1 crossover post](/blog/fable-5-1-cache-read-crossover) that pulls the numbers
straight from the API response.

**2. Your workload shape, not the vendor's.** Take your own median session — turns, prefix
size, output length — and put it through the four-line arithmetic above. The 75:1 read-to-
output ratio in Technspire's loop produced a 39% gap; a 5:1 ratio produces almost none.
Both are agent workloads. Only one of them makes cache-read pricing decisive.

**3. Provider tiers, not just model names.** The 4x spread inside one model's provider
table is larger than the gap between the two models this post compared. If your selection
process ends at "Astra or Fable," it stops one level above where most of the money is. And
price the latency you are buying or giving up while you are there — Flex saves 50% and
costs you 4.8 seconds of P50.

**4. Cost per completed task, last.** Once the first three are measured, benchmark the
finalists on your own work and divide by outcomes, not tokens. This is the number that can
reverse everything above, and it is the only one nobody else can compute for you.

| If your bill is… | The decisive number is… | And the sticker price is… |
| --- | --- | --- |
| Long-prefix agent loops, cache reads >50% | Cache read /M | Roughly half the information |
| One-shot document jobs, no cache | Input + output /M | Actually decisive |
| Anything near 272K input tokens | The long-context threshold | Misleading by 2x |
| Latency-bound interactive work | Provider tier P50 | A tier choice, not a model choice |
| Fixed deliverables, variable turns | Cost per completed task | Nearly irrelevant |

The models in this comparison shipped two days apart at the same headline price, and
that turned out to be the least informative thing about them. All figures here were read
on 2026-09-05, most of them will have moved by the time this argument is useful to you,
and none of that changes the method: find the line that carries the volume in your own
traffic, then go price *that*.

---

## Sources

### openrouter.ai

- [OpenRouter's model page](https://openrouter.ai/openai/gpt-6-astra)

### technspire.com

- [GPT-6 Astra in Foundry: the price, the gate and the EU gap](https://technspire.com/en/blog/gpt-6-astra-foundry-price-gate-eu-gap)

### arxiv.org

- [Inference Economics of Enterprise Coding Agents](https://arxiv.org/pdf/2607.13080)

### forkast.news

- [Three labs cut frontier prices in 72 hours: the AI pricing war's dual track](https://forkast.news/three-labs-cut-frontier-prices-in-72-hours-the-ai-pricing-wars-dual-track-emerges/)

### coderabbit.ai

- [GPT-6 Astra in code review: gains, privacy, and cost](https://www.coderabbit.ai/blog/gpt-6-astra-code-review-evaluation)

### engineering.atspotify.com

- [Portal by Spotify cut my Claude Code token usage by 90%](https://engineering.atspotify.com/2026/9/portal-by-spotify-cut-my-claude-code-token-usage-by-90)