DEV Community: Hassann

Gemini 3.7 Flash to 3.8 Flash: API migration guide

Hassann — Thu, 03 Sep 2026 08:35:09 +0000

Migrating from Gemini 3.7 Flash to Gemini 3.8 Flash: A Practical Checklist

Google shipped Gemini 3.8 Flash on September 2, 2026—three weeks after Gemini 3.7 Flash—with the same introductory price and roughly the same speed. The model ID is gemini-3.8-flash, without a preview suffix, and the model card describes it as “based on Gemini 3.7 Flash.” A plain chat prompt usually needs only a one-line model swap. However, configurations that control thinking, sampling, or tool loops require nine migration checks—two of which can produce errors that 3.7 Flash did not.

Try Apidog today

This checklist is based on Google’s What’s new in Gemini 3.8 Flash page and the Gemini 3 developer guide. The examples cover both the Interactions API, which Google now treats as the primary path, and the legacy generateContent endpoint used by much existing 3.7 Flash code. You can paste the requests into Apidog and test them against the live endpoint before changing production.

Google says 3.8 Flash “works harder” by taking smaller reasoning steps, verifying its work, and calling tools iteratively on complex tasks. That improves capability but can also increase token usage, so migration requires a budget review—not just a configuration diff.

What changes—and what doesn’t

Area	Gemini 3.7 Flash	Gemini 3.8 Flash
Model ID	`gemini-3.7-flash`	`gemini-3.8-flash`
Context / output	1,048,576 / 65,536	Same
Introductory price through Dec. 31, 2026	$0.75 / $3.75 per 1M tokens	Same
Price from Jan. 1, 2027	—	$1.50 / $7.50 per 1M tokens for both models
Thinking levels	`low`, `medium`, `high`	Same; `minimal` returns a validation error; default is `medium`
Tokens per task	Baseline	About 30% more output tokens on average, according to Artificial Analysis
Function results	`call_id` + `name`	Both required and enforced
Support status	Fully supported; no deprecation date	Current

The pricing rows come from Google’s Gemini API pricing page, where the 3.6, 3.7, and 3.8 Flash rows are identical.

Step 0: Decide whether to migrate

Migration is optional. Google says Gemini 3.7 Flash “remains fully supported,” and no sunset date has been published.

Per-token pricing is unchanged, so the main cost difference is usage. Artificial Analysis measured Gemini 3.8 Flash at high thinking with approximately 48,000 output tokens per task—30% more than 3.7 Flash. At identical rates, that moved the estimated cost per task from $0.40 to $0.58. The index score increased from 56 to 59, while tool-use accuracy on τ³-Banking increased 12 points to 45%.

The trade-off is more capability per task in exchange for more tokens per task. If your workload is short, latency-sensitive, or already passes its evaluations on 3.7 Flash, staying on 3.7 may be reasonable. See the Gemini 3.8 Flash vs. 3.7 Flash comparison for a workload decision matrix.

Step 1: Swap the model ID in both API shapes

Interactions API

{
  "model": "gemini-3.7-flash",
  "input": "..."
}

Change it to:

{
  "model": "gemini-3.8-flash",
  "input": "..."
}

Legacy `generateContent`

POST /v1beta/models/gemini-3.7-flash:generateContent

Change it to:

POST /v1beta/models/gemini-3.8-flash:generateContent

Python SDK

client.interactions.create(
    model="gemini-3.8-flash",
    input=...,
    generation_config={"thinking_level": "medium"},
)

client.models.generate_content(
    model="gemini-3.8-flash",
    contents=...,
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="low")
    ),
)

If you have not used the Interactions API, the Gemini 3.8 Flash API guide covers both request shapes. The older 3.7 Flash walkthrough covered only generateContent.

The nine-item migration checklist

Work through these in order:

Update thinking_level
Remove sampling parameters
Replace thinking_budget
Remove candidate_count
Include call_id and name in function results
Preserve thought signatures
Increase token budgets where needed
Test media resolution by input type
Remove unsupported image-segmentation paths

1. Map `thinking_level: "minimal"` to `"low"`

Gemini 3.8 Flash accepts low, medium, and high. Sending minimal returns a validation error. If you omit the setting, the default is medium.

Gemini 3 Pro defaults to high, so do not copy a Pro configuration without checking the intended behavior.

Before:

{
  "generation_config": {
    "thinking_level": "minimal"
  }
}

After, Interactions API:

{
  "generation_config": {
    "thinking_level": "low"
  }
}

After, legacy API:

{
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "low"
    }
  }
}

Google’s thinking documentation describes low as the latency-oriented setting and medium as the default for complex code and agentic work. For migration purposes, low is the direct replacement for minimal.

2. Remove `temperature`, `topP`, and `topK`

Google recommends leaving temperature at its default of 1.0 for every Gemini 3 model. Lower values may cause looping or degraded performance.

Many 3.7 Flash configurations still contain values such as temperature: 0.2 from earlier model generations. Delete the sampling parameters instead of tuning them for 3.8 Flash.

Before:

{
  "generationConfig": {
    "temperature": 0.2,
    "topP": 0.9,
    "topK": 40
  }
}

After:

{
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "medium"
    }
  }
}

For repeatable JSON, use structured outputs rather than low temperature. Structured outputs are supported on 3.8 Flash and return schema-shaped data without changing sampling behavior.

3. Replace `thinking_budget` with `thinking_level`

thinking_budget was an integer token cap. thinking_level is a string enum, and there is no direct arithmetic mapping between them.

Choose based on intent:

low for latency-sensitive routes
medium for default routes
high for the hardest multi-step tasks

Before:

{
  "generationConfig": {
    "thinkingConfig": {
      "thinkingBudget": 4096
    }
  }
}

After:

{
  "generationConfig": {
    "thinkingConfig": {
      "thinkingLevel": "low"
    }
  }
}

Thinking tokens are still billed as output tokens and reported in usageMetadata.thoughtsTokenCount. Cost control now comes from the thinking level plus assertions in your regression tests.

4. Remove `candidate_count`

Gemini 3 and later do not support multiple candidates. Remove the parameter and any code that accesses candidates[1] or later entries.

Before:

{
  "generationConfig": {
    "candidateCount": 2
  }
}

After:

{
  "generationConfig": {}
}

If you previously sampled several candidates and selected the best one, try a higher thinking level instead. The model performs verification within a single response.

5. Include `call_id` and `name` in every function result

This is the second breaking change. Every function result sent to Gemini 3.8 Flash must include both the function call ID and function name.

The Gemini 3 developer guide requires all FunctionResponse objects to include these fields.

Interactions API:

{
  "previous_interaction_id": "<id from the function_call step>",
  "input": [
    {
      "type": "function_result",
      "name": "get_weather",
      "call_id": "<id from the function_call step>",
      "result": [
        {
          "type": "text",
          "text": "{\"temp_c\": 24}"
        }
      ]
    }
  ]
}

The model’s function_call step provides id, name, and arguments. Copy the ID and name into the function result.

In the legacy shape, the functionResponse part uses a field named id, matching the model’s functionCall ID, alongside name and response.

The Gemini 3.8 Flash function-calling guide shows the complete two-turn loop and explains why 3.8 Flash may call tools more times per task.

6. Preserve thought signatures exactly

Gemini 3 models attach thought signatures to response parts. When constructing the next turn, return every response part unchanged, including signatures and non-text parts.

Do not strip or reserialize signatures. Doing so can degrade continuity on the next step.

The Interactions API handles this automatically when you use server-side state:

{
  "previous_interaction_id": "<interaction-id>"
}

If you set store: false, you must manage the history yourself and return the thought blocks and signatures. With legacy generateContent, your application always owns the history, so audit code that rebuilds contents from a trimmed response.

7. Increase token budgets per route

This change does not produce an error, so it is easy to miss. Artificial Analysis measured approximately 30% more output tokens on average at high thinking. Google also notes that the model can use more tokens on long-running and complex tasks, especially at higher effort levels.

Budget by route:

Latency-sensitive: Use low. Artificial Analysis measured about 0.8 minutes and $0.24 per task at low versus 2.5 minutes and $0.58 at high.
Default routes: Use medium, measured at approximately $0.41 per task on the same index.
Agent loops: Expect more tool-call turns. Cap loops by turn count, not only by token count.

Recheck the 65,536-token output ceiling. A 3.7 Flash prompt that returned 40,000 tokens with thinking may approach the limit on 3.8 Flash. The 3.8 Flash pricing breakdown includes per-task estimates for all three thinking levels.

8. Test `media_resolution_high` separately for PDFs and video

Gemini 3.8 Flash accepts text, image, video, audio, and PDF input. Media resolution changes token consumption, and the cost differs by media type.

Do not carry a global high-resolution setting from 3.7 Flash without measuring it. Test one representative PDF and one representative video at each resolution, then compare:

usageMetadata.promptTokenCount

A setting that is affordable for a PDF page may be expensive for a long video.

9. Remove image-segmentation calls

Image segmentation is not supported on Gemini 3 models. If an older pipeline routed segmentation through another Gemini model, that path is separate from this migration.

Prompts asking Gemini 3.8 Flash for segmentation masks should be expected to fail rather than return usable masks. The model page also lists image generation, audio generation, and the Live API as unsupported.

Build a regression plan in Apidog

A migration with two breaking changes and a token-usage shift needs repeatable comparisons rather than a one-off curl request. Apidog works well here as an API client and test runner: it sends requests, validates responses, and schedules tests. It does not run the model itself.

Configure the environment

Create a Gemini environment with:

GEMINI_API_KEY stored as a secret variable
MODEL as an environment variable

Use {{MODEL}} in the generateContent URL and in the Interactions API model field. The same saved requests can then run against either model.

Create golden prompts

Save 10–20 prompts representing your production routes, including:

A short chat turn
A structured-output extraction
A two-turn function call with a mocked tool
A representative PDF input
A representative video input

Make each prompt a request in a test scenario.

Add assertions

Add at least three assertions per request:

The status is 200, and the response matches a JSON schema. For structured-output routes, validate the fields consumed downstream.
usageMetadata.thoughtsTokenCount remains below a route-specific ceiling, such as 8,000 for a low-thinking route.
usageMetadata.totalTokenCount remains below the route budget.

For function calls, also assert that the call_id sent in the function result equals the ID from the previous step’s function_call.

Compare both models

Duplicate the scenario:

Set MODEL to gemini-3.7-flash in one copy.
Set MODEL to gemini-3.8-flash in the other.
Run both scenarios.

Apidog’s test reports show assertion results and response bodies side by side, making token deltas visible per prompt.

Schedule the test

Turn the 3.8 Flash scenario into a scheduled run so token ceilings are checked daily during rollout. Follow the scheduled API tests guide for setup instructions.

You can also download Apidog and import the request fragments above.

Roll back with a configuration flag

Because Gemini 3.7 Flash remains fully supported and has the same price, rollback is inexpensive. Keep model IDs in configuration rather than hard-coding them:

{
  "gemini_model": "gemini-3.8-flash",
  "gemini_fallback_model": "gemini-3.7-flash"
}

Follow three rules:

Keep one request shape for both models. The migrated shape—no minimal, no sampling parameters, thinking_level instead of thinking_budget, no candidate_count, complete function results, and preserved signatures—is valid on 3.7 Flash too.
Roll out by route. Start with low-thinking latency routes, where the token delta is smallest. Move agent loops last, after side-by-side tests pass for several days.
Monitor tokens as well as errors. A 3.8 Flash regression is more likely to appear as a cost or latency increase than as a 4xx response. Feed token-ceiling assertions into alerting.

FAQ

Does Gemini 3.8 Flash cost more than 3.7 Flash?

Not per token. Both cost $0.75 per 1M input tokens and $3.75 per 1M output tokens through December 31, 2026. Both increase to $1.50 and $7.50 on January 1, 2027.

Per task, 3.8 Flash uses more tokens by design. Artificial Analysis measured approximately 30% more output tokens at high thinking.

What happens if I leave `thinking_level: "minimal"` in place?

The request fails with a validation error on 3.8 Flash. Replace it with low. The thinking-level documentation explains the remaining levels and how to measure them.

Do I have to use the Interactions API?

No. generateContent is described as legacy but remains fully supported, with no published sunset date.

The Interactions API provides server-side conversation state through previous_interaction_id, which removes much of the thought-signature bookkeeping described in item 6.

Is Gemini 3.7 Flash deprecated?

No. Google says it “remains fully supported” and has not published a deprecation date. That makes a configuration-flag rollback practical.

Can I keep the temperature tuned for 3.7 Flash?

Google recommends leaving temperature at 1.0 for all Gemini 3 models. If you override it on 3.7 Flash, use this migration to remove the override and rerun your evaluations. Use structured outputs when you need deterministic response shapes.

Ship in stages

The code migration is small:

One model ID change
Four configuration deletions or renames
Two function-result fields
A thought-signature audit

The time-consuming part is proving that token budgets and latency still hold for every route. Save golden prompts, assert response schemas and token ceilings, compare 3.7 and 3.8 Flash side by side until the numbers stabilize, and switch one route at a time.

If a route regresses, the configuration flag can send it back to 3.7 Flash without another code change.

References

Gemini 3.8 Flash pricing: intro rates, thinking tokens, and the real cost per task

Hassann — Thu, 03 Sep 2026 08:21:08 +0000

Gemini 3.8 Flash costs $0.75 per million input tokens and $3.75 per million output tokens—the same introductory rate Google set for 3.7 Flash. This rate runs through December 31, 2026. On January 1, 2027, it doubles to $1.50 and $7.50. The same increase applies to 3.6 Flash and 3.7 Flash. The per-token price did not change with this release.

Try Apidog today

What changed is how many tokens the model uses. Google says 3.8 Flash “works harder”: it takes more reasoning steps, calls tools iteratively, and “can use more tokens on longer running and complex tasks, by design.” Artificial Analysis measured the impact independently: its Intelligence Index cost $0.58 per task on 3.8 Flash at high thinking versus $0.40 on 3.7 Flash, with approximately 30% more output tokens per task.

Same sticker price, higher bill.

This guide covers the official Gemini API pricing page, explains the impact of each thinking level, and compares Gemini 3.8 Flash with Flash-Lite, Claude Sonnet 5, and GPT-5.6 Luna. For a model overview, start with what Gemini 3.8 Flash is.

Gemini 3.8 Flash pricing at a glance

All prices are per 1 million tokens on the paid tier.

Rate	Intro (through Dec 31, 2026)	Standard (from Jan 1, 2027)
Input (text, image, video, audio, PDF)	$0.75	$1.50
Output (includes thinking tokens)	$3.75	$7.50
Context cache read	$0.075	$0.15
Cache storage (per 1M tokens per hour)	$0.50	$1.00
Batch API input (50% off)	$0.375	$0.75
Batch API output (50% off)	$1.875	$3.75
Google Search grounding	5,000 free requests/month shared across Gemini 3.x, then $14 per 1,000	Same
Free tier	$0, rate-limited, data used to improve Google products	Same

Three details matter:

Thinking tokens are billed as output at $3.75 per million, not as input.
The introductory rate ends on December 31, 2026.
3.7 Flash and 3.6 Flash have the same January 1 price increase, so switching to an older Flash model does not avoid it.

The 3.7 Flash pricing breakdown covers the same rates for a model that uses fewer tokens per task.

Thinking tokens count as output tokens

Gemini 3.8 Flash reasons before answering, and every reasoning token is metered as output. A generateContent response reports:

usageMetadata.thoughtsTokenCount: internal reasoning tokens
usageMetadata.candidatesTokenCount: visible answer tokens
usageMetadata.promptTokenCount: input tokens

Both output counters use the same $3.75-per-million rate.

You control reasoning effort with thinking_level: low, medium, or high. On 3.8 Flash, the default is medium; Gemini 3 Pro defaults to high.

minimal is no longer supported and returns a validation error. Configurations migrated from earlier models should map minimal to low.

Google’s thinking documentation describes these settings as relative effort levels rather than fixed token budgets. Unlike the older integer thinking_budget, you cannot directly cap the number of thinking tokens. See the 3.8 Flash thinking levels guide for the latency and cost trade-offs.

Example request cost

Suppose a request uses 10,000 input tokens and returns 2,000 visible output tokens plus 6,000 thinking tokens.

At the introductory rate:

Input: 10,000 × $0.75 / 1,000,000 = $0.0075
Output: (2,000 + 6,000) × $3.75 / 1,000,000 = $0.03
Total: $0.0375 per request

Thinking accounts for 75% of the output charge and 60% of the total request cost.

From January 1, the same request costs:

Input: $0.015
Output: $0.06
Total: $0.075

“Same price as 3.7” is true but incomplete: the rate stayed the same while token usage increased.

Why cost per task increased

Google’s launch post describes the trade-off directly. On complex tasks, 3.8 Flash “executes extra reasoning steps, and calls tools iteratively,” verifying its work along the way.

More reasoning steps create more thinking tokens. Agent loops can also create additional tool-call turns.

Google’s recommended mitigations are to lower thinking_level or remain on 3.7 Flash.

Artificial Analysis measured the difference using nine evaluations in its Intelligence Index. Gemini 3.8 Flash at high scored 59 versus 56 for 3.7 Flash at high, while using approximately 48,000 output tokens per task—30% more than 3.7 Flash.

Configuration	Cost per task (AA, intro rates)	Time per task
Gemini 3.8 Flash, high	$0.58	2.5 min
Gemini 3.8 Flash, medium	$0.41	not published
Gemini 3.8 Flash, low	$0.24	0.8 min
Gemini 3.7 Flash, high	$0.40	2.2 min

