AI Spend Management with Requesty: A Practical Guide

Enlarge

"We have a monthly AI budget" sounds controlled. Often it only describes one number.

The same organisation may still be running separate provider accounts, shared API keys, developer tools, production agents and experiments nobody has looked at since the demo. Finance sees the total once the bill arrives. The platform team cannot always say which team, person, application or agent caused it.

The practical answer is to manage spend at the point where AI requests are routed. That is the one place where every request is visible before the money is spent, rather than aggregated after it.

This guide covers what Requesty can measure, how to structure spend ownership, where budgets belong, how alerts work, and the controls that lower cost per outcome rather than only capping the total.

The whole discipline is a loop, and skipping a stage is what produces the surprise at month end.

Why does AI spend become hard to manage?

AI spend rarely becomes difficult because a model has a published price. It becomes difficult because usage is distributed.

Requesty gives one view of spend across providers and models, and lets the controls sit closer to the team, person or workload creating the cost.

The objective is not to stop people using AI. It is to let teams use AI freely inside known boundaries.

What can Requesty measure?

The Analytics dashboard reports total spend, cost over time, cost by model, cost by user and projected end-of-period spend based on the current rate. Every non-streaming response also returns the request's own USD cost in the standard usage object, so the same figure that appears on the dashboard can feed your own metering.

"usage": {
  "prompt_tokens": 13,
  "completion_tokens": 17,
  "total_tokens": 30,
  "cost": 0.0000935
}

On a streaming call, pass stream_options with include_usage set to true to receive that final chunk.

The useful reporting dimensions

Two of those deserve care because they are easy to confuse. A member is a person inside your Requesty organisation, typically the developer who owns a key. A user is an external end user identity you supply yourself in the request metadata. One answers "whose key was this", the other answers "who was this for".

Group spend is aggregated monthly for budget monitoring at group level, which is where you check a team against its allocation. The analytics Group By control works on the dimensions in the table above, so if you need per-team reporting inside a chart, carry the team in a custom metadata field as well as in the group.

Enlarge

How should spend ownership be structured?

Before setting any budget, decide what each identity in Requesty represents. A practical structure looks like this.

Organisation
│
├── Engineering group                      team allocation
│   ├── Alice, individual member           personal limit
│   └── Support Agent, service account     workload owner
│       ├── support-agent-production       hard cap
│       └── support-agent-staging          small cap
│
├── Marketing group                        team allocation
│   ├── Content team members               personal limits
│   └── campaign-generator-production      hard cap
│
└── Request metadata                       unit economics
    ├── feature
    ├── environment
    ├── customer_id
    └── tier

Use groups for accountable teams

Groups can match departments such as Engineering and Marketing, projects such as a product launch, or functions such as the AI platform team. Requesty aggregates monthly spend at group level and lets administrators attach access lists, approved models and budgets to a group. New members join the default group and inherit its settings, so what that group grants is your real baseline whether or not anyone chose it deliberately.

Use members for human activity

An individual member should be a named person whose own experimentation or development usage needs measuring separately from the applications they build.

Use service accounts for applications and agents

A service account is a non-human identity. It can represent a production API, a mobile app, an agent or an analytics job, and it can own multiple API keys without tying their spend to an employee.

Do not attach a production agent permanently to a developer's personal identity. Create a service account, then give it separate production, staging and experimental keys. The spend then belongs to the workload, and it survives that developer changing team.

Use metadata for business-level attribution

Keys identify the workload. Metadata identifies what happened inside it. Custom fields travel with the request and surface in logs and analytics, which is what lets you answer a question a key cannot, such as what one feature or one customer cost.

response = client.chat.completions.create(
    model="policy/support-assistant",
    messages=messages,
    extra_body={
        "requesty": {
            "user_id": "user_1234",
            "tags": ["support-assistant"],
            "extra": {
                "feature": "meeting-summary",
                "environment": "production",
                "customer_id": "acme",
                "tier": "enterprise",
            },
        }
    },
)

Standardise those field names across the organisation before anyone builds a report on them. Two teams spelling the same environment differently is the most common reason a cost breakdown cannot be trusted.

Where should budgets sit?

One organisation-wide ceiling is not enough, because it tells you nothing about who to talk to when it is reached. Put the control closest to the source of the risk.

Group budgets: check which mode you are in first

This is the detail that most often makes a written budget policy wrong.

A team of ten with a $5,000 group limit means $50,000 of headroom in Global mode and $5,000 in Group Budget mode. Confirm the mode before documenting anything, and state it explicitly in the policy you write.

User limits: how much autonomy should one person have?

Administrators can set an individual monthly limit, define a default limit that applies to new members automatically, compare current-month spend against the limit, and let a cutoff apply when the limit is reached.

The default for new members is the setting worth getting right first. It is the only one that applies to people nobody has thought about yet.

Key limits: what is the maximum blast radius?

Each API key can carry its own monthly spend cap, and the cap lives on the key rather than on the service account above it. A workload's real ceiling is therefore the sum of its keys' caps, which is what lets one owner hold a generous production key and a deliberately small staging key.

Separate keys matter most for:

• Production applications
• Autonomous or scheduled agents
• External integrations
• Temporary experiments
• Partner or customer keys

When a key reaches its limit, new requests using that key are blocked until the next billing period. That is a feature, and it is also the reason a production workload and an experiment must never share a key.

An illustration, not a customer claim

A Customer Support team holds a shared monthly budget of $5,000 in Group Budget mode. Standard team members can spend up to $250 each. The production support assistant has its own service account, with a $3,000 cap on its production key and $250 on its staging key.

A staging loop cannot consume the production allocation. One employee's experimentation cannot consume the team budget. Nothing about that requires anyone to ask permission before using AI.

How should spending alerts be configured?

A budget defines the boundary. An alert creates time to act before the boundary is reached.

Requesty evaluates thresholds as requests are processed. An alert fires once when a threshold is crossed and does not repeat until it is crossed again, such as in a new billing cycle.

Thresholds are organisation-wide, at a level

This is the part most teams get wrong on the first attempt, so it is worth being blunt about.

A threshold is not attached to a particular key, service account, group or person. You choose an alert type, which fixes the level it watches, and a value. It then applies across the organisation at that level. An API key threshold of 80% fires for any key that reaches 80% of its own limit. A user threshold of 80% fires for any user who reaches 80% of theirs.

In practice that inverts how you design the two controls together. Per-key limits carry the specificity, because each key's percentage is measured against its own cap. The alert is the single tripwire that sits above all of them.

Enlarge

The two absolute-spend types are the useful ones for anything new. They fire on a dollar amount and work even where no budget has been configured, which makes them a safety net for a workload nobody has sized yet. Percentage alerts need a budget to measure against, and an API key percentage alert needs that key to have a monthly limit set.

Enlarge

A practical threshold ladder

The percentages should reflect how fast the workload can spend. A low-volume internal tool may only need one warning at 80%. A high-volume production agent can move from normal to over budget inside a few hours, so it needs several thresholds and a named owner who is reachable out of hours.

Every alert needs an action

Do not create a threshold without deciding who receives it, who investigates it, whether the limit may be raised and by whom, which usage should be reduced first, and by when the decision has to be made. An alert with no owner is a notification that trains people to ignore notifications.

Alerts are delivered by webhook, configured once for the organisation, as a generic JSON payload, a Slack incoming webhook or a Microsoft Teams card. Failed deliveries are retried three times with exponential backoff, and each attempt times out after 15 seconds. A threshold with no valid webhook is stored but delivers nothing, which is a quiet way to believe you have monitoring you do not have.

Enlarge

How ZoomInfo centralised spend control for 1,300+ engineers

How do you reduce AI cost, rather than only contain it?

Budgets reduce the risk of unexpected spend. They do nothing about the cost of a request that was always going to happen. Those are separate problems and they need separate controls.

1. Right-size the model

Use the cost-by-model breakdown to find expensive models doing simple work. Classification, extraction and light summarisation rarely need the model you chose for complex reasoning or agent planning.

The goal is not the cheapest model everywhere. It is to reserve premium models for the work that benefits from them, which is usually a small share of requests and a large share of the bill.

2. Route inexpensive requests first

A routing policy can start with a lower-cost model and fall back to a more expensive one when the cheaper model fails or is unavailable. That gives you a cost-aware cascade behind a single stable model name, with no provider-specific logic in the application.

3. Cache repeated prompts and context

Workloads with a large repeated system prompt or repeated context pay the full input cost every time unless caching is in play. Auto caching inserts cache breakpoints into the largest content blocks before the request is forwarded, so repeated prefixes are billed at a fraction of the normal input rate.

Two things worth knowing before you count on it. The payload does not shrink, since you still send the full message history; only the billing changes. And providers enforce a minimum cacheable prefix, so short prompts are not eligible.

The Savings tab then reports whether it worked: dollars saved, percentage saved, cache hit rate and token cache rate.

Enlarge

That distinction matters more than it sounds. A lower bill is not evidence of optimisation. Savings percentage and cache hit rate hold roughly steady when a workload is genuinely more efficient, and they move with volume when the bill fell because people used the product less.

What does that look like when it works?

Recommended implementation checklist

1. 1
   Assign ownership before configuring anything

   • Name who owns AI spend at organisation, team and workload level.
   • Create groups that match real departments or accountable projects.
   • Check what the default group grants, since new members inherit it.
   • Create service accounts for applications, agents and integrations.

   A budget with no named owner is a number, not a control.

2. 2
   Make spend attributable at the request

   • Use separate API keys for production, staging and experiments.
   • Send an external user ID where end users matter to the analysis.
   • Add custom fields for feature, environment, customer and tier.
   • Agree the field names and spellings across teams before reporting on them.
3. 3
   Set the budgets

   • Confirm whether the organisation is in Global mode or Group Budget mode, and write it down.
   • Set realistic user limits, including the default that applies to new members.
   • Put a monthly limit on every production and experimental key.
   • Cap staging and experimental keys well below production.
4. 4
   Configure alerts and the actions behind them

   • Add percentage thresholds at the levels you budget on.
   • Add absolute-spend thresholds as a safety net for unbudgeted workloads.
   • Configure the webhook and send a test, since a threshold without one delivers nothing.
   • Write down who receives, who investigates and who may raise a limit at each threshold.
5. 5
   Review monthly, and rebase

   • Check projected spend against the allocation during the month, not after it.
   • Review model mix, cost by feature and caching savings alongside total spend.
   • Investigate any key whose share of total spend changed sharply.
   • Rebase limits on observed usage instead of leaving the initial guess in place.

   Most budget policies fail slowly, by never being revisited after the first month.

What does Requesty not decide for you?

The gateway can measure, attribute, cap, alert and route. It cannot make the judgements that give those numbers meaning.

Those are business decisions, and they are better ones when the data underneath is attributable. That is the whole argument for doing this at the gateway: not that it decides, but that it removes the excuse that nobody could tell where the money went.