DEV Community: Serhii Troian

Orchestrator: Agents Take the Next Issue While You Review

Serhii Troian — Tue, 10 Nov 2026 17:34:14 +0000

Last week, we added a Start with button to every issue in Origin.

Pick an issue, choose Claude Code or Codex, press Start, and the agent runs headlessly on your machine. It gets its own Git worktree, works through the task, and opens a pull request when it is done.

That workflow worked well, but it also made the next bottleneck obvious. Agents were ready to work, yet they still spent most of the day waiting for one of us to open the issue list, decide what should run next, choose an agent, and press the button.

So we automated that part too.

Origin's Orchestrator now watches the issue queue on a schedule. It finds work that is actually ready, takes issues by priority, assigns each one to the agent most likely to finish it, and starts the run automatically.
Once a PR opens, reviewer agents take over. If they request changes, the coding agent gets another round on the same branch. When every required review passes, the run stops at Ready to merge.

Final merge still belongs to a person.

On the first live day in our own workspace, Orchestrator handled 43 runs and produced 21 PRs ready to merge.

Orchestrator in our own workspace after its first live day: 43 runs and 21 PRs ready to merge.

How AI Agent Orchestration Picks the Next Issue

By default, Origin checks selected repositories every 10 minutes instead of simply grabbing the first open issue.

Before an issue enters the execution queue, several conditions have to be true. Nobody else can already own it, every dependency must be closed, and the issue has to match configured filters such as type, labels, and maximum priority.

Work that clearly should not be handled by a coding agent gets skipped.
We added that filtering after seeing what happened on our own issue list. During the first live day, Orchestrator picked up three issues starting with “Verify…” and another that said it “waits on the replay benchmark.” Each one occupied a slot for roughly 15 minutes before the agent reached the pre-start check and asked for clarification.

Those were valid issues, just not actionable coding tasks.

Origin now leaves them out, along with anything marked [Postponed].

Once the ready queue is clean, Orchestrator fills available execution slots. You control how many AI agent runs can happen at once we use two and can also set a daily budget or restrict automated execution to a specific window, such as overnight.

One additional rule keeps the queue balanced: Origin will not start more than one new issue per agent during the same check. Otherwise, one high-performing agent could consume the whole queue before other available agents get a chance to run.

How Origin Chooses the Best Coding Agent

Only agents that can actually run are considered.

For local agents, the required CLI has to be installed and signed in on one of your machines. Cloud agents such as Copilot, Cursor, or Devin need the corresponding credentials.

Once eligible agents are known, Origin scores each one against the issue.
Three signals determine the assignment:

60% historical completion rate. Origin looks at how often the agent has successfully finished the same kind of work, such as bug fixes, features, refactors, or chores. Task-specific performance is used once at least three relevant runs exist. Otherwise, Origin falls back to the overall rate. With fewer than three runs total, the agent gets a neutral score rather than a fabricated success rate.
25% your agent order. Your own preference still influences the result. If one agent is ranked first in the workspace, Origin takes that into account.
15% billing model. An agent already covered by a subscription gets an advantage over one billed per token.

Origin also shows why it picked a particular agent. One of our bug-fix runs, for example, was assigned to Claude Code with this explanation:

100% of 10 runs on bug fixes finished · #1 in your order · on a subscription (max) · on Artems-MacBook-Pro.local

Completion rates come from the same run history already visible on the issue page. As Claude Code, Codex, or another agent completes or fails more tasks, future assignments use that updated history. In practice, routing improves as the workspace accumulates real run data instead of relying only on static preferences.

Dry Run Before Automated Execution

You do not have to hand the queue over to Orchestrator immediately.
Dry run uses the same scheduling and agent-selection logic, then writes each planned assignment and its reason to the activity feed without starting anything.

That makes it easy to watch several checks and compare Origin's choices with what you would have picked manually. If the routing looks sensible, switch to Live.

What Happens When an AI Agent Run Starts

In Live mode, an issue assigned to a local agent is queued for one of your machines.

Origin's existing review runner - origin review runner - claims the job and executes the same command behind the manual Start button:

origin issue start --agent claude --background --force
Because Orchestrator uses the existing issue-runner path, all the same safeguards still apply.

Every task gets its own Git worktree. Origin checks that the selected agent is signed in, runs a pre-start check to make sure the task is clear enough, applies a time limit, and expects the run to produce a pull request.

Code stays on your machine and runs through your existing agent account.
For supported cloud agents, Origin starts the task through the provider using the same prompt that the manual Start dialog would have sent.

Queue handling also includes a couple of failure protections. If no runner picks up a queued run within 30 minutes, it expires. If a run starts but fails, Origin removes that issue from the orchestration plan for six hours instead of retrying the same broken launch every 10 minutes.

Automated Pull Request Review and Fix Rounds

Opening a PR does not end an orchestrated run.

One of Orchestrator's PRs: Codex fixed a security alert, three reviewer agents approved it, then a person merged it.

Once the PR reaches Origin, the run moves to In review and every reviewer agent configured for that repository receives it.

If all required reviewers approve the change, the run moves to Ready to merge and Origin sends a notification. Automation stops there; someone on the team still decides whether the code should actually be merged.

When a reviewer asks for changes, Origin collects the findings into one fix issue and sends it back to the same coding agent on the same branch.
After the agent pushes its fixes, the PR goes through review again. Only reviews against the new commit count, so approval from an older version of the code cannot carry over after the branch changes.

You can also decide how many automated fix rounds an agent gets. Default is one, with a maximum of three.

If reviewers still request changes after the final round, the fix fails, or reviewers do not finish, Origin moves the run to Needs you.
Every run therefore ends at one of two useful human checkpoints:

Ready to merge - implementation is complete and reviewer agents approved the current commit.
Needs you - something in the execution or review loop needs a person to step in.

That is the boundary we wanted to keep. Orchestrator handles issue execution, pull request review, and fix cycles without making the final shipping decision for you.

Activity feed and Orchestrator settings: fix rounds, two concurrent runs, a 10-minute check interval, and a $30 daily budget.

What Happened on the First Live Day

We switched our own workspace to Live on October 29. Setup was deliberately small: Claude Code and Codex on one MacBook, two simultaneous runs, and a $30 daily budget.

By the evening, Orchestrator had started 43 runs. Claude Code handled 20, and Codex handled 23. Not every run worked, and that was probably the most useful part of the test.

25 runs opened a PR. Twenty-one were approved by reviewer agents and waiting for merge. Two had already been merged, and we closed another two ourselves.
14 runs ended without a commit. Agent inspected the issue but changed nothing. Some tasks had already been completed by an earlier PR. Others were too vague to act on, including one literally titled “change it - I don't know how.”
4 runs stopped during the pre-start check. Those were the “Verify” and “waits on” issues mentioned earlier. Instead of guessing, agents asked for clarification. Those runs are also why the current filters exist.

Running Orchestrator on our own development work exposed product bugs too.
One run finished before its PR reached Origin, which caused the review step to be skipped. Another problem involved an optional reviewer: three PRs remained in review for roughly an hour because the runner processed required reviewers first.

Both issues were fixed the same day. More important, though, was what the experiment showed about the queue itself. Roughly a third of our issues were not real, actionable coding work.

Some were outdated. Some had already been solved elsewhere. Others were too vague or blocked by work that had not happened yet.

AI agent orchestration makes this visible quickly. Even a strong coding agent cannot do much with an issue that should not have entered the queue in the first place.

Orchestrator works best when the issue list contains work that is actually ready to be done.

What Orchestrator Will Not Automate

Orchestrator has explicit boundaries. It will not merge a pull request. Runs stop at Ready to merge or Needs you.

Local-agent code does not execute on Origin's servers. Local coding agents continue to run on your machine, while cloud agents execute through their own vendors.

