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:

  1. Installed the sleev command-line tool.
  2. Run sleev once to sign in and let it install and start the local gateway.
  3. 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.

  1. In the TUI, open the Config Wizard. It lists the coding tools detected on your machine.
  2. Select the harness you want to configure. sleev shows its setup panel with both an automatic and a manual option.
  1. 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.

~/.claude/settings.json
{
  "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,

~/.codex/config.toml
model_provider = "sleev"

and the second part at the very bottom:

~/.codex/config.toml
[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.

~/.config/opencode/opencode.json
{
  "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:

Claude Code sleeve-harness: claude code
anthropic
Anthropic Claude models, with a pay-as-you-go API key or a Claude Max subscription.
Codex CLI 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.
OpenCode 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:

Custom headers
# 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.