bug: OAuth auth + cache_control ephemeral causes HTTP 400 on all Claude models since 2026-03-17

[cyberprophet]

Description

All Claude models fail with HTTP 400 when using OAuth authentication (Claude subscription). The error started on 2026-03-17 with no configuration changes. Non-Anthropic models (e.g., GPT-5-nano) work fine.

Root Cause

OpenCode's bundled @ai-sdk/anthropic unconditionally injects cache_control: {"type": "ephemeral"} into system message blocks. This prompt caching metadata appears to no longer be accepted on the OAuth authentication path (Claude subscription). Previously, the Anthropic API silently ignored this field for OAuth requests; as of 2026-03-17, it returns HTTP 400.

Evidence from request body

{
  "model": "claude-sonnet-4-6",
  "max_tokens": 32000,
  "stream": true,
  "system": [
    { "type": "text", "text": "...", "cache_control": { "type": "ephemeral" } },
    { "type": "text", "text": "...", "cache_control": { "type": "ephemeral" } },
    { "type": "text", "text": "..." },
    { "type": "text", "text": "..." }
  ]
}

• No thinking parameter is present — this is not a thinking/extended-thinking issue.
• The API response is {"type":"error","error":{"type":"invalid_request_error","message":"Error"}} with status 400.

Confirmed: not a version-specific regression

Tested on both v1.2.27 and v1.2.26 — same error. The cache_control: {"type": "ephemeral"} injection is hardcoded in the bundled @ai-sdk/anthropic (applyCaching()), so downgrading does not help.

Steps to Reproduce

1. Authenticate via OAuth (opencode providers login anthropic)
2. Run opencode run "say hello" --model anthropic/claude-sonnet-4-6
3. → HTTP 400 invalid_request_error

Works fine with API key authentication or non-Anthropic providers.

Expected Fix

When the authentication method is OAuth (Claude subscription), strip cache_control from system blocks before sending to the Anthropic API. Prompt caching is an API-tier feature and should not be applied to OAuth-authenticated requests.

Related

• [Question]: How does oh-my-opencode map the 'max' variant for native Anthropic provider models like claude-opus-4-6? code-yeongyu/oh-my-openagent#2630 — Same breakage reported on 2026-03-17, "was working on 2026-03-16, broke on 2026-03-17 with no config changes"
• bug: Claude Sonnet 4.5 with thinking + ephemeral cache returns HTTP 400 #17883 — Previously filed as thinking + ephemeral conflict, but the actual root cause is OAuth + ephemeral
• feat(provider): add adaptive thinking and 1M context support for Claude Opus 4.6 #12342 — Pending @ai-sdk/anthropic v2→v3 upgrade PR

Environment

• OpenCode: v1.2.26, v1.2.27 (both affected)
• Auth: OAuth (Claude subscription)
• OS: Linux (WSL2)

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Broken Claude Max #7410: Broken Claude Max — an existing open issue tracking Claude OAuth/subscription failures that may cover the same breakage

If this is a distinct root cause (specifically the cache_control: ephemeral injection being newly rejected on the OAuth path), it may warrant staying open as a separate, more precise bug report. Please check #7410 to confirm.

[cyberprophet]

Difference from #7410

#7410 is about Anthropic blocking non-Claude Code clients via system prompt pattern matching (e.g., rejecting requests that contain "opencode" in the system message). The workaround there is injecting "You are Claude Code" into the system prompt.

This issue is mechanistically different:

	#7410	#17910
Root cause	System prompt content triggers client identity check	cache_control: {"type": "ephemeral"} in system blocks triggers invalid_request_error
Error pattern	Credential authorization error ("only for Claude Code")	Generic HTTP 400 invalid_request_error with "message": "Error"
Workaround	Inject "You are Claude Code" into system prompt	Unknown — cache_control is hardcoded in applyCaching()
Affected scope	OAuth users without opencode-anthropic-auth	OAuth users with opencode-anthropic-auth@0.0.13 already installed and working
Timing	Recurring since Jan 2026	Started specifically on 2026-03-17 (worked on 2026-03-16)

Key evidence

1. opencode-anthropic-auth is active and has been working — the system prompt already contains "You are Claude Code". This is not a client identity rejection.
2. The request body shows no thinking parameter — this rules out the thinking/ephemeral conflict described in bug: Claude Sonnet 4.5 with thinking + ephemeral cache returns HTTP 400 #17883.
3. The only anomaly in the request is cache_control: {"type": "ephemeral"} on system blocks, which is injected by the bundled @ai-sdk/anthropic's applyCaching() and cannot be disabled by plugins.
4. Same breakage reported independently at [Question]: How does oh-my-opencode map the 'max' variant for native Anthropic provider models like claude-opus-4-6? code-yeongyu/oh-my-openagent#2630 with identical timing (2026-03-16 OK → 2026-03-17 broken, no config change).

It's possible that Anthropic expanded their OAuth restrictions to reject cache_control (prompt caching is an API-tier feature). But the mechanism and fix path are different from #7410.

[cyberprophet]

Investigation Update: Root cause is not cache_control

After building from source with a fix that strips cache_control from OAuth requests, the ephemeral metadata was successfully removed from the request body — confirmed via logs. However, the API still returns HTTP 400.

Direct API testing

Tested the Anthropic API directly with the stored OAuth access token:

With Authorization: Bearer header:

HTTP 401 — {"type":"error","error":{"type":"authentication_error","message":"OAuth authentication is currently not supported."}}

With x-api-key header (how @ai-sdk/anthropic actually sends it):

HTTP 400 — {"type":"error","error":{"type":"invalid_request_error","message":"Error"}}

Both paths fail even with a minimal request (model + max_tokens + single user message, no cache_control, no thinking, no tools).

Conclusion

The root cause is not cache_control: {"type": "ephemeral"}. The Anthropic API appears to have dropped OAuth token support as of 2026-03-17. The vague "message":"Error" response on the x-api-key path is because an OAuth token is not a valid API key.

This may be an intentional change on Anthropic's side, or a regression in their OAuth infrastructure. Either way, the fix needs to come from the Anthropic API or from how OpenCode's plugin auth layer handles OAuth tokens for the Anthropic provider.

Environment

• Tested on: OpenCode built from source (dev branch + cache_control fix)
• Auth: OAuth (type: "oauth" in auth.json)
• Token: valid, not expired

[HCPTangHY]

Xerxes-2/clewdr@a4e5df3

This commit fixed this issue. To put it simply, Anthropic added some new checks for the user-agent and salt values.

[R00tedbrain]

@HCPTangHY how fix now ? my error?