The fastest way to make a customer angry is to lock them into a single AI vendor and then have that vendor ship a worse model. We watched it happen across the AI-IDE category in 2025 and decided we'd rather not do it ourselves.
So Pearl Scout has four providers behind one model picker:
- Pearl Scout (native) — Pearl's own gateway. Anthropic, OpenAI, Google, DeepSeek, PearlFibers. Sign in once with your Pearl account.
- Codex — your OpenAI API key. Pearl Scout's quota doesn't apply; you're billed by OpenAI directly.
- Claude Code — your Anthropic API key. Same arrangement.
- GitHub Copilot — device flow against your Copilot subscription.
Same chat input. Same modes. Same inline-diff. Switch per turn.
The design pressure that gets this wrong
The temptation when shipping multi-provider support is to make your own gateway the "default" and the others second-class — different UI, different keybindings, missing features. We've seen products where the BYOK path runs through a separate sidebar with fewer modes. That's not multi-provider; that's lock-in with a politeness layer.
Pearl handles this differently. The agent-side logic — three modes, inline diff, project memory, context-usage ring, sub-agent delegation — lives in the editor. The provider is swappable. Switching to your Anthropic key doesn't change the workflow, just the model behind it. Every provider gets the full Pearl experience.
How the picker works
Models are fetched from Pearl's entitlements endpoint and grouped by provider in a native dropdown attached to the chat input. Icons differentiate model tiers — rocket for frontier models, sparkle for the mid-tier Sonnet / Flash class, zap for the small fast Haiku / Flash-Lite tier.
The active context window for each model is registered, so the context-usage ring shows real utilization for whatever model is selected. Switching models is one click. Switching providers is one click. No config file. No environment variable. No IDE restart.
Where keys live
Non-Pearl provider API keys go in the OS keychain — Windows Credential Manager on Windows, Keychain on macOS, libsecret on Linux. Pearl never sees a non-Pearl provider key in plaintext beyond the keychain handoff. If the keychain write fails (sandbox restrictions, etc.) Pearl falls back to user preferences with an inline warning so you know what happened.
The "use both" reality
Plenty of teams adopt Pearl and keep Copilot. Different jobs:
- Copilot for inline completions in the editor — the thing it's best at.
- Pearl Scout (native or Claude Code) for the chat-and-diff workflow — the thing Pearl is best at.
This isn't a contradiction. It's why we built multi-provider in the first place. The point isn't to win every model; it's to never be in the way of you using the right one.
Try it: open the model picker. Switch to a provider you've never used. Same chat input, same modes. Notice that nothing breaks. That's the feature.