# Measurements and quality

> What the platform measures about your endpoints, where you and customers see it, how capacity and task quality work, and how to earn more traffic.

Source: https://0.0.0.0:3000/docs/providers/measurements
Documentation index: https://0.0.0.0:3000/docs/llms.txt

Price decides whether your offer is in the running; measurements decide how much traffic it gets. The platform measures every request it sends you at the gateway and uses the same evidence for routing, for the catalogue customers browse and for your dashboard. Nothing your agent reports about itself can make you look faster or more reliable than the gateway observed.

Misrepresenting a model, its capabilities, its usage or its data handling leads to suspension and to withholding or reversal of earnings.

## What is measured

| Measurement | Definition |
| --- | --- |
| Time to first token | From dispatch to your source until the first output arrives at the gateway. Routing and queueing before dispatch aren't included. |
| Throughput | Output tokens per second between the first and the last output. |
| Outcome | Success or a failure category for every request. |
| Availability | Whether your endpoint and each model are connected and ready, as observed by the platform. |
| Capacity and queue | Your declared limits, current use and queue depth. |

Failures are recorded as categories and safe codes, never as upstream error messages, request content or credentials. Your error rate counts only failures attributable to you; failures caused by customers or by the platform aren't counted against you. A source that reports a context limit below your offer's approved context size counts against your reliability.

Signals are measured over recent traffic. Values without enough evidence are shown as unavailable, never as zero.

## Where you see it

| Place | What it shows |
| --- | --- |
| [Provider › Logs](/dashboard/provider/logs) | Searchable request history and lifecycle events. Summary charts show measured requests, their covered range and freshness; unsupported summaries are marked unavailable. **Alert rules** notify you when evidence crosses a threshold you set. |
| **Routing measurement history**, from your provider page | The windows routing used for your offers: sample and error counts, time to first token, throughput, queue and capacity, routing exclusions and quality category counts. |
| Model details in the provider overview | Current routing blockers and recent verification checks. |
| Terminal UI **Activity** | The same platform measurements, plus a separately labelled strip of this session's local counters. |

Local counters in the terminal UI and desktop app, such as requests in flight and tokens per minute, come from your own process. They're never used for routing, health or earnings.

## What customers see

The public catalogue and each model page list every endpoint that serves the model, with availability, error rate, time to first token, throughput and the task-quality rate, each with its sample count and freshness. Customers choose a window of 1 hour, 24 hours, 7 days or 30 days and can sort by price, speed, availability, error rate and quality. These are historical measurements, not a live status.

The [Compare providers](/dashboard/providers) directory lists a provider while at least one of its offers is live.

## How routing uses measurements

Routing considers eligible offers close to the lowest estimated price for the customer's currency and balances price, reliability and performance across them, with randomization to spread load. New offers receive some traffic so they can build a track record. Customers can override this with sorts, price ceilings, data-policy filters and explicit provider lists; see [Provider routing](/docs/routing/provider-routing).

An offer is considered only when it's approved, not paused or held, healthy and connected, verified (hosted offers excepted), within the customer's ceilings and has free capacity. Every condition is checked again immediately before dispatch.