The results support two conclusions:

3.8 Flash at high costs 45% more per task than 3.7 Flash at high: $0.58 / $0.40 = 1.45.
On 3.8 Flash, medium reduces cost by 29% compared with high: $0.41 / $0.58 = 0.71.
Low reduces cost by 59% compared with high: $0.24 / $0.58 = 0.41.

Medium on 3.8 Flash costs within one cent of high on 3.7 Flash, which is a useful benchmark when deciding whether to upgrade. The 3.8 Flash vs. 3.7 Flash comparison compares the models by workload.

Artificial Analysis also reports a blended price of $0.58 per million tokens at a 3:1 input-to-output ratio. Its matching the high-level cost per task is coincidental: the blended price is a per-token calculation, while task cost depends on how many tokens the model chooses to use.

Use the introductory rate before December 31

“Lock in” does not mean signing a contract. Google bills tokens at the rate in effect when they are consumed, so you cannot prepay 2027 usage at 2026 prices. Switching to 3.7 or 3.6 Flash also does not avoid the increase.

You can, however, move discretionary work into the introductory-rate window:

Run backfills and one-off document processing through the Batch API. A 100-million-token backfill with 75 million input tokens and 25 million output tokens costs:

75 × $0.375 + 25 × $1.875 = $28.13 + $46.88 = $74.99

in batch during 2026. The same workload costs twice as much—$149.98—in January.

Build your evaluation set now. Establish baseline token counts before the price change, so you can distinguish increased usage from increased rates.
Choose a thinking level per route. Every production route left on medium by default is a route whose cost has not been evaluated. Routes that pass your tests at low should use low before January.

If price is the deciding factor, see the cheapest LLM API providers roundup. The Fable 5.1 and GPT-5.6 Sol comparison covers the premium tiers.

Gemini 3.8 Flash vs. Flash-Lite, Sonnet 5, and GPT-5.6 Luna

Per-token rates, per 1 million tokens:

Model	Input	Output	Notes
Gemini 3.8 Flash (intro)	$0.75	$3.75	Thinking billed as output; cache read $0.075
Gemini 3.8 Flash (from Jan 1)	$1.50	$7.50	Cache read $0.15
Gemini 3.5 Flash-Lite	$0.30	$2.50	About 350 tok/s
Claude Sonnet 5	$2	$10	Permanent; the Sep 1 rise was cancelled
GPT-5.6 Luna	$1	$6

At introductory rates:

3.8 Flash input costs 2.5 times Flash-Lite’s input rate.
3.8 Flash output costs 1.5 times Flash-Lite’s output rate.
3.8 Flash is approximately 2.7 times cheaper than Sonnet 5 for both input ($2 / $0.75) and output ($10 / $3.75).
3.8 Flash is cheaper than Luna for input ($0.75 vs. $1) and output ($3.75 vs. $6).

On January 1, the comparison changes:

3.8 Flash becomes more expensive than Luna for both input and output.
The gap with Sonnet 5 narrows to approximately 1.3 times ($2 / $1.50 and $10 / $7.50).
Flash-Lite remains cheaper throughout.

If the introductory rate is why you selected 3.8 Flash, schedule a January re-evaluation now.

Per-token pricing is only half the calculation. A model with a higher rate can still cost less per task if it uses fewer tokens. Run the same task set through each candidate and compare the returned usage counts. The 3.8 Flash API guide shows how to read usageMetadata from both the Interactions API and legacy generateContent.

Catch cost regressions with Apidog token assertions

The main failure mode is not necessarily an incorrect answer. It is a correct answer that quietly uses 40% more tokens after a prompt or thinking-level change—until the invoice exposes the regression.

Apidog lets you treat token usage as an assertion target, just like an HTTP status code.

1. Store the API key securely

Create GEMINI_API_KEY in an Apidog environment and reference it as {{GEMINI_API_KEY}} in the x-goog-api-key header. The key never needs to be stored in the saved request.

2. Send a representative prompt

Save a POST request to:

https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:generateContent

Use a representative production prompt and set an explicit thinkingConfig.thinkingLevel for each route.

3. Assert on usage fields

Add a post-processor script that reads usageMetadata and fails when usage exceeds your baseline:

const usage = pm.response.json().usageMetadata;
pm.test("thinking tokens within budget", () => {
  pm.expect(usage.thoughtsTokenCount).to.be.below(8000);
});
pm.test("visible output within budget", () => {
  pm.expect(usage.candidatesTokenCount).to.be.below(2500);
});
pm.test("request cost within budget", () => {
  const cost = usage.promptTokenCount * 0.75 / 1e6
    + (usage.thoughtsTokenCount + usage.candidatesTokenCount) * 3.75 / 1e6;
  pm.expect(cost).to.be.below(0.05);
});

4. Schedule the test

Put the requests in a test scenario and run it on a schedule. A token-usage increase then appears as a failed run the same day. The guide to scheduling API tests in Apidog covers the setup.

Update the two rate constants on January 1; the cost assertion will continue tracking the actual bill.

The same scenario can power a provider bake-off. Point copies at Flash-Lite, Sonnet 5, or Luna and compare usage fields side by side. Download Apidog to build the first scenario; the free plan supports this workflow.

FAQ

Does Gemini 3.8 Flash cost more than 3.7 Flash?

Per token, no. Both cost $0.75 per million input tokens and $3.75 per million output tokens through December 31, followed by $1.50 and $7.50 from January 1. Per task, yes: Artificial Analysis measured $0.58 per Intelligence Index task on 3.8 Flash at high versus $0.40 on 3.7 Flash because 3.8 Flash generates approximately 30% more output tokens.

Are thinking tokens billed separately?

No. They are billed as output tokens at $3.75 per million during the introductory period and appear in usageMetadata.thoughtsTokenCount. You control them indirectly through thinking_level; 3.8 Flash has no hard token budget, and minimal returns an error.

Is there a free tier for Gemini 3.8 Flash?

Yes. The AI Studio free tier charges nothing for input or output, subject to rate limits shown in AI Studio. Google uses free-tier data to improve its products.

The consumer Gemini app provides 3.8 Flash only to AI Pro and Ultra subscribers. See the free-usage guide for details.

What happens to costs on January 1, 2027?

Input, output, cache-read, cache-storage, and batch rates all double. If token usage per task remains constant, your bill doubles as well. The 3.6 and 3.7 Flash rates increase on the same date.

Which thinking level keeps costs down?

Start with Artificial Analysis’s measurements: $0.24 per task at low, $0.41 at medium, and $0.58 at high. Run your own evaluations at each level, keep the lowest setting that passes, and assert on token counts so the configuration cannot drift.

What to do this week

Gemini 3.8 Flash is priced like 3.7 Flash but uses tokens like a larger model.

This week:

Set thinking_level per production route instead of accepting the default.
Move batch-friendly work into the introductory-rate window before December 31.
Establish token baselines now.
Add assertions for thinking tokens, visible output tokens, and estimated request cost.
Schedule a provider and pricing re-evaluation for January 1, 2027.

That turns the January price increase into a planned variable instead of an invoice surprise.

Gemini 3.8 Flash vs Claude Fable 5.1 vs GPT-5.6 Sol: which API should developers use?

Hassann — Thu, 03 Sep 2026 08:06:06 +0000

Gemini 3.8 Flash vs Claude Fable 5.1 vs GPT-5.6 Sol: Which API Should You Use?

Three frontier APIs shipped or changed pricing within a week of one another, landing in three distinct price bands. Google released Gemini 3.8 Flash on September 2, 2026, at $0.75 per million input tokens and $3.75 per million output tokens. Anthropic released Claude Fable 5.1 the day before at $10 and $50. OpenAI’s GPT-5.6 Sol sits between them at $5 and $30. On Artificial Analysis’ independent Intelligence Index, they score 59, 57, and 59 respectively. A model priced at roughly one-thirteenth of the top tier matches it on the only index that evaluates all three the same way.

Try Apidog today

The catch is the word “index.” Benchmarks count answers per task; your bill counts tokens per task. Gemini 3.8 Flash is designed to spend more of them.

This guide compares the three models by:

Published specifications
Google’s cross-vendor benchmark tables
Artificial Analysis’ independent results
Input, output, and cache pricing
Cost per completed task
Best-fit workloads

Google’s launch post is the primary source for the Gemini claims below. For context, our August comparison used Claude Fable 5, not 5.1. Anthropic replaced that model on September 1, making this a new comparison rather than a refresh.

Specs at a glance

Specification	Gemini 3.8 Flash	Claude Fable 5.1	GPT-5.6 Sol
Vendor	Google	Anthropic	OpenAI
Context window	1,048,576 tokens	1M tokens	1M tokens
Maximum output	65,536 tokens	128K tokens	128K tokens
Input price per 1M tokens	$0.75 introductory; $1.50 from Jan. 1, 2027	$10	$5
Output price per 1M tokens	$3.75 introductory; $7.50 from Jan. 1, 2027	$50	$30
Cache read per 1M tokens	$0.075 introductory; $0.15 from Jan. 1	$0.25	$0.50
Knowledge cutoff	March 2026	June 2026	Not listed here
Reasoning control	`thinking_level`: low, medium, high; medium default	Extended thinking, always on	Effort levels up to `xhigh`
Artificial Analysis Index	59 at high	57 at medium	59 at `xhigh`

Two specifications matter immediately:

Gemini 3.8 Flash has half the maximum output of the other two: 65,536 versus 128K tokens. That matters for single-shot long documents more than for agent loops that emit short steps.
Gemini’s introductory pricing ends on December 31, 2026. Both rates double on January 1, 2027, changing every price ratio in this article.

The Gemini 3.8 Flash pricing guide covers the doubling, caching, batch, and grounding rates in detail.

The independent result: 59, 57, and 59

Artificial Analysis runs the same nine evaluations against each model and publishes one Intelligence Index score:

Gemini 3.8 Flash at high thinking: 59
GPT-5.6 Sol at xhigh effort: 59
Claude Fable 5.1 at medium effort: 57

Gemini 3.8 Flash improved from 56 for 3.7 Flash and 52 for 3.6 Flash. Fable 5.1’s score of 57 also matches GPT-5.6 Terra at max effort and Muse Spark 1.2 at xhigh. Grok 4.6 at medium is another model at 59.

Read the reasoning settings before interpreting those numbers. Fable 5.1 was tested at medium, while Sol was tested at its top listed setting, xhigh. A two-point difference across different effort levels is not a definitive ranking.

The defensible conclusion is narrower: at the tested settings, Gemini 3.8 Flash matches the two premium models on this index and is the cheapest model with a score of 59 by a wide margin.

What that score costs

Artificial Analysis also measured token usage and latency for Gemini 3.8 Flash at high thinking:

Average output per task: 48,000 tokens
Output usage: 30% more than Gemini 3.7 Flash
API spend: $0.58 per task
Time per task: 2.5 minutes
Output speed: about 300 tokens per second
Time to first [REDACTED CREDENTIAL] seconds**
τ³-Banking tool-use score: 45%, 12 points above Gemini 3.7 Flash

The model thinks before it writes, which explains the relatively high time to first token. Keep these measurements in mind when the per-token price appears too attractive.

Google’s benchmark tables—and the missing model

Google’s Flash page publishes three cross-vendor benchmark rows in text form, but Claude Fable 5.1 is not included. The Anthropic entries are Claude Opus 5 and Claude Sonnet 5 instead. Fable 5.1 had been public for only one day when Google’s tables were published.

The Anthropic results below are therefore proxies, not direct results for Fable 5.1:

Google-run benchmark	Gemini 3.8 Flash	Claude Opus 5	Claude Sonnet 5	GPT-5.6 Sol	GPT-5.6 Terra
HLE-Verified	54.9%	54.4%	31.0%	54.5%	51.1%
Vals Finance Agent v2	61.4%	58.6%	53.9%	53.8%	54.4%
Harvey Legal Agent Benchmark	10.0%	6.7%	5.0%	2.5%	0.8%

HLE-Verified is effectively a three-way tie: Gemini 3.8 Flash, Opus 5, and Sol are within half a point of one another.

Vals Finance Agent v2 is where Gemini 3.8 Flash separates:

2.8 points above Opus 5
7.6 points above Sol

Harvey Legal is the outlier. Every model scores below 11%, so the ordering is more meaningful than the gaps.

Google did not publish text results for:

SWE-Bench Pro
Terminal-bench
OSWorld

The DeepSWE v1.1 result appears only as an image-table claim that Gemini 3.8 Flash “outperforms most larger frontier models” at “a fraction of the cost.”

For coding and computer-use comparisons, you must rely on separate vendor-run evaluations, which do not overlap. Anthropic’s results are in the Claude Fable 5.1 benchmarks breakdown, and OpenAI’s are in the GPT-5.6 Sol benchmarks. Artificial Analysis remains the only like-for-like source in this comparison.

The price gap, line by line

At introductory rates:

Fable 5.1 input is 13.3× Gemini 3.8 Flash input
Fable 5.1 output is 13.3× Gemini 3.8 Flash output
Sol input is 6.7× Gemini input
Sol output is 8× Gemini output

Cache reads narrow the difference:

Gemini 3.8 Flash: $0.075 per 1M tokens
Fable 5.1: $0.25 per 1M tokens, or 3.3× Gemini
Sol: $0.50 per 1M tokens, or 6.7× Gemini

Fable 5.1’s cache-read price is half of Sol’s—the one pricing line where the most expensive model is not the most expensive option.

Worked example

Assume a request uses 1 million input tokens and 200,000 output tokens, with no cached input:

Gemini 3.8 Flash: $0.75 + $0.75 = $1.50
GPT-5.6 Sol: $5.00 + $6.00 = $11.00
Claude Fable 5.1: $10.00 + $10.00 = $20.00

From January 1, 2027, the same Gemini request costs $3.00. The gaps then compress to:

Sol: 3.7× Gemini’s cost
Fable 5.1: 6.7× Gemini’s cost

The price doubling also applies to Gemini 3.6 Flash and 3.7 Flash, so there is no cheaper Gemini Flash fallback at the same introductory rates.

See the Claude Fable 5.1 pricing guide and GPT-5.6 pricing guide for batch and cache tiers.

Measure cost per task, not just cost per token

Google says Gemini 3.8 Flash “can use more tokens on longer running and complex tasks, by design.”

On difficult problems, the model may:

Take smaller reasoning steps
Verify intermediate results
Call tools iteratively

Artificial Analysis measured the impact:

Gemini 3.8 Flash setting	Cost per task
High	$0.58
Medium	$0.41
Low	$0.24

At high, Gemini used an average of 48,000 output tokens per task—30% more than Gemini 3.7 Flash. As a result, its measured cost rose from $0.40 per task for 3.7 Flash to $0.58 for 3.8 Flash at unchanged token prices.

Two conclusions follow:

A 13.3× per-token gap does not guarantee a 13.3× bill reduction. A premium model may finish with fewer tokens or fewer tool turns.
On Gemini, thinking_level is a major cost control. Moving from high to low reduced measured cost by more than half.

Artificial Analysis has not published comparable per-task figures for Fable 5.1 or Sol in the available text. Benchmark your own prompts before assuming any multiplier.

The Gemini 3.8 Flash thinking-levels guide explains how to configure the setting per endpoint. In some routes, Gemini 3.7 Flash may still be the better buy because its measured per-task cost is 31% lower; see the 3.8 Flash vs. 3.7 Flash comparison.

When to choose each model

Choose Gemini 3.8 Flash for volume and cost-sensitive agents

Use Gemini 3.8 Flash as the default for thousands of agent tasks per day. It matches the premium models on the independent index, leads Google’s finance and legal agent rows, and remains substantially cheaper per token after the January 2027 price increase.

Additional advantages include:

Native video, audio, and PDF inputs
Batch processing at 50% off
5,000 free Google Search grounding requests per month
A free tier for prototyping

Trade-offs:

Text-only output
No Live API
65,536-token output ceiling
Higher token usage on complex tasks

Set thinking_level to medium or low where the workload does not require high-depth reasoning.

Choose Claude Fable 5.1 for the hardest long-horizon reasoning

Fable 5.1 is an escalation model rather than the default starting point. Use it when an incorrect result costs more than the additional tokens, such as:

Multi-hour research agents
Long terminal sessions
Reasoning chains where cheaper models fail your evaluations

Its 128K output limit and $0.25 cache reads are useful for prefix-heavy agent loops that reuse a large context on every turn. In those workloads, the effective cost multiplier can be much smaller than 13.3×.

See what Claude Fable 5.1 is for its own specification and positioning.

Choose GPT-5.6 Sol for OpenAI-based agent stacks

Sol scores 59 at xhigh, ties Gemini 3.8 Flash on HLE-Verified, and offers 128K output at $5 input and $30 output per million tokens.

It is a practical premium option when your agents, evaluations, and tooling already use OpenAI’s ecosystem. The downside is its $0.50 cache-read price, the highest of the three. Sol is therefore a better fit for fresh-context workloads than for long cached sessions.

The Grok 4.6 vs. GPT-5.6 vs. Claude Fable 5 comparison provides additional context on Sol versus the previous Anthropic flagship.

Test all three in one Apidog workspace

Every model argument should end with the same action: measure your own prompts.

Apidog is an API client and testing platform. It does not run these models, but it makes it fast to send the same request to all three providers and compare the results.

