Claude Fable 5.1 and GPT-6 Astra: what we use each for

Same $10 and $50 list price, different bills. What the cache rate, the 272K cliff and the vendor benchmarks mean once you deploy one of these.

Published: 2026-09-15 · Author: Ahmed Heshmat · 9 min read

Key takeaways

  • The sticker price is identical. Claude Fable 5.1 and GPT-6 Astra both bill $10 per million input tokens and $50 per million output tokens. The bill diverges on cache reads, $0.25 against $1.00, and on long requests, where Astra charges double for input and half again for output on anything over 272,000 tokens.
  • Use Astra when the work is driving software that gives you no usable API, and when the deliverable is an artifact: a spreadsheet, a drawing, a filled form.
  • Use Fable 5.1 when the work runs in a loop over a large fixed context, when a single request goes past 272,000 tokens, and when the reasoning has to hold up to a question six months later.
  • Every head-to-head figure published so far was produced by one of the two vendors on its own harness. Nobody has run both on identical tasks.
  • Most production work belongs on neither. A $2 model handles the classify, extract and draft work these two are wasted on, and the model is the cheapest part of a system to change later.

What the two labs shipped, three days apart

Anthropic released Claude Fable 5.1 on September 1. OpenAI previewed GPT-6 Astra on September 3 and opened it to paid tiers on September 4. Two frontier models, one price list, and a week of benchmark charts that mostly do not answer the question a business owner is asking.

The question we get is some version of "should we be on the new one." The useful version of it is narrower: which of these two does the specific job in front of us, at what monthly cost, and what happens to the build when the next one lands in December.

The spec sheet

| | Claude Fable 5.1 | GPT-6 Astra |

|---|---|---|

| Released | September 1, 2026 | September 4, 2026 |

| Input / output per million tokens | $10 / $50 | $10 / $50 |

| Cache reads per million | $0.25 | $1.00 |

| Long requests | one price at any length | over 272K input tokens the whole request bills at $20 in, $75 out |

| Context window | 1M tokens | 1.05M tokens, 922K of it input |

| Max output | 128K tokens | 128K tokens |

| Knowledge cutoff | June 2026 | April 30, 2026 |

| Runs on | Claude API, Amazon Bedrock, Google Cloud, Microsoft Foundry | OpenAI API |

| Published retirement floor | not sooner than September 1, 2027 | not published in the same form |

Sources: Anthropic's model docs and OpenAI's Astra model page, both read on September 14, 2026. Both vendors sell overnight batch work at half price, which is the cheapest line in this post if your job can wait until morning.

That retirement row matters more than it looks. Anthropic publishes a floor date for every model, so a build can be planned around it. If you are putting a model inside a workflow your operation depends on, the date it goes away belongs in the plan on day one, next to the client's own software renewals.

The benchmarks, and what they are worth

Astra takes most of the published comparisons. On OpenAI's own September 4 table it scores 57.9% on Terminal-Bench 4.0 against 55.8% for Fable 5.1, 64.6% against 52.6% on Terminal-Bench-Science, 41.4% against 31.4% on AutomationBench, and 95.9% against 84.3% on BenchCAD. It leads on maths and physical science too, 97.6% against 87.8% on FrontierMath Tier 4 and 96.0% against 93.7% on GPQA Diamond.

Fable 5.1 leads where the test is reasoning rather than execution. It takes Humanity's Last Exam with tools, 65.0% against 57.2%, and sits ahead on Artificial Analysis' independent intelligence index, 66 against 61. Anthropic's own published figures put it at 52.6% on Terminal-Bench-Science and 60.9% on Humanity's Last Exam without tools, both large jumps over Fable 5.

Read all of that with the caveat attached. OpenAI ran the comparison table with OpenAI's settings. Anthropic's computer-use numbers come from a different task release with different grading, which is why the same benchmark name appears with two incompatible scores depending on whose blog you are reading. The clearest third-party roundup we have found is DataCamp's, and even it is assembling vendor-reported numbers. No lab has an incentive to publish the eval where it loses, and no independent group has run both models end to end on the same real workload.

Which is fine, because a benchmark was never going to tell you what a week of your own tickets costs.

Where the money actually goes

At list price the two are the same model to a finance team. The difference shows up in the shape of the work.

Cache reads are the first split. An agent that re-reads a fixed context each turn, your policies, your property list, your price book, pays $0.25 per million tokens on Fable and $1.00 on Astra. Take a 50,000-token context re-read ten times in a conversation, and 200 conversations a day. That is 500,000 cached tokens per conversation, so 12.5 cents against 50 cents, or $25 a day against $100. Over a year, on that line alone, about $9,000 against $36,000. It is arithmetic on list prices, not a quote, and it ignores everything you pay for the actual input and output. It is also the single largest cost lever in an agent build, and it is invisible on a pricing page that shows both models at $10 and $50.

