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:
Top comments (0)