Problem
The regex /too many tokens/i in OVERFLOW_PATTERNS (packages/opencode/src/provider/error.ts, line 22) is too broad. It matches rate limit / daily quota errors that contain "too many tokens" but are not context overflow errors.
Example: AWS Bedrock returns this when the daily token quota is exhausted:
Too many tokens per day, please wait before trying again.
This matches /too many tokens/i → classified as ContextOverflowError → triggers compaction → compaction also fails (same quota error) → user is stuck. The error never reaches the retry loop or plugin event hooks (session.status with type: "retry").
Cerebras has the same issue: "Tokens per minute limit exceeded - too many tokens processed" (see #7463).
Expected Behavior
Daily/minute token quota errors should be classified as retryable API errors (or at least non-overflow errors), so that:
- The retry loop can handle them with backoff
- Plugins listening for
session.status retry events can trigger fallback logic
- Compaction is NOT triggered (context size isn't the problem)
Root Cause
The classification chain:
ProviderError.parseAPICallError() calls isOverflow(message)
isOverflow() checks OVERFLOW_PATTERNS — /too many tokens/i matches
- Returns
{ type: "context_overflow" } → becomes ContextOverflowError
SessionRetry.retryable() line 63: ContextOverflowError.isInstance(error) → returns undefined (not retryable)
SessionProcessor.process() sets error on message, emits session.error, never emits session.status with type: "retry"
- Processor returns
"compact" → compaction triggered on a quota error
Suggested Fix
Make the regex exclude temporal qualifiers:
// Before
/too many tokens/i, // Generic fallback
// After — exclude "per day", "per minute", "per hour", "processed"
/too many tokens(?! per (day|minute|hour|second))(?! processed)/i,
Or add a pre-check for rate limit patterns before checking overflow patterns, since rate limits should take priority.
Affected Error Messages
| Error Message |
Source |
Should Be |
| "Too many tokens per day, please wait before trying again." |
AWS Bedrock |
Rate limit (retryable) |
| "Tokens per minute limit exceeded - too many tokens processed" |
Cerebras |
Rate limit (retryable) |
| "prompt is too long: 285744 tokens > 200000 maximum" |
Anthropic/Bedrock |
Context overflow ✅ (correct) |
Environment
- OpenCode version: 1.1.53+
- Provider: amazon-bedrock (Claude Opus 4.6)
- OS: macOS
Related Issues
Problem
The regex
/too many tokens/iinOVERFLOW_PATTERNS(packages/opencode/src/provider/error.ts, line 22) is too broad. It matches rate limit / daily quota errors that contain "too many tokens" but are not context overflow errors.Example: AWS Bedrock returns this when the daily token quota is exhausted:
This matches
/too many tokens/i→ classified asContextOverflowError→ triggers compaction → compaction also fails (same quota error) → user is stuck. The error never reaches the retry loop or plugin event hooks (session.statuswithtype: "retry").Cerebras has the same issue: "Tokens per minute limit exceeded - too many tokens processed" (see #7463).
Expected Behavior
Daily/minute token quota errors should be classified as retryable API errors (or at least non-overflow errors), so that:
session.statusretryevents can trigger fallback logicRoot Cause
The classification chain:
ProviderError.parseAPICallError()callsisOverflow(message)isOverflow()checksOVERFLOW_PATTERNS—/too many tokens/imatches{ type: "context_overflow" }→ becomesContextOverflowErrorSessionRetry.retryable()line 63:ContextOverflowError.isInstance(error)→ returnsundefined(not retryable)SessionProcessor.process()sets error on message, emitssession.error, never emitssession.statuswithtype: "retry""compact"→ compaction triggered on a quota errorSuggested Fix
Make the regex exclude temporal qualifiers:
Or add a pre-check for rate limit patterns before checking overflow patterns, since rate limits should take priority.
Affected Error Messages
Environment
Related Issues
context-1m-2025-08-07not sent for Claude Opus 4.6, causing 200k hard limit #12507 — Beta header not sent for Opus 4.6 (separate issue causing 200K limit)