Console and chat
Chat in the console
Talk to a served model from the browser, read the verification badge, inspect the attestation, and know where the conversation is kept.
How-toFor users
Chat sends your messages over the same POST /v1/chat/completions path every API client uses, with a real workspace key, through the same metering and billing. There is no console-only inference route.
Send a message
- Open Chat and pick a model under Choose a model. Built-in and external models sit side by side.
- Wait for the badge next to the composer. The composer reads Locked until this endpoint's evidence checks out until the page has verified the endpoint.
- Type under Ask the model something… and click Send.
A model disappearing from the picker mid-session means its endpoint lost its verdict; the router fails closed.
The badge
The badge is the chat's one claim about verification, and the sentence behind it carries that claim's limit. Click it for the caveat, then What has been verified? for the full report.
| Badge | What happened |
|---|---|
| Checking this endpoint | Fetching the endpoint's signed evidence and checking it in your browser |
| Verified by this page | This page checked the evidence itself. The page came from the same deployment, so this is self-reported, and it does not include the check that decides whether Super Protocol vouches for the VM. Gatekeeper makes that one, and can refuse an endpoint this page unlocked |
| Evidence did not check out | A check this page can make failed; the composer stays locked |
| Independently verified by the extension | The Super Protocol browser extension verified the endpoint with code this deployment did not serve |
| The extension refused this endpoint | Trust its answer over the page's |
| No extension detected | Not a failure; the extension is optional |
The report lists the page's checks by name: Web Crypto available, signed evidence retrieved, certificate chain, evidence signature, freshness, TLS certificate binding, root vouched for by Super Protocol. The last row can read not established on the live platform; that is neither a pass nor a failure, and it is the check Gatekeeper enforces. The report's third section, 3 — Gatekeeper, on your machine, prints the same four setup commands as Connect Gatekeeper with the digest this page just read substituted in, so you can pin exactly what the page saw. Why the three differ: Attestation and the evidence chain.
Inspect the attestation
Inspect attestation opens the deployment's evidence: measurements, the deployment graph drawn from the signed snapshot, the images by digest, and the raw fields. For a model served by an external endpoint the button reads Inspect upstream attestation and shows the upstream's own publication, relayed by this router. The badge above is about this router; the upstream is checked here.
Where the conversation is kept
The line under the composer says which of two modes the deployment runs, and the ⓘ beside it opens the rest.
- Stored inside the attested boundary: threads are stored on the deployment's own state, inside the enclave and encrypted at rest. A deleted thread is deleted outright. Conversations may be lost during infrastructure maintenance.
- This conversation is stored in this browser only: threads live in this browser's local storage and are never sent to the router. Clearing site data, or opening the console in another browser, loses the history.
In both modes the messages themselves travel to the model over /v1/chat/completions, which records tokens and cost and no content at all. Production runs the first mode.
New conversation starts a thread; the bin beside a thread deletes it.