Skip to main content
Pullfrog supports BYOK (bring your own key) for every supported provider — and, through GitHub Actions secrets, for providers with no console card as well. You control the provider, the spend, and the data.
BYOK is the recommended setup: you keep your existing provider relationship, rate limits, and billing, and you pay the provider directly at their prices. If you’d rather not manage keys at all, Pullfrog Router reaches every model through Pullfrog’s gateway at raw provider cost with no markup.
If you want to use Codex access from your ChatGPT account instead of buying OpenAI API tokens, see Codex subscription — there’s a dedicated one-command CLI for it (npx pullfrog auth codex) that’s simpler than pasting keys. For a Claude Pro/Max subscription, see Claude subscription (npx pullfrog auth claude).

​
How to provide keys

Pullfrog can pick up provider keys from two places. Use the one that fits your team, you can mix and match per provider. Store your provider keys directly in the Pullfrog console. Pullfrog encrypts them at rest, injects them into the agent runtime at dispatch, and never writes them to your repository or workflow files. No pullfrog.yml edits required.
  1. Open pullfrog.com/console/<account> and find the Model usage section of the Billing card.
  2. Switch to the BYOK tab.
  3. Find your provider card, click Set up, and follow its credential instructions.
Billing card Model usage section on the BYOK tab
The Add secret modal lets you scope the secret to your whole organization or a specific repo:
Add secret modal in the Pullfrog console
Org-level secrets are inherited by every repo in the organization; repo-level secrets override an org secret of the same name for that one repo. You can also manage secrets per repo from the Secrets card on the repo console:
Secrets card on the repo console
Inherited org secrets show up here read-only so it’s clear which keys are available to the repo. Adding a repo secret with the same name overrides the org one for this repo only.

​
GitHub Actions secrets (alternative)

If you’d rather keep keys in GitHub Actions secrets, for example, because you already have org-wide secret rotation tooling there, Pullfrog also reads keys from the workflow env: block.
  1. Add the secret in GitHub. Org-level (github.com/organizations/<org>/settings/secrets/actions → New organization secret) or repo-level (github.com/<org>/<repo>/settings/secrets/actions → New repository secret).
  2. Map it into pullfrog.yml:
If a key is set in both the workflow env: and Pullfrog secrets, the workflow value wins. This lets you override Pullfrog-stored secrets per-workflow when needed.

​
Custom providers

The workflow env: block isn’t limited to the providers listed in the console. Whatever you put there reaches the agent as-is, and any provider in the models.dev catalog switches on the moment its API-key variable is present — Groq, Mistral, Cerebras, Together, Fireworks, and the rest. Add the key as a GitHub Actions secret, map it into env:, and set the model input to that provider’s models.dev specifier. There is nothing to wait on us for and nothing to enable. Full walkthrough: custom providers.

​
Free models

A handful of models are completely free and work out of the box with zero key setup:
  • Big Pickle (OpenCode)
Select it in the model selector and skip BYOK entirely.

​
Amazon Bedrock

If you want to route through your own AWS Bedrock account instead of going to a model vendor directly, see Amazon Bedrock for the multi-secret setup. Bedrock is BYOK only and uses pinned model IDs (no aliasing) so enterprise compliance and provisioned-throughput contracts stay predictable.

​
Google Vertex AI

If you want to route through your own Google Cloud project, see Google Vertex AI for the service-account setup. Vertex AI is BYOK only and uses pinned model IDs through VERTEX_MODEL_ID.

​
Azure OpenAI

If your organization buys models through Azure, see Azure OpenAI for the five-value setup. Azure is BYOK only and routes on your deployment name via AZURE_DEPLOYMENT rather than a model alias, so inference bills to your Azure subscription and Azure credits apply.

​
OpenAI-compatible endpoints

If you route through your own gateway or run your own inference — a LiteLLM proxy, a Cloudflare AI Gateway, a self-hosted vLLM server — see OpenAI-compatible endpoints. One entry covers every such endpoint: you supply the base URL, key, model ID, and that model’s two token limits through OPENAI_COMPATIBLE_*. BYOK only.

​
Anthropic gateways

Anthropic models run through Claude Code, which honors ANTHROPIC_BASE_URL. If you front Claude with your own gateway — a LiteLLM proxy, a corporate egress proxy — point runs at it from your workflow env:. Keep your normal anthropic/* model selection; there’s no separate model entry to pick.
The base URL is plain config, not a credential, so it belongs in the workflow file rather than a secret — only the key needs encrypting. Pullfrog talks to your gateway in Anthropic’s native format, so prompt caching and extended thinking survive the hop. (If you’d rather not edit pullfrog.yml, both values can go in Pullfrog secrets instead, under Additional secrets.) Which credential variable you use depends on the header your gateway reads. ANTHROPIC_API_KEY sends the value as x-api-key; ANTHROPIC_AUTH_TOKEN sends it as Authorization: Bearer. Both are accepted, and a gateway that reads the wrong one answers 401 — if that happens, swap the variable and re-run.
Pullfrog does not check a gateway credential against api.anthropic.com before a run, because your token is not valid there and asking would only ever produce a false rejection. A gateway that refuses the credential surfaces its own error from the run instead. This works for Claude models only. Several providers publish an /anthropic endpoint serving their own models, but Anthropic doesn’t support routing Claude Code to non-Claude models through a gateway — and all of them expose an OpenAI-compatible API too, so use OpenAI-compatible endpoints for those.

​
Troubleshooting

“Missing API key” error in GitHub Actions The agent couldn’t find a valid key at runtime. Check, in order:
  1. The selected model’s required env var is set somewhere, Pullfrog secrets (Billing → Model usage → BYOK) or a workflow env: mapping.
  2. The secret name matches the provider’s env var exactly (e.g. ANTHROPIC_API_KEY, not CLAUDE_API_KEY).
  3. If you used GitHub secrets, the secret is mapped in your pullfrog.yml env: block, Actions only injects what the workflow file lists.
“Missing API key” warning in the Pullfrog console The console couldn’t find the env var the selected model needs. Add the secret via the Model usage section of the Billing card or switch to a model whose key you already have.