Vibe coding rate limits, as your AI builder actually sees them

Three different things, and most pages on this topic conflate them. The first is a transient 429 from the Anthropic API: a single request was throttled, and the SDK retries automatically with exponential backoff. The second is a soft warning: the rate_limit_event arrives with status 'allowed_warning' and a utilization percentage between 0 and 1, meaning your prompt is going through but you are close to your weekly cap. The third is a hard rejection: status 'rejected' with a resetsAt UNIX timestamp telling you exactly when the cap unlocks. The first you should never see. The second you should see as a non-blocking banner. The third should pin a 'usage limit reached, resets at H:MM' message at the bottom of the chat. If your AI builder treats all three as the same generic 'you hit your limit' toast, it is not reading the structured event at all.

Because forwarding the signal takes a patch. The Anthropic API emits a structured rate_limit_event over the streaming connection. The Claude Agent SDK packages it as an SDKRateLimitEvent. The stock @agentclientprotocol/claude-agent-acp wrapper, which is what most agentic apps build on, drops the event in its sessionUpdate translator because it does not have a mapping for that type yet (this was reported in anthropics/claude-agent-sdk-python issues 583, 601, 603, where the Python SDK actually crashed on the same message). mk0r works around it by intercepting the SDK iterator before the wrapper sees it, in src/core/vm-scripts.ts, and translating the event into a custom 'rate_limit' sessionUpdate that the bridge forwards to the browser.

status (allowed, allowed_warning, rejected, or unknown), resetsAt (UNIX milliseconds for when the cap unlocks, or null), rateLimitType (a string identifying which cap was hit, e.g. 'five_hour' or 'weekly'), utilization (a number between 0 and 1 that tells you how close to the cap you are), overageStatus (a string describing whether the overage pool is in use), overageDisabledReason (why overage is not available, if applicable), isUsingOverage (a boolean for whether the current request is being billed against the overage pool), and surpassedThreshold (a numeric threshold the user crossed, if any). The full forwarding lives between lines 144 and 163 of src/core/vm-scripts.ts. Anything the SDK adds in a later version still flows through the unknown-field passthrough; the patched entry point only normalizes the eight fields it knows about and lets the rest ride along.

api_retry is the per-request retry signal. It fires while the SDK is automatically retrying a transient failure (a 429, a 500, a connection reset) before giving up. The fields are httpStatus, errorType, attempt, maxRetries, and retryDelayMs. mk0r forwards it as a separate stream event from rate_limit because it has a different lifecycle: api_retry comes and goes within a single user prompt, while rate_limit reflects account-level state that persists across prompts. In the UI, an api_retry shows as a transient 'Retrying request, attempt 2/3' banner with the next-retry countdown. A rate_limit shows as a sticky usage indicator. They can fire together: the retry attempt itself can be the request that surfaces the rate-limit ceiling.

No. mk0r runs on the user's session against Anthropic directly, so the rate limits you see are Anthropic's account-level caps for whatever Claude Code subscription tier is in play (Free, Pro, Max). There is no mk0r-side request quota layered on top. The reason this matters: if you switch builders to escape a rate limit, and both builders use the same underlying Anthropic key or your own subscription, you will hit the same wall. The cap travels with the credentials, not the builder.

Haiku, set as the default model on src/lib/acp-chat-store.ts line 189 and re-applied to the session on src/core/e2b.ts line 1275. Haiku is the cheapest and fastest Claude model, which means a single prompt consumes far fewer tokens than the same prompt routed to Sonnet or Opus. On a fixed weekly cap, that translates to roughly five to ten times more iterations before you hit a soft warning. Vibe coding tools that default to Sonnet for code quality reasons burn through the cap proportionally faster. Neither default is wrong; they just trade quality for headroom.

On api_retry: an amber-dot banner reading 'Retrying request, attempt N/M' plus the error type, HTTP status, and the next-retry delay in seconds. On rate_limit with status allowed_warning: a non-blocking utilization indicator. On rate_limit with status rejected, or on credit_exhausted (HTTP 429 or 402 with billing_error / rate_limit error type): a persistent error overlay reading 'Usage limit reached', the raw SDK message (which contains the human-readable reset time), and Retry/Dismiss buttons. The classifier that decides which overlay to render is the isStructuredCredit check at the top of src/app/api/chat/route.ts, which combines errorType, httpStatus, and a regex fallback for stock-ACP installs that don't forward the typed signal.

Probably. v0.29 of the Claude Agent SDK started emitting nine new event types including system/api_retry and rate_limit_event (per the Claude Code April 2026 update notes). The trajectory is toward more signals, not fewer, and the stock ACP wrapper will eventually catch up. Until then, any AI builder that wants to show structured rate-limit info has to either patch the wrapper, intercept the iterator, or read the lastApiError on the prompt response. The third path is what mk0r uses for terminal errors; the first two are how it surfaces in-flight signals.