pi-keyrouter
API key rotation for pi-coding-agent. Multiple keys per provider, automatic 429/401 fallback, max-retries guard.
Package details
Install pi-keyrouter from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:pi-keyrouter- Package
pi-keyrouter- Version
0.3.1- Published
- Jun 17, 2026
- Downloads
- not available
- Author
- lowern1ght
- License
- MIT
- Types
- extension
- Size
- 28.2 KB
- Dependencies
- 0 dependencies · 1 peer
Pi manifest JSON
{
"extensions": [
"./index.ts"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
🔑 pi-keyrouter
API key rotation for pi-coding-agent.
Multiple keys per provider · automatic 429/401 fallback · native integration.
pi install npm:pi-keyrouter
# create ~/.pi/keyrouter.json with your keys
/reload
When your model returns 429 (rate-limited) or 401 (unauthorized), the next key is set via pi's native authStorage.setRuntimeApiKey(). pi's built-in retry then uses the new key automatically.
⚡ Install
pi install npm:pi-keyrouter
Add your provider config to ~/.pi/keyrouter.json:
{
"providers": [
{
"name": "z-ai",
"match": ["api.z.ai", "z.ai"],
"keys": [
{ "name": "primary", "value": "key-1-..." },
{ "name": "backup", "value": "key-2-..." }
]
}
],
"maxRetries": 3,
"cooldownMs": 60000
}
/reload — extension wraps globalThis.fetch and rotates on 429/401.
🎯 How it works (native integration)
This extension uses pi's native API key resolution — no fetch hacks, no header manipulation.
From the pi SDK docs:
API key resolution priority (handled by AuthStorage):
- Runtime overrides (via
setRuntimeApiKey, not persisted) ← we use this- Stored credentials in
auth.json- Environment variables
- Fallback resolver
Flow:
- session_start — extension loads config, calls
authStorage.setRuntimeApiKey(provider, firstKey)for each managed provider. Runtime override takes priority over auth.json. - Request — pi makes the HTTP call with the runtime-overridden key.
- after_provider_response (429/401/403) — extension fires, calls
setRuntimeApiKey(provider, nextKey). - pi's built-in retry — pi's retry logic (the "Retrying 3/3" you see in the UI) makes the next attempt, which now picks up the new runtime key.
- Success or exhaustion — if all keys fail, runtime override is cleared and pi surfaces the real error.
Why not fetch wrapping?
An earlier version wrapped globalThis.fetch. It didn't work because the OpenAI SDK (used by pi-ai for z.ai and others) captures the fetch reference at client creation time, before extensions load. The SDK kept calling the original fetch, ignoring the wrapper.
The native setRuntimeApiKey approach is cleaner: pi owns the HTTP layer, we only swap the key between attempts. No monkey-patching, no timing issues.
What gets rotated
| Status | Action |
|---|---|
| 200 | Key marked OK |
| 429 | Current key marked rate-limited (cooldown), setRuntimeApiKey(nextKey) |
| 401 / 403 | Current key marked unauthorized (cooldown), setRuntimeApiKey(nextKey) |
| All keys exhausted | Runtime override cleared, pi surfaces real error |
📊 Visibility
The /keyrouter command shows live state:
/keyrouter
🔑 keyrouter: active
z-ai (current: backup)
• primary uses=12 fails=2 status=rate-limited ⏱ 47s
• backup uses=2 fails=0 status=ok
Subcommands:
/keyrouter status— show snapshot (default)/keyrouter enable— re-activate (if disabled)/keyrouter disable— restore original fetch, stop rotating/keyrouter reload— re-read config
Every key switch notifies the user with a Box widget:
🔑 keyrouter: z-ai — primary → backup (HTTP 429, attempt 1)
🔧 Config
~/.pi/keyrouter.json only (user-level, never project-scoped).
- Windows:
%USERPROFILE%\.pi\keyrouter.json - macOS/Linux:
~/.pi/keyrouter.json
Config is global because API keys are personal credentials — they do not
belong inside a project directory. Project-local keyrouter.json files are
deliberately ignored (security: prevents a malicious repo from overriding
your real keys).
{
"providers": [
{
"name": "display-name", // for logs (any string)
"match": ["api.z.ai", "z.ai"], // URL substrings (case-insensitive)
"keys": [
{ "name": "primary", "value": "key-1..." },
{ "name": "backup", "value": "key-2..." }
]
}
],
"maxRetries": 3, // total retries per request across all keys
"cooldownMs": 60000 // how long a bad key stays marked bad (1 min default)
}
Multi-provider
{
"providers": [
{ "name": "z-ai", "match": ["api.z.ai"], "keys": [...] },
{ "name": "openrouter", "match": ["openrouter.ai"], "keys": [...] }
]
}
Each provider rotates independently. Cross-provider URLs are not intercepted.
🛡️ Security
API keys live in plain text in keyrouter.json. Don't commit it. Options:
- Add
keyrouter.jsonto.gitignore - Use
chmod 600on the file - (Future) env var interpolation
$ENV_VAR— not yet implemented
🛠 Development
bun test # 33 tests
bun run typecheck # tsc --noEmit
Monorepo layout:
packages/pi-keyrouter/
├── index.ts — extension entry point (native setRuntimeApiKey)
├── rotation.ts — pure key-pick logic
├── config.ts — config loader
├── types.ts — shared types
└── tests/
├── rotation.test.ts — pure logic
├── provider-resolution.test.ts — provider name mapping
├── config.test.ts — config loader
└── smoke.test.ts — load-time smoke test
📜 License
MIT — same as pi-soly.