Everyone's always talking about agentic coding harnesses: Claude Code, Codex, OpenCode, Pi... the list goes on. But what's the difference between all of them? What even Is a harness anyway?
In this thread, we'll take a look under the hood. (1/5)🧵
In this thread, we'll take a look under the hood. (1/5)🧵
It is first helpful to understand how the underlying models work. Opus, GPT 5.5, etc (the models) are all stateless -- they remember nothing between requests. That is, each time you press "enter" at the prompt factory, the harness rebuilds the entire conversation and ships it (this is why prompt caching is so important!). There is no memory sitting on the server. Whatever the model "knows" about your session exists only because the harness packed it into that one request. (2/5)
So a "harness" is really a context orchestration tool. Every request body it builds typically has the same three parts:
🟠 System Prompt: the "you are Claude Code" setup, plus injected stuff like your file tree or recent commits
🟠 Tool Definitions: a list of JSON schemas describing available tools the model has to "act", I.e., Bash, FileRead, etc.
🟠 Messages: the chronological list of user/assistant messages, as well as thinking blocks.
Since the model is stateless, the harness reassembles and resends all of these parts every turn. What differs between Claude Code, Codex, and OpenCode is not only the TUI/UX features, but how this context is managed. For instance, people like Pi because you have more control over how the harness is managed and therefore how the context is. (3/5)
🟠 System Prompt: the "you are Claude Code" setup, plus injected stuff like your file tree or recent commits
🟠 Tool Definitions: a list of JSON schemas describing available tools the model has to "act", I.e., Bash, FileRead, etc.
🟠 Messages: the chronological list of user/assistant messages, as well as thinking blocks.
Since the model is stateless, the harness reassembles and resends all of these parts every turn. What differs between Claude Code, Codex, and OpenCode is not only the TUI/UX features, but how this context is managed. For instance, people like Pi because you have more control over how the harness is managed and therefore how the context is. (3/5)
When you send a message, the harness will route your request to the appropriate LLM server, then apply some chat templates to convert the HTTP request to something the model can better understand. The harness will also add more advanced parameters to control cache, max output tokens, and other things depending on the type of request.
Given the context described above, the model will decide what tools, if any, to use. If the model chooses a tool, it will literally generate the appropriate tool use JSON and return it in the response body! This tool use is then parsed in the harness on the host machine and executed, and its output is automatically sent back to the LLM for processing. (4/5)
Given the context described above, the model will decide what tools, if any, to use. If the model chooses a tool, it will literally generate the appropriate tool use JSON and return it in the response body! This tool use is then parsed in the harness on the host machine and executed, and its output is automatically sent back to the LLM for processing. (4/5)
So while all harnesses make slightly different decisions while performing this "plan, act, verify" pattern, this loop is the common skeleton driving all agentic tasks. So let's stop talking about harnesses like they're magic! While good harness engineering helps, the real power is still in the models themselves. Everything else is just REST all the way down. (5/5)
• • •
Missing some Tweet in this thread? You can try to
force a refresh
