SubQ Snap 1.1 vs Granite 4.2 3B: The Per-Token Price Is the Wrong Bill

IBM's Granite 4.2 3B lists at $0.03 per million input tokens. SubQ Snap 1.1 lists at $0.04. If the per-token rate were the bill, the 3-billion-parameter Apache-2.0 model would beat the decision model that tied for first on the Artificial Analysis Decision Index v1.0, and this article would be short. The rate is not the bill. Once you price a decision rather than a token — including what each model has to emit to produce one — the ranking flips, flips back depending on a single configuration setting, and ends somewhere neither vendor advertises.

Granite 4.2 3B is IBM's small dense reasoning model, released on August 25, 2026 alongside 8B and 30B siblings with unusually little fanfare — a technical blog post rather than a launch event. Snap 1.1 is Subquadratic's decision model, live since October 22, 2026, which returns a choice from a fixed answer set instead of generating text. They overlap on exactly one workload: taking a chunk of text and deciding what it is. Everything else about them is different, including what "cheap" means.

First, what the two models actually are

Granite 4.2 3B is a three-billion-parameter dense decoder built on Granite-4.1-3B-Base. It is a reasoning model with three modes: a thinking mode that emits a chain of thought, a low-effort mode, and a non-thinking mode that answers directly. IBM reports AIME 2025 at 78.33, GPQA at 54.80, LiveCodeBench v6 at 69.71, MMLU-Pro at 67.84, IFBench at 74.3 and τ³-Bench at 45.8 — all vendor figures, none reproduced independently. On long context it reports RULER of 67.52 at 64K and 55.30 at 128K. Artificial Analysis puts its Intelligence Index at 9, which is unremarkable in absolute terms and above the median for its size class.

The hardware story is the interesting part. It runs in six to eight gigabytes at bf16 and under two gigabytes quantised, which means a laptop, a single consumer GPU, or a CPU with enough RAM. It is text-only, covers twelve languages, supports OpenAI-compatible tool calling, and ships in vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX and Ollama. If your constraint is "must run somewhere I control", this model clears it.

SubQ Snap 1.1 is the opposite kind of product in almost every dimension. It has no weights. It runs only through Subquadratic's API. It takes up to 384K tokens of text and images plus an answer set of two to 255 alternatives, and returns a selection with a calibrated probability. It cannot write a sentence, which is the point: there is no output to parse and no output to pay for.

The output-token trap

Here is the arithmetic that the per-token comparison hides. Take a million routing decisions, each reading 6,000 tokens of ticket text — a plausible monthly volume for a mid-size support operation, or a busy afternoon for a large one. That is six billion input tokens.

• Granite 4.2 3B in non-thinking mode — 6B input tokens at $0.03/M is $180, plus roughly five output tokens per decision, or 5M output tokens at $0.12/M, for $0.60. Total: about $180.60.

• Granite 4.2 3B in thinking mode — 6B input at $180, plus perhaps 800 reasoning tokens per decision, or 800M output tokens at $0.12/M, for $96. Total: about $276.

• SubQ Snap 1.1 — 6B input tokens at $0.04/M is $240, and there is no output line at all.

So the honest answer is three different answers. Configured to answer directly, Granite is 25% cheaper than Snap and the article really would end there. Configured to think, Granite is 15% more expensive than Snap, because reasoning tokens are the most expensive thing in the pipeline and nobody budgets for them. Snap's advantage was never its input rate — it is 33% higher than Granite's — it is that the architecture has no way to spend tokens on deliberation.

That is not a theoretical risk. Artificial Analysis's independent profile of Granite 4.2 3B calls the model "very verbose" and records that it generated 92 million output tokens while being evaluated on the Intelligence Index, against a median of 67 million for comparable models. The verbosity is a measured property of the model in reasoning mode, and it is the property that decides whether the per-token price advantage survives contact with a routing workload.

That also explains a number that looks wrong at first glance. Artificial Analysis frames Snap 1.1 at roughly $30 per million tasks, against $8.4 for Elephant 9B. Thirty dollars per million tasks implies a very short average task, on the order of a few thousand tokens. The Decision Index's benchmark mix is short. Your tickets, contracts and logs are not, and the cost scales linearly with input length from there. Treat per-task figures as a property of the benchmark, not a quote.

