Lane

I run my bigger projects with a lead agent, a long-running coding agent that plans the work and hands pieces of it to workers. Lane is how it hands them off. The lead writes a short brief, and Lane starts a Codex or Claude Code worker on it in the background, to write code, look into a question or review a change. Lane returns at once, so the lead keeps going. By default up to four workers run at a time, and each one that writes code gets its own checkout of the repo on its own branch.

Every job comes back as one line of JSON. This one is from the reference docs, shortened and wrapped to fit.

{"lane_id": "20261001-214755-add-flag-5940",
 "status": "ok", "marker": "STATUS: DONE",
 "profile": "implement", "model": "gpt-6-astra",
 "effort": "high", "duration_s": 412.3,
 "branch": "lane/20261001-214755-add-flag-5940",
 "quota_before": 41.0, "quota_after": 43.0,
 "report_path": "…/final.md"}

status: ok means the worker exited and its report opens with a marker such as STATUS: DONE or STATUS: BLOCKED. That is the worker’s own account of the job. It says nothing about whether the code works.

Holdout checks

To find out, I pass my own acceptance command with --holdout. Lane tells the worker the check exists, and after the worker exits it runs the command in the worker’s checkout, outside the worker’s sandbox. --protect names files the worker may not edit, usually the acceptance test itself. Lane hashes them before the worker starts and again after the check, down to permissions and symlink targets.

lane run --brief /tmp/add-flag.md --cwd ~/code/app \
  --profile implement \
  --holdout 'python3 -m unittest discover -s tests' \
  --protect tests/test_acceptance.py

The result’s holdout.passed is true only when the command exits 0 and nothing protected changed. A failed holdout leaves the worker’s own status alone, so the lead has to read both.

When a task is one change repeated across several cases, the lead can make the first edit itself and hand it over with --prewalk, along with a plan of up to eight items, each with its own check. For a Codex worker, Lane writes the commit and the real output of the first check into the worker’s session as the worker’s own tool history. The worker resumes with item 1 done and carries on from item 2. The idea comes from Stencil’s prewalk.

Choosing the worker

Each job runs on a profile that sets the provider, model, effort, sandbox and time limit. They range from quick-investigate, read-only at low effort for 15 minutes, to implement-hard at xhigh effort for 90. With --profile auto, fixed rules read the brief’s goal and steps and pick one. A write task has to name the paths it owns. Four or more paths, two hard keywords such as migration or concurrency, or more than six steps get implement-hard, and a simple rename in at most two files gets implement-light. A retry climbs a ladder from implement-light up to Claude Opus.

Before it starts anything, Lane reads the rate-limit samples Codex writes to its own logs. It refuses new tasks once my account reaches 90% of its weekly limit, or 95% for reviews.

A spark provider points a Codex worker at a self-hosted server that speaks the Responses API, and mine is a DGX Spark. At each start Lane asks the server which model it serves. If the server doesn’t answer, the job is refused before any worker runs.

Long runs

The lead works from a card, one page at the root of the repo called CARD.md. It holds my goals and a done check in my own words, which only I change, the decisions that are mine to make, and an ordered list of tickets, each with its own check. When the lead hits a question only I can answer, it writes it on the card and moves to the next ticket. A run ends when the done check’s output exists or when every remaining ticket is waiting on me. Then a reviewer from the other model family reads the card, the diff and the check results. This site has a card too.

The card’s rules owe a lot to Dietrich Dörner’s The Logic of Failure. In his studies the people who did well pursued each goal through several decisions, and they tested their hypotheses where the others treated them as facts. So every goal on a card gets at least two tickets that pull different levers, and a suspected cause stays a hypothesis until a check confirms it.

To compare setups I score whole runs. A coding agent wrote lead-eval for me this month. It copies a repo at a commit, opens a terminal pane, starts the lead there with a kickoff, and turns the finished session into one table row, read from the session’s state and its transcript. The row has wall minutes, workers, holdouts passed, commits, open tickets and tokens.

The first row is a lead run of about 13 hours on one of my own repos. The run going now replays the same kickoff from the same commit, with the workers sent to a local model on the DGX Spark by the rules file it loads. I don’t have its row yet. The Spark workers run at high effort and they’re slow.

What it is not

Lane checks the shape of a report and runs my check. It can’t tell whether my check tests the right thing, so a passing holdout proves what the command tests and nothing more.

Claude workers that write code have no filesystem sandbox. A separate checkout keeps their files apart and does nothing to limit what their shell can reach, so I run them only on repos I trust. Codex workers run inside Codex’s own sandbox.

Quota readings are account-wide and approximate. My interactive sessions count against the same limit, so a check before launch can’t promise that a job finishes before the limit hits.

It’s tested on macOS, and Linux is untested. It’s one Python file of about 2,100 lines with no third-party packages, under the MIT license. The tests swap Codex and Claude for small fakes, so the suite spends no quota and takes about 90 seconds.

Source on GitHub · All projects