1. Create three environments

Create one project with three environments. Store each provider’s base URL and API key as environment variables:

Environment	Base URL variable	API key variable
Gemini	`https://generativelanguage.googleapis.com`	`GEMINI_API_KEY`
Claude	Anthropic’s base URL	Your Claude key
OpenAI	OpenAI’s base URL	Your OpenAI key

Keep keys in environment variables—not in request bodies or shared collections.

2. Create one test scenario

Add three request steps with the same prompt.

The Gemini request uses /v1beta/interactions with:

{
  "model": "gemini-3.8-flash",
  "thinking_level": "medium"
}

The Claude and OpenAI steps should use their respective messages or chat endpoints.

Add assertions to every step:

HTTP status is 200
A JSON path confirms that an answer is present
The token-usage field stays below your cost ceiling

For Gemini’s legacy endpoint, the reasoning-token field is:

usageMetadata.thoughtsTokenCount

Assert against the equivalent usage block for the other providers.

3. Run and schedule the comparison

Run the scenario against a set of golden prompts, then schedule it daily. If a vendor changes a default or a model starts consuming more thinking tokens, the failed assertion alerts you before the invoice does.

Use the AI agent API testing guide for multi-turn scenarios and scheduling API tests in Apidog for recurring runs.

Download Apidog to create the three at $0.75 input and $3.75 output through December 31, 2026.

Artificial Analysis measured its cost per task at:

$0.58 at high
$0.41 at medium
$0.24 at low

Because token usage varies by model and prompt, measure cost per completed task—not just cost per token.

Do all three models have a 1M-token context window?

Yes:

Gemini 3.8 Flash: 1,048,576 input tokens
Claude Fable 5.1: 1M tokens
GPT-5.6 Sol: 1M tokens

Maximum output differs. Gemini supports 65,536 tokens, while the other two support 128K.

Why is Claude Fable 5.1 missing from Google’s benchmark tables?

Google’s published rows list Claude Opus 5 and Claude Sonnet 5. Fable 5.1 shipped on September 1, one day before Gemini 3.8 Flash, so it was not included.

For Anthropic’s own results, see the Claude Fable 5.1 vs. Opus 5 comparison.

Does Gemini’s price advantage survive 2027?

Partly. On January 1, 2027, Gemini 3.8 Flash moves to $1.50 input and $7.50 output per million tokens.

It remains cheaper, but the gap falls to:

Fable 5.1: 6.7× Gemini on both input and output
Sol: 3.3× Gemini on input and 4× on output

Which model should you call first?

Start with Gemini 3.8 Flash for high-volume workloads. Set thinking_level per route and monitor tokens per task.

Escalate to Claude Fable 5.1 when cheaper models fail your evaluations, especially when you reuse a large context across turns. Choose GPT-5.6 Sol when the rest of your stack is already OpenAI-based and you want a premium model without adding another vendor.

Before committing, send the same golden prompts to all three models in one test scenario. The price ratio is public; the cost-per-task ratio for your prompts is yours to measure.

References

What is Gemini 3.8 Flash?

Hassann — Thu, 03 Sep 2026 05:14:43 +0000

Gemini 3.8 Flash: More Agentic Reasoning at the Same Token Price

Gemini 3.8 Flash is Google’s newest Flash-tier model, released on September 2, 2026, alongside the gated security model Gemini 3.8 Flash Cyber. It is the third Flash release in six weeks, following Gemini 3.6 Flash on July 21 and Gemini 3.7 Flash on August 13. Introductory pricing matches 3.7 Flash: $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026. Google describes it as “our most intelligent Flash model, engineered for long-horizon software engineering, autonomous agents, and complex enterprise workflows.”

Try Apidog today

The main change is behavior, not price or context size. Gemini 3.8 Flash takes smaller reasoning steps, verifies its work, and calls tools iteratively. This improves agentic benchmark results, but also increases token usage by design. Artificial Analysis measured approximately 30% more output tokens than Gemini 3.7 Flash.

So the per-token price is unchanged, but the per-task cost can be higher.

Gemini 3.8 Flash at a glance

Specification	Value
API model ID	`gemini-3.8-flash`
Released	September 2, 2026
Based on	Gemini 3.7 Flash, according to the DeepMind model card
Context window	1,048,576 input tokens
Maximum output	65,536 tokens
Input modalities	Text, image, video, audio, PDF
Output modalities	Text only
Thinking levels	`low`, `medium` (default), `high`; `minimal` returns an error
Introductory pricing	$0.75 input / $3.75 output per million tokens through December 31, 2026
Standard pricing	$1.50 input / $7.50 output per million tokens from January 1, 2027
Context caching	$0.075 per million cached tokens introductory; $0.15 standard
Batch API	50% off: $0.375 input / $1.875 output introductory
Knowledge cutoff	March 2026
Developer availability	Gemini API, Google AI Studio, Android Studio, Google Antigravity, Stitch, Gemini Enterprise
Consumer availability	Gemini app for AI Pro and Ultra subscribers, AI Mode in Search, Gemini in Google Sheets
Gemini 3.7 Flash	Fully supported; no deprecation date announced

Three details matter during migration:

The default thinking level is medium, not high as with Gemini 3 Pro.
minimal returns a validation error instead of falling back to low. See the thinking levels guide.
Although the stated knowledge cutoff is March 2026, the model card notes that some domains may have knowledge limited to January 2025.

What Gemini 3.8 Flash is

Flash is Google’s workhorse tier: it is intended for most production traffic, while Pro targets the hardest problems. Google calls Gemini 3.8 Flash its “most intelligent workhorse model yet,” but the DeepMind model card describes it as based on Gemini 3.7 Flash.

A practical description is therefore: Gemini 3.7 Flash refined for long-running software engineering and agent workflows.

The release cadence is unusually fast:

Gemini 3.6 Flash: July 21, 2026, at $1.50 / $7.50
Gemini 3.7 Flash: August 13, 2026, at the $0.75 / $3.75 introductory rate
Gemini 3.8 Flash: September 2, 2026, at the same introductory rate

Google calls this the third Flash release in six weeks. Artificial Analysis counts a fourth Flash model in under four months because its tally includes Gemini 3.5 Flash-Lite. No Gemini 3.8 Pro, Gemini 4, or new Flash-Lite model shipped with this release.

Gemini 3.7 Flash remains supported, and Google has not announced a deprecation date or a timeline for a Pro update. The previous Gemini 3.7 Flash what’s-new post is already describing the previous generation only three weeks after publication.

The “works harder” design—and its cost

Google describes Gemini 3.8 Flash’s changes in concrete terms. On difficult tasks, it:

Executes additional reasoning steps
Breaks work into smaller reasoning steps
Verifies intermediate results
Calls tools iteratively

Google also warns that the model can use more tokens on long-running and complex tasks, especially at higher effort levels.

Artificial Analysis measured the impact using its Intelligence Index:

Thinking level	Cost per task	Time per task
High	$0.58	2.5 minutes
Medium	$0.41	—
Low	$0.24	0.8 minutes

At high reasoning, Gemini 3.8 Flash averaged 48,000 output tokens per task—about 30% more than Gemini 3.7 Flash. The comparable 3.7 Flash high-reasoning task cost was $0.40 and took 2.2 minutes.

This makes thinking_level a routing decision rather than a global configuration:

Use low for latency-sensitive endpoints.
Use medium for most agent workflows.
Use high when task completion matters more than token or time budgets.

Speed is otherwise similar to Gemini 3.7 Flash. Logan Kilpatrick of Google described it as “same price as 3.7, [and] ~the same speed.” Artificial Analysis measured 302.1 output tokens per second at high reasoning. Its 13.30-second time to first token reflects model-side thinking, not necessarily network latency.

See the pricing breakdown for examples across 1,000 agent tasks per day.

What the benchmarks say

Google published the following benchmark results on its DeepMind Flash page:

Benchmark	Gemini 3.8 Flash	Gemini 3.7 Flash	Claude Opus 5	GPT-5.6 Sol	GPT-5.6 Terra	Claude Sonnet 5
Vals Finance Agent v2	61.4%	59.0%	58.6%	53.8%	54.4%	53.9%
Harvey Legal Agent Benchmark	10.0%	8.8%	6.7%	2.5%	0.8%	5.0%
HLE-Verified	54.9%	53.6%	54.4%	54.5%	51.1%	31.0%

The gains over Gemini 3.7 Flash are 2.4, 1.2, and 1.3 percentage points. The finance and legal results place a Flash-priced model ahead of Opus 5 and GPT-5.6 Sol on these published tests.

Claude Fable 5.1, released the day before, is not included in Google’s tables. The three-way comparison uses Anthropic’s Opus 5 and Sonnet 5 results as the closest published entries.

Google also reports:

On DeepSWE v1.1, Gemini 3.8 Flash outperforms most larger frontier models at a fraction of the cost. The model card includes image-based percentage tables; Google reports Gemini 3.7 Flash at 65.3%.
On document-heavy, long-running workflows, an internal evaluation completed more than three times as many tasks as Gemini 3.7 Flash.
On the Gray Swan prompt-injection evaluation, it achieved a “significant leap,” without a published figure.

Text results for SWE-Bench Pro, Terminal-bench, and OSWorld were not published for Gemini 3.8 Flash.

Artificial Analysis independently scored Gemini 3.8 Flash high at 59 on its Intelligence Index, compared with:

Gemini 3.7 Flash: 56
Gemini 3.6 Flash: 52
GPT-5.6 Sol xhigh: 59
Grok 4.6 medium: 59
GPT-5.6 Terra max: 57
Claude Fable 5.1 medium: 57
Muse Spark 1.2 xhigh: 57

On the τ³-Banking tool-use evaluation, Gemini 3.8 Flash scored 45%, 12 points above Gemini 3.7 Flash. The 3.8 versus 3.7 comparison weighs these gains against the added token consumption.

Pricing: same per token, more per task

The official pricing page lists Gemini 3.8 Flash alongside Gemini 3.6 and 3.7 Flash. Prices double on January 1, 2027.

Item	Through December 31, 2026	From January 1, 2027
Input	$0.75 / 1M tokens	$1.50 / 1M tokens
Output, including thinking	$3.75 / 1M tokens	$7.50 / 1M tokens
Cached input	$0.075 / 1M tokens	$0.15 / 1M tokens
Cache storage	$0.50 / 1M tokens / hour	$1.00 / 1M tokens / hour
Batch input / output	$0.375 / $1.875	$0.75 / $3.75

Two billing details are easy to miss:

Thinking tokens are billed as output tokens and reported separately as usageMetadata.thoughtsTokenCount. A short high-reasoning answer can cost more than a longer low-reasoning answer.
Google Search grounding has a separate meter: 5,000 free requests per month shared across Gemini 3.x models, then $14 per 1,000 requests.

AI Studio and the API provide a rate-limited free tier. Google states that free-tier data is used to improve its products. Per-model rate limits are shown in AI Studio.

Billing tiers unlock as follows:

Tier 1: link a billing account
Tier 2: spend $100 and wait three days
Tier 3: spend $1,000 and wait 30 days

The free-access guide explains the free path, while the Batch API guide covers the 50% discount for jobs that can wait.

How to call Gemini 3.8 Flash

Google now treats the Interactions API as the primary API for Gemini 3.x. generateContent is considered legacy but remains fully supported with no announced sunset date.

A minimal Interactions API request looks like this:

curl -X POST "https://generativelanguage.googleapis.com/v1beta/interactions" \
  -H "x-goog-[REDACTED CREDENTIAL] \
  -H 'Content-Type: application/json' \
  -d '{"model":"gemini-3.8-flash","input":"Explain HTTP caching in 3 sentences.","generation_config":{"thinking_level":"medium"}}'

For multi-turn conversations, send previous_interaction_id so the server can maintain state.

Function calling uses a JSON Schema tool declaration. The model returns a function_call step, and your application sends back a function_result containing both call_id and name. Both fields are required for Gemini 3.8 Flash. In legacy generateContent, the corresponding field is id.

The API walkthrough includes REST and Python examples. The function calling guide explains iterative tool loops and how to cap them.

When migrating from Gemini 3.7 Flash, watch for these incompatibilities:

minimal thinking is rejected.
thinking_budget is replaced by thinking_level.
candidate_count is unsupported.
Google recommends leaving temperature at its default of 1.0; lowering it may cause looping or degraded performance.

Use the migration guide for before-and-after JSON examples.

What Gemini 3.8 Flash cannot do

Gemini 3.8 Flash does not support:

Audio generation
The Live API
Image generation
Image segmentation, which is not supported on Gemini 3 models

Although the model accepts text, images, video, audio, and PDFs as input, its output is text only. For real-time voice or image output, use Gemini 3.8 Flash as the reasoning and tool-calling layer alongside other services.

For inexpensive, high-throughput text generation without heavy reasoning, Gemini 3.5 Flash-Lite remains available at $0.30 input / $2.50 output per million tokens.

Supported features include:

Function calling
Structured outputs
Context caching
Code execution
Search and Maps grounding
Batch API
Computer use in preview

Gemini 3.8 Flash Cyber: the gated twin

Gemini 3.8 Flash Cyber shipped on the same day, but it is not publicly available. Access is limited to Google’s Fairwind Program for trusted government authorities, critical infrastructure operators, and software maintainers.

The program requires background checks and controls such as phishing-resistant MFA. There is:

No public API
No public pricing
No self-hosting option

Gemini 3.8 Flash Cyber replaces the Gemini 3.5 Flash Cyber limited pilot.

Google reports a vulnerability-discovery success rate above 70% across 20 programming languages. Google’s Chrome security team also reports that Cyber produced 2.6 times more correct vulnerability patches than the best much-larger commercial models. Both figures are Google-reported.

The Cyber explainer covers eligibility, obligations, and the implications for teams without access.

Test Gemini 3.8 Flash in Apidog

Because Gemini 3.8 Flash’s cost is driven by task-level token usage, a successful HTTP response is not enough. Test how many tokens each request consumes.

In Apidog:

Store GEMINI_API_KEY as an environment variable.
Save both Interactions API and generateContent requests as endpoints.
Assert that the response status is 200.
Validate the JSON fields consumed by your application.
Set a ceiling for usageMetadata.thoughtsTokenCount.
Run the same prompt at low, medium, and high.
Compare token usage and latency for your own workload.

Streaming responses use SSE. Set includeThoughts: true when debugging thought summaries, then follow the SSE testing guide.

Schedule the scenario daily so a token regression fails an assertion before it reaches your invoice. You can download Apidog and set up the test on the free plan.

FAQ

Is Gemini 3.8 Flash a new model or an update to Gemini 3.7 Flash?

The DeepMind model card says it is based on Gemini 3.7 Flash. Treat it as a tuned successor with the same price, speed, and context window, but more reasoning and tool-calling steps on difficult tasks. Gemini 3.7 Flash remains fully supported with no announced deprecation date.

Why does Gemini 3.8 Flash use more tokens than Gemini 3.7 Flash?

That behavior is intentional. Google says Gemini 3.8 Flash can use more tokens on long-running and complex tasks. Artificial Analysis measured approximately 30% more output tokens in its benchmark.

Set thinking_level to medium or low for routes that do not need maximum reasoning. The thinking levels guide includes per-level cost examples.

What is the Gemini 3.8 Flash context window?

The model supports 1,048,576 input tokens and 65,536 output tokens. Context caching costs $0.075 per million cached tokens through December 31, 2026.

Can I use Gemini 3.8 Flash in the free Gemini app?

Launch coverage lists the Gemini app for Google AI Pro and Ultra subscribers, not the free app tier. Developers can use a rate-limited free tier in AI Studio and the API.

How does Gemini 3.8 Flash compare with Claude Fable 5.1?

Artificial Analysis scores Gemini 3.8 Flash at 59 and Claude Fable 5.1 at 57. Claude Fable 5.1 costs $10 input / $50 output per million tokens—approximately 13 times Gemini 3.8 Flash’s introductory rate for both token types.

That gap narrows when you account for Gemini 3.8 Flash’s higher token consumption per task. See the Claude Fable 5.1 overview.

Conclusion

Gemini 3.8 Flash is a workhorse that reasons longer. The trade-off is explicit: modest gains on agentic benchmarks and a 12-point improvement on tool use, offset by approximately 30% more output tokens at high reasoning.

If Gemini 3.7 Flash was hitting limits on complex agent tasks, Gemini 3.8 Flash offers the upgrade at the same per-token price. If your workload is latency-sensitive chat, use low or stay on Gemini 3.7 Flash.

Start with the API walkthrough, send a request from Apidog with a token-count assertion, and choose the thinking level for each route based on your own workload—not only the launch benchmarks.

Reference links

Claude Mythos 5.1 vs Fable 5.1: Same Model, Different Safeguards

Hassann — Wed, 02 Sep 2026 04:16:28 +0000

Anthropic released Claude Fable 5.1 and Claude Mythos 5.1 together on September 1, 2026, describing them as “the same model but with different levels of safeguards.” They use the same weights, specifications, pricing, and API. Fable 5.1 is generally available, while Mythos 5.1 is limited to approved organizations in Project Glasswing through cybersecurity and life-sciences verification programs. Mythos 5.1 also powers Anthropic’s Claude Security product.

Try Apidog today

This guide compares the models, explains their four practical differences, shows how Mythos 5.1 access works, and examines the only published benchmark gap. Sources include Anthropic’s launch post and the Fable 5.1 migration guide, which covers both models.

