T3 Code drives provider CLIs and does no inference itself, so there is no native OpenAI-compatible base-URL field; the feature request for one, pingdotgg/t3code issue 4941, was open when this was checked. The supported route is a Claude provider instance: set Binary path to claude and CLAUDE_CONFIG_DIR path to a dedicated home such as ~/.claude_continuum_home, then in that provider’s Environment variables pane set ANTHROPIC_BASE_URL to https://continuumcode.ai (bare origin, no /v1), ANTHROPIC_AUTH_TOKEN to a cont_sk_ key marked Sensitive, and ANTHROPIC_API_KEY to an empty value. Pin the model roles with ANTHROPIC_DEFAULT_OPUS_MODEL, ANTHROPIC_DEFAULT_SONNET_MODEL, and ANTHROPIC_DEFAULT_HAIKU_MODEL, the last of which must point at claude-sonnet-5 because Continuum serves no Haiku. Verify with /status in a session. Do not use the OpenCode provider for this: t3code issue 4239 reports that T3 Code unconditionally sets OPENCODE_CONFIG_CONTENT to an empty object, which hides custom providers.
- T3 Code does no inference. It drives provider CLIs, so you configure the CLI through T3 Code rather than configuring T3 Code.
- There is no native OpenAI-compatible base-URL field; the feature request for one was still open when this page was written.
- Use a dedicated
CLAUDE_CONFIG_DIR, neverHOME. SettingHOMEwrites the login somewhere T3 Code does not look. - Variables go in the provider’s Environment variables pane, not Launch arguments and not your shell profile.
- Mark the token Sensitive: T3 Code stores it as a server secret and never sends it back to the app.
- Pin the Haiku role to
claude-sonnet-5. Continuum serves no Haiku, and an unpinned role fails the same way it does in bare Claude Code.
What T3 Code is, and why that decides the method
T3 Code is an agent-harness control surface. It supports Codex, Claude, Cursor, Grok Build, and OpenCode, and it works by launching those CLIs as child processes and rendering their sessions in one place. You authenticate with the CLI, not with T3 Code — its own installation guide tells you to run claude auth login or codex login before first use.
A feature request for a native OpenAI-compatible provider by base URL — pingdotgg/t3code#4941 — was open when this guide was written on 13 August 2026, so if you came here looking for that field, it does not exist yet rather than being hidden somewhere. The route below is not a workaround for a missing feature; it is the mechanism T3 Code’s own documentation uses for external providers, worked through with an OpenRouter example.
Where a Continuum setup can live in T3 Code, checked 13 August 2026.
| Provider type | Workable? | Notes |
|---|---|---|
| Claude | Yes — the recommended route | Environment variables on the instance, exactly as the docs do for OpenRouter |
| Codex | Workable, less turnkey | Carry the config.toml setup; the docs point at the same env pane but name no OpenAI base-URL variable |
| OpenCode | No | T3 Code clobbers the OpenCode config in the child environment — see the warning below |
What you need first
Setting T3 Code up this way requires Continuum Plus or higher. Inference keys do not mint on the Free tier, so the Create key button stays disabled until you subscribe, and the provider below has no token to carry without one.
- T3 Code installed and running, with the Claude CLI on the machine that runs the sessions.
- A Continuum account on a paid plan. Personal API keys are a paid-plan feature: Plus at $25/mo, Max 100 at $100/mo, Max 200 at $200/mo, or Ultra at $500/mo as of August 2026. See pricing.
- A decision about isolation. This setup wants its own Claude home so it cannot collide with a normal Anthropic login. Create it before you start:
mkdir -p ~/.claude_continuum_home.
Add a Claude provider pointed at Continuum
Create a Continuum API key
In the Continuum web app at continuumcode.ai/app, open Settings, then Account, then Inference API. Create your key under Your keys. The same panel is on the Usage tab. Copy it at creation: it begins cont_sk_ and is shown exactly once.
Keys mint on Plus and above, so on the Free tier Create key stays disabled until you subscribe.
Create the provider with a dedicated Claude home
In T3 Code Settings, add a Claude provider (or edit one you keep for experiments):
Display name: Claude Continuum
Binary path: claude
CLAUDE_CONFIG_DIR path: ~/.claude_continuum_homeT3 Code points the child at that directory with the CLAUDE_CONFIG_DIR environment variable and leaves HOME alone, which is what you want: your keychain, git, and ssh configuration all keep working. Do not try to achieve the same isolation by setting HOME yourself — that writes the login to a path T3 Code does not read, and the provider then behaves as though it were never configured.
Set three environment variables on that provider
Open the provider’s Environment variables pane. Not Launch arguments: T3 Code’s documentation says plainly that environment-variable assignments do not work there.
ANTHROPIC_BASE_URL https://continuumcode.ai
ANTHROPIC_AUTH_TOKEN cont_sk_... Sensitive
ANTHROPIC_API_KEY Empty valueThe base URL is the bare origin with no /v1, because Claude Code appends /v1/messages itself — the same rule T3 Code’s own OpenRouter example follows when it insists on https://openrouter.ai/api rather than .../api/v1. Mark the token Sensitive so T3 Code stores it as a server secret and never sends it back to the app after saving. The empty ANTHROPIC_API_KEY is deliberate: an empty value reads as unset, which stops Claude Code from attempting an Anthropic login.
Pin the model roles
Claude Code routes work to model roles rather than to one model, and each role has a built-in default ID that Continuum does not necessarily serve. Add these to the same pane:
ANTHROPIC_DEFAULT_OPUS_MODEL claude-opus-5
ANTHROPIC_DEFAULT_SONNET_MODEL claude-sonnet-5
ANTHROPIC_DEFAULT_HAIKU_MODEL claude-sonnet-5
CLAUDE_CODE_SUBAGENT_MODEL claude-sonnet-5The Haiku line is the one that matters and the one that looks like a typo. Continuum serves no Haiku model, so the Haiku role has to point at something that exists; claude-sonnet-5 is the cheapest served Claude and the natural target. This is the same fix as pinning ANTHROPIC_SMALL_FAST_MODEL in a plain Claude Code setup, wearing a different variable name.
Open a session and check /status
Start a Claude session on the new provider and run /status. It reports the Anthropic base URL in effect, which should read https://continuumcode.ai. If it shows Anthropic’s own endpoint, the variables did not reach the child, and the provider instance is where to look rather than your shell.
The other two routes
The Codex provider: workable, less turnkey
T3 Code also drives the Codex CLI, and Codex has its own first-class provider mechanism in ~/.codex/config.toml. Setting that up as described in the Codex guide gives you a Codex provider on Continuum, and T3 Code’s Codex documentation points at the same per-provider environment pane under "I Need A Different API Key Or Endpoint" for account-specific variables. What it does not do is name an OpenAI base-URL variable, so the endpoint half of the configuration has to live in config.toml rather than in T3 Code. That works; it is just less contained than the Claude route, because part of the setup sits outside the provider record.
The OpenCode provider: do not
Standalone OpenCode is unaffected and works fine with Continuum — the bug is in the T3 Code driver, not in OpenCode. If OpenCode is the harness you want, run it directly and follow the OpenCode guide.
When it does not work
| Symptom | Cause | Fix |
|---|---|---|
/status shows Anthropic’s endpoint | The variables are not on this provider instance | Check the Environment variables pane of the provider you actually started the session on |
| Sessions bill your Anthropic plan | A cached login in that Claude home wins | Run /logout in a session for that home, then start again |
| Variables set in Launch arguments do nothing | Assignments are not supported there | Move them to the Environment variables pane |
| 404 on every turn | A /v1 on the base URL | Use the bare origin https://continuumcode.ai |
| Works, then fails on an unfamiliar model ID | A model role still points at its built-in default | Pin all three role variables, Haiku included |
| Custom models missing from an OpenCode provider | The OPENCODE_CONFIG_CONTENT clobber, t3code#4239 | Use the Claude provider route instead; the OpenCode driver cannot see your config |
| The provider shows the wrong account | Two providers sharing one config directory | Give each provider its own CLAUDE_CONFIG_DIR path |
One structural note worth internalising: T3 Code deliberately keeps Claude providers with different config directories isolated from one another, and will not offer a provider on a different config directory for an existing thread. That is correct behaviour rather than a bug — Claude Code spreads account and local state across several files under its config directory — but it means a thread started on your normal Claude account cannot be continued on the Continuum provider. Start a new thread instead.
Questions people ask
Not as of 13 August 2026. T3 Code drives provider CLIs and does no inference itself, so there is no endpoint of its own to redirect. The feature request, pingdotgg/t3code#4941, was open when this page was written.
Because T3 Code points the child at CLAUDE_CONFIG_DIR and leaves HOME alone. Setting HOME yourself writes the login into a nested path T3 Code does not read, so the provider behaves as though nothing was configured, and it breaks git, ssh, and the keychain along the way.
In that provider instance’s Environment variables pane. Not Launch arguments, where T3 Code says environment assignments do not work, and not a global shell profile, where they would leak into every other provider.
T3 Code stores sensitive values as server secrets and does not send them back to the app after saving, so the key is not echoed into a client that may be running somewhere you would rather it were not.
An empty value is treated as unset for provider selection, which stops Claude Code from trying an Anthropic login instead of using the token you supplied. It is the same instruction T3 Code gives for its OpenRouter setup.
Continuum serves no Haiku model, and the Haiku role’s built-in default is a Haiku ID. Pointing it at claude-sonnet-5 gives the role something that exists. It is the same fix as pinning ANTHROPIC_SMALL_FAST_MODEL in a plain Claude Code setup.
No. t3code#4239 reports that T3 Code unconditionally sets OPENCODE_CONFIG_CONTENT to an empty object in the child environment, so custom providers in opencode.json never appear. Standalone OpenCode is unaffected; the bug is in the driver.
Usually not. T3 Code only offers Claude providers that use the same config directory for an existing thread, and this setup deliberately uses its own. Start a new thread on the Continuum provider.
Run /status inside a Claude session in T3 Code. It prints the Anthropic base URL in effect, which is the only check that reports what the running child process actually received.
Sources
Every figure above was read from these pages on August 2026. Vendors reprice without notice; if you find a stale number, tell us.
- T3 Code docs: Claude providers the provider fields, the CLAUDE_CONFIG_DIR-not-HOME rule, the environment-variable pane, the Sensitive flag, the model-role variables, the /logout caveat, and the Launch-arguments warning
- T3 Code docs: Codex providers "I Need A Different API Key Or Endpoint" points at the same per-provider environment pane
- t3code#4941: OpenAI-compatible provider by base URL the feature request for a native base-URL provider; open when read on 13 August 2026
- t3code#4239: opencode subprocess forced to an empty config the OPENCODE_CONFIG_CONTENT clobber that hides custom providers; open when read on 13 August 2026
- Continuum pricing plan names, prices, and which tiers include personal API keys
- Continuum hosted inference the model lanes and the gateway surfaces, read 13 August 2026; the live /v1/models endpoint itself needs a cont_sk_ bearer