This post is about Jev's Choice API: how to send a question with a fixed set of answers and get back a probability for each one, and how I used it to build Ask Jev, an independent browser extension for Jev. Jev is TypeSafe's System One model, and it does not generate text. You give it a state and a set of choices, and it returns a probability distribution over those choices, which is what lets you ask a question about a webpage and get an answer instead of a paragraph. I am the developer of Ask Jev, and it is the extension I use as the running example here.
The problem: most questions I ask during a workday need an answer, not a conversation
I spend a good part of my day asking software yes or no questions. A vendor's pricing page says overage is billed monthly, and I need to know whether that is actually monthly or "on the anniversary." A pull request touches a file near the auth code, and I want to know whether it changes the auth path. A contract PDF has a clause that looks like it lets them change the price, and I want to know if it does.
None of those are conversations. I do not want four paragraphs I then have to read and summarize into the decision I already knew I was making. A chat model gives me prose and makes me extract the answer. That extra step is the whole problem. I wanted to press a key, ask the question, and get the answer.
That is the thing I built. Ask Jev is a Chrome extension. Press Command+J on any page, type a question, and instead of generated text you get a probability for each possible answer. It runs on TypeSafe's Jev model, which returns decisions rather than prose. The extension is mine, it is independent, and it is not affiliated with TypeSafe.
Jev is a model, served on TypeSafe's System One endpoint, that puts probability mass over a fixed set of answers instead of generating a reply. The part I use is the choice question type. You send it three things: a state (the text it should judge), a model string, and a questions object. For a choice question you give it instructions (your question as a string) and criteria (a map whose keys are the possible answers). It gives back a probability for each answer and which one it selected.
The criteria values are null on purpose. Only the keys matter. The keys are the labels you get probabilities for.
Here is a full request you can copy and run. It uses a plain string for state, which is the simplest valid form, and the endpoint, header, body, and model are the real ones.
The response also carries a usage block with input and output token counts. The probabilities above are an example, not a measured query. What matters for a builder is that there is no text field to render and no streaming to handle. There is choice, one string, the probabilities you asked for, one per label, and confidence, a single number derived from that distribution. My parser reads choice and probabilities and treats any distribution that does not sum to within 2 percent as an invalid response, showing an error rather than a wrong answer.
Create an account at console.typesafe.ai and generate a key on the API keys page, then export it as TYPESAFEAPIKEY so the official SDKs and the examples here can find it. TypeSafe briefly paused new signups in late September and reopened them on September 27, 2026, and as of this writing new accounts no longer receive the $5 free credit that early accounts got, so you pay list price from your first request. If you cannot get a TypeSafe account, Jev is also served through gateways like Vercel AI Gateway and OpenRouter, which issue their own keys under their own model names.
One naming detail that cost me an afternoon: on your own key the extension sends the model string from Settings, which defaults to jev-latest, while the free-tier proxy pins jev-1.13.0 so the free path does not move under users. The response echoes whichever model served the request, which is why the model field above reads jev-1.13.0 while the request asked for jev-latest.
I am not going to quote timings or accuracy figures. TypeSafe's terms restrict publishing performance information, I do not have accuracy numbers I would stand behind, and neither is useful for deciding whether the API fits your use case.
Press Command+J on macOS (Ctrl+Shift+K elsewhere) and a palette opens in the current tab inside a Shadow DOM, out of reach of page CSS. The toolbar icon does the same.
Context starts with your selection. With nothing selected, it walks main, article, [role='main'], falls back to body, drops tags that are never the answer (script, style, nav, header, footer, forms, inputs, canvas, dialog), skips hidden elements and duplicate lines, and truncates to a byte budget. The truncation binary-searches a UTF-8 boundary, so it never splits a character:
Drag a PDF in and pdfjs-dist parses it locally: the file is read from an ArrayBuffer, text is pulled page by page up to 500 pages, and the output is capped at 5 MB per file and 250 KB of text. The raw file never leaves the browser, which is what makes it reasonable to ask AI about a PDF you would not otherwise upload anywhere. TXT, Markdown, JSON, and CSV read the same way.
A dropped PDF appears as a chip in the palette. It is parsed in the browser; only its extracted text is sent with the question.
Everything the model sees shares one 24 KB budget. The state is { webpage, documents }, split across the page and each document with a binary search until the serialized state fits:
Before anything is sent, the question and choices are validated: 500 characters max, two to eight answers, deduplicated case-insensitively, 80 characters each. Only the background worker holds the API key; the content script cannot read it.