SubQ Snap is entering a capacity-limited public preview with support for up to 384K tokens of text and images. Its job is narrower than that of a general-purpose LLM: choose a tool, score an option, classify a result or decide whether an agent should continue.
In its October 12, 2026 announcement, SubQ lists a price of $0.05 per million input tokens, with outputs free, and says Snap can process 100K tokens and return a decision in about one second. These are company-published specifications and performance claims, not independently verified measurements.
Snap is intended for repeated decisions inside an agent workflow, leaving the final written response to a generative model. If those calls are sufficiently accurate, cheap and fast, builders could reserve larger generative models for work that needs generation. The preview gives them a service to test that proposition, though access is first-come, first-served and constrained by available capacity.
Snap Makes Choices Beside the Generative LLM
A coding agent may need a generative LLM to write a patch. Choosing which files to inspect, which tool to call next or whether a test result warrants another attempt can involve much smaller answer spaces.
SubQ describes Snap as a decision model that takes context, a question and application-defined answers, then scores those possibilities. Its output might be a choice, a score or a label instead of open-ended text. That interface places it in the control logic surrounding an agent’s generative work.
The company identifies four roles:
- Routing: Decide which task, model or workflow should receive a request.
- Tool picking: Select an appropriate tool from the available options.
- Checking: Evaluate an output or result against a defined condition.
- Stopping: Decide whether to continue, finish or escalate.
These roles overlap, but each raises different evaluation problems. A routing mistake might send an easy request to an unnecessarily expensive model. An incorrect check could approve faulty work, while a premature stopping decision could leave a task unfinished.
For example, a builder could ask Snap to choose between inspecting another file, running tests or handing a difficult debugging step to a larger model. The larger model would still generate the patch; Snap would handle a bounded decision around that work.
Restricting the answer space makes the output easier for software to consume. It doesn’t make the selected answer correct. Applications still need deterministic permission checks and appropriate escalation paths. A model’s decision that a tool is suitable should not, by itself, authorize the tool to perform a sensitive action.
A Small Answer Space Can Still Need a Large Context
Snap’s central proposition is that a short answer need not come from a short input.
Choosing between three tools might require examining a repository, previous failures and a constraint buried in an earlier interaction. Checking a contract could require reading both the main document and its exhibits. A single label may depend on substantial evidence.
SubQ says Snap supports up to 384K tokens of mixed text and image context, allowing documents, screenshots, charts and other artifacts to appear in the same request. This is an advertised input capacity, not proof that every task benefits from filling the window.
The company attributes its long-context efficiency to Subquadratic Sparse Attention, the research underlying its broader SubQ work. Removing lengthy text generation still leaves the cost of processing the input, a limitation its approach aims to address.
In standard dense self-attention, the attention computation grows quadratically with sequence length. That describes the attention component; it does not guarantee that total inference cost or latency follows exactly the same curve.
Retrieval, summarization and chunking can reduce the input burden, but they also determine what evidence reaches the decision model. Snap’s longer window offers a way to avoid some of that preprocessing. Builders still need to test whether passing more material improves decisions enough to justify repeatedly processing it.
The Price Is Concrete; the Speed Claim Needs Conditions
Snap’s published preview price makes the input-cost calculation straightforward:
| Input per decision | Input charge at the published rate |
|---|---|
| 100,000 tokens | $0.005, or half a cent |
| 384,000 tokens | $0.0192, or 1.92 cents |
These figures are arithmetic based on SubQ’s $0.05-per-million-token rate. Outputs are listed as free. The calculations cover model-input charges, excluding the cost of running an agent, executing tools or calling a separate generative LLM.
Twenty decisions, each processing 100K tokens, would cost $0.10 in Snap input charges at that rate. Whether repeated calls save money depends on what those decisions replace and whether errors trigger additional work.
SubQ’s latency claim needs a separate reading: Snap can process 100K tokens and return a decision in approximately one second. That does not establish one-second performance at the full 384K context limit, nor does it establish the response times a builder will observe under concurrent traffic, varying image inputs or preview congestion. A useful evaluation would measure both typical latency and slower responses across the actual request sizes an application sends.
Price, speed and context capacity answer different questions. The price supports a cost estimate, the context limit describes how much input the service advertises accepting, and the latency figure is a reported performance point at a particular input size.
A like-for-like comparison with another service would need equivalent tasks, input lengths, concurrency and decision quality. A low per-token rate alone cannot establish a lower cost per successfully completed workflow.
SubQ’s Benchmark Lead Comes With Important Boundaries
SubQ’s published benchmark tables compare Snap primarily with Jev. They provide evidence for the company’s positioning, though they are first-party evaluations, not independent validation.
On Decision Index v0.2.1, SubQ reports a score of 61.7 for Snap versus 57.9 for Jev, a 3.8-point difference. The announcement says requests in that public suite are under 34K tokens. This result supports the company’s short-context decision-quality claim without directly validating the advertised 384K window.
The headline enterprise-subset summary reports an average of 67.6 for Snap versus 61.6 for Jev, with Snap leading on 13 of 16 tasks. Those tasks cover areas including support routing, document verification, legal analysis, code and tool use.
For selecting an agent component, the individual results are more useful than the average. In SubQ’s table, Snap trails Jev on API-Bank, scoring 86.4 against 88.0, and on When2Call, scoring 67.0 against 74.6. The latter evaluates whether to call, ask, answer or decline, making it particularly relevant to decisions about an agent’s next action. These losses do not negate the reported aggregate lead, but they show why an overall score cannot settle whether Snap is the better choice for a particular control decision.
