yetone
0470411122
Set in the provider editor (under Concurrency; empty or 0 is no limit) or with `magpie provider rpm <id> [n|off]`; kept per provider as MaxRPM, a subscription's with its picks. Over the limit the gateway waits until the oldest request of the minute is a minute old, in the order they came, after the lane's slot and right before sending. A wait longer than 2 minutes (or the provider's Queue wait, when shorter) is turned away at once with a 429 and a Retry-After of when the minute has room; nothing rests for it. An agent gone while waiting gives its place back and is never sent. Every request that reaches the vendor counts: each try of the forward loop (retries, the next key, fallbacks) waits in serve, and requests a try makes on the way plus the gateway's own (count_tokens, System One decisions, embeddings, drawing/video, Kimi search) are counted by an rpmTransport on s.client. count_tokens never waits: a key with no room is skipped and the local estimate answers. A key or account with no room in its minute gives way to a ready one of the provider or the group, as a full lane does (laneMate). No wait happens under rpms.mu. Not counted: a plugin account's own extra requests (its own transport; its tries are). Verified (Go tests on Linux in Docker, golang:1.26.8, since new binaries hang at launch on this Mac while syspolicyd is pegged): - internal/gateway rpm_test.go through the real server stack (lanGuard(s.Handler())): limit 2, third request reaches the vendor a window after the first, all 200; past the bound a 429 with Retry-After and no rest; a cancelled waiter is never sent and gives its place back; a 503 retry and a count_tokens count, and a count with no room is estimated; a group member with no room gives way. With RPMLimit forced to 0, those five gateway tests fail. -race -count=5 passes. - internal/provider TestSetRPM (clamp, subscription picks reach each account), TestRPMCmd, internal/gui TestRPMSave. - go test -tags nogui ./... on Linux: all pass except internal/agent's TestAside* write-refusal tests, which fail only as root in Docker and pass as uid 1000. - go vet -tags nogui for linux, windows and darwin; gofmt -l clean. - GUI: new provider-rpm.test.cjs (en/zh/ja/de, 360 and 440px, Chromium and WebKit; 32 pass, and all 16 Chromium cases fail on the old app.js), plus gui-ja, gui-de, gui-zh-tw, i18n-keys, provider-concurrency, lane-limit, provider-price-rate and clinepass-pin in both engines. Not tried against the real OpenRouter.
Subsystem design references
These pages describe current responsibilities, runtime paths, state, and contracts. Start with the subsystem relevant to your task, then follow its source links to verify the implementation you change.
| Subsystem | Reference |
|---|---|
| Built-in subscriptions moving to plugins | Provider and plugin ownership |
| Plugins that run on the gateway's requests and replies | Gateway middleware |
| Claude subscription turns across Claude Code runs | Claude subscription bridge |
| How the gateway picks a provider, key or account, and falls back | Gateway routing and fallback |
| Connecting an agent's config to the gateway, drift, disconnect, WSL twins | Agent wiring |
| Providers, keys, subscription accounts, refresh and allowance | Providers and accounts |
| Instructions, MCP servers, skills and RTK written into agents | Library |
Tray, panel, window, magpie web and the page's JSON API |
GUI app shell |
A subsystem can span several packages or repositories. Its reference describes the behavior those parts provide together; it does not need to list every function.
Maintain a reference
Update the owning reference in the same PR when a change alters a documented responsibility, interface, state transition, runtime path, compatibility rule, or failure behavior. An internal refactor that preserves these contracts does not require a prose change.
Keep each fact in one reference and link to it from agent instructions or other pages. Link to source files and named symbols rather than copying implementation details that change frequently. Explain field meanings and constraints that signatures alone do not express.
For a new reference, include the responsibilities and boundaries, source of truth, main runtime paths, state transitions, important constraints, and existing verification commands. Include failure and compatibility behavior where relevant. Document current behavior separately from proposed changes; the proposal belongs in its issue or PR.
Describe a PR's semantic changes
For each affected subsystem, explain the observable change with its trigger and before/after behavior. Include changes to interfaces, state, compatibility, and failure behavior when relevant. Link the affected reference, implementation, and verification evidence. State when a refactor preserves the documented behavior.
For example, a change to plugin adoption should explain which migration state and account condition trigger it, which implementation handles requests before and after adoption, and which test exercises that transition.
This is an author-provided explanation that a reviewer verifies against the diff and surrounding code. It is not an automatically proven compatibility verdict.
Review a change
- Identify the affected subsystem and the actual runtime path, including plugin or built-in ownership.
- Compare the claimed before/after behavior with the base and head implementation. Trace relevant callers and state transitions beyond the changed lines.
- Check that changed contracts appear in the owning reference and that source links still resolve.
- Check that the cited tests or runtime evidence exercise the claimed behavior. Report checks that were not run.
A documentation update alone does not prove the implementation. Existing tests and runtime evidence remain necessary for behavior changes.