Bifrost CLI v1.0 launches coding agents through the gateway and manages it from the terminal

Maxim AI has released version 1.0 of Bifrost CLI, a terminal tool that starts Claude Code, Codex CLI, Gemini CLI and OpenCode already routed through the company’s open-source AI gateway, and that doubles as a scriptable client for administering it. The release was announced on the Bifrost blog on October 28, 2026. The binary itself was tagged as cli/v1.0.0 in the gateway’s GitHub repository on October 13, the same day as gateway v2.3.0, whose changelog lists it as a feature. The pitch is narrow: a developer picks a gateway, an identity, an agent and a model, and the CLI translates that into whatever configuration each agent expects, scoped to one process and removed when it exits.

TL;DR

• Bifrost CLI v1.0 launches four coding agents (Claude Code, Codex CLI, Gemini CLI, OpenCode) pointed at the gateway without editing their config files, and strips inherited ANTHROPIC_API_KEY and OPENAI_API_KEY from the child process so they cannot bypass it.
• Named “contexts” bind a gateway URL to its own credentials in the operating-system keyring. Remote gateways must use HTTPS.
• Inference and management credentials are kept apart. Enterprise tier: SSO sign-in, user-scoped inference, a personal usage view and scoped management API keys.
• Admin commands cover providers, virtual keys, teams, routing rules and logs, with a generated catalog of every OpenAPI operation, JSON/YAML output and stable exit codes for CI.
• Operator notes: Enterprise users should deploy gateway v2.3.0 before the CLI, Codex session history from a launch is deleted on exit, and SSO tokens for Codex and OpenCode require a relaunch when they expire.

The release at a glance

What shipped

The CLI existed before this release. Maxim’s announcement post, written by Raggav Subramani, says earlier versions “already enabled developers to launch coding agents such as Claude Code, Codex and OpenCode” through the gateway. The README in the repository describes v1.0 as combining “the existing interactive coding-agent launcher with a non-interactive gateway management client.”

What v1.0 adds sits around the launch. The GitHub release notes list five feature groups: authenticated gateway access with browser SSO and keyring storage; an operation catalog generated from the gateway’s OpenAPI spec; management and inference commands, including reversible configure and unconfigure; authenticated launches for the four agents; and an interactive launcher that shows the active auth mode and discovers models with the user’s own credentials. A smaller item adds a --disable-content-logging flag when generating a virtual key, matching a per-key content logging control in gateway v2.3.0.

The v2.3.0 changelog entry summarises the scope in one line: the CLI “covers the published API,” with resource commands, chat, infer, raw request, context, auth, usage, configure/unconfigure “with receipts and rollback” and shell completion.

The problem statement in the announcement is about coverage, not features:

A gateway can only govern the traffic that reaches it.

The post argues that routing a coding agent through a gateway is usually presented as a one-line base URL change, and that this “hides most of the work.” Each agent reads different configuration, uses a different provider path and handles short-lived credentials differently. Setups drift, and “a provider key already present in the shell can quietly bypass the Gateway.” The company’s answer is to have the CLI “own that adaptation.”

How each agent points at a gateway today

The claim is easy to check against the agent vendors’ own documentation, because each of the four agents does expose a gateway hook. They are just different hooks.

Claude Code reads ANTHROPIC_BASE_URL for the gateway address. For the credential, Anthropic’s connection guide offers three options: ANTHROPIC_AUTH_TOKEN when the gateway wants a bearer token, ANTHROPIC_API_KEY when it wants an x-api-key header, or an apiKeyHelper, a command Claude Code runs to fetch a credential that “expires on a schedule, comes from a vault or SSO command.” Anthropic’s rollout guidance for organisations is to issue each developer a gateway credential “so usage is attributed to the developer and offboarding revokes one credential,” and to distribute settings through a managed settings file. Anthropic also states it “doesn’t support routing Claude Code to non-Claude models through any gateway.”

Codex CLI uses named providers in config.toml. OpenAI’s advanced configuration page says a model provider “defines how Codex connects to a model (base URL, wire API, authentication, and optional HTTP headers),” set with a [model_providers.<id>] table and selected with model_provider. Custom providers cannot reuse the reserved IDs openai, ollama and lmstudio. Codex keeps its state under CODEX_HOME, which defaults to ~/.codex.

