Test-phase registration for the local vLLM endpoint. Every value here is measured from the server over HTTP or read from the deployment's own launch arguments and model config; config/README.md records the evidence for each one. Latency, throughput and uptime are deliberately absent — they are live measurements, and a number frozen into a config file stops being true the moment the next request lands.
One provider serves this model, so every request routes to it. When a second one appears, this table becomes the comparison — price, context, quantization and uptime side by side — and the routing mode you pick decides between them.
| Provider· | Provider ID· | Endpoint tag· | Context· | Max Output· | Quant· | Input $/M▲ | Output $/M· | Cache Read· | Latency· | Throughput· | Uptime 30m· | Uptime 1d· | ZDR· | Discount· | Moderated· | Impl. cache· | Region· | Params· |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Local Test Provider | local-test-provider | local-test-provider | 131,072 | — | fp8 | $0.100 | $0.400 | $0.037 | — | — | — | 99.42% | Unknown | — | No | YES | — | 17 |
Provider identity, routing tag, per-endpoint pricing, context ceiling, max output, quantization, implicit caching, uptime, endpoint discount, moderation flag, region and zero-data-retention are read from the API.
Latency and throughput are blank here — the spec exposes them only to an authenticated caller, our capture was taken without a key, and nothing on this deployment has reported one yet. Nothing is generated to fill them.
Catalogue pricing next to what individual providers actually post. Every figure on this panel is read from the API. There is no modelled cache-hit rate and no blended “effective price” here, because the API exposes neither of the inputs one would need.
Throughput is how fast the model writes (tokens per second — higher is better). Latency is total round-trip time (lower is better). The API types both as a percentile block: 0 of 1 endpoint rows here carry a latency reading.
Latency and throughput are blank here — the spec exposes them only to an authenticated caller, our capture was taken without a key, and nothing on this deployment has reported one yet. Nothing is generated to fill them.
| Endpoint | Thr p50 | p75 | p90 | p99 | Lat p50 | p75 | p90 | p99 |
|---|---|---|---|---|---|---|---|---|
| Local Test Provider | — | — | — | — | — | — | — | — |
Percent of requests that succeeded, as reported by the snapshot. Consensus Protocol monitors every provider continuously and automatically retries on the next-best provider when one returns an error. These are the three windows the API returns; no other window is shown, and an absent reading renders as an em-dash rather than a zero.
Artificial Analysis indices, read from the model's own benchmarks block. Present on 0 of 1 models; each index is independently nullable and an absent one is left blank rather than scored. Rank percentile is taken among the models that carry that index.
Public apps that send the most traffic to this model. Good signal for what real production workloads look like.
Token volume and request traffic to this model over time.
Token volume, request counts and trend series are blank: no field for them exists in the API contract, and nothing has been metered through this gateway yet.
Drop-in code to call this model. The API is OpenAI-compatible — most SDKs work by just swapping the base URL. The only thing that changes between models is the model slug.
curl https://api.consensusprotocol.org/api/v1/chat/completions \ -H "Authorization: Bearer $CP_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "local-test-provider/dsv4s", "messages": [{ "role": "user", "content": "Hello" }] }'Test-phase registration for the local vLLM endpoint. Every value here is measured from the server over HTTP or read from the deployment's own launch arguments and model config; config/README.md records the evidence for each one. Latency, throughput and uptime are deliberately absent — they are live measurements, and a number frozen into a config file stops being true the moment the next request lands.