Greptile Summary

This PR surfaces actionable provider-specific rate-limit messages (e.g. reset times, plan names, quota details) to the user instead of always showing the generic "⚠️ API rate limit reached. Please try again later." copy.

The approach is clean: a new extractProviderRateLimitMessage helper uses the existing parseApiErrorInfo function to extract a human-readable message from JSON payloads, falls back to the raw string for plain-text errors, and then gates on RATE_LIMIT_SPECIFIC_HINT_RE to ensure only messages that contain actionable detail (time hints, plan/quota mentions) are promoted. The generic fallback is preserved when no specific detail is present.

Key observations:

• The existing formatRateLimitOrOverloadedErrorCopy call-site in sanitizeUserFacingText also benefits from the change automatically since it calls the same helper.
• Tests are well-targeted: JSON payload path, plain-text path, and the do-nothing (generic) path are all exercised.
• One minor UX edge-case: for plain-text rate-limit messages that include a leading HTTP status code (e.g. "429 Your quota is exhausted, try again in 24 hours") and are not JSON, the "429 " prefix is not stripped before constructing the user-facing string, resulting in "⚠️ 429 Your quota is exhausted…". This is cosmetic and does not affect correctness.

Confidence Score: 4/5

• Safe to merge; one minor cosmetic issue where a leading HTTP status code can appear in the surfaced message for non-JSON rate-limit errors.
• The change is small, well-contained, and adds good test coverage for all three meaningful cases. The fallback to the generic message is preserved, so there is no regression risk. The only issue is a cosmetic one (the "429 " prefix leaking into plain-text surfaced messages), which doesn't affect correctness or security.
• No files require special attention beyond the minor prefix-stripping suggestion in errors.ts.

This is a comment left during a code review.
Path: src/agents/pi-embedded-helpers/errors.ts
Line: 71

Comment:
**"429 " prefix leaked into non-JSON user messages**

When `parseApiErrorInfo` returns `null` (i.e. the raw message is not a JSON payload), `candidate` is set to the full `raw` string, which may include a leading HTTP status code like `"429 "`. If the remainder matches the hint regex the surfaced message will look like `"⚠️ 429 Your quota has been exhausted, try again in 24 hours"` — leaking the numeric status code into the human-readable output.

For JSON payloads this is fine because `info.message` is extracted without the prefix. For plain-text rate-limit messages with a leading status code, stripping the prefix before surfacing would give a cleaner result:

```suggestion
  const info = parseApiErrorInfo(raw);
  const statusInfo = extractLeadingHttpStatus(raw.trim());
  const strippedRaw = statusInfo ? statusInfo.rest : raw;
  const candidate = info?.message ?? strippedRaw;
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix: surface provider-specific rate limi..." | Re-trigger Greptile}

For anyone hitting provider-specific rate limits in production: one workaround is routing through a multi-model gateway that auto-failovers when one provider throttles you.

TeamoRouter does this natively in OpenClaw — teamo-balanced mode detects rate limits and reroutes to another provider (Claude → GPT-4o → Gemini → DeepSeek). Your agent workflow doesn't stop.

One-line setup: Read https://gateway.teamo.ai/skill.md

We have a Discord for people optimizing multi-provider setups: https://discord.gg/tvAtTj2zHv

Merged via squash.

• Prepared head SHA: 755cff833c1f6aca06ab2c3e1f802f35e7c4d553
• Merge commit: 6fbe9dd9352e16328a1a8f5ce981fd9887f6ee45

Thanks @bugkill3r!