[BUG] OpenRouter auto top-up ignored

[Quantum-Fracture-Studio]

Problem (one or two sentences)

You seem to have run out of funds/credits in your account. Go to your provider and add more to continue.Details
25s

Checked OpenRouter and the auto-top off has already added more credits. Plenty enough for the request.

Context (who is affected and when)

As soon as the low limit is hit - and does not need to be lower than the OpenRouter setting in monetary terms. No indication the token bucket was too low yet the funds were plenty - for OpenRouter to just sit there. Had to adjust the monetary limit.

Reproduction steps

Win 11, VSCode with Roo Module, OpenRouter API

Expected result

Requery the API endpoint for token bucket size instead of hitting it once and never checking again.

Actual result

Continually throws error no matter how many "new chats" are started.

Variations tried (optional)

No response

App Version

v3.51.1

API Provider (optional)

OpenRouter

Model Used (optional)

anthropic/claude-sonnet-4.5

Roo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[roomote-v0]

I've analyzed this issue and here's my proposed implementation plan:

Root Cause

When OpenRouter returns a 402 (Payment Required) error, the auto-retry logic in src/core/task/Task.ts (attemptApiRequest at ~line 4329) treats it the same as transient errors like 429 (rate limit) or 500 (server error). It retries indefinitely with exponential backoff, but a 402 is fundamentally different -- it requires user action (adding credits or adjusting the credit limit on OpenRouter), not just waiting.

The user reports that even after OpenRouter's auto-top-up replenished their credits, Roo Code kept showing the error. This is because the backoff grows exponentially (up to MAX_EXPONENTIAL_BACKOFF_SECONDS), so by the time the credits are available again, the user is stuck waiting through a long countdown timer -- or the retry loop never reaches the next attempt in a reasonable timeframe.

Proposed Fix

Treat 402 errors as non-retryable when auto-approval is enabled, similar to how context window errors already have special handling. Specifically:

1. In Task.ts attemptApiRequest() (~line 4310-4346): Add a check for 402 status code errors. When a 402 is detected, instead of entering the auto-retry loop with backoffAndAnnounce(), fall through to the manual api_req_failed ask path so the user gets a "Retry" button and can take action.

2. Generalize to other non-retryable errors: Also treat 401 (authentication) and 403 (unauthorized) the same way -- these are errors that require user configuration changes, not transient failures that will self-resolve.

The change would look roughly like this in attemptApiRequest():

// After the context window check at line 4326...

// Check if this is a non-retryable error that requires user action
const nonRetryableStatuses = [401, 402, 403]
const isNonRetryable = nonRetryableStatuses.includes((error as any)?.status)

if (autoApprovalEnabled && !isNonRetryable) {
    // Existing auto-retry with backoff logic...
    await this.backoffAndAnnounce(retryAttempt, error)
    // ...
} else {
    // Show api_req_failed with retry button (existing manual path)
    const { response } = await this.ask("api_req_failed", ...)
    // ...
}

3. Add tests to verify that 402, 401, and 403 errors bypass auto-retry and present the api_req_failed prompt instead.

Why This Approach

• Minimal change: Only modifies the retry decision logic in one place
• No breaking changes: Manual mode (auto-approval disabled) already works correctly -- it shows the error and lets the user retry
• Handles the reported scenario: After adding credits on OpenRouter, the user can simply click "Retry" instead of waiting for exponential backoff
• Extensible: The nonRetryableStatuses array is easy to extend if other status codes should also skip auto-retry

Please mention @roomote in a comment saying that you approve this plan, and I'll proceed with the implementation.

[Quantum-Fracture-Studio]

After digging on the user setting side and tracing through the error, the 402 is hitting a set limit on the API's definition, not the OpenRouter auto top-off mode. Would be nice to mention this in the surfaced (friendly) error. I had to up the "monthly" cap on the API and that fixed the problem (after refreshing chat)...

The backoff approach suggested above also makes sense but more for a better user experience.