SuperQode 0.2.0: A Harness Engineering Framework for Coding Agents

Shashikant Jagtap

Today we are shipping the first public beta of SuperQode, an open source harness engineering framework for coding agents that is built for local and open models from the ground up.

If you have used a coding agent lately, you already know the model is only half the story. The other half is the harness: the software around the model that decides what it sees, which tools it can reach, how it remembers, how its work gets checked, and what it is allowed to do. The model does the reasoning. The harness does everything else. SuperQode is the framework for building, running, and improving that harness, and keeping it in your own repository instead of someone else’s product.

The part nobody lets you change

The way we get value out of models has moved through three layers. First we learned to write better prompts. Then we learned to assemble the right context around the prompt. The third layer is the harness: tools, memory, search, approvals, sandboxing, the workflow, the checks, and the model routing. Each layer wraps the one before it, and a brilliant prompt inside a weak harness still gives you an unreliable agent, because the harness is what controls retries, tool calls, context limits, and verification.

Here is the catch. Closed coding products ship a large, fixed harness tuned to one model family. It can be excellent, but you cannot see it, version it, or change it, and it is built to keep you on that vendor’s model. SuperQode takes the opposite position. The harness is the product, and it belongs to you.

Why this matters most for local and open models

Open weights are yours to run, but they arrive with no harness at all. Drop a capable local model into a harness designed for a frontier API and it will look weak. Not because it cannot code, but because that harness wastes its context, assumes a native tool head it does not have, and never verifies its edits. We have watched good local models get blamed for harness problems for over a year.

That is the gap SuperQode closes. It is tuned for the realities of local and open models: real context windows, prompt-based tool calling when a model needs it, post-edit verification, and a search stack that gives small models the right slice of code instead of the whole repository. The model is the part you swap. The harness is the part you build.

A harness is just a file you own

In SuperQode a harness is a single YAML file that lives in your repo. You can read it in code review, commit it, and run it the same way on your laptop, a teammate’s machine, a remote runtime, or in CI. No hidden defaults, no surprises.

# harness.yaml: the contract your agent runs by
name: my-coder
flavor: coding
runtime:
  backend: builtin
model_policy:
  primary: ollama/qwen3-coder
  temperature: 0.1
  tool_call_format: prompt      # for models without a native tool head
execution_policy:
  sandbox: docker
  approval_profile: balanced
  allow_write: true
  allow_shell: true
  allow_network: false
agents:
  - id: coder
    tools: [read_file, grep, glob, repo_search, edit_file, patch, bash]

That file is the whole contract. Change the model line and you have switched models. Tighten the execution policy and you have tightened safety. Add a tool and every run gets it. Run superqode harness explain and it reads back to you in plain English so a reviewer can actually reason about it.

Up and running in a minute

SuperQode is uv first. Install it, or run it with uvx and skip the install, then drop into the interactive workbench.

# install it, or run it without installing
uv tool install superqode
# uvx superqode

cd your-project
superqode

That opens the TUI, where you connect a model, build or run a harness, and watch every session as it happens. Prefer scripts and CI? Everything in the TUI has a headless command behind it.

Bring any model you like

Local model, open model, a hosted model with your own key, or an ACP coding agent you already run. They all go through the same harness layer, so your workflow does not change when the model does.

# inside the TUI
:connect local ollama qwen3-coder     # a model you run
:connect byok <provider> <model>      # a hosted model and your key
:connect acp opencode                 # an ACP coding agent you already use

# or from a script
superqode --print "inspect this repo and suggest the smallest next step"

Prove it before you trust it

A harness you cannot measure is just a guess. SuperQode treats evaluation as a first-class step. Write tasks, run a scorecard, and put a regression gate in front of any change, so a new candidate that breaks something the old one solved never sneaks into your daily setup. When you want to go further, optimization stages candidate harnesses, skills, and model routes for a human to adopt, so a failure gets fixed once instead of retried forever.

Local dynamic workflows with RLM

This release introduces something we are genuinely excited about: local recursive language-model workflows. When you point an agent at a giant CI log, a dense diff, a long trace, or a wide repo audit, stuffing the whole thing into the context window is the wrong move. Instead, a small local model can work through the evidence in chunks and keep the big artifact outside the prompt.

Three tools make this practical. context_handle holds the large artifact outside the context window. spawn_harness runs bounded child passes. dynamic_workflow_script orchestrates the whole thing and writes a trail to disk you can replay later. It runs in a Docker sandbox, read-only by default, with conservative recursion caps so it stays safe.

# generate a local-first harness for this machine
superqode local init --repo .

# run a recursive, local workflow over a big artifact
superqode harness eval --spec examples/harnesses/local-recursive-dynamic.yaml \
  --provider ollama --model qwen3:8b

Built to work offline

Local-first is not a slogan here. Airplane Mode prepares a strict offline harness with local repositories, local model servers, local indexes, and the network tools stripped out, and superqode local airplane doctor tells you whether you are actually ready before you unplug. Memory stays on your machine by default with simple remember, search, forget, and export, and you can connect an external memory provider only if you want one. The search stack gives models bounded reads, local and multi-repo search, optional semantic search, and offline indexes, so context never balloons.

You stay in control

Every powerful thing an agent can do is behind an explicit gate. File access, shell, network, approvals, sandboxing, plugins, MCP, and project trust are all set in the spec, not buried in a tool you cannot inspect. You decide how much rope the agent gets, and you can see that decision written down.

Fits into what you already use

The same harness runs on the builtin engine or on ADK, the OpenAI Agents SDK, the Codex SDK, the Claude Agent SDK, DeepAgents, or PydanticAI. You can expose your harness workflows as MCP tools, connect ACP clients, and run A2A workflows, all while the harness stays the portable contract. SuperQode folds every runtime’s stream into one event graph, so a run looks the same when you debug it no matter which framework produced it.

Try it and tell us what breaks

SuperQode 0.2.0 is a beta, and it is genuinely open. If you care about owning the system around your coding agent, install it, bring your own harness, run it local first, and push on it. File the rough edges. Harness engineering is the practice. Harness independence is the point.

Resources