Stop naming a provider for MCPJam's own swarm model limit - #5292
Conversation
A swarm attempt stopped by MCPJam's daily model limit was stored as `rate_limited` with the humanized sentence, which had already dropped the backend's `user_rate_limit` code. The run screen read that as the user's provider throttling their key and printed "Anthropic rate-limited this key. Retry again later or switch models." for a Haiku run on MCPJam's own credits. - The runner keeps the account-limit code from the raw message as the attempt's errorCode. - isAccountLimit also recognizes the backend's "Daily/Monthly MCPJam model limit reached" sentence, so rows already written read correctly. - The run screen explains account-limited sessions when other sessions in the wave succeeded, where the run banner stays silent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
GitHub Actions
Error
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
Bugbot couldn't run - usage limit reachedBugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit. A user or team admin can review and increase usage limits in the Cursor dashboard. (requestId: serverGenReqId_3faa7e74-9e9c-4db7-8cf6-50bc019cbb7b) |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
✅ Snyk checks have passed. No issues have been found so far.
💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (6)
Included review availability: Your plan provides up to 8 included reviews per hour; 4 remain after this review. WalkthroughThe shared error module now extracts account-limit codes and detects humanized MCPJam model-limit messages. The session runner preserves these codes for rate-limited outcomes. The running-step UI aggregates account-limit failures and renders a dedicated banner when appropriate. Tests cover legacy messages, code normalization, server propagation, banner selection, and duplicate-card suppression. Priority: ⬇️ Low Merge Risk: ⚪ Minimal · up to No concrete merge-blocking issue was identified in the account-limit detection or banner behavior. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
One conflict, in `shared/__tests__/swarm-attempt-error.test.ts`. Both sides ADD a case after the same anchor and neither replaces the other, so both are kept: - main (#5292) covers a legacy attempt row stored under the generic `rate_limited` code, where the humanized sentence is all that is left to say MCPJam rather than a provider stopped the run; - this branch covers the three Ask MCPJam refusals as whole-run stops. They are about different inputs to the same predicate and are both worth having. Verified after resolving that main's own edits to `ACCOUNT_LIMIT_CODE` kept this branch's three codes in the regex — that half auto-merged, so it needed checking rather than assuming. 356 tests across every suite the merge touched (swarm-attempt-error, swarm-runner, run-supervisor, session-rate-limit, mcpjam-limit, the agent routes and the agent thread) pass, client typecheck is clean, and lint has no errors on the resolved file. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01HMbHn25hsRSEbw6oMACxog
This branch was successfully deployed
1 participant
What happened
A swarm running
anthropic/claude-haiku-4.5on MCPJam's credits hit the daily MCPJam model limit on 2 of 5 sessions. The run screen said:Anthropic throttled nothing, and switching models doesn't lift this limit (BYOK or waiting does).
Why
The two stopped attempts were stored with:
terminalForOutcomecleans up the raw message, which drops the backend'suser_rate_limitcode, and then saves the genericrate_limited.isAccountLimitfinds no code in either field, so the banner treats the attempt as a provider throttle and names the provider from the session's model id.Change
swarm-runner.ts): arate_limitedterminal keeps the account-limit code from the raw message (accountLimitCode) and falls back torate_limitedonly when none is found. The whole-run stop already read that same code, so run behavior doesn't change. Only the storederrorCodedoes.swarm-attempt-error.ts): newaccountLimitCode().isAccountLimitalso matches the backend'sDaily/Monthly MCPJam model limit reachedsentence, so rows already saved in prod stop blaming a provider without a backfill.new-swarm-running-step.tsx): when a wave also has successful sessions, the run banner stays silent. Sessions stopped by the account limit now get their own amber line ("N sessions stopped at your MCPJam model limit." plus the backend's sentence) instead of no explanation. It is hidden when the run banner already shows the same message.Not changed: account-limit denials that arrive as
failed(billing codes) still storesession_failed. That's a separate path, and the provider banner never reads it.Tests
shared/__tests__/swarm-attempt-error.test.ts:accountLimitCodefor the envelope, the(code, HTTP n)format, code preferred over message, and no code for a provider 429 or a cleaned-up sentence. Also a sentence saved underrate_limitedis recognized as an account limit.swarm-runner.test.ts: a rate-limited session whose raw message carriesuser_rate_limitis saved with that code.new-swarm-running-step.rate-limit-card.test.tsx: the exact prod row gets no provider banner, a mixed wave shows the account-limit banner, and an all-limited wave shows only the run banner.Local:
vitest runon those three +client/src/components/swarms(52 files, 674 tests) pass.🤖 Generated with Claude Code
Note
Medium Risk
Touches swarm terminal error persistence and run UI messaging for rate-limited outcomes; behavior change is scoped to limit classification but affects what users see and what codes are stored on attempts.
Overview
Fixes swarm runs that hit MCPJam’s model/credit limits being shown as provider throttles (e.g. “Anthropic rate-limited this key”) when the stored attempt used generic
rate_limitedafter humanization droppeduser_rate_limit.The runner now persists the account-limit denial code from the raw agent error via new
accountLimitCode, falling back torate_limitedonly for true provider limits.isAccountLimitalso recognizes legacy rows whose message is the “Daily/Monthly MCPJam model limit reached” sentence under a barerate_limitedcode.On the run screen, account-limited sessions get a dedicated amber
new-swarm-running-account-limitbanner when other sessions succeeded (so amber chips aren’t unexplained); that banner is suppressed when the whole-run failure banner already states the same limit.Reviewed by Cursor Bugbot for commit 4675449. Bugbot is set up for automated code reviews on this repo. Configure here.
Summary by cubic
Stops MCPJam's own model limit from being reported as a provider rate limit. Swarm attempts now retain the backend account-limit code, so the run screen no longer blames the provider or tells users to switch models; mixed waves get a dedicated explanation while all-limited runs keep the existing run-level message.
Daily/Monthly MCPJam model limit reachedsentence are recognized without a data migration.failedbilling denials keep their existing behavior.Written for commit 4675449. Summary will update on new commits.