Per-Key or Per-Account? Where a Volume Discount Would Be Counted

Why the accounting boundary matters

When you call models through an LLM API aggregator, every request is authenticated by an API key. But if you use many keys — for different projects, environments, or rotation — the question arises: which entity's volume counts for a potential volume discount? The answer depends on where the platform draws the accounting boundary.

If the boundary is per-key, each key accumulates its own usage. A discount might only apply to the key that crosses a threshold. If the boundary is per-account, all keys under the same account contribute to a shared volume pool.

Per-key accounting

With per-key accounting, each API key is treated as an independent unit. Usage is tracked and billed separately for every key.

Implications for discounts:

• A discount would apply only to a key that individually exceeds a volume threshold.
• Rotating keys resets the volume for each new key, preventing accumulation.
• Multiple applications using different keys each start from zero.

When per-key makes sense:

• When you need strict isolation between projects or teams.
• When you want to attribute costs directly to a specific application.
• When the platform's design naturally ties usage to the key.

Per-account accounting

With per-account accounting, all keys under one account contribute to a single usage total. The account is the billing entity.

Implications for discounts:

• Volume from all keys adds up, so you can qualify for a discount sooner.
• Rotating keys does not affect the accumulated volume.
• Multiple applications share the same discount tier.

When per-account makes sense:

• When you operate several apps or microservices and want a unified view.
• When you rotate keys for security but want usage to count together.
• When you need a single billing relationship.

How rotation and multiple apps affect accumulation

Key rotation is a common practice to limit exposure if a key is compromised. If the platform counts per-key, rotation fragments your volume: each key starts fresh. If it counts per-account, rotation is transparent to the discount calculation.

Similarly, if you run multiple applications — each with its own key — the same fragmentation occurs under per-key accounting. Under per-account accounting, all applications feed into one pool.

Current model on this platform

On this platform, users pay official price × 1.3 for all usage, regardless of volume. There is no volume discount at this time. Keys are tied to an account, and all usage is billed to that account. So the question of per-key vs per-account discount is hypothetical. However, understanding the accounting boundary is still useful if you are designing your own key management.

Practical strategies

Even without a volume discount, you can manage keys and usage effectively:

• Use separate keys for separate projects to track usage and revoke access independently. The platform's dashboard shows usage per key, so you can monitor each application.
• Rotate keys periodically for security. Since billing is per-account, rotation does not affect your costs or payment method.
• Consolidate when possible if you want a single view of usage. But keep in mind that separate keys can help with debugging and access control.

How to decide

If you are evaluating a platform for volume discounts, ask:

• Is the discount calculated per key or per account?
• Do rotated keys reset the volume?
• Can multiple keys contribute to the same volume pool?

On this platform, the answer is account-level billing, but no volume discount. Your costs are predictable: official price × 1.3. If you contribute keys to the pool, you are credited official price × 1.1 (premium × 1.2) in USDC — separate from any discount discussion.