Claude Fable 5.1 vs GPT-6 Astra for Long-Running Work

That is the question this guide helps you test. Grow AI Skills has not completed a matched Fable 5.1 and Astra run on the task below, so this page does not report a measured winner. We reviewed the current provider documentation, checked the pricing arithmetic, and designed the evaluation we would want before committing an expensive workflow to either model.

The working hypothesis

If the job moves repeatedly among a repository, browser, spreadsheet, policy document, and release checklist, Astra is the first system I would test. OpenAI's current guidance describes multistep work across code, browsers, and professional software, together with mid-turn steering, asynchronous tool calls, persisted reasoning, and compaction. Those controls map well to a task that changes while work is underway.

Fable is the first system I would test when the difficult part is sustained reasoning over a large source pack, especially when many turns reuse the same cached prefix. Anthropic positions it for demanding reasoning and long-horizon agent work, while its $0.25-per-million cache-read price can materially change the bill. These are starting hypotheses based on documented capabilities and economics. The eventual choice should come from accepted work in the environment your team will actually operate.

A representative task with something real to break

We chose release repair because it exposes the dull failures that short demos miss. An old number survives in one export. A browser check never runs. The final memo sounds finished even though a spreadsheet still contains yesterday's rule. A useful long-task evaluation needs dependencies like these; otherwise it rewards fluent narration more than dependable work.

The starting packet.

• A repository snapshot with a half-finished reporting feature, two failing tests, and a bug report describing an incorrect total.
• A 70-page policy and requirements pack containing three values that must be quoted exactly.
• Two CSV exports with different date formats, one missing value, and one duplicate record.
• A screenshot of the intended layout and a browser test that covers desktop but misses the mobile defect.
• A deployment checklist whose production steps remain outside the agent's authority.

The required handoff.

1. A minimal patch that fixes the root cause without unrelated cleanup.
2. Focused tests for the defect, malformed row, missing value, duplicate, and mobile layout.
3. An evidence matrix connecting every release claim to a source field, command, screenshot, or retained test result.
4. A short handoff that separates completed local work from production actions still waiting for a person.

The change at hour three.

Halfway through the session, finance supplies a corrected rate sheet and the product owner changes the rounding rule. The agent must keep completed work that is still valid, identify stale artifacts, update the implementation and tests, rerun the affected checks, and refresh the handoff. A full restart wastes work; quietly carrying forward the old rate is worse.

This interruption matters more than adding another puzzle to the test. Long assignments often fail at the seam between old and new instructions. The agent may remember the new rule in its prose while leaving the old one in a chart, fixture, or release note. That is exactly the kind of failure a senior reviewer ends up finding late.

The official facts that affect this test

We checked these specifications on 15 September 2026 against the Claude model overview and the GPT-6 Astra model page. Account, cloud, product, and regional availability can differ, so record the environment used for each run.

Long context helps only when the work has state

A large context window gives the system room to carry material. It does not manage the project for you. The test should ask whether the agent can find the exact rounding rule from an earlier phase, notice that a regenerated chart invalidates the memo, and tell the difference between a planned check and a passed check.

Anthropic documents that Fable 5.1 keeps earlier thinking blocks by default, with those blocks counting toward later context unless they are cleared. Its documentation recommends task budgets and compaction as conversations approach the limit. OpenAI documents compaction and persisted reasoning for Astra, plus mid-turn steering that can add a requirement while preserving completed work. These features shape the experiment, but the surrounding application still decides what history, tool output, and files the model can see.

Make the workspace carry the durable truth. At each milestone, record the current requirements, source identities, completed actions, failed checks, unresolved questions, and next step. After compaction or a restart, require the agent to rebuild its orientation from those records. Confidence is a poor recovery mechanism.

The price tie disappears on some long requests

The base rates match, but the long-context rules differ. When an Astra request exceeds 272,000 input tokens, OpenAI applies the multipliers to the entire request: 2× for input and cached tokens, and 1.5× for generated tokens. Anthropic documents standard token pricing across Fable 5.1's one-million-token window and lists cache reads at $0.25 per million tokens. Astra lists cached input at $1 per million. Cache writes, retention, tools, service tiers, and retries can add to either bill.

For a simplified request with 250K uncached input tokens and 30K output tokens, both models cost $4.00: $2.50 for input and $1.50 for output. At 300K uncached input and 50K output, Fable costs $5.50 at its documented standard rates. Astra crosses the threshold, producing $6.00 of input and $3.75 of output, or $9.75.

The cheaper request can still create the more expensive outcome. One avoided retry or an hour less of senior review can outweigh several dollars of token cost. Keep a per-run ledger with input, output, cache reads, cache writes, tool charges, retries, and correction minutes. Compare cost per accepted result after the grader has finished.

Published benchmarks are context, not the result

OpenAI's Astra launch page reports several cross-vendor scores at the highest-scoring effort settings. Astra leads Fable 5.1 on Terminal-Bench 4.0 (57.9% versus 55.8%), AutomationBench (41.4% versus 31.4%), BenchCAD (95.9% versus 84.3%), Terminal-Bench Science 0.1 (64.6% versus 52.6%), and the extended FrontierCode score (64.5 versus 63.6%). Fable leads on Humanity's Last Exam with tools (65.0% versus 57.2%). The ordering changes with the workload.

The OpenAI launch report explains that the displayed evaluation scores use the maximum achieved at any effort. It also notes that production ChatGPT can differ because of harness and system-prompt choices, and that some Claude comparisons use provider-specific settings or modified evaluations. Anthropic's Fable 5.1 announcement publishes a different suite and does not place Astra in its main table. These are useful provider disclosures, not a neutral run of the release fixture.