For more context, see what “Mythos-class” means and Fable 5 vs. Mythos 5.

Side-by-side comparison

	Claude Fable 5.1	Claude Mythos 5.1
Model ID	`claude-fable-5-1`	`claude-mythos-5-1`
Availability	All customers	Project Glasswing participants only
Access route	Sign up	Cyber Verification Program or Life Sciences Verification Program; US organizations
Pricing	$10 / $50; cache reads $0.25	Same
Context / maximum output	1M / 128K	Same
Knowledge cutoff	June 2026	Same
Thinking	Adaptive, always on	Same
Forced `tool_choice`	400	400
Safety classifiers	Full Fable set: `cyber`, `bio`, `frontier_llm`, `reasoning_extraction`, `general_harms`	Program-specific safeguards; more permissive for approved defensive work
Vulnerability work	Can identify vulnerabilities but cannot develop exploits	Can discover exploit paths for approved defensive research
Reads Fable 5.1 thinking blocks	Yes	Yes—the only other model that can
History-editing check	Yes	No
Platforms	Claude API, Bedrock, Claude Platform on AWS, Google Cloud, Foundry	Claude API, Bedrock, Google Cloud, Foundry; not Claude Platform on AWS
Priority Tier	No	No
Data retention	30-day required; Covered Model	Same
Terminal-Bench 4.0	55.8%	60.9%

What is identical

Anthropic describes Fable 5.1 and Mythos 5.1 as the same model with different safeguards. Both provide:

A 1M-token context window
A 128K-token maximum output
Always-on adaptive thinking
Five effort levels
A June 2026 knowledge cutoff
$0.25 cache reads
The same pricing and API behavior
The same three Fable 5-generation breaking changes, except for the history-editing check described below

The Fable 5.1 specification overview also applies to Mythos 5.1.

Both models require 30-day data retention and are Covered Models. They are not available under zero data retention unless Anthropic explicitly authorizes it. Neither supports Priority Tier, and both include Anthropic’s statistical text watermark on every platform.

Difference 1: availability and access

Fable 5.1 is generally available through the Claude API and every supported partner platform.

Mythos 5.1 is limited to approved Project Glasswing customers. At launch, there were two access routes:

The Cyber Verification Program for defensive security professionals, with applications submitted through Anthropic’s portal.
The Life Sciences Verification Program for life-sciences organizations, operated in partnership with the US government with enrollment expanding over time.

Both programs were limited to US organizations at launch. Access is arranged through your Anthropic, AWS, or Google Cloud account team. Whether existing Mythos 5 access transfers automatically was still being confirmed.

This differs from the Mythos 5 generation, which was invitation-only and ran no safety classifiers. Mythos 5.1 still has safeguards; they are calibrated to the access program rather than removed.

Difference 2: safeguard behavior

Fable 5.1 runs the complete Fable classifier set. When it declines a request, the API returns HTTP 200 with:

{
  "stop_reason": "refusal"
}

The response also includes a refusal category. Anthropic reports substantial reductions in false positives compared with Fable 5:

Biology classifiers trigger 85% less often on benign requests.
Cyber safeguards produce approximately 60% fewer interventions per Claude Code session.

Fable 5.1 can identify software vulnerabilities, but it will not develop exploits.

Mythos 5.1 is intended for work that Fable 5.1 may decline, including exploit-path discovery for approved defensive research and life-sciences work that triggers the bio classifier. It still runs safeguards, so your integration should handle refusals on both models:

if (response.stop_reason === "refusal") {
  const category = response.stop_details?.category;
  // Log, retry, or route to an approved fallback.
}

Anthropic’s launch post and system card also describe:

A real-time classifier for aggressive probing and sandbox-escape attempts
Stronger isolation for high-risk cyber workloads
New network-isolation requirements for external evaluators

These measures follow incidents in earlier evaluations where models reached real systems.

Difference 3: history-editing validation

Fable 5.1 thinking blocks are valid only in the exact conversation that produced them. On accounts created on or after August 31, 2026, editing any of the following invalidates subsequent thinking blocks:

An earlier conversation turn
The system prompt
The tools array

The API then returns a 400 error because the blocks are bound to a different conversation. The preserved thinking guide covers this behavior in detail.

Mythos 5.1 does not run this history-editing check. However, thinking blocks remain bound to their producing model:

Mythos 5.1 can read Mythos 5 thinking blocks.
Mythos 5 cannot read Mythos 5.1 thinking blocks.
Editing history still restarts the prompt cache.
History edits do not produce the “bound to a different conversation” 400 error.

Mythos 5.1 is also the only model besides Fable 5.1 that can read Fable 5.1 thinking blocks. You can move a conversation between those two models without losing its reasoning. Switching to Opus 5 causes the API to drop the blocks.

Difference 4: platforms and rate limits

Fable 5.1 is available on Claude Platform on AWS. Mythos 5.1 is not.

Mythos 5.1 is available through:

The Claude API
Amazon Bedrock as anthropic.claude-mythos-5-1
Google Cloud
Microsoft Foundry

On Bedrock, Mythos 5.1 is available in us-east-1 but is not publicly listed.

The models also use separate rate-limit pools:

Fable 5.1 shares the Fable 5.x pool with Fable 5.
Mythos 5.1 shares the Mythos pool with Mythos 5.

What the benchmark gap shows

Anthropic published one benchmark result for Mythos 5.1:

Mythos 5.1: 60.9% on Terminal-Bench 4.0
Fable 5.1: 55.8%

Because the underlying model is the same, the five-point difference is the clearest public measurement of safeguard overhead on an agentic coding task unrelated to cyber or biology. The classifiers presumably intervene on some benign steps during long terminal sessions.

In other words, Mythos 5.1 is a demonstrably stronger option for some workloads, even though it is not a different model. The complete benchmarks breakdown covers the rest of the results.

Anthropic’s science claims were all made for Mythos 5.1, not Fable 5.1:

Protein binders with affinities 10 times higher than the best competition submissions across three targets
A nearly 50% hit rate across 12 targets, compared with a typical 10–15%
A Venus elevation map with detail down to two or three kilometers

These are the workloads targeted by the Life Sciences Verification Program.

Which model should you use?

For most developers, the answer is Fable 5.1 because it is generally available.

Mythos 5.1 is relevant if your organization:

Performs defensive security research that triggers the cyber classifier
Conducts legitimate life-sciences research that triggers the bio classifier
Has been approved for Project Glasswing

If you qualify, migrating from Fable 5.1 should usually require only a model-ID change:

{
  "model": "claude-mythos-5-1"
}

The API behavior is otherwise the same, apart from history-editing validation.

Before applying for Mythos access, try these steps if Fable 5.1 is refusing legitimate defensive work:

Follow Anthropic’s phrasing guidance. Ask “are there any bugs?” instead of “does this compile?”
Include documentation for lesser-known programming languages.
Remove tools that inject base64 data into the context.
Configure a fallback:

{
  "fallbacks": "default"
}

This allows declined requests to fall through to Opus 5 or Opus 4.8. See the refusal handling guide for implementation details.

Test both model IDs

Because the models are otherwise identical, the easiest comparison is to send the same request body to both IDs in Apidog.

First, send a benign vulnerability-analysis prompt to:

claude-fable-5-1
claude-mythos-5-1, if your organization has access

Compare:

stop_reason
stop_details.category

Then send a two-request sequence that edits the system prompt between turns while including the thinking-binding-controls-2026-08-01 header.

Expected behavior:

Fable 5.1 reports prefix_binding_mismatch in input_transformations.
Mythos 5.1 does not run that history-editing check.

Download Apidog to run the comparison.

FAQ

Is Claude Mythos 5.1 more capable than Fable 5.1?

They use the same underlying model, so their capabilities are the same. The published Terminal-Bench 4.0 results—60.9% for Mythos 5.1 versus 55.8% for Fable 5.1—reflect safeguard interventions rather than different model weights.

How do I get access to Claude Mythos 5.1?

Apply through Project Glasswing’s Cyber Verification Program or Life Sciences Verification Program. Both programs were limited to US organizations at launch. You can also contact your Anthropic, AWS, or Google Cloud account team.

Does Mythos 5.1 cost more than Fable 5.1?

No. Both cost $10 and $50 per million tokens, with the same cache and batch rates.

Does Claude Mythos 5.1 refuse requests?

Yes. Unlike Mythos 5, which ran no classifiers, Mythos 5.1 uses safeguards calibrated to the access program. Handle stop_reason: "refusal" and stop_details.category for both models.

Can I switch a conversation between Fable 5.1 and Mythos 5.1?

Yes. They are the only two models that can read each other’s thinking blocks, so switching between them does not discard the reasoning.

Is Mythos 5.1 available on Amazon Bedrock?

Yes. It is available as anthropic.claude-mythos-5-1 in us-east-1, although it is not publicly listed. It is not available on Claude Platform on AWS.

Prompting Claude Fable 5.1: Every Behavior Shift and the Line That Fixes It

Hassann — Wed, 02 Sep 2026 03:00:20 +0000

Claude Fable 5.1 Prompting: What Changed and How to Adapt

Anthropic says existing Fable 5 prompts should perform well on Claude Fable 5.1, but the behavior around those answers has changed: tool-call batching, progress updates, prose density, chat formatting, file-editing style, and autonomous task completion all behave differently. This guide maps each shift to a practical fix from the official prompting guide. For the model overview, see what Claude Fable 5.1 is.

Try Apidog today

Tune effort before changing prompts

Effort is the main control for intelligence, latency, and cost on Fable 5.1. Start with the default high setting, then evaluate low, medium, xhigh, and max against your own test suite. Repeat the sweep even if you already tested Fable 5; effort levels do not represent the same amount of thinking across models.

Anthropic recommends testing these hypotheses:

Medium may approximate Fable 5 quality at lower cost.
Low can be competitive with Opus and Sonnet on cost per task while scoring higher in some evaluations.
Improvements over Fable 5 are largest at xhigh and max.

You can also change effort mid-conversation without resetting the cache by sending an empty-content system message with output_config and the mid-conversation-output-config-2026-07-01 beta header. See the Effort documentation and API walkthrough.

Put per-turn instructions in the right place

Fable 5.1 thinking blocks are valid only in the exact conversation that produced them. Editing an earlier turn—for example, injecting a reminder and deleting it on the next request—restarts the prompt cache and, for accounts created on or after August 31, 2026, invalidates every later thinking block.

Use one of these patterns for turn-scoped instructions.

With the mid-conversation-system-clear-at-2026-08-21 beta, append a system message after the tool result:

{
  "role": "system",
  "clear_at": "next_user_message",
  "content": "Your turn-scoped instruction goes here."
}

Keep earlier copies in the conversation array. After the next user message, the API clears the older copies, so the model sees only the newest instruction and cleared copies consume no tokens.

Without the beta, place the instruction in a text block after the tool_result blocks in the same user message. Again, keep every earlier copy. Never delete or rewrite text that has already been sent.

See the preserved thinking documentation and the turn-scoped system message guide.

Use the system prompt or first user turn for session-level instructions. Anthropic reports that style instructions hold more reliably in the first user turn than in the system prompt.

Restore parallel tool calls in agent loops

When a request explicitly names several independent items, Fable 5.1 usually calls the tools in parallel. In coding and computer-use loops, however, it may issue one implied read per turn when Fable 5 batched several calls.

Measure before changing the [REDACTED PROMPT] assistant turns containing more than one tool call.

Add the instruction only if parallelism has declined.
Measure round trips, token usage, and wall-clock time as well.

Append this instruction after each tool-result message as a turn-scoped system message:

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

Keep the word “privately.” Without it, the model may answer the reminder instead of continuing the task. A sentence near the end of the current request generally has more effect than the same sentence in the system prompt.

Make progress updates visible

Fable 5.1 often produces fewer user-facing updates during long tool-calling turns than Fable 5, especially at higher effort. Users may see no updates for several minutes or receive a final message that mentions only the last step.

Apply these fixes in order:

Confirm that progress updates are being returned. Between-tool notes arrive as thinking blocks and are displayed as "omitted" by default.
Enable display: "updates" with the thinking-display-updates-2026-08-18 beta header.
Render each non-empty thinking block as a status line.
Remove old instructions such as “hold all findings for the final response.”
If needed, add this to the system [REDACTED PROMPT]

If your product hides tool output, tell the model explicitly:

Only you see that command’s output. If the user needs to read any of it, put it in your reply.

Otherwise, it may run extra commands to “show” output the user cannot actually see.

Prevent premature turn endings

On complex asynchronous tasks, Fable 5.1 may describe the next action instead of taking it, or ask permission for work already covered by the request. This forces the user to reply “continue” and limits long-horizon execution.

Add this system-prompt block:

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to...?' or 'Shall I...?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.

Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done, do that work now with tool calls. End your turn only when the task is complete or you are blocked on input only the user can provide.

Pair it with a scope rule:

Treat the user’s request as the complete scope.
Do not narrow, widen, or replace it.
Finish every unblocked part and report anything omitted.
Treat unrequested observations as suggestions, not changes.
Add a separate sentence listing the confirmations that still require user input.

Unlike the Opus 5 prompting advice, keep instructions that tell Fable 5.1 to verify its work.

Prevent unrequested fixes and extra tests

Open-ended feature requests can produce nearby bug fixes, performance changes, extended behavior, or more test files than necessary.

Use this instruction:

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files. This is about extras only: implement every behavior the task asks for, completely.

This reduces scope creep without discouraging complete implementation of the requested behavior.

Prefer targeted file edits

Fable 5.1 is more likely than Fable 5 to rewrite an entire file for a small change. The result may be correct, but it costs more output tokens and creates noisier diffs.

Add this to the system prompt or first user message:

The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.

Reduce dense, mannered prose

Fable 5.1 generally writes better prose, but it can produce longer sentences and fewer paragraph breaks. Anthropic defines “mannered prose” as writing that uses metaphor and flourish to display the writer instead of conveying the idea directly.

Use a direct instruction:

Say what you mean and use the literal phrase when one is available. Please remove all mannered prose.

Restore useful formatting

Older models often overused bullets and bold text, so many prompts contain anti-formatting rules. Fable 5.1 tends to use less formatting, which means those rules can now suppress structure the reader needs.

Replace blanket anti-formatting instructions with a conditional rule:

Use lists when asked or when the content is multifaceted enough that they aid clarity. Honor explicit requests for minimal formatting. Use plain prose in conversational or emotional exchanges.

Mark quotations in summaries

When summarizing documents, Fable 5.1 is more likely than Fable 5 to reproduce source passages without clearly marking them as quotations.

Add one complete example to the system prompt containing:

The user’s request.
A correct response that summarizes each source in the assistant’s own indirect speech.
At most one short, clearly marked quotation.
A one-sentence explanation of why the response is correct.

Replace any tool-call placeholders in Anthropic’s example with your own tool name.

Make low-effort search behavior explicit

At low effort, Fable 5.1 may search and retrieve less often than Fable 5, particularly for named products and models it recognizes but has stale knowledge of.

Use either of these fixes:

Raise effort for affected turns with per-message effort.
Add this guidance to the system [REDACTED PROMPT] state. Search before answering, and include the name exactly as the user wrote it in at least one query.

Control long deliverables at xhigh and max

At xhigh and especially max, Fable 5.1 may draft a long deliverable in its thinking and then reproduce it in the final response. This doubles latency and output tokens.

Prefer high unless evaluations show a measurable gain at higher effort. If you use xhigh or max:

Set max_tokens high enough for both thinking and the final response.
Tell the user message that all content produced in one reply, including reasoning, counts toward one limit of approximately max_tokens.
Explain that composing the deliverable in reasoning and then repeating it in the reply doubles the turn without improving the result.
Keep earlier copies of that instruction in later requests.

Reduce false refusals on benign coding tasks

Fable 5.1’s classifiers produce fewer false positives than Fable 5 at launch, and finding vulnerabilities in source code is permitted. False positives can still occur.

Try these changes:

Ask, “Are there any bugs in this program?” instead of “Does this program compile without errors?”
Provide documentation for lesser-known languages.
Remove tools that inject base64-encoded data into context.
Keep fallback behavior configured regardless of the expected result.

See the refusal handling guide.

Preserve details during client-side compaction

Fable 5.1 responds well to explicit compaction requirements. Server-side compaction already preserves these details. For client-side compaction, instruct the model to write inside <summary> tags and retain the following in order:

Difficulties and how they were resolved.
Approaches that were proposed or rejected, and why.
Everything requested or decided, stated exactly.
The current state.
Open items.
Hard-to-reconstruct details such as names, numbers, and links.

End with:

Do not call any tools while writing this summary; respond with text only.

This is important when the summarization request still includes the conversation’s tools.

Use architecture for subagents and vision

Two improvements are architectural rather than prompt-based.

For coding tasks:

Let the lead agent continue while subagents work.
Have the subagent-starting tool return immediately.
Deliver each subagent result in a later user message.
Give the lead agent a separate tool it can call when it wants to wait.

For dense charts and nested tables:

Provide a crop tool that returns a selected region at a larger size, or
Provide a container with basic image libraries.

At low effort, the model may skip cropping, so inspect tool-call logs to confirm it used the capability when needed.

Test prompt changes in Apidog

Treat every fix as a before-and-after experiment:

Save the first three turns of your agent loop as a request sequence in Apidog.
Parameterize the system prompt.
Run the sequence with and without one snippet at the same effort.
Compare task success, latency, and token usage.

Useful assertions include:

