Performance & history
Read provider attempts, completion outcomes, latency, and reported usage without treating estimates as earnings.
Open My computers and select an enrolled computer to review its current state and observed activity.
Time windows
Provider statistics support 7-day and 30-day views. History can be filtered by model and outcome, then paginated through older attempts.
Account totals and 24h amounts
Web My computers shows account-wide lifetime Points, Credits earned and Requests completed across your computers. These totals are separate from a selected computer's 7-day or 30-day operational history. Points are account rewards and are not attributed to an individual computer.
Desktop Router source also shows absolute amounts beneath those totals with a 24h label. The web provider cards do not render these 24h rows yet, and the landing walkthrough is a simulated example. Check the published Router-enabled Desktop version before relying on this UI; a source merge or development build is not an installer release.
| 24h amount | When activity enters the window |
|---|---|
| Points | First Router-confirmed grant delivery, which can be later than the availability that earned it. Pending grants are excluded. |
| Credits earned | First Router observation of a confirmed financial receipt. Eligible interrupted work can also earn credits. |
| Requests completed | Completion of an accepted customer attempt. Readiness checks are excluded. |
Credits earned are gross confirmed earnings, not a spendable balance or a net total after later compensation. Points remain separate from billing credits. The amounts use the rolling 24 hours ending at the server's as_of snapshot, rather than a calendar day or a percentage comparison. Historical activity without the required timestamp is not assigned a fabricated confirmation time.
Freshness and incomplete collection
The complete provider statistics response is cached for five minutes by default. Client polling does not force a fresh calculation. The optional last_24h contract includes window_started_at, as_of, fresh_until and collection coverage; the window remains anchored to that snapshot until refreshed.
Collection may not cover a full 24 hours yet, and reconciliation can still be pending. These are separate limits: a displayed amount reflects recorded activity and does not prove that all activity in the window was collected. Missing measurements are unavailable, rather than zero. A measured zero is valid.
In Desktop, Saved identifies retained values when refresh fails or the snapshot is past its freshness allowance; freshness and coverage notices still apply to the 24h amount. Read readiness and states for what earns Points.
Attempt outcomes
| Outcome | Meaning |
|---|---|
completed | The provider reported a normal terminal result and usage. |
provider_failed | The runtime reported an inference failure. |
caller_canceled | The developer connection ended before completion. |
interrupted | The assignment ended without a normal completion path. |
Measurements
History can include total duration, time to first output, prompt tokens, completion tokens, and a terminal error. Missing values mean the measurement was not reported; they do not mean zero.
Percentiles and averages describe observed attempts inside the selected window. They are useful for diagnosing changes, but they are not uptime guarantees or model-quality scores.
Usage is provider-reported
The provider runtime reports token counts after inference. Router validates protocol bounds and stores the observation. It cannot independently prove that the runtime’s token count is exact.
Diagnose a change
- Narrow the history to one model and time window.
- Compare completion rate and first-output timing before and after the change.
- Open failed attempts and group them by terminal error.
- Check whether missing usage increased separately from zero-token responses.
- Correlate the time with local Core Node logs and resource pressure.
Use provider troubleshooting for state-specific recovery.