Use the benchmarks to choose what deserves testing. They cannot tell you whether a stale number in your spreadsheet will be caught, how many permission pauses your workflow creates, or how long a reviewer will spend repairing the final handoff.

Run the comparison at the layer you buy

For a raw-model question.

Use equivalent API loops, tool contracts, machines, timeouts, input files, and network rules. Pin claude-fable-5-1 and gpt-6-astra. Record the effort settings and expose the same information to each model. Start with the documented defaults if that reflects production, then run a separate effort sweep when the purchasing decision is sensitive to quality or cost.

For a product-system question.

Run Fable inside Claude Code, Cowork, or the Anthropic environment your team plans to use, and run Astra in Codex or the intended Responses API application. Preserve the task and acceptance gates while documenting differences in built-in tools, approval prompts, skills, context handling, browser access, default instructions, and recovery. This comparison is less controlled, but it measures the systems people will actually operate.

Choose the layer before the first run. Mixing a bare API on one side with a mature coding product on the other makes attribution impossible. It may still answer a buying question, but it no longer isolates the model.

Grade artifacts, change handling, and recovery

A long task should earn most of its score from accepted artifacts and traceable decisions. Publish the weights before either model sees the task, then use the same grader for every run:

The 35-point artifact weight reflects the purpose of this fixture: a reviewable release candidate matters more than polished commentary. Change handling and traceability carry another 35 points because that is where long sessions become expensive. If your largest risk is security, visual quality, or regulated evidence, change the weights before testing and explain why.

Apply hard failures first. Fabricating a missing value, omitting a deliverable, claiming an unrun check passed, leaving the old rate in a dependent file, or performing an unauthorized production action fails the run. A high prose-quality score cannot repair any of those outcomes.

A shared brief for both systems

Give each agent the same operational contract. Keep vendor-specific advice in a separate, disclosed configuration so that it does not quietly change the task.

OUTCOME
Produce a reviewable local release candidate by 17:00.

SOURCE PRIORITY
1. Current policy and corrected rate sheet
2. Repository tests and fixtures
3. Bug report and design reference
Preserve missing or conflicting values; do not guess.

DELIVERABLES
Minimal patch, focused tests, evidence matrix, release handoff.

AUTHORITY
May read and edit the isolated workspace and run local tests.
May not deploy, message anyone, delete evidence, or weaken checks.

CHANGE PROTOCOL
When a requirement changes, list completed work that remains valid,
artifacts now stale, checks to rerun, and the revised next action.

EVIDENCE
Record commands, exit status, source identity, artifact hashes,
and what each check proves. A plan is not a completed action.

DONE WHEN
All required artifacts exist, hard-failure checks pass, the handoff
separates completed local work from pending production actions,
and unresolved facts are visible.

The brief is deliberately plain. Long assignments are usually lost through small state errors, so “done” needs a concrete meaning before the agent opens the first file.

Turn the description into a reproducible fixture

The task above is still a design. Before calling it a benchmark, create the files and make each run independently reproducible. A useful fixture folder should contain:

1. An immutable inputs/ directory with the repository snapshot, policy, CSV files, screenshot, and initial brief.
2. A sealed change-hour-3/ directory containing the corrected rate sheet and revised rounding rule, released at the same checkpoint in every run.
3. A manifest with SHA-256 hashes, timestamps, locale, timezone, tool versions, network policy, and the exact model and effort settings.
4. Machine checks for values, tests, file presence, stale strings, browser widths, and forbidden production side effects.
5. A blind-review sheet for patch focus, evidence quality, and handoff clarity, with scoring guidance for partial credit.
6. A run ledger that stores prompts, progress events, tool calls, outputs, exit codes, token accounting, reviewer corrections, and final status.

Copy the input directory for each run and keep the grader outside the agent's workspace. Reveal the hour-three change by the same mechanism and at the same task state, not merely after the same number of clock minutes. Record any human intervention; an unrecorded hint can decide a close comparison.

Read the results without forcing a winner

A single paired run is useful for finding concrete failure modes. Treat three runs as a smoke test, not a reliability estimate. Randomize which system runs first, reset the workspace and caches as your protocol requires, and report acceptance rate separately from speed. Median completion time among successful runs can otherwise hide every failure.

Calculate model spend and human correction time for all attempts, then divide by accepted results. That exposes the cost of a cheap run that needs repeated repair. Keep raw token cost visible as well, because a team may value operator time differently.

A defensible result sounds like this: “On release-repair fixture v1.0, using these product environments and effort settings, Astra passed two of three runs and Fable passed three of three. The accepted Fable runs required a median of X reviewer minutes.” Until those records exist, describe which model you would test first and why. Avoid turning a hypothesis into a leaderboard.

Which model should enter your test first?

Anthropic's Fable 5.1 prompting guide gives useful test ideas: progress can be sparse in long tool chains, targeted changes may become whole-file rewrites, and client-side summaries can lose constraints. OpenAI's Astra guidance notes that Astra may ask clarifying questions more readily, react strongly to instructions in skills or repository files, and test more broadly than a small change requires. Turn those documented tendencies into grader cases instead of treating them as universal behavior.

Recommendation

For the representative release task, I would test GPT-6 Astra first because the work crosses several tools and benefits from active steering. I would put Claude Fable 5.1 through the same fixture immediately afterward, especially if repeated reading or requests beyond Astra's extended-context threshold shape the workload. I would keep the scorecard empty until both retained runs exist.

The useful decision is rarely “Which frontier model is best?” It is “Which system finishes our task with fewer expensive failures, at an operating cost we can sustain?” A fair fixture turns that question into evidence. This guide gives you the structure; the recorded runs must supply the answer.