# SubQ Snap: what 'constant compute per token' has to mean, checked against what Subquadratic published
> Satyajit Ghana ā Head of Engineering @ Inkers Technology
> canonical: https://ai.thesatyajit.com/articles/subq-snap
> date: 2026-10-13
> tags: sparse-attention, long-context, benchmarks, ecosystem, agents, multimodal
[Alex Whedon's launch post](https://x.com/alex_whedon/status/2109676361371824229) for SubQ Snap has a list of numbers. One line in it is a different kind of claim: "Snap is the only decision model or LLM where compute per token stays constant as context grows."
That line is about architecture. A transformer with dense attention cannot satisfy it, because every new token compares itself against every token before it, so the work per token grows with the context. Something has to give for the cost per token to stay flat, and there are only a few things that can. I wanted to know which one Subquadratic picked, and whether the rest of the list (384K tokens, 61.7 on the Decision Index, 13 of 16 enterprise benchmarks, under a second for 100K tokens) holds up when you go to the files behind it.
The short answer: the mechanism is not published, but Subquadratic's own technical report gives away its shape, and once you know the shape you know which of Snap's numbers can say anything about it. Most of them can't.
## What a decision model pays for
A decision model takes some context and a question with a fixed set of allowed answers, and returns a probability for each answer instead of generating text. The site has covered this category at length, starting with [TypeSafe's Jev](/articles/jev-system-one-models), and [the limits it inherits from that design](/articles/what-decision-models-cannot-do).
Snap speaks Jev's dialect exactly. Its [API docs](https://docs.subq.ai/markdown/endpoints/decisions-api.md) put it at `POST /v1/systemone`, the same path [llama.cpp adopted](/articles/llamacpp-decision-models) for Jev-style models, with the same three question types: a `noul` (yes/no probability), a `choice` over 2 to 255 named options, and a `score` over 2 to 10 ordered levels. A request "must fit the model's 384K-token (393,216) context window". It takes up to 4 images, at about 64 to 256 tokens each. The response's `usage` block always reports `output_tokens: 0`.
That last detail explains "Output is free." A decision head reads a probability distribution off the final hidden states; there are no output tokens to bill. The phrase is true, and it would be true of every model in this category.
It also means the whole cost of a call is prefill: reading the input. Subquadratic's [launch blog](https://subq.ai/introducing-subq-snap) says so plainly, "For a decision model, nearly all inference compute is prefill." Take away generation and what is left is attention over a long input, which is exactly the part that grows quadratically. So if you want a decision model to read a whole repository, the attention mechanism is the only thing worth changing. As product theses go, I think this one is right.
## Three ways to keep per-token cost flat
For the work per token to stop growing with context, each token has to read something of fixed size. There are three families that manage it.
The first is a recurrent state. Mamba, RWKV and linear attention fold the past into a fixed-size state and read only that. Per-token cost is constant by construction. The price is that the state is a compression, and a specific fact from 300K tokens ago may not survive it. The site's [Mamba explainer](/architectures/mamba-ssm) and [roundup of linear attention's memory problem](/articles/linear-attention-state-roundup) cover this trade.
The second is a hybrid: keep a few full-attention layers among recurrent ones. Qwen3.8-27B, the base of two strong open decision models ([pplx-decider v1.1](/articles/pplx-decider-v1-1) and Cloudflare's clef), is built this way: its config has `full_attention_interval: 4`, so 16 of its 64 layers are full attention and 48 are linear attention. That cuts the bill by a constant factor, but the 16 full layers still grow with context, so per-token cost is not flat.
The third is sparse attention with a fixed budget. Every query still does exact softmax attention, but only over a fixed number of positions it selects from the whole context. If the number is fixed, the read is constant per token. [MiniMax Sparse Attention](/articles/minimax-sparse-attention) does this with 2,048 tokens per query; DeepSeek's DSA does it with 2,048 as well.
SSA is the third kind. The [SubQ-1.1-Small technical report](https://subq.ai/docs/subq-1-1-small-model-card.pdf) (22 pages, Saul Ramirez, Alex Whedon, Ashmal Vayani and Phong Vo) says "SSA is sparse, each query attends to a small, selected subset of positions", and it spends a section explaining why recurrent models fall short at exact retrieval. So no state, no hybrid: content-dependent top-k-style selection.
The catch with the third family is the selector. To pick the best positions, something has to look at the candidates, and if it looks at all of them, every query does work proportional to n again. That is the report's critique of DSA, and its Table 2 makes it concrete for a V3.2-style configuration: the Lightning Indexer costs the same as the sparse attention it feeds at about 52K tokens, 16.1 times as much at 1M, and 190.4 times at 12M. The selection is quadratic even when the attention is not. (The report's background section also calls Native Sparse Attention "also known as DeepSeek Sparse Attention". They are different DeepSeek mechanisms: NSA's paper selects compressed blocks, DSA is V3.2's Lightning Indexer. The comparison in Table 2 is with DSA, which is the right one.)
SSA's claim is that its "selection, retrieval, and attention steps are each linear in sequence length, so the mechanism is linear end-to-end." For the total to be linear, choosing positions for one query must cost something that does not grow with n: hashing into buckets, clustering keys into routes, or descending a hierarchy of summaries would each do it (the last at a log factor). Which of these SSA uses, the report declines to say: "The mechanism by which SSA meets these requirements is outside the scope of this report."
## The budget is about 16K positions
The report does not describe SSA, but it does publish how SSA's cost scales, in three places. Read together, they point to one number.
Table 1 gives attention FLOPs per layer for SSA and for dense attention on the same backbone. The SSA column doubles exactly with context: 0.12 PFLOP at 32K, 0.25 at 64K, 0.49 at 128K, up to 3.9 at 1M. That is the linear part. The reduction column, dense attention FLOPs over sparse, reads 2.1x at 32K tokens, 4.0x at 64K, 8.0x at 128K, 16x at 256K, 31.5x at 512K and 64.5x at 1M. Divide each context length by its reduction and you get the same number every time, within rounding: 32,768 / 2.1 is about 15,600, and 1,048,576 / 64.5 is about 16,260. Dense attention reads n positions per query; SSA's cost is what dense attention would cost at about 16K.
Figure 12, the single-layer speed comparison against FlashAttention-2, says "SSA reaches parity near 16K tokens." Below that there is nothing to skip.
And the 12M-token needle test, the report says, ran "attending to only 0.13% of token pairs". 0.13% of 12M is about 16,000.
Three independent numbers, one budget. My reading is that each SSA query reads a fixed set of roughly 16,384 positions per layer, whatever the context length. I could be wrong in the details (the FLOP accounting could count causal halves differently, which would halve the figure), but the scaling is not in doubt: flat per query above about 16K tokens, dense below it.
This is the most useful thing to know about Snap, because it tells you where its architecture can matter. Slide the widget to the Decision Index's longest request:
At 1,933 tokens, Nimble's longest record, SSA and dense attention do identical work. At 34K, the Decision Index's ceiling, the saving is about 2x in the attention layers alone, and attention is only part of a forward pass. At Snap's 393,216-token limit it is about 24x, and that is where a dense decision model would actually hurt.
Two small things in the report's accounting bothered me. Table 3 compares DSA with SSA "under a matched selected-position budget", and its SSA column (headed "DBSA", an acronym the report never defines) is identical, row by row, to the sparse-attention-only column of Table 2: 71.0T at 128K, 568.3T at 1M. So the comparison charges SSA's selector zero FLOPs. That may be close to true; nothing published lets me check it. And the numbers drift between Subquadratic's own documents: the May SSA blog post gives a 62.8x FLOP reduction at 1M where the report says 64.5x, reports both 56.2x and 52.2x as the 1M prefill speedup, and lists 6.88x at 128K as both a wall-clock speedup and a FLOP reduction. None of this changes the shape. It does tell you the efficiency figures were not proofread against each other.
## "The only decision model or LLM"
The post says Snap is the only decision model or LLM whose compute per token stays constant as context grows. The blog calls SubQ "the first fully subquadratic LLM".
The "or LLM" half is not right, and Subquadratic's own report is the evidence. Its section on recurrent models: "The complexity is O(n) by construction," naming Mamba, RetNet, RWKV and gated variants. A pure recurrent language model has constant per-token compute, and several ship as open weights; the site covered one, [RWKV-7 G1k](/articles/rwkv-7-g1k), a 100% RNN family. What the report actually argues is that those models give up exact retrieval. That is a fair argument and a different claim.
"The only decision model" is plausible. Every [Decision Index](https://huggingface.co/spaces/multimodalart/jev-decision-index) entrant whose base model I know is a dense or hybrid transformer underneath, and I found no published decision model on a recurrent or fixed-budget sparse backbone. I would phrase it as "the first one with a fixed attention budget" and leave LLMs out.
## The latency numbers are almost linear
The launch post gives four speeds: "80ms for minimal context, 250ms for 32k, 660ms for 100k, and 2.5 seconds for 384k." If per-token cost is constant, time after the fixed overhead should grow in proportion to context. Subtracting the 80 ms floor, the marginal cost is 5.2 microseconds per token at 32K, 5.8 at 100K and 6.3 at 384K.
That is close to flat. A purely linear line through the 32K point predicts about 2.07 s at 384K, not 2.5 s. A dense model would be in another world: if all of the 32K request's variable time were quadratic, 384K would take about 23 seconds.
With a crude two-term model (a part that grows with n and a part that grows with nĀ²), all three published points fit when about 2% of the 32K request's variable time is quadratic. That residue could be the selector, memory traffic, the vision path or just rounding in a launch post. Either way, the published speeds leave very little room for quadratic work. Someone in the replies plotted their own three measurements and called them "remarkably linear"; Whedon replied that he was glad they "were able to observe the linear behavior".
The launch video's policy demo is in the same range: about 212,849 tokens answered in 1.62 s, where a line through the published points gives roughly 1.3 to 1.4 s. Two replies are worth noting as leads I could not confirm: one integrator reported that the largest input they managed to send was 295,957 tokens, not 384K, and a closed-beta tester reported 90 to 95% accuracy "up to ~195k tokens" with a 0.55 s median. I had no API key and did not call the service.
One more back-of-envelope, with a caveat. The SSA blog's B200 table gives 380.96 ms for one SSA layer at 1M tokens. Scaled linearly, that is about 140 ms per layer at 384K. Snap does all of its layers at 384K in 2.5 s, which is about 18 such layers end to end, with nothing else in the forward pass. So either Snap is shallow or narrow next to the layer configuration that was benchmarked, or it is served across several GPUs in parallel, or its budget is smaller. The model's size, depth and serving setup are unpublished, so I can't say which.
## Where the scores can and cannot speak
The launch makes five evaluation claims. They split cleanly once you know the budget.
### The short-context wins say nothing about SSA
Two of the headline wins are on short inputs. Bespoke Nimble's public benchmark is 3,880 records from 13 datasets, and its own [documentation](https://github.com/bespokelabsai/nimble/blob/main/docs/PUBLIC_BENCHMARKS.md) says "no record exceeds the 2,048-token budget"; the longest is 1,933 tokens. The Decision Index tops out at about 34K tokens by the launch blog's own description. In both, SSA either does nothing or saves a factor of about two. Snap's 82.9% against Jev's 76.0% on Nimble, and 61.7 against 57.9 on the Decision Index, are wins for whatever backbone and training Snap has, not for its attention.
Jev's 76.0 on Nimble checks out: it is the plain average of Jev's 13 subset accuracies in Nimble's results table (80.4, 89.7, 81.0 and so on), exactly 76.0. Snap's 82.9 is Subquadratic's own run; Nimble's repository has no Snap results.
The Decision Index number needs two qualifications.
First, nobody else has run it. The board's `data/index.json`, regenerated on 12 October, has 148 entrants and no Snap. The 61.7 is Subquadratic's own run of the public kit, the same situation as [Agr's 58.15](/articles/agr-decision-model) a week earlier.
Second, the chart compares Snap with Jev and nobody else. The launch cites "Decision Index v0.2.1". On the 0.2.1 board as it stood on 28 September, Jev led at 57.91, so 61.7 would have been first by almost four points. The board has moved since: on the public-panel score it reports today, seven entrants sit above 61.7, from RSI-Jev v6.1 VL 27B at 65.64 and vLLM-SR d3 at 65.45 down to pplx-decider v1.1 at 62.25, and Cloudflare's clef sits at 61.71. Against the field Snap launched into, 61.7 is eighth, level with clef. That is still a good score for a model that is also the only one built for 393,216 tokens. It does not make Snap "the industry leader in short and long context decision-making", as the homepage puts it, on the short half.
The area bars are worth reading closely. The blog's text says Snap "outperforms Jev on four out the five major categories" and lists those four; the chart adds the fifth, knowledge and reasoning, where Snap is behind, 48.5 to 51.2. That loss comes with CRUXEval, a knowledge benchmark, at +16.7 in Snap's favour, so the rest of the area (GPQA Diamond, MMLU-Pro, BBH, HLE and the others) is further behind than the bar suggests.
The Jev bars are the odd part. Three of them match Jev's area scores on the 0.2.1 board: language 62.0, retrieval 55.4, tools 75.1. Knowledge is 51.2 against the board's 51.4. Arts and human taste is 32.8 in the chart and 37.7 on the board. Weight the chart's five Jev bars the way the index does (25.8% each for knowledge and language, 20% retrieval, 18.3% tools, 10% arts, as [measured in the Agr article](/articles/agr-decision-model) from the kit) and you get 57.3, not the 57.9 printed beside them; Snap's five bars give 61.6, consistent with its 61.7. So Snap's area scores and its total agree, and Jev's do not. Against the board's arts figure, Snap's largest area gain, +12.1, would be about +7.2. I don't know where 32.8 came from; it may be an older run or a different arts panel. It is the number that makes the chart's most striking bar.
### The enterprise table is honest arithmetic over a chosen subset
I compared every Jev number in this table with Jev's chance-corrected skill scores in the board's `index.json`. All sixteen match after rounding: CLINC150 89.21, BANKING77 79.48, PhishNChips 25.10, ESCI 43.82, through to ACOS 27.27. Subquadratic copied the board, not a rerun. The averages also reproduce: Snap's sixteen average 67.54 and Jev's 61.58, a gap of 5.96, and Snap is ahead on 13. The launch materials round 67.54 three ways (67.5 on the homepage, 67.6 in the blog's summary and chart, 67.54 in its table), which is untidy but not wrong.
What the table cannot tell you is how the 16 were chosen from the 37 in the index. The blog's criterion is benchmarks "that map most closely to enterprise workloads", which is reasonable, and the three losses are left in. When2Call, deciding whether to call a tool, ask, answer or decline, is the largest loss at ā7.6, and it is the most agent-shaped benchmark on the list.
### Long context is where SSA can show, and the evidence is thinner
Decision RULER is Subquadratic's conversion of 11 of RULER's 13 tasks into four-option decisions; they dropped the two question-answering tasks because models could answer them from memory. Snap scores 99.8 at 32K and between 99.3 and 99.8 out to 512K. The blog's summary leads with "96.3 on Decision RULER at 1MM tokens". The API rejects anything over 393,216 tokens, so the 512K and 1M bars, including the headline, measure a configuration a customer cannot send. They are evidence that SSA keeps retrieval at long range, which is what the report claims for the 1.1 Small model too. For Snap as sold, the number to quote is 99.8 at 256K. Jev appears once, at 32K, with 94.1, because that is as far as it goes.
Decision LCR is the most interesting result in the launch, because it is the only one that tests reasoning, not lookup, over inputs that do not fit in 32K. The protocol is careful: 118 decisions from 100 questions, three option orderings each, credit only when every part of a question is right, random at 19.2 and models with documents removed at about 24 to 25. The confidence intervals in the chart are the right ones; I recomputed Wilson 95% intervals for 74 and 48 out of 100 and got 64.6 to 81.6 and 38.5 to 57.7, as printed.
But it is a protocol comparison as much as a model comparison. Jev cannot see a 100K-token document set, so it was given chunks, and the blog does not say how chunk answers were combined. A 26-point gap between reading everything and reading pieces mostly confirms the premise that whole-document reading helps. The obvious missing baseline is a long-window decision model that reads the whole set too. One exists: [pplx-decider v1.1](/articles/pplx-decider-v1-1) accepts up to 262,144 tokens per request, enough for every LCR document set, though it was trained only up to 8,192. The blog's line that "today's decision models stay at 32K tokens" was already untrue of Perplexity's API when Snap launched.
## Price, and what I would use it for
Snap costs \$0.05 per million input tokens. A full 393,216-token request is about two cents, and a 100K-token request half a cent. pplx-decider is \$0.02 per million, so Snap is two and a half times the per-token price. Perplexity's own docs say "about 190,000 tokens took 14 seconds"; Snap's post says 2.5 s for twice that. Whether Snap bills the state once per request or once per question, as Perplexity's server does, the docs do not say directly; they advise putting related questions in one request "so the state is sent once", which suggests once.
What I take from all this:
The architecture claim is mostly real and badly worded. Every published efficiency number is consistent with a fixed budget of about 16K positions per query and a linear end-to-end cost, and the launch latencies are close to linear. "Only LLM" is wrong; "only decision model" is probably right. The selection mechanism, the part that makes or breaks the linear claim, is unpublished, and the report's own comparison prices it at zero.
The short-context scores are good and unrelated to the architecture. Treat 61.7 as a self-run eighth place behind seven other entrants until it appears on the board, with a weak spot in knowledge-heavy questions.
The long-context results are the reason to try it. I know of no other decision model with a published long-context evaluation, and no other that publishes a latency at 384K. If your decisions really depend on the whole repository or the whole contract (picking the files a change touches, checking an answer against a long policy), Snap is the first decision model built for that, and the API accepts the same requests as Jev's. Before trusting it, measure it on your own labelled long inputs, set thresholds from those, and compare against a strong long-window baseline, not against a 32K model reading chunks. That is the comparison Subquadratic did not publish.
## How I checked
I read the launch post, its thread and the first page of replies through the fxtwitter mirror; Subquadratic's homepage, the Snap launch blog, the "How SSA Makes Long Context Practical" post (updated 15 May), the SubQ 1.1 Small announcement, the 22-page SubQ-1.1-Small technical report PDF (text extracted with `pdftotext`, figures with `pdfimages`), and the API docs at docs.subq.ai (Decisions API, Models, quickstart). The budget inference divides context length by Table 1's reductions and compares with Figure 12 and the 0.13% figure. Board comparisons use the Decision Index Space's `data/index.json` (generated 12 October 2026) and `data/index-v0.2.1.json` (28 September), reading Jev's per-benchmark skill and every entrant's public-panel score. The area check reweights the chart's bars with the index's five area weights and compares Jev's bars with the board's category scores. Nimble's figures come from a shallow clone of [bespokelabsai/nimble](https://github.com/bespokelabsai/nimble), `docs/PUBLIC_BENCHMARKS.md`. Qwen3.8-27B's layer layout is from its `config.json` on Hugging Face. Latency arithmetic uses only the four figures in the post. I had no API key, did not call the service, and could not check anything Subquadratic ran itself: Snap's own scores, the Jev chunking procedure, the model's size or backbone, or how SSA selects positions.