Overview
By default, 3XCode routes LLM calls through a platform-provided key managed by your organization's admin. BYOK (Bring Your Own Key) lets you instead supply your own provider credentials (an Anthropic API key, AWS Bedrock access keys, a Google Vertex AI project, or an Azure AI Foundry endpoint) and have every conversion call go directly from your machine to your own account.
BYOK is admin-gated: an admin must assign BYOK as your account's key source before 3xcode keys store will fully activate. Once assigned, your credentials are stored locally on your machine. The 3XDE backend is told which provider and which models you prefer, but it never receives, stores, or has access to the key itself.
Supported Providers
Four providers are supported, each with its own credential fields collected interactively by 3xcode keys store:
| Provider | Credentials Collected | Secret Fields | SDK Env Flag Set |
|---|---|---|---|
| Anthropic (default) | ANTHROPIC_API_KEY | API key | none (default routing) |
| AWS Bedrock | AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_REGION | Access key + secret key | CLAUDE_CODE_USE_BEDROCK=1 |
| Google Vertex AI | CLOUD_ML_REGION, ANTHROPIC_VERTEX_PROJECT_ID | none prompted (region + project ID only) | CLAUDE_CODE_USE_VERTEX=1 |
| Azure AI Foundry | ANTHROPIC_FOUNDRY_API_KEY, ANTHROPIC_FOUNDRY_BASE_URL | Foundry API key | CLAUDE_CODE_USE_FOUNDRY=1 |
Note that AWS Bedrock only accepts a raw access key / secret key pair. There's no AWS profile or SSO field. All conflicting provider env flags are explicitly cleared before the CLI sets exactly one, so a shell alias or function that might otherwise force a different provider can't silently interfere.
Setting Up BYOK
BYOK setup is a short sequence: log in, request BYOK access from your admin if it isn't already assigned, store your provider credentials, then verify the key actually works before relying on it.
# 1. Log in (device flow, or --email/--password) 3xcode login # 2. If BYOK isn't assigned to your account yet, request it 3xcode contact-admin -m "Please enable BYOK for my account" # 3. Store credentials for a provider (interactive prompts follow) 3xcode keys store --provider anthropic # Provider-specific examples: 3xcode keys store --provider bedrock # prompts for AWS access/secret key + region 3xcode keys store --provider vertex # prompts for GCP region + project ID 3xcode keys store --provider azure # prompts for Foundry API key + base URL # 4. Confirm what's stored 3xcode keys list # 5. Verify the key actually works with a live call 3xcode keys test --provider anthropic
During keys store, after the credential fields you're also asked which models you prefer: opus, sonnet (Claude Sonnet 5, the default), or haiku, given as comma-separated numbers, or Enter to allow all three. Only the provider name and this model preference list are registered with the backend; the credential values themselves stay on your machine.
How Keys Are Stored
OS keychain first
Sensitive fields (API keys, secret access keys) are stored in your OS's native credential store when available (macOS Keychain, Linux Secret Service, or Windows Credential Manager), the same pattern used by Claude Code, the GitHub CLI, and the AWS CLI.
Local file fallback
Each provider's config also lives at ~/.3xcode/providers/{provider}.json, created with owner-only permissions. When the keyring holds a secret, the JSON file stores a placeholder instead of the real value.
Never sent to the backend
Storing a key is registered with the 3XDE backend as metadata only: provider name and preferred models. The credential value itself is never transmitted, stored, or logged server-side.
Your code never leaves either
Independent of BYOK, source SQL is never sent to the 3XDE backend under any key mode. The backend only handles auth, licensing, provider-key metadata, and usage tracking. Conversion calls go directly from your machine to your chosen LLM provider.
Managing Keys
The keys command group covers the full lifecycle of a BYOK provider configuration:
| Command | What it does |
|---|---|
3xcode keys store --provider <name> | Interactively prompts for and stores credentials for one provider (anthropic, bedrock, vertex, azure) |
3xcode keys list | Table of stored providers with masked credential values, preferred models, and storage backend (keyring vs. file) |
3xcode keys status | Reports which key source is currently active: a configured BYOK provider, or "Using platform key" if none is set |
3xcode keys test --provider <name> | Makes a minimal live API call to confirm the stored key actually works; only available while your account is in BYOK mode |
3xcode keys delete <provider> | Removes a provider's credentials from both the keychain and the local JSON file |
3xcode keys test reports latency, the model tested, which key source was used, and the approval state of the request, useful for confirming a newly stored key before running it against a real conversion. If your account is not in BYOK mode, it prints a notice and returns without making a call.