Costing One Feature, Not One Call: Assigning LLM Spend to the Button That Triggered It

Why per-call cost accounting falls short

Most teams start by tracking LLM costs as a list of API calls: tokens in, tokens out, price per model. That view answers "how much did we spend?" but not "which part of the product spent it?" A single user-visible feature—like a summary button, a chat reply, or a document classifier—can trigger multiple calls, retries, or model fallbacks. Without attributing those calls back to the feature, you cannot tell whether a feature is cheap to run or quietly expensive.

From calls to features: the attribution idea

Feature-level costing means every LLM call is labeled with the feature (and often the user action) that caused it. Instead of summing by model or by day, you sum by feature. The goal is a cost per feature that you can compare against the value that feature delivers.

Key principles:

• Tag at the source. Whenever your code calls an LLM, attach a stable feature identifier.
• Carry the tag through. If one feature makes several calls, all of them should share the same tag.
• Aggregate by feature. Roll up token usage and cost by that tag over a chosen period.
• Separate one-off from ongoing. Prototype calls and production calls should not blur together.

Implementing feature tags

How you attach tags depends on your stack, but the pattern is similar:

• Application-level tagging. In your LLM client wrapper, require a feature argument and include it in every request. This is the most reliable method because it lives in your code, not in the provider.
• Provider metadata. Some APIs accept metadata or user fields that you can repurpose for a feature tag. Use this as a backup or for reconciliation.
• Log correlation. If the provider does not support tags, log the request ID alongside your feature tag in your own logs, then join the two datasets later.

A simple rule: if a call cannot be traced to a feature, treat it as untagged and fix the gap.

Rolling up cost per feature

Once calls are tagged, you need to turn raw usage into a feature-level cost. The formula is straightforward:

1. Collect usage records: timestamp, feature tag, model, input tokens, output tokens, and any provider-specific pricing details.
2. Apply the price you actually pay. If you use an aggregator, that price may be the official model price multiplied by a fixed factor. For example, on this site users pay official price ×1.3, so your cost per call uses that effective rate.
3. Sum by feature tag over a time window (daily, weekly, per release).
4. Optionally, divide by the number of times the feature was used to get a cost per invocation.

This rollup gives you a feature-level cost that can be tracked over time and compared across features.

Turning rollups into unit economics

Feature cost becomes actionable when paired with usage. For each feature, you can compute:

• Cost per active user. Total feature cost divided by the number of users who used it.
• Cost per successful outcome. If the feature has a success metric (e.g., a summary that was accepted), divide by that count.
• Cost as a share of revenue. If the feature supports a paid plan, compare its cost to the revenue it helps generate.

These numbers help you decide where to optimize, where to set limits, and which features to promote.

A concrete cost layer: aggregator pricing

When you use an LLM API aggregator, the pricing model itself can simplify feature costing. On this site, you top up with USDC on Base (no KYC) and call many models with one API key. You pay official price ×1.3. If you contribute keys, you are credited official price ×1.1 (or ×1.2 for premium) in USDC. Because the multiplier is fixed and transparent, your feature-level cost calculation is just:

feature_cost = sum over calls in feature (official_cost_of_call * 1.3)

No hidden tiers or per-model surprises. You can tag requests, roll them up by feature, and know that the effective rate is consistent. This makes it easier to forecast and to explain feature costs to stakeholders.

Practical steps to get started

1. Define a feature taxonomy. List the user-facing features that trigger LLM calls. Keep it short and stable.
2. Instrument your client. Wrap your LLM calls so that a feature tag is mandatory. Reject calls without a tag in development.
3. Store usage with tags. Log every call with its tag, model, token counts, and timestamp. If you use an aggregator, you can export or query usage and join it with your tags.
4. Build a simple dashboard. Show cost per feature over time, and cost per invocation. Start with a spreadsheet if needed.
5. Review regularly. Use the numbers to spot features that are more expensive than expected, and investigate retries, model choices, or prompt sizes.

Common pitfalls

• Tagging only at the UI layer. If the feature tag is added after the call is made, you may lose it in asynchronous flows. Tag before the call.
• Ignoring retries and fallbacks. A single user action can cause multiple calls. Make sure all of them inherit the same feature tag.
• Mixing environments. Development and production usage should be tagged separately so that experiments do not distort production feature costs.
• Forgetting non-LLM costs. Feature cost may also include embedding, storage, or compute. LLM cost is often the largest variable, but note the others.

Conclusion

Costing one feature, not one call, gives you a clearer picture of where your LLM spend goes. By tagging calls with feature identifiers, rolling up usage at the effective rate you pay, and reviewing unit economics, you can make informed product decisions. With a transparent aggregator like this one—USDC top-ups, one API key, and a fixed multiplier—the cost layer is predictable, so your feature-level analysis stays simple and accurate.