原始内容
Pi Provider Multiplexer
A Pi extension that gives an existing provider additional identities. Each identity gets its own Pi login and model namespace while reusing the source provider's API implementation.
What is it?
Provider aliases are useful when the same provider needs more than one account, credential, or login context. The extension creates a live provider facade for an existing provider:
- aliases appear as providers in Pi's model picker;
- each alias can be authenticated independently through Pi's normal login flow;
- requests and model refreshes are forwarded to the selected source provider;
- the alias name is preserved in model and assistant-message metadata.
The source provider is not duplicated. Its API behavior and model catalog remain the source of truth, while Pi stores credentials for the alias separately.
What commands it exposes
| Command | Arguments | Description |
|---|---|---|
/login-alias |
[alias] |
Interactively create an alias for a provider. If alias is omitted, Pi asks for it. |
Creating an alias is a two-step process:
- Run
/login-alias my-openaiand choose the provider to wrap. - Run
/login my-openaito sign in with credentials for that alias.
After authentication, the alias's models are available from /model and show
the alias provider ID, for example gpt-5.4 [my-openai].
The extension does not add its own login or model-selection commands; /login
and /model are Pi commands used with the providers it registers.
Configuration
Aliases are stored in:
~/.pi/agent/login-aliases.json
The file maps an alias ID to the source provider ID:
{
"my-openai": {
"source": "openai"
},
"work-anthropic": {
"source": "anthropic"
}
}
The source value must be a provider ID known to Pi. Alias IDs may contain
letters, numbers, ., _, and -, and must begin with a letter or number.
Credentials are not written to this file; Pi manages them in its usual
auth.json, keyed by the alias provider ID.
The configuration is loaded when the extension starts. Changes made manually take effect the next time Pi starts. To remove an alias, delete its entry from the file and restart Pi.
Install
Install the packaged extension from npm:
pi install npm:pi-provider-mux
Or directly from GitHub:
pi install git:github.com/NikolaiUgelvik/pi-provider-mux
Restart Pi after installation. Pi loads the packaged TypeScript source through its built-in jiti loader. npm and Git installs do not need TypeScript or a build step.
For a local checkout, load the same TypeScript entry directly:
pi -e ./extensions/login-alias.ts
Notes and limitations
Aliases for built-in providers and providers configured in models.json can be
available during startup model resolution. Providers supplied only by another
extension are discovered later, at session_start, so those aliases may not be
usable as Pi's initial or restored model.
When a source provider refreshes models, the alias forwards its alias-scoped credential and model store to that refresh. Pi's provider API does not currently support isolated provider cloning, so a source with mutable catalog state may share refreshed models across aliases even though their credentials and stored configuration remain separate.
Development
Install dependencies and run the checks from the repository root:
npm install
npm run format
npm run lint
npm run dead-code
npm run typecheck
npm test
npm run check
npm run smoke:package
Pi loads extensions/login-alias.ts and its source modules through jiti. The
package publishes those TypeScript files directly, so no production build is
required.
The repository also has a Husky pre-commit hook that formats staged files and runs the dead-code, typecheck, and test checks in parallel.
License
Copyright 2026 Nikolai Ugelvik.
This project is licensed under the Apache License, Version 2.0.