Set the AI budget once.
Never approve again.
A team hits its token limit and asks for more. Navigara agent answers in seconds against rules you set, with the reasoning attached.
Trusted by engineering teams
Checkout needs 30% more tokens
$14,300 → $18,590 per month · raised by the team lead · answered in 1.4s
- ENG-2841 · Guest checkout rewrite, 3 of 5 sprints
- ENG-2903 · Card vault migration, on track
- ENG-2917 · Address validation, in review
Cheapest unit of delivery in the org, and it has been on its ceiling since the 4th. At this team's rate, the $4,290 it is asking for buys roughly 51 more ETV a month. The same money at Mobile's rate buys 9.
The person approving your AI budget has never seen your roadmap.
Somebody in finance holds the queue. Approve everything and the ceiling means nothing. Decline on instinct and you throttle whichever team happened to ask.
It is not a judgement problem. Nobody has given them anything to judge with.
The amount is not the question
Whether $12,000 is a lot depends on what the last $12,000 produced.
Volume is not delivery
Pull request and commit counts inflate when work gets cheaper to produce.
The loudest team is not the neediest
Requests arrive in the order teams think to send them. Nothing more.
Toggle the panel above. The request is identical on both tabs. On one it has been sitting on a desk for two days. On the other it was answered before anyone read it.
The biggest number on the screen is almost never the problem.
One request in isolation is still not enough. What makes a limit decision easy is the other five teams next to it, priced the same way. Token spend is not normally distributed, so a list sorted by spend puts the heaviest agent users at the top and the answer writes itself. Add what each of them delivered and the order comes apart.
| Team | Devs | Cap | Spent | Delivered | AI spend / ETV | Aligned | Perf |
|---|---|---|---|---|---|---|---|
Checkout26d at cap | 22 | $14,300 | $14,180 | 168 ETV | $84.40 | 87% | +14% |
Payments | 16 | $10,400 | $8,940 | 74 ETV | $120.81 | 68% | +6% |
Platform | 14 | $9,100 | $8,610 | 37 ETV | $232.70 | 54% | +3% |
Search19d at cap | 12 | $7,800 | $7,760 | 83 ETV | $93.49 | 76% | +9% |
Mobile | 12 | $7,800 | $7,340 | 16 ETV | $458.75 | 31% | -8% |
Growth | 14 | $9,100 | $6,020 | 63 ETV | $95.56 | 82% | +11% |
| Org | 90 | $58,500 | $52,850 | 441 ETV | $119.84 | ||
Sorted by spend, Checkout is the obvious place to cut and Mobile sits four rows below it. Sorted by what a unit of delivery cost, Checkout is the cheapest thing you own and Mobile runs at nearly four times the org median. The two teams pinned to their ceilings are the two you would least want to throttle.
Delivered work here is ETV, graded per commit. It is the denominator the whole page rests on, because dividing by pull requests measures activity, and activity is exactly what inflates once work gets cheaper to produce.
It does not penalise trial and error. Prompt six times if the sixth one lands: ETV prices what shipped, not the attempts behind it, and the ratio simply asks how many tokens it took to get there.
How every commit is graded, and what ETV countsDecide the policy once. Stop deciding the requests.
Once every request carries the same evidence, most of them stop needing a person. You write the conditions under which a team earns more room, and the limits follow the conditions. Three of the factors are on screen below; there are around twenty more, and none of them are on by default.
Set once, by the person who owns the budget
- Roadmap alignmentabove 75%
- AI efficiencycost per ETV falling
- Engineering performancedelivered ETV rising
- + 20 other factors
- Checkout✓ 87%✓ -22%✓ +14%Limit raised
Cheapest unit of delivery in the org, and it has been on its ceiling since the 4th.
- Payments✕ 68%✓ -4%✓ +6%Held at current
Alignment is under the bar and the cap is not binding. More tokens would not move it.
- Platform✕ 54%✕ +9%✓ +3%Limit reduced
Sixty percent of the month went to maintenance and fixes with no issue behind it.
- Search✓ 76%✓ -14%✓ +9%Limit raised
Second cheapest unit of delivery, and it hit the ceiling on nineteen of thirty days.
- Mobile✕ 31%✕ +34%✕ -8%Limit reduced
Forty percent of the spend went to fixing work the same team shipped last quarter.
- Growth✓ 82%✓ -18%✓ +11%Limit raised
Every rule passes. The team is cheap per unit because it stops work that is not landing.
Six decisions, none of which reached anyone's inbox. The two teams that were sitting on their ceilings got more room, and the money came from the two that were spending it on work nobody sequenced.
What a team actually experiences.
Nothing is silent and nothing is final. Every automatic decision arrives with the reasoning behind it, a person is one click away, and an approval is re-checked rather than left standing on numbers that have since moved.
- 1
The cap binds
A team draws down its monthly budget and stops.
- 2
It asks for more
One click. No business case to write, no thread to chase.
- 3
Answered in seconds
Approved or declined against your rules, with the reasoning attached.
- 4
Escalate any time
Not convinced? It goes to a person, carrying the same evidence.
- 5
Re-checked next month
If the numbers behind an approval move, a person is warned.
A team that clears every rule gets more room without asking. A team that misses one holds where it is. A team that misses most of them gets less, and finds out why in the same sentence you would have used.
Give us a fixed budget. We will handle the distribution.
This is not a request for more money. A flat per-seat cap splits the budget by headcount, which is a number that has nothing to do with who is converting tokens into shipped work. The total below does not move. Only the split does.
Mobile sits on its floor, at 40% of the flat cap, because the floor is where the rule stopped rather than where it wanted to stop. No policy can take a team to zero, and the floor is a number you set rather than one we pick.
The cap stops being the binding constraint on your roadmap, and it stops being a spreadsheet decision made by somebody who was not in the planning session.
An automated limit is a cap with better aim. It can still be aimed badly.
Output data is easy to misuse. Four guardrails exist for that reason, and the last one is how we would suggest starting.
Team level by default
Both are available. Team is the default, because a number beside a name gets optimised.
Every team has a floor
A rule can restrict a limit, never remove it. You set the floor.
A mandate beats a metric
Alignment is scored against the work a team was given, not the roadmap in the abstract.
Propose before it applies
Review mode drafts the decisions first. Switch it on when you stop disagreeing.
What this changes.
Answer whether a team deserves more tokens with six numbers instead of a feeling about the team
Stop being the person who throttles the team shipping the most roadmap, because it had the biggest bill
Hand engineering a fixed AI envelope and stop arbitrating who gets what inside it
Take the exception queue off your desk without giving up the ceiling
Tell the board the AI line moved because delivery moved, and name the teams either way
Stop managing AI spend on vibes.
Let Navigara manage the tokens.
Start in review mode. For the first quarter the policy only drafts the decisions, and you compare them against the ones you were making by hand. Turn it on when the two stop disagreeing.
Read-only by default
Navigara measures against your repositories, boards and provider bills. Enforcing a limit is a separate, opt-in step.
Your envelope, your rules
You set the total, the thresholds and the floors. We never raise a budget, only redistribute the one you fixed.
Every decision logged
The rule that fired, the readings behind it, the previous limit, and who can reverse it.