OpenAI API Key Cost Attribution Is Now Programmable: What Every Routing Operator Must Change

OpenAI's August 4 changelog entry is easy to miss: customers can now filter and group Usage and Costs data by API key in the platform dashboard, and the same api_key dimension is available programmatically in the Usage API and Costs API.

For teams that route AI traffic through a single OpenAI organization but use multiple API keys — one per environment, one per downstream model fallback path, one per customer workspace — this changes how you build cost accountability. The breakdown that previously required creating separate organizations is now a query parameter.

What actually changed on August 4

Two endpoints gained an api_key grouping dimension:

• Usage API (/v1/organization/usage): supports group_by=api_key across completions, tokens, and request counts.
• Costs API (/v1/organization/costs): supports group_by=api_key for aggregated spend in USD.

The dashboard at platform.openai.com/settings/organization/usage exposes the same breakdown as a filter — select a specific key to isolate its contribution.

No migration is required. Teams already using these APIs get the new dimension without any request shape changes. If you're on the /v1/organization/usage endpoint today, add &group_by=api_key to your existing query.

Why this matters for AI gateway operators

A routing gateway typically runs under one OpenAI organization but issues different API keys for different purposes. Common patterns:

• Environment isolation: separate keys for production, staging, development. You want to know that production consumed 92% of your monthly bill before you receive the invoice.
• Per-customer billing: SaaS teams that front-load OpenAI costs into customer accounts. Without key attribution, reconciling which tenant drove which spend required request-level logging with external aggregation.
• Model fallback paths: a primary key for GPT-5.6 Sol, a secondary key used when the router falls back to GPT-5.6 Luna. Knowing how often fallbacks fire, and how much they cost, is a routing policy input.

Before August 4, the only way to get this isolation at the API level was to create separate OpenAI organizations — each with its own billing, rate limits, and management overhead. The practical result was that most routing teams ignored per-key attribution and did their own log aggregation downstream.

The cross-provider gap this closes

API key attribution within a single organization is not universal:

• Anthropic: does not offer per-key cost breakdown. To isolate costs by key, you must create separate Anthropic workspaces, each with independent billing and rate limits.
• Google Vertex AI: uses projects, not API keys, as the cost isolation unit. Per-key attribution is not exposed; per-project attribution is the finest granularity.
• Azure OpenAI / AI Foundry: uses deployments and resource groups as cost units. API key attribution within a resource group is not directly available in the billing API.

OpenAI is now the only major provider where a single organization can have fine-grained, per-key cost attribution via a programmable API. This changes the recommended key architecture for multi-tenant routing designs: there is no longer a compelling reason to split production traffic across multiple organizations purely for cost visibility.

The routing policy change: what to audit now

1. Key architecture review

If your gateway was structured around multiple OpenAI organizations for billing isolation, evaluate whether a single-org multi-key design now achieves the same goal. Consolidation reduces rate-limit headroom fragmentation (rate limits are per-org) and simplifies credential management.

2. Per-key spend alerts

The Costs API with group_by=api_key enables per-key hard spend limits when combined with OpenAI's spend limits feature (released July 22). Set a monthly cap per routing key so that a misbehaving agent or unexpected traffic spike triggers a 429 rather than an unbounded bill.

# Example: fetch per-key costs for the last 30 days
import httpx

r = httpx.get(
    "https://api.openai.com/v1/organization/costs",
    params={
        "start_time": "2026-07-07T00:00:00Z",
        "end_time": "2026-08-07T00:00:00Z",
        "group_by": "api_key",
    },
    headers={"Authorization": f"Bearer {admin_key}"},
)
for bucket in r.json()["data"]:
    print(bucket["api_key_id"], bucket["amount"]["value"])

Note: the Admin API key (not a project key) is required for organization-level cost queries.

3. Fallback cost visibility

If your router uses a secondary API key for fallback models, the group_by=api_key breakdown now tells you: how often fallbacks fired this month, and what they cost. This is a direct input to the fallback-threshold policy — if fallback costs exceed a threshold, tighten the primary-model retry budget or switch to a cheaper fallback.

4. Billing reconciliation cadence

With per-key costs available programmatically, you can automate monthly customer billing reconciliation instead of relying on the platform dashboard. Pull the Costs API on the first of each month, group by the customer-facing key, and feed the result directly into your billing system.

What TheRouter users should watch

TheRouter routes requests through provider-specific API keys. The OpenAI per-key cost breakdown means you can now cross-reference TheRouter's routing logs (which path fired, which model, which fallback) with per-key spend from the Costs API to get a complete cost-per-routing-path view without external log aggregation. Configure your OpenAI keys in TheRouter such that primary and fallback paths use distinct keys — the new API does the cost attribution automatically.