Tool batching: Count tool_use blocks per assistant turn.
Targeted edits and prose density: Compare usage.output_tokens.
Autonomy: Assert that the final paragraph does not start with “Next, I”.
Progress: Verify that non-empty update blocks are displayed.

Download Apidog to build the test sequence. The Claude Code guide shows which instructions belong in CLAUDE.md.

FAQ

Do my Fable 5 prompts work on Fable 5.1?

Anthropic says they should perform well without changes. The main differences are behavioral: fewer batched tool calls in some loops, fewer progress updates, denser prose, less chat formatting, whole-file rewrites, and scope creep on open-ended tasks.

What effort level should I use?

Start at high and run an evaluation sweep. Anthropic reports that medium can approximate Fable 5 at lower cost, while low can be competitive with Opus and Sonnet on cost per task.

Where should I put a per-turn instruction?

Use a turn-scoped system message with:

"clear_at": "next_user_message"

Place it after the tool results and keep earlier copies in the conversation. Editing earlier turns invalidates later thinking blocks and restarts the cache.

Should I remove “verify your work” instructions?

No. That advice was specific to Opus 5’s over-verification behavior. Keep verification instructions for Fable 5.1.

How do I stop whole-file rewrites?

Add this sentence to the system prompt or first user message:

Minimize tokens used to edit files and surgically edit rather than rewrite when doing so does not affect the result.

Claude Fable 5.1 Benchmarks: What the Numbers Actually Say

Hassann — Wed, 02 Sep 2026 02:54:45 +0000

Claude Fable 5.1 Benchmarks: The Numbers That Matter

Anthropic launched Claude Fable 5.1 on September 1, 2026. Across nine published benchmarks, its largest gain is Terminal-Bench-Science: 52.6% versus 24.7% for Fable 5. Its smallest lead is CursorBench, where it beats Opus 5 by only 3.4 points despite costing twice as much. This guide collects the published results, explains what they measure, and shows how to validate them against your own workload.

Try Apidog today

The primary source is Anthropic’s launch post. For background, see what Claude Fable 5.1 is.

The full benchmark table

Benchmark	What it measures	Fable 5.1	Fable 5	Opus 5	GPT-5.6 Sol
Terminal-Bench-Science 0.1	Agentic scientific research in a terminal	52.6%	24.7%	29.0%	22.4%
Terminal-Bench 4.0	Agentic coding in a terminal	55.8%	42.0%	52.3%	37.3%
GDPval-AA v2	Economically valuable knowledge work (Elo)	1853	1723	1824	1711
OSWorld 2.0 (partial credit)	Computer use on real desktop tasks	77.9%	72.9%	75.4%	Not reported
OSWorld 2.0 (strict)	Same, counting only full task completion	41.7%	36.1%	39.6%	Not reported
Humanity’s Last Exam (no tools)	Expert-level reasoning questions	60.9%	57.8%	56.6%	Not reported
Humanity’s Last Exam (with tools)	Same, with search and code	65.0%	63.8%	63.6%	Not reported
AutomationBench	End-to-end business workflows	31.4%	17.1%	26.9%	19.6%
CursorBench 3.2.0	IDE-style coding tasks	73.4%	70.5%	70.0%	67.2%

Anthropic also published one Mythos 5.1 result: 60.9% on Terminal-Bench 4.0.

VentureBeat reported an additional Browserbase result: Fable 5.1 scored 82%, compared with 74% for Opus 5 and 57% for Fable 5 on the hardest browser-agent tasks. Because this figure comes from press coverage rather than Anthropic’s launch post, treat it as less authoritative.

The large gaps

Terminal-Bench-Science 0.1

Fable 5.1: 52.6% · Fable 5: 24.7% · Opus 5: 29.0%

This is the standout result. Fable 5.1 more than doubles its predecessor and nearly doubles Opus 5 on a benchmark that gives the model a terminal, scientific tools, and multistep research tasks.

It is the clearest evidence that Anthropic’s focus on “long-horizon problem-solving” produced a measurable improvement. However, this is a version 0.1 benchmark, so the task set and scores may change as it matures.

AutomationBench

Fable 5.1: 31.4% · Fable 5: 17.1% · Opus 5: 26.9%

AutomationBench evaluates end-to-end business workflows across applications. Absolute scores remain low for every model, but Fable 5.1 nearly doubles Fable 5 and leads Opus 5 by 4.5 points.

If your product automates multi-application business processes, this row is especially relevant.

Terminal-Bench 4.0

Fable 5.1: 55.8% · Fable 5: 42.0% · Opus 5: 52.3%

Fable 5.1 gains 13.8 points over Fable 5 on agentic coding and leads Opus 5 by 3.5 points.

Opus 5 had surpassed Fable 5 on this benchmark in July. Fable 5.1 restores the Fable tier’s advantage, although the lead is narrower than it was in June. See the Opus 5 benchmarks breakdown for the July results.

GDPval-AA v2

Fable 5.1: 1853 · Fable 5: 1723 · Opus 5: 1824

Fable 5.1 gains 130 Elo over Fable 5 on knowledge-work tasks. This is the benchmark Anthropic cites for its document, spreadsheet, and presentation claims.

Against Opus 5, the difference is only 29 Elo—a relatively small gap.

The small gaps

CursorBench 3.2.0

Fable 5.1: 73.4% · Fable 5: 70.5% · Opus 5: 70.0%

CursorBench measures IDE-style coding tasks. Fable 5.1 leads both models by about three points, making this its narrowest advantage.

This benchmark may matter most to developers. If your workload is primarily “help me in my editor,” these results alone do not justify paying twice as much.

OSWorld 2.0

Partial credit: Fable 5.1 77.9% vs Opus 5 75.4%

Strict completion: Fable 5.1 41.7% vs Opus 5 39.6%

Fable 5.1 leads Opus 5 by roughly two points under both scoring methods and leads Fable 5 by five points.

The strict score is the more sobering metric: fewer than half of tasks were fully completed by any model. Computer use remains one of the frontier’s weakest capabilities.

Humanity’s Last Exam

Without tools: Fable 5.1 60.9% vs Opus 5 56.6%

With tools: Fable 5.1 65.0% vs Opus 5 63.6%

Without tools, Fable 5.1 leads Opus 5 by 4.3 points—the largest of the smaller gaps. With search and code execution, the advantage falls to 1.4 points.

The no-tools score better represents raw reasoning. The with-tools score is closer to typical production usage.

Fable 5.1 vs GPT-5.6 Sol

Anthropic published GPT-5.6 Sol results for five rows. Fable 5.1 leads on each:

Terminal-Bench-Science: 52.6% vs 22.4%, a 30.2-point lead
Terminal-Bench 4.0: 55.8% vs 37.3%, an 18.5-point lead
AutomationBench: 31.4% vs 19.6%, an 11.8-point lead
CursorBench: 73.4% vs 67.2%, a 6.2-point lead
GDPval-AA v2: 1853 vs 1711

Two caveats are important:

Anthropic ran these competitor comparisons itself.
GPT-5.6 Sol results are missing from five of the nine rows, and Anthropic did not explain why.

The earlier GPT-5.6 Sol vs Fable 5 comparison covered the previous matchup. On the published numbers, Fable 5.1 widens every gap reported for Fable 5.

What launch coverage skipped

Every result is vendor-run

Anthropic ran all benchmark tests, including the GPT-5.6 Sol comparisons. No independent lab had reproduced the results at launch.

Anthropic’s benchmark history has generally held up, but small gaps—especially on CursorBench and OSWorld—could change with a different harness, prompt set, or scoring method.

Mythos 5.1 is the higher-performing sibling

Anthropic’s system card and launch post describe Fable 5.1 and Mythos 5.1 as “the same model but with different levels of safeguards.”

On Terminal-Bench 4.0:

Mythos 5.1: 60.9%
Fable 5.1: 55.8%

The five-point difference shows the capability cost of the safeguards on agentic coding. It also means Anthropic’s most capable widely released model has a more capable sibling. The Mythos 5.1 vs Fable 5.1 comparison covers access differences.

Anthropic did not state the effort level

Anthropic’s effort documentation says Fable 5.1’s gains are largest at xhigh and max.

The launch post does not identify the effort level used for each result or state which settings were used for the comparison models. Because effort is a major quality and cost lever, this omission makes exact reproduction difficult.

Multilingual performance is flat

Anthropic says multilingual performance is on par with Fable 5 rather than improved. If your workload is not in English, the benchmark table may overstate the practical gain.

Safeguard metrics measure a different outcome

Anthropic reports:

85% fewer biology false positives on benign requests
About 60% fewer cyber interventions per Claude Code session versus Fable 5

These figures come from Anthropic’s own traffic and are not externally reproducible. For users who frequently encounter refusals, however, they may matter more than capability scores.

What to test yourself

A launch table tells you where to investigate. Your own evals determine whether migration is worthwhile.

1. Run a long-horizon agent task

Use a representative task from your product and compare:

Fable 5.1 at high effort
Opus 5 at xhigh
Fable 5 at high effort

This approximates Terminal-Bench-Science and AutomationBench. It will show whether the higher price pays off for your workflow.

2. Compare your hardest coding prompts

Run your ten most difficult coding prompts at the same effort level on Fable 5.1 and Opus 5. If the results are tied, you have reproduced the CursorBench story—and Opus 5 may be the better value.

3. Sweep effort levels

Run one routine task on Fable 5.1 at every setting from low through max. Anthropic claims that:

Medium effort matches Fable 5
Low effort can compete with Opus 5 on cost per task
Gains are largest at xhigh and max

Measure both quality and cost rather than relying on a single score.

4. Count benign refusals

Run benign security and life-sciences prompts on Fable 5 and Fable 5.1. Track refusal rates to test Anthropic’s 60% and 85% claims.

You can build all four evals as requests in Apidog. Define model and effort as environment variables, then add assertions for:

stop_reason
An expected string in the response
Request success or failure
Latency and token usage, if available

Run the collection once per model and compare the resulting history. This gives you a reproducible evaluation table without building new infrastructure. Download Apidog to get started; the Claude Fable 5.1 API walkthrough includes the request shapes.

How the benchmarks map to a decision

Long-horizon agents, research, and automation: The gaps are large and consistent. Fable 5.1 is the strongest choice in Anthropic’s table. The pricing breakdown explains how cheaper cache reads narrow the cost difference on these workloads.
IDE coding, knowledge Q&A, and tool-assisted reasoning: The advantage over Opus 5 is only one to four points. Stay on Opus 5 unless Fable 5.1 wins your higher-effort evals. See the Fable 5.1 vs Opus 5 comparison.
Migration from Fable 5: Every published capability row improves, while the price does not. Anthropic also reports fewer false positives. The Fable 5.1 vs Fable 5 comparison covers migration considerations.

FAQ

What is Claude Fable 5.1’s best benchmark result?

Terminal-Bench-Science 0.1 at 52.6%. That is more than double Fable 5’s 24.7% and ahead of Opus 5’s 29.0% and GPT-5.6 Sol’s 22.4%. All figures come from Anthropic.

How does Fable 5.1 compare with Opus 5 on coding?

Fable 5.1 scores 55.8% vs 52.3% on Terminal-Bench 4.0 and 73.4% vs 70.0% on CursorBench 3.2.0. The advantage is real but narrow—roughly three points.

Is Fable 5.1 better than GPT-5.6 Sol?

On the five benchmarks where Anthropic published both results, yes. Fable 5.1 leads by 6 to 30 points. Anthropic ran the GPT-5.6 Sol tests itself, and four other benchmark rows have no GPT-5.6 Sol result.

Are the Fable 5.1 benchmarks independently verified?

Not at launch. Every number is Anthropic-run. Treat the results as claims to validate against your own workload.

How does Mythos 5.1 score?

Anthropic published one result: 60.9% on Terminal-Bench 4.0, five points above Fable 5.1’s 55.8%. Anthropic describes both as the same model with different safeguards.

Which effort level produced these scores?

Anthropic did not say. Its guidance is that Fable 5.1 performs best at xhigh and max, so reproduce the tests across effort levels before drawing conclusions.

Claude Fable 5.1 vs Opus 5: When Is Twice the Price Worth It?

Hassann — Wed, 02 Sep 2026 02:50:36 +0000

Claude Fable 5.1 vs. Claude Opus 5: Which Model Should You Use?

Claude Fable 5.1 costs $10 per million input tokens and $50 per million output tokens. Claude Opus 5 costs $5 and $25. Anthropic recommends starting with Opus 5 and switching to Fable 5.1 only “when your evals on Claude Opus 5 at higher effort still fall short.” This comparison applies that rule to benchmarks, pricing, caching, and real-world integration constraints.

Try Apidog today

The sources are Anthropic’s launch post, the Fable 5.1 model page, and the pricing page. For each model’s overview, see what Claude Fable 5.1 is and what Claude Opus 5 is.

Side by side

	Claude Fable 5.1	Claude Opus 5
Model ID	`claude-fable-5-1`	`claude-opus-5`
Released	September 1, 2026	July 24, 2026
Positioning	Demanding reasoning and long-horizon agentic work	Complex agentic coding and enterprise work; the recommended default
Input / output	$10 / $50	$5 / $25
Cache read	$0.25	$0.50
Cache write (5m / 1h)	$12.50 / $20	$6.25 / $10
Batch	$5 / $25	$2.50 / $12.50
Fast mode	No	Yes ($10 / $50)
Priority Tier	No	No
Context / max output	1M / 128K	1M / 128K (300K on Batch with beta)
Knowledge cutoff	June 2026	May 2026
Comparative latency	Slower	Moderate
Thinking	Always on; `disabled` returns 400	On by default; `disabled` allowed at `high` or below
Forced `tool_choice`	400	Accepted
Safety classifiers	cyber, bio, frontier_llm, reasoning_extraction, general_harms	cyber only
Zero data retention	Not available unless authorized	Available
Per-message effort (beta)	Yes	Yes
History-editing check	Yes	No

What the benchmarks show

All results below come from Anthropic, were run by Anthropic, and have not yet been independently reproduced.

Benchmark	Fable 5.1	Opus 5	Gap
Terminal-Bench-Science 0.1	52.6%	29.0%	+23.6
AutomationBench	31.4%	26.9%	+4.5
Humanity’s Last Exam (no tools)	60.9%	56.6%	+4.3
Terminal-Bench 4.0	55.8%	52.3%	+3.5
CursorBench 3.2.0	73.4%	70.0%	+3.4
OSWorld 2.0 (partial)	77.9%	75.4%	+2.5
OSWorld 2.0 (strict)	41.7%	39.6%	+2.1
Humanity’s Last Exam (with tools)	65.0%	63.6%	+1.4
GDPval-AA v2	1853	1824	+29 Elo

The results tell two different stories:

On Terminal-Bench-Science, Fable 5.1 nearly doubles Opus 5. This is a long-horizon, tool-heavy research benchmark where models run terminal experiments over extended periods.
On the other benchmarks, the advantage ranges from one to five points. A five-point lead on AutomationBench is meaningful, while a 1.4-point lead on Humanity’s Last Exam with tools—or 29 Elo on GDPval—may be smaller than the effect of prompt design and effort settings.

Opus 5 launched in July at 52.3% on Terminal-Bench 4.0, ahead of Fable 5’s 42.0%. Fable 5.1 retook the lead at 55.8%, but the current difference is 3.5 points rather than 13.8. The Fable tier’s advantage in agentic coding is real, but narrower than it was in June. The Opus 5 vs. Fable 5 comparison covers the earlier results.

The pricing math is not simply 2×

Without caching, Fable 5.1 costs exactly twice as much as Opus 5 on every pricing line. Cache reads reverse that relationship: Fable 5.1 costs $0.25, compared with $0.50 for Opus 5.

The effective multiplier therefore depends on how much of each request is a cached prefix.

Consider an agentic turn with 150,000 cached tokens, 1,000 uncached input tokens, and 800 output tokens:

Opus 5: 5(0.001) + 0.5(0.15) + 25(0.0008) = $0.005 + $0.075 + $0.02 = $0.10
Fable 5.1: 10(0.001) + 0.25(0.15) + 50(0.0008) = $0.01 + $0.0375 + $0.04 = $0.0875

On this turn, Fable 5.1 is cheaper.

Now consider a code review with 30,000 uncached input tokens and 4,000 output tokens:

Opus 5: $0.15 + $0.10 = $0.25
Fable 5.1: $0.30 + $0.20 = $0.50

Here, Fable 5.1 costs exactly twice as much.

Fable 5.1’s per-turn cost falls below Opus 5’s when cached input tokens exceed roughly 20 times the sum of uncached input tokens and five times output tokens. This is common in prefix-heavy agent loops but impossible for output-heavy workloads. Cache writes also cost twice as much on Fable 5.1, so frequently resetting a cache can eliminate the advantage.

See the Fable 5.1 pricing breakdown and the Opus 5 pricing breakdown for the complete tables.

Where Opus 5 wins

Workloads that can run with thinking disabled. Opus 5 accepts thinking: {"type": "disabled"} at high effort or below. Fable 5.1 does not. For classification, extraction, and short-answer routes, Opus 5 with thinking disabled—or at low effort—is cheaper and faster.

Fast mode. Opus 5 offers a research-preview fast mode with up to 2.5× the output speed for $10 per million input tokens and $50 per million output tokens. Fable 5.1 has no equivalent.

Latency. Anthropic lists Fable 5.1 as “slower” and Opus 5 as “moderate.” A difficult Fable 5.1 request at high effort can run for several minutes.

