Sign up
View stargazersSign up

[Bug]: Claude via OpenCode loses usage-limit classification and reset time#29289

opened8d agobyUunsync

Before submitting

  • I searched existing issues and did not find a duplicate.
  • I included enough detail to reproduce or investigate the problem.

Area

apps/server

Summary

When Claude's weekly subscription allowance is exhausted, OpenCode's built-in claude-agent provider returns provider.unknown with an explicit ISO reset timestamp in the message. T3's OpenCode adapter maps that error to provider_error and omits resetAt, preventing the failure from using the existing reset-based snooze/resume path.

This report is limited to Claude Code login through OpenCode. ChatGPT through OpenCode is already tracked separately in #26265 / #26264.

Steps to reproduce

Prerequisite: an existing Claude Code login whose weekly subscription allowance is already exhausted.

The provider failure was reproduced live with:

sh
1opencode run --format json --model claude-agent/haiku \
2 "Reply only QUOTA_PROBE_OK. Do not call tools, read files, delegate work, or make changes."

To verify the corresponding T3 behavior, send a minimal prompt in a T3 thread using OpenCode with claude-agent/haiku, then inspect the failure classification and reset-based actions. This T3 runtime check remains pending; the adapter behavior below is established by source inspection.

Expected behavior

Recognize the quota stop as usage_limit and preserve the reported reset as resetAt, so T3 can offer its existing Snooze until reset and Resume at reset actions and schedule recovery when enabled.

No reset time should be guessed when Claude does not provide one.

Actual behavior and evidence

A real minimal request on 2 November 2026 at 12:38 Europe/Paris failed with exit code 1 and this OpenCode error:

json
1{
2 "type": "provider.unknown",
3 "message": "You've hit your weekly limit · resets 9pm (Europe/Paris) Resets at 2026-11-02T20:00:00.000Z."
4}

The error contained only type and message: no HTTP status, response body, structured reset field, or retry delay. The timestamp corresponds to 2 November at 21:00 Europe/Paris.

In packages/provider-opencode/src/server/v2/adapter.ts, session.execution.failed:

  • Only provider.quota (except HTTP 402) and provider.rate-limit become usage_limit; this provider.unknown failure becomes provider_error.
  • The adapter constructs the failure without passing resetAt, despite the explicit timestamp in the message.

Impact

Affected failures cannot use reset-based recovery and require manual continuation after the allowance resets. The requested behavior is to wait for the reported reset, not bypass the quota.

Versions and environment

  • macOS; T3 Code desktop 0.1.6, installed via Homebrew cask t3-code (confirmed by Homebrew and app metadata).
  • OpenCode 2.2.5, running as a local service.
  • Claude Code 2.1.316; built-in OpenCode provider claude-agent, model claude-agent/haiku.
  • External Claude Code login, not a direct Anthropic API-key connection or OpenCode Go.

Latest-source check

On 2 November 2026, the same classification and missing resetAt forwarding were confirmed in source at:

  • Installed release v0.1.6.
  • Latest published nightly v0.1.7-nightly.20261102.4066.
  • Current main, commit 47f2c8d29e981c7723467efe137ee19e91df924e (linked above).

The nightly was source-inspected, not installed or runtime-tested.

  • #26265 / open PR #26264 cover ChatGPT-backed OpenCode models: a typed quota failure with the reset in response.body. This Claude case additionally needs quota classification, and its reset is in the message. This report does not request expanding that PR's scope.
  • #16366 / merged #18315 established usage-limit classification for OpenCode's typed quota/rate-limit failures. This Claude bridge failure does not use those types.

Direction before contributing

Would a narrowly scoped T3 adapter fix recognizing this claude-agent quota failure and its explicit ISO reset timestamp be acceptable, or should this wait for structured quota/reset metadata from OpenCode?

The proposed scope is only this Claude failure: validate the explicit timestamp, preserve unrelated errors and billing failures, and add regression coverage using the captured payload. No new settings, scheduler, plugin, or account-usage probing is proposed. No PR has been opened.

Workaround

Check Claude's reported reset time and manually resume the thread afterward.