en:twine
AI Strategy & Compliance● 7 September 2026

Minimal Coding Harness: building for less on European infrastructure

A minimal coding harness saves tokens by processing tool and shell output locally, on open-source European infrastructure.

D
Dennis Verstappen
AI Architecture, Strategy & Commercial
Robin works on a laptop while Twijn floats beside it; a long receipt strip curls over the edge of the desk

Where do tokens leak away when building with AI? The answer lies mainly in shell output, tools, and verification steps around the model, and much less in the model itself.

A coding harness is that layer around a coding agent: configuration, tools, compression, and verification. What a harness does in general and why you want to own that layer is covered in the guide to building your own AI agent. At en:twine, we built an optimised version on top of the Pi harness. It is now available through the AiOps Community GitHub, under the MIT licence, as Minimal Coding Harness. It is less than 900 lines of code on top of Pi.

The occasion was the AiOps Community AI Hackathon, hosted at Yoink, with OpenValue, orq.ai, and GreenPT. The assignment was clear: build a working sustainability tracker with as few tokens and LLM calls as possible. Planning with large models was allowed, but the build run had to be done entirely by an open source model. Lynn and Dennis actively used the harness there.

Where a coding agent spends its tokens

A coding agent’s budget largely goes on everything surrounding the writing of code. The shell output of a test run enters the context in full, including hundreds of identical lines. The counter tracking how much you spend is itself a block of text in the conversation. A verification step becomes an extra model call, while npm test simply returns an exit code. Five skills you never enabled appear in every system prompt.

In other words, you pay for your own bookkeeping. With an open source model that has a tighter context window, that bookkeeping consumes the budget you wanted to use for the actual task.

Three choices that reverse this

All three share the same idea: do it locally if it can be done locally.

  1. Compression happens before the model sees anything. For output of 25 lines or more, three or more identical lines become one line with a counter after it. Output longer than 8,000 characters is truncated while preserving the beginning and end, because that is where you find the error. This happens in Node before the result reaches the context.

  2. The usage summary never goes back into the conversation. After each task, your terminal shows the number of requests, input tokens, cached tokens, output tokens, cost, and current context usage. In the repo, those lines are called receipts, and they stay entirely local. The model knows nothing about them and therefore spends no tokens on them. At a configured threshold, 12,000 tokens by default, you receive a warning that it is time to wrap up or start /new.

  3. Verification costs no request. Set verifyCommand to "npm test" and the harness runs it locally as soon as the model is finished. You get pass or fail without another call.

A skill that is mostly about stopping

The harness comes with one skill, build-more-with-less, and most of it concerns stopping. Seven rules: the smallest verifiable change, no added dependencies, never the same failed approach more than twice, done as soon as the acceptance criteria are green.

That also includes the agent writing back no more than three short bullets and no progress narrative. That sounds cosmetic. But output tokens are the most expensive ones you buy. The result is a build run that stays cheap and fast, even on an open source model with a tight context window.

Extending it is easy

Pi’s strength is that you can add your own tools and skills without fuss. A custom skill is a SKILL.md in .pi/skills. A custom tool or behaviour rule is a TypeScript file in .pi/extensions.

The six bundled extensions total just over six hundred lines and are intended to be read as examples: compress hooks into tool_result, verify into agent_settled, and budget into usage events. That is most of the API surface you need. If you want browser control, set browser: true and make sure browser-harness is in your PATH.

Orchestrating from large to small

This works best as the final stage of a chain. That is exactly what we did at the hackathon. First, plan the frontend and backend with a large model. Then write build instructions for each component with exact acceptance criteria. Next, have the open source model build those instructions one by one.

The underlying pattern: let the expensive model think and specify, let the cheap model type. Good build instructions with firm acceptance criteria make the build run practically one-shot. My impression was that the final solution built by DeepSeek was close to the version a frontier model would have produced. We did not compare that systematically.

Mei slides build instructions across the table to Twijn, who carries out the task on a laptop

The harness is the receiving end of that. It expects a bounded task with a verification command, and it stops as soon as that is green. Lynn describes how we run en:twine with two people and several AI agents, showing the same pattern beyond development.

Does this run entirely within the EU?

There is another reason we find this setup interesting. The endpoint you choose determines both what you pay per token and where your code ends up. The entire chain can stay within the European Union. The only thing that goes over your network is the request to that endpoint. Everything else is on your own machine.

GreenPT, a Dutch company based in Utrecht, works well for that endpoint. GreenPT was a hackathon partner and is the profile we tuned for, so read this as one tested endpoint, not a market comparison. The documentation states that all processing stays within the European Union: Scaleway in France handles infrastructure, and Inceptron in France and Finland handles model inference, in data centres running on renewable energy. For many organisations, knowing where their infrastructure is and who does the processing has become essential.

If you want stricter control, baseUrl is simply a setting. Point it to a local Ollama or vLLM server and nothing leaves your machine at all. The harness cannot tell the difference.

Getting started

The installation steps are in the repo’s README. You need Node 20.12 or newer and an OpenAI-compatible endpoint with a model and a key.

The key goes in the ignored .env, never in the config. In harness.config.mjs, set baseUrl, model, and workspacePath. The last one points to the repo to be built, keeping the harness outside your application.

The harness is tuned and tested on GreenPT with glm-5.2-honey, which according to GreenPT combines GLM 5.2’s coding performance with Honey’s compression rules at the endpoint. If your key does not provide that variant, use glm-5.2 with compression: "skill", and the harness loads the bundled Honey Lean rules locally. Any other OpenAI-compatible endpoint also works.

The harness is open source, so issues and pull requests are welcome in the repo. If you get stuck setting it up or adapting it, contact us.

Credits

Minimal Coding Harness is an open source collaboration between the AiOps Community and en:twine. The project is hosted on the AiOps Community GitHub and was developed out of en:twine.

It is a configuration and extension layer on top of Pi by Mario Zechner, maintained by Earendil Works, pinned to version 0.81.1 as a local dependency. Pi does the heavy lifting; we added a thin, economical layer around it. The bundled Honey Lean skill belongs to GreenPT and retains its own MIT licence.

A note on how this was made: our content is AI-assisted. We use AI for research and drafting a first concept. A human reviews and edits the text and takes responsibility for everything we publish. Read how we make our content.

NEXT STEPGET STARTED

Would you like to map this out for your own business?

The AI Readiness Scan takes 10 minutes and identifies which processes to tackle first, with an indication of ROI per use case.