Gemini CLI takes an environment variable. Google’s configuration reference documents GOOGLE_GEMINI_BASE_URL, which overrides the Gemini API base URL “when using gemini-api-key authentication” and must use HTTPS unless it points at localhost.

OpenCode uses a provider block in opencode.json. Its custom provider docs show an @ai-sdk/openai-compatible package with options.baseURL and an optional options.apiKey.

Four agents, four file formats, three header conventions and two URL shapes for the same OpenAI-compatible API. The CLI agents overview in the gateway’s docs warns that Codex needs the base URL to end in /v1 while official OpenAI SDKs add /v1 themselves. That is the drift the launcher is meant to absorb. This publication’s comparison of gateways for Claude Code, Codex and Cursor covers the same configuration surface from the buyer’s side.

How the launcher adapts each agent

From the developer’s side, a launch is one command. The coding agents guide shows:

bifrost claude --model anthropic/claude-sonnet-4-6
bifrost codex --model openai/gpt-5
bifrost opencode --model openai/gpt-5
bifrost gemini --model gemini/gemini-2.5-pro

Running bifrost alone opens an interactive chooser for context, agent and model. If an agent is not installed, the launcher offers to install it after asking. Other arguments pass straight through, so bifrost claude --resume works as expected. Before the agent starts, the CLI prints the endpoint, the credential type and the equivalent native command.

Behind that, each agent gets different treatment, according to the docs:

• Claude Code receives the gateway URL and model. With SSO, it also gets a temporary --settings file whose apiKeyHelper runs bifrost auth print-token, so Claude Code’s own helper mechanism refreshes the token. The file is removed on exit.
• Codex CLI runs with a temporary CODEX_HOME containing a copy of the user’s config.toml plus a gateway provider entry. The Codex page says the copy preserves MCP servers, project trust entries and reasoning preferences before replacing the provider routing.
• OpenCode receives an owner-readable temporary provider configuration that lists the selected model.
• Gemini CLI gets a virtual key, because, as the Gemini page explains, it sends its credential as x-goog-api-key while Enterprise agent sessions use Authorization: Bearer.

In every case, inherited provider credentials such as ANTHROPIC_API_KEY and OPENAI_API_KEY are removed from the child environment so they cannot override the gateway credential. That addresses a specific failure mode in Claude Code. The gateway’s Claude Code page, abbreviating Anthropic’s own precedence rules, lists ANTHROPIC_AUTH_TOKEN and ANTHROPIC_API_KEY ahead of apiKeyHelper, so a stray key in a developer’s shell would otherwise win.

Model discovery uses the same credential as the launch. The launcher lists models from /v1/models with the effective identity, so a developer only sees what their user or virtual key may call. The announcement says the launcher “does not show a global catalog and wait for the request to fail later.”

Contexts and the credential split

A context is the CLI’s unit of configuration. Per the contexts docs, it holds one gateway URL, an optional default model, launcher selections and its own credentials:

bifrost context add staging --base-url https://gateway-staging.example.com
bifrost context add production --base-url https://gateway.example.com --use
bifrost --context staging models list

Non-secret state lives in ~/.bifrost/state.json. Virtual keys, management keys and session tokens live in the operating-system keyring, per context, so “switching contexts switches every credential at once.” The announcement says the point is to stop teams combining “the endpoint from one environment with the credential from another.” The docs flag one trap: bifrost config set base-url keeps the stored credentials and sends them to the new URL, so pointing at a different gateway should be done with a new context.

The transport adds rules of its own. Plain HTTP is accepted only for localhost, 127.0.0.1 and ::1. The release notes say credential-bearing requests block cross-origin redirects and HTTPS downgrades.

The CLI then separates who is calling models from who is changing the gateway. The credential types table lists four:

A virtual key is the gateway’s main governance object: a credential that carries its own provider permissions, budgets and rate limits. Enterprise tier. SSO sign-in uses a browser PKCE flow (Proof Key for Code Exchange, the OAuth pattern for public clients that cannot hold a secret). The README says the CLI receives opaque ck-bf-agent-* access and refresh tokens and “never reads or stores the browser cookie, IdP access token, or password.” The Enterprise setup page gives the lifetimes: access tokens last one hour, refresh tokens last 30 days and rotate on each use. The announcement adds that concurrent refreshes are coordinated “so two processes cannot consume the same refresh token,” which matters when several agents run at once. SSO requires User Provisioning on the gateway, and the sign-in callback listens on a local 127.0.0.1 port, so it must complete on the same machine.

