AI opens doors and rarely closes them
It notices more work, starts more work, and leaves the unfinished part for you to carry. One request becomes a queue of open decisions.
For the AI practitioner
Let AI keep working without you.
Everyone monitors AI's token count and billing. Nobody monitors the scarcest resource of all: the attention of the person who must constantly judge, decide and own the work. remit records the work and lets it continue or wait without you. It only needs you for the judgement that is genuinely yours, and it will not nag you. When work is delivered, it shows you what it did.
The shipping problem
AI can produce code faster than you can judge it.
Generated work needs clear boundaries and a person willing to review and own it.
Review cannot keep up with generation
Code can be produced faster than anyone can review and ship it. The decision to ship still lands with you.
Every decision costs you
A long queue of decisions makes it harder to keep judging well, and time on task adds to the strain.
The scarcest resource is your attention
Work starts and stops with you. The judgement stays yours.
Work starts with you, not when the AI notices something. Work stops with you, not when the AI thinks it is done. It asks you when your judgement is needed.
Your brief starts the work
The brief is in your words, filed as you said it, with one word for how far the work may go before it waits for you. remit keeps the brief as you wrote it.
It waits when it needs your answer
Your update starts with the outcome, any material consequence or blocker, and the decision actually owed. A shared cause gets one explanation. Detailed evidence stays available when you ask. A question only you can answer is the stop that reaches you where you are.
The record keeps the context
Weeks later, in a new session or a different agent, the item reads the same. No chat is the memory for the work.
A separate evaluator judges the work
A fresh context that did not write the work checks an independent checkout of the exact recorded candidate against selected current authority, rules and proof. It never falls back to the builder's tree, and remit audits that checkout after the evaluator's owned process lifetime ends. Native execution detects mutation; it is not hostile-code read isolation. Put that evaluator on a model from another maker, and it is less likely to wave through work from its own family.
Every delivery shows you what it did
A showcase states the problem and the approach, optionally how the evidence was taken and the command that takes it again, then walks through each thing the brief asked for, with screenshots, requests or transcripts from runs the builder kept. The evaluator is told to open every image before it passes the delivery. A delivery without a showcase, or with a picture no cited run names, fails at the gate into accepted. The showcase is kept with the work item, and a pull request, when there is one, shows it, with its images from the first draft when the record is on GitHub.
It counts the attention each item used
The words you typed and the words said back to you, per session and per item, never summed into a score. Every context raised is on the record with its agent, its model, and its cost where the agent reports one.
The boundary
remit does not act for you.
You start and close every item
You authorise work and closure. Before closing, your agent explains any material unresolved finding or undelivered work. Closing archives the record and seals unresolved findings; it does not merge a pull request or deliver unfinished work.
You choose every agent and model
A registry you write says which agent and model each role uses. Nothing runs elsewhere, nothing falls back when a seat refuses, and every refusal happens before anything is billed.
You can stop it with one command
One command ends a running chain and the contexts it raised, leaving the item at its last completed stage. The environment is filtered, but each CLI uses your authentication configuration. That is not an enforced boundary against reading your files.
Bounded loops
Every loop stops itself, and your rulings become the rules.
The build loop stops itself
A builder gets four rounds at most. The same must-fix twice stops it. A must-fix that comes back after being displaced stops it, because the brief is arguing with itself, and that is yours to settle.
An unavailable evaluation prerequisite returns BLOCKED: the item waits and resume retries evaluation. Findings without an explicit must-fix do not become another build round. A delivered-when line whose proof the evaluator could not see run is not met, so it does not pass on one: a FAIL where the delivery could have produced the proof, BLOCKED where nothing before the pull request can, such as hosted CI.
The judgement loop stops itself
A conductor may answer a question for you only under an elevation you wrote, twice per item; the third is yours, and a question it already answered is yours when it returns.
Your rulings become the rules
A retro proposes one compact batch from your actual rulings. Each lesson belongs in a rubric, executable check, environment or configuration, item authority, or no durable change. Duplicate rules can be pruned. You decide what changes.
One item, end to end
The board shows where every item is.
Preparation fits the work: establish the problem, research the solution and technical approach, then define proof before building when the outcome warrants it. Reuse existing authority. A small change can keep its outcome and proof in one brief, with no extra stages or mandatory documents.
Four stages, three approval gates. You say how far an item may go; it stops there, or earlier where it needs your judgement, and the record says which. An item can depend on other items, and waits at the start until what it depends on has landed. Each row of the board is one item: attention, stage, why it stopped, the item's name and title. Beneath the row, the decision waiting for you.
active refined asked: 1 question retry-on-timeout Retry a failed upload once
1. Should the second failure reach the user, or retry silently? The brief does not say.One command records your answers, in your words, and the chain resumes once, where it stopped. A conductor may answer for you only under an elevation you wrote, at most twice per item; the third is yours.
Your existing AI subscriptions
Use the agents you already pay for.
Open whichever one you feel like; the work item and its state are the same. The builder and the evaluator are separate contexts, and they can be different model families: a model favours its own work, so an evaluator from another maker is less likely to wave it through.
Claude Code
Cannot spawn its own agents: every context comes through remit's one seam. It runs on your machine under your login, with no enforced read boundary.
Codex
Requests Codex's filesystem sandbox, with the worktree as its only writable workspace, and checks its reported mode, refusing a reported downgrade. A missing report is unconfirmed. This is not a guarantee of blind or selected-input reads.
Devin
May use only the tools on a list written for the run; anything else ends it. An unknown model is turned away before the run starts. No enforced read boundary.
Copilot CLI
Uses tool-denial hooks and a preflight canary for Git commands. These checks are not a complete shell security boundary. Checks the model and reasoning effort before dispatch. No enforced read boundary.
Pi
The odd one out: it runs local models on your own machine, and any hosted provider you have configured, with built-in tools only and no extensions. A model the machine's own catalogue does not list is refused. No enforced read boundary.
The launch environment is filtered; each CLI still uses your authentication configuration. Fresh contexts and scratch directories do not establish blind isolation. Read the actual boundaries in the README.
Install
Install remit in your repository.
Three scripts, the conventions, one section of AGENTS.md, a CONTRIBUTING.md it manages, a pre-push guard and the hook registrations, and a folder for the work, every file recorded in a manifest. There is no service to operate. The README explains how to inspect or pin the installer before you run it.
Keep a dedicated install where the project adopts remit. Use --shadow to separate frequent working-record commits from the product repository's human-review merge gates. Both repositories may be private. Shadow is a workflow separation, not a confidentiality or public-export boundary, and does not isolate worker reads.
Working records are not inherently confidential: useful practitioner words may enter the product. Remit does not fingerprint their contents or audit Git history for copied wording. Handle secrets upstream and public exports explicitly; exact-candidate checks and deliberately selected PR summaries remain.
Windows build-worktree creation enables long-path support for the checkout command. Delivery checks only its base and branch, without requiring unrelated GitHub pull refs locally.
Exact delivery snapshots use a short repository-owned location under Git metadata, independent of the item name. Windows inspection handles long paths while retaining integrity checks, without changing machine settings. Older item-local snapshots remain recoverable after an upgrade; resume a snapshot-blocked item to retry.
Read the install guide on GitHubOne installer serves all five agents.
curl -fsSL https://raw.githubusercontent.com/shobman/remit/main/get-remit.sh | sh -s -- /path/to/your-repositoryWork waits without losing its record.
remit keeps the context and gets a separate evaluation before you read the result. The work starts and stops with you.
Open the remit repository