IBM Granite 4.2 ships with a thinking switch: 57.00 on SWE-Bench Verified at 30B, all three sizes Apache 2.0

IBM released Granite 4.2 on August 25, 2026 in three sizes, 3B, 8B and 30B, all published on Hugging Face under the Apache 2.0 license. All three were trained from scratch on approximately 15 trillion tokens and ship with a thinking / non-thinking switch plus a low-effort thinking mode that spends a short reasoning budget on easy questions. In IBM's own numbers the 30B scores 57.00 on SWE-Bench Verified, 89.17 on AIME25 and 77.60 on MMLU-Pro, and the family supports 12 languages including Korean. ASAP summarizes what changed in this release and how to read the scores, using the IBM Granite team's Hugging Face technical write-up as the primary source.

The three sizes, the license, and what you actually download

Granite 4.2 consists of granite-4.2-3b, granite-4.2-8b and granite-4.2-30b, released on Hugging Face under Apache 2.0. The architecture is a decoder-only dense transformer combining grouped query attention with 40 attention heads and 8 KV heads, rotary position embedding, SwiGLU activation in the MLP layers, RMSNorm normalization and bfloat16 precision.

Context length comes as two separate numbers worth keeping apart. IBM describes extending the context window to 512K tokens during pre-training phase 5, while the released models carry a sequence length of 131,072 tokens. For deployment purposes the second number is the one that matters. FP8, FP4 and GGUF quantized variants ship alongside, so the family arrives in a form that can go straight onto a self-hosted server or a laptop.

The supported languages are English, German, Spanish, French, Japanese, Portuguese, Arabic, Czech, Italian, Korean, Dutch and Chinese. Tool calling is supported natively in an OpenAI-compatible function-calling format.

Why the thinking switch has three positions rather than two

Reasoning control in Granite 4.2 has 3 settings rather than a binary toggle, and all 3 ship in every size from 3B to 30B. Thinking mode answers with an explicit chain of thought, non-thinking mode answers directly, and low-effort thinking spends only a short reasoning budget on easy questions.

That arrangement targets a problem familiar to anyone who has put a reasoning model into production. Turning thinking on raises accuracy on hard problems but attaches the same cost to trivial questions, inflating both latency and token spend. Teams routinely respond by building a routing layer that classifies difficulty first and dispatches to different models or modes. Putting an intermediate setting inside the model moves part of that routing job into the model itself.

The switch widens the routing menu rather than removing the need for routing. Deciding which questions deserve low effort still belongs to the caller, and a badly calibrated threshold means hard questions get short budgets and lose accuracy for nothing. Three settings only pay off once difficulty classification is itself accurate.

What it means that agentic RL starts at 8B

Post-training for Granite 4.2 runs supervised fine-tuning followed by multi-stage reinforcement learning, and the agentic RL stage applies only to the 8B and 30B models. Supervised fine-tuning used roughly 7.2 million samples, about 100 billion tokens, split 31.6 percent agentic and 68.4 percent non-agentic. The RL curriculum is built on asynchronous GRPO: a foundational stage with verifiable rewards across math, coding, STEM and tool calling, skill boosters for instruction following and code, an agentic stage covering SWE agent work, terminal operations and web search in real sandboxed environments, and a final RLHF alignment pass.

The signal a practitioner should take from this is a sizing rule. The 3B received foundational RL and RLHF but never trained by acting with tools in a real environment. The blank cells in its SWE-Bench and Terminal-Bench 2.1 rows read the same way. The 3B is a model for summarization, classification and short responses, not a place to mount a long-horizon agent.

Read the other direction, the 30B scoring 57.00 on SWE-Bench Verified, 41.89 on SWE Bench Multilingual, 33.29 on SWE Bench Pro and 29.24 on Terminal-Bench 2.1 means the family has exactly one candidate for agentic workloads. The 8B sits at 47.67, 30.78, 19.11 and 20.56 respectively, a substantial distance back.

Bigger does not win everywhere

The most instructive part of the Granite 4.2 benchmark table is not the top score but the two places where size order inverts. On the tool-calling benchmark BFCL v4 the 3B scores 52.41 against the 8B's 50.29, and on instruction following the 8B scores 79.33 on IFBench against the 30B's 77.17.

Those two inversions are concrete grounds for not picking a model by size alone. A pipeline that does nothing but repeated tool calls has a reason to evaluate the 3B instead of the 8B, and a document workflow where format compliance decides the outcome may be better served by the 8B than the 30B. Even inside a vendor's own table, the optimal size varies by task.

Multilingual results move in the opposite direction, with one large step. On MMLU-ProX lite the 3B scores 27.78 while the 8B jumps to 61.06. Korean appearing on the supported-language list is therefore a different claim from the 3B being usable on Korean tasks, and for non-English work the 8B is effectively the floor.

Long context deserves the same reading. RULER 64K gives 67.52, 80.99 and 89.96 across 3B, 8B and 30B, and extending to 128K drops those to 55.30, 71.41 and 81.38. Accepting 131,072 tokens and holding accuracy at that length are separate properties.

One entry needs care. GDPval is listed as 1189.00 for the 8B and 1225.00 for the 30B, on a scale unlike the percentage metrics beside it, so it cannot be read on the same axis. Lifting that number out of the table without its context invites misreading.

Where this lands for teams that must self-host

Apache 2.0, 12 languages including Korean, and a size range running from 3B to 30B together widen the menu for organizations that cannot send data out. In healthcare, finance and the public sector, where self-hosting is effectively mandatory, license terms matter as much as capability, and Apache 2.0 requires no separate negotiation for commercial deployment or derivative models.

Practical deployments split in two. High-volume short-input work such as internal document search, classification and summarization fits a 3B or 8B with an FP8 or GGUF build. Agentic work involving code edits, terminal operations and multi-step tool calls leaves the 30B as the only real candidate, which moves the required hardware class up a tier.

For Korean-language services the safer move is to invert the usual evaluation order. Rather than sizing from the English-based numbers in a vendor table, run an in-house Korean evaluation set first and measure the 3B-to-8B gap directly. The 33.28-point spread on MMLU-ProX lite is reason enough not to skip that step.

What has not been established yet

IBM's write-up contains no head-to-head comparison against Claude, GPT or Llama. Every value in the table is self-reported, and agentic benchmarks in particular shift substantially depending on the harness they were run in. Until an independent party reproduces these numbers under the same conditions, there is no basis for asserting a competitive ranking.

Training data is described mainly in terms of volume and stage count. The roughly 15 trillion tokens and the five-phase strategy are stated, but publishing weights under Apache 2.0 is not the same as publishing the training corpus. In regulated industries where data provenance must be verified, that distinction is what actually stalls an adoption review.

The open question is the cost curve of the thinking modes. How many tokens each of the three settings consumes, and at what difficulty the trade-off flips, cannot be derived from the published table. For a team evaluating adoption, measuring average output tokens and accuracy across all three modes on its own workload is the right first experiment.

Source: IBM Granite team, "Granite 4.2 LLMs: How They're Built" (Hugging Face blog, August 25, 2026). Summarized by ASAP.