Zot seems interesting, this is the first time I see it. On a quickl look it seems like Pi, but in Go. I was hoping to embed Pi into some of our internal projects and the typescript stuff was blocking me, I'll definitely give Zot a look.

From the landing page:

“Written (vibe-slopped) in Go. In beta forever.”

Okay - No thanks.

Glad to see tooling in my native language. I don’t want to touch TypeScript stuff with a ten foot pole, but sadly it seems to be the lingua franca for agentic tools.

The one thing that would keep me from making the jump is CC’s auto mode.

Thought Claude models can only be used through Claude Code. I was wrong, I guess.

Anyone here using Zot and can share their experience?

I'm getting a little fatigued by all the harnesses that are made by other coding agents. Like, when I checked out opencode, it looked and felt incredibly impressive, until I looked at how frequently it completely invalidated the KV-cache. After looking at the source code, it's basically unsalvageable and I ran far far away. (It's mostly imperative garbage which is typical of undisciplined agent output. It doesn't even use React, it uses some other reactive library in a non-declarative way, I think SolidJS)

DeepSeek Reasonix is better in terms of cache stability because that is a core tenet, which should honestly be table stakes for agentic tooling, but the TUI is kind of ugly and the tools also kind of suck (they pretend the sandboxed working directory is at /, which makes the model almost unable to use MCP servers that expect to be passed filesystem paths). On top of that, it doesn't expose the structuredContent of MCP server tool responses, which is like... the entire point of it? Now all my tools that return huge swaths of JSON data into structuredContent, which Claude Code can process perfectly fine, need an additional separate path to generate readable versions of it into content because Reasonix ignores structuredContent for some reason. That's supposed to be the model-side output, while content is the user-side output, but whatever.

I don't know how much more of this I can take. I'm in the process of working on my own harness essentially from scratch, manually, because I'm so fed up with all this vibecoded tooling that misses incredibly basic and obvious design.

I feel like Claude Code used to be from scratch like this and that was why it was so good, until they started vibecoding large swaths of it and stripping away all the power-user features and good taste that made it so wonderful before. Now it even has random, inexplicable problems like "API Error: 400 messages.1.content.15: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response." which shouldn't even be able to happen!!

And like, I get the distillation angle of why thinking output was completely removed from Claude, but I work in bypass-permissions mode and I want to correct misunderstandings as I see them. This is different than wanting to review each edit.

Speaking of reviewing each edit, I hate that Reasonix doesn't print diffs, and just says "use git diff". Like, no? I want to see each change the agent made and when. I don't want to only see one diff at the end; that nearly ruins the point of conversation history.

Having just started out building my own harness because I don't like the others, I really resonate with this post. You probably should make a harness, it seems you've got a really good approach and a great understanding of what it should have.

I mostly still like Claude Code, but I agree it's getting buggy and bloated in their need to move so fast. With the June pricing changes I felt I needed to build an alternative quickly just in case, and so I can start looking at other models for my "claude -p" usage.

The videos from the makers of Pi are interesting with some useful information, but ultimately I came away deciding I would never want to use Pi.

It also helps that Pi & most harnesses don't work on a lot of older computers systems I'd like to be able to use a harness on. It's just API calls, there's no reason this shouldn't all work on much much older machines.

Thanks for sharing your experience with reasonix in detail.

Have you tried pi? I don't think I am at your level, so I'd welcome some more advanced user's advice.

Thanks for your evaluation.

I've deliberately been post-poning harness building.

I think it's great as an obligatory learning experience.

But I'm hoping someone will come along and provide the "best of breed" harness:

  - OpenCode's TUI and client-server model,
  - Claude's prompt engine,
  - Pi's extensibility, and
  - the codebase stability of a craftsman (yet to be seen).

I haven't tried other harnesses than those three. It's time-consuming, and does not align with my primary goals.

I've been reimplementing a TUI library based on Ratatui, but drawing the UI components of OpenCode's OpenTUI and a bunch of Ratatui-adjacent components. Was hoping someone would separate the concerns and reverse engineer Claude's prompt engine and just not provide a UI for it. Make it modular so each part can be replaced by something better. There's only really 3 parts: TUI library, engine, and client-server (so you can choose between web or terminal, and so you can host the engine + server in the cloud, resume your sessions, and whatever enterprise features you want for session and memory management.