Where the 3B genuinely wins

Cheaper tokens are the least of it. Granite 4.2 3B can be self-hosted under Apache 2.0, which means no per-call cost at all once the hardware is paid for, no data leaving your network, no rate limit, and no vendor that can change the price or the model under you. For a compliance-bound workflow this is not a preference, it is a requirement, and Snap 1.1 simply cannot enter that room.

It also does more. It writes the summary after the routing decision. It handles tool calls with a schema. It supports an opt-in context extension to 512K, added in a fifth pre-training phase, which is longer than Snap's 384K on paper — though its RULER score falling from 67.52 at 64K to 55.30 at 128K is a fair warning about how much of that window is usable. And it is small enough to run at the edge, in a container next to your application, with no network hop between the decision and the action.

Where Snap 1.1 genuinely wins

Three things that a 3B generative model is bad at by construction.

Calibration is the first. Snap 1.1 reports an expected calibration error of 0.014, down from 0.108 in the preview, and an abstention rate of 86% on questions it cannot answer — against a 0.7% non-hallucination score for its own 1.0 release on the vendor's proxy. Those are vendor numbers and should be read as such, but they describe a model trained with abstention as an explicit objective. A 3B reasoning model has no such target. Ask it whether a ticket is answerable and it will produce a plausible sentence either way.

Long-context single-pass behaviour is the second. Snap processes 384K tokens in one forward pass with constant compute per token, which is the entire justification for Subquadratic Sparse Attention. Granite's RULER decay is the normal behaviour of a dense model at ten times its comfortable length. If your decision depends on something buried at position 200,000 in a log bundle, the architectural difference is not academic.

Determinism of output shape is the third, and it is underrated. Snap returns a number over your option list. Granite returns text that you then parse, and every parser is a place where a malformed answer becomes an outage. Constrained decoding closes most of that gap, which is worth saying — it is not a fundamental advantage, it is a difference in how much scaffolding you write.

The configuration question nobody asks

If you are running Granite 4.2 3B as a router, the single most valuable change you can make is turning thinking off. IBM ships that mode for exactly this reason, and the arithmetic above shows why: a reasoning model asked to pick one of five labels will often spend eight hundred tokens justifying a decision that a non-thinking pass gets right. Benchmark the two modes on your own data before assuming the thinking one is better. On a task with a fixed answer set, it frequently isn't.

Snap's equivalent lever is the opposite: you give it fewer, sharper options. Its API caps questions at sixteen and alternatives at 255 per question, and its accuracy on the Decision Index is 20% — lower than d1-ultra's 32% — with the index score carried by abstention. Narrow the answer set and the accuracy problem shrinks; hand it an open-ended judgement and it will decline, correctly, and often.

What I would actually build

For a support or document pipeline at meaningful volume, the cheapest defensible design is a two-stage one. Granite 4.2 3B runs in non-thinking mode as the first-pass classifier on the easy majority — the tickets that are obviously refund, obviously outage, obviously spam — where a 3B model is accurate and costs nothing at the margin. Snap 1.1 handles the residue: the long threads, the ambiguous cases, the ones where the right answer might be "escalate" and a confident guess is worse than a refusal. You pay $0.04 a million tokens only on the fraction that needs it, and you get a calibrated probability on exactly the decisions where calibration matters.

Neither vendor sells that design, because each one wants to be the whole layer. Granite 4.2 3B is not in OrcaRouter's catalogue — it is Apache 2.0, so self-hosting is the normal route, and it is also carried by a number of inference providers. Snap 1.1 is not ours either; it runs through Subquadratic's own API. What OrcaRouter contributes to a design like this is the generation tier behind it: 200+ models behind one key, provider list price passed through at 0% markup, and automatic failover, so the model that writes the escalation summary is not the same dependency as the model that decides to escalate.

The thing to watch is whether Snap 1.1's calibration holds when someone else runs it. Its 20% accuracy is the weakest number in its own launch material, and it is the one that decides whether the two-stage design above is cheaper than it looks — the more often Snap abstains, the more work falls back to the stage that has to actually answer.