●Breaking
Claude Fable 5.1: `tool_choice` Types `any` and `tool` Return 400
What changed
On Claude Fable 5.1 and Claude Mythos 5.1, tool_choice: {"type": "any"} and tool_choice: {"type": "tool", "name": "..."} now return HTTP 400 invalid_request_error with the message tool_choice: type "tool" and "any" are not supported for this model. This applies to both the /v1/messages endpoint and the token-counting endpoint.
TL;DR
Forced tool use is removed from Fable 5.1 because adaptive thinking is always on and a forced tool call would bypass it; only tool_choice: auto (default) and none are supported.
Developer signal
Before updating any production service from claude-fable-5 to claude-fable-5-1, audit every tool_choice setting. Where you currently use {"type": "tool", "name": "..."} for schema-conformant JSON, replace it with tool_choice: {"type": "auto"} plus strict: true on the tool definition (strict tool use), or migrate the schema to structured outputs. Where you're forcing tool calls through prompt logic, switch to clear prompt instructions — the docs note Fable 5.1 follows explicit tool instructions reliably at auto. This change also fires on the token-counting endpoint, so any token-estimation code that sends a tool_choice type will also break.
Affects you ifYou call the Claude API directly with tool_choice set to "any" or "tool"; any agent framework or orchestrator that auto-sets forced tool use when passing tools (check LangChain, LlamaIndex, and AutoGen integrations before upgrading the model ID).EffortModerate — must audit and remove all forced tool_choice settings before updating model ID.
●Breaking
Claude Fable 5.1: Thinking Blocks Are Model-Bound and Turn-Edit-Sensitive
What changed
Two new constraints on thinking block handling: (1) Thinking blocks produced by Fable 5.1 cannot be read by any earlier model — a router or fallback that switches to Fable 5, Opus 5, or older Claude models will have those blocks silently dropped (or reported, with the thinking-binding-controls-2026-08-01 beta header). (2) For API accounts created on or after August 31, 2026: modifying anything before a Fable 5.1 thinking block — system prompt, tools array, or any earlier message — returns a 400 The block is bound to a different conversation on the next request. Accounts predating August 31 log the mismatch but only enforce it when prefix_mismatch_behavior is explicitly set.
TL;DR
Fable 5.1 thinking blocks are forward-only (readable only by Fable 5.1 and newer) and invalidated by any history edit for new accounts — two constraints that break common multi-model routing and per-request injection patterns.
Developer signal
Two separate issues to fix: (a) Model routing — any code that can fall back from Fable 5.1 to an earlier Claude model mid-conversation loses thinking blocks on the fallback leg; this is usually silent without the beta header. Add the thinking-binding-controls-2026-08-01 beta header and log input_transformations to detect drops. (b) History mutation — if your code builds the messages array by injecting and removing per-request text (e.g., status lines, reminders), or rebuilds system or tools between turns, this breaks thinking block continuity. The fix: move per-turn injections to mid-conversation system messages with clear_at: "next_user_message" (new feature, also in this release), and apply tool/system changes via mid-conversation system messages instead of editing the top-level fields. The migration guide at platform.claude.com/docs/en/models/fable-5-1/migration-guide has a three-step history-editing check. Run it before promoting Fable 5.1 to production.
Affects you ifYou use model routing or fallback that switches between Fable 5.1 and any earlier model; you build messages arrays that inject/remove text per request; you rebuild system or tools between turns of the same conversation; your account was created on or after August 31, 2026.EffortSignificant — requires auditing message construction, routing logic, and potentially restructuring how per-turn context is injected.
●Breaking
GitHub Copilot Retires 6 Models Today — All Copilot Surfaces Affected
What changed
GitHub Copilot retired six AI models today: Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6, and Raptor mini. The retirement applies immediately to all GitHub Copilot surfaces: Copilot Chat, inline edits, ask and agent modes, code completions, the Copilot IDE extension, Copilot.com, and any Copilot Extension or workflow calling these model IDs via the Copilot API directly. Exception: individual GitHub Copilot subscribers on annual plans retain access to Claude Sonnet 4.6 beyond September 1.
TL;DR
Six Copilot models are gone today across all Enterprise/Business tiers; the affected models include Claude Sonnet 4.5, 4.6 and Opus 4.5, 4.6 — any extension or CI workflow still referencing these IDs returns errors right now.
Developer signal
Org admins who have not already acted: go to Settings → Copilot → Policies → Model access and enable replacement models now. Retired models return errors, not degraded responses. Replacement paths: Gemini 3.1 Pro → Gemini 3.6 Flash; Claude Opus 4.5/4.6 → Claude Opus 4.7, 4.8, or Opus 5; Claude Sonnet 4.5/4.6 → Claude Sonnet 4.6 (if on annual individual plan) or Claude Sonnet 5 on Business/Enterprise. For any Copilot Extension or CI/CD workflow that references a retired model ID explicitly: update the model identifier string in your extension manifest or workflow config. If your organization relies on model-ID-specific routing in Copilot Extensions (e.g., a tool that always requests claude-sonnet-4-6), this is a code change, not just a settings change.
Affects you ifYou are a GitHub Copilot Business or Enterprise org admin; you use or build Copilot Extensions that reference any of the six retired model IDs; you run CI/CD workflows that call Copilot APIs with a specific model ID.EffortModerate — settings change for most, code change for extensions/pipelines with hardcoded model IDs.
●Breaking
Gemini API: Standard Keys Rejected Starting September 2026 — Migrate to Auth Keys Now
What changed
Google's Gemini API is now rejecting requests authenticated with standard API keys. This completes a migration that started June 19, 2026 (when unrestricted standard keys were first blocked); standard keys with explicit API restrictions applied continued until this month. The replacement is auth keys — cryptographically bound to a specific Google Cloud service account, scoped to the Gemini API by default, and controlled via IAM policies.
TL;DR
All Gemini API standard keys are now rejected; production workloads using unrotated keys from before mid-2026 are broken today and must migrate to auth keys, which tie API access to a GCP service account identity.
Developer signal
Any request to the Gemini API with an AIza... standard key prefix will now fail. To migrate: (1) In Google AI Studio or Cloud Console, create a new auth key — new keys created in Google AI Studio are auth keys by default. (2) Update your application to use the new key. (3) Revoke the old standard key. Auth keys are GCP IAM-scoped, meaning a leaked auth key can only access the Gemini API (unlike standard keys, which could be misused across Google services). For teams using service account impersonation or workload identity federation with GCP, the auth key approach is a natural fit — the service account the key is bound to carries your existing IAM policies. The timeline to watch: this enforcement enforces the deadline that was communicated in June; there are no further grace periods.
Affects you ifYou call the Gemini API from any application using a key that predates mid-2026; you have Gemini API keys embedded in CI/CD, local development, or production infrastructure that haven't been rotated since the June 2026 announcement.EffortModerate — create new auth key in Google AI Studio/Cloud Console, rotate into all environments, revoke old key.