Use case
Set spending caps for an AI coding agent on every project
Short answer
Every project has spending caps per ticket, per day and per calendar month. When a cap is hit, Autopilot starts nothing new, Run now is blocked and the message names the cap that stopped it.
Three caps on every project
Caps are set per project under Budgets and guardrails in Settings, and the setup wizard shows them, so you can set them before the first ticket runs. The per ticket cap keeps a single run from running away, and the per day and per calendar month caps are a ceiling across the whole project.
Limits on run time and tool calls sit alongside the caps.
What happens when a cap is hit
A cap stops the current stage cleanly instead of leaving a half applied change, and nothing already running is interrupted destructively.
A ticket also cannot ship if a budget was breached, because the ship decision checks that along with the evidence and your checks.
- A per ticket cap breach in the middle of a stage stops that stage immediately
- Autopilot stops enqueueing new tickets until you raise the cap or the period resets
- Run now is blocked on that project, with a message that tells you which cap was hit
See where the spend goes
You pick the model and effort for each pipeline stage, so heavier models can go where they matter and faster ones where they do not.
The dashboard shows cost per ticket as tickets ship, with cost split by stage, a budget forecast and token burn. Threshold alerts and a daily digest can reach you by email, Slack or webhook.
A cap is a ceiling, not a forecast
What a ticket costs depends on the size of the change and the model chosen for each stage, and there is no fixed price per ticket.
Run real tickets and read the dashboard: the cost per ticket as tickets ship is where your own figure comes from. Then set the caps to match.
Good fit
- Teams that want spending caps on each project
- Engineering leads who need to see what each ticket cost, split by stage
- Teams that run Autopilot and want it to stop picking up tickets when a cap is hit
Not the right fit
- Cost per ticket varies with the size of the change and the models you choose, so there is no fixed figure to plan on
- Caps limit spend, they do not predict it, so your own figure comes from real tickets on your own codebase
- It installs on a Linux server you operate, because there is no hosted version of the product itself
- Status today: Onboarding founding customers
Frequently asked questions
In Settings, under Budgets and guardrails, set a cap per ticket, per day and per calendar month for each project. The setup wizard shows the caps, so you can set them before the first ticket runs.
A per ticket cap breach in the middle of a stage stops that stage right away. Autopilot starts no new tickets, and Run now is blocked on that project with a message naming the cap, until you raise the cap or the period resets.
No half applied change is left. A cap that is hit mid stream stops the current stage cleanly, and nothing already running is interrupted destructively. Autopilot then waits until you raise the cap or the period resets.
Yes. The dashboard shows cost per ticket as tickets ship, along with tokens and duration for every attempt, cost split by stage and a budget forecast. Insights add the cost trend, so you can see where usage goes over time.
Related pages
Comparison
Versus hosted AI agents
A hosted agent runs on its provider’s machines. Reqursor Development runs on a Linux server you operate, with its secrets on your data volume and spending caps that you set per project.
Use case
Clear a ticket backlog
Your developers write tickets with acceptance criteria. Reqursor Development implements them in your repository and, by default, opens a draft pull request for your team to review.
See it on your own codebase
See Reqursor Development work through real tickets on a repository like yours, in a 30-minute call with the people who build it.