[Bug]: OpenCode Go usage limit fails threads as a generic provider error: no reset time, no auto-resume, not exposed to orchestrator MCP tools#16366

Before submitting

• I searched existing issues and did not find a duplicate. (Related but different: #15665 covers Claude, where the usage-limit state and auto-resume exist but are inconsistent. This report is about OpenCode Go, where the limit is not recognised as a usage limit at all.)
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Configure the OpenCode provider with an OpenCode Go subscription and start several long-running threads on a Go model (here: 13 threads on opencode-go/deepseek-v4.1-flash, variant high, launched by an orchestrator thread through t3_thread_launch).
2. Let them run until the Go session window is exhausted.
3. Look at the affected threads, at Usage → Limits, and at what the orchestration MCP tools return for those threads.

Expected behavior

T3 already knows the answer: Usage → Limits shows Go · Session 0% left with a reset countdown, next to the weekly and monthly windows. So when a run dies on that limit I would expect:

• The run to end in a usage-limit state rather than a generic failure, carrying which window was exhausted (session / weekly / monthly) and when it resets.
• The same recovery affordances that exist for Claude usage limits (reset time in the banner, auto-resume / snooze until reset).
• The orchestration MCP surface to expose that information, so an orchestrating agent can decide between "wait for the reset and resume the same thread" and "hand over to a fallback provider". For example: a structured usageLimit { window, resetsAt } on the failed run / terminal item in t3_thread_read, and per-provider limit windows in orchestrator_capabilities (or a dedicated read tool).

Actual behavior

• All 13 threads failed within about 35 seconds of each other (2026-10-06 04:19:59Z – 04:20:34Z). t3_thread_list reports status: "failed"; the sidebar shows them as Failed.
• The terminal timeline item is type: "error", title: "Provider error", text: "Go usage limit exceeded". Nothing else: no window, no reset time, no retry-after.
• There was no auto-resume. After the reset the threads stay failed until something sends them a new message.
• At the same moment Usage → Limits showed Go · Session 0% left · resets in 1h 27m, Go · Weekly 60% left · 5d 19h, Go · Monthly 62% left · 20d 10h. So the reset time exists inside T3, but it is only reachable by a human opening that page.
• From the orchestrator thread I could not get it by any route: t3_thread_read (messages and activity views) only has the error text above; orchestrator_capabilities lists providers, models and options but no limits; t3_environment_read has none either. The OpenCode CLI (opencode stats, logs) does not print a reset time.

Practical consequence: the orchestrating agent cannot tell a 90-minute session window from a 5-day weekly window. Those need opposite reactions (wait vs. hand the work to another provider), so it has to stop and ask the user for a screenshot of the Limits page.

Impact

Major degradation or frequent failure

Version or commit

0.0.46-nightly.20261005.2702

Environment

Windows 11 x64, desktop app. OpenCode CLI v2.0.23, OpenCode Go subscription. Orchestrator thread on the Claude provider driving OpenCode threads through the t3-code MCP server.

Logs or stack traces

OpenCode service log, repeated once per failing session (paths trimmed):

The error class is AI.Error.QuotaExceeded, so the provider failure is at least distinguishable from other provider errors even if OpenCode itself does not include the reset time in it; T3 could join it with the limit windows it already fetches for the Usage page.