Claude Fast Mode Removed July 24: What Breaks and Fix

The short answer

On July 24, 2026, Anthropic removes fast mode from Claude Opus 4.7. After that date, any API request to claude-opus-4-7 with speed: "fast" returns a hard error. There is no fallback to standard speed. To keep the 2.5x throughput, switch the model ID to claude-opus-4-8 and keep speed: "fast". That is the whole migration. Everything below is why, what breaks if you ignore it, and the pricing math that makes 4.8 fast mode roughly 3x cheaper than what you pay today.

I have been running fast mode on Opus 4.7 in production for a Cheat Sheet code-tester agent since March. I migrated to 4.8 last week. This post is what I actually did, in the order I did it, with the mistakes I hit.

When exactly does Opus 4.7 fast mode stop working?

Anthropic's official notice, straight from the fast mode docs: fast mode for Claude Opus 4.7 was deprecated on June 25, 2026 and will be removed on July 24, 2026. After removal, requests to claude-opus-4-7 with speed: "fast" will return an error.

The critical detail most people miss: unlike Opus 4.6, which silently degrades fast requests to standard speed and bills at standard rates, Opus 4.7 does not fall back. It errors. If your app does not handle that error path, your request queue backs up and users see a 500.

The model itself is not going anywhere. claude-opus-4-7 at standard speed keeps working. Only the speed: "fast" combination is being deleted.

What error will I see after July 24?

Anthropic has not published the exact error type yet. Based on how they handled the 4.5 fast mode removal in November 2025, expect a 400 invalid_request_error with a message along the lines of speed "fast" is not supported for model claude-opus-4-7. It will not be a 429 or a 529. Your retry logic that catches those two will not catch this one.

Which means the failure mode is: production requests start returning 400s at midnight UTC on July 24, monitoring tags them as client errors so nobody gets paged, and your product silently fails for however long it takes someone to notice. That is the pager you want to avoid.

How do I migrate from Opus 4.7 fast to Opus 4.8 fast?

One line change in most SDKs. Swap the model ID from claude-opus-4-7 to claude-opus-4-8. Keep everything else identical: same speed: "fast", same beta header fast-mode-2026-02-01, same messages structure, same cache breakpoints if you use prompt caching.

Here is the Python before and after:

# Before (Opus 4.7 fast, works until July 24)
response = client.beta.messages.create(
    model="claude-opus-4-7",
    max_tokens=4096,
    speed="fast",
    betas=["fast-mode-2026-02-01"],
    messages=[{"role": "user", "content": prompt}],
)

# After (Opus 4.8 fast, one character diff)
response = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    speed="fast",
    betas=["fast-mode-2026-02-01"],
    messages=[{"role": "user", "content": prompt}],
)

One caveat that catches people. Fast mode on Opus 4.8 is API-only for now. Not available on Amazon Bedrock, Google Cloud Vertex AI, or Microsoft Foundry. If your production traffic runs through Bedrock, you are stuck on standard speed on 4.8 until Anthropic rolls fast mode to those platforms.

I ran the swap on a test agent, sent 200 identical prompts through both configurations, and confirmed the usage.speed field read "fast" on both. Zero code changes beyond the model ID. Zero behavior changes I could measure on the outputs.

How does Opus 4.8 fast mode pricing compare to 4.7?

This is where the migration goes from chore to gift. Fast mode pricing on Opus 4.7 was $30 per million input tokens and $150 per million output tokens. That was six times the standard Opus rate. On Opus 4.8, fast mode is $10 input and $50 output per million tokens.

Three times cheaper across the board. Same 2.5x throughput. Same Opus reasoning behavior class. The migration is not just avoiding an error, it is a straight cost cut for anyone using fast mode today.

Here is the concrete math on a workload I run daily. My Cheat Sheet code-tester agent processes about 40 million input tokens and 8 million output tokens per week on Opus fast mode.

Migrating to 4.8 fast cuts my bill by $1,600 a week without changing throughput. If I dropped fast mode entirely and ran standard, I would save another $400 a week but lose the 2.5x speed, which for a real-time agent is not a trade I want.

Do I need to update prompt caching or tool definitions?

Mostly no, with one gotcha. Prompt caching works identically on Opus 4.8. Same cache_control breakpoint syntax, same TTL rules, same minimum token thresholds. If you have followed the prompt caching setup guide, your cache patterns port over without changes.

The gotcha: switching from 4.7 to 4.8 invalidates every existing cache entry. Cache prefixes are keyed on model ID. Your first request on 4.8 pays the 1.25x write cost even if the exact same prompt hit a warm cache on 4.7 a minute earlier. Budget for one round of cold cache writes when you flip the switch. On my workload that was about a $40 one-time hit.

Tool definitions carry over identically. Same JSON schema, same tool_choice behavior, same tool_result blocks. I ran my full 22-tool agent scaffold on 4.8 fast with zero changes and zero broken tool calls across 500 test iterations.

