Symptom
The staleness digest's provider-health section showed provider unknown for the 2026-07-30 entries, even though the stored error was unmistakably Anthropic:
400 {"type":"error","error":{"type":"invalid_request_error","message":"You have reached your specified API usage limits. You will regain access on 2026-08-01 at 00:00 UTC."},"request_id":"req_011..."}
classifyProviderQuota's providerOf only checks a structured provider/providerId field (lost once the error is flattened to fetch_log.error text) and the words "anthropic|claude" in the message — which Anthropic's own quota message doesn't contain.
Fix ideas (either/both)
- Teach
providerOf the wire shapes: the {"type":"error","error":{"type":"invalid_request_error"...}} envelope with a req_-prefixed request_id is Anthropic's; "reached your specified API usage limits" is Anthropic-specific wording and could map directly in QUOTA_PATTERNS.
- Stamp the provider at classification time where the error is still a live object (callers of
classifyProviderQuota in the fetch path), and persist it alongside the error text.
Cosmetic-but-useful: the digest tells an operator which console to open.
Symptom
The staleness digest's provider-health section showed
provider unknownfor the 2026-07-30 entries, even though the stored error was unmistakably Anthropic:classifyProviderQuota'sproviderOfonly checks a structuredprovider/providerIdfield (lost once the error is flattened tofetch_log.errortext) and the words "anthropic|claude" in the message — which Anthropic's own quota message doesn't contain.Fix ideas (either/both)
providerOfthe wire shapes: the{"type":"error","error":{"type":"invalid_request_error"...}}envelope with areq_-prefixedrequest_idis Anthropic's; "reached your specified API usage limits" is Anthropic-specific wording and could map directly inQUOTA_PATTERNS.classifyProviderQuotain the fetch path), and persist it alongside the error text.Cosmetic-but-useful: the digest tells an operator which console to open.