Zero data retention. Opus 5 is available under ZDR. Fable 5.1 is a Covered Model and returns a 400 unless Anthropic expressly authorizes ZDR access.

Fewer refusals. Opus 5 uses cybersecurity-only classifiers. Fable 5.1 also applies bio, frontier LLM development, reasoning extraction, and general-harms classifiers. A benign life-sciences or machine-learning workload may pass on Opus 5 but trigger Fable 5.1. When that happens, Opus 5 is the fallback target.

Forced tool use. Opus 5 accepts tool_choice values any and tool; Fable 5.1 returns a 400. Integrations that depend on forced calls may need changes before switching.

History editing. Opus 5 permits edits to earlier turns. Fable 5.1 invalidates later thinking blocks when earlier history changes. Client-side compaction and per-turn reminder injection therefore require an audit before migration.

Where Fable 5.1 wins

Long-horizon research and terminal agents. The 52.6% versus 29.0% result on Terminal-Bench-Science is the largest gap in Anthropic’s table. This is the workload Fable 5.1 was designed for: running experiments, conducting multistep web research, and operating for hours.

Business workflow automation. Fable 5.1 scores 31.4% versus Opus 5’s 26.9% on AutomationBench, which models end-to-end tasks across applications.

Cached-prefix-heavy agents. The $0.25 cache-read price can make Fable 5.1 cheaper per turn when most input tokens come from a reusable prefix.

Knowledge cutoff. Fable 5.1’s June 2026 cutoff is one month newer than Opus 5’s May 2026 cutoff.

Dense-document vision. Anthropic identifies improved reading of charts, filings, and tables embedded in PDFs—especially with crop-and-zoom tools—as a Fable 5.1 strength. Opus 5 has not been compared on a published vision benchmark, so test this claim on your own documents.

Tasks Opus 5 fails at xhigh. This is Anthropic’s recommendation: if a task fails your Opus 5 eval at xhigh, test Fable 5.1 at high before changing anything else.

Effort changes the comparison

Both models provide five effort levels. Anthropic specifically claims that Fable 5.1 at low effort is often competitive with Claude Opus and Claude Sonnet models on cost per task while scoring higher.

That makes the practical comparison more nuanced than Opus 5 at high versus Fable 5.1 at high. For routine work, compare Opus 5 at high with Fable 5.1 at low or medium. Lower effort usually produces fewer output tokens, offsetting Fable 5.1’s higher per-token price.

The reverse is also true: Fable 5.1’s gains over Fable 5 are largest at xhigh and max, where latency and cost are highest. Sweep both models across all relevant effort levels on your own evals before relying on the launch tables. The Opus 5 effort guide covers all five levels; the semantics are the same for Fable 5.1.

A practical decision framework

Start with Opus 5 at high. It is Anthropic’s default recommendation, costs half as much, uses fewer classifiers, and supports ZDR.
Raise failing tasks to xhigh. This is cheaper than switching models for every request.
Move only the remaining failures to Fable 5.1 at high. Use a per-route policy rather than switching globally.
Check the cache profile. If the migrated route uses a large reusable prefix, Fable 5.1 may cost less per turn.
Audit your harness before migrating. Forced tool_choice and history edits both break on Fable 5.1. Use the migration guide as a checklist.

Run the comparison in Apidog

Create one collection containing your production prompts, with model configured as an environment variable. Run the collection with:

claude-opus-5 at high
claude-opus-5 at xhigh
claude-fable-5-1 at high
claude-fable-5-1 at low

For every run, record the response, usage.output_tokens, and usage.cache_read_input_tokens on a repeat request. Apply each model’s rates in a post-response script to calculate cost per task, model, and effort level in one table.

Apidog keeps every run in history, so you can repeat the comparison when the next model launches. Download Apidog to get started.

FAQ

Is Claude Fable 5.1 better than Opus 5?

On every benchmark Anthropic published, yes, with margins ranging from 1.4 points to 23.6 points. The largest gap is on Terminal-Bench-Science; most other results are under five points. These are vendor-run results.

Is Fable 5.1 worth twice the price of Opus 5?

Often, for long-horizon research, terminal agents, business automation, and prefix-heavy loops where cache reads can reduce the per-turn cost. Usually not for output-heavy, latency-sensitive, or classification workloads. Anthropic’s rule is to switch only after Opus 5 at higher effort fails your evals.

Which is faster, Fable 5.1 or Opus 5?

Opus 5. Anthropic lists its latency as “moderate” versus “slower” for Fable 5.1. Opus 5 also offers a fast mode with up to 2.5× the output speed; Fable 5.1 does not.

Does Opus 5 have the same safety classifiers as Fable 5.1?

No. Opus 5 uses cyber-only classifiers. Fable 5.1 also applies bio, frontier LLM, reasoning extraction, and general-harms classifiers. When Fable 5.1 refuses a request, Opus 5 is one of the two permitted fallback targets.

Can I use Fable 5.1 under zero data retention like Opus 5?

No. Fable 5.1 requires 30-day retention and is a Covered Model. Opus 5 is available under ZDR.

Can a conversation move between Opus 5 and Fable 5.1?

Upward, yes: Fable 5.1 reads Opus 5’s thinking blocks. Downward, the API removes Fable 5.1’s thinking blocks before Opus 5 receives them. Those blocks are unbilled, and Opus 5 replans the turn.

Claude Fable 5.1 vs Fable 5: What Changed and Should You Upgrade?

Hassann — Wed, 02 Sep 2026 02:49:02 +0000

Claude Fable 5.1 vs. Fable 5: Should You Migrate?

Claude Fable 5.1 replaced Fable 5 on September 1, 2026, at the same $10 and $50 per million-token prices. Cache reads dropped from $1 to $0.25 per million tokens, and every benchmark Anthropic published improved. Fable 5 remains available, with Anthropic’s Fable 5 model page committing to support through at least June 9, 2027. The practical question is whether Fable 5.1’s gains justify the migration work—and whether its breaking changes affect your application.

Try Apidog today

This guide covers what stayed the same, what improved, what changed, and how to choose by workload. Sources include Anthropic’s launch post and What’s new in Claude Fable 5.1. For the full specification, see what Claude Fable 5.1 is.

Fable 5.1 vs. Fable 5

Specification	Claude Fable 5.1	Claude Fable 5
Model ID	`claude-fable-5-1`	`claude-fable-5`
Released	September 1, 2026	June 9, 2026 (suspended June 12, back July 1)
Retirement	Not sooner than September 1, 2027	Not sooner than June 9, 2027
Context / maximum output	1M / 128K	1M / 128K
Knowledge cutoff	June 2026	January 2026
Input / output price	$10 / $50	$10 / $50
Cache read	$0.25 per million	$1.00 per million
Cache writes	$12.50 (5m), $20 (1h)	Same
Batch	$5 / $25	Same
Tokenizer	Same (Opus 4.7 generation)	Same
Thinking	Adaptive, always on	Adaptive, always on
Forced `tool_choice`	400	Accepted
Thinking blocks readable by older models	No	Yes
History-editing check	Yes, enforced for accounts created on or after 2026-08-31	No
Priority Tier	Not supported	Supported
Per-message effort	Yes (beta)	No
Turn-scoped system messages	Yes (beta)	No
`thinking.display: "updates"`	Yes (beta)	Yes (beta)
Content provenance	Text watermark + C2PA on media	Text watermark
Data retention	30-day required, Covered Model	Same
Refusal categories	Same five	Same five

What stayed the same

The migration is relatively small for most applications. Both models retain:

The same API surface
A 1M-token context window and 128K maximum output
The same input, output, cache-write, and batch prices
The same tokenizer
A 512-token cache minimum
Always-on adaptive thinking
"omitted" as the default for thinking.display
No prefilling
No sampling parameters
Mid-conversation system messages
The same refusal categories and fallback mechanics

Anthropic expects existing Fable 5 prompts to work well on Fable 5.1 without modification.

Existing guidance also remains relevant, including the rate limits guide, safeguards explainer, and cloud availability guide. The models also share one rate-limit pool.

What improved

Benchmark performance

Every benchmark row published by Anthropic improved:

Benchmark	Fable 5.1	Fable 5	Delta
Terminal-Bench-Science 0.1	52.6%	24.7%	+27.9
AutomationBench	31.4%	17.1%	+14.3
Terminal-Bench 4.0	55.8%	42.0%	+13.8
GDPval-AA v2	1853	1723	+130 Elo
OSWorld 2.0 (strict)	41.7%	36.1%	+5.6
OSWorld 2.0 (partial)	77.9%	72.9%	+5.0
Humanity’s Last Exam (no tools)	60.9%	57.8%	+3.1
CursorBench 3.2.0	73.4%	70.5%	+2.9
Humanity’s Last Exam (with tools)	65.0%	63.8%	+1.2

The largest gains are on long-horizon agentic tasks:

Scientific research in a terminal
Business workflow automation
Agentic coding

Knowledge tasks and IDE-style coding show smaller improvements. These are vendor-run results and have not yet been independently reproduced. See the benchmarks breakdown for a row-by-row analysis.

Cache reads cost 75% less

According to the pricing page, cache reads are the most immediate cost improvement for many Fable 5 users.

A 150,000-token prefix reread on every turn costs:

Fable 5: $0.15 per turn
Fable 5.1: $0.0375 per turn

Anthropic estimates that typical workloads become 25% cheaper, with savings reaching 45% for agentic workloads. The pricing breakdown includes three worked examples.

Fewer safeguard false positives

Anthropic reports that Fable 5.1’s biology classifiers trigger 85% less often on benign elementary biology and medical requests than Fable 5’s did at launch.

Its cyber safeguards also produce approximately 60% fewer interventions per Claude Code session. Fable 5.1 can identify vulnerabilities in source code that Fable 5 previously declined to analyze. Exploit development remains refused.

More useful effort levels

Anthropic says medium effort on Fable 5.1 roughly matches Fable 5 at lower cost. The biggest quality gains appear at xhigh and max.

A practical migration strategy is to:

Move a Fable 5 workload from high to Fable 5.1 medium for similar quality and fewer output tokens.
Keep high when you want higher quality than Fable 5 provided.
Re-run your own evaluation suite rather than assuming effort levels map exactly between models.

Newer knowledge

Fable 5.1 has a June 2026 knowledge cutoff, compared with January 2026 for Fable 5. That adds five months of framework releases, API changes, and model launches.

New harness features

Fable 5.1 adds:

Per-message effort changes without resetting the cache
Turn-scoped system messages for per-turn reminders
Readable progress updates between tool calls

Fable 5 supports the last feature through thinking.display: "updates"; the first two are new.

What changed

Forced tool use now returns an error

On Fable 5.1, tool_choice: "any" and tool_choice: "tool" return HTTP 400 errors.

If you used forced tools to guarantee JSON, migrate to either:

{
  "tool_choice": {
    "type": "auto"
  },
  "output_config": {
    "format": {
      "type": "json_schema",
      "strict": true
    }
  }
}

Or use structured outputs directly.

If your application requires a tool call on a particular turn, add a mid-conversation system message that explicitly requires it. Audit every forced-tool call site before switching models.

Thinking blocks are one-way

Fable 5.1 can read thinking blocks created by Fable 5, so conversations can move upward without losing reasoning.

The reverse is not true. Fable 5 cannot read Fable 5.1 thinking blocks. During a gradual migration, if a router sends a conversation back to Fable 5:

The API drops the incompatible thinking blocks
The dropped blocks are not billed
Fable 5 replans the turn

Account for this behavior in routing and cost estimates.

History editing is validated

Fable 5.1 thinking blocks are valid only in the exact conversation that produced them. On accounts created on or after August 31, 2026, the next request fails if your application:

Edits an earlier turn
Rebuilds the system prompt
Changes the tools array
Injects or removes per-turn reminders
Refreshes dates or other dynamic system-prompt content
Compacts the client-side history while replaying recent turns verbatim

Run the three-step history check before migrating. Fix every prefix_binding_mismatch error. The preserved thinking guide provides a complete checklist.

Priority Tier is unavailable

Fable 5.1 does not support Priority Tier. If your enterprise workload depends on guaranteed capacity, remain on Fable 5 until Anthropic adds support.

Agent loops behave differently

At some effort levels, Fable 5.1 may:

Issue one tool call per turn instead of batching several
Write fewer progress updates
Answer from memory more often instead of searching at low effort

Each behavior can be adjusted with a prompt change. See the prompting guide.

Migration decision rule

Upgrade now

Upgrade immediately for:

Long-running agentic coding
Multistep research
Document generation
Spreadsheet generation

These workloads benefit from the largest benchmark gains, cheaper cache reads, and fewer safeguard false positives. Cognition also said it was moving its Devin traffic to Fable 5.1 on launch day.

Upgrade after auditing your harness

If your application builds the messages array manually and does more than append new turns, audit history handling first:

Replay conversations with preserved thinking blocks.
Test system-prompt and tool-array changes.
Fix every prefix_binding_mismatch.
Re-run production-like evaluations.
Migrate only after the checks pass.

Move from `high` to `medium`

If Fable 5 at high handles routine tasks well, test Fable 5.1 at medium. You may get similar quality with fewer output tokens and lower total cost.

Stay on Fable 5

Stay on Fable 5 when:

Priority Tier is required
The workload is output-heavy with little cached input
Migration overhead exceeds the expected quality improvement

Fable 5 is supported until at least June 9, 2027, on Anthropic-operated platforms. Bedrock and Google Cloud may set different retirement dates.

Consider Opus 5

If Fable 5 was already more capable than your workload required, evaluate Opus 5 instead. Anthropic recommends starting with Opus 5 and moving up only when it falls short. The Fable 5.1 vs. Opus 5 comparison covers the option at half the price.

Test both models in Apidog

The most reliable migration decision comes from your own production-like prompts.

In Apidog:

Save your ten hardest production prompts as requests.
Store the model ID in an environment variable.
Run the collection against claude-fable-5.
Run it again against claude-fable-5-1 at the same effort level.
Compare the response text, usage.output_tokens, and usage.cache_read_input_tokens on the second run.
Add a forced tool_choice request to confirm that your test suite catches the new 400 error.

Download Apidog to get started. The API walkthrough includes the request bodies.

FAQ

Is Claude Fable 5.1 a new model or an update to Fable 5?

It is a new model with its own ID, claude-fable-5-1, and its own retirement date. It uses the same tokenizer and per-token pricing as Fable 5 and is trained on data through June 2026.

Does Fable 5.1 cost more than Fable 5?

No. Input and output pricing remains $10 and $50 per million tokens. Cache writes and batch rates are also unchanged. Cache reads are cheaper: $0.25 per million tokens instead of $1.

Will my Fable 5 code work on Fable 5.1?

Most of it will. Forced tool_choice returns a 400, and applications that edit conversation history between requests can invalidate thinking blocks on accounts created on or after August 31, 2026. The remaining API behavior carries over.

Is Fable 5 being retired?

Not yet. Anthropic will not retire Fable 5 before June 9, 2027, on Anthropic-operated platforms. Bedrock and Google Cloud set their own dates.

Which model is better at coding?

On Anthropic’s benchmarks, Fable 5.1 performs better:

Terminal-Bench 4.0: 55.8% vs. 42.0%
CursorBench 3.2.0: 73.4% vs. 70.5%

The agentic-terminal improvement is large, while the IDE-style improvement is smaller. Both results are vendor-run.

Does Fable 5.1 refuse less often?

Anthropic reports 85% fewer biology false positives and approximately 60% fewer cyber interventions per Claude Code session. The refusal categories remain the same, so keep your refusal handling and fallback logic in place.

How to Use the Claude Fable 5.1 API (Step-by-Step with Apidog)

Hassann — Wed, 02 Sep 2026 02:43:17 +0000

Claude Fable 5.1 API: A Practical Guide to Requests, Effort, Tools, Fallbacks, and Caching

Claude Fable 5.1 shipped on September 1, 2026. Its API model ID is exactly claude-fable-5-1—there is no date suffix. Pricing matches Fable 5 at $10 per million input tokens and $50 per million output tokens, while cache reads now cost $0.25 per million. It also introduces three breaking changes that Fable 5 does not have.

Try Apidog today

This guide covers the complete API workflow: creating a key, sending a request, controlling effort, streaming, using tools without forced tool_choice, handling refusals, displaying progress updates, and verifying cache usage. Every example uses plain HTTP with JSON, so you can build and debug it in Apidog before moving it into application code.

If you are migrating an existing Fable 5 or Opus 5 service, read the full migration guide. For an overview, start with What Claude Fable 5.1 is.

Before your first call: three causes of `400`

1. Thinking is adaptive only

Fable 5.1 runs adaptive thinking on every request. Omit thinking, or send:

{"type": "adaptive"}

These configurations return 400:

{"type": "disabled"}

{"type": "enabled", "budget_tokens": N}

If you are migrating from Opus 5, where disabled thinking was accepted at high effort or below, remove that setting and control spend with output_config.effort.

2. Forced tool use is unsupported

These values return an error:

{"type": "any"}

{"type": "tool", "name": "..."}

Use tool_choice: {"type": "auto"} and follow the tool-use pattern below.

3. Your organization needs 30-day data retention

Fable 5.1 is a Covered Model. Requests from an organization or workspace configured for zero data retention return:

400 invalid_request_error

If the request body looks correct, check retention settings first.

See Anthropic’s What’s new in Claude Fable 5.1.

Step 1: Get an API key

