> ## Documentation Index
> Fetch the complete documentation index at: https://help.nops.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Requests

> The queue where people ask for a higher AI spend limit and reviewers approve, reject, or ask for more detail.

**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.

<Note>
  Requests needs a seat tracking project with a budget. See [Set up AI seat tracking](/ai/setup).
</Note>

## Get started

1. Sign in to [nOps](https://clara.nops.io/dashboard).
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.

| Group           | Options                                                                                               |
| --------------- | ----------------------------------------------------------------------------------------------------- |
| **Show**        | **Team requests** or **My requests**.                                                                 |
| **Blocked now** | Seats that are out of headroom right now, with a live count.                                          |
| **Status**      | **Open**, **Needs info**, **Approved**, **Rejected**, each with a count.                              |
| **Rebalancing** | **Increase** and **Decrease** counts that jump you to [Automated Rebalance](/ai/automated-rebalance). |

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**:

| Control                       | What it does                                                                                                |
| ----------------------------- | ----------------------------------------------------------------------------------------------------------- |
| **Applied limit on approval** | The limit actually written if you approve. You can approve a different number than was asked for.           |
| **Duration after approval**   | **Permanent** keeps it as the new lasting cap. **Temporary** is a time-boxed bump for a launch or incident. |
| **Approve request**           | Applies the limit at the provider.                                                                          |
| **Request more info**         | Moves the request to **Needs info** and puts it back to the requester.                                      |
| **Reject**                    | Declines the request.                                                                                       |
| **Close**                     | Closes it without a decision.                                                                               |

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.

<Warning>
  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.
</Warning>

## FAQs

<AccordionGroup>
  <Accordion title="Who can approve a request?">
    Seat tracking admins. You can also set per-group approvers in [Wallets](/ai/wallets) so requests route to the person who owns that group's spend.
  </Accordion>

  <Accordion title="Why can I only see my own requests?">
    The restricted request-viewer role is scoped to your own requests by design. Reviewers get the **Show** switcher and the team queue.
  </Accordion>

  <Accordion title="Can I approve a different amount than was requested?">
    Yes. Edit **Applied limit on approval** before approving; that is the number that gets written.
  </Accordion>

  <Accordion title="What happens to a temporary approval when it expires?">
    It comes back for review on the date you set, which defaults to the end of the current month.
  </Accordion>

  <Accordion title="Where do requests opened by automation come from?">
    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](/ai/automated-rebalance).
  </Accordion>
</AccordionGroup>

## Related

* [Automated Rebalance](/ai/automated-rebalance)
* [Wallets](/ai/wallets)
* [Budgets](/ai/budgets)
* [Set up AI seat tracking](/ai/setup)