Configuration
Configuring Sleev means pointing your coding tool at the local gateway so its traffic flows through Sleev before reaching your provider. Each tool keeps its own config, so the steps differ slightly per harness. The easiest path is to let the sleev CLI write the config for you, but the examples below show exactly what changes if you would rather configure things by hand.
Prerequisites
Before you configure a harness, make sure the gateway is installed and running. The Quickstart walks through this in full. In short, you should have:
- Installed the sleev command-line tool.
- Run sleev once to sign in and let it install and start the local gateway.
-
Confirmed the gateway is running locally on
127.0.0.1:17321.
You can check that the gateway is up at any time with:
Setup wizard
The easiest way to configure any harness is the setup wizard built into the TUI, and it works the same for every supported tool. Run sleev to open the TUI, then open the Config Wizard to connect your apps.
- In the TUI, open the Config Wizard. It lists the coding tools detected on your machine.
- Select the harness you want to configure. sleev shows its setup panel with both an automatic and a manual option.
- Press auto setup to have sleev write the change into that tool's config for you, or copy the config block shown and merge it into the file yourself.
Prefer the command line? The same auto setup runs as a one-shot command:
where <harness> is one of
claude-code,
codex, or
opencode. The sections below
cover each tool in detail.
Claude Code
Claude Code reads its config from
~/.claude/settings.json.
Merge the env block below into
that file: create it if it doesn't exist, or add these keys to your existing
env object.
{
"env": {
"ANTHROPIC_BASE_URL": "http://127.0.0.1:17321",
"ANTHROPIC_CUSTOM_HEADERS": "sleeve-provider: anthropic\nsleeve-harness: claude code"
}
} ANTHROPIC_BASE_URL sends Claude
Code's requests to the gateway instead of straight to Anthropic.
ANTHROPIC_CUSTOM_HEADERS adds
the two headers every request needs:
sleeve-provider tells the gateway
which upstream to forward to, and
sleeve-harness which tool's format
to expect. Your Anthropic API key stays in Claude Code's own config and is forwarded
upstream unchanged.
Codex CLI
Codex picks its upstream by named provider in
~/.codex/config.toml, which
takes two edits. If you're unsure exactly where to place them, put the first
part at the very top of the file,
model_provider = "sleev" and the second part at the very bottom:
[model_providers.sleev]
name = "Sleev"
base_url = "http://127.0.0.1:17321/v1"
wire_api = "responses"
[model_providers.sleev.http_headers]
"sleeve-provider" = "openai"
"sleeve-harness" = "codex cli"
This works because TOML requires top-level keys (like
model_provider) to come
before any table sections (like
[model_providers.sleev]).
model_provider tells Codex to
use the new provider. Pointing its
base_url at the gateway routes
Codex's traffic through Sleev, and
http_headers carries the Sleev
headers. Set sleeve-provider to
openai for an OpenAI API key,
or
codex for ChatGPT sign-in.
OpenCode
OpenCode talks to each provider directly, so you override the connection per
provider in
~/.config/opencode/opencode.json. Merge the block below into your existing config: deep-merge under
provider and
compaction rather than replacing
them. The example below configures Anthropic. Repeat the provider block under each
provider you use.
{
"compaction": {
"prune": false
},
"provider": {
"anthropic": {
"options": {
"baseURL": "http://127.0.0.1:17321",
"headers": {
"sleeve-provider": "anthropic",
"sleeve-harness": "opencode"
}
}
}
}
}
The baseURL override points that
provider's traffic at the gateway, and the headers under its
options tell the gateway which
provider semantics and harness to use. Setting
compaction.prune to
false stops OpenCode from trimming
history on its own, so Sleev manages context instead.
Providers
The harness config above sends two Sleev routing headers.
sleeve-provider selects the provider
semantics and default upstream destination, and
sleeve-harness tells it which
coding tool the request came from, so it can read that tool's wire format correctly.
Your own provider key or subscription credential travels on the same request. Sleev
never stores it, and the gateway forwards it upstream unchanged.
Which providers you can use depends on the harness. Set
sleeve-provider to one of the
values below for the harness you are configuring:
sleeve-harness: claude code -
anthropic - Anthropic Claude models, with a pay-as-you-go API key or a Claude Max subscription.
sleeve-harness: codex cli -
openai - OpenAI models with a pay-as-you-go API key.
-
codex - OpenAI's Codex backend through ChatGPT sign-in, with no separate API key.
sleeve-harness: opencode -
anthropic - Anthropic Claude models with a pay-as-you-go API key. Claude Max subscriptions are not supported here.
-
openai - OpenAI models with a pay-as-you-go API key.
-
codex - OpenAI's Codex backend through ChatGPT sign-in, with no separate API key.
-
moonshotai - Moonshot AI's API for Kimi models.
-
kimi-coding - Moonshot's Kimi coding plan subscription.
-
opencode-go - OpenCode Zen.
Custom upstream endpoints
The Sleev gateway supports forwarding requests to custom upstream destinations. Most users should leave this unset. Use it when you want Sleev to keep handling a request normally, but send it somewhere other than the provider's default endpoint, such as a local model server, company proxy, or staging relay.
Configure this in your coding tool's own config file, next to the existing
Sleev headers. The exact syntax depends on the tool; see the
Claude Code, Codex CLI, and OpenCode examples above for how each config sets request headers. Keep the tool pointed
at the local Sleev gateway, then add
sleeve-base-url with the provider
and harness values that match the request you are sending:
# Sends /v1/responses to https://proxy.example.test/v1/responses
sleeve-provider: openai
sleeve-harness: opencode
sleeve-base-url: https://proxy.example.test/v1
# Sends /v1/responses to https://proxy.example.test/codex/responses
sleeve-provider: codex
sleeve-harness: opencode
sleeve-base-url: https://proxy.example.test/codex sleeve-provider still selects
how Sleev handles the request and which provider-specific route rules apply.
sleeve-base-url only replaces
the destination base URL; it does not translate the request into a different provider's
format. The custom destination must accept the forwarded request, and the header
is stripped before Sleev sends it upstream.
The value must be a base URL with a scheme and host, using
http,
https,
ws, or
wss. Do not include a query
string, fragment, username, or password. Include a path such as
/v1 only if that is part of the
upstream server's API base.
Custom upstream endpoints are experimental. If your endpoint does not route as expected or rejects forwarded requests, contact support@sleev.ai with the provider, coding tool, and endpoint shape you are using.
Limited internet
Most users sign in through the setup wizard before configuring their coding harness. If the target machine cannot use normal browser sign-in, or if Sleev should avoid sharing tracking data and usage patterns, approved accounts can activate the local gateway with an offline license instead.
Once the gateway is licensed, the harness configuration above is the same:
your coding tool still points at the local Sleev gateway and sends
sleeve-provider and
sleeve-harness headers with each
request.
Deconfigure
To stop routing a coding tool through Sleev, remove the Sleev-specific config from that tool's harness file. In practice, that means deleting the local gateway base URL and the Sleev-specific headers shown in the sections above. Once those entries are removed, the harness will go back to calling its provider directly.
You can also open the sleev TUI and sign out. When you sign out, the TUI stops and removes any local gateway process. This will also deconfigure any detected coding harness' config file.