Subquadratic launches SubQ Snap, a decision model that reads 384K tokens per call

What did Subquadratic launch?

Subquadratic announced SubQ Snap on 12 October 2026 in a launch post and a Business Wire release. The company emerged from stealth earlier this year with Subquadratic Sparse Attention, or SSA, an attention mechanism whose compute it says grows roughly linearly with context length instead of quadratically, and with SubQ, a language model built on it.

Snap is the first product aimed squarely at agents. Rather than generating answers, it makes the small, structured calls inside an agent loop: which files are relevant, which tool to use next, whether a test passed, or whether a step should be handed to a frontier model. Subquadratic’s pitch is that these calls depend on a lot of context, and that today’s decision models cannot afford to read it.

“Decision models get exciting when they can take real work away from LLMs, but the context window size of today’s decision models are simply too small or slow to handle real enterprise work,” Alex Whedon, Subquadratic’s co-founder and chief executive, said in the release. Snap is in limited public preview from today.

What is a decision model, and why does context matter?

A decision model is given some context, a question and a fixed set of allowed answers, and returns a probability for each answer. Because it never writes text, it avoids the time and cost of generating tokens the application does not need. Our coverage of OpenAI’s Decisions API and TypeSafe’s Jev explains how this category has grown into a standard interface in recent months.

Subquadratic’s argument is about input, not output. Removing generation removes the cost of the answer, but nearly all of a decision model’s compute goes into reading the prompt, and with standard attention that cost grows with the square of the context length. Doubling the context quadruples the attention work, which erodes the speed advantage that makes decision models worth using.

The alternative is to cut the input down with retrieval, summaries, truncation or chunking. Each of those decides in advance what the model will see, and the company gives examples of what gets lost: a user constraint stated 40 turns earlier, a function defined in another module, or a clause in a separate exhibit. It says today’s decision models typically stop at 32K tokens; Snap’s 384K is twelve times that.

How does SubQ Snap work?

Snap combines two parts. SSA handles reading: it uses content-dependent selection so the model attends only to the parts of a long input that matter, which is how Subquadratic keeps compute from exploding as context grows. A decision head handles answering: it maps the model’s internal representation straight to a probability for each allowed answer, with no word-by-word generation.

The company says Snap accepts mixed text and images in one context, so screenshots, charts, diagrams and scanned pages can be judged next to the documents and logs around them. It claims Snap can process a 100K-token request and return a decision in about one second. It frames four everyday agent jobs for the model: routing, tool picking, checking and stopping.

Subquadratic has not published Snap’s parameter count, training data or a technical paper for this model, and the SSA research it cites dates from its earlier SubQ announcement. In that work, it says, testing at 12 million tokens cut attention compute by almost 1,000 times compared with other frontier models.

How does Snap compare with Jev?

Jev, from TypeSafe, is the benchmark Subquadratic chose to beat, and it is the model most decision-model releases now compare against, as with H2O.ai’s Lightning-4B. On the Decision Index v0.2.1, a public suite of 37 short multiple-choice decision benchmarks scored so that guessing is 0 and a perfect answer is 100, Snap scores 61.7 against Jev’s 57.9. Every request in that index is under about 34K tokens, so it measures short-context decisions.

On a subset of 16 Decision Index benchmarks that the company maps to enterprise work, Snap averages 67.5 against 61.6 and leads on 13. The biggest gaps are phishing detection, up 22 points, predicting code output, up 16.7, spotting hallucinations in retrieval answers, up 13.5, and financial sentiment and NDA review, both up about 12. On Bespoke Labs’ Nimble set of 13 public datasets, Snap reaches 82.9 percent against 76.0.

Snap loses three rows, and they are telling for agent builders: When2Call, which tests whether a model should call a tool, ask a question, answer or decline, where it trails by 7.6 points; API-Bank’s next-call prediction, down 1.6; and aspect-level review analysis, down 0.6.

The long-context tests are where Subquadratic expects the largest difference. On its Decision RULER adaptation, which hides facts in long filler text, Snap scores 99.8 at 32K tokens against Jev’s 94.1, and Jev has no scores beyond that. On Decision LCR, built from Artificial Analysis’s AA-LCR multi-document questions of 72K to 115K tokens, Snap scores 74.0 reading everything at once against 48.0 for Jev working through chunks.

How do developers call SubQ Snap, and what does it cost?

Snap is called through the Decisions API at POST /v1/systemone with the model name subq-snap-preview. A request carries a state, which can be text, an object or an array, up to four images, and named questions of three types: a “noul”, the company’s term for a yes/no gate that returns the probability of yes; a choice among 2 to 255 named options; or a score over 2 to 10 ordered levels.

Each answer comes back with probabilities and, for choices and scores, a confidence value, so code can set its own thresholds. The documentation’s example triages a patient chat, returning a 0.92 probability that a nurse should see it, a nurse_line queue and an urgency score. Subquadratic’s other endpoints, Chat Completions and Responses, are OpenAI-compatible, but the Decisions API uses its own typed JSON contract.

Pricing is $0.05 per million input tokens, and output tokens are always billed at zero. That is in the same range as other hosted decision services such as Celeris, but at long context the input is the whole bill: a 384K-token call costs about two cents. Access is first come, first served while capacity lasts, and new users may be put on a waitlist.

What should teams check before using it?

All of the benchmark results come from Subquadratic. The Jev scores are as the company ran or reported them, several benchmarks are its own multiple-choice adaptations, and it notes that Decision LCR scores cannot be compared with published AA-LCR results. We have not tested Snap. One figure also needs clarifying: the post reports Decision RULER scores up to 1 million tokens, beyond the 384K context it advertises.

The weak spots matter for agents. Snap’s worst result is the call, ask, answer or decline test, which is exactly the kind of gate many agent loops use. Research on typed decision models used as guardrails has also shown that such gates can fail open, so teams should test edge cases and keep a fallback before letting any decision model approve actions on its own.

There are practical limits too. Snap is a hosted preview with no published weights, images are capped at four per call and 4 MiB each, video is not supported, and stored decisions follow Subquadratic’s data-retention policy. A sensible plan is to run Snap on a sample of your own routing and checking decisions against the model you use today, and switch only where the long-context gains show up in your data.