If a model fails repeatedly, routing stops sending it traffic until it passes verification again; see [Recovery after repeated failures](/docs/providers/lifecycle#recovery-after-repeated-failures).

## Capacity

You declare capacity when you publish, and the platform enforces it before every request. Declared capacity is a ceiling: live reports from your agent can lower it but never raise it.

| Limit | Scope | Default |
| --- | --- | --- |
| Concurrent requests | Endpoint | The value shown in setup |
| Concurrent requests | Per model (optional) | None; the endpoint limit applies |

Input-token volume is measured for usage and diagnostics, without a platform
rolling token budget. Capacity admission checks endpoint and model concurrency.
Context length, per-request input limits, payload bounds, spending authorization
and abuse controls still apply. Upstream rate limits and overload responses may
cause bounded retries or eligible fallback before output begins.

Your agent counts a request as current use from the moment its connection attaches. An attachment that never receives a request, for example because the customer cancelled first, is released automatically shortly after its attachment window ends.

A connected endpoint can still fail to open the separate connection for a
request. Platform attachment failures don't count against your endpoint's
reliability or trigger a provider circuit penalty.

Set concurrency in setup with `--capacity` or `--model-capacity ID=N`, or edit
and publish model concurrency in the terminal UI or desktop app.

Publishing a capacity-only update reuses the model's technical pass. The new ceilings take effect when static validation, price review and the other activation gates pass. Live capacity reports can still lower available capacity. A change to the executable model or added capabilities requires review before full verification runs.

For capacity-only updates, approval also preserves still-valid readiness from
your connected workers, so serving can continue before their next report.
This does not extend readiness expiry or override a worker that is unavailable.

Cloud sources can't report the upstream's real headroom, so your declared limits apply until you change them.

Declare capacity you can sustain. Requests beyond it go to other providers before they reach you, while requests you accept and then fail count against your reliability.

## Task quality

Task quality answers one narrow question: did a response satisfy the objectively checkable parts of the request? It isn't a subjective ranking of the model.

The gateway checks each response as it's delivered, without storing content:

- **Tool calls**: required or forbidden calls happened, call IDs are unique, function names were declared, and arguments are valid JSON matching the supplied schema.
- **Structured output**: the JSON object or JSON schema mode was honored.
- **Every task**: the finish reason and declared output modality are consistent.

Each checked response is valid or invalid. Invalid responses carry a category, which you see in your routing measurement history: `invalid_json`, `unknown_tool_name`, `schema_mismatch`, `missing_required_call`, `unexpected_call`, `response_format_mismatch`, `finish_reason_mismatch` or `modality_mismatch`.

Responses that can't be checked objectively, such as free-form chat, aren't counted. A customer's own cancellations and `max_tokens` cut-offs don't count against you. The quality rate is valid ÷ (valid + invalid). Customers see only the rate, sample counts and freshness.

Quality affects routing only when a customer sorts by quality. Verification also includes objective quality checks for chat models, and failing one fails verification.

## Earning more traffic

- **Price competitively.** Offers close to the lowest estimated price share default traffic by quality of service. Far above it, you get traffic mostly from explicit sorts and when cheaper offers are full.
- **Be fast from the first token.** Keep models loaded, avoid cold starts, and tune batch settings for latency as well as throughput.
- **Fail rarely.** Keep your source healthy, your upstream balance funded and your credentials valid. Repeated failures pause the model.
- **Declare capacity and capabilities honestly.** Declare only what you can serve without queueing, and advertise tools, structured output, reasoning and modalities only when the exact model and server support them.
- **Stay connected.** A disconnected endpoint is offline and can't serve requests.
- **Offer both currencies.** Customers with BTC keys can only reach offers priced in BTC, and vice versa.

## Next steps

:::cards
- {badge} [Review and lifecycle](/docs/providers/lifecycle) Verification, recovery and every status label.
- {coins} [Pricing your models](/docs/providers/pricing) Prices, protection and the platform fee.
- {plug} [Inference sources](/docs/providers/sources) Server flags that affect tools, caching and speed.
- {terminal} [Terminal UI](/docs/providers/terminal-ui) The Activity screen and local counters.
:::

Log summaries report measured requests at receipt time. Counts are exact for
processed data; latency and throughput percentiles have up to 0.79% error.
Text searches and unsupported filters keep their matching records but cannot
produce summaries. Usage and earnings summaries are unavailable in Logs; open
[Earnings](/dashboard/provider/payouts) for the currency-separated earnings report.

Summaries over more than about 24 days chart one point per day, or per several
days for longer ranges. If a summary reaches
its processing limit, it may show only its completed whole hours and days, marked
as a partial range; if even those exceed the limit, it is unavailable. Narrow the
provider, endpoint or offer selection to see the rest. These resource filters
are applied before that limit. Other filters may still reach the limit within
the selected resource. Summaries keep completed results while updates are
processed; an incomplete update is never presented as a completed range. A
summary that is only behind on recent data is complete up to its update time.

## Execution timing diagnostics

For chat, the agent reports how long source work runs until final usage arrives
and how long it waits to send events to the gateway. Plaintext chat also reports
how long it waits for the first output; encrypted chat has no token first-output
measurement. Our team can use these diagnostics to investigate slow requests.
When your source reports queue, model-loading, prompt-processing or generation durations, the
agent includes those separately. Missing durations remain unavailable. These
measurements overlap and don't change your earnings, prices or routing health.
A source that doesn't expose its internal timings needs upstream support to
separate queueing from compute.