SIRTHEO/sailor

Sailor

For whoever runs more than one command-line agent — Claude Code, Codex, Gemini CLI — and is tired of each one having its own rules, its own memory and no record of what it actually did. Sailor gives them one set of rules and one ledger: it decides which engine to call, under which identity, how much it may spend, and it writes down what actually happened, so a run can be reviewed, compared and repeated instead of recounted.

One concrete outcome: point Sailor at a project, run one flow, and get back a queue of work items drained one at a time — each one either finished with a recorded result or handed back to you with the reason it stopped.

Status — what you can do tonight. Run a queue of work through one engine end to end (take-the-next-work), and watch a desktop window that shows what is waiting and lets you close a step that was handed to a person. Not there yet: filesystem and network restrictions on a handed step are not enforced by Sailor itself, and a completed flow does not by itself prove its result met your acceptance criteria: a required step withholds completion, it does not certify the result. The open defects a user can meet are described in docs/faults-encountered.md.

Five minutes

cargo install --path crates/sailor        # one binary, `sailor`, no service
sailor workspace init                     # in the project you work on
sailor flow check dispatch-the-work       # which engines are here, tried without spending
sailor remaining                          # what is left of each subscription window
sailor flow run sweep-the-tree            # a mechanical job on one file, by the local model

What you get: the engines on this machine with whether they are signed in and how much of their window is left; a flow that splits a mandate across two engines and has a third judge them; a ledger row for every call, with tokens, cost, identity and the kind of work; and a desktop window that shows all of it and opens terminals that know which engine runs in them.

Quota and cost coverage depend on each engine's descriptor and the data it returns. Missing measurements remain unknown. A spending threshold is a guaranteed ceiling only when the engine can enforce the bound on each call. The local rewrite flow needs a configured local runner and hands back a proposal for verification; it does not apply the proposal automatically.

What it does, concretely

• Runs flows: a graph of steps, where independent ones genuinely start

together. A step can call an engine, run a check, read and write a store, or hand the work to a person.

• It knows no engine by name. Every tool introduces itself with a

descriptor declaring how you talk to it: how to ask a one-shot question, which words it uses to refuse a malformed line, how it says it is out of quota, how to ask whether it is authenticated. What does not declare triggers nothing — staying silent is different from guessing.

• Tries the command lines before spending: sailor flow check assembles

each engine's real command line and runs it without the question, so a malformed line is found there and not on the first paid run.

• Measures what it costs: tokens per class, cost per call, a spending cap

that tightens as the remainder falls. And when part of the bill is not measured it says so in place of the number, instead of handing you a bare figure you would read as the total.

• Knows which identity every engine started under: separate credential