Run Cline on any catalog model via OpenAI Compatible.

Quick answer: three fields in Cline's settings.

Open the Cline panel in VS Code and click the settings gear. In the API Provider dropdown choose OpenAI Compatible, then fill three fields: Base URL https://api.apisrouter.com/v1, your key in API Key, and the exact catalog id in the model field, for example claude-sonnet-4-6. Because Cline cannot know what an arbitrary endpoint's model can do, the provider exposes model-configuration options you should set honestly: context window size, max output tokens, and capability flags like image support, plus optional input and output prices so Cline's own cost display matches reality. Set the window and limits from the model's documentation. Save, and the agent runs its next task through the gateway; the id is swappable any time without touching your workflow.

API Provider:  OpenAI Compatible
Base URL:      https://api.apisrouter.com/v1
API Key:       sk-YOUR-APISROUTER-KEY
Model:         claude-sonnet-4-6

Model config:  context window + max output tokens
               from the model's documentation,
               image support only if the id has it

How Cline uses the configured model.

Cline (roughly 65K GitHub stars) is the autonomous coding agent for VS Code: it reads your codebase, edits files, runs terminal commands, and iterates on failures, with human approval gates on the way. That loop is model-hungry in a specific shape: long contexts (file trees, diffs, terminal output) in, tool calls and code out, many turns per task. The OpenAI Compatible provider sends that loop as standard chat completions to your Base URL with the model id as a plain string. Vendor does not matter to the wire format, which is what makes model shopping real here: claude-sonnet-4-6, kimi-k2.7-code, and gpt-5.3-codex-spark are interchangeable backends behind the same three fields, instead of three separate provider configurations with three vendor accounts. The capability flags deserve care because the agent depends on them. Cline plans around what you declare: image support enabled lets it send screenshots to a model that may not accept them, and an overstated context window invites truncated-context failures deep inside long tasks. Declare what the model documentation says, not what you hope.

Plan and Act: two modes, two models.

Cline splits work into Plan mode, where it explores the codebase and strategizes without editing, and Act mode, where it executes. The API configuration follows the split: with the use-different-models option enabled, the settings show per-mode tabs and each mode remembers its own provider and model, switching automatically as you toggle. The economics of the split are the point. Plan mode is where deep reasoning pays: claude-opus-4-7 or gpt-5.5 reading the codebase and writing the approach. Act mode is many fast tool-calling turns executing a plan that already exists, which is exactly the profile of kimi-k2.7-code or claude-sonnet-4-6. Since both modes bill through the same gateway key, the pairing is a settings choice rather than a multi-vendor project. One honest caveat from the issue tracker: per-mode model selection has had rough edges specifically with the OpenAI Compatible provider, including reports of Act mode silently reusing the Plan model. After configuring the split, run one task and confirm in the task header which model actually served each mode, and check your usage log; treat the split as verified only after you have seen both ids appear.

Plan mode:  claude-opus-4-7      (read, reason, strategize)
Act mode:   kimi-k2.7-code       (execute, edit, run, iterate)

verify: run one task, check which id served each mode,
then confirm both ids appear in the usage log

Choosing coding models for the agent loop.

Agent loops multiply token spend in ways chat never does; a single Cline task can be dozens of requests carrying file context. That makes the model choice measurable: run the same class of task on two ids for a week and read the per-model spend next to how often you had to intervene.

• claude-sonnet-4-6 is the default answer for Act-mode work: dependable tool calling, strong diffs, and enough judgment to recover from failed commands.
• kimi-k2.7-code is the volume pick for long agentic sessions; code-tuned, fast, and priced for the many-turn loop that Cline actually runs.
• gpt-5.3-codex-spark earns a slot for quick scoped edits and test-fixing runs, where latency per turn shapes how the session feels.
• claude-opus-4-7 belongs in Plan mode on hard tasks: architecture changes, cross-file refactors, debugging that needs the whole picture.
• gpt-5.5 is the strong generalist to A/B against Claude in Plan mode on your own codebase, not on benchmarks.

Pay-as-you-go · transparent per-model pricing

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Failure modes specific to Cline.

Truncated or amnesiac behavior deep into a task is the context-window declaration: set it to the model's documented window, and remember that Cline packs file context aggressively, so an overstated window fails exactly on the biggest, most annoying tasks. Tool-call weirdness, malformed edits, or the agent narrating instead of acting usually means the chosen id is weak at function calling; switch to claude-sonnet-4-6 to separate configuration problems from model choice before blaming the setup. Hard errors map cleanly: authentication is the key field; model-not-found is id spelling against the /v1/models listing; 404s on every request are a Base URL missing its /v1 or doubling it. The provider appends route paths to the base you give it. And the per-mode caveat repeated once, because it costs real money when missed: if you configured different Plan and Act models, verify both ids actually serve their modes on a live task. A silent fallback to the expensive Plan model for every Act turn is the kind of thing the usage log catches on day one and a card statement catches at month end.

Who routes Cline through a gateway.

• Developers who want Claude driving their agent without an Anthropic billing relationship, on a prepaid balance with no card to start.
• Model shoppers comparing coding models on real tasks in their real codebase, where each candidate is a model-field edit.
• Heavy Cline users pairing an expensive Plan model with a fast Act model to keep long sessions affordable without losing planning quality.
• Teams metering agent spend per developer or per project with per-key usage, instead of guessing from a shared vendor bill.
• Developers already routing terminal and editor tools through a gateway who want the VS Code agent on the same key and log.

Verify the endpoint and debug the first task.

Curl the models listing and one chat completion first, with the exact id you plan to configure. Both passing means the gateway half is done and every remaining symptom is in the provider settings. Then give Cline a small real task, one file, clear goal, and watch the first turns. Clean tool calls and sensible edits mean the id and capability flags fit. Errors map to the three fields; strange agent behavior maps to model choice or declared capabilities. If you enabled per-mode models, this first task is also your verification run for the split. Once tasks flow, the APIsRouter console shows per-request model, token counts, and spend. An agent loop is the most token-intensive way to use a model, and the per-key usage view is where a week of Cline becomes a concrete number, per model, per day, per mode if you split keys.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

curl -s https://api.apisrouter.com/v1/chat/completions \
  -H "Authorization: Bearer $APISROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"kimi-k2.7-code",
       "messages":[{"role":"user","content":"ping"}]}'

FAQ