Skip to content

"Extra usage is required for long context requests" error still occurs after Anthropic removed long-context premium (March 13) #18242

Closed as not planned

Description

@coolbossov

Description

OpenCode shows "Extra usage is required for long context requests. retrying in Xs - attempt #N" and enters an infinite retry loop during long sessions. This error appears to be a stale handler for a restriction that Anthropic officially removed on March 13, 2026.

Anthropic's announcement (1M context GA, March 13 2026) explicitly states:

Full rate limits at every context length. Your standard account throughput applies across the entire window. No long-context premium. Claude Opus 4.6 and Sonnet 4.6 now include the full 1M context window at standard pricing.

Environment

  • OpenCode version: 1.2.27
  • Provider: Anthropic (Claude Max — OAuth, not API key)
  • Model: `anthropic/claude-sonnet-4-6`
  • Context at time of error: ~313,655 tokens (31% of 1M limit)
  • Platform: macOS

What happened

After ~20 minutes of a coding session, OpenCode displayed:

Extra usage is required for long context requests.
retrying in 3387s - attempt #14

The session was stuck retrying with a ~56 minute delay between attempts, making it completely unusable. The session had to be abandoned.

What should happen

With the long-context premium removed by Anthropic on March 13, this error should no longer occur. OpenCode should either:

  1. Remove or update the handler for this specific error code/message, or
  2. Fail gracefully with a clear message rather than an infinite retry loop with 3000+ second delays

Context panel at time of error

  • Context Limit: 1,000,000
  • Total Tokens: 313,655
  • Cache Tokens (read/write): 313,091 / 349
  • Usage: 31%
  • Messages: 200 (190 assistant, 10 user)

Additional notes

