Home›Become a Host›Scorecard
The scorecard is not a black box. It is computed from four components over a 30-day window, its weights are exactly as written here, and it drives the placement order directly. A high score means more work at the same price — not a marketing sentence, but an input to the scheduler.
The scorecard model was defined in Phase 0; measurement for community hosts starts with the agent in Phase 1. There is no live host scorecard today.
Host section
Four metrics
The score is computed out of 5. Each of the four components is normalized to a 0–1 range within itself, multiplied by its weight and summed. If we change the formula or the weights, we write it in the changelog.
Heartbeat coverage over the last 30 days. Power and network outages, unplanned restarts and a crashed agent are all written here. This is the heaviest component, because the customer's most expensive problem is a job left stranded.
The variance of throughput across regularly scheduled tests. What is measured is not speed but predictability: a card that is sometimes fast and sometimes slow scores worse than one that runs steadily at medium speed.
How many of the jobs routed to you that you accepted. Repeatedly declined offers break placement and keep the customer waiting. A declared maintenance window is not counted here — when you say up front that you are closed, no job is routed to you.
The median of measured download and upload bandwidth, normalized against an upper bound. It counts because model and dataset transfer shape the customer's first experience; going beyond the bound earns no extra points.
| Component | Weight | Window | How it is measured |
|---|---|---|---|
| Uptime | 35% | 30 days, rolling | Agent heartbeat coverage; scheduled maintenance windows excluded |
| Benchmark consistency | 30% | 30 days, rolling | Throughput and variance of a regularly scheduled reference job |
| Job acceptance rate | 20% | 30 days, rolling | Number of jobs routed / accepted |
| Network | 15% | 30 days, rolling | Median of measured download + upload, normalized to an upper bound |
A new machine does not start with a low score but in an "insufficient data" state: for the first 72 hours it warms up on a limited job flow, and the score settles as measurements accumulate. That warm-up period is not a penalty, it is data collection.
Placement
The scheduler picks the most suitable row, not the cheapest one. Scoring weighs price, scorecard and latency/network fit together; if the customer wants to, they can shift the weighting on their side (cheapest, fastest, Verified only, and so on).
VRAM, card count, disk, region constraint and operating system class are checked. A long training job rules out machines on the WSL2 profile from the start; that is a question of fit, not of score.
The remaining candidates are reduced to a single score. A machine with a high scorecard can come out ahead even if it is slightly more expensive — because the cost of a job that fails is larger than the price difference.
When scores are close, priority goes to the machine in the same region, with the image already in its cache, and that has taken less work in the last 24 hours. The last item exists to stop supply piling up on a single host.
As the score falls you drop out of long and critical jobs first, then out of the general pool. Below a certain threshold the machine stays listed but is only routed short, interruptible jobs. Delisting is the last step and appears in the panel as a warning beforehand.
Raising the score
The score is not something to guess at: the panel shows the 30-day trend of every component and which event lowered the score. The items below are the interventions that make the biggest difference.
Transparency
Every machine's score and its four components appear in the marketplace listing and in the API. A customer can filter by "above this score only". You cannot hide your score; a machine that works well wants to show it anyway.
If we intervene by hand in an incident — for example, offsetting an outage caused by us — the computed score is not deleted. Two values sit side by side in the panel: the measured score and the adjusted score. The reason for the intervention and its date go on the record.
If you believe an outage was not yours, you report the incident from the panel. We review it; if you are right we make the correction and leave it visible as described above. We do not quietly add points.
If the formula and the weights change, it is announced in advance and written in the changelog. If a retroactive recomputation is done, that is written too.
The scorecard model is defined but is not yet collecting data for community hosts: the agent ships in Phase 1. Today the supply in the marketplace comes from integrated providers and is scored by our own benchmark bot. Last updated: 29 August 2026
Next step
A high score means more work in the general pool. Enterprise workloads come through a separate door: the Verified tier, with an on-site audit and an SLA commitment. It opens in Phase 3, and its criteria are already written down.
; scores and measurements are illustrative.