Subquadratic has launched SubQ Snap, a "long-context decision model" that picks from a fixed set of answers instead of generating text. It accepts up to 384K tokens of text and images per call, is priced at $0.05 per million input tokens with free output, and, according to Subquadratic's announcement, processes requests up to 100K tokens in under a second. It is in public preview now.
The pitch is a narrow but practical one: most steps in an agent loop are small calls, and paying a frontier model to make them is wasteful. Below, we cover what Snap is, what the vendor-reported numbers say, and when it makes sense.
TL;DR: the questions people will ask
| Question | Answer |
|---|---|
| What is it? | A decision model: scores a fixed set of allowed answers rather than generating free text |
| Context | Up to 384K tokens of text and images in one call |
| Speed | Requests up to 100K tokens in under a second (vendor claim) |
| Price | $0.05 per million input tokens, output free |
| Access | Public preview at subq.ai, first come first served, waitlist when capacity is reached |
| Compared with Jev | 61.7 vs 57.9 on Decision Index 0.2.1; leads 13 of 16 enterprise benchmarks (vendor results) |
| Open weights? | Not stated; it is a hosted API |
What a decision model actually is
According to the announcement, Snap uses two pieces. The first is Subquadratic Sparse Attention (SSA), the company's attention method that, per the page, cuts the cost of reading long inputs from quadratic to linear in context length. We covered the underlying idea in our earlier piece on SubQ's SSA and 12M-token context. The second is a decision head that maps the model's internal representations to a probability distribution over the allowed answers, so it never has to generate text token by token.
That design explains the product claims. Because the output is a choice, a score or a label, your code can use it directly without parsing free text. Subquadratic's comparison table puts it this way: a language model is best at reasoning, writing and open-ended work, while a decision model is best at routing, ranking, classifying and yes/no calls, and weak at open-ended generation.
Why quadratic scaling matters here
A long ribbon passing through a ring, illustrating a long input read in one pass by the SubQ Snap decision model
Standard transformer attention compares every token with every other token, so doubling the input roughly quadruples the compute, while Subquadratic says SSA's linear scaling only doubles it. That is why most decision-style models have stayed small in context: Subquadratic's page says today's decision models see about 32K tokens, "a sliver of a real codebase". SSA is the company's answer. It tries to isolate the small fraction of token relationships that actually matter and spend compute only there. If the claim holds, the cost of a call grows roughly in line with input length, which is what makes a flat $0.05 per million input price plausible even at 384K tokens.
The practical effect is that you can show the model a whole repository, data room or agent history instead of a chunk. For routing a support ticket that is overkill, but for questions like "which of these 200 files matters for this bug" or "does anything in this contract bundle break our rules", seeing everything at once is the point.
Where this sits in Subquadratic's roadmap
Subquadratic says SSA powers SubQ, which it calls the first fully subquadratic LLM, announced earlier this year. Snap applies the same research to a narrower job. The company says its language model, SubQ 1.1 Small, is still in early access with selected design partners who contact sales, while Snap is open in public preview at subq.ai, so it is the way for most developers to try the technology now.
Snap also enters a small field. Subquadratic's page names Laya, Perplexity's Decider and TypeSafe's Jev as existing decision models that expose the same interface: a question, a finite set of allowed answers and a structured prediction. Its pitch is that those models typically stay at about 32K tokens of context, while Snap goes to 384K.
A worked cost example
Suppose an agent makes 20 routing decisions per task, each over a 50K-token context. That is 1M input tokens per task, or about five cents at Snap's list price, and nothing for output. Run 10,000 tasks a day and the decision layer costs roughly $500 per day at list price. The same volume at typical frontier input prices would be many times higher, and the frontier model would also spend seconds to minutes per call instead of under a second. The saving only materializes if Snap's accuracy is good enough on your decisions, which is why the comparison step in the try-it list matters more than the headline price.
The benchmark numbers (all vendor-reported)
Subquadratic's own results, from its launch page:
- Long context: Decision RULER scores range from 96.3 to 99.8 across 32K to 1M tokens. On Decision LCR, a multi-document benchmark with 72K to 115K token inputs, Snap scores 74.0 against 48.0 for Jev, which had to chunk the input.
- Short context: Decision Index 0.2.1 gives Snap 61.7 against 57.9 for Jev. On the Nimble 13 accuracy set it is 82.9% versus 76.0%.
- Enterprise workflows: across 16 benchmarks Snap averages 67.6 versus 61.6 and leads on 13. It trails on ACOS (reviews), API-Bank (API calls) and When2Call (routing). The biggest wins listed are PhishNChips phishing detection (+22.0), CRUXEval code (+16.7), RAGTruth RAG checks (+13.5), FinEntity finance (+12.0) and ContractNLI legal (+11.6).
Two cautions. These are first-party numbers on benchmarks the company chose, including a "Decision Index" that is new and carries a v0.2.1 version tag. And the comparison model, Jev, has a 32K context limit in this comparison, so the long-context wins partly reflect that rival being forced to chunk. Treat the headline as "competitive on its target task", not as a general ranking.
Note also that the vendor's table shows the enterprise average as 67.54, which the text rounds to 67.6; we use the figure in the text.
Pricing: the part builders will care about
At $0.05 per million input tokens and free output, a 100K-token decision call costs about half a cent in input. Compared with sending the same context to a frontier model, the difference is large, which is the point of the product. It also fits a broader trend we have tracked in context-window pricing: long context is getting cheaper, but only when the architecture is built for it.
Launch terms: public preview is first come, first served while capacity is limited, with a waitlist once it is reached. Broader availability is promised as more capacity comes online. That is a real caveat for anything in a latency-critical path.
Long scroll unrolling with a marker, illustrating a whole repository or data room read in one SubQ Snap call
Where it fits in an agent loop
The vendor lists these roles, which match the decision-model definition:
- Context curation inside coding agents: which files or history are relevant.
- Multimodal recommendation: scoring candidates using text and images together.
- Support queue triage: which ticket needs a human, whether a lead is worth chasing, whether a contract clause breaks a rule.
- Tool selection and checks: pick a tool, open a file, check a result.
The design principle is to leave planning and generation to your LLM and hand the repeated, structured calls to Snap. This is the same split you see in efficient agent harnesses, and it echoes our coverage of small search-agent models that offload retrieval from the main model. If you run coding agents, also see how context cost shapes agent design.
Limits and unknowns
- Vendor benchmarks only. We found no independent evaluation yet.
- Narrow task type. A decision model cannot draft, explain or plan, so you still need an LLM.
- Capacity. Public preview, a waitlist, and variable latency mean it is not yet a drop-in for production routing.
- Details. The launch page does not detail the API, limits or customer quotes.
- Fixed answer spaces. If your decision cannot be framed as a closed set of options, Snap is the wrong tool.
How to try it
- Sign up at subq.ai, as linked from the launch page, and join the waitlist if capacity is full.
- Pick one decision in your pipeline with a closed answer set, such as ticket routing or file relevance.
- Log your current LLM's answers for a few hundred cases, run Snap on the same inputs, and compare accuracy, latency and cost.
- Only then move traffic, keeping the LLM as a fallback for low-confidence cases.
Related reading
- SubQ SSA sparse attention and 12M context
- Context window pricing decoded
- Mixedbread Toast-1 search agent
- Managing AI coding costs at scale
- Sliding window attention vs linear attention
- Fork-and-Flush and long-running agents
- Announcement: Introducing SubQ Snap
Prices, limits and benchmark figures are accurate as of October 12, 2026 and come from Subquadratic's launch page; they may change.
