Use cases/Lanes Desktop/Point sessions at any model provider

Point sessions at any model provider

Run Claude Code or Codex against a provider you host or buy: a box on your network, OpenRouter, z.ai GLM, or anything serving the same wire format. Lanes is never in the request path.

The CLI you run does not have to use the provider it shipped with. A provider profile in Lanes points a session at a model provider of your choosing, and the harness stays exactly the same. Only where its requests go changes.

That covers three shapes: a model on your own machine, your own hardware on the network such as a vLLM box, and a provider you buy by the token like OpenRouter or z.ai GLM.

How Lanes does it

  • Presets, then one field. Start from Ollama, LM Studio, vLLM, OpenRouter, or z.ai GLM and the base URL and auth mode are filled in, or add a blank profile and type your own. Adding a profile selects it, so there is nothing else to switch on.
  • Lanes is not in the request path. A profile is applied as real process environment when the session starts, so the request goes straight from the CLI to your provider. Nothing routes through us, and the credential never reaches terminal scrollback, the command line, or ps.
  • Per session, not per app. Switch providers in the Gateway row of the session settings picker, right next to Model. A profile with no base URL does nothing at all, so the half-filled one you are still typing into cannot affect a session that is already running.
  • A probe that tells you something. Test connection sends a single one-token request. An "unknown model" result counts as success: the probe uses a placeholder model name on purpose, so the provider authenticated the request before rejecting the name, which is exactly what is being checked.
  • One profile, either harness. A profile does not name a CLI. The session already chose one, so Lanes derives the right environment variable names at launch. Claude Code is the harness whose names Lanes knows today; other CLIs are served through the profile's free-form environment table.

Name the model

The profile deliberately has no model field, because Lanes already has one: the Model row in the session picker. Type your provider's model id into the custom field there.

Default is the one guaranteed-wrong pick. With no model flag set, the harness sends its own default model id, which your provider will not serve any more than the other first-party ids. While a profile is active, that row stops offering the built-in ids for the same reason.

One extra worth setting through the profile's Extra environment table is ANTHROPIC_DEFAULT_HAIKU_MODEL, because Claude Code uses Haiku for background work like conversation titling, and those calls otherwise fail quietly.

Prefer Bearer

The two auth modes differ only in which header carries the credential, Authorization: Bearer or x-api-key. Prefer Bearer. Most providers, OpenRouter and z.ai included, only read the Authorization header, even though they call the credential an API key.

API key mode has a second problem that Test connection cannot catch. Claude Code asks you to approve an API-key variable once per machine, and the prompt's default answer is No. Decline it and the key is ignored from then on, so the session falls back to your saved claude.ai login and sends that to your provider, which rejects it with a 401, while Test connection still passes because Lanes never hits the approval gate. If you see a session 401 on a profile that tested fine, switch to Bearer.

What you give up

Routing a harness away from its own provider costs some features, and it is better to know before you start. The most common failure is a 400 on adaptive thinking, because Claude Code treats a model name it does not recognise as one that accepts adaptive reasoning. Lanes ships Disable adaptive thinking and Disable experimental betas on by default to cover that. Beyond it: web search is unavailable, prompt caching depends entirely on the provider, and Remote Control and voice dictation need a claude.ai identity. MCP itself keeps working, including the Lanes server.

Why it matters

Your subscription is not the only meter that can run a fleet. A profile lets a session use hardware you already own, or a model that is simply better at the thing in front of you, without changing the CLI, the board, or the worktree isolation around it.

Set it up

Install Lanes and open it:

Bash
brew install --cask lanes-sh/lanes/lanes && open -a Lanes

Then:

  1. Open Settings, Agentic Coding, Gateway and add a profile from a preset. Fill in the base URL and the token, leaving auth mode on Bearer.
  2. Hit Test connection. An unknown-model response is a pass.
  3. Start a session and set the Model row to a model id your provider serves. The Gateway row picks the profile, or None to go back to the CLI's own provider.

Further reading

Get Lanes Desktop or read the quick start.