Skip to content
Pairon
Sign inJoin the beta

Private beta

AI work was never meant to be single-player.

Pairon is one shared room where your team directs Claude Code, Codex and OpenCode together — running on your own computers, with every step kept.

Join the beta See how it works

Letting teams in a few at a time · Have an invite? Sign in

A replay of a Pairon room. Maya asks Codex, running on her laptop, why a checkout test is flaky. Dev joins and points out that two test suites share a fake clock. Codex, now working for both of them, fixes test/setup.ts and the tests pass. Sam joins to watch, and Maya saves the decision to project memory.

ReplayMaya opens a room. Codex runs on her own laptop.

Measured19–33% lower cost per solved task with Codex · 360 graded runs

02The single-player problem

Everyone has their own chat. Nobody has the whole story.

When three people ask three agents about the same bug, each agent reads the same code from scratch, each person explains the problem again, and whatever gets decided stays in one private window.

  • Separate context
  • The same bug explained three times
  • Decisions stay in private chats

Three private chats: Maya asks Codex, Dev asks Claude Code and Sam asks OpenCode about the same flaky checkout test. Each agent reads the same files from scratch, and nobody sees the others’ answers.

03Watch a session

Steer the agent. Don’t just watch it.

Forty seconds of one conversation: a task, a teammate who knows better, a hand-off to a second computer, and a decision that sticks. Switch seats to see what each person, and the agent, actually gets.

A 40-second replay of a Pairon conversation. Maya asks Codex, on her MacBook, to retry timed-out payments while Sam watches as a viewer. Dev joins, connects a second computer and points out a double-charge risk, so Codex’s next turn works for both of them and reuses the idempotency key. Codex proposes handing the web fix to Dev’s computer, Maya sends it, and Claude Code updates the checkout status there. Dev checks the result and Maya saves the decision to project memory. You can switch between Maya, Dev, Sam and Claude Code to see what each seat shows.

View as

Owner. Codex runs on her MacBook. Hand-offs from her instructions wait for her to send them.

Maya asks Codex, on her MacBook, to retry timed-out payments. Sam is watching.

0:00 / 0:40

Scripted replay built from Pairon’s own interface. Space plays or pauses; ← and → move between steps.

04How it works

From a question to merged work in five steps.

05Anatomy of a room

What’s actually in there.

Each piece below is a real part of a Pairon conversation today, not a mock-up of a roadmap.

  • Lanes

    Several computers, one conversation

    Each lane is one person’s computer and folder. Any collaborator can send work to any online lane, with the owner’s consent.

  • Queue

    Instructions wait their turn

    Each lane runs its instructions in order. Add to the queue while an agent works, and everyone sees what’s next.

  • Hand-off

    Pass a sub-task to another computer

    An agent can propose sending part of the work to a teammate’s lane. The person who gave the instruction decides.

  • Parallel tries

    Two agents, one question

    Run the same instruction on two lanes side by side, then keep the answer you prefer.

  • Review

    Merge a teammate’s copy

    Changes made on another lane come back as a review. When both sides touched the same lines, you choose, or ask an agent to combine them.

  • Previews

    Show the running app

    Share a port from your computer and everyone in the room can open it through a Cloudflare link until you stop.

  • History

    Every step, in order

    Instructions, finished turns and connections are kept in the conversation’s History, with change summaries rather than file contents.

  • Memory

    Decisions that stick

    Save a decision once and later agents treat it as settled. Project memory is what our published benchmark measures.

06Workflows

Three ways teams share one agent.

Short replays of situations Pairon is built for. The people and repositories are made up; every screen is the product’s own.

Backend on one laptop, frontend on another. Two agents work at once, and both turns stay in one conversation.

A replay. Maya asks Codex on her MacBook to add a refund date to the orders API. Dev asks Claude Code on his Mac mini to show it on the order page. Both agents work at the same time and both finish in the same conversation.

Maya and Dev each connect a computer to the same conversation.

07Measured

Measured, not promised.

We ran the same agent on the same tasks, with and without Pairon’s project memory, across three real codebases. With memory it solved them for less in every repository.

Measured
Lower cost per solved task
19–33%
Paired, graded runs
360
Upper end of every 90% CIa saving in all three repositories
< 1.0
Answer qualityno significant difference
Same
SET A

Pairon-Backend

TypeScript API, WebSocket orchestration, Postgres

−33%
Agent alone
1.00
With Pairon
0.674

90% CI 0.538–0.835

SET B

Pairon-Frontend

React workspace with a large component surface

−22%
Agent alone
1.00
With Pairon
0.778

90% CI 0.619–0.944

SET C

Excalidraw

Popular open-source canvas app, not ours

−19%
Agent alone
1.00
With Pairon
0.811

90% CI 0.702–0.936

Cost per successful answer, relative to the same agent without Pairon. Lower is better. The faint band behind each Pairon bar is its 90% confidence interval.

