Claude API Cost Allocation Per Department Guide

If you're asking how to allocate Claude API costs per department, the short answer is: don't rely on a single shared API key and a monthly invoice. Issue a separate application key (or at minimum a distinct tag) per department, capture per-request usage metadata at the point of the call, and aggregate it into a cost report by key or tag on a regular cadence. The mechanics are simple, but most teams skip them until finance asks "why did our Claude bill triple last month" and nobody can answer which team, feature, or customer drove it.

This matters because Claude usage is metered by tokens, not seats, and token consumption varies wildly by use case. A support-ticket summarizer might use a few hundred tokens per call; a RAG-based research assistant might burn tens of thousands. Without per-department attribution, you're stuck splitting the bill evenly or by headcount, which almost never matches actual consumption and makes budget conversations with engineering, support, and marketing teams unproductive.

Why a single shared API key breaks cost allocation

Most teams start with one Anthropic API key shared across every internal project. That works fine for a prototype, but it has three structural problems once multiple departments are involved:

• No request-level ownership. The API has no idea whether a call came from the support bot or the internal analytics tool.
• No per-team rate limits. One department's traffic spike can throttle or degrade service for everyone else sharing the key.
• No clean audit trail. When a cost spike happens, you're grepping logs for timestamps instead of pulling a report filtered by department.

The fix is structural, not analytical: separate the identity of the caller from the model call itself, before you try to build any reporting on top of it.

Step 1: Give every department its own key

The cleanest approach is one API key per department (or per team, or per product surface — whatever unit finance wants to bill against). This is exactly what SubToAPI's key system is built for: you create an application key (sub_live_...) per department from the dashboard, each one inherits your underlying Claude access, and every request made with that key is automatically attributed to it. You get usage metadata — tokens in, tokens out, model used — back on every response without building a separate logging pipeline.

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY_SUPPORT" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4-5",
    "max_tokens": 1024,
    "messages": [{"role": "user", "content": "Summarize this ticket thread."}]
  }'

Swap $SUBTOAPI_KEY_SUPPORT for $SUBTOAPI_KEY_MARKETING or $SUBTOAPI_KEY_ENGINEERING and you have clean separation with zero extra code. See /docs/quickstart for how key creation works and /docs/messages for the full request/response shape.

Step 2: Capture usage metadata on every call

Every Claude response includes usage data — input tokens, output tokens, and the model that served the request. If you're calling the API directly, make sure your client code logs this on every call rather than discarding it:

const res = await fetch("https://api.subtoapi.app/v1/messages", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.SUBTOAPI_KEY_ENGINEERING}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    model: "claude-sonnet-4-5",
    max_tokens: 512,
    messages: [{ role: "user", content: prompt }]
  })
});

const data = await res.json();

logUsage({
  department: "engineering",
  model: data.model,
  inputTokens: data.usage.input_tokens,
  outputTokens: data.usage.output_tokens,
  timestamp: new Date().toISOString()
});

Write that logUsage payload to wherever your cost data already lives — a database table, a BigQuery dataset, a simple CSV export — rather than inventing a new analytics stack. The point is to make token usage a structured, queryable fact, tagged by department, from day one.

Step 3: Aggregate into a per-department cost report

Once usage is tagged, allocation is just arithmetic: multiply tokens by your per-token rate (or, if you're on a flat per-seat plan, use token share to allocate the flat cost proportionally). A basic monthly rollup looks like:

| Department | Input tokens | Output tokens | Requests | Est. cost share | |---|---|---|---|---| | Support | 2.1M | 480K | 14,200 | 38% | | Engineering | 1.4M | 390K | 3,100 | 26% | | Marketing | 900K | 210K | 5,600 | 18% | | Product | 700K | 180K | 2,900 | 18% |

This kind of table is what finance actually wants: not raw tokens, but a defensible percentage split they can apply to the invoice. If you're on SubToAPI's Team or Scale plan, each seat maps to a team member, and combining per-key usage metadata with your seat assignments gives you this breakdown without extra tooling — check /docs for the full metadata reference and /pricing for how seats map to usage.

Step 4: Set soft budgets per department

Attribution without limits just tells you who to blame after the fact. Pair department keys with a budget alert — even a simple cron job that sums token cost per key daily and pings Slack past a threshold works better than nothing. If one department's usage trend breaks pattern (a new feature launch, a runaway agent loop, a misconfigured retry), you want to know within a day, not at month-end reconciliation.

Step 5: Review and rebalance quarterly

Department usage shifts as products evolve — a feature that was experimental last quarter might be driving half your token spend this quarter. Revisit your allocation percentages every quarter rather than locking them in. If you're deciding between model tiers per department (e.g., cheaper models for support triage, stronger models for engineering code review), that choice itself becomes a lever for cost allocation, not just a performance one.

Getting started

If you're currently splitting one shared key across departments, the fastest fix is to provision separate keys and start logging usage metadata immediately — even before you've built a dashboard around it. You can create department-scoped keys in a few minutes at /signup, with a free trial to validate the setup against your real usage, and /docs/quickstart walks through the first request end to end.

questions

Do I need a separate Anthropic account per department to allocate costs? No. You can keep one underlying Claude access and issue separate application keys per department through a layer like SubToAPI, which gives each key its own usage metadata without needing multiple vendor accounts.

What's the simplest metric to split costs by if I don't want to build reporting? Request count by key, multiplied by an average cost-per-request estimate, is a reasonable starting approximation. Token-based allocation is more accurate but requires logging usage.input_tokens and usage.output_tokens from each response.

Should cost allocation be based on tokens or on team headcount? Tokens. Headcount-based splits consistently misallocate cost because token consumption depends on use case complexity, not team size — a two-person team running a RAG pipeline can outspend a ten-person team doing simple Q&A.