OpenFox: the coding agent that takes local models seriously

Level BeginnerEstimated time 30 minRead first One gateway for all your models, and three ways a local model freezes your agentsA word you don't know? Glossary

OpenFox is the agent we open first, every day. Not because it is free, but because it was designed for what a local model really is: fast, cheap, a little forgetful, and in need of a frame. Where cloud-first agents hope the model will stay on track, OpenFox writes the track down, checks it at every step, and does not stop until it is reached. With a 9B or a 27B model on your own card, that changes everything.

What you get. A complete coding agent in your browser, for any local backend (llama.cpp, Ollama, vLLM, SGLang), open source under the MIT licence, with no cost per token. Here it runs on the server with the graphics cards, and the phone app Inari drives its sessions from anywhere.

Three coding agents, three roles. OpenFox drives local models for everyday sessions. Claude Code runs both ways: on the subscription as the operations agent, and on local models as an isolated junior. Kimi Code takes the long or heavy tasks on its own subscription. All of them reach models through the same gateway or their vendor, never a private key in a script.

1. Why it is different: a contract, not a hope

Plan, then build. You and the agent break the task down together; then it implements on its own.
Acceptance criteria are a contract. Once the plan is agreed, its criteria are immutable: the agent cannot quietly redefine "done".
It loops until every criterion passes. Build, verify, fix, verify again. Small models make mistakes; this loop is what turns them into delivered work.
Immediate feedback from the language server: an invalid edit is caught at once, not three steps later.
Workflows: declarative pipelines of agent turns, sub-agents, shell commands and human gates, with a code review phase in the build–verify cycle.

2. Built for your own hardware

It detects your backend on first run and configures itself.
Real-time metrics: prefill time, generation speed, context used. You see your card work, and you see when the context fills.
Vision for every model: images are described before each turn, so even a text-only model can "see" a screenshot.
Safe parallel edits: one lock per file, so two sub-agents never write the same file at once.
Plugins for more providers, tools and commands, installable from the interface without a restart.

3. Install it in one evening

npm install -g openfox      # Node 24 or newer
openfox                     # opens the interface; the first run detects your backend

Point it at your model gateway rather than at one model server: the gateway knows which model is on which card, OpenFox only needs one stable address. Run it on the machine with the cards, and reach it from the laptop or the phone through your private network.

OPENFOX_LLM_URL=http://your-gateway:4000/v1 \
OPENFOX_MAX_CONTEXT=65536 openfox --no-browser

Declare the real window of your model with OPENFOX_MAX_CONTEXT. The default assumes 200,000 tokens; a local model with 64k would overflow long before OpenFox compacts.

4. Run it as a service on the server

Ours runs as a user service on the machine with the cards, listening only on the private network, so the laptop and the phone reach the same sessions:

[Service]
Environment=OPENFOX_HOST=<the server's private-network address>
Environment=OPENFOX_LLM_URL=http://127.0.0.1:4000/v1
Environment=OPENFOX_MAX_CONTEXT=180224
Environment=OPENFOX_LLM_TIMEOUT=900000
Environment=OPENFOX_WORKDIR=/srv/devlab
Environment=OPENFOX_DEFAULT_AGENT=fh-coder
ExecStart=%h/.local/bin/openfox

A long timeout (15 minutes) leaves room for a large model reading a long prompt; the work folder confines projects to one tree; the default agent is our own (see FH Coder). Agents, workflows and skills live as plain files in ~/.config/openfox/, easy to version.

5. What we added around it

It follows the card. A small follower reads which model each card declares and rewrites OpenFox's default model to match: the agent's configuration follows the hardware, never the reverse.
A context meter in the status bar of the laptop (see three small tools).
Phone and desktop clients: Inari and FoxDesk open, follow and approve its sessions.

Traps

Keep the tool list short. Our first turn weighed 8,455 tokens before a single word, mostly tool descriptions: one permanent tool server instead of five, tools loaded on demand.

Never let two processes write its configuration file at once: two parallel registrations left us a corrupted config.json. Keep a copy before changing it.

Test it where it is used. A model that answers a curl is not a working agent; the proof is a session where it calls a tool and uses the result.

Sources

OpenFox, official repository

Found this useful? Tell us what to measure next.