Cloud & remote models

OptiQ Code is built for local models, and that stays the default. But the client is a plain OpenAI-compatible consumer, so it drives any endpoint that speaks the Chat Completions API. When you would rather not run a model locally, point it at a cloud provider like OpenRouter, or at your own remote server, and bring your own key.

Point it at an endpoint

Three settings do it: the base URL, your API key, and the model name. Set them as environment variables, or with the matching flags.

Example: OpenRouter

Run OptiQ Code against Qwen3.5-397B-A17B hosted on OpenRouter. The model runs on their hardware; OptiQ Code drives it exactly as it drives a local one.

# point at OpenRouter with your key, and name the model
$ export OPTIQ_BASE_URL=https://openrouter.ai/api/v1
$ export OPTIQ_API_KEY=sk-or-v1-...
$ export OPTIQ_CODE_MODEL=qwen/qwen3.5-397b-a17b
$ export OPTIQ_CONTEXT_WINDOW=131072

# drive it in a repo (interactive)
$ cd my-project && optiq code

# or headless toward a goal
$ optiq code -p "Fix the failing test in parser.py"

Because OPTIQ_BASE_URL is set, OptiQ Code attaches to that endpoint and never spawns a local server. Name the model with OPTIQ_CODE_MODEL (or --model): a cloud endpoint lists many models, so there is nothing to auto-discover, and an explicit name is required.

Compaction needs a window

On a local optiq serve, OptiQ Code reads the context window from the server and compacts old tool output before it overflows. A cloud endpoint has no such probe, so set OPTIQ_CONTEXT_WINDOW to the model's window in tokens. Without it, compaction stays off and a long task can run past the model's limit.