Skip to main content
Requests is the workflow between “I hit my AI spend cap” and “someone changed it”. Seat holders file a limit request with a justification, reviewers see that person’s actual usage next to the ask, and approving one writes the new limit at the provider.
Requests needs a seat tracking project with a budget. See Set up AI seat tracking.

​
Get started

  1. Sign in to nOps.
  2. In the sidebar, open AI → Requests.
  3. If you are a reviewer, work the Open list. If you need more headroom yourself, switch to My requests and click Request an increase.
The sidebar entry carries a badge with the number of open requests, so you do not have to go looking.

​
Key features

​
The status rail

The left rail is how you slice the queue. Everything except Status is reviewer-only. If you can only see your own requests, the rail shows just the four status filters.

​
Filing a request

Switch to My requests and click Request an increase to open the Request a limit increase composer:
  • Limit request shows your current limit for context.
  • Desired new limit is the cap you are asking for. It has to be higher than your current one. nOps suggests a figure that covers your projected spend for the period; click Use suggested to take it.
  • Why do you need this? is the justification your reviewer reads — expected traffic, timeline, or launch context.
Click Submit request. Requests filed this way ask for an ongoing baseline, not a temporary bump; the reviewer decides whether to make it temporary at approval time. If your project has a Request Prefix, your request gets a readable ID like ENG-1001 that you can paste into a ticket or chat.

​
Blocked now

Blocked now lists seats that have run out of limit, whether or not anyone has filed anything. Each entry shows the seat, how much of the limit is used, the current limit next to a proposed one, and a generated Why this change summary. Open a request straight from here — it is marked as automatically triggered so it is obvious it did not come from the seat holder. This is the fastest path when someone pings you saying they are stuck.

​
Reviewing a request

Selecting a request opens a detail pane with the ask, the requester, the current and requested limits, the justification, and that seat’s real usage — including model usage — so you can judge the request against behavior rather than a number in isolation. Under Finish your review: A temporary approval defaults its review-again date to the end of the current month, so a launch bump does not silently become permanent.

​
Comments and activity

Every request has a discussion thread with Comments and Activity tabs. Type @ to mention someone. Activity is the audit trail of what happened to the request and when. If your project has issue tracking connected, requests can carry a link to the corresponding ticket.
Approving a request writes the new limit at the provider. Only Claude Enterprise supports limit writes today — Cursor and ChatGPT / Codex spend is tracked read-only.

​
FAQs

Seat tracking admins. You can also set per-group approvers in Wallets so requests route to the person who owns that group’s spend.
The restricted request-viewer role is scoped to your own requests by design. Reviewers get the Show switcher and the team queue.
Yes. Edit Applied limit on approval before approving; that is the number that gets written.
It comes back for review on the date you set, which defaults to the end of the current month.
A rebalance run can open one request per affected seat instead of writing limits directly. Those show up in this same queue. See Automated Rebalance.