Anthropic Claude release April 2026, read through the 400 most guides miss

The headline shipments were Claude Opus 4.7 GA on April 22, 2026 at $5 input and $25 output per million tokens, a 1M context window, materially better long-horizon coding, and a refreshed Claude Design surface. The Agent Client Protocol moved from v0.25.0 on April 7 to v0.29.2 on April 20. Claude Haiku 4.5 expanded to 27 AWS Bedrock regions. A Mythos Preview landed behind Project Glasswing. The piece nobody writes up is that Anthropic also refreshed their consumer terms during the same window, and every client that hits claude.ai for OAuth started getting 400 invalid_request_error responses until users went and clicked Accept.

Because the 400 that Anthropic returns is shaped almost identically to an auth-failure 400. It is an invalid_request_error with a human-readable message pointing at claude.ai. A naive client sees a 400 from the Claude API and does the default thing: invalidate the cached token and trigger a fresh OAuth flow. That does not help. The user signs in again successfully, the token is minted, the next request still returns the same 400, the cycle repeats. The user lands on an OAuth loop. The correct behavior is to show the terms prompt verbatim and stop retrying until the user has clicked Accept at claude.ai.

In Desktop/Sources/Providers/ChatProvider.swift at line 1374, a static function called isTermsAcceptanceRequired takes the raw agent error message, lowercases it, and substring-matches against four patterns: consumer terms, terms of service combined with accept, terms and privacy, and updated our combined with policy. Any match returns true. The branch that consumes this match sits in the query error handler at line 2918, ahead of all three auth-error branches. That ordering is deliberate, because every one of those downstream branches would otherwise mis-triage the error into a re-auth flow.

Because Anthropic does not ship a machine-readable error_type for terms-not-accepted. The detection has to be text-based. The four patterns cover the phrasings Fazm has actually seen on the wire from the Claude API, the claude.ai OAuth gateway, and the ACP SDK's error translation layer. Consumer terms is the most common phrasing when a Pro user hits a refreshed TOS page. Terms of service plus accept catches the more formal phrasing used in some 400 bodies. Terms and privacy covers the case where Anthropic combines the two documents in the message. Updated our plus policy catches policy-only refreshes that do not mention terms at all. Four patterns in one six-line function.

Three reasons. First, user experience: an OAuth loop with no explanation is the exact shape of an app that looks broken. The user does not know what to fix, so they quit and complain. Second, rate limits: Anthropic's OAuth callback endpoint is itself rate-limited, and repeated sign-in attempts from the same client IP in a short window can trip that limit, which makes recovery slower once the user does accept the terms. Third, cached tokens: some client libraries refresh the token preemptively on 400, which means the retry path actively throws away a valid token in exchange for nothing. Showing the verbatim message is cheaper and correct.

It affects both, but for different reasons. Users on Fazm's built-in account are signed in as a Fazm-managed Vertex AI identity, not as themselves. They still occasionally see a 400 from Claude if Anthropic refreshes the Vertex AI enterprise terms, which is why the detector is also wired into the built-in branch. Users on their own Claude Pro or Max account see it whenever claude.ai ships a TOS update and their OAuth session has not been re-consented yet. The detector fires in both modes and the error is surfaced the same way: verbatim text, no retry, no bridge-mode switch.

The query error handler between lines 2918 and 2958 has exactly five branches. First, terms acceptance required: show verbatim. Second, built-in auth failure: switch bridge mode to personal, trigger sign-in. Third, personal OAuth auth failure: trigger re-sign-in in place. Fourth, personal mode model access error: switch to built-in and auto-retry the query. Fifth, generic fallback: show the localized error description. Each branch is a specific signal that came out of a real production incident. The terms branch is the only one that actively refuses to retry.

Because the April 2026 cycle was the first time Anthropic pushed a consumer terms refresh on the same weekend as a GA model launch. Prior terms updates landed on quiet days and did not pile up with a traffic spike. When Opus 4.7 went GA on April 22 and a noticeable fraction of users signed in for the first time in weeks, the OAuth gateway started returning terms-not-accepted 400s at a rate that was not small. Fazm's Sentry clustered the errors under auth-failure for a day, which is how the bug was found, and the detector was added in the 2.4.1 release that shipped the same day.

Nothing in the Fazm client needs to change. The next query goes out on the already-valid OAuth token, claude.ai sees that consent has been recorded against the user account, the 400 no longer fires, and the agent responds normally. There is no in-app prompt to reload or re-sign-in because none is needed. That is the whole reason this branch is a dead-end instead of a retry: the fix is on the Anthropic side, not in the client.

Every client that embeds Claude needs an equivalent branch. The specific substrings are specific to the phrasings Fazm has seen, but the pattern is universal: any time an upstream API returns a 400 that the user has to resolve out of band (in a browser, on a billing page, at a terms screen), the client cannot paper over it with a retry. The cheapest correct behavior is to detect the class, show the text, stop the loop. If you are building on the Anthropic API and you do not have a branch like this, your next policy refresh will put your users into an OAuth loop until you ship a fix.