Summary

Refines the billing error detection logic to prevent false positives from conversational text (e.g., "billing plan") while ensuring legitimate errors like "insufficient balance" are correctly identified.

Problem

The isBillingErrorMessage function was overly aggressive. It used a fallback check that would flag any message containing the word "billing" along with keywords like "plan", "upgrade", "credits", or "payment" as an error.

This caused legitimate user queries (e.g., "How do I upgrade my billing plan?") to trigger the "API provider returned a billing error" UI, creating a confusing user experience.

⚠️ API provider returned a billing error — your API key has run out of credits or has an insufficient balance. Check your provider's billing dashboard and top up or switch to a different API key.

Solution

1. Removed Loose Matching: Deleted the broad fallback logic that matched combinations of "billing" + keywords.
2. Strict Pattern Matching: The function now relies exclusively on matchesErrorPatterns, which checks against a list of specific error strings and regexes.
3. Enhanced Patterns: Added "insufficient balance" to the ERROR_PATTERNS.billing list to ensure this specific error is still caught explicitly, as it might have been previously caught by the loose check.

Greptile Overview

Greptile Summary

This PR tightens billing error detection in src/agents/pi-embedded-helpers/errors.ts by removing a broad fallback that treated conversational mentions of "billing" + related keywords as an error. isBillingErrorMessage now relies solely on the explicit ERROR_PATTERNS.billing list via matchesErrorPatterns, and the patterns list is extended to include the literal string "insufficient balance" so that common real billing failures are still classified correctly.

This logic feeds into user-facing error rewriting (formatAssistantErrorText / sanitizeUserFacingText) and failover classification (classifyFailoverReason), so reducing false positives here directly prevents the "API provider returned a billing error" UI from triggering on normal user questions.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk.
• Change is narrowly scoped to billing error classification, removes an overly broad heuristic that caused known false positives, and keeps detection based on an explicit pattern list (with an added concrete pattern for "insufficient balance"). No other call sites or error formatting paths are modified.
• src/agents/pi-embedded-helpers/errors.ts

_{(2/5) Greptile learns from your feedback when you react with thumbs up/down!}