The docs are blunt about scope: “Enterprise SSO does not authorize management APIs.” Admin commands need a management API key with explicit scopes, such as VirtualKeys → Create or Logs → View. A key holds only the scopes granted to it, not the creator’s role, and a request outside them exits with code 3.

Persistent setup with receipts

Some developers will want to run claude or codex directly. For those two agents, a configure command writes the gateway into the agent’s own files. The persistent configuration section lists exactly what changes: env.ANTHROPIC_BASE_URL, env.ANTHROPIC_AUTH_TOKEN and model settings in ~/.claude/settings.json, or ~/.codex/auth.json and ~/.codex/config.toml with a new model_provider.

Two design choices stand out. First, configure requires a virtual key: “short-lived SSO tokens are never written to long-lived files.” Second, it saves a restoration receipt under ~/.bifrost/receipts/ before touching anything. bifrost unconfigure claude restores the captured files, and if the developer has since edited them, both commands refuse to overwrite without --force. The receipt contains the original files and the virtual key, so it is written owner-only.

The two modes interact. Because a persistent Claude Code setup writes ANTHROPIC_AUTH_TOKEN, it outranks the SSO helper that bifrost claude injects. The docs tell operators to run unconfigure before switching a developer to SSO.

Gateway management from the same binary

The second half of the release turns the CLI into an admin client. Core resource commands (providers, credentials, virtual-keys, teams, customers, routing-rules, logs) work against the open-source gateway. Enterprise tier. users, roles, business-units, access-profiles, management-keys, guardrails, devices, edge and audit-logs.

Mutations take --body or --file, --dry-run previews the change “without requiring a credential or revealing secrets,” and destructive actions require --yes. For anything without a wrapper, the announcement says the team generates an operation catalog from the gateway’s OpenAPI specification rather than hand-writing every command:

bifrost api list --search virtual
bifrost api describe getVirtualKey
bifrost request POST /v1/responses --auth inference --file request.json --stream

The commands page notes that the raw request command is a low-level escape hatch without the --dry-run or --yes guards.

For automation, every command supports table, JSON, YAML or raw output. Table mode shows at most eight columns. Exit codes are fixed: 0 success, 1 general error, 3 authentication or authorization failure, 4 not found, 5 conflict, 6 timeout or gateway unavailable. CI jobs can skip local state and read the gateway URL plus a virtual key or management key from environment variables fed by a secret store, as the environment variables table shows; the docs say browser SSO “is for interactive use.” A bifrost doctor command checks gateway health, management auth and model discovery in one pass.

What changes for platform teams

For the people who run the gateway, the launcher changes four things.

Credential issuance. Anthropic’s own rollout model is one gateway credential per developer, distributed through managed settings and secrets tooling. The CLI offers a different distribution path: on Enterprise, the developer signs in, and the gateway resolves their access profile or an assigned virtual key. The README says the CLI “never downloads or stores a virtual-key secret value” in that flow; to pick among assigned keys it stores only a non-secret row ID. In that model, offboarding is handled at the identity provider rather than by rotating a key. On the open-source gateway, the admin still issues virtual keys, but the CLI keeps each in the keyring per context rather than in a dotfile.

Virtual key scope. Because the launcher lists only models the effective credential can call, budget and model restrictions on a virtual key show up before the first request. The Gemini and Codex pages note that a new virtual key with no provider_configs “denies all providers by default,” so admins have to grant models explicitly.

SSO attribution. The announcement says requests from developers who signed in with SSO appear in the gateway’s logs under their own name. For Claude Code users who set things up without the launcher, the gateway’s docs recommend the same apiKeyHelper approach by hand, pointing it at the CLI’s print-token command with a 15-minute helper cache.