How we measure

  • 01

    Two identical copies

    Each task runs on a plain checkout and on a Pairon checkout of the same pinned commit. Both reset before every run, and the arm order alternates.

  • 02

    Answers stay hidden

    Benchmark material is excluded from both copies, so neither agent can read the expected answer.

  • 03

    People grade the work

    Every automatic failure and a sample of passes are checked by hand: cited lines, completeness, exact locations, clean edits.

  • 04

    Cost per success

    Total cost divided by the answers that passed grading, so a cheap wrong answer never counts as a saving.

What didn’t work

Measured

We built these, measured them the same way, and found no saving on Codex. They stay off by default.

  • Hand-off packageRatio 0.97 [0.87, 1.09]Its facts were change notes rather than how the code works. Opt-in only.
  • Procedures−14%, +20%, +14%Missed the −30% target and stayed within run-to-run noise. Opt-in only.
  • Output compressor+3%, +33%, +80%On the three valid pairs; the test output here was too small to compress. Off by default.
  • pairon_ask tool+10% costCodex never called it. No value on Codex.

What this doesn’t show

  • One agent (Codex) and one model at low effort. Claude Code and OpenCode were not part of this run.
  • 60 paired tasks per repository bound cost well, but answer quality only to about ±10 points.
  • This measures one agent using Pairon’s project memory. It does not measure teams.

We haven’t measured teams yet. The model below shows how we think about it, and labels which part of its answer rests on these measurements.

Codex · gpt-5.6-luna · low effort · 360 runs · 2026-09-23 · report BENCHMARK-2026-09-23-v3-codex-luna-low.md. A confirmation run on the final code the same day (396 runs, six new held-out prompts) gave −25% / −22% / −20%. Cost uses the harness’s fixed notional token prices, the same for both arms, not what Codex bills. Set C is Excalidraw, an open-source project we do not maintain.

08Team model

Where a team’s tokens actually go.

A model, not a measurement. It compares several people each running their own agent on the same task with one Pairon room, and separates the part that rests on our benchmark from the part that doesn’t.

Workflow

The core use

People on the task
Agent lanes in the room

Computers doing the work. Never more than people.

Complexity

Scales discovery and instructions by ½, 1 or 2.

Memory ratioMeasured

Measured cost per solved task with Pairon’s memory, by repository.

AssumptionsDefaults

Token and time defaults are our assumptions. They have not yet been calibrated from recorded sessions.

Simulated: 252k tokens without Pairon, 164k in one Pairon room, 35% fewer. Estimated time: 3 h 45 min against 2 h 23 min.

TokensSimulated
164k−35%

with Pairon, against 252k without it

People’s timeEstimated
2 h 23 min−1 h 23 min

with Pairon, against 3 h 45 min without it

Where the difference comes from

88k tokens
One shared roomSimulated
72k tokens
48k not rediscovered, 24k not re-briefed
Project memoryMeasured
16k tokens
Uses the measured ratio you picked
Agent sessions started
3 → 1
Duplicated context
48k → 0
Catch-up time
1 h → 0 min

Illustrative simulation based on the assumptions shown. Not a measurement.

The formula
n people, a lanes (a ≤ n)

Without Pairon = n·D + n·T·Q + n·(n−1)·R
With Pairon    = r·D·[1 + (n−1)(1−k) + (a−1)·k]
                 + n·T·Q + (a−1)·R

Time without = n·W + n·(n−1)·c + n·S
Time with    = n·W + (a−1)·c + n·S·g
(sync counts only when n > 1)
  • Only r, the memory ratio, is measured. Everything else is an assumption you can see and change.
  • Instruction work (n·T·Q) is identical in both columns, so Pairon gets no credit for doing the actual work faster.
  • Each extra lane pays a full re-brief (R). Our hand-off package showed no measurable saving, so the model gives it none.
  • With one person and one lane, the model reduces to the measured single-agent result and nothing more.
  • Prompt caching is ignored on both sides.

09Your code stays yours

Built to hold even if our server doesn’t.

The rules for what an agent may do on a computer are enforced by the Pairon runner on that computer, not by our server. A compromised server can send requests; it can’t grant permissions.

  • Agents run on your computers

    Claude Code, Codex and OpenCode run through the Pairon runner on your own machine, limited to the folders you allow.

  • Code is relayed, not stored

    File contents, diffs and terminal output pass through Pairon to the room but aren’t kept. History keeps change summaries. Conversation text is stored.

  • Secrets are redacted on the runner

    Secret redaction, the sensitive list, approval mode and the pause switch are all enforced on the computer, before anything leaves it.

  • Loosening rules needs the owner

    Raising access or allowing a new folder needs the computer owner’s confirmation — a local prompt or their passkey — which the runner checks itself.

Source: Pairon architecture decision record 0002, “The runner, not the server, enforces what agents may do on a computer” (accepted 16 September 2026).

PRIVATE BETA

Bring your team into the room.

We’re onboarding a small number of teams at a time. Tell us a little about yours and we’ll send your invite when a spot opens.

  • A direct line to the people building Pairon
  • Help setting up your first project and runner
  • Your feedback shapes what we ship next

Already approved? Sign in to Pairon

FAQ

Questions, answered.

Something else? Email hello@pairon.dev.