Usage, costs, and quotas

Gateway usage records provide an operational view of requests, tokens, providers, models, and estimated cost. They support monitoring and budget decisions, but they are not a billing ledger and do not establish fixed public quotas.

Pricing, quotas, plan allowances, and public rate limits are not verified in the supplied sources.

Usage analysis is strongest when aggregate trends can be traced back to individual requests. Project, model, and provider groupings reveal where consumption is concentrated; request and trace IDs explain a specific spike, fallback, or unexpected estimate. Keep the terms precise: usage is observed activity, estimated cost is a calculation, a budget is an enforcement boundary, and quotas or rate limits are separate controls that are not verified here. That precision prevents implementation defaults from being presented as commercial plan terms.

Usage model

The usage service records request count, input tokens, output tokens, and estimated cost together with project, model, provider, route, and trace dimensions. Summaries can be grouped by project, model, and provider. These records support operational analysis of the inspected Gateway path; they are not a complete billing ledger.

Missing token or cost values normalize to zero in summaries. Zero therefore means the event did not contribute a reported value, not necessarily that the provider performed no work or charged nothing.

A usage event can carry project, model, provider, route, trace, request count, input tokens, output tokens, and estimated cost.

Summaries can group data by project, model, and provider.

Missing token or cost fields normalize to zero in current aggregation, which means zero can represent unavailable telemetry.

Usage records capture the measurable work associated with Gateway requests: request count, input tokens, output tokens, and estimated cost, with project, model, provider, route, and trace context.

The chat handler performs a project budget check before provider execution.

Usage summaries can group events by project, model, and provider. No fixed public quota, RPM, TPM, rate limit, or plan allowance is verified. A configured budget can block a request, but it is not itself a quota, price, or subscription entitlement.

Missing token or cost values normalize to zero during summary calculations. Missing cost or token values should remain unavailable data instead of being rewritten as zero consumption.

Cost attribution

A failed attempt may contribute latency or provider consumption even when the final response comes from another route. Cost analysis should therefore preserve attempt order and fallback state instead of assigning all activity to the final provider.

Fallback and retry can increase attempts without increasing the successful response count. Cost review should therefore compare usage events with attempt history where available. A single successful response may still have consumed time or provider resources on earlier failed attempts.

Estimated cost should be read alongside the selected provider, model alias, token counts, attempts, and fallback state. A request that falls back may have more than one provider attempt, while the final response identifies only the selected route. The current fields are useful for estimates and comparisons but should not be reconciled as a provider invoice without an authoritative billing source.

Avoid freezing current model prices into evergreen documentation. Pricing can change independently of the request schema and may differ by provider account or route.

Estimated cost is associated with the executed route and provider context recorded for the request.

Fallbacks can change the provider and therefore the operational estimate.

Do not present an estimate as an invoice, settled provider charge, or guaranteed future price.

Cost attribution is an estimate derived from available usage data. It can support comparison and budget monitoring, but it is not a provider invoice, settlement record, or guarantee that every surcharge and discount is represented.

Summary calculations normalize missing token or cost values to zero. Analysts should inspect the underlying event before interpreting that normalized value as zero consumption.

The default event-query limit of 200 is an implementation default, not a retention or billing guarantee. Aggregate usage is most useful when it can be traced back to the request, model, provider, route, and project that produced it.

No fixed public quota, RPM, TPM, rate limit, or plan allowance is verified by the supplied sources. Usage records aggregate request count, input tokens, output tokens, and estimated cost.

Quotas

A provider may return its own capacity error independently of the project budget check. Diagnose that response as provider behavior rather than evidence of an Ethen plan quota.

The supplied implementation verifies a project budget check in the chat handler. It does not define a public quota plan, included request allowance, or universal requests-per-minute value. Budget, quota, and rate limit are separate concepts: a budget constrains estimated spend, a quota constrains allowed consumption, and a rate limit constrains request or token throughput over time.

Do not translate type fields mentioning RPM or TPM into published product limits without implementation and product evidence. Keep the limits review flag until authoritative values are available.

The chat handler performs project budget checks before provider execution.

No stable public request quota, token allowance, or plan table is established by the implementation.

A budget block is distinct from provider rate limiting or a catalog readiness failure.

The inspected chat route enforces a project budget check. A budget is a spend-control boundary; it should not be described as a request quota, token allowance, rate limit, or subscription entitlement.

Summaries can group events by project, model, and provider.

Limits

