zot stands for zero-overhead-tool.

I've used several coding harnesses before, and much of this space is genuinely impressive and excellent: pi (my big love and most used), OpenCode, and of course Claude Code, Codex and the manufacturers' things.

I built zot for a simple reason: I wanted to understand coding agents from the inside.

Not just use them. Not just compare products. I wanted to build one myself, live with its constraints, watch where it breaks, and learn what actually matters when you're designing an agent harness that has to feel fast, predictable, and useful in a terminal.

Part of it was curiosity. Part of it was stubbornness. Mostly, it was that the desire to build my own coding agent harness just wouldn't go away.

So I stopped circling the idea and built it.

Why build another coding agent tool?

We're in a moment where coding agents are becoming a real interface, not just a demo. The interesting questions are no longer: “can an LLM write code?” but:

• How should an agent interact with tools?
• What belongs in the model prompt versus in the runtime?
• How much autonomy is useful before the experience becomes annoying or unsafe?
• What parameters actually change outcomes in meaningful ways?What kinds of feedback loops help a model recover from mistakes?

You can speculate about those questions forever, but building a harness forces honesty.

Once you have a real loop, user input, model stream, tool execution, rendering, cancellation, retries, subprocesses, context windows, output sinks, every vague opinion gets tested against reality. You learn very quickly which abstractions are elegant and which ones collapse under actual usage.

That was a big motivation behind zot. I wanted something small enough to fully understand, but real enough to teach me how these systems behave in practice.

zot as a learning vehicle

zot started as a way for me to get hands-on experience with agent systems end to end.

I wanted to understand:

• How different models behave under the same harness
• Which prompt structures hold up over repeated use
• What kinds of tool schemas models handle cleanly
• Where streaming helps versus where it just adds noise
• How cancellation, retries, and timeouts affect the feel of the system
• What knobs are there

Why Go?

One of the obvious questions is: why build zot in Go instead of TypeScript?

It's a fair question. Most of the visible tools in this space are written in TypeScript. If your goal is maximum familiarity with modern AI CLI patterns, TypeScript is the path of least resistance. The ecosystem is large, the iteration speed is excellent, and the extension story is very attractive for web developers.

But for zot specifically, Go was the right choice (I think).

The install story matters

zot is a terminal tool. I care a lot about the experience being:

• Download one file
• Make it executable
• Run it

With Go, that's easy: a single static binary, no runtime dependency, no package manager dance, no "please install Node 20+ first," no npm weirdness, no environment drift.

That simplicity is not cosmetic. It changes how willing people are to try the tool, update it, and trust it in different environments.

For a developer utility, "one binary, zero runtime" is a genuinely good product property. (In my opinion).

zot's concurrency model maps naturally to Go

zot has a lot of moving parts that want to happen at once:

• Provider stream consumption
• Output fanout
• Terminal rendering
• Subprocess extension management
• Polling or background coordination
• Cancellation and timeout propagation

That kind of system fits Go very well. Goroutines and channels aren't just a performance story here; they're a modeling advantage. They make the architecture feel direct.

Could this be done in Node? Of course. Event emitters, promises, streams, AbortController, and process management are all workable. But for this particular kind of runtime, Go feels more natural.

Go was often my first choice, even in the pre-Claude days.

Go's standard library is enough for most of zot

A lot of what zot needs is already in the box:

• HTTP
• JSON
• Subprocess execution
• File handling
• Context cancellation
• …

That means fewer dependencies, fewer transitive surprises, and less framework gravity. This is one of Go's underrated strengths for infrastructure-style tools: you can build a lot before needing to reach for a large dependency tree.

Where TypeScript would have been better

First of all, I must mention that I love TypeScript and there are real areas where TS would have been nicer:

• Extension SDK ergonomics
• JSON-shaped systems are naturally pleasant in TS
• Ecosystem momentum
• …

But Go still works for zot.

What I've learned from building it?

The biggest lesson so far is that the model is only part of the system. A lot of agent quality comes from everything around the model:

• Tool shape
• Prompt discipline
• Retry strategy
• Context selection
• Streaming UX
• Failure handling
• Cancellation behavior
• How much the harness allows versus constrains

Small runtime decisions have outsized effects on how "smart" an agent feels.

I've also learned that there's a huge difference between raw capability and usable capability. A system that can do impressive things occasionally is much less valuable than one that behaves predictably, recovers cleanly, and stays out of your way.

That's part of why building zot has been so useful to me personally. It has made the tradeoffs concrete.

Hate it, love it, use it:

• Website: https://zot.patriceckhart.com/
• Github Repository: https://github.com/patriceckhart/zot