Anthropic just metered the Agent SDK. Credit exhaustion is now a real failure mode.

Six failure modes that emerge once credit becomes the binding constraint instead of rate limits. Severity reflects how reachable each becomes in typical agent deployments.

1. 01 HIGH

   Credit exhaustion as a denial-of-service surface

   If an attacker controls input that drives an agent loop — adversarial user content, prompt-injection payloads, recursive tool calls — they can spike token consumption and drain the Agent SDK credit pool. Once drained, your agents are offline until next month or until you buy emergency credit. This is a new DoS surface that did not exist when chat + programmatic usage shared the same elastic pool.

   DO Add per-loop, per-user, and per-tenant credit-consumption budgets. Alert on anomalous consumption rates before the pool drains. Treat credit-burn rate the same way you treat any other resource-exhaustion metric.
2. 02 HIGH

   Cost runaway in autonomous agents

   Long-horizon agent loops — multi-step research, recursive tool calls, multi-agent collaboration — produce highly variable token consumption. Without explicit budget instrumentation, a single bug or prompt-injection event can consume an entire month of credits in hours. Production cost predictability now requires what production resource management requires.

   DO Instrument expected vs actual token consumption per agent task. Set hard ceilings per loop and per session. Default to failing closed (stopping the loop) rather than failing open (continuing to consume) when the budget is exceeded.
3. 03 MEDIUM

   Fallback path planning gets more complex

   Existing fallback paths watch for HTTP 429 (rate limited) and back off. Credit-exhaustion errors are a different signal — they will not resolve with backoff alone. Your fallback code needs to distinguish 'rate-limited, retry in 60 seconds' from 'credit exhausted, escalate' and route appropriately.

   DO Update agent SDK error-handling code to recognize credit-exhaustion responses distinctly. Route them to a human escalation path or a non-Claude fallback model, not to a retry loop.
4. 04 MEDIUM

   Team plan billing may not match security boundary

   Team Standard provides $20/seat and Team Premium $100/seat. If your security boundary differs from your team-plan boundary (e.g., one team plan covers multiple security tenants), the credit pool is shared in ways that may not be visible to consumers. A compromised tenant can affect availability for the whole team.

   DO Audit whether your team-plan boundary matches your tenancy boundary. If not, consider separate team plans per security tenant, or migrate to direct API access where credit boundaries can be explicitly drawn.
5. 05 MEDIUM

   Third-party agent frameworks consume from the same pool

   Cursor, Continue, Zed, Aider, and other third-party tools that use the Agent SDK or claude -p draw from your subscription credit pool. If you run multiple tools concurrently, their consumption competes for the same monthly budget. A developer running Cursor in autopilot can drain credits that the production agent stack depends on.

   DO Inventory every place programmatic Claude consumption happens in your organization. Assign a budget per consumer. Consider separating production agent loops onto direct API keys with dedicated budgets, away from the shared subscription pool.
6. 06 MEDIUM

   No-rollover policy concentrates failure modes

   Unused credits expire monthly. Failed automations (errors that caused you to under-consume one month) do not amortize against the next month. The accounting is symmetric in both directions — you cannot smooth consumption across the cycle.

   DO Plan for tight credit-cycle alignment. If your usage is bursty (e.g., end-of-month batch jobs), the no-rollover policy makes that worse. Consider pre-buying extra credit to absorb spikes rather than relying on month-over-month carryover.