Treat model context limits and provider throughput as dynamic inputs. A limit reported by the current catalog or provider response can guide one request, but it should not be copied into an evergreen plan promise.

The usage query has an implementation default of 200 events when no limit is supplied, and logs have a different default. Those values are retrieval defaults, not retention guarantees or plan limits. They should not be presented as the maximum number of stored records.

Similarly, the chat route recognizes max_tokens and max_completion_tokens, but the source bundle does not define universal maximum values across models. Model and provider constraints remain dynamic.

Event-query limits control how many records a read returns; they are not retention rules or customer entitlements.

Model context and provider rate limits can vary dynamically and are not defined by this batch.

Document only a limit that appears in the current response, error, or approved policy.

Fixed limits are not verified. RPM and TPM appear in settings types, but a type alone does not establish enabled enforcement, current values, or a public plan matrix.

For the initial test, compare usage by project, model, and provider, then investigate unexpected changes through trace-linked request logs before changing a budget.

A configured budget can block a request, but it is not automatically a quota, rate limit, price, or plan allowance.

Settings types that mention RPM or TPM are not enough to publish a fixed limit. Until an enforced public contract is verified, clients should handle explicit budget or provider errors rather than coding against guessed allowances. Capacity planning can use observed request and token summaries, but it should label those observations as historical usage.

Monitoring

A useful monitoring view combines volume, token counts, estimated cost, model, provider, route, latency, fallback state, and error code. Aggregates identify a trend; request and trace identifiers locate the individual events behind it. When a value is missing and aggregation normalizes it to zero, inspect the underlying event before concluding that no tokens or cost were incurred.

Budget failures should be reviewed alongside estimated usage, but the budget decision occurs before the next provider execution. If the application receives budget_exceeded, adding fallback providers or retrying immediately cannot change the project budget state. Resolve the budget condition through the verified administrative path before resubmitting.

Monitor request count, input and output tokens, estimated cost, model, provider, fallback, error code, and latency together. A cost increase can result from more traffic, longer prompts, longer outputs, provider changes, retries, or fallbacks. Grouping by project, model, and provider helps separate those causes.

Use trace-level records when aggregate totals change unexpectedly. The usage summary shows the trend; request logs and attempts explain individual outliers.

Review request count, input and output tokens, estimated cost, model, provider, and fallback patterns together.

Correlate unexpected spikes with request and trace IDs in logs.

Separate missing telemetry from genuine zero usage before drawing conclusions, and keep secrets out of monitoring exports.

Monitor trends by project, model, and provider, then use trace identifiers to explain outliers. Missing token or cost values normalize to zero in summaries, so zero must be interpreted alongside the underlying event.

Use the four measured values for different questions. Request count shows volume; input and output tokens show consumption; estimated cost applies the available pricing data to that usage. Grouping by project identifies organizational demand, grouping by model shows workload choice, and grouping by provider can reveal routing changes. None of these summaries is a provider invoice, and a missing estimate should remain unavailable rather than being converted to zero.

Budget enforcement is a request gate in the inspected chat route. It is not the same as a published quota or rate limit. The source pack does not verify fixed requests-per-minute, tokens-per-minute, plan allowances, or storage limits, even though settings types may mention related concepts. When usage rises unexpectedly, correlate the project, model, provider, route, and trace fields with request logs before changing a budget; a fallback to another provider can change estimated cost without any change to the client’s requested model.

Optimization

Compare one change at a time against the same workload and quality requirement. A lower estimate is not an improvement if it introduces repeated fallback, unacceptable latency, or output that no longer meets the task.

Optimize only after identifying the dominant driver. Reduce unnecessary input when prompts are growing, constrain completion length when outputs dominate, evaluate a different eligible model when quality requirements allow, or adjust routing when repeated fallback increases latency and attempts. These are operational choices, not universal recommendations.

Retest after each change and compare the same dimensions. An apparent cost reduction that also changes model, provider, output length, and traffic volume cannot be attributed to one control.

Route simpler workloads to an eligible model that meets the task rather than selecting solely by brand or maximum capability.

Control retries and fallbacks because additional attempts affect latency and estimated cost.

Use project budgets as a guardrail while keeping application-level monitoring for workload-specific thresholds.

Optimization should compare quality requirements with observed tokens, latency, provider choice, and fallback frequency. Avoid hardcoding dynamic prices or treating the cheapest estimate as a universal model recommendation.

Estimated cost is not an invoice, missing values normalize to zero in summaries, and implementation query limits are not quotas, retention periods, or plan allowances.