Ask Thalamus routing for every vault API-key request
Merged
OA
7h ago+1362+1362+0123456789012345678901234567890123456789-139-139-012345678901234567890123456789
When Thalamus started the host, every request that would use a vault API key first asks Thalamus routing which key to use, and sends only on routing's pick.
- A routing refusal stops the request: nothing is sent, and the user sees "Thalamus routing declined this request, so it was not sent."
- No answer within 1.5 s, or routing unreachable, also stops it: "Thalamus routing did not answer, so this API key request was not sent." This follows the ruling that paid API keys never send on the plugin's own choice while routing is away.
- Subscription (OAuth) rows keep today's choice and aren't routed yet.
- After an admitted send, an OpenRouter credits refusal or a DeepSeek 402 balance refusal is reported to routing as
credential_refused. - Outside Thalamus nothing changes.
Moves to common-auth 0.47.0.
Summary by cubic
Makes every vault API-key attempt ask Thalamus routing which key to send, and sends only on routing's pick. A routing refusal, or no answer within 1.5 s (including an unreachable router), stops the request before anything is sent; both cases show a fixed message. Pi requests with no session id also stop with the no-answer message. Subscription (OAuth) rows are not routed yet and keep today's selection, and nothing changes outside Thalamus.
Routing
- Routing picks among enabled API-key rows for the request's provider, covering titles, compaction, and retries.
- A retry asks routing again and excludes every tried key; a 401 rotates to a newer version of the same admitted credential without another routing call.
- Same-origin redirects make one routing call and keep the admitted key.
- Qualifying balance refusals (OpenRouter credits, DeepSeek 402) are reported back to routing as
credential_refused; user-set spending caps are not.
Adoption
@cortexkit/common-authis bumped to 0.47.0 across thecore,opencode, andpipackages.- Routing-admitted sends skip the plugin's rate-limit and balance cooldowns; vault authorization and the user's on/off switch still apply.