The retry interval of 3387 seconds (56 minutes) and attempt #14 suggest this had been retrying silently for an extended period before surfacing in the UI. The retry behavior itself may also warrant review — exponential backoff with this ceiling is not user-friendly for what should now be a non-existent restriction.

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Mar 19, 2026
  2. coolbossov commented on Mar 19, 2026

    @coolbossov
    Author

    Additional findings after source code review + further testing

    1. The error is intermittent, not threshold-based

    A subsequent session reached 450,743 tokens (45% of 1M) on the same model/provider with no error. This confirms the error is not triggered by a fixed token count — it appears to be an Anthropic-side capacity issue for Claude Max OAuth requests that only surfaces occasionally.

    2. Root cause identified in retry.ts

    Two bugs compound the problem:

    • No cap on retry-after header values — delay() in retry.ts directly passes the retry-after header value from Anthropic with no maximum cap. When Anthropic returns retry-after: 3387, OpenCode waits 56 minutes per attempt with no bound.

    • "Extra usage required" treated as indefinitely retryable — retryable() returns the message string for any retryable API error, causing the while loop in processor.ts to retry forever. There is no escape hatch for this specific error type.

    Suggested fix in packages/opencode/src/session/retry.ts:

    // 1. Cap retry-after header at RETRY_MAX_DELAY_NO_HEADERS (30s)
    return Math.min(Math.ceil(parsedSeconds * 1000), RETRY_MAX_DELAY_NO_HEADERS)
    
    // 2. Treat "Extra usage is required" as non-retryable
    if (error.data.responseBody?.includes("Extra usage is required") ||
        error.data.message?.includes("Extra usage is required"))
      return undefined

    3. Tool calls dominate context in active sessions

    Context breakdown at 450K: Tool Calls 87.5%, Other 12.5%. The system prompt baseline (~132K) is not the primary growth driver — accumulated tool outputs are. This is relevant context for the compaction/prune behavior as well.

  3. davetha commented on Mar 19, 2026

    @davetha

    Root Cause Found: [email protected] sends a header Anthropic rejects for OAuth

    After extensive debugging, I found the actual cause. It's not a stale retry handler or a context-length issue — it's the deprecated builtin plugin [email protected] injecting context-1m-2025-08-07 into the anthropic-beta header, which Anthropic actively rejects for OAuth tokens.

    The Problem

    The published [email protected] (deprecated on npm, maintained by thdxr) hardcodes these required betas:

    // node_modules/opencode-anthropic-auth/index.mjs
    const requiredBetas = [
      "claude-code-20250219",
      "oauth-2025-04-20",
      "context-1m-2025-08-07",    // ← THIS CAUSES THE ERROR
      "interleaved-thinking-2025-05-14",
      "prompt-caching-scope-2026-01-05",
    ];

    Anthropic's API rejects context-1m-2025-08-07 when sent with an OAuth Bearer token — returning the "Extra usage is required for long context requests" error. This happens on every request, regardless of actual context size. Even a brand new session with <10K tokens gets rejected.

    Despite the March 13 GA announcement saying "no beta header required," the reality is:

    • Without context-1m-2025-08-07: OAuth requests work fine, and 1M context works automatically (tested at 281K tokens with Sonnet 4.6)
    • With context-1m-2025-08-07: OAuth requests are rejected at any context size

    The Fix

    Remove context-1m-2025-08-07 from the plugin's requiredBetas array. The header is not needed post-GA and actively breaks OAuth authentication.

    Patch for ~/.cache/opencode/node_modules/opencode-anthropic-auth/index.mjs:

                  const requiredBetas = [
                    "claude-code-20250219",
                    "oauth-2025-04-20",
    -               "context-1m-2025-08-07",
                    "interleaved-thinking-2025-05-14",
                    "prompt-caching-scope-2026-01-05",
                  ];

    After this change, both short and long-context requests work correctly through OAuth. Successfully tested at 281K tokens with anthropic/claude-sonnet-4-6 on a Max plan.

    Note: The fix needs to be re-applied any time the plugin is re-downloaded (cache clear, reinstall, etc.) since the npm package itself ships with the broken header.

    Additional Context

    • The binary's CUSTOM_LOADERS["anthropic"] headers are irrelevant — the opencode-anthropic-auth plugin's chat.headers hook overwrites them entirely
    • The plugin is marked as DEPRECATED on npm — unclear if it's being maintained or if auth was supposed to be internalized into the OpenCode binary
    • This also affects the retry behavior from the original issue: the infinite retry loop with 3387s delays is because OpenCode's retry.ts treats the 429 response as retryable and honors Anthropic's retry-after header. But the real fix is preventing the rejection in the first place.
    • Related: PR feat(provider): add adaptive thinking and 1M context support for Claude Opus 4.6 #12342 (open since Feb 5) attempted to fix this but its forked auth plugin actually strips context-1m — same conclusion we reached independently

    Verification

    # Before fix: fails immediately on any Anthropic request
    opencode run -m anthropic/claude-sonnet-4-6 "say hello"
    # → "Extra usage is required for long context requests"
    
    # After fix: works, including >200K token requests  
    opencode run -m anthropic/claude-sonnet-4-6 "count fox" -f large-file.txt  
    # → 25000 (281K tokens, no error)
  4. rawscripter commented on Mar 19, 2026

    @rawscripter

    @davetha it worked.

  5. vinzabe commented on Apr 10, 2026

    @vinzabe
  6. SirBrenton commented on Apr 10, 2026

    @SirBrenton

    This looks like two independent issues getting collapsed into one failure mode.

    1) Root cause (request rejection)
    The OAuth + context-1m-2025-08-07 header mismatch is causing the request to be rejected upstream. That part seems correctly identified above.

    2) Execution behavior (retry loop)
    What’s interesting is how the system responds after that rejection:

    • retry-after: 3387 is treated as fully authoritative
    • the error is considered indefinitely retryable
    • no cap on delay
    • no escape condition

    So the system ends up doing:

    429-like response → retry → wait 56 min → retry → repeat
    

    At that point it’s no longer a retry strategy — it’s a stalled execution loop.


    What’s missing is a classification step before retry

    Right now the system effectively treats all 429-like responses as:

    retry()
    

    But in practice these tend to fall into different buckets:

    • transient pressure → retry after delay
    • concurrency overshoot → reduce pressure before retry
    • quota / invalid request / long-window rejection → do not retry

    This case looks closer to the last category once the header mismatch is present.


    Concrete improvements (independent of root fix):

    • cap retry-after (e.g. 30–60s max inside a single execution)
    • introduce a non-retryable classification for this error string
    • add a max attempts / max elapsed guardrail
    • optionally treat very large retry-after values as terminal for the current run

    Fixing the header removes the trigger, but without these guards the same pattern can reappear with other provider responses.

  7. xNarkon commented on Apr 19, 2026

    @xNarkon

    Any update?

  8. removed
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  9. github-actions commented on Jul 3, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions