Claude Code runs on a local model, and 74 percent of what it sends before starting work is tool definitions

Every few months someone builds a system that runs an army of coding agents, and the first question is always whether you can point it at your own hardware instead of a metered API. Gas Town, an open-source multi-agent orchestrator first tagged in January 2026, answers that question in its own source code, in a preset almost nobody reads. It runs Claude Code, so we pointed Claude Code at a local model on a Mac, and then measured what the agent actually sends before it does a single useful thing: 29,424 tokens, of which 74 percent by size is tool definitions.

Measured on 20 August 2026 on our test machine (an M4 Pro with 48 GB, LM Studio, gemma-4-31B-it-QAT at Q4_0 with a 65,536-token context) with Claude Code CLI 2.1.153. The current release is 2.1.283; the tool count and sizes below are for the build we ran.

The short version is that the local path works and the arithmetic is brutal. Both halves matter, and the second half is the one nobody publishes.

Can Claude Code run on a local model?

Yes, and Gas Town ships the proof rather than the documentation.

Reading internal/config/agents.go in the Gas Town repository turns up a preset called groq-compound. Its comment explains the mechanism plainly: the Claude binary acts as an SDK proxy, and the preset overrides the base URL, API key and model name at spawn time to send traffic somewhere other than Anthropic.

ANTHROPIC_BASE_URL  -> https://api.groq.com/openai/v1
ANTHROPIC_API_KEY   -> $GROQ_API_KEY

The preset’s own note is the interesting part: because the transport is still the Claude binary, every Gas Town hook, session tracker and lifecycle event works exactly as it does on the standard preset. Nothing downstream knows the difference.

Swap that host for a local one and the same trick points at your own machine. There is no mention of Ollama, LM Studio or a user-facing base-URL setting anywhere in the repository, so this is a capability rather than a feature. It works because of how the redirect is built, not because anyone documented it for local use.

Two things have to be true for it to work, and both took a measurement to establish.

The first is that the server has to speak the Anthropic protocol, not just the OpenAI one. LM Studio does: a POST to /v1/messages with an anthropic-version header returns a proper content block, and with "stream": true it returns correct message_start and content_block_delta events. That is the wire format the Claude binary expects.

The second is the URL itself, and this one wastes an afternoon if you get it wrong. Set ANTHROPIC_BASE_URL to http://127.0.0.1:1234/v1 and the CLI appends its own path, producing /v1/v1/messages. LM Studio answers that with HTTP 200 and an error body, which the CLI reports as “API returned an empty or malformed response (HTTP 200)”, followed by advice to check for a proxy or gateway intercepting the request. There is no proxy. The status code is a success, the body is a complaint, and the error message sends you looking in the wrong place. Drop the /v1 and it connects.

What does a coding agent send before it does anything?

We put a logging proxy between the CLI and LM Studio to capture the exact request bodies, because the interesting number is not what the model returns but what it has to read first.

One claude -p invocation with a single short prompt produced three requests totalling 149,989 bytes. The large one breaks down like this:

That is the finding. The agent’s own instructions are the small half. Three quarters of the payload is machine-readable schemas describing 28 tools, most of which any given turn will never call, and all of which are re-sent on every request that carries them.

Our first reading of this was wrong, and the correction is worth stating because it is easy to make. LM Studio rejected the initial attempt with request (29424 tokens) exceeds the available context size (8192 tokens), and we recorded that as the size of the system prompt. It is not. It is the whole request, and the capture shows the system prompt is barely a fifth of it. An error message told us a true number about the wrong thing.

This sits alongside what we found counting the context files an agent loads. Those were 38,922 tokens across four files, and they are the part a user writes and can edit. The tool block is the part the tool ships, and on this measurement it is the larger cost of the two.

What does it cost to run one turn locally?

Eight minutes, for one line of output.

The model was gemma-4-31B-it-QAT at Q4_0, loaded at 65,536 context because 8K is not enough to hold the request at all. Two runs of the same trivial prompt:

Both sent byte-identical payloads of 149,989 bytes. The reply in each case was three words.

The second run is the one that surprised us. On this machine, repeating a prompt normally collapses prompt processing to almost nothing, because llama.cpp reuses the KV cache for any matching prefix. Here it bought six percent, and the capture timestamps show the large request itself was no faster on the second run; the saving came from the small follow-up call. We did not establish why, and will not guess at it in print: the payload is identical byte for byte, so something inside the request is defeating the prefix match, and identifying it needs another experiment. What we can say is that the caching behaviour which rescues ordinary local chat does not rescue this workload.

The rough arithmetic is consistent with our earlier measurements without matching them exactly. Cold prompt processing on this machine runs at about 65 tokens a second, so roughly 34,000 tokens of request across three calls predicts something in the region of eight to nine minutes, which is what the clock showed. We are not claiming a precise fit. Three requests, partial cache effects and a larger context window than the original benchmark all sit between the estimate and the stopwatch.

Then there is memory. At 65,536 context the backend process held 25.17 GB, which lines up with the 80 KB per token we measured for this model’s KV cache. One agent, one model, one context window, and a 48 GB machine is already more than half committed.

Gas Town’s README says it scales to 20 to 30 agents. Our two-model test on the same hardware showed that concurrent generation converges on about 9 tokens a second per model, because the GPU time-slices. Dozens of agents on one Mac is not a tuning problem. It is arithmetic.

Is Beads worth running on its own?

This is the part we would actually use, and it needs no model at all.

Beads is the work ledger underneath Gas Town, shipped as a separate MIT-licensed binary. It has more stars than the orchestrator it was built for, which tells you how many people arrived for the memory and left the agents behind. It runs completely offline.

The mechanism is a dependency graph over a work queue. Create four tasks and all four are open. Declare that the writing depends on the audit, the card depends on the writing, and publishing depends on the card, and bd ready returns exactly one item: the audit. Close it, and the queue advances by itself. Close the next, and it advances again.

That is the whole trick, and it is aimed squarely at the thing that breaks agent fleets. A coding agent’s context ends when its session ends. Thirty agents in parallel have thirty separate amnesias. Beads keeps the plan outside all of them, in a .beads/ database (embedded Dolt by default) with a JSON export carrying status, priority and a dependencies array so an agent can ask what is startable and get a definitive answer instead of re-reading a plan document and guessing.

One thing to know before running it in a real repository: bd init writes AGENTS.md and CLAUDE.md into your project root alongside the .beads/ directory.

The honest summary of a day with both is that the orchestrator is a bet on cheap inference and the ledger is not a bet at all. Beads costs nothing to run, works with any agent or none, and solves a problem you have whether or not you ever start a second agent. Gas Town on local hardware works exactly as advertised, and the eight-minute reply is the argument against it.