Claude Code bills to your company account wherever a developer opens it - a personal fork, a side project, 2am on a Sunday, or well past what this month was meant to cost. Normally you find out when the invoice does. Lineman checks every session against six rules and tells you within minutes, in Slack, Discord, email, PagerDuty or any signed webhook.
A walkthrough on your own setup. Alerts are on Pro; cost reporting is free.
Alerts arrive where you work
A coding agent has no idea which repositories are yours. It reads the checkout it is given and bills the key it is handed. A fork, a side project, an experiment on a personal account: all of it lands in the same invoice, four weeks later, as one number.
It reports keys, models and dates. Whether the work was on your codebase is not a question it can answer.
By the time an unusual line item is visible, the spend is committed and the context is gone.
Every company has a rule about where company resources may be used. Almost none can tell you when it was broken.
The message carries the rule, the repository, the person, the amount and the window. The link goes straight to the spend behind it.
Unauthorised repository
$412.87 recorded against a repository that is not on the authorised list.
Figures are illustrative. The layout is the one the Slack renderer produces.
A runaway agent, a policy breach and a blown budget are the same event seen from three chairs.
Not a line item somebody finds in arrears. The alert names the repository, the person and the amount, and links straight to the spend behind it.
Daily, weekly, monthly and per-person budgets, with threshold crossings raised as they happen rather than reconciled a month later. Every breach carries its evidence.
Every company has a rule about where company resources may be used. This is the one that can tell you, the same day, when it was broken and by how much.
Alerts and budgets are on Pro. Cost reporting, including the full breakdown, is on the free tier.
Send the alert where the team already looks. Availability is per destination, because each one is released only after it has been run against the real service.
The alert renders as a card with the rule, the amount and a link back to the spend.
For teams that would rather see spend beside their other signals than in a chat channel.
Observability destinations are reached over OTLP, so anything that accepts OpenTelemetry works, whether or not it is named here.
A signed webhook covers every destination we have not built a first-class connector for, including your own service.
These are the exact rule types the evaluator produces, and the exact event names they publish as. A name with no producer behind it would be worse than no name at all, so there are none on this page.
| Rule | Event | Fires when |
|---|---|---|
| Unauthorised repository | cost_alert.unauthorized_repo | Spend was recorded against a repository that is not on your authorised list. |
| Out of hours | cost_alert.out_of_hours | A member spent outside the working hours configured for them. |
| Daily budget | cost_alert.budget_day | Company spend crossed a threshold of the daily budget, including passing it outright. |
| Weekly budget | cost_alert.budget_week | Company spend crossed a threshold of the weekly budget. |
| Monthly budget | cost_alert.budget_month | Company spend crossed a threshold of the monthly budget. |
| Member budget | cost_alert.member_budget | An individual's spend crossed a threshold of their own budget. |
Unauthorised repository
Spend was recorded against a repository that is not on your authorised list.
Out of hours
A member spent outside the working hours configured for them.
Daily budget
Company spend crossed a threshold of the daily budget, including passing it outright.
Weekly budget
Company spend crossed a threshold of the weekly budget.
Monthly budget
Company spend crossed a threshold of the monthly budget.
Member budget
An individual's spend crossed a threshold of their own budget.
Unauthorised-repo and out-of-hours alerts are classed as policy breaches, so they stay separable from budget noise in the board and in the payload.
The parts that matter if you are going to wire an alert into something that pages a human.
An HMAC signature over the raw body, so a receiver can prove the payload came from us before acting on it.
Each alert carries its rule type, the subject, and a dedupe key, so a receiver branches on a field rather than string-matching an English title.
Amounts are carried as integer micro-USD with a floating-point sibling beside them. No cents, no guessing which unit a field is in.
Send webhook.test on demand, so an endpoint and its signature verification can be proven without waiting for a real alert to fire.
{
"type": "cost_alert.unauthorized_repo",
"dedup_key": "unauthorized_repo:grant-personal/scratch-agent:2026-07-28",
"subject_user_id": "9f2c...",
"detail": {
"repo": "grant-personal/scratch-agent",
"spend_usd_micro": 412870000,
"spend_usd": 412.87,
"window_start": "2026-07-28T09:00:00Z"
}
}Three things worth knowing before you rely on it.
The evaluator runs every five minutes against completed sessions. It is a governance control, not a circuit breaker: it tells you a rule was broken, it does not stop the session that broke it.
Cost reporting, including the full breakdown by repository, developer and ticket, is on the free tier. The alerting and budget surfaces are the Pro-only part, and we would rather say so here than at the checkout.
Spend from a machine without the plugin installed is not evaluated, because it never reaches us. Authorised-repository alerting is only as complete as your plugin rollout.
If you have something we haven't covered, email us and we'll get back to you.
You keep an authorised list. Anything outside it that records spend raises the unauthorised-repository alert. Connecting GitHub, GitLab or Bitbucket populates the list for you, and you can edit it by hand.
Bring your repository list to the call and we will show you what the rules would have caught. Or start on the free tier and turn alerting on when you are ready.