The second split is the long-request cliff. Astra bills the entire request at $20 input and $75 output once you cross 272,000 input tokens, so a retrieval job that dumps a full lease file or a year of maintenance history into one call gets more expensive at exactly the moment it gets big. Fable holds one price to a million tokens.

Artificial Analysis found the reverse effect on completion cost, incidentally: Astra finished their index for about $1.67 a task against $3.76 for Fable, because it gets there in roughly a third of the tokens. So the honest summary is that Astra is cheaper when it thinks less and Fable is cheaper when it reads the same thing over and over. Your workload decides which of those you are.

What we use Astra for

Driving software that was never meant to be driven by anything but a person. Computer use is where Astra's published numbers are strongest: 92.7% on ScreenSpot-Pro and 72.6% on OSWorld 2.0's offline set. Anthropic reports 77.9% on OSWorld 2.0 for Fable 5.1, but as a partial score from a different task release and grading setup, so the two do not sit on the same scale and neither lab has published the other's test.

In property, brokerage and trades work that capability lands somewhere specific: the twenty-year-old portal with no API, the supplier site that still wants a form filled by hand, the vendor whose integration costs more than the work it saves. We have quoted jobs where the only route to the data was a person clicking, and until recently the honest answer was to price the person.

Astra also wins on produced artifacts, the spreadsheets and drawings end of the work, and on anything with real maths under it.

What we use Fable 5.1 for

Long-running loops, big context, and anything we have to explain afterwards. It holds one price to a million tokens, its cache reads are a quarter of Astra's, and its knowledge runs two months later, which shows up more than you would expect when a model is reasoning about a platform that shipped a feature in May.

It also matters that Fable runs on Amazon Bedrock, Google Cloud and Microsoft Foundry as well as Anthropic's own API. For a Canadian client with a data residency clause in its contracts, or an enterprise that has already done its security review of one cloud, where the model can run is not a detail. It is often the whole decision, made before anyone looks at a benchmark.

Sometimes the client's software picks for you

Yardi is the clearest example on our side of the market. Its Interface Partner Program charges an annual licence fee per interface and requires a firm to be two years old with at least three active Voyager clients before it can build one, which we verified on Yardi's own site on September 11. Meanwhile Yardi shipped its Virtuoso Connector in June, and it speaks to Claude through the Anthropic marketplace, with other models listed as coming.

So on a Yardi build the model question can be settled by procurement before it reaches engineering. That happens often enough that we sort platform work into three lanes before quoting: what we can do outside the platform, what the vendor already ships, and what needs a licensed interface. The model comparison sits inside lane one and barely touches the other two.

Most work should not be on either

The uncomfortable part of a launch week is how little of it applies to a working system. A frontier model at $10 and $50 is for reasoning that genuinely needs it. Classifying an inbound email, pulling four fields off an invoice, drafting a reply an operator will read before it sends, all of that runs fine on Claude Sonnet 5 at $2 and $10, a fifth of the price, and faster.

The two phone lines we run at one Toronto property management and brokerage operation answered 3,332 calls in a quarter. Almost none of that traffic is frontier-model work. It is intake, routing, and a record that a person can read at eight the next morning. Paying frontier prices for it would be a design error, not an upgrade.

How we choose, in order

Answer these in order and stop at the first yes.

  1. Does the job require operating software you have no API for? Astra, and budget for the fact that a model clicking through a UI is slower and more fragile than a call to an endpoint.
  2. Does it run in a loop over a large fixed context, or exceed 272,000 tokens in one request? Fable 5.1, on the cache price and the absence of a surcharge.
  3. Does the model have to run inside a specific cloud, region or contract? Whichever one is available there. Fable's four-platform spread makes that easier more often than not.
  4. Is it classification, extraction or drafting under about 50,000 tokens? Neither. Use the cheap tier and spend the savings on the workflow around it.

Then write the choice down where the next person can find it, put the model name in one configuration value, and keep the prompts in files rather than buried in a no-code node. We have written before about why that boundary is the real architecture decision. When the next model lands in December, a system built that way moves in an afternoon. A system built the other way gets rebuilt, and the client pays for it twice.

The model is the part of your stack with the shortest shelf life and the loudest launch. Build so that swapping it is boring.

---

If you want this decided against your own operation rather than a benchmark chart, a discovery call is free and takes thirty minutes. Bring the workflow you were thinking of automating and we will tell you which tier it belongs on, including the cases where the answer is a tool you already pay for. If it is bigger than a call, our audit maps the operation first and recommends second.