What Usage Analytics This Aggregator Actually Gives You: A Field-by-Field Tour

What this analytics tour covers

When you call multiple models through one API key, your dashboard becomes the source of truth for cost and consumption. This article walks through the analytics fields you can expect to see on the aggregator's dashboard, what each one means, and which metrics are typically not exposed. The goal is to help you read the numbers accurately and avoid common misinterpretations.

All examples are conceptual. Specific thresholds, limits, and model availability are set by the platform and may change.

Core usage counters

Most aggregator dashboards start with a few high-level counters. These are usually available at the account level and can be filtered by time range and sometimes by API key.

• Requests: the number of API calls made in the selected period. This is a count of successful calls unless the dashboard explicitly includes failed attempts. Check the label.
• Prompt tokens and completion tokens: token counts split by input and output. These are typically aggregated across all models.
• Total tokens: the sum of prompt and completion tokens. Useful for a quick volume check, but not sufficient for cost analysis because model prices differ.
• Errors: some dashboards show a separate error count. If present, treat it as a signal for retries or bad requests, not as billable usage.

If your dashboard does not show errors separately, you cannot distinguish successful from failed calls from the request count alone.

Token-level detail per model

Because different models have different token prices, the most useful breakdown is per model.

• Tokens by model: prompt and completion tokens for each model you called. This is the basis for any cost estimate.
• Requests by model: how many calls went to each model. Useful for routing decisions and for spotting unexpected model usage.
• Model mix over time: some dashboards let you chart token volume by model. If available, this shows whether usage is shifting toward more or less expensive models.

A common pitfall: comparing total tokens across models as if they were equivalent. They are not, because the official price per token differs. Always pair token counts with the model identifier before drawing cost conclusions.

Per-model spend and the ×1.3 multiplier

The dashboard's spend figures are typically derived from official model prices plus the platform's multiplier. On this aggregator, users pay official price × 1.3. That means:

• Per-model spend reflects tokens consumed multiplied by the model's official price, then multiplied by 1.3.
• Total spend is the sum across models for the selected period.
• Spend by day (if shown) helps you spot bursts or gradual changes in burn rate.

When you see a per-model spend number, verify whether it already includes the multiplier. If the dashboard shows "official cost" and "billed cost" separately, the billed cost is the one that affects your USDC balance.

Do not assume the multiplier is the only adjustment. Taxes, rounding, and minimum charges may apply depending on the platform's terms.

USDC burn and balance

The aggregator uses a prepaid USDC balance on Base. The analytics view typically includes:

• Current USDC balance: the amount available for API calls.
• USDC spent in the period: how much of your balance was consumed by usage.
• Top-ups: deposits you made in the period. These are not spend, but they affect the balance trajectory.

A useful practice is to reconcile: starting balance + top-ups − spend should equal the ending balance, within rounding. If it does not, look for fees or adjustments not shown in the summary.

Contributor rebates: ×1.1 and ×1.2

If you contribute keys or capacity to the platform, your dashboard may show a separate rebate or credit line. The model here is:

• Contributors are credited official price × 1.1 in USDC for standard contributions, or × 1.2 for premium contributions.
• These credits are typically visible as a distinct balance or transaction type, separate from your prepaid USDC.

What to check:

• Whether the rebate is calculated on official price or on billed price. The stated model uses official price, so the rebate should not include the ×1.3 user multiplier.
• Whether rebates are paid in the same USDC balance or tracked separately. Mixing them can make your burn rate harder to read.

The rebate does not change what you pay as a user. It is a separate flow for contributors.

What is typically not exposed

No aggregator dashboard shows everything. Based on common patterns, expect some of the following to be missing or only partially available:

• Real-time per-token latency and time-to-first-token: latency analytics are often absent or limited to coarse aggregates.
• Per-request logs with full payloads: many dashboards show counts and tokens but not the request or response bodies, for privacy and storage reasons.
• Provider-side rate-limit headers: the dashboard may not surface upstream rate-limit information, so you cannot rely on it to tune concurrency.
• Cost attribution by end user or team: unless the platform supports tags or sub-accounts, you may only see account-level totals.
• Historical data beyond a retention window: check how far back the charts go. Older data may be aggregated or deleted.
• Failed-request token accounting: whether failed calls consume tokens (and are billed) depends on the provider and is often not broken out.

If a metric is critical to your workflow, verify it directly via the API response headers or your own logging rather than assuming the dashboard exposes it.

Practical reading checklist

Use this checklist when reviewing your analytics:

• Confirm the time range and time zone of the dashboard.
• Check whether request counts include errors.
• Compare per-model token counts with per-model spend to validate the ×1.3 multiplier.
• Reconcile USDC balance changes with top-ups and spend.
• If you are a contributor, confirm rebates are calculated on official price and tracked separately.
• Note any metrics you need that are not shown, and capture them in your own logs.

Summary

The dashboard gives you request counts, token splits, per-model spend (with the ×1.3 multiplier), and USDC balance and burn. Contributor rebates at ×1.1 or ×1.2 appear as a separate credit flow. Metrics like latency, per-request payloads, and upstream rate limits are commonly not exposed. Read the labels carefully, reconcile balances, and supplement the dashboard with your own logging where precision matters.