Configured limits are also hard boundaries. Orchestrator will not exceed the number of concurrent slots, go over the daily budget, or launch new work outside the execution window.

Duplicate starts are blocked as well, including cases where two Origin workspaces share one repository.

This is not meant to be an unrestricted autonomous coding loop. What makes sense to automate is the repetitive coordination between a ready issue and a reviewed pull request, while the team keeps control over what actually ships.

Start With Dry Run

You need three things to try Orchestrator:

Origin CLI, at least one supported agent CLI signed in on your machine, and the Origin runner:

origin review runner

Open Orchestrator in the sidebar, select the repositories it should watch, choose the issue types it can pick up, order your agents, and configure concurrency, budget, and scheduling limits.
Start in Dry run and watch a few checks in the activity feed.

You will see which issues Origin would start, which agent it would assign to each one, and the reasoning behind every choice.

If those assignments look right, switch to Live.

From there, Origin keeps ready work moving through AI agent assignment, implementation, pull request review, and fix rounds while your team stays focused on decisions that still need human judgment.

Try Origin and put Orchestrator to work on your issue queue.

HandRethinking the Pull Request for the Age of Coding Agents an issue to an agent and let it run on your machine

Serhii Troian — Fri, 30 Oct 2026 10:01:12 +0000

Code review rests on a fifty-year-old assumption: writing code is expensive and reading it is cheap. Coding agents turned that around. What a pull request has to become when machines write most of the code, the two ways the industry is starting to build it, and what we learned building one of them.

Open a pull request written by a coding agent and you get a strange feeling.

The description is perfect: neat headings, a summary, a test plan with every box checked. The diff is 1,200 lines across 31 files. The author's name is yours, because the agent ran on your laptop.

And somewhere in the middle of the diff is a decision nobody made. The agent made it at 3 a.m. while you were asleep. Now it's waiting for a reviewer who'll scroll, see green checks, and type "LGTM".

This isn't a story about bad agents. The agents are good, and that's the problem. They write code much faster than anyone can read it, and the pull request was never designed for that.

This essay is about what the pull request has to become.

The deal code review was built on

Formal code review is older than most of the languages we use. In 1976 Michael Fagan at IBM published a paper on code inspections: a group of engineers in a room, a printout of the code, and a moderator reading it line by line. It was slow and expensive, and it worked.

The next forty years made inspection cheaper without changing what it was. Patches went to mailing lists. Gerrit and Phabricator gave every change a review page. Around 2008 GitHub made the pull request a button, and review became the default way software gets built.

Every form of it rested on the same deal:

Writing code is expensive. A person spends hours or days on a change, so each change is worth a careful look.
Reading code is cheap. A reviewer spends minutes on what took the author hours.
The author is accountable. Someone wrote every line, can explain it, and will remember why tomorrow.
The conversation is the record. Why something changed lives in the description and the review thread.

From that deal comes the pull request as we know it: a diff, a description, a comment thread, a green CI check, and an approval from someone who has read the change.

The deal is broken

Coding agents reversed it.

	Before agents	With agents
Writing	The bottleneck	Nearly free. One developer runs five or six agents, and each one ends in a PR.
Reading	The cheap part	The bottleneck. A person still reads at the speed of a person.
The author	Can explain the change	A session that ended an hour ago
The description	A record	Written by the same model that wrote the code

On the repository we work in every day, 1,248 pull requests have been merged, and agents opened almost all of them. One person reviews them. Review stops being a quality gate and becomes a queue, and a queue that's too long gets skimmed.

So teams drift into one of two failure modes:

Review every line. The agents spend most of their time waiting for a person.
Stop reading and approve on vibes. The team finds out what it merged in production.

Neither is a fix. The fix is a different idea of what a pull request is for.

What a pull request has to become

Strip the PR down to its job:

Decide whether this change can land, and leave a record of why.

In 1976 the only way to do that job was a person reading the code. That's no longer true. Here is what the job looks like now, as six principles.

1. Review intent, not lines.
The first question about agent code isn't "is this line right?" It's "what was the agent asked to do, and did it do that?" A thousand-line diff from five prompts is five things to check, not a thousand.