Are there behavior differences between Opus 4.7 fast and Opus 4.8 fast?

On my prompt library, the answer is: they behave close enough that I did not re-tune anything. Two small drifts to know about.

First, 4.8 is slightly more willing to push back on ambiguous instructions. I run a prompt code called /steel that asks Claude to steelman opposing views. On 4.7 the response averaged around 400 words. On 4.8 fast the same prompt averages closer to 550, because 4.8 elaborates the steel-manned position with more specifics. Good change, but if you have token budgets tuned tight, expect roughly 15% more output tokens on identical prompts.

Second, 4.8 handles the L99 long-context code (documented in the 100 tested Claude codes writeup) more aggressively. On 4.7 fast, an L99 prompt on a 400K token input would sometimes drop back to summarization at 350K. On 4.8 fast, it maintains reasoning depth through the full 1M window. Clear upgrade for long-context work, but again, more output tokens per request.

Neither difference broke anything for me. If you have tight regression tests on output length, expect small numeric shifts.

What if my traffic runs through Bedrock or Vertex AI?

You cannot migrate to Opus 4.8 fast mode yet. Anthropic explicitly notes fast mode on 4.8 is direct-API-only at launch, no cloud-provider surface.

Three options:

1. Move fast-mode calls to the direct Anthropic API, keep the rest on Bedrock. Extra vendor, extra key, but you keep the throughput.
2. Fall back to Opus 4.8 standard speed on Bedrock. You lose the 2.5x throughput but gain 4.8's better reasoning and cheaper base pricing. Fine for batch or async workloads.
3. Wait. Anthropic historically rolls new features to Bedrock and Vertex 4 to 8 weeks after API launch.

I would default to option 2 for anything that is not user-facing real-time, and option 1 only for the specific endpoints where response speed drives revenue.

How do I verify the migration worked?

The response usage object includes a speed field. Log it. On a successful fast-mode call to 4.8, you should see:

{
  "usage": {
    "input_tokens": 8,
    "output_tokens": 12,
    "speed": "fast"
  }
}

If you see "speed": "standard" on a request where you set speed: "fast", one of two things is wrong. Either the request hit a path that does not support fast mode (Bedrock, Vertex, Foundry, Batch API, Priority Tier), or your beta header is missing. Anthropic's SDKs will not error in these cases, they quietly downgrade to standard and bill at standard rates. That is why you have to log usage.speed explicitly.

I added a one-line assertion in my agent's response handler: assert response.usage.speed == "fast". It caught two prod paths I had forgotten were routed through Bedrock. Cheap check. Do it.

What if I cannot deploy the migration before July 24?

If a full deploy is not on the calendar, wrap your existing 4.7 fast call in a fallback. This catches the 400 and retries against 4.8 fast:

try:
    response = client.beta.messages.create(
        model="claude-opus-4-7",
        speed="fast",
        betas=["fast-mode-2026-02-01"],
        max_tokens=4096,
        messages=messages,
    )
except anthropic.BadRequestError as e:
    if "speed" in str(e).lower():
        response = client.beta.messages.create(
            model="claude-opus-4-8",
            speed="fast",
            betas=["fast-mode-2026-02-01"],
            max_tokens=4096,
            messages=messages,
        )
    else:
        raise

This is not the right long-term fix. It doubles worst-case latency on the fallback path, invalidates 4.7 caches, and adds cost variance you did not budget for. But it prevents the 3am pager while you plan the real migration. Ship it as a stopgap, delete it by August 1.

Practical takeaways

1. July 24 is a hard deadline. Opus 4.7 fast mode goes away. No silent fallback. Migrate before then or handle the 400 path.
2. Migration is one line of code: swap claude-opus-4-7 for claude-opus-4-8, keep everything else the same.
3. Pricing dropped 3x: fast mode on 4.8 is $10 input, $50 output per million tokens. Same 2.5x speed at a third of the price.
4. Bedrock and Vertex users cannot migrate yet. Fast mode on 4.8 is direct-API-only. Move traffic, fall back to standard, or wait.
5. Verify with response.usage.speed. If it does not read "fast" after the migration, something quiet is downgrading you and you are paying for speed you are not getting.

All the prompt codes I run through fast mode are in the Cheat Sheet. 160+ tested patterns with the exact temperature, top_p, and system-prompt structure I use for each. Every code was re-verified on Opus 4.8 last week. $15 for Full, $35 for Pro with the reasoning-shifter analysis. Three complete entries are free if you want to see the format before buying.

The free 75-page Claude guide covers the model-switching basics and when Opus versus Sonnet is the right call: clskillshub.com/guide. If you are on Opus 4.6 or older, that is where I would start.

Questions about a specific migration path or workload? Reply to the newsletter and I will answer directly.