Sign in to the Claude Console, open your organization settings, and create an API key. Copy it immediately because it cannot be read again later.

Export it instead of pasting it into source code:

export ANTHROPIC_API_KEY="sk-ant-..."

In Apidog, save it as an environment variable named ANTHROPIC_API_KEY and reference it as {{ANTHROPIC_API_KEY}} in the x-api-key header. This keeps the key out of saved request bodies.

Step 2: Send your first request

Create a POST request to:

https://api.anthropic.com/v1/messages

Use these headers:

x-[REDACTED CREDENTIAL]
anthropic-version: 2023-06-01
content-type: application/json

cURL

curl https://api.anthropic.com/v1/messages \
  -H "x-[REDACTED CREDENTIAL]IC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-fable-5-1",
    "max_tokens": 16000,
    "messages": [
      {
        "role": "user",
        "content": "Explain the difference between idempotent and safe HTTP methods, with one example each."
      }
    ]
  }'

Python SDK

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    messages=[
        {
            "role": "user",
            "content": "Explain the difference between idempotent and safe HTTP methods, with one example each.",
        }
    ],
)

if response.stop_reason == "refusal":
    print(
        "declined:",
        response.stop_details.category if response.stop_details else None,
    )
else:
    for block in response.content:
        if block.type == "text":
            print(block.text)

Check stop_reason before reading content. A classifier refusal returns HTTP 200 with an empty content array.

Also give max_tokens enough room. It caps thinking tokens and response tokens together, and thinking is always enabled. A value tuned for a no-thinking model may truncate the response.

By default, the response includes a thinking block with empty text because its display mode is "omitted". This is expected. Pass the block back unchanged on the next turn.

Step 3: Control cost and depth with effort

output_config.effort is the main control for Fable 5.1. It accepts:

low
medium
high
xhigh
max

The default is high.

{
  "model": "claude-fable-5-1",
  "max_tokens": 16000,
  "output_config": {
    "effort": "medium"
  },
  "messages": [
    {
      "role": "user",
      "content": "Summarize this changelog in five bullets."
    }
  ]
}

Anthropic recommends starting at high, then evaluating every level against your own test set. Repeat the evaluation when migrating from Fable 5 because effort levels do not represent the same amount of thinking across models.

Anthropic reports that:

medium can roughly match Fable 5 at lower cost.
low is often competitive with Opus and Sonnet on cost per task.
At low, the model calls search and retrieval tools less often and relies more on memory.
At xhigh and max, it may draft a long deliverable during thinking and then write it again. Allocate max_tokens accordingly.

Change effort mid-conversation

This beta feature changes effort from the next user turn without invalidating the cached prefix. It requires:

mid-conversation-output-config-2026-07-01

Use the client.beta.messages namespace:

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    output_config={"effort": "high"},
    betas=["mid-conversation-output-config-2026-07-01"],
    messages=[
        {
            "role": "user",
            "content": "Plan a migration from SQLite to PostgreSQL in three short steps.",
        },
        {
            "role": "assistant",
            "content": (
                "1. Export the SQLite data. "
                "2. Create the PostgreSQL schema. "
                "3. Import the data and verify row counts."
            ),
        },
        {
            "role": "system",
            "content": [],
            "output_config": {"effort": "low"},
        },
        {
            "role": "user",
            "content": "Summarize the plan in one sentence.",
        },
    ],
)

Lowering effort this way is reliable. For increases, use larger jumps such as low to xhigh.

See the effort parameter documentation and the Opus 5 effort parameter guide.

Step 4: Stream long responses

At higher effort, difficult turns can run for several minutes. Stream anything that may be long. The SDK requires streaming for max_tokens values near the 128,000-token cap to avoid HTTP timeouts.

with client.messages.stream(
    model="claude-fable-5-1",
    max_tokens=64000,
    messages=[
        {
            "role": "user",
            "content": "Write a test plan for a rate-limited public API.",
        }
    ],
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

    final = stream.get_final_message()

print(final.stop_reason, final.usage.output_tokens)

Apidog renders streaming responses as they arrive, making it easy to measure how long a high-effort turn spends thinking before the first text token.

Step 5: Use tools without forcing a call

Tool definitions work the same way as in Fable 5. The difference is that Fable 5.1 does not support forced tool calls. A forced call can skip thinking and cause the model to write its working process into the arguments, so tool_choice: {"type": "tool", ...} returns 400.

Use three safeguards instead:

Keep tool_choice set to auto.
Name the tool explicitly in the instruction.
Set strict: true, and use additionalProperties: false in the schema.

record_summary_tool = {
    "name": "record_summary",
    "description": "Record the structured summary of the document.",
    "strict": True,
    "input_schema": {
        "type": "object",
        "properties": {
            "summary": {"type": "string"}
        },
        "required": ["summary"],
        "additionalProperties": False,
    },
}

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    tools=[record_summary_tool],
    tool_choice={"type": "auto"},
    messages=[
        {
            "role": "user",
            "content": (
                "Summarize: The meeting moved to Thursday. "
                "Call the record_summary tool with your result."
            ),
        }
    ],
)

For JSON extraction, use structured outputs with output_config.format instead of a tool.

If your application requires a specific tool call during a multi-turn conversation, append a system message after the latest user turn that names the required tool. Keep that message in the conversation history. tool_choice: {"type": "none"} still works when a turn must not call tools.

The agentic loop remains the same:

Wait for stop_reason == "tool_use".
Execute every tool_use block.
Return all tool_result blocks in one user message.
Append the assistant turn exactly as returned, including thinking blocks.

For long loops, Fable 5.1 may issue one independent read per turn instead of batching several as Fable 5 did. After each tool-result message, add this turn-scoped system nudge:

First privately list what you need next; then request every item that doesn’t depend on another’s result in this one response.

Use the mid-conversation-system-clear-at-2026-08-21 beta header and clear_at: "next_user_message". Keep earlier copies in the history.

For schema details, see Anthropic’s strict tool use guide and this preserved thinking guide.

Step 6: Handle refusals with fallbacks

Fable 5.1 runs safety classifiers. A declined request returns HTTP 200 with:

stop_reason: "refusal"

The stop_details.category value can be:

cyber
bio
frontier_llm
reasoning_extraction
general_harms

A refusal before any output is not billed.

Enable server-side fallbacks

Use fallbacks: "default" with this beta header:

server-side-fallback-2026-07-01

For Fable 5.1, permitted fallback targets are claude-opus-4-8 and claude-opus-5.

response = client.beta.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    fallbacks="default",
    betas=["server-side-fallback-2026-07-01"],
    messages=[
        {
            "role": "user",
            "content": "Audit this authentication middleware for logic bugs.",
        }
    ],
)

fallback_ran = any(
    entry.type == "fallback_message"
    for entry in (response.usage.iterations or [])
)

if fallback_ran and response.stop_reason != "refusal":
    print("served by", response.model)

The top-level model field identifies the serving model. A fallback content block marks the handoff. Preserve that block when echoing the turn back.

Limitations:

fallbacks is rejected on the Batches API.
It is unavailable on Bedrock, Google Cloud, and Foundry.
For those platforms, register the SDK’s BetaRefusalFallbackMiddleware on the client.

See the refusal handling and fallbacks guide for billing, sticky routing, and manual retry behavior.

Step 7: Display progress updates

During long tool workflows, Fable 5.1 can emit short notes about what it found and what it will do next. Each note appears in its own thinking block immediately before a tool call.

To receive these notes as text, set:

"thinking": {
  "type": "adaptive",
  "display": "updates"
}

Also send the beta header:

thinking-display-updates-2026-08-18

Example:

{
  "model": "claude-fable-5-1",
  "max_tokens": 16000,
  "thinking": {
    "type": "adaptive",
    "display": "updates"
  },
  "tools": [],
  "messages": [
    {
      "role": "user",
      "content": "Review the PRs open against our billing service."
    }
  ]
}

Render thinking blocks with non-empty text as status lines while keeping the reasoning hidden. Fable 5.1 produces fewer updates than Fable 5, so remove prompt instructions that tell the model to hold findings for the final response if your UI depends on narration.

Step 8: Verify the `$0.25` cache-read rate

Prompt caching is where Fable 5.1’s pricing changes matter most. Cache a stable prefix and inspect the usage object:

response = client.messages.create(
    model="claude-fable-5-1",
    max_tokens=16000,
    system=[
        {
            "type": "text",
            "text": LONG_STABLE_SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Which endpoints in the spec lack an error schema?",
        }
    ],
)

u = response.usage
print(
    u.input_tokens,
    u.cache_creation_input_tokens,
    u.cache_read_input_tokens,
)

Expected behavior:

First request: cache_creation_input_tokens is nonzero and billed at $12.50 per million for the five-minute TTL.
Second request within five minutes: cache_read_input_tokens is nonzero and billed at $0.25 per million.
Minimum cacheable [REDACTED PROMPT]

If cache reads remain zero across identical requests, the prefix is changing. Check for:

Timestamps in the system prompt
Unsorted JSON
A changing tools array

Because a cache miss costs 40 times more than a hit, keeping the cache warm matters more than it did on Fable 5. Per-message effort and turn-scoped system messages also let you change behavior without resetting the prefix.

Edits that reset the cache—such as rebuilding the system prompt or changing earlier turns—also invalidate thinking blocks. Append-only conversation handling therefore protects both the cache and thinking state.

See Anthropic’s prompt caching documentation.

Test the complete flow in Apidog

Save each step as a request in one Apidog collection:

Basic request
Effort variants
Streaming
Tool loop
Refusal fallback
Cache verification

Use environment variables for the API key and model. Switching the collection between claude-fable-5 and claude-fable-5-1 should require only one change.

Add assertions for:

stop_reason is not refusal on benign test prompts.
usage.cache_read_input_tokens > 0 on the second cache request.
No input_transformations entry has reason: "prefix_binding_mismatch" when using the thinking-binding header.

Run the collection before and after changing your harness. Download Apidog to get started; the same collection can run in CI through the Apidog CLI.

Errors and gotchas

400 tool_choice: type "tool" and "any" are not supported for this model

Use auto, explicitly name the tool in the instruction, and set strict: true.
400 for {"type": "disabled"} in thinking

Remove the field and lower output_config.effort instead.
400 invalid_request_error with an otherwise valid body

Verify that the organization or workspace has 30-day retention.
400 Invalid signature in thinking block

The block belongs to a different conversation. Your code changed an earlier turn, the system prompt, or the tools array.
Empty thinking text

This is expected with display: "omitted". Use "summarized" or "updates" when you need visible output.
Cache reads remain zero

Audit the prefix for timestamps, unsorted objects, and changing tool definitions.
Priority Tier validation fails

Fable 5.1 does not support Priority Tier. Fable 5 does.

FAQ

What is the model ID for the Claude Fable 5.1 API?

Use:

claude-fable-5-1

On Amazon Bedrock, use anthropic.claude-fable-5-1. Google Cloud, Microsoft Foundry, and Claude Platform on AWS use claude-fable-5-1.

Do I need a beta header?

No. The base model, adaptive thinking, effort, tools, and caching work with:

anthropic-version: 2023-06-01

Beta headers are required only for:

Per-message effort
Turn-scoped system messages
Progress updates
Server-side fallbacks
Thinking-binding controls

Can I force a tool call?

No. tool_choice: "any" and tool_choice: "tool" return 400.

Use auto, name the tool in the prompt, and set strict: true for schema-valid arguments. For JSON extraction, use structured outputs.

What is the maximum output?

The Messages API supports up to 128,000 tokens. Stream large responses. The 300,000-token Batch API beta is not listed for Fable 5.1.

How do I verify cheaper cache reads?

Inspect:

usage.cache_read_input_tokens

On Fable 5.1, cache reads cost $0.25 per million tokens, compared with $1 on Fable 5 and $0.50 on Opus 5. See the pricing breakdown.

Does the Fable 5 API guide still apply?

Mostly. The Fable 5 API guide covers the same endpoint, but its forced tool-use examples return 400 on Fable 5.1. It also predates per-message effort and progress updates.

How to Test OAuth 2.0 APIs in Apidog (Authorization Code, Client Credentials, and Token Refresh)

Hassann — Mon, 31 Aug 2026 11:20:26 +0000

Every API team hits the same wall: endpoints work in isolation, then OAuth 2.0 enters the picture and half the test suite starts returning 401. Suddenly, you’re juggling authorization servers, short-lived access tokens, and manually copying tokens from curl responses into headers.

Try Apidog today

The solution isn’t skipping authentication in your tests. It’s making token handling part of test setup. This guide covers the two OAuth flows you’ll use most often:

Authorization code with PKCE for APIs acting on behalf of a user
Client credentials for machine-to-machine calls

For a complete overview of OAuth grants, see OAuth 2.0 flows overview.

You’ll also learn how to configure OAuth 2.0 in Apidog, reuse tokens, refresh expired tokens, inherit authentication at the folder level, and test authentication failures.

The two OAuth flows that matter for API testing

OAuth 2.0 defines several grant types, but day-to-day API testing usually centers on one question:

Does the API act on behalf of a user or a service?

Authorization code flow with PKCE

The authorization code flow obtains a token tied to a user:

The client redirects the user to the authorization server.
The user logs in and grants consent.
The authorization server redirects back with a one-time code.
The client exchanges the code for an access token at the token endpoint.

RFC 6749 defines this flow in section 4.1.

PKCE (Proof Key for Code Exchange, RFC 7636) protects the code exchange. The client generates a random verifier, sends a hashed challenge with the authorization request, then proves possession of the verifier when redeeming the code. An attacker who intercepts the code cannot use it.

PKCE was originally designed for mobile apps, but oauth.net recommends it for every authorization code exchange, including confidential clients.

Use this flow when endpoint behavior depends on user identity, such as:

GET /orders returning only the caller’s orders
Role-protected admin endpoints
Per-user rate limits

Client credentials flow

The OAuth 2.0 client credentials grant skips the user. The client authenticates with its own ID and secret and receives a token representing the application:

curl -X POST https://auth.example.com/oauth/token \
  -d grant_type=client_credentials \
  -d client_id=orders_service \
  -d [REDACTED CREDENTIAL] \
  -d scope="orders:read orders:write"

Use client credentials for machine-to-machine APIs, including:

Internal microservices
Cron jobs
CI pipelines calling deployment APIs
Most automated test suites

If your test environment can provision a test client, use client credentials unless user identity is the behavior under test.

Configure OAuth 2.0 authentication in Apidog

Apidog treats OAuth 2.0 as a first-class authentication type. Configure it once in the Auth tab for a request or folder, and Apidog handles token retrieval, attachment, and refresh.

Supported grant types include:

Authorization Code
Authorization Code (With PKCE)
Client Credentials
Password Credentials
Implicit

The examples below use a fictional order-management API.

Configure client credentials

Open a request—or preferably its folder—set the authentication type to OAuth 2.0, and select Client Credentials.

Enter:

Access Token URL: https://auth.example.com/oauth/token
Client ID: orders_service
**Client [REDACTED CREDENTIAL] Your provisioned secret
Scope: orders:read orders:write under advanced options

Apidog can send credentials in either:

A Basic Auth header
The request body

Match the option expected by your authorization server. Auth0 and Okta accept both, while some internal authorization servers only parse credentials from the body.

Click Get Token. Apidog calls the token endpoint, stores the response, and displays the token and validity period. Subsequent requests automatically send:

[REDACTED CREDENTIAL] <access-token>

No copy-paste or {{token}} variable plumbing is required.

Configure authorization code with PKCE

For user-context testing, select Authorization Code (With PKCE). In Apidog, PKCE is a separate grant option rather than a checkbox.

Enter:

Auth URL: https://auth.example.com/oauth/authorize
Access Token URL: https://auth.example.com/oauth/token
Callback URL: The redirect URI registered with your provider
**Client ID and Client [REDACTED CREDENTIAL] From your OAuth app registration

Click Get Token. Apidog opens a browser window to the login page. Sign in with your test user, approve the consent screen, and Apidog stores the returned token in the same managed token slot.

If your provider returns an OpenID Connect ID token alongside the access token, use Token Type Used to choose which token Apidog attaches. This is useful when the API validates ID tokens.

Create a dedicated test user for each role you need to cover, such as:

Buyer
Administrator
Read-only auditor

Fetching a token for each user and rerunning the same scenario is a fast way to verify role-based access rules.

Reuse and automatically refresh tokens

Access tokens commonly expire within an hour. An expired token should not turn into a mysterious or flaky test failure.

When the authorization server issues a refresh token, Apidog automatically refreshes the access token after expiry. This capability shipped in the June update.

Apidog uses the refresh token to request a new access token and replaces the stored token before sending the request. If your provider separates refresh operations into another endpoint, configure a custom refresh token URL in advanced settings.

Client credentials flows often do not return refresh tokens because the client can authenticate again at any time. In that case:

Click Get Token to request a new token
Configure scheduled or CI runs to request a token at the beginning of each run

Inherit authentication at the folder level

Configuring OAuth separately on every request creates unnecessary maintenance. Instead, set OAuth 2.0 on a folder and let child requests inherit the configuration.

For example, configure OAuth once on an Orders API folder. Every request inside it—including requests added later—uses the same managed token.

Folder-level authentication is especially useful for multi-step scenarios:

POST /carts
POST /carts/{id}/items
POST /orders

All steps share one token and one configuration. Automatic refresh handles token expiry during the scenario, and rotating a client secret requires updating only the folder instead of dozens of requests.

