Reasonix: History, Architecture, and Coding-Agent Comparison¶
Verified through: 2026-07-22.
Executive finding¶
Reasonix is an independent, MIT-licensed coding-agent project owned by
esengine; it is not a DeepSeek-AI repository or an official DeepSeek client.
It began on 2026-04-21 as a TypeScript/Ink experiment whose differentiator was
the economics and protocol behavior of DeepSeek models. On 2026-05-29, its
maintainers created a second, unrelated Git root and imported a completed Go
rewrite that had temporarily been developed as duo. The current default
branch is this Go generation, released as Reasonix 1.x.
The shortest fair characterization is:
Reasonix started as a DeepSeek-specific cache experiment and evolved into a configurable Go agent platform that retains DeepSeek-oriented defaults, reasoning-field handling, and cache-stable session design.
That is more precise than either “DeepSeek-only wrapper” or “fully neutral multi-provider framework.” Its provider registry can use OpenAI-compatible endpoints without code changes, but its identity and several architectural choices still come from DeepSeek's prefix-cache economics.
Revisions inspected locally¶
The repositories were cloned under /Users/mac/projects/github and inspected
at these revisions. The path records the local audit snapshot; it is not a
portable installation requirement.
| Project | Local directory | Revision inspected | Default branch at inspection |
|---|---|---|---|
| Reasonix | deepseek-reasonix |
c53c13c178ba9d60b8ce600c24810cda0563282a |
main-v2 |
| OpenCode | opencode |
0a601cf334b9a83cc2854108a2b860f25e6e7e8e |
dev |
| Pi Coding Agent | pi |
dd6bea41efa8caa7a10fe5a6401676dc5699f83f |
main |
| OpenAI Codex | openai-codex |
963cda85aa2a4cfb85e52d771d22d9f3069951fa |
main |
| Claude Code | claude-code |
ac062f33ab0ca7c62b9df648d0f2027fa9b969f0 |
main |
“Picode” is ambiguous. This study interprets it as Pi Coding Agent, whose
former badlogic/pi-mono GitHub location redirects to the current
earendil-works/pi repository and whose executable remains pi. A different
project named Picode would require a separate comparison.
The existing /Users/mac/projects/github/codex directory was preserved because
it was a source snapshot rather than a Git checkout. The fresh OpenAI repository
therefore uses openai-codex.
Part I — How Reasonix began¶
1. The repository contains two histories, not one continuous rewrite¶
git rev-list --max-parents=0 --all returns two roots:
| Root | Date | Meaning |
|---|---|---|
e9e7ccc62237e0b6dca70849c3f5647ad639edb7 |
2026-04-21 | TypeScript v0.0.1 lineage |
32a4c02e5446bb38eaf8efb7592bef3d249ea195 |
2026-05-29 | clean-slate Go generation |
This matters. A normal rewrite retains parentage, so blame/log can connect new
code to earlier decisions. Reasonix used an orphan branch: the Go root has
no parent. The next commit says that the already-finished implementation was a
“code-only import” and that its upstream duo history was not included. The
public repository can therefore establish the import event and the resulting
architecture, but it cannot reconstruct every design iteration made while
duo was being developed. That interval has evidence class U — Unknown.
2. v0.0.1 was a thesis, not a generic product¶
The first commit described three pillars:
- Cache-First Loop. Keep an immutable prompt prefix, append new turns and tool results, and isolate volatile state. DeepSeek's automatic prompt cache rewards exact repeated prefixes; changing earlier bytes turns what could be cached input into newly processed input.
- R1 Thought Harvesting. Parse DeepSeek's separate
reasoning_contentstream and carry selected planning signals into agent state. - Tool-call repair. Recover malformed or truncated tool calls, flatten nested arguments, scavenge partial calls, and stop repeated call storms.
The initial stack was Node.js 20+, TypeScript, ECMAScript modules, React, and Ink. Its README explicitly listed multi-agent orchestration, retrieval-augmented generation, multiple providers, and a web service as non-goals. The original identity was therefore unusually narrow: make DeepSeek inexpensive and robust inside long tool-using sessions, not build a universal coding-agent platform.
3. The first benchmark caused a public thesis correction¶
On the launch day, an 18-run “harvest” experiment compared a baseline, DeepSeek reasoner, and reasoner-plus-harvesting across six math/logic tasks. The maintainer reported that the baseline and ordinary reasoner passed all six, while the harvesting mode had one timeout. The commit explicitly rejected the claim that harvesting improved answer accuracy and reframed its possible value as introspection or tool-sequence steering.
This is historically important for two reasons:
- the project did not preserve all three original pillars as equally validated product claims; and
- cache reuse, not harvested reasoning, remained the strongest measured part of the initial thesis.
The experiment is a project-authored artifact, not an independent reproduction. Its tiny task set cannot establish general coding quality, but it can establish what claim the project itself decided not to make.
4. The TypeScript line rapidly expanded beyond its original non-goals¶
The legacy log shows a compressed product-discovery cycle:
| Date | Public-history milestone | Interpretation |
|---|---|---|
| 2026-04-21 | transcript replay/diff, MCP client, reasonix code edit workflow |
observability and tools arrived immediately |
| 2026-04-22 | project memory and Plan Mode | long-lived project state and role separation began |
| 2026-04-23 | subagents through skills | the initial multi-agent non-goal was relaxed |
| 2026-04-26 | feature catch-up against Codex, Claude Code, and Cursor; semantic search | competitive product breadth became explicit |
| 2026-04-28 | web dashboard | the initial “no web UI” boundary was relaxed |
| May 2026 | many 0.x releases, a Rust-TUI experiment, then return to Ink | the team explored packaging and interaction architecture quickly |
| 2026-05-29 | v0.54.x era and Go orphan root | incremental evolution ended in a replacement kernel |
This is not hypocrisy; non-goals often describe a release boundary rather than a permanent constitution. But it means the v0.0.1 README must not be used as a description of current Reasonix.
5. The Go rewrite reset implementation lineage¶
The Go root says:
- kernel rewritten from TypeScript to Go;
- web client removed at the reset;
- desktop client rebuilt;
- legacy TypeScript retained separately.
Twenty minutes later, commit 7de6a247... imported 92 files and about 13,480
inserted lines from duo, renamed every duo identifier to Reasonix, and
described a registry core, OpenAI-compatible provider, built-in tools, MCP over
standard input/output and HTTP, permissions, sandboxing, custom commands,
references, and two-model collaboration. Both rewrite commits include a
Claude-Opus co-author trailer. That trailer is evidence of credited assistance,
not evidence that the model independently designed or authored the entire
rewrite.
Reasonix 1.0.0 was marked released on 2026-06-02. In the migration guide, “v1” means the legacy codebase generation even though it used 0.x semantic versions, while “v2” means the Go generation that uses 1.x releases. Branch labels and semantic versions therefore cross:
That naming is a frequent source of confusion.
Part II — The current Reasonix architecture¶
1. System topology¶
The present system is better pictured as a shared controller and event model behind several interfaces, not as a terminal script wrapped around one API:
CLI/TUI Wails desktop VS Code / ACP HTTP/SSE workbench
\ | | /
+-------- transport-neutral controller and typed events --------+
|
Agent or Coordinator
/ \
Provider registry Tool registry
| / | \
model endpoint built-ins MCP subagents/skills
|
permissions -> sandbox -> host OS
session JSONL / archives / history / memory / compaction
The architecture document states an acyclic dependency direction from command surfaces into agent/plugin/config, then into tools/providers. This makes the agent loop reusable by terminal, HTTP streaming, Agent Client Protocol (ACP), desktop, and remote-workbench surfaces. The visible clients do not each implement an independent agent.
2. Provider abstraction: extensible, but deliberately small¶
At the core is a Go Provider interface with a streaming method. Factories are
registered by provider kind, while a configuration instance supplies name,
base URL, model, API key, and extra options. The built-in openai kind speaks
the OpenAI-compatible chat-completions protocol. A new compatible vendor is a
configuration entry rather than a source-code branch.
This creates two limits:
- it is genuinely no longer hard-locked to DeepSeek; but
- compatibility is initially protocol-shaped. A provider with semantics that cannot be represented through this protocol or its extra fields needs a new implementation, transformations, or a gateway.
Reasonix also round-trips model reasoning fields where supported. This is more
than displaying hidden thoughts: DeepSeek-style reasoning_content may need to
be serialized back with the assistant turn so a following request remains
valid and cache-compatible. Model-specific behavior therefore survives beneath
the generic provider interface.
3. The agent loop¶
The engineering specification describes the loop as:
build request with tool schemas
-> Provider.Stream
-> emit text/reasoning deltas and accumulate tool-call deltas by index
-> if there is no complete tool call, finish
-> otherwise permission-check and execute each complete call
-> append assistant call plus matching tool result
-> repeat up to maxSteps
Incomplete streaming fragments are not exposed to the tool executor. Tool
errors become observations for model self-correction rather than fatal process
errors. A context.Context carries cancellation into provider and tool work.
This loop is conceptually conventional; Reasonix's differentiation lies in the state invariants around it.
4. Prefix-cache stability as a state invariant¶
Autoregressive providers compute key/value states for the request prefix. A server-side prefix cache can reuse that work only when a sufficiently long prefix is identical under the provider's cache-key rules. Agent scaffolds often damage reuse by rewriting system prompts, reordering tool schemas, inserting volatile clocks/status, or repeatedly summarizing early history.
Reasonix's response is architectural:
- keep standing instructions and environment information stable and deterministic;
- canonicalize tool schemas and avoid needless ordering changes;
- append messages and tool results rather than editing old turns;
- shorten old tool results deterministically before asking a model to summarize;
- make summary compaction infrequent and observable as a cache-reset point;
- keep planner and executor in separate sessions so switching models does not mutate one shared prefix.
This does not mean a conversation can grow forever without cache misses. Model context windows are finite, provider caches can evict entries, and a summary necessarily changes the subsequent request. It means the runtime tries to make invalidation low-frequency and intentional.
5. Tiered context management¶
The inspected specification exposes three approximate pressure stages:
- At the tool-result snip ratio (default 0.6 of configured context), old large results are replaced by deterministic head/tail forms while message pairing remains intact.
- At the compaction ratio (default 0.8), stale tool results are archived and pruned to placeholders; only if the request is still too large does a model produce a digest.
- At the force ratio (default 0.9), a fold may proceed even when ordinary fold economics would skip it.
Recent results and errors are preferentially retained. User briefs below the
pin budget and previous digests survive the fold verbatim; dropped originals
are archived as JSON Lines. A BM25-based history tool can search saved session
transcripts and archives, while a separate memory tool searches durable facts.
There are three different notions here:
- active context: bytes sent on the next model request;
- durable transcript/archive: data retained for traceability or resumption;
- retrievable memory/history: data that can be searched back into a later turn.
Conflating them leads to false claims such as “nothing is ever forgotten” or “the whole transcript is always in context.”
6. Two-model collaboration is session separation, not expert routing¶
When planner_model differs from the executor, Coordinator maintains two
independent histories:
- a lower-frequency planner receives standing memory and a filtered read-only research tool set, then emits a concise plan;
- the full executor receives that plan as structured text and performs writes and commands through the normal agent loop.
This is application-level orchestration. It is unrelated to Mixture-of-Experts routing inside a neural network and does not jointly train the models. Its specific cache advantage comes from never swapping two providers inside one conversation prefix.
7. Tools and MCP¶
Built-in tools implement a small interface: name, description, JSON Schema, and execute. A per-run registry combines enabled built-ins with external tools. External plugins are MCP servers reached through:
- a persistent local subprocess over JSON-RPC standard input/output;
- Streamable HTTP, including Server-Sent Events responses; or
- the legacy HTTP-plus-SSE transport.
MCP tools are namespaced and their readOnlyHint annotations influence
parallel dispatch and default permission classification. Reasonix explicitly
warns that those annotations are assertions by an installed server, not a
containment boundary against a malicious server. Project-discovered MCP
configuration requires an identity-specific launch confirmation, whereas an
explicit user installation is itself an authorization decision.
This distinction is sound: tool metadata, permission policy, and process containment are separate trust layers.
8. Permission is not sandboxing¶
Reasonix uses both:
- a per-call policy returns allow, ask, or deny, with deny taking precedence; and
- a lower enforcement layer confines filesystem and shell effects where the operating system provides a backend.
At the inspected revision, documentation describes macOS Seatbelt
(sandbox-exec) and Linux bubblewrap for shell confinement; Windows lacks an
equivalent built-in operating-system shell sandbox. In enforcement mode, a
missing backend causes shell execution to fail closed rather than silently run
unconfined. File tools also apply workspace/read/write root rules.
Approval protects intent; sandboxing limits effects after approval or model error. Neither completely neutralizes prompt injection, compromised build scripts, malicious MCP servers, or credentials deliberately placed inside an allowed boundary.
9. Why the project still calls itself DeepSeek-native¶
“Native” here is a runtime-optimization claim, not ownership or model lineage. It refers mainly to:
- design around DeepSeek prefix-cache behavior and cached-input economics;
- explicit reasoning-stream handling and round-tripping;
- model presets, pricing, and defaults oriented toward DeepSeek;
- cache observability and separate-session orchestration.
The current configuration-driven provider layer means “DeepSeek-native” no longer means “DeepSeek-only.” A more exact label would be DeepSeek-first, OpenAI-compatible multi-provider harness. Whether another provider receives equal quality depends on protocol fidelity, tool-call behavior, reasoning-field semantics, cache rules, and maintainer testing—not merely whether its endpoint accepts the request.
Part III — Comparison with OpenCode, Pi, Codex, and Claude Code¶
High-level matrix¶
| Dimension | Reasonix | OpenCode | Pi Coding Agent | OpenAI Codex | Claude Code |
|---|---|---|---|---|---|
| primary design center | DeepSeek-efficient long sessions | broad provider platform and clients | minimal, user-modifiable harness | OpenAI-native local/cloud coding system | Anthropic-native integrated product |
| current core | Go | TypeScript/Bun with Effect-based components | TypeScript packages | Rust workspace | proprietary core; public plugins/artifacts |
| provider posture | OpenAI-compatible registry, DeepSeek-first | broad provider/model normalization | 15+ providers and custom providers | OpenAI/Codex service and Responses semantics | Claude models and Anthropic service |
| topology | shared controller behind CLI/desktop/ACP/web | HTTP server + OpenAPI/SDK + clients | library/CLI/RPC/SDK in one small stack | local core + app-server + IDE/app/cloud | terminal/IDE/GitHub/remote product |
| default product policy | plan/executor, permissions, sandbox, memory | build/plan agents, subagents, permissions | intentionally omits built-in plan/subagent policy | approvals, native OS sandbox, skills/MCP/multi-agent | permissions, sandbox, subagents, hooks/plugins |
| extension center | TOML, built-ins, MCP, skills/hooks | plugins, MCP, skills, agents, server API | trusted in-process TypeScript extensions | skills, MCP, plugins/connectors, app-server protocol | skills, agents, hooks, MCP, plugins/marketplaces |
| state emphasis | append-oriented cache stability, archives, retrieval | durable server/session state; V2 moving toward SQLite admission | tree-structured JSONL sessions and branching | typed threads/turns/events across clients | resumable/checkpointed sessions by documented behavior |
| built-in containment | policy + macOS/Linux shell sandbox; Windows limitation | permission rules; implementation-specific process controls | no built-in sandbox by design | deep cross-platform system sandbox and approval model | documented permission/sandbox system; core not auditable |
| open-source boundary | core open under MIT | core open under MIT | core open under MIT | local runtime open under Apache-2.0 | public repository all-rights-reserved, core absent |
Public-origin chronology¶
The earliest reachable Git commit and the creation time of the current GitHub repository are different facts. A repository can import or merge history older than the repository object itself, as OpenCode demonstrates.
| System | Current GitHub repository created | Earliest relevant public root/milestone | Caution |
|---|---|---|---|
| Claude Code | 2025-02-22 | research-preview repository root, 2025-02-22 | root is a product page, not core source |
| OpenAI Codex | 2025-04-13 | TypeScript CLI root, 2025-04-16 | Rust arrived in parallel eight days later |
| OpenCode | 2025-04-30 | reachable Go root, 2025-03-21 | older and multiple roots reflect synchronized/merged history |
| Pi | 2025-08-09 | general pi monorepo root, 2025-08-09 |
coding-agent package appeared in October |
| Reasonix | 2026-04-21 | TypeScript v0.0.1 root, 2026-04-21 | Go generation adds a second root on May 29 |
These dates establish public artifact lineage, not the first private prototype, company decision, or idea. Those earlier events are unknown unless the maintainers disclose them.
1. OpenCode: a platform first, not a model-economics experiment¶
OpenCode's visible history begins with a Go codebase on 2025-03-21, before the current GitHub repository's creation date. Its history includes synchronizations and merges from other roots, a phase combining a Go Bubble Tea TUI with a JavaScript/TypeScript server, and a 2025-11-02 commit that removed the Go TUI. The current default development branch is a TypeScript/Bun monorepo.
Current OpenCode starts a server even when the user launches the TUI. The TUI is a client, the HTTP endpoint is described by OpenAPI, and generated SDKs let desktop, web, IDE, and programmatic clients share the same backend. That client/server boundary is more central than in Reasonix, whose specification starts from a compact Go kernel and transport-neutral controller.
OpenCode also treats provider breadth as a first-class product problem. Its source contains extensive model-specific normalization around reasoning, caching, schemas, and provider options. This breadth is not “free neutrality”: the project carries compatibility code precisely because vendors differ.
Its default agent concepts include full build and read-only plan roles, general
subagents, fine-grained permission rules, MCP, skills, Language Server Protocol
integration, and plugin-defined tools. At the inspected dev revision, an
ongoing V2 session architecture separates durable prompt admission from model
execution, uses a process-global per-session execution coordinator, and scopes
model/tool/permission services to a workspace location. These are current
development-branch contracts, not guaranteed stable-release behavior.
Practical difference from Reasonix: choose OpenCode when broad provider choice, multiple clients, server automation, and ecosystem scale are primary. Choose Reasonix when a small static Go distribution and explicit DeepSeek/cache-oriented behavior are primary. OpenCode can optimize caching, but cache stability is not its founding invariant.
2. Pi Coding Agent: a substrate with intentionally less built-in policy¶
Pi's history did not start with a coding agent. The 2025-08-09 root created a
three-package monorepo containing terminal UI, generic agent, and GPU-pod
functionality. A coding-agent work-in-progress appeared on 2025-10-17; the
package became @mariozechner/pi-coding-agent in November. In 2026 the project
moved to Earendil Works, shed unrelated pod/messaging packages, and renamed its
published package scope to @earendil-works.
The current stack is deliberately layered:
pi-ainormalizes model providers;pi-agent-coreexposes a generic event-driven loop and state;pi-tuisupplies terminal components; andpi-coding-agentassembles the coding product.
Its loop distinguishes an outer queue of user follow-ups from an inner
assistant/tool loop and exposes event streams, steering, optional parallel tool
execution, and a convertToLlm boundary. The product supports interactive,
print/JSON, RPC, and SDK modes. JSONL session records form a tree using message
and parent identifiers, so branching does not require copying a linear chat.
Pi's strongest difference is philosophical. It intentionally skips built-in subagents and plan mode, expecting extensions or packages to implement the workflow a user wants. Extensions are trusted TypeScript modules running in the same process with the user's permissions. Official security documentation is explicit that project trust only controls whether project-local settings and extensions load; it is not a sandbox. Real isolation must come from a container, virtual machine, micro-VM, or an extension that redirects execution.
Practical difference from Reasonix: Pi is the cleaner choice for embedding, teaching, or inventing a bespoke agent policy. Reasonix supplies more policy and containment out of the box. Pi's smaller core is flexibility, not an unfinished attempt to replicate every Claude Code feature.
3. OpenAI Codex: a systems-engineered OpenAI agent stack¶
Codex CLI began as TypeScript on 2025-04-16. Only eight days later OpenAI imported an initial Rust implementation, explicitly citing standalone binaries, lower overhead, and direct access to Linux sandbox APIs. The implementations coexisted while Rust caught up; the TypeScript implementation was removed on 2025-08-08.
The current Rust workspace has a typed session/turn protocol, an asynchronous
turn loop, and a ToolRouter that separates model-visible specifications from
runtime handlers. Tools can declare parallel-call support. A large app-server
JSON-RPC boundary exposes threads, turns, streaming events, configuration,
skills, MCP, plugins/connectors, feedback, and other product operations to
clients. This makes Codex both a local agent and a platform component behind
IDE and desktop experiences.
Codex's most visible architectural specialization is system safety. The open runtime contains native sandbox paths for macOS and Linux and Windows-specific isolation work, combined with approval and permission profiles. OpenAI's first-party architecture material describes the CLI as a cross-platform local agent and the app as reusing configurable system-level sandboxing.
Its model layer is vertically integrated with OpenAI account/API authentication, Responses API items, Codex model behavior, and optional hosted/cloud services. That coupling can support model/runtime co-design, but it is not the provider neutrality offered by OpenCode or Pi.
Practical difference from Reasonix: Codex has a deeper open local systems surface, stronger cross-platform sandbox investment, and tighter model/product co-design. Reasonix is easier to point at arbitrary OpenAI-compatible providers and uniquely foregrounds cached-input economics. Neither repository opens the frontier model weights or every hosted backend component.
4. Claude Code: compare behavior, not unavailable internals¶
Anthropic's public repository began on 2025-02-22 as a research-preview landing page. Its initial README said the preview was intended to learn how developers collaborate with Claude and listed reliability, long-running commands, and terminal rendering as improvement areas. The repository did not contain the CLI implementation then, and it does not contain the proprietary core now. Its current license states “all rights reserved” and points to Anthropic's commercial terms.
The public tree is still useful: it contains plugins, agents, commands, skills, hooks examples, a development container, issue tooling, and a detailed changelog. First-party documentation describes:
- separate-context subagents with selectable models, tools, permission modes, skills, MCP servers, and lifecycle hooks;
- foreground and background execution;
- declarative allow/ask/deny rules and several permission modes;
- hooks around tool, session, and subagent lifecycle events;
- MCP, skills, plugins, marketplaces, checkpoints/rewind, IDE and remote surfaces.
Those are D — Disclosed product contracts. They are not C — Confirmed core implementation artifacts. Claims about Claude Code's private scheduler, prompt assembly, exact compaction algorithm, internal persistence schema, or sandbox implementation must remain unknown unless Anthropic documents them.
Practical difference from Reasonix: Claude Code is a polished, Claude-specific, vertically integrated product with a broader disclosed workflow surface. Reasonix is source-auditable, model-configurable, and exposes its cache/context mechanics. A source-level claim about Reasonix can often be traced to Go; the analogous Claude Code claim usually stops at documentation or observed behavior.
Part IV — What the comparison does and does not prove¶
Common but incorrect conclusions¶
| Incorrect shortcut | Correct interpretation |
|---|---|
| “DeepSeek-native means DeepSeek made it.” | It describes optimization posture; repository ownership is independent. |
| “OpenAI-compatible means all providers behave identically.” | Request shape may match while reasoning fields, tool calls, caching, limits, and errors differ. |
| “Two models means multi-agent intelligence.” | Reasonix's coordinator is two isolated sessions with a text handoff; capabilities depend on roles, tools, and models. |
| “Project trust is a sandbox.” | Trust controls loading of local configuration/code; sandboxing constrains runtime effects. |
| “Permission prompts make execution safe.” | Approval and containment cover different failure modes and both have gaps. |
| “The project with more files or stars is better.” | Community size and code surface are not controlled task-quality evaluations. |
| “Claude Code's GitHub repository is its source.” | It is a public product/plugin repository; the core remains proprietary. |
| “An open CLI means the whole product is open.” | Models, inference, account services, cloud runners, and control planes can remain closed. |
No task-quality winner is established here¶
This study did not run the five agents on an identical commit, model, prompt, tool policy, budget, and sandbox. It therefore does not claim that one produces better patches. A defensible evaluation would control at least:
- exact model checkpoint and provider;
- context/tool schemas and repository instructions;
- token, wall-clock, and monetary budgets;
- permission and network policy;
- number of retries/subagents and human interventions;
- clean starting repository and deterministic tests;
- patch correctness, regression rate, security, latency, and cost.
Provider-neutral harnesses make model control easier but not perfect because their prompts and protocol transforms still differ. Vendor-native agents may use private model features unavailable through a common endpoint.
Decision guide¶
| If the dominant requirement is... | First system to examine | Why |
|---|---|---|
| minimize DeepSeek long-session cached-input cost and inspect that behavior | Reasonix | cache stability is a named invariant with separate planner/executor sessions |
| use many vendors through one product with TUI, desktop, web, and server APIs | OpenCode | provider normalization and client/server architecture are central |
| embed a small agent loop or invent a custom workflow in TypeScript | Pi | layered SDK and trusted extensions, intentionally minimal policy |
| use OpenAI models with strong local sandboxing and connected local/cloud surfaces | Codex | model/runtime co-design, Rust core, typed app-server, native isolation |
| use Claude with Anthropic's full integrated workflow and accept a closed core | Claude Code | deep Claude product integration, subagents/hooks/plugins/remote features |
For high-risk unattended work, the deciding question should often be the containment boundary rather than the user interface. Pi's own documentation recommends external isolation; Reasonix documents platform gaps; Codex and Claude Code still require careful filesystem, network, secret, and approval configuration.
Primary sources¶
Reasonix¶
- GitHub API, repository metadata, verified 2026-07-22.
- esengine, initial TypeScript commit, 2026-04-21.
- esengine, harvest benchmark correction, 2026-04-21.
- esengine, Go orphan-root rewrite and
duocode import, 2026-05-29. - Reasonix, revision-pinned README, engineering specification, and migration guide.
OpenCode and Pi¶
- GitHub API, OpenCode metadata; OpenCode, server architecture and agent/permission documentation, verified 2026-07-22.
- OpenCode history, initial visible root, server/TUI synchronization, and Go TUI removal.
- OpenCode, revision-pinned session source, provider transforms, and tool source.
- GitHub API, Pi metadata; Pi, product and philosophy, security boundary, and extension model, verified 2026-07-22.
- Pi history, initial monorepo, coding-agent start, package naming, and Earendil Works migration.
- Pi, revision-pinned agent loop and coding-agent package.
Codex and Claude Code¶
- GitHub API, OpenAI Codex metadata; OpenAI, Codex agent-loop engineering article and Codex app sandbox description, verified 2026-07-22.
- OpenAI Codex history, initial TypeScript commit, Rust import and rationale, and TypeScript removal.
- OpenAI Codex, revision-pinned turn loop, tool router, and app-server protocol.
- GitHub API, Claude Code metadata; Anthropic, initial public commit and revision-pinned license.
- Anthropic, how Claude Code works, subagents, permission modes, and extension features, verified 2026-07-22.
Unresolved questions¶
- The omitted
duohistory prevents a complete causal reconstruction of the Go rewrite. Only the imported result and commit explanation are public. - Reasonix's project-authored cache case studies need independent reproduction under fixed providers, cache retention, workloads, and prices.
- OpenCode's current
devbranch is actively migrating session architecture; release behavior must be checked against a tagged version before operational deployment. - Cross-harness quality and cost remain unevaluated under controlled models and permissions.
- Claude Code's internal loop, prompt assembly, persistence, scheduler, and exact sandbox implementation remain unavailable for source audit.