u/ChemicalBig9254

I had a bunch of agents hitting the same OpenAI key, and the monthly bill was a single number — no way to see which agent/feature/run actually spent it. The usage dashboard only splits by key.

Most tools that fix this are gateways/proxies: your calls route through them so they can capture full prompt + response. 

I didn't want that extra latency and a failure point in front of the model, plus prompts leaving for a third party (dealbreaker if you're regulated). 

I'm an SRE, so "add a hop to the critical path" is a reflexive no.

So the design is: an SDK wraps your OpenAI client and calls OpenAI directly. 

It meters the call in-process and ships only metadata: token counts, cost, and an agent/run tag to a separate control-plane API. 

Prompt/response content never leaves your process.

(There is a gateway service, but it's for ingest + policy, not in the LLM request path.)

import OpenAI from "@spaturzu/sdk/openai";

// Swap one import — reads SPATURZU_API_KEY + OPENAI_API_KEY from env.
const openai = new OpenAI();

// Tag any call with the agent that made it — one line, no closure.await 
openai.withAgent("support-triage").chat.completions.create({ /* … */ });

On top of attribution there are three controls — the part I'd most like feedback on:

• Budgets. A USD limit scoped to the whole project or a single agent, over a daily or monthly period.
• Alerts. A background worker sums spend per period and fires at a % threshold to Slack, email, or a generic JSON webhook. (Email comes from our own sender; nothing to set up.) before a wrapped call hits OpenAI, the SDK checks current spend against the cap and, if breached, throws BudgetExceededError — the provider sees zero traffic. It's opt-in on both ends (an operator flags the budget as a hard cap; the dev passes { budget: { hardCap: true } }), and you pick onBreach: "throw" vs "warn". Spend state reaches the SDK via a server-sent-events push on breach, plus a ~60s poll backstop.

Honest caveat, since this sub will ask: because enforcement is client-side and eventually-consistent, it's a near-real-time guardrail, not a transactional ceiling a burst of concurrent calls right at the limit can slip slightly over before the breach propagates. The tradeoff buys you no proxy in the hot path. A gateway can block to the cent, but only by sitting in your request path.

Disclosure: I built this (spaturzu), solo. It's in beta with a free tier; the SDKs (Node + Python) are open source, MIT.

What I'm actually curious about:

1. If you run several agents on one key, how do you attribute + cap spend today: separate keys per workload, parsing the usage export, a gateway, or just eating it?
2. For hard limits specifically: is client-side enforcement (no proxy, small race window) good enough for you, or do you want a proxy that blocks to the cent and will accept the latency/content tradeoff to get it?

Disclosure up front: I build one of the tools I mention below (spaturzu). This isn't a launch post, I genuinely want to know how other people are solving this, because none of the options are clean.

We run a handful of LLM agents: a triage bot, a few summarisers, a couple of nightly batch jobs. They all hit the same OpenAI and Anthropic keys. 

At the end of the month we get one consolidated invoice per provider. The provider console shows a single number per key/project. Neither answers the only question finance actually asks: which agent, which team, which feature spent the money?

Tagging-after-the-fact doesn't work because the metadata (team, env, cost center, agent name) doesn't exist in the billing data at all, there's nothing to tag against. So you have to capture it at request time. We looked at three ways to do that:

1. AI gateway / proxy (OpenRouter, Cloudflare AI Gateway, LiteLLM, Helicone, etc.) You route every call through a proxy that records request-level telemetry. Great visibility, and you get routing/caching as a bonus. The catch for us: it's now in the request path (latency + a new failure point), and your prompts and responses pass through a third party; which our security team killed immediately for the regulated workloads.
2. Provider-native projects / tags (OpenAI projects, separate keys per workload) Zero new infra. But it's coarse, you end up minting keys per agent and it falls apart the moment one service runs several agents, and it's inconsistent across providers (Anthropic ≠ Bedrock ≠ Gemini). Good enough at 3 agents, not at 30.
3. In-process instrumentation (meter at the call site, in your own code) You wrap the SDK client so each call is metered locally. token counts + computed cost get sent to your cost backend, tagged with the agent/run, while the prompt itself goes straight to the provider with your own key. No proxy in the path, and the prompt/response text never leaves your servers (only the counts + cost do). Tradeoff: it's code you add to each service, and it only sees what your app sees (no infra-level catch-all).

We went with #3 — I ended up building it out as an open-source SDK called spaturzu (Node + Python, MIT) because the "prompts never leave our network" property was a hard requirement for us and the proxies couldn't offer it. Happy to link it if useful, but I'm honestly more interested in the question than the plug.

For those of you doing AI cost allocation today — which of these three did you land on, and how are you handling the multi-provider + per-agent granularity problem? Is anyone getting clean chargeback out of virtual tagging without instrumenting the call site?

I've spent years getting our cloud allocation to a place I'm proud of — tags enforced, showback by team and cost center, unit economics per customer, anomalies caught before they're a board conversation.

Then GenAI spend landed on my desk and every tool and habit I have just… stopped working. Wanted to sanity-check with people who actually do this for a living, because I can't tell if I'm missing something obvious or if the category genuinely isn't built yet.

Here's where it breaks for me:

1. There are no tags. An Anthropic/OpenAI invoice is essentially one number. There's no resource-level metadata like I get on EC2 or a managed DB. So the dimensions I actually need to allocate on — team, cost center, customer/tenant, feature, environment — aren't in the bill at all. I can't chargeback what I can't see.
2. Unit economics are basically unanswerable. "What does customer X cost us in AI?" or "is this feature gross-margin positive?" — questions I answer in my sleep for compute — I currently cannot answer. For an AI feature that's priced per-seat while it's billed per-token, that's terrifying.
3. Closed CLIs are a black box. We rolled out Claude Code / Cursor to the eng org. Leadership asked the obvious question — "what's that costing us per team, per dev?" — and the honest answer is we have no idea. The provider dashboard is one org-wide total.
4. Measured ≠ billed. Even when I meter calls myself, my number never matches the invoice — credits, enterprise discounts, mid-month price changes. Reconciliation is manual and I don't trust it.
5. Anomaly detection doesn't transfer. A token-spend spike looks nothing like an instance-hours spike. My existing thresholds are useless and a runaway agent loop can cost four figures overnight before anything fires.

What I've tried: native provider dashboards (too coarse), routing everything through a gateway and tagging at the call site (works but eng has to instrument every call, and half our spend is in closed tools I can't instrument), and the LLM-observability tools — but those are built for AI engineers debugging prompts, not for finance doing allocation. Wrong buyer, wrong primary number.

So, genuinely asking the people here:

• How are you allocating GenAI spend to teams/customers today? Tag-at-source, proxy, manual spreadsheet, or just… not yet?
• Anyone solved per-developer attribution on Claude Code / Cursor / Codex?
• How do you handle measured-vs-billed reconciliation for token spend?
• Is anyone's existing platform (Vantage / CloudZero / Cloudability / native) actually doing this well, or are you all duct-taping it like I am?

Full disclosure so nobody feels misled: I'm building something in this space, which is why I'm deep in this rabbit hole. I'm deliberately not naming or linking it — I'm not here to pitch, I'm here because I'd rather learn how seasoned FinOps folks are solving this than keep guessing. If you've cracked any piece of this (or you're stuck on the same thing and want to compare notes), comment or DM — happy to share what I've found in either direction.