Individual requests can override the inherited configuration, which is useful for negative tests.

Test OAuth failure paths

Happy-path tests verify that your token pipeline works. Failure-path tests verify that your API enforces authentication and authorization.

For a refresher on status-code behavior, see API keys and Bearer [REDACTED].

Expired or missing [REDACTED CREDENTIAL] `401`

Duplicate a request and override its inherited authentication with either:

No authentication
A hardcoded expired token, such as Bearer [REDACTED]

Assert that:

The status code is 401
The WWW-Authenticate response header is present
The response body does not expose stack traces or internal hostnames

A 200 response is a critical bug. A 403 is a design smell: the server should distinguish between “I don’t know who you are” and “I know who you are, but you are not allowed.”

Incorrect scope: expect `403`

Provision a second test client limited to orders:read. Fetch its token and call a write endpoint such as POST /orders.

Assert that:

The status code is 403
If your API follows RFC 6750, the WWW-Authenticate header contains error="insufficient_scope"

This catches configurations where scope checks are enforced on some routes but omitted on others. For more background, see OAuth 2.0 scopes explained.

Invalid client: expect a token-endpoint error

Send a request directly to:

https://auth.example.com/oauth/token

Use an invalid client_secret. Under RFC 6749 section 5.2, the authorization server should return either:

400, or
401 for failed client authentication

The JSON response should contain:

{
  "error": "invalid_client"
}

Assert on both the status code and error field. Authorization servers are APIs too, so their error contracts belong in your test coverage.

Assert token responses in test scenarios

The token endpoint deserves coverage beyond invalid-client handling. Add a scenario step that calls the token endpoint directly, then assert that:

access_token exists and is non-empty
token_type equals bearer, case-insensitively
expires_in is greater than 0 and within policy, such as no more than 3600
scope matches the requested scope

These checks catch authorization servers that silently narrow grants or return malformed responses.

Apidog test scenarios support visual assertions on response JSON without scripting. You can also extract access_token into a variable for a follow-up request when testing the raw OAuth handshake instead of managed authentication.

Run the scenario in CI so an authorization-server regression fails the build rather than appearing as a mysterious 401 in production.

A practical test structure looks like this:

Configure OAuth 2.0 at the folder level for happy-path requests.
Override authentication per request for 401 and 403 cases.
Add a scenario that validates the token endpoint contract.
Run the scenario in CI.

This covers user-context APIs with authorization code and PKCE, service-to-service APIs with client credentials, and token refresh without manual intervention. Download Apidog and try it free. OAuth 2.0 authentication is available on the free plan.

FAQ

Which OAuth flow should I use for API testing?

Use client credentials for machine-to-machine APIs and most automated suites because it requires no browser interaction.

Use authorization code with PKCE when tests depend on user identity, including:

Per-user data isolation
Role checks
Consent behavior

Avoid implicit and password grants in new test plans; both are discouraged in current OAuth guidance.

How do I refresh an expired token automatically in Apidog?

Configure OAuth 2.0 in the Auth tab and click Get Token. When the authorization server returns a refresh token, Apidog refreshes the access token after expiry without requiring you to authenticate again.

If your provider uses a separate refresh endpoint, configure its URL in advanced settings. For client credentials flows without refresh tokens, click Get Token again to issue a fresh token.

Can every request in a scenario share one OAuth token?

Yes. Configure OAuth 2.0 on the parent folder, and child requests inherit the managed token.

Individual requests can override the folder configuration, allowing you to add expired-token and insufficient-scope tests to the same scenario.

What should `401` versus `403` mean in OAuth-protected APIs?

Return 401 when authentication fails because the token is missing, expired, or malformed.

Return 403 when the token is valid but lacks permission, such as a required scope.

Mixing up these status codes breaks client retry logic:

401 tells the client to authenticate again
403 tells the client to stop retrying

For token-validation coverage, see testing JWT authentication.

API Retry Logic and Exponential Backoff: Patterns That Actually Work

Hassann — Mon, 31 Aug 2026 10:49:27 +0000

Production-Ready API Retry Logic: Backoff, Jitter, and Idempotency

Your payment API call failed at 2 a.m. Was it a network blip, a rate limit, or a dead server? The answer determines whether retrying saves the transaction—or double-charges a customer.

Try Apidog today

Retries are one of the most common resilience patterns in distributed systems—and one of the easiest to get wrong. A loop around an HTTP call may look defensive, but poorly designed retries can turn a 30-second outage into a 30-minute one by making thousands of clients hammer an already struggling server.

Done correctly, retries absorb transient failures so smoothly that users never notice them.

This guide covers:

Which failures to retry
Exponential backoff with full jitter
Retry-After headers
Idempotency keys for POST
Retry budgets and circuit breakers
Testing retry behavior with Apidog mock servers

A retry pattern that has never been tested against a failing server is a guess, not a design.

Why naive retries make outages worse

Imagine a service handling 1,000 requests per second. It fails for five seconds, and every client retries immediately three times. Demand jumps from 1,000 requests per second to 4,000—directly at a server already under stress.

The server falls over completely, and every client retries again.

This feedback loop is called a retry storm. When clients retry in sync as the server recovers, the result is a thundering herd. Google’s SRE guidance on addressing cascading failures explains why retries without backoff amplify load when a system can least afford it.

Most retry storms come from two design flaws:

No delay: Immediate retries multiply load during the worst possible window.
Fixed delays: If every client waits exactly one second, they all retry in lockstep.

The solution is not to avoid retries entirely. Retry selectively, use growing randomized delays, and impose a hard limit on additional load.

Retry these failures, not those

Before implementing backoff, define a decision table. Retrying an invalid request wastes capacity and pollutes logs; retrying a transient fault is the purpose of the mechanism.

Retry these

Signal	Meaning
`429 Too Many Requests`	You hit a rate limit. Back off and return more slowly.
`502 Bad Gateway`	An upstream hop returned an invalid response. Often transient.
`503 Service Unavailable`	The server is overloaded or restarting.
`504 Gateway Timeout`	An upstream dependency took too long.
Connection resets, DNS failures, socket timeouts	The request may never have reached the server.

A handling idempotency.

Do not retry these automatically

Signal	Meaning
`400 Bad Request`	The payload is malformed and will fail again.
`401 Unauthorized`	Credentials are wrong or expired. Refresh the token instead.
`403 Forbidden`	The caller lacks permission.
`422 Unprocessable Entity`	Validation failed. Fix the data, not the timing.

The general rule:

Retry when the failure concerns the server’s state or the network.
Fail fast when the failure concerns the request itself.

A 429 is retryable, but repeated 429 responses also indicate that your overall request rate needs attention. Solve that with client-side throttling, caching, or another rate-limiting strategy, not an increasingly aggressive retry loop.

Exponential backoff and full jitter

Exponential backoff increases the delay after each failed attempt:

delay = base * 2^retry_count

With a base delay of 500 ms, the schedule is:

0.5s, 1s, 2s, 4s, 8s

Always add a cap:

delay = min(cap, base * 2^retry_count)

For example, a 30-second cap prevents delays from growing indefinitely.

Plain exponential backoff prevents immediate hammering, but it does not prevent synchronization. If 5,000 clients fail at the same time, they may all retry at 0.5 seconds, then 1 second, then 2 seconds.

That still creates traffic waves.

Full jitter

Full jitter randomizes the delay between zero and the exponential ceiling:

delay = random_between(0, min(cap, base * 2^retry_count))

The AWS analysis of exponential backoff and jitter found that backoff without jitter still produced clustered call spikes. Full jitter produced fewer total calls and near-shortest completion times.

Randomizing down to zero may feel less orderly than a fixed doubling schedule, but distributing clients across the entire retry window keeps load flatter. Full jitter is a simple, reliable default unless measurements show that another strategy is better.

Honor `Retry-After`

Backoff is your client estimating how long to wait. Sometimes the server provides a better answer.

The Retry-After header, commonly returned with 429 and 503 responses, contains either a number of seconds or an HTTP date:

HTTP/1.1 429 Too Many Requests
Retry-After: 12

When present, Retry-After should override your computed backoff. The server knows when its rate-limit window resets or maintenance ends; your exponential schedule does not.

Parse and respect the header, but still enforce:

A maximum delay
A maximum retry count
A deadline for the overall operation

This prevents a malformed or hostile value such as Retry-After: 86400 from blocking a worker for an entire day. See the Retry-After header reference for parsing details.

Idempotency: the precondition for retrying `POST`

The 504 scenario creates a dangerous ambiguity. GET, PUT, and DELETE are generally idempotent: sending the same request more than once should leave the resource in the same state. POST is not inherently idempotent.

If POST /v1/payments times out after the server processes the payment, retrying can create a second charge.

The solution is an idempotency key: a unique, client-generated identifier—usually a UUID—sent as a request header for each logical operation. The server stores the key with the initial response and returns that stored response for duplicates. Stripe’s idempotent request implementation follows this model.

Two rules are essential:

One operation, one key. Every retry of one payment must reuse the same key. A new user action gets a new key.
Generate the key before the first request. Do not create it inside the retry loop.

If the API does not support idempotency keys, avoid automatically retrying non-idempotent writes. Surface the failure and let a human or reconciliation process decide what happened.

For more implementation guidance, see idempotency keys.

Retry budgets and circuit breakers

Backoff controls when retries happen. It does not control how many retries occur.

During a prolonged outage, even well-jittered clients can create substantial retry traffic. Layered retries make this worse: if an API gateway retries three times and the service client also retries three times, one user action can produce up to nine requests.

Retry budgets

Instead of allowing “three retries per request,” define a global budget such as:

Retries may add no more than 10% extra traffic over a sliding window.

When the budget is exhausted, return failures immediately. This bounds retry amplification regardless of how many requests are failing. Linkerd and Envoy both support retry-budget configurations.

Circuit breakers

A circuit breaker tracks failures for each downstream dependency. When the failure rate exceeds a threshold, it opens and fails calls immediately without sending network requests.

After a cooldown, the breaker permits a small number of probe requests. If the dependency has recovered, the breaker closes.

Backoff slows a stampede; a circuit breaker stops it. Production systems typically use both.

A production-ready Python example

This example combines:

Retryable-status filtering
Full jitter
Retry-After support
An idempotency key
A maximum retry count

import random
import time
import uuid
import requests

RETRYABLE = {429, 502, 503, 504}
BASE = 0.5     # seconds
CAP = 30.0     # ceiling on any single delay
MAX_RETRIES = 5

def create_payment(payload):
    idempotency_key = str(uuid.uuid4())  # one key per logical payment
    headers = {"Idempotency-Key": idempotency_key}

    for retry_count in range(MAX_RETRIES + 1):
        try:
            resp = requests.post(
                "https://api.acmepay.com/v1/payments",
                json=payload, headers=headers, timeout=10,
            )
            if resp.status_code < 400:
                return resp.json()
            if resp.status_code not in RETRYABLE:
                resp.raise_for_status()  # 400/401/403/422: fail fast
            retry_after = resp.headers.get("Retry-After")
        except (requests.ConnectionError, requests.Timeout):
            retry_after = None  # network fault: fall through to backoff

        if retry_count == MAX_RETRIES:
            raise RuntimeError("payment failed after all retries")

        if retry_after and retry_after.isdigit():
            delay = min(CAP, float(retry_after))
        else:
            delay = random.uniform(0, min(CAP, BASE * 2 ** retry_count))
        time.sleep(delay)

Important details:

The idempotency key is generated once, outside the loop.
Retry-After takes precedence over calculated backoff.
The delay still respects the cap.
Non-retryable HTTP statuses fail immediately.
Network failures fall through to jittered backoff.

On JavaScript projects, axios-retry provides the same structure through retryCondition and retryDelay hooks. The decision table remains the same.

Test retry behavior before production does it for you

Many systems ship retry logic whose failure branch has never executed. The happy path was tested; the 503 path runs for the first time during a real outage.

You can test it with two Apidog features.

1. Simulate failures with mock servers

Use Apidog’s smart mock server to define an endpoint such as /v1/payments and control its responses:

Return 503 for the first two calls and 200 on the third.
Return 429 with Retry-After: 5.
Add a 15-second delay to trigger a client timeout.

Point your client at the mock URL and observe the retry behavior without creating a production incident.

2. Assert behavior with test scenarios

Apidog test scenarios can chain requests and validate responses and timing. Build a scenario that:

Calls the flaky mock endpoint.
Verifies that the request eventually succeeds.
Checks that elapsed time falls within the expected backoff envelope.
Confirms that exactly one resource was created.
Proves that the idempotency key deduplicated retries.

Run the scenario in CI so retry logic is exercised on every commit instead of during every outage.

That is the difference between “we added retries” and “we verified that our client survives a rate-limited, partially unavailable dependency.” You can download Apidog and run a failing mock server against your client in about ten minutes.

FAQ

Should I retry a `429`?

Yes. It is the status where the server most often tells you how long to wait. Read Retry-After and wait at least that long. If the header is missing, use exponential backoff with jitter.

Repeated 429 responses should also trigger client-side throttling, caching, or other changes to reduce request volume.

What is full jitter?

Full jitter chooses each delay uniformly at random between zero and the exponential ceiling:

random(0, min(cap, base * 2^n))

It prevents synchronized retry waves. In AWS simulations, it outperformed plain backoff and equal jitter in both total calls and completion time, which is why it is a common default in AWS SDKs.

Is it safe to retry `POST` requests?

Only when the operation is idempotent in practice. For POST, that usually means supplying an idempotency key that the server uses to deduplicate requests.

Without one, retrying after a timeout can duplicate a payment, order, or record because the server may have processed the request before the client received the response. AI agent error recovery patterns use the same principles: keyed writes, capped retries, and circuit breakers.

How many times should I retry?

Three to five attempts handle most transient faults. Beyond that, success rates typically flatten while latency and load continue to increase.

Pair the per-request retry cap with a global retry budget—for example, allowing retries to add no more than 10% extra traffic. If a dependency remains unavailable after the final attempt, use circuit-breaker behavior instead of retrying indefinitely.

DEV Community: Hassann

Gemini 3.7 Flash to 3.8 Flash: API migration guide

Migrating from Gemini 3.7 Flash to Gemini 3.8 Flash: A Practical Checklist

What changes—and what doesn’t

Step 0: Decide whether to migrate

Step 1: Swap the model ID in both API shapes

Interactions API

Legacy generateContent

Python SDK

The nine-item migration checklist

1. Map thinking_level: "minimal" to "low"

2. Remove temperature, topP, and topK

3. Replace thinking_budget with thinking_level

4. Remove candidate_count

5. Include call_id and name in every function result

6. Preserve thought signatures exactly

7. Increase token budgets per route

8. Test media_resolution_high separately for PDFs and video

9. Remove image-segmentation calls

Build a regression plan in Apidog

Configure the environment

Create golden prompts

Add assertions

Compare both models

Schedule the test

Roll back with a configuration flag

FAQ

Does Gemini 3.8 Flash cost more than 3.7 Flash?

What happens if I leave thinking_level: "minimal" in place?

Do I have to use the Interactions API?

Is Gemini 3.7 Flash deprecated?

Can I keep the temperature tuned for 3.7 Flash?

Ship in stages

References

Gemini 3.8 Flash pricing: intro rates, thinking tokens, and the real cost per task

Gemini 3.8 Flash pricing at a glance

Thinking tokens count as output tokens

Example request cost

Why cost per task increased

Use the introductory rate before December 31

Gemini 3.8 Flash vs. Flash-Lite, Sonnet 5, and GPT-5.6 Luna

Catch cost regressions with Apidog token assertions

1. Store the API key securely

2. Send a representative prompt

3. Assert on usage fields

4. Schedule the test

FAQ

What to do this week

Gemini 3.8 Flash vs Claude Fable 5.1 vs GPT-5.6 Sol: which API should developers use?

Gemini 3.8 Flash vs Claude Fable 5.1 vs GPT-5.6 Sol: Which API Should You Use?

Specs at a glance

The independent result: 59, 57, and 59

What that score costs

Google’s benchmark tables—and the missing model

The price gap, line by line

Worked example

Measure cost per task, not just cost per token

When to choose each model

Choose Gemini 3.8 Flash for volume and cost-sensitive agents

Choose Claude Fable 5.1 for the hardest long-horizon reasoning

Choose GPT-5.6 Sol for OpenAI-based agent stacks

Test all three in one Apidog workspace

1. Create three environments

2. Create one test scenario

3. Run and schedule the comparison

Do all three models have a 1M-token context window?

Why is Claude Fable 5.1 missing from Google’s benchmark tables?

Does Gemini’s price advantage survive 2027?

Which model should you call first?

References

What is Gemini 3.8 Flash?

Gemini 3.8 Flash: More Agentic Reasoning at the Same Token Price

Gemini 3.8 Flash at a glance

What Gemini 3.8 Flash is

The “works harder” design—and its cost

What the benchmarks say

Pricing: same per token, more per task

How to call Gemini 3.8 Flash

What Gemini 3.8 Flash cannot do

Gemini 3.8 Flash Cyber: the gated twin

Legacy `generateContent`

1. Map `thinking_level: "minimal"` to `"low"`

2. Remove `temperature`, `topP`, and `topK`

3. Replace `thinking_budget` with `thinking_level`

4. Remove `candidate_count`

5. Include `call_id` and `name` in every function result

8. Test `media_resolution_high` separately for PDFs and video

What happens if I leave `thinking_level: "minimal"` in place?