2. Machines review first, on every push.
Review agents with clear instructions (security, correctness, your team's rules) run on every new commit, and each review names the commit it reviewed.

3. Many reviewers, one voice.
Three agents posting three comment threads is three times the reading. Their findings are merged: duplicates folded, agreement counted, disagreement shown.

4. A finding starts a loop, not a thread.
A finding becomes a task, an agent pushes the fix to the same branch, and the reviewers run again. It's resolved when the next review doesn't raise it, not when someone ticks a box.

5. Merge conditions are rules, not habits.
"Someone looked at it" isn't a rule. "Every required reviewer approved this exact commit, nothing high-severity is open, CI is green" is one. A machine can check it the same way every time.

6. Keep determinism where it matters.
A gate has to give the same answer twice, and an agent run doesn't. CI stays the source of pass/fail. Agents explain failures, trace them to their cause, and fix them.

None of this is exotic. It's the same goal as Fagan's inspections, catching problems before they ship, rebuilt for code that arrives faster than anyone can read it.

Two ways to build it

Nobody has agreed on the shape yet, but two approaches are taking form.

Replace the host. On 26 October Entire launched as a Git forge built around these ideas. Its Trails replace the PR: review agents score every push, and gates combine approvals, CI and findings. Because it hosts the repo and the CI, it can redesign everything from scratch.

Build a layer on top. Leave GitHub or GitLab where it is, with its branch protection and CI, and add an agent-aware layer above it. Nobody moves a repository, and everything also shows up on the host's own PR page. The price: you're limited by each host's API.

"The pull request has become an audit log that only the agent reads."
— Entire, launch post

We took the second approach. For the past few months we've been building it into a tool called Origin. It started as a way to record what coding agents do in a repository: the prompts, the diffs, the cost, and which agent wrote which line.

That record turned out to be exactly what a pull request was missing. The rest of this essay walks through one PR's life with the six principles built in: the details that mattered, and what broke.

A pull request's life, rebuilt

The queue

It starts with the list of open pull requests. Each row shows how many agent sessions produced it and the live state of every review agent: queued, reviewing, approved, or changes requested.

Open pull requests, each with the live state of every review agent.

Principle 1 · Review intent, not lines

Open a PR and you can read the diff grouped by prompt instead of by file. Each card is one request: the agent, the model, the prompt, the decisions it recorded, then the code it wrote.

Restore rolls the code back to before that prompt, if the prompt sent the agent the wrong way.

One card per prompt, then the code that prompt wrote.

Two details made this trustworthy:

One line, one answer. A line's commit comes from blame at the PR's head, and one function maps commit to session to prompt for every view: the diff, blame, CI failures and review comments. If two views could disagree about a line, you couldn't trust either.
The intent comes from the agent, while it works. Agents write short markers as they go (an intent, a decision and its reason), and the hooks save them with the turn. A validator then checks each claim against what was captured, and flags "added tests" when no test file changed.

What the agent meant to do, and the decisions it made on the way.

Principle 2 · Machines review first, on every push

A review agent is a job: what to look for, which repos it covers, which coding agent runs it, and when. It can run manually, when a PR opens, or on every push, and it can be marked required.

Three review agents, two of them required.

One choice shaped everything else: review agents run on the developer's machine, not on our servers.

People pay for Claude or ChatGPT subscriptions that sign in an agent on their laptop.
The laptop already has the repo's toolchain.
Running code from someone else's repo on our servers would be a security product of its own.

So the server keeps the queue and the results, and a small runner on the developer's machine does the work:

GitHub: a PR opens or gets a push. One review is queued per reviewer and commit, never two at once.
Laptop: the runner, a background service, claims the oldest queued review for a repo it has checked out.
Laptop: it checks out the PR's head in a separate worktree. Your own checkout is untouched.
Laptop: it runs the agent read-only, e.g. claude -p --permission-mode plan, with the prompt the server built.
Server: the verdict and findings come back, go to GitHub, and update the status check.

The review is read-only by construction: Claude runs in plan mode and Codex in its read-only sandbox, with no "skip permissions" flag. Each finding comes back with a file, line, severity, failure scenario and a confidence of confirmed or plausible.

The prompt is where this beats a generic review bot. A bot sees a diff. This reviewer also sees which agent, model and prompt wrote each file, the decisions the authors recorded, and the open TODOs from the repo's history. It also gets these rules:

From the reviewer's instructions

Confirm a finding by reading the code it is about. Mark it "confirmed" only when you traced the failure.

"High" means it breaks the change or exposes data in a reachable path. Style and preference are not findings.

The authors' own notes are claims, not proof. A stated verification you can't see in the diff is worth a finding.

That last rule matters more than it looks. When the author is an agent, "I verified it" is something to check, not something to trust.

Each review is recorded like any other agent session, so its cost sits on the PR next to the cost of writing the code. Ours take 2 to 20 minutes and cost about $0.70 to $1.10 each.

Principle 3 · Many reviewers, one voice

Once two or more reviewers have finished, a judge combines their findings into one list. Duplicates are folded together, each finding says who raised it, and disagreements stay visible.

Three reviewers, one list.

Each reviewer's own run stays one click away, with its session and what it posted on GitHub.

Each reviewer's own run, and what it posted on GitHub.

Because this is a layer on top of the host, everything also lands on GitHub, for people who never open the tool:

One summary comment per reviewer, edited on later runs instead of repeated.
Inline comments on changed lines. GitHub rejects a whole review if one comment points outside the diff, without saying which, so every line is checked against the diff first.
No duplicates on re-runs. Each inline comment carries a hidden marker (reviewer, file, line, title hash), so a re-run posts only what's new.
A status check that branch protection can require.

Principle 4 · A finding starts a loop

Every finding has a Fix button, and the judge's list has Fix all. Either one creates a task on the PR's own branch, so the agent pushes to the same PR instead of opening a new one. The push is a new commit, so the reviewers run again:

Push → Reviewers → Judge → Findings → Fix task → Agent pushes the fix ↺

Repeats on every push, until the merge rules hold on the current commit. Then it merges.

There's no "resolved" checkbox, on purpose. A ticked box proves nothing. A clean review of the commit that will merge proves a lot more.

Principle 5 · Merge conditions are rules

This is the real replacement for "a person read it". A repository, or a whole workspace as a default, sets its merge rules: required reviewers approve, no findings above a chosen severity, CI passes, a person approves.

Merge rules, as a workspace default and per repository.

One function checks the rules and returns a line per rule: met or not, and why. The Merge button, the PR page and auto-merge all read that same answer, so the button and its explanation never disagree.

What stands between this PR and the merge, one line per rule.

The idea was simple. The details took most of the work:

Everything is checked against the head commit. An approval of commit a1b2 says nothing about c3d4. A review of an older commit fails the rule, even if it found nothing.
"Head" means what the host thinks it is. We once ordered a PR's commits differently from GitHub and posted the status on the wrong commit. Now every status post asks the host first.
Auto-merge is stricter than the rules. It lands code nobody clicked on, so it needs an explicit approve of exactly this commit from every required reviewer, and no check failing or still running.
Auto-merge acts as a person. It merges as whoever turned it on, re-checks their permission every time, and says so in the audit log.
It wakes on every event that could unblock a merge: a review finishing, a person approving, CI completing.

None of this replaces the host. Branch protection still applies, and a merge on GitHub's own page follows GitHub's rules.

Principle 6 · Keep determinism where it matters

CI stays the source of pass/fail. Agents work around it:

Failures traced to prompts. A failed check's file:line goes through the same blame step, so "the type check failed" becomes "it failed on a line written by this prompt".
Fix with an agent. A failed check gets a button that creates a task on the PR's branch with the failure, the suspect commits and the end of the log. It ends with: "Don't change the check to make it pass."
Local CI for repos without CI. The same runner runs a fixed test command on every new commit. The command lives in the tool, not the repo, so no branch can decide what runs on your laptop.

The record

The timeline shows everything GitHub's conversation tab shows, plus what only the agent layer knows: which sessions started, which prompt produced which commit, and the fixes agents were asked for.

The pull request's story, with the sessions and prompts behind each commit.

What broke along the way

Work queued with nobody to run it. With a reviewer on every push, one repo queued more than twenty reviews a day, and nothing ran them without a runner. Now the runner installs as a background service, the card says "Waiting for a runner" with the command, and stale reviews expire.
Approvals of code that no longer existed. Before every check was tied to the head commit, an approval from three pushes ago kept a PR green. The first version didn't have this rule. It's now the most important one.
Agents believed agents. Before the "claims, not proof" rule, a reviewer would read "added tests" in the description and take it as true.
Hosts set the limits. Inline comments work on GitHub only for now, and RhodeCode has no CI event to react to. That's the trade-off of building on top, and the one Entire avoided by becoming the host.

What a pull request is now

The pull request isn't dying. It's still the place where a change waits before it lands, on the same host, behind the same branch protection. What changes is the contract.

The old contract	The new contract
A person read it, and CI is green.	Every required reviewer approved this exact commit. Nothing above the bar is open. CI is green. A person signed off if the repo says one must. Every line can be traced to the request that produced it.

When a person does look, they don't read a thousand lines. They read five requests and the decisions behind them, and decide whether those were the right things to ask for.

That was always the point of review. Fagan's inspections were never about reading code for its own sake. They were about catching the wrong decision before it shipped.

Agents just took the reading off our hands.

Whether the future is a new forge or a layer on the forges we already have, the direction is the same: review on every push, mostly by machines, against rules anyone can read, with people spending their attention on decisions instead of diffs.

Origin, the layer described here, is at getorigin.io. It connects to GitHub, GitLab and RhodeCode and leaves your repositories where they are.

Hand an issue to an agent and let it run on your machine

Serhii Troian — Wed, 21 Oct 2026 14:14:27 +0000

Most of our tickets end the same way now. Someone copies the issue text into Claude Code or Codex, adds “look at the memory notes first”, waits, pushes a branch, opens a PR and pastes the link back into the ticket. The work is done by the agent. The glue around it is done by hand, and nothing records which run produced which PR, what it cost, or why the first try failed.

So we moved the glue into Origin. An issue now has a Start with button. It hands the issue to an agent that runs on your own machine, in its own worktree, and the run is recorded on the issue: who ran it, which agent and model, how long, what it cost, how many lines, and whether its PR was merged. This post shows how it looks and what it does. A separate write-up covers how we built it.

One list, every source

Issues come from five places and land in one list: GitHub and GitLab issues (two-way sync), Jira, issues created in Origin, security alerts from Dependabot and code scanning, and TODOs that agents left in the repo’s memory notes. The list sorts by priority and filters by repo, source and assignee. Each row shows the source, labels, priority and, once an agent has worked on it, the number of sessions and the AI cost.

The host stays the owner of what it owns. Title, body, labels, assignees and open/closed come from GitHub or GitLab, and Origin writes assignees back. Origin owns the states the host does not have: in progress, in review and blocked.

Start with an agent

The menu lists the agents Origin can launch headless: Claude Code, Codex, Gemini CLI, Cursor, Copilot CLI and Antigravity. Pick one and you get the Start dialog.

The prompt is built from the issue and the repo’s memory (here 4,418 characters, 10 lines of it memory), and you can edit it before you start. Below it is the exact command the button runs, so you can run the same thing from a terminal:

origin issue start OR-44 --agent claude --background

Without Run in the background, Origin opens a terminal in your checkout with the agent and the prompt in it, and you work as usual. With it, there is no terminal. The agent runs headless in a new worktree on branch issue/OR-44-…, so your own checkout can stay dirty. When the agent exits cleanly, Origin pushes the branch and opens a PR. It never merges and never force-pushes.

The run happens on your machine, with your agent CLI and your agent’s account. Origin’s server never runs code. The button opens a getorigin:// link that carries only the repo and issue ids; the Origin CLI on your machine reads the issue with your own key and starts the agent. The full log stays in ~/.origin/agent-runs/. The server gets the status, the exit code and the last few log lines.

Before it starts: is the agent signed in, and is the task clear?

A signed-out Claude Code exits in a second with “Not logged in”, and for a while that run still looked completed. Now a background run first checks that the agent is signed in. If it is not, nothing starts, no worktree is made, and the issue shows a failed run with the reason. The Agents page shows the same check per machine; above, the last background Claude run on this MacBook could not sign in.

The second check is about the task. A one-line issue leaves the agent guessing, and a background agent has nobody to ask. So before a background run, Claude or Codex reads the repo in a read-only mode, without hooks and without saving a session, and answers one question: is this clear enough to do? If yes, it writes a short brief (files and approach) into the prompt. If not, it asks up to three questions. They appear on the issue, nothing starts, and you answer on the page or with:

origin issue answer OR-44 "Keep v1 readable; consumers must handle both"

A run can also stop and ask halfway. When you answer, the next start resumes the same agent session (claude --resume, codex exec resume) if that session is on this computer, so the agent keeps what it already read. Otherwise it starts fresh with every answer in the prompt.

Every attempt stays on the issue

This issue was not written by a person. Claude Code left it as a TODO in the repo’s memory during an earlier session (“the header’s tokens, cost and tools chips still come from the old session totals”), and Origin turned it into an issue. Antigravity took it twice. The first run failed and the table says so; before we recorded runs, a run that died before the agent’s first hook fired left no trace at all. The second run worked for 30 minutes and opened PR #2487 with +846 −70 lines in 9 files. The issue moved to In review on its own.

Each row links to the captured session, so you can read every prompt, tool call and diff of that run. Status follows the work: start or claim → in progress, PR open → in review, PR merged → closed, PR closed unmerged → back to in progress. An agent can also end with a line like [Origin: Outcome] blocked — which schema version?, and the issue goes to blocked with that question on it.

Race two agents on the same issue

If you are not sure which agent is best for a task, give it to two to four of them. Each runs in the background on its own branch from the same base, and each one that finishes cleanly opens its own PR. Merge the best one, and the issue closes.

This one was a Dependabot alert for source-map-js. Origin turned it into an issue with acceptance criteria (the lockfile no longer resolves a vulnerable version, tests pass). Claude’s PR was merged at $0.50. Codex’s PR was closed; it cost $0.96 and used about ten times the tokens. Over a few dozen issues, that table tells you which agent to give which kind of work. For closed issues the page also gives a origin benchmark replay-tasks command, so you can replay the issue on other agents later and grade them against the tests the merged PR added.

Agents that pick up work themselves
The Start button is one way in. The other is the queue. Origin’s MCP server gives agents list_tasks, take_task, finish_task and release_task. An agent in a session can take the next ready issue, and two agents can never take the same one: a claim is a single conditional database write, so exactly one of them wins and the others get “claimed”. A claim is a lease (30 minutes by default) renewed by the session’s heartbeat. If the agent dies, the lease runs out and the task is free again, without a cleanup job. Issues with open dependencies are not served.

What it will not do
Run anything on Origin’s servers. The agent runs on your machine, with your installed CLI and your account.
Use a blanket permission bypass. Each agent gets the narrowest unattended mode it has: Claude’s --permission-mode auto, Codex’s workspace-write sandbox, a per-run Antigravity project allowed only git and read-only commands with no network, a scoped .cursor/cli.json.
Merge, or force-push. It opens a PR and stops.
Run forever. Background runs stop after 120 minutes by default, together with every process the agent started.
Send the whole log to the server. Only the status and the last lines.

Try it
You need the Origin CLI and at least one agent CLI signed in. Run origin url-handler install once so the Start button can reach your machine, then open Issues and press Start with. From a terminal it is origin issue start --agent codex --background, origin issue race --agents claude,codex and origin issue runs to see what is running.

A repo page for code that agents wrote

Serhii Troian — Wed, 07 Oct 2026 14:11:04 +0000

Open any repo on GitHub and you see files, commits and people. That was the right picture when people wrote the code. In our own repo, 93.9% of the code was written by an agent. The person in the author column mostly typed a prompt and pressed enter.

So the GitHub page is still correct, but it answers the wrong questions. It tells you who pushed. It does not tell you which agent wrote it, which model, from what prompt, what it cost, what the agent decided on the way, or what it left unfinished. Those are the questions you actually have now.

We rebuilt the repository page in Origin around those questions. It looks like GitHub on purpose (same tabs, same file tree, same commit list), so there is nothing new to learn. Every view just carries the AI context on top.

The bar at the top is the first thing GitHub cannot show: how the code splits between agents and people. Here it is Claude 93.9%, Cursor 3.8%, Codex 1.5%, human 0.8%. This is measured from capture of the actual sessions, not guessed from commit messages.

The heatmap is the familiar contribution graph, but each square is coloured by which agent made the commits that day. You can see the day the team switched from writing code to directing agents.

Below it is the agent scorecard. For each agent: commits, lines added, sessions, cost per commit, how much was later reverted, and how much was rejected in review. On this repo Claude made 3,821 commits at $5.18 each, Cursor 122 at $0.02, Codex 82 at $0.51. That is the table you want when someone asks whether the AI spend is worth it, or which agent to give the next task.

The About panel on the right is not a static description. It is the repo’s continuation brief: what the last sessions worked on, what is in flight, and what is unfinished. More on that below.

The file tree works like GitHub’s, but every folder shows how much of it AI wrote and what it cost, and every file shows the agent, the person who ran it, the cost and the age. You can find the parts of the codebase nobody on the team has really read, or the folder that ate the budget, in a few seconds.

git blame tells you who committed a line. On an agent-written repo that is nearly useless, because it is the same person on every line. Origin’s blame groups lines by the prompt that wrote them. Each block says the agent and model (Claude, Opus 5), the person, and the prompt number. Hover a line and you get the prompt text itself, here “merge them, release the cli and deploy”, and the commit it landed in.

The header says the file is 100% Claude across two models, written by two people, linked to PR #1977, and that 0 of 5 sessions behind it were reviewed. That last number is the one that matters in review: it tells you how much of this file a human actually looked at.

Same commit list as GitHub, with the agent and model on every commit and the prompt right under the title. You can filter by agent, by model, or search the prompts themselves. “Find the commit where we asked it to change the sync interval” becomes a search, not an archaeology project.

Memory: what the agents decided, and what they left open
This is the part that has no GitHub equivalent at all.

Every agent session starts from zero. It does not know what the last session tried, what it decided, or what it left half done. So it re-reads the code, re-makes the same decisions (sometimes the opposite ones), and re-discovers the same bugs. On a team with several agents and several people, this happens all day.

Origin keeps a memory for each repo. After each session it writes down what was done, what was decided and why, and what is still open. It lives in the repo’s git notes (refs/notes/origin-memory), so it travels with the code and works offline. The next agent reads it before it starts, through the CLI or the MCP server, whichever agent it is. Claude can pick up where Codex stopped.

The Memory tab shows that record to people. The decisions list is the useful bit: each one says what was chosen and why, and links to the session. When you wonder why the code does something odd, the answer is usually already there. The History tab shows how the memory changed over time, and you can read it as of any date.

Issues: the TODOs agents leave behind

Agents leave a lot of loose ends: “this still needs a check on Windows”, “not deployed yet”, “the old data is still wrong”. Usually that text sits in a chat log nobody opens again.

In Origin, those open items become Issues on the repo automatically. They have a priority, they show which session raised them, and they close when a later session finishes the work. The [Verify] ones are checks an agent said a human should do. So the backlog of agent work is visible, and the next agent sees the same list through memory.

Why this matters now

GitHub was built for a world where the author of a commit wrote it, remembered why, and could be asked. None of that holds when agents write most of the code:

The author column lies by omission. One person can run four agents on six models in a day. Without attribution you can’t tell which agent writes code that sticks, which one gets reverted, or what any of it cost.
The reason is lost. The prompt and the decisions are the real source of a change. They live in chat logs on one laptop and disappear. Origin keeps them next to the lines they produced.
Review can’t keep up. Nobody reads every line an agent writes. Knowing which files are AI-written and which sessions nobody reviewed tells you where to spend the review time you have.
Agents forget. Every new session pays to rediscover the repo. A shared memory and an open-issues list means the next agent starts from where the last one stopped, not from zero.
For an engineering lead, this is the repo page that answers the questions you get asked now: how much is AI, which agent, what did it cost, did anyone review it, what is still open. For the agents, it is the context they need to not repeat each other.

Connect a GitHub or GitLab repo at getorigin.io and install the CLI. The repo page fills in from your existing history, and every new session adds to it.

AI Code Provenance: How to Track AI-Generated Code in Git

Serhii Troian — Thu, 01 Oct 2026 16:56:14 +0000

AI Code Provenance: How to Track AI-Generated Code in Git

Pull request lands in your repository. Tests pass. Diff looks reasonable. Git shows which files changed, when the commit was created, and which developer pushed it. One important part of the story is still missing.
Was this function written manually, generated by Claude Code, rewritten in Cursor, or produced during a Codex session? Which prompt triggered the change? What model was used? How many files did the agent touch before arriving at the final implementation?
Once AI coding tools become part of everyday development, commit history alone stops being a complete record of how software was created. AI code provenance fills that gap. Instead of showing only what changed, provenance connects code back to the AI session, prompt, model, and development context that produced it.

Git Records the Change, Not the AI Process Behind It

Git answers familiar engineering questions:

Who committed this change?
When was it committed?
What changed?
Which commit introduced this line?

AI-assisted development adds another layer before the commit exists. Imagine a developer asking Claude Code to refactor an authentication module. First response modifies six files. Developer requests a smaller implementation. Claude revises three files. Cursor is then used to fix a type error before everything is committed.
Git sees the final state. What it does not naturally preserve is the sequence of AI coding sessions, prompts, models, or intermediate changes that shaped the implementation.
Traditional git blame has the same limitation. It associates a line with a commit and an author, but that author may simply be the person who committed code largely generated by an AI agent. Human commit authorship and actual code generation are no longer always the same thing. That gap is where AI code attribution becomes important.

What Is AI Code Provenance?

AI code provenance is a record of how AI-assisted code was produced and how that activity connects to the resulting source code.
Useful provenance should answer questions such as:

Which AI agent and model produced a change?
Which prompt resulted in a specific file or line?
Which developer initiated the AI coding session?
What files changed?
How did the implementation evolve?
What token usage or cost was associated with the work?

Provenance is different from AI code detection.
Detection asks:
“Does this code look like AI wrote it?”
Provenance asks:
“What recorded AI activity produced this code?”
Second question is far more useful for engineering teams because it relies on captured development context rather than guessing after the fact. As organizations move from occasional AI suggestions to agent-driven workflows with Claude Code, Cursor, Codex, Gemini CLI, and similar tools, being able to track AI-generated code becomes increasingly practical.

Why AI Code Attribution Matters

Knowing which agent generated a line may sound like extra developer analytics. In practice, it affects several core engineering workflows.

Code Review

Large AI-assisted pull requests are difficult to evaluate from a diff alone.
Suppose an agent rewrites authorization logic. Reviewer can see the resulting code, but not what the developer originally asked for or which assumptions guided the agent. Access to the relevant prompt or session provides context Git cannot show.
AI code attribution does not replace review. It helps reviewers understand both the output and the intent behind it.

Debugging

Consider a regression introduced three weeks ago.
git blame points to a commit. Commit points to a developer. Yet that developer may no longer remember which AI tool produced the implementation or what prompt was used.
With AI coding history connected to the code, investigation can continue beyond the commit. Engineers can trace affected code back to the relevant session or prompt and reconstruct how the implementation was produced.

Security and Audit

Coding agents can modify configuration files, authentication flows, infrastructure definitions, dependencies, and other sensitive parts of a codebase.
AI code traceability provides a clearer path between developer, agent, model, prompt, affected files, and resulting code. Goal is not to treat AI-generated code as inherently risky. Goal is to make its origin inspectable.
Same context also helps with auditability. If someone later asks how a specific implementation was produced, a commit hash may no longer be enough. AI code audit trail adds the missing development evidence.

Cost Control

AI coding costs are difficult to interpret when usage is disconnected from engineering output. Provider invoices may show total consumption, but not which repository, task, feature, or resulting code consumed that budget.
Connecting AI coding sessions to actual development work makes cost data more useful.
Instead of asking only:
“How much did we spend on models?”
teams can also ask:
“What work did that spend support?”

What Should AI Code Provenance Track?

Effective AI-generated code tracking does not require storing every action forever. It requires connecting relevant development context to the code that reaches the repository

Git remains the system of record for source code. AI code provenance extends that record with the context created before the commit.

How to Track AI Code in Git

Teams could ask developers to mention AI usage in commit messages, store transcripts separately, add labels to pull requests, or export model usage into analytics tools. Problem is fragmentation. Prompts may live in one tool, costs in another, code in Git, and agent transcripts on individual machines. Reconstructing a change later becomes difficult.
More useful approach is to capture AI interactions while development is happening and maintain a relationship between those interactions and the code they produce. That is the model behind Origin. Origin adds an AI coding history layer around the existing Git workflow instead of replacing it. It can capture prompt text, model information, files touched, diffs, tokens, cost, and session metadata while developers continue using their normal coding agents.
Support includes workflows with Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot, and other AI development tools. Result is provenance connected to the repository rather than a separate history that needs to be matched back to Git later.

From Git Blame to AI Git Blame

Traditional git blame answers:
Which commit last changed this line?
AI-assisted development adds another useful question:
Which AI interaction produced this line?
Origin provides line-level AI attribution so developers can move from source code back to the prompt and session associated with it.
For example:
origin why src/auth.ts:42
can expose the AI context related to a specific line, including the agent, model, and prompt behind the code.
Debugging flow becomes:
code → line → AI attribution → prompt → session
That gives engineers more context than simply knowing which developer committed the file.

Reconstructing AI Coding Sessions

Line-level attribution works well when an engineer already knows which piece of code needs investigation.
Sometimes the question is broader:
What did the agent actually do during the task?
AI coding sessions provide that wider view.
Session history can show prompts, affected files, model information, intermediate changes, and the context behind the final result. With Origin, developers can inspect captured sessions instead of depending on memory or disconnected local chat histories.
Value comes from maintaining the relationship between the session and the code that eventually reaches Git. Origin stores session information alongside the Git workflow using Git refs and notes, keeping AI coding history connected to the repository.

A Practical AI Code Provenance Workflow With Origin

Using Origin does not require teams to replace their Git workflow. Think of it as an additional history layer around development.

Enable provenance tracking
Install Origin and run:
origin enable
Origin integrates with the Git workflow and begins capturing supported AI coding activity.
Keep using existing coding agents
Developers continue working with Claude Code, Cursor, Codex, Gemini CLI, or other supported tools. Prompts, sessions, changed files, model usage, and related metadata can be captured as the work happens.
Inspect context when needed
Session history helps with reviewing an entire AI-assisted task. Line-level attribution helps when investigating specific code. Teams can move from a final line back to the prompt that produced it instead of stopping at the commit. Origin supports this workflow for both individuals and teams.
Solo usage focuses on personal AI development history, including session replay, token and cost tracking, repositories, sessions, and local CLI workflows.
Origin Team adds centralized visibility, policies, GitHub and GitLab pull-request checks, budget controls, and audit logs.
For one developer, provenance may answer:
“What did my agent change yesterday?”
For an engineering organization, the same data can support review, security, governance, cost visibility, and auditing across multiple repositories.

Provenance Should Add Context, Not More Process

Governance becomes ineffective when developers spend more time documenting work than doing it. Manually recording every AI interaction, copying prompts into pull requests, labeling generated files, and reconciling model usage afterward is difficult to sustain. Automatic capture with selective inspection is more practical.
Developers keep working in Git and their preferred coding agents. Reviewers, engineering leads, and security teams retrieve deeper context only when they need it. That becomes increasingly important as agent usage grows faster than any manual documentation process.

Git History Is Still Essential. It Is Just No Longer the Whole Story

AI coding agents do not make Git less important. They make surrounding context more important.
Commits still record durable repository changes. Pull requests remain a primary review surface. git blame still helps engineers understand when code changed.
Another history now exists before the commit: prompts, models, AI coding sessions, intermediate changes, agent decisions, and usage data.
AI code provenance connects those two histories. Engineering teams can track AI-generated code without abandoning Git or forcing developers into a completely new workflow.
When a reviewer, developer, security engineer, or auditor asks:
“Where did this code come from?”
answer no longer needs to stop at a username and commit hash.
It can lead back to the AI session that created it.
Explore Origin to capture AI coding history alongside Git and add traceability to AI-assisted development.

Switching AI Agents Without Starting Over

Serhii Troian — Mon, 31 Aug 2026 18:51:51 +0000

A note the last session leaves in your repo, so the next one — any vendor — knows where the work stood

We build Origin, an MIT-licensed CLI that runs alongside AI coding agents and records each session into the repository itself. This is how one part of it works.

1. The note the last session left

AI coding agents — Claude Code, Cursor, Codex and the rest — work in sessions. You open one, you work, you close it, and everything it understood about the task is gone. The next session starts blank. If you switch to a different agent it starts blanker still, because none of them can read each other’s history.

Here is the exception. This was sitting in an agent’s context window one morning, before anyone typed anything:

Previous session context (claude-code, 18h ago):
Summary: Diagnosis is solid. It's not Origin's code — it's CPU
starvation from the host.
Last prompt: "Origin is slow again, debug what's the issue"
Changes: +6774 -308 lines

Nobody pasted that in. Nobody asked for it. The session that produced it had ended eighteen hours earlier and wrote it to a file on the way out. When the next session started, that file was read and rendered into its prompt before the first instruction arrived.

So the agent opened already knowing where things stood — which branch, which files were unfinished, what the last instruction had actually been. That is the entire feature. The rest of this article is about why the block is that short.

2. What it is like without one

You spent Friday afternoon on something nasty. Three files half-rewritten, a branch you named in a hurry, a fix that worked but needed one more case handled. You closed the laptop.

Monday you open your agent and type “ok let’s finish this.”

It has no idea what “this” is. So the first ten minutes go to reconstruction: which branch, which files are dirty, what the goal was as opposed to the last thing you typed, what you already tried and rejected. You are briefing a new hire who was in the room on Friday and remembers none of it.

Then make it worse in the way that is now normal — on Monday you open a different agent. Friday was Claude Code; today you want Cursor, or Codex, or whatever shipped a better model last week. Each keeps its history in its own directory in its own format, and none of them read each other’s. There is no shared storage even in principle.

This is not an edge case. People pick an agent per task, not per project, and the switching cost is paid in re-explanation every single time.

3. Seeing it

The note lives at .git/origin-handoff.json. You can read exactly what is stored and exactly what the next agent will be given:

$ origin handoff show

Cross-Agent Handoff Context

Agent: claude-code
Model: claude-opus-5
Session: 7f3776c8
Ended: 18h ago
Branch: fix/prompt-capture-window

Last prompt:
"the turn count is still wrong on merge commits"

Files in progress (3):
packages/cli/src/git-capture.ts
packages/cli/src/session-state.ts
packages/cli/src/commands/hooks.ts

Changes: +212 -47 lines

Open TODOs:
- handle the squash-merge case in the same pass

Context that will be injected into next agent session:
──────────────────────────────────────────────────
...
──────────────────────────────────────────────────

origin handoff clear throws it away if you would rather start clean.

4. What gets carried

Every field earns its place by answering a question you would otherwise have to answer yourself.

Two properties matter more than the schema.

It is written at the end of every turn, not at session end — so an agent that crashes, is killed, or is closed without ceremony still leaves a current note behind.

And agentSlug is written by one agent and read by another. That is what makes it cross-vendor: a Cursor session’s note is read by a Claude Code session, and says plainly that it came from Cursor.

5. The hard part is what it refuses to carry

This is where a feature like this is won or lost. Each rule below exists to prevent a specific bad experience, and each costs the feature something on purpose.

Not the transcript. There is a permanent temptation to make the note bigger — the whole conversation, every file read, all the reasoning. Every version of that makes it worse. The value is that the next agent reads it completely before starting work. A 40,000-token history does not get read, it gets skimmed, and skimmed context is how an agent confidently resumes the wrong task.

Not a session where you only talked. Ask your agent a question — “what’s in this repo’s history?” — and it answers. No files changed, nothing written. If that session overwrote the note, Friday’s real work-in-progress would be replaced by Monday’s idle question, and the next agent would open oriented around nothing. So a session that touched no files and changed no lines never replaces one that did.

Not its own output, fed back. Origin already injects context at session start. Ask an agent about that context and its answer is a recap of the injection. Store the recap as the session summary and the next session injects it, the agent after that recaps the recap, and within days the note is a description of a description of something that was once actual work. So the feature recognises text that is its own prior output and refuses it — on read as well as on write, which means a repo that already picked one up heals itself the next time it is read.

Not everything you say, as a commitment. Open TODOs are the highest-leverage field and the most dangerous, because a TODO is injected into every future session until it is resolved.

“We should refactor the retry logic” is a commitment. “We need to switch the gh user, but switch it back after” is an instruction for right now.

If the extractor cannot tell those apart, you get an agent that keeps trying to switch your GitHub user next week, for reasons nobody remembers. So extraction is anchored to actual development verbs (fix, add, refactor, migrate, handle…) and rejects hedged phrasing (I think, maybe, for now, never mind). Both rules deliberately match less.

That inversion is the most transferable idea here. In an ordinary data pipeline you tune an extractor toward recall, because a false positive is just a bad row somebody filters later. When the consumer is a language model, a false positive is an instruction that a capable system will act on, repeatedly, until a human notices. The cost is unbounded and nearly undetectable, because a plausible-looking TODO is indistinguishable from a real one.

Not stale state. A note older than 24 hours is not injected at all. In-progress state decays fast: a day-old list of “files in flight” probably describes files since committed, reverted, or rewritten by someone else. Confidently wrong context is worse than none, because the agent has no way to know it should distrust what it was handed.

6. It lives in .git, and that is a decision about you

.git/origin-handoff.json is not a committed file. It never appears in a diff, never shows up in a pull request, never lands in a teammate’s clone. It is scoped to your checkout, the way .git/HEAD is. Three consequences worth knowing before turning it on:

Nothing leaks into review. Your last prompt — however you phrased it at 7pm on a Friday — is not going in front of your team.
It does not sync. A colleague pulling your branch gets your code, not your note. Origin has a separate mechanism for metadata meant to travel between machines; this deliberately is not it.
You can inspect and delete it with ordinary tools. It is JSON on disk. cat it, rm it, or use origin handoff show and origin handoff clear.

7. What it cannot do

It cannot arbitrate between simultaneous sessions. It records the last one to finish, so in a checkout where three agents run at once the note reflects whichever stopped most recently. The honest fix there is a worktree per session, not a smarter merge.

It cannot reconstruct reasoning it was never given. If a session’s approach lived entirely in the model’s head and never touched a file, a note about files will not recover it.

And it is only as good as the last session’s summary. It is a bookmark, not a substitute for writing things down.

8. Why it belongs next to the code

Agents are becoming interchangeable faster than anyone expected. Which one is best for a given task changes month to month, and people switch accordingly, often mid-task.

The thing that should not be interchangeable is your place in the work. That state does not belong in a vendor’s session store, because you will not be in that vendor’s session tomorrow. It belongs next to the code — in a format anything can read, small enough that the next agent, whatever it turns out to be, can absorb it in one pass before touching anything.

The whole feature is a JSON file in .git. Most of the engineering went into deciding what to leave out of it.

Implemented in the Origin CLI (MIT, getorigin.io): handoff.ts holds the payload, the carry-forward rules and TODO extraction; context-injection.ts assembles and deduplicates the blocks injected at session start. origin handoff show prints the current note and exactly what the next agent will receive.

ORIGIN

Serhii Troian — Fri, 07 Aug 2026 13:05:01 +0000

Ground Truth for AI-Written Code

Session capture, per-line attribution, and selection-bias-free agent benchmarks - on top of the Git host you already use.

A technical overview for engineers and engineering leaders evaluating how much of their codebase is now written by AI agents - and who is accountable for it.

Contents

The problem: git blame no longer tells the truth
How Origin captures an agent session
Attribution: first-author-wins, with Git as the source of truth
Prompt-level time travel
Honest benchmarking: the agent scorecard
Bake-offs: the selection-bias-free comparison
For teams: governance without a second source of truth
Architecture, privacy, and getting started

1. The problem: git blame no longer tells the truth

On most teams, AI agents now write a large share of new code. But the tools that record who wrote what were built for humans. When an agent edits files in your working tree and you commit them, git blame attributes every one of those lines to you. The prompt that produced them, the model that ran, the cost, the number of turns, and whether the code survived the next sprint - none of it is recorded anywhere.

That gap has real consequences:

Provenance - no answer to “which agent, from which prompt, wrote this line?” during review or an incident.
Cost & efficiency - no ground truth on what a feature cost in tokens and dollars, or which agent got there in fewer turns.
Quality - no measure of whether agent-written code survives, or gets reworked and reverted days later.
Comparison - “which agent is better for us?” answered by vibes, because every naive comparison is poisoned by selection bias (the hard tasks go to the agent you already trust).

Origin closes that gap. It captures the full agent session - prompt, diff, tokens, cost, tools, duration - attributes every surviving line back to an agent and a prompt using Git as the source of truth, and turns that data into honest, selection-bias-free comparisons between agents. It runs on top of GitHub or GitLab; there is nothing to migrate.

2. How Origin captures an agent session

Capture is deliberately boring and durable. A one-time origin enable registers the machine, auto-detects installed agents (Claude Code, Codex, Cursor, GitHub Copilot, Gemini, Aider, Devin, Antigravity, and more), and installs two kinds of listeners:

Agent hooks - Origin hooks fire on the agent’s lifecycle events (session start, each user prompt, each tool/file edit, and stop/end). They record the prompt text, the per-turn file diff, token and cost counters, tool calls, and the model.
Transcript watchers - for agents that keep a durable on-disk transcript (e.g. Codex’s rollout logs, Devin’s local session DB), Origin reads that record directly instead of depending on hooks. The principle: if there is an authoritative transcript, read it; hooks are for context and policy.

Capture is resilient by design. It writes locally first, retries on a durable queue when the network is down, resolves session end from heartbeat liveness rather than a fragile inactivity timer, and is aware of git worktrees so parallel sessions don’t collide. Sessions that never produced real work are swept so counts reflect reality.

Figure 1. Every AI coding session Origin captured - agent, model, cost, tokens, branch, and review status. This is the raw material everything else is built on.

3. Attribution: first-author-wins, with Git as the source of truth

Recording a session is easy; attributing lines correctly is the hard part, and it is where Origin is opinionated. The model is first-author-wins: a line is credited to whoever introduced it, and later edits never re-claim it. For pushed commits, Git is the ground truth - Origin reconciles its capture against the committed diff rather than trusting a possibly-lossy hook stream.

Figure 2. One session, decomposed: each prompt and its diff (committed vs uncommitted), the linked commit, and a 100%-AI verdict - the ground truth per-line blame is built from. The AI Blame tab drills to the line level.

4. Prompt-level time travel

Because Origin records the state before every prompt, each prompt becomes a restore point. You can undo an agent’s changes - the files revert - without rewriting or losing your commits.

5. Honest benchmarking: the agent scorecard

Once sessions are captured and attributed, Origin computes a per-agent scorecard - efficiency, outcome, and survival - over your real work. The point of difference is honesty: the scorecard refuses to draw conclusions the data can’t support.

The guardrails matter as much as the metrics:

Minimum sample size - agents aren’t ranked on a handful of sessions; below a threshold, a metric is shown as “not enough data,” not a misleading average.
Confidence intervals - ratio metrics (e.g. tokens-per-line) carry a CI, so a noisy small sample can’t masquerade as a clear winner.
Estimated tokens excluded - sessions whose token counts were estimated rather than reported are flagged and kept out of the money math.
Line-weighted authorship - the AI-vs-human percentage is weighted by lines, not session count, so one giant human commit doesn’t get outvoted by many tiny agent ones.

Figure 3. The agent scorecard - cost, tokens-per-line, median turns, approval, and survival per agent, with sample-size and confidence guardrails.

6. Bake-offs: the selection-bias-free comparison

The scorecard measures agents on the work you happened to give them - and you give the hard tasks to the agent you trust, which skews every comparison. A bake-off removes that bias by construction: it runs the same prompt through N agents, each in its own isolated Git worktree, and lets you compare the results side by side. Every arm gets identical work.

Architecture: the server schedules, your machine executes

Coding agents run on your machine, with your keys - Origin’s cloud can never run them. So a bake-off is split cleanly in two: the server owns the queue and the schedule; a local runner daemon owns execution.
Each arm branches from HEAD into bakeoff//, the agent works autonomously and commits, and Origin correlates the result back to the branch via normal session capture - nothing extra to wire up. The list nests each arm’s session inline (cost, tokens, lines, status), filters by status/repo/agent, pages ten at a time, and rolls up a head-to-head agent comparison across every bake-off you’ve run.

Deliberately, Origin does not auto-declare a winner. It tints the cheapest and fewest-turns arms to help you scan, but “cheapest” and “best” are not the same thing - only a human reading the diff can decide. You pick the winner.

Figure 4. Composing a bake-off - the same prompt, two or more agents, each running autonomously in its own git worktree. Results stream back as sessions and roll up into a head-to-head comparison.

7. For teams: governance without a second source of truth

Everything above is per-developer value that also aggregates for a team. On top of it, Origin adds an org layer: typed policies enforced across review, PR checks, and CI; AI auto-review of agent sessions; secret and PII scanning on captured diffs; budgets and cost controls with per-agent visibility; role-based access; and an organization dashboard that shows what share of the codebase is AI-authored, by whom, at what cost - line-weighted, not guessed.

Because attribution is per line and travels with the repo (prompts are carried in Git notes, and a dedicated sessions branch makes context portable across clones), the governance view is derived from the same ground truth developers see - not a parallel system that drifts.

8. Architecture, privacy, and getting started

Local-first capture - session data is recorded on your machine first. A fully standalone mode keeps everything in the repo with no account at all.
Sits on your host - GitHub and GitLab, multiple connected accounts, native Windows/macOS/Linux CLI. No repo migration.
Portable provenance - prompts live in Git notes; the origin-sessions branch is a zero-tooling vehicle so a fresh clone still has the history.
CLI-native - the CLI is a single Node binary distributed via signed GitHub releases; the platform API runs on a small, boring stack (Express + Prisma).

Origin turns the invisible half of your codebase - the half an agent wrote - into something you can read, attribute, price, and compare. Solo, it’s your provenance and undo button. For a team, it’s the ground truth under every AI-code decision.

AI coding at team scale: sessions, budgets, and policies

Serhii Troian — Thu, 16 Jul 2026 17:28:22 +0000

What it takes to see every session, control the spend, and enforce policy when several agents are writing your code.

A pull request lands. Four hundred lines, six files, tidy commits. Which agent produced it? Which prompts? What did it cost? Did it touch anything it shouldn’t have? Has anyone actually looked at it?

For most engineering organizations, the honest answer to all five is: no idea. Your team adopted Claude Code, Cursor, Codex and Gemini in about six months. Your tooling still assumes a human typed every line.

Three things have to be true before any of that becomes answerable at team scale. You need a record of what the agents actually did — the sessions. You need to know what it cost, and be able to stop it before it hurts — the budgets. And you need your standards to be something that runs, not something on a wiki — the policies.

That’s the shape of the rest of this piece. The examples below are how we built it in Origin Team, but the three problems are the same whatever you use.

1. Sessions: what your agents actually did

Everything else is built on one thing: the session. If you can’t reconstruct what an agent did, you can’t cost it, review it, or govern it. So that’s where it starts.

The capture

Your engineers install a CLI, log in to your organization, and run one command inside their repo. From then on, capture is automatic. No per-tool setup, no changed workflow, and it works the same across every agent they use.

npm i -g https://getorigin.io/cli/origin-cli-latest.tgz

origin enable

The Sessions view then lists every session anyone on the team runs, with the name, model, repository, branch, and the engineer who ran it. Open one and you get the full timeline: each prompt, the agent’s output, and the exact changes that prompt produced, down to the files it touched and the lines it wrote.

That record is the raw material for everything that follows.

The dashboard: your organization at a glance

The dashboard answers what a lead actually asks on a Monday: sessions per agent, token usage this month broken out by agent, cost by model, and AI adoption, meaning how many of your engineers are genuinely coding with AI rather than just licensed for it.

Four tabs go deeper:

Activity — sessions per day, top agents, top repositories, and lines written this month. Team adoption breaks it down per engineer: how many sessions they ran, and how much code they actually produced.
Cost & efficiency — which agent is genuinely more productive: cost per session, cost per commit, cost per line.
Quality — reviewed PRs, approved PRs, and policy compliance.
Prompts — every prompt your engineers ran, searchable. Find a specific session or prompt for debugging, review, or reference.

Repositories: every change, attributed

Connect your GitHub or GitLab repos and every change made to them is tracked. Click into a repository and you see each commit by user, the familiar Git line-by-line view, and, on captured work, the prompt behind each change plus the agent and model that made it. You can also see which sessions ran inside that repo, and by whom.

It answers “what changed, who changed it, which agent, and what were they asking for” in one place, per repository.

Insights: the numbers you’ve been guessing at

Insights turns the session record into the view you actually wanted: AI authorship as a share of the lines written, lines changed over time, cost over time, cost by model, sessions and cost per repository, and model adoption, meaning which models your team leans on most.

It’s the difference between “we use AI a lot” and a number you can take into a budget meeting.

2. Budgets: what it costs, and stopping it before it hurts

Once you have the sessions, cost stops being a monthly surprise. Spend is tracked across the organization so you can project it, monitor it, and cap it: how much went to a specific engineer, agent, or model, alongside a monthly projection based on recent usage. Token utilization is tracked the same way, not just dollars.

Then you set the guardrails. Limits come at two levels:

A soft limit warns the engineer but lets them keep coding.
A hard limit stops the agent from writing code and tells the user they have exceeded their budget. Set them daily, weekly, or monthly, and scope them per organization, per engineer, per agent, per model, or even per repository.

This is the difference between finding out about a $600 Thursday on next month’s invoice and not having a $600 Thursday.

3. Policies: your rules, actually enforced

Most teams already have standards for AI use. They live in a Notion page nobody opens. Policies make them something that runs inside the coding session: rules that allow, restrict, or prohibit specific actions, for the whole org or for specific users.

Agents: what your team is allowed to run

First you decide the surface: which agents exist, which are allowed, and what rules ride along with each. Per agent, you can:

Set a system prompt that is shown to every engineer who launches it.
Set session limits, meaning how many tokens or how much cost a single session may consume.
Attach policies, org-wide or specific to that agent.
Review versions. Every configuration change is versioned, and you can roll back.
Control access, so you can see exactly who can use each agent.

The rules

The built-in rule types cover most of what teams need:

File restriction, to keep agents out of .env files, secrets, and prod configs.
Model allow-list, to ban specific models from being used for coding.
Content filter, to block specific words, phrases, or patterns.
Cost limits, required review, commit-message rules, and session limits.

When the presets don’t cover it, you describe the rule in plain English and the policy is generated for you, then injected into your agents: all of them, or only the ones you choose. Those rules reach each engineer through their CLI, and when someone crosses a line it shows up under Violations.

Pull request checks: the gate

A rule with no teeth is a suggestion. This is where it bites. Origin builds its review directly into GitHub pull requests and GitLab merge requests. When an engineer finishes a session and pushes, you get a PR check, and the pull request stays frozen until someone reviews what produced it: the sessions, the cost, the prompts, and the changes. Approve, and only then is it allowed to merge.

No new process for your team to adopt. The gate sits on the workflow you already have.

The rest of it

Snapshots let an engineer roll back to a specific prompt. Ten prompts deep and you want to return to prompt five? Digging through git history for that is miserable. Instead, pick the snapshot for that prompt, press restore, and the source is back to that point.

Security runs a built-in analyzer over captured work and flags what slipped in: credentials, API keys, emails, and other secrets that ended up in the source. Because every change carries the prompt behind it, tracing how something got there is a click, not an investigation.

Infrastructure shows the users and machines running Origin, a live picture of who and what is doing AI-tracked work.

IAM is where you define access levels to agents and repositories, and invite members with exactly the permissions you intend.

Settings holds general configuration, your coding plan (set per agent), API keys, and integrations: GitHub, GitLab, Slack, email reports, and an AI provider (recommended, so PR summaries and review checks work). Alongside it: notifications, a full audit log of everything reported, and a compliance tab for reporting.

One design decision underneath all of it

None of this works as a dashboard watching from the outside. The prompt, the model, the diff, and the cost are written into the Git repository itself, next to the commits they produced.

That has consequences worth caring about. The history travels with a clone: new laptop, new teammate, new agent, it comes along. It is vendor-neutral, so work recorded by Claude Code is readable by Codex. And there is no lock-in on your own project’s history.

Getting started

Setting up the organization takes a few minutes: create the account, pick the agents your team uses, set your billing policy, connect your repositories, and invite your teammates. Each engineer then installs the CLI and runs origin enable once. Their sessions roll up into your dashboard from that point on.

Origin Team is $29 per user per month, with a 14-day free trial. Solo developers use it free, forever.

Watch the full platform tour:

https://youtu.be/XMwH7j9Ij5k