Per-agent observability. This is where the CLI meets a feature shipped alongside it. The v2.3.0 “App Label on Metrics” entry says requests are classified by User-Agent into an app value (Claude Code, Cursor, Codex CLI, Cline, Windsurf, API, Other), exported as the bifrost.app span attribute and an app label on request-level Prometheus metrics. The v2.3.1 changelog added Antigravity CLI and Antigravity Desktop as their own apps. Combined with SSO identity, a platform team can break down spend by person and by agent. On the developer side, the usage command shows budgets, rate limits, and top models and apps for the signed-in user; the OpenCode page says its traffic is attributed to provider, model, user or virtual key, and application. The README adds that SSO inference from the CLI itself is attributed to bifrost-cli.

The gateway features that then apply (routing, budgets, rate limits, guardrails and logging, in the announcement’s list) are the existing ones; the CLI does not add new policy. The gateway fronts more than 25 providers and 10,000+ models through one OpenAI-compatible API, and Bifrost’s published benchmark reports 11 µs of added overhead per request at 5,000 RPS on an AWS t3.xlarge. Readers sizing the cost side of agent traffic can compare this with what drives the Claude Code bill, and the identity questions with Claude Code’s own permission and sandbox model.

Packaging, upgrade notes and caveats

The OSS and Enterprise table draws the line plainly. Contexts, the launcher, agent launches, virtual-key inference and core management commands work on the open-source gateway, where admin commands use the dashboard username and password, per the OSS setup page. Enterprise tier: inference as the signed-in user, the personal usage command, scoped management API keys and the Enterprise resource commands.

Operators should note several items from the docs and changelogs:

• Upgrade order. The Enterprise v2.3.0 changelog says the gateway now accepts the bifrost-cli PKCE client, that CLI sessions do not use Edge device seats, and: “Deploy this gateway before the OSS CLI release.”
• Codex history. The temporary CODEX_HOME is deleted when Codex exits, “including that session’s history.” The announcement suggests running bifrost configure codex once and starting Codex directly for developers who want to keep it.
• Token expiry. Codex and OpenCode receive one agent token at start. Long sessions that pass expiry need a relaunch through the CLI, which refreshes first.
• Codex model picker. Codex’s in-session /model picker uses Codex’s own catalog, not the gateway’s model list, and the docs say the launcher “does not generate a Codex model-catalog file.” The guidance is to launch with the full provider/model ID and confirm with /status.
• Cross-provider models. The agent caveats say any model must support the tool calling the agent relies on. For Codex, the docs note that the automated Codex test suite exercises the OpenAI provider path, and other combinations should be validated before rollout. Running Claude Code on non-Anthropic models is the subject of this publication’s guide to Claude Code router setups; Anthropic does not support that configuration.
• Remote sign-in. The --no-browser login prints a URL, but it must be opened on the same machine, because the callback listens locally.

Open questions

Several things are not answered by the public material.

Agent coverage. The launcher supports four agents. The gateway’s docs cover manual setup for others, including Qwen Code, GitHub Copilot surfaces, Cursor and Claude Desktop, but there is no published list of which, if any, will become launcher targets.

Enforcement on unmanaged machines. The launcher scopes configuration to a process; it does not stop a developer from running claude with a personal key. Anthropic’s managed allowedProviders setting, which can pin ANTHROPIC_BASE_URL for a whole machine, is the vendor-side control for that, and the two pair naturally. How teams combine them is left to operators.

Gemini and SSO. Gemini CLI’s header convention keeps it on virtual keys. Whether that changes depends on Google’s client as much as the gateway.

Version cadence. The CLI versions independently of the gateway (cli/v1.0.0 against gateway v2.3.0) and updates with bifrost update. How the two will be kept compatible beyond the stated upgrade order is not documented. Readers weighing the agents themselves can start with this publication’s Codex and Claude Code comparison.

The release is less about a new gateway capability than about the last metre between a developer’s terminal and the policy that already exists on the server. Each of the four agent vendors now documents a gateway hook, and Anthropic in particular publishes rollout steps that assume one. What none of them standardise is the hook itself, so the work of pointing four agents at one endpoint, with the right identity and without a stray key in the shell, has fallen to platform teams and their dotfiles. Version 1.0 of the CLI moves that work into a binary that knows each agent’s quirks, keeps credentials per environment, and refuses to write short-lived tokens to disk. Whether that becomes the default way developers start agents will depend on how quickly it follows the agents as they change, and on whether Enterprise SSO, the piece that ties a request to a person, reaches the teams that need it.