Anthropic quota fetch broken — /api/oauth/usage now returns an array for a bucket value (cannot unmarshal array into AnthropicQuotaEntry)

[olaxe]

Summary

Since 2026-06-16 ~18:05 UTC, every Anthropic quota poll fails to decode. The Anthropic agent goes healthy=0 and quota tracking stops. Auth is fine — the OAuth token refreshes normally; this is purely a response-schema decode failure.

Error (every poll, ~10 min interval, continuous)

level=ERROR msg="Failed to fetch Anthropic quotas" \
  error="anthropic: invalid response: json: cannot unmarshal array into Go value of type api.AnthropicQuotaEntry"

A daemon restart does not help — it re-fails on the first poll after boot.

Versions affected

• Reproduced on v2.12.0.
• Type is unchanged through v2.12.5 (latest) and main → all current versions are affected. (v2.12.1–v2.12.5 changelogs touch Codex/Antigravity/self-update, nothing on the Anthropic quota schema.)

Root cause

AnthropicClient.FetchQuotas (internal/api/anthropic_client.go) GETs https://api.anthropic.com/api/oauth/usage and decodes into:

// internal/api/anthropic_types.go:21
type AnthropicQuotaResponse map[string]*AnthropicQuotaEntry

// internal/api/anthropic_client.go (~line 156)
var quotaResp AnthropicQuotaResponse
if err := json.Unmarshal(body, &quotaResp); err != nil { ... }   // <-- fails here

The error is cannot unmarshal array into AnthropicQuotaEntry (not into map), so the top-level object is intact, but at least one bucket value, which the code expects to be a single AnthropicQuotaEntry object, is now a JSON array (Anthropic appears to have split a window into per-model entries, e.g. seven_day → [ {…}, {…} ]). Because the whole map is unmarshalled in one pass, a single array-valued key fails the entire decode → all quota data is lost, not just the affected bucket.

Request used (for repro)

GET https://api.anthropic.com/api/oauth/usage
Authorization: Bearer <oauth-access-token>
Content-Type: application/json
anthropic-beta: oauth-2025-04-20
User-Agent: claude-code/2.1.69

Inspect the response: one of the top-level keys now holds [ … ] instead of { … }.

Impact

Anthropic quota tracking is fully down for OAuth/subscription users since the API change. Anything gating on onwatch_agent_healthy / quota metrics fails closed.

Suggested fix

Make the per-bucket value tolerate both shapes. Minimal approach — a wrapper type with a custom UnmarshalJSON that accepts a single object or an array of AnthropicQuotaEntry:

type quotaBucket []*AnthropicQuotaEntry   // always a slice internally

func (b *quotaBucket) UnmarshalJSON(data []byte) error {
    trimmed := bytes.TrimSpace(data)
    if len(trimmed) > 0 && trimmed[0] == '[' {
        var arr []*AnthropicQuotaEntry
        if err := json.Unmarshal(data, &arr); err != nil { return err }
        *b = arr
        return nil
    }
    var one AnthropicQuotaEntry
    if err := json.Unmarshal(data, &one); err != nil { return err }
    *b = []*AnthropicQuotaEntry{&one}
    return nil
}
// type AnthropicQuotaResponse map[string]quotaBucket

Then decide downstream semantics for multi-entry buckets (e.g. expand into per-model keys like seven_day_opus / seven_day_sonnet, or aggregate by max utilization). Happy to PR if useful.

[motonari728]

Still reproduces on v2.12.5 (Linux, OAuth auto-detect, token valid):

level=ERROR msg="Failed to fetch Anthropic quotas"
  error="anthropic: invalid response: json: cannot unmarshal array into Go value of type api.AnthropicQuotaEntry"

Anthropic polling is effectively dead: every anthropic_snapshots row in my DB is "_source":"statusline" — not one API-sourced snapshot has ever been written.

#90 fixes it. Applied on fcc8d27 (v2.12.5) and rebuilt: five_hour went from frozen at 1% to live (7% → 8%), seven_day 1%, resets_at correct for both windows, zero errors since. The live payload does contain the limits array plus experimental keys (amber_ladder, cinder_cove), and #90 skips them as intended.

"Statusline Only" is not a workaround, despite what the settings UI implies:

1. main.go — SetAPIPollCycleInterval(0) is applied for statusline mode, then immediately overwritten by the DB value on the next lines (default 10), so hybrid API polling still runs.
2. anthropic_agent.go poll() — the statusline branch is gated only on statuslinePath != "" && isStatuslineFresh(...), with no check on the configured source mode. Stale statusline always falls through to the API path.

(2) bites in practice because the bridge only fires when an interactive TUI renders a status line — headless usage (claude remote-control, SDK/--print) never refreshes it.

[prakersh]

Both issues here are now fixed and released. 🎉

1. The decode failure (the original bug) - fixed in #90 (thanks @yesme), shipped in v2.13.0. The per-bucket value now tolerates both the old object shape and the new array/metadata shape; the experimental keys (limits, amber_ladder, cinder_cove) are skipped as intended. Thanks @olaxe for the precise root-cause writeup.

2. @motonari728's "Statusline Only" finding - confirmed and fixed in v2.13.1. You were right: a stale or missing statusline file silently fell through to the usage API, so headless usage (--print/SDK/remote-control) kept polling despite the mode promising "no API polling". The agent now hard-stops before the API path in statusline mode. Great catch.

Both fixes are present in https://github.com/onllm-dev/onWatch/releases/tag/v2.13.1