Vega 0.8B: typed decisions
A frozen Qwen3.5-0.8B read by a trained physics engine. You give it a state and questions whose answer types are fixed in advance; it returns values your code can use: a choice, a 0–1 score, or a probability that a statement is true, each with a calibrated probability, a conformal set and an abstain flag. Several questions about one state cost one read.
73,728-token context · images · no text generated anywhere in the path. Every tab below is prefilled. Press Ask, then change the inputs.
On generalisation: the engine answers any state zero-shot, and the benchmark figures quoted here are measured that way. A TTT head is different: it is fitted on a handful of labelled examples and only knows the boundary they drew, so it can be sharp on cases like its examples and wrong just outside them. The phishing tab runs both readouts side by side so that gap is visible rather than hidden.
First call downloads the backbone and warms up, so it is slow once. After that: ~0.27 s per decision on a GPU.
Route, judge urgency and score frustration in one call: three questions, one read of the message.
Every row appears twice: engine + adapter (zero-shot, what the benchmarks measure) and a TTT head fitted here on 20 labelled messages. Rewrite the message (a calm billing question, a security report, something off-topic) and watch where they part company.
answers
The benchmark win: 2.5× the phishing caught versus a hosted reference (252/400 vs 99/400).
Two questions on every email, both readouts on both: the yes/no phishing judgment that the benchmark measures, and a three-way kind (phishing, spam or legitimate), so the answer says what the mail is, not only what it is not. Each row shows the highest-probability class and its probability; the raw panel has the full distribution.
Edit the body. Prize and advance-fee bait reads like spam but asks for account details, so it is phishing; a 70%-off blast asks for nothing, so it is spam. That line is what the 32 labelled examples are drawn around.
answers
A real 254-section returns policy plus an order, two questions, one read of the document. The clauses that decide the answer are in the final section, so at every length the governing text sits at the far end of the read.
Pick 71k tokens to exercise the long window; the TTT head is fitted at 3.5k and is shown only there, because a head fitted on 3.5k-token reads cannot honestly be applied to a 71k-token one. The head saw 14 labelled requests, including late-but-faulty and opened-but-fine cases.
answers
The frozen backbone's vision encoder, same typed interface, same typed answers.
Engine + adapter only here. Fitting a TTT head would need labelled example images and there are none, so this tab shows the zero-shot path alone: the one that works on an input nobody prepared for.
answers
Which device answered, read from inside the GPU worker rather than assumed.
answers
Long-read probe. A bare forward pass of N tokens through the backbone, no engine and no pooling. The policy tab answers at 15k tokens but a 24k read dies inside the worker with cudaErrorNoDevice while 44 GB sits free; this separates sequence length from the typed-decision path.
answers
Any state, any typed questions. State may be JSON or plain text.
Leave the examples box empty for the engine alone. Fill it in with one JSON object per line, {"state": ..., "labels": {"<question id>": "<option id>"}} and a TTT head is fitted on the spot for every question with 6 or more labelled rows, then shown beside the engine.
answers