OpenClaw merged PR #151377, a provider-runtime fix that stops deterministic HTTP 402 budget failures from being retried as if they were transient rate limits.
The bug came from a subtle classifier interaction. A billing help URL could contain organization or workspace wording, while the actual error text said the prompt or output token limit was exceeded. The shared 402 classifier combined those signals and treated the result like a rate-limit condition.
The User Impact
Before the fix, OpenClaw could spend retry budget on a request that was never going to succeed without billing or quota action. That is noisy for users and wasteful for runtimes.
After the fix, budget failures reach the normal billing handling path immediately. Genuine HTTP 429 recovery is unchanged, so temporary rate limits can still take the retry path that users expect.
This is a small distinction with a big quality-of-life effect. A deterministic billing error should tell the operator what to fix. It should not look like a flaky provider or sit through a sequence of doomed retries.
What Changed In Classification
The PR excludes HTTP and HTTPS URLs from the text used for 402 classification while preserving the raw provider error. That means a URL such as an account, organization, or workspace settings link can still be shown to the user, but its path components do not pollute the classifier's interpretation of the actual failure.
No configuration, schema, protocol, retry-budget, cache, or stored-state changes are required.
The result is more faithful handling:
- HTTP 402 prompt-budget failures become billing errors without same-model retries
- HTTP 402 output-budget failures follow the same billing path
- Temporary HTTP 429 responses still use retry recovery
- Raw provider details remain available for the final error
Evidence From The PR
The PR includes transport-backed synthetic proof using pnpm openclaw agent exec against a local provider endpoint, not a paid live request. The fixed prompt-budget and output-budget 402 cases each made one HTTP request, produced zero retry decisions, and ended as billing errors.
The 429 control case still retried once and then completed with a synthetic success response. Focused tests and generated protocol checks passed, and the PR reports 832 focused tests plus cleanup coverage for affected fixtures.
That evidence is useful because provider error handling often sits between product code and external services. Testing it against a synthetic transport path gives better confidence than only testing a helper function.
Why This Kind Of Fix Matters
Provider integrations are full of messy boundary cases: account limits, daily limits, workspace limits, malformed payloads, temporary throttles, and genuine billing exhaustion can all look similar at first glance.
OpenClaw's job is not just to retry. It is to retry when retrying is rational, stop when the operator needs to act, and preserve enough error detail that the next step is obvious.
PR #151377 is a clean example of that philosophy. It makes the failure less dramatic, which is exactly what good runtime plumbing should do.