PROBLEM — A coding_loop_start run against this instance failed immediately with: "UserAiProviderError: Anthropic (400): Your credit balance is too low to access the Anthropic API." There was no way to see this coming: billing_status returned {active:false, status:"none", hasBillingAccount:false} — correctly showing no PAGS-side billing issue, because this is an Anthropic-account-level credit balance, not a PAGS billing state. Nothing in coding_diagnostics or coding_loop_status surfaced it either; the only signal was the run dying.
EXPLICIT NON-GOAL — Do NOT add a balance check before every dispatch or every action. This is a rare failure mode and a pre-flight check on every call would be wasted latency/cost for something that almost never happens. The ask is purely for VISIBILITY on demand and clearer failure reporting, not a gate.
PROPOSAL — 1) Add a way to check current provider credit health on demand (e.g. via coding_diagnostics or a small dedicated read), so a caller CAN check when they suspect something's wrong, without it being mandatory. 2) When a run does fail for this specific reason, make the stop reason unambiguous and distinguishable from other provider errors, so the caller (human or orchestrator) immediately understands "top up credits" is the fix, rather than treating it like a generic transient failure worth retrying.
CONTEXT — This surfaced mid-session while triaging a red production deploy on ProAgentStore/platform main; the fix-forward run could not even start because of this, and only became diagnosable by manually re-running coding_loop_status and reading the raw error text.
PROBLEM — A coding_loop_start run against this instance failed immediately with: "UserAiProviderError: Anthropic (400): Your credit balance is too low to access the Anthropic API." There was no way to see this coming: billing_status returned {active:false, status:"none", hasBillingAccount:false} — correctly showing no PAGS-side billing issue, because this is an Anthropic-account-level credit balance, not a PAGS billing state. Nothing in coding_diagnostics or coding_loop_status surfaced it either; the only signal was the run dying.
EXPLICIT NON-GOAL — Do NOT add a balance check before every dispatch or every action. This is a rare failure mode and a pre-flight check on every call would be wasted latency/cost for something that almost never happens. The ask is purely for VISIBILITY on demand and clearer failure reporting, not a gate.
PROPOSAL — 1) Add a way to check current provider credit health on demand (e.g. via coding_diagnostics or a small dedicated read), so a caller CAN check when they suspect something's wrong, without it being mandatory. 2) When a run does fail for this specific reason, make the stop reason unambiguous and distinguishable from other provider errors, so the caller (human or orchestrator) immediately understands "top up credits" is the fix, rather than treating it like a generic transient failure worth retrying.
CONTEXT — This surfaced mid-session while triaging a red production deploy on ProAgentStore/platform main; the fix-forward run could not even start because of this, and only became diagnosable by manually re-running coding_loop_status and reading the raw error text.