What an agent harness is, and how it differs from an IDE plugin

Developers often say "the model fixed the bug" or "Claude ran the tests". Strictly speaking, the model does none of that. It does exactly one thing: takes text and returns text. Everything else — reading files, running commands, editing code — is done by the program around it. That program is the harness.

The distinction matters for a very practical reason: when an agent "can't see your files" or "refuses to work", the harness or its configuration is almost always at fault, not the model.

The loop

The harness gives the model a list of tools — usually function descriptions like "read a file", "run a bash command", "write contents". Then this happens.

The harness sends the model your task along with the tool list. The model replies not with text but with a request: call run_bash with the argument ls src/. The harness runs the command itself, on your machine, and sends the model the result. The model reads the output and asks for the next call — or, once it has enough, answers in plain text.

That loop can repeat dozens of times within a single task. The model never touches your disk: it only asks, and the harness decides and executes.

One consequence follows. If a gateway sits between you and the model, it must translate tool calls correctly in both directions. Get the translation wrong and the model starts answering "I don't have access to your files" — when it does, its request simply never reached the harness.

How this differs from an editor plugin

Editor autocomplete works differently: it takes the code around your cursor, sends it to the model, and inserts the reply. One request, one result, no loop.

The difference shows on tasks that require finding something out before writing. "Add a field to this model and fix every place it is used" is out of reach for a plugin: it doesn't know where the model is used and can't find out. A harness can — it will search the project, read what it found, and only then start editing.

The reverse holds too. For "finish this function" a harness is overkill: it will spend several requests studying what is already on screen.

Picking one

There are plenty of harnesses today: Claude Code, opencode, OpenHands, Goose, Aider, and Cline or Roo Code inside VS Code. They differ in their tool sets, their context strategies, and how eagerly they ask permission before touching files.

They share one thing: all of them run over a plain API, and nearly all let you point at your own server. Which means the model underneath is your choice, and switching costs one line of configuration.

ANTHROPIC_BASE_URL=https://api.zukko.pro
ANTHROPIC_AUTH_TOKEN=fetch_your_key

For OpenAI-compatible harnesses the address takes a suffix: https://api.zukko.pro/v1. A Zukko↗ key works with both, and billing is per token actually used — which matters for an agent loop, where the number of requests is not known in advance.

Worth keeping in mind

A harness burns tokens differently from a chat. Every tool call is a new request, and it carries the whole prior conversation plus command output. A task that would cost a couple of thousand tokens in chat easily runs to a hundred thousand in an agent loop.

So a cheap input price matters more here than in chat: in agent work, input tokens usually dominate. One caveat when comparing against vendor pricing: vendors charge about 10% of the input price for prompt-cache reads, while Zukko bills cached tokens at the regular price, so for agents with a large repeated context the real difference is smaller than a head-to-head price comparison suggests. And that is why it pays to keep an inexpensive model like GLM 5.3 ($0.10/$0.10 per 1M tokens, 128K context) around for the simple steps, saving the expensive one for the steps that genuinely need its judgment.