AI Spend Management for Engineering-Led Teams

Two meanings of the term, and which one this is

Search for AI spend management and most results come from SaaS management and corporate finance vendors. Zylo's 2026 buyer's guide says the phrase means two different things: finance software that uses AI to manage corporate spend, and software that manages spend on AI itself. The second meaning is usually framed for IT and procurement, with a focus on seat licenses, vendor dashboards, and renewals.

Engineering-led teams have a different problem. The spend comes from API calls that their own services make, the bill arrives per token, and the people who can change the number are the ones writing the code. For them, AI spend management is less about collecting invoices and more about deciding, before the traffic starts, how every request will be attributed and where it can be stopped.

Attribution is decided when you issue keys

Providers can only report spend along the dimensions they see on each request. Anthropic's Usage API filters and groups by API key, workspace, model, service tier, and a few other dimensions, and its Cost API groups by workspace or line-item description. OpenAI's Costs endpoint groups by project_id, user_id, line_item, api_key_id, and api_source. None of them knows which product feature, customer, or team made a call unless your key and project layout already encodes it.

That makes the key layout a cost design decision. A single shared key across five services produces one undivided line on the bill. A workspace or project per product surface, with a separate key per service inside it, gives you per-feature cost from the provider's own data with no extra tooling. Two gaps in Anthropic's reporting are worth knowing: usage in the default workspace reports a null workspace_id, and Console playground usage reports a null api_key_id. Spend that lands there cannot be attributed later.

• Create one Anthropic workspace or OpenAI project per product surface or team that owns a budget.
• Issue one key per service inside it, and never reuse a key across services.
• Keep production traffic out of Anthropic's default workspace, where workspace_id reports as null.
• For attribution finer than a key, such as per customer, tag requests in your own gateway or logs, because the provider will not see the tag.

Building one ledger from two providers

Both major providers expose admin endpoints for this. Anthropic's Usage and Cost Admin API requires an Admin API key, which starts with sk-ant-admin01. Its usage endpoint, /v1/organizations/usage_report/messages, returns token counts in 1-minute, 1-hour, or 1-day buckets, split into uncached input, cached input, cache creation, and output. Its cost endpoint, /v1/organizations/cost_report, returns USD as decimal strings in cents, in daily buckets only. Anthropic says data typically appears within 5 minutes of a request and supports polling once per minute.

OpenAI's admin Costs endpoint, GET /organization/costs, also supports only a 1d bucket width. Neither provider gives you billed dollars at an hourly grain, so a single dashboard needs two layers: a near-real-time estimate computed from token usage multiplied by current list prices, and a daily reconciliation that replaces the estimate with billed cost. Gaps between the two usually point to something the estimate missed, such as server tools, batch discounts, or a price change.

Anthropic's docs list one more trap for reconciliation: Priority Tier costs are not available in the cost endpoint, and code execution appears only in the cost endpoint, not in usage. A ledger built from one endpoint alone will drift from the invoice.

Where alerts and hard limits belong

Alerts and limits work at different layers. Provider-side spend limits, such as Anthropic's organization and workspace limits, are the last line of defense: they stop everything in their scope at once, which is right for a runaway loop and wrong for a single noisy feature. Alerts from the ledger catch trends a day later. Neither stops one service from overspending in the next ten minutes.

Enforcement at request time needs a layer that sees each call before it reaches the provider, which is a gateway or proxy that tracks spend per key, team, or customer and rejects calls past a budget. Engineering-led teams that already run a gateway for routing or failover can add budgets there. Teams that do not can start with the ledger and provider limits, then add a gateway once a specific feature or customer needs its own ceiling. FrugalAI combines the gateway budget and the multi-provider ledger in one place, but the layering applies whichever tools you use.

• Provider spend limits: a backstop that blocks a whole workspace or organization.
• Ledger alerts: daily trend and anomaly detection against billed cost.
• Gateway budgets: per-key, per-team, or per-customer limits enforced on each request.