Skip to content

Coding agents

You want the coding agent on your laptop - OpenCode, Claude Code, Codex, an editor assistant - to use your gateway instead of a vendor's endpoint. Then its traffic runs on your models, against your budgets, in your logs.

Almost every one of these tools speaks the OpenAI API, and a gateway that speaks it too is interchangeable with the endpoint the tool shipped with. Connecting one is a configuration change rather than an integration.

Prerequisites

The step-by-step guide and the console walkthrough cover the configuration. The rest of this page explains what changes once it is connected.

A connection is three values

flowchart LR
    AGENT["coding agent<br/>on your machine"] -->|"base URL + virtual key"| GW["your gateway"]
    GW --> SELF["your own models"]
    GW --> EXT["external providers"]
    GW -.->|"logged and budgeted<br/>per key"| YOU["you"]

Whatever the tool, it is asking for the same three things:

Value What it is Where it comes from
Base URL your gateway's endpoint, ending /v1 the route you created
API key your virtual key issued to you, not shared
Model name the name the gateway maps to a backend your provider registration

If a tool insists on a vendor-specific variable name, it is still these three. The names differ; the values do not.

What actually changes

Connecting an agent takes a few minutes. These are the consequences to understand before you do.

Your prompts now go where you decided. With a self-hosted model behind the gateway, the code an agent reads stays on the platform. That is the reason most teams do this, and it only holds for model names that route to your own backends - a name that falls back to an external provider sends the same code there. Know which of your names are which.

Your key now has a second holder. A coding agent is a long-running process reading your repository. Give it a key of its own rather than reusing the one an application holds, so that revoking it costs you nothing else.

Coding agents are heavy users. They send large contexts and they retry. A key with a budget and a rate limit is the difference between noticing that on a dashboard and noticing it on an invoice.

The agent reads whatever is in the repository

Files a coding agent opens become tokens sent to the gateway - including .env files, dumps and anything else that should not leave your machine. That is true of the vendor endpoint too, but pointing the agent at your own gateway is the moment to check what the tool is configured to ignore.

Not every model suits an agent

A coding agent behaves quite differently from a chat application, and a model that is fine for one can be unusable for the other.

It needs Why
A long context window it sends whole files, and its own history
Reliable tool calling the agent loop is tool calls; a model that formats them loosely stalls
Instruction-following over fluency it is producing diffs and commands, not prose

A small model served locally is excellent for completion and summarising, and often frustrating as an autonomous agent. It is worth registering both, under names that say which is which, rather than concluding the gateway is at fault.

Test the gateway before you blame the agent

One curl against the gateway with your key and model name separates three failures that look identical from inside a tool: the gateway is unreachable, the key is refused, or the model name does not exist. See Verify.

Reachability is the usual problem

A gateway is often deployed for in-cluster callers first, and reachable only inside the cluster. Your laptop is not inside the cluster. Either the gateway has a route with TLS, or you forward a port for local use - and a port-forward is a development convenience, not a way to run a team.