Back to the work

Developer toolsPrivate preview

Multithread

Native collaboration
for coding agents.

I built Multithread because I was the courier between my coding agents. It now coordinates designed roles across Codex, Claude Code and a named Meta Muse collaborator, keeping each role’s purpose, ownership and handoffs attached to the work.

Linux x86-64 previewSource by invitation

An example native call and return

  1. 01

    Codex

    Scopes the task and calls a peer.

  2. 02

    Claude Code

    Works in its own session and returns findings.

  3. 03

    Codex

    Assesses them and continues on the main thread.

A workflow illustration, not a live transcript. Either provider can lead; calls use the native installations already on the machine, with their normal permissions.

Copying work between agents

I work with Codex and Claude Code on the same projects, and for a long time the way they collaborated was me. I would copy what one had done into the other’s window, explain the context it was missing, ask for a review, wait, then carry the findings back and explain those too. Every exchange was two windows, a paste, and an explanation I had already given once. When both were changing the same project, the questions got expensive: which one owned the file, which commit was the one to review, and what was still waiting when a session ended.

Multithread takes me out of the middle. From inside its own session, either agent can call the other through the installation and sign-in already on the machine, hand it a scoped task, get the answer back as the result of a command, and keep working. There is no second application and no message service. What crosses between them is the task and the answer, and a durable local record keeps the rest straight: who owns what, which exact commit was handed over, and whether anyone has acknowledged it yet. Linked Git worktrees share that record through their common repository, so it survives a closed terminal or a new session.

Assessing a peer’s return

The agent that made the call reads the findings and decides what to do with them. Agreement is not the goal; a second model family is useful precisely where it disagrees. While a call is running, the caller can send it more input, and afterwards it can go back to the exact same session for a follow-up instead of starting a stranger. The record is a set of agreements between cooperating participants. It grants no permissions, and acknowledging a handoff is not approval to merge or deploy. I still set the scope and judge the result.

Collaboration is optional, and small tasks stay with one agent. Where it earns its cost is a change that everything after it will be built on: a sensitive edit, a stalled investigation, a design that is not landing. A review there can make the immediate task slower and the whole project faster. Whether that trade pays off is a judgment each time, not a number I can give you.

Design overview

A shared record around provider-native agents.

Multithread supplies a coordination record and provider connections. Each agent is given a designed role: its purpose, scope and expected return. The provider connection lets that role work through its own agent environment. Claude Code, Codex and Meta's Muse are the current connections.

The record keeps ownership, handoffs and decisions attached to the work. An agent can ask for another perspective, assess what comes back and continue. A received message, an acknowledged handoff and an approved result are separate states.

The coordinator sets the scope and judges the contribution. Multithread adds no operating-system or account authority. A returned answer is evidence to assess, not a completed review by itself.

The evidence

Reviews of Multithread

Multithread has been used to review its own changes since the first preview. Three of those reviews are excerpted here from the project’s records: what the review found, what was decided, and the commit that carried it.

  1. v0.4.613 Sep 2026commit e943dad

    A Claude review of the change that kept a valid answer when a usage counter was malformed returned three findings. Warnings could outlive the observations they described: accepted. A provider difference in what receipts keep was hidden by the guidance: accepted as a documentation correction. A missing Codex usage update silently cleared measurements: the warning was accepted, but the suggestion to keep the old counters as current was rejected. Missing usage now reads as unknown, and earlier counters stay as history.

    The follow-up added regression checks for the accepted corrections and shipped as v0.4.6. The record is an account of this review, not a comparison against another way of reviewing.

    “It does not establish an advantage over same-family review, lower total cost, subscription-quota savings or broad reliability.”

  2. v0.4.1114 Sep 2026commit 885c481

    A Claude source review of the change that records why a caller stopped waiting caught a session warning shown too broadly and a report value the documentation never defined. Both were corrected before release.

    The affected output checks were run again after the corrections. This is the project’s retained verification record; I have not repeated that historical run for this page.

    “These checks do not diagnose the underlying provider stall or establish native workflow completion.”

  3. v0.4.1626 Sep 2026commit 9f39b1b

    Four Claude Opus reviews examined the change that added per-call model requests, content-free progress and recovery checkpoints. Material findings were resolved, and the final review found no change needed before merge.

    The project records local and hosted checks on the reviewed commit. Their recorded result does not establish broader reliability.

    “Returned model usage identified claude-opus-5-5; effective effort was not independently verified.”

On Bendr, my tube-bending app, one review call hit its turn cap. Resuming that exact session without the cap returned a critique that changed the proposal. Another call ended with nothing back, and the receipt could not say whether the caller had stopped waiting or the provider had gone silent. Since v0.4.11 the receipt records the caller’s reason. The provider’s silence is still unexplained, and the tool does not guess at it. Since v0.4.16 a Claude call can report the last native event it observed, without its content; what follows that event is still reported as unknown.

These are single observations from one developer’s machine. They do not establish onboarding for a fresh account, reliability across providers, or any saving in time or tokens; nobody has measured those. Codex and Claude Code can lead native peer calls through their existing installations. A separate adapter connects a named Muse collaborator. Current source also supports named roles, session inboxes and guarded wake messages; a message reaching an inbox does not establish that its recipient read it or completed the task. The exercised native profile remains x86-64 Linux on WSL2; broader platform support is not established.

Source by invitation.

The source is private. Read access to the repository and the full protocol documents are available on request.

Request access

A Mainthread project. Created by David Jones with Codex implementation, testing and release work, and Claude review.

Changelog

What shipped, newest first.

21 releases since 12 Sep 2026, the latest on 1 Oct 2026. From Multithread release notes.

  1. 0.4.18

    Multithread v0.4.18

  2. 0.4.17

    Multithread v0.4.17

  3. 0.4.16

    Muse agent adapter and native collaboration improvements

  4. 0.4.15

    More precise timed-out Claude peer receipts

Earlier releases (17)
  1. 0.4.14

    Clearer hook feedback when the worker fails

  2. 0.4.13

    Support for repositories before their first commit

  3. 0.4.12

    More accurate waiting feedback for Claude streaming calls

  4. 0.4.11

    Offline version discovery and caller stop reasons

  5. 0.4.10

    Recovery advice that matches where progress stopped

  6. 0.4.9

    Attributed provider diagnostics

  7. 0.4.8

    Easier follow-up and discovery

  8. 0.4.7

    Waiting feedback for peer calls

  9. 0.4.6

    Peer answers survive malformed measurements

  10. 0.4.5

    Pending work stays discoverable in full briefs

  11. 0.4.4

    Clearer installation, readiness and follow-through

  12. 0.4.3

    Support reports from retained peer calls

  13. 0.4.2

    Clearer peer timeout observations

  14. 0.4.1

    Clearer setup and native launch reviews

  15. 0.4.0

    One product name from installation to collaboration

  16. 0.3.0

    Native collaboration in either direction

  17. 0.2.0

    Simpler setup and native collaboration