IBM Granite 4.2 and the Open Reasoning Model Wave of 2026

IBM released Granite 4.2 on August 25, 2026, and the release marks a quiet but meaningful shift in the open-weights race. For the first time, the Granite family is not instruction-tuned. It is reasoning-native. Every checkpoint emits a chain of thought before it answers, exposes a thinking and non-thinking switch, and ships under Apache 2.0 with no licensing gate. For the 8 billion and 30 billion parameter sizes, IBM also pushed the training past conventional supervised fine-tuning and into a multi-stage reinforcement learning chain where the model learns to edit code, drive a terminal, and run web searches inside real sandboxes.

The release lands as the open-weights field has stopped chasing closed frontier labs on chat quality and started competing on something narrower and more enterprise-shaped: reliable tool use, software engineering, and reasoning that holds up under real workloads. Granite 4.2 is IBM’s argument that a dense, well-trained, openly licensed model can join that conversation without resorting to a mixture-of-experts scale.

This guide explains what Granite 4.2 is, how IBM’s training pipeline differs from the previous generation, what the benchmarks actually show, and where Granite 4.2 sits in the 2026 open-weights reasoning field alongside DeepSeek V4, Qwen 3.6, GLM 5.2, Llama 4, and others.

What IBM Actually Released on August 25, 2026

Granite 4.2 is a family of three dense, decoder-only language models at 3 billion, 8 billion, and 30 billion parameters, plus two 470 million parameter speech models under the Granite Speech 5.0 Turbo CTC banner. All three language models are released under Apache 2.0, with weights on Hugging Face, GitHub, and Ollama, and quantized GGUF variants down to Q4_K_M for local serving.

Three things separate this release from earlier Granite versions:

• Reasoning is native, not bolted on. Every model can emit a chain of thought before answering. The chat template exposes a thinking mode, a non-thinking mode, and a low-effort mode that spends a short reasoning budget on easy questions.
• The 8B and 30B go through an agentic RL block. The 3B does not. That single design choice explains most of the capability gap across the three sizes, and it is the most important thing to know before picking a checkpoint for a coding agent or terminal automation task.
• Tool calling is built in, in the OpenAI function-calling format. Served through vLLM or SGLang, the model emits structured tool calls without extra glue and drops into existing agentic harnesses such as OpenHands, OpenCode, and Terminus-2.

IBM published a high-level release post on the IBM Research blog and a full technical breakdown on Hugging Face. The Hugging Face post is the canonical source for architecture, training, and the staged reinforcement learning curriculum. All three sizes are deployable: the 3B fits a laptop through Ollama or LM Studio, the 8B fits a single modern GPU, and the 30B fits enterprise on-prem or FP8 and NVFP4 serving through vLLM.

Native Reasoning vs. Instruction Tuning: What Changed From Granite 4.1 to 4.2

The earlier IBM Granite 4.1 release was an instruction-following family. It was strong on chat, function calling, and structured extraction, and it competed on parameter efficiency by showing that a dense 8B model could match a 32B mixture-of-experts predecessor. Granite 4.1 did not reason explicitly. It could not emit a chain of thought, and its training pipeline ended at supervised fine-tuning plus a four-stage reinforcement learning pass that focused on helpfulness and math.

Granite 4.2 changes that model in three concrete ways.

Reasoning is the default behavior, not an optional prompt trick

Every Granite 4.2 checkpoint can spend compute on chain of thought before producing a final answer. Operators choose how much reasoning to allow at request time by toggling the chat template. The three modes are:

• Thinking: the model spends a full reasoning budget on every prompt.
• Non-thinking: the model answers directly, matching the latency profile of a standard instruction-tuned assistant.
• Low-effort thinking: the model spends a short reasoning budget tuned for easy questions, which trades a small amount of accuracy for measurable latency gains on high-volume traffic.

This is the same pattern OpenAI popularized with its o-series models, where reasoning effort is exposed as a parameter the application can control. The difference is that Granite 4.2 ships the behavior at the open-weights level, so a team can self-host the same switch without routing traffic through a closed API.

Tool calling is native, in a standard schema

Earlier Granite models supported function calling, but the workflow required glue code. Granite 4.2 emits tool calls in the OpenAI function-calling format and serves through vLLM with the –tool-call-parser granite flag, so any OpenAI-compatible client can point at the endpoint without modification.

The training pipeline ends with agentic RL, not alignment

This is the biggest change. Granite 4.2’s post-training is a multi-stage, multi-environment reinforcement learning chain. After the standard SFT pass, every model goes through foundational RL, which covers math, science, coding, reasoning, instruction following, and tool calling. The 8B and 30B continue into a separate agentic RL block that targets software engineering, terminal use, and web search inside real sandboxes. Every model finishes with RLHF alignment.

The 3B stops after foundational RL and alignment. That shortcut is what creates the steep capability cliff between 3B and 8B on agentic benchmarks, and it is the most important detail for any team choosing a checkpoint by parameter count rather than by measured behavior.

The Multi-Stage Agentic RL Pipeline: How the 8B and 30B Learn to Act in Sandboxes

The training pipeline is where Granite 4.2 diverges from most open-weights competition, and it is the part that deserves a careful read. The full chain, applied to the 30B, runs in this order:

1. Supervised fine-tuning on roughly 7.2 million samples, about 100 billion tokens with 65 billion trainable.
2. RLVR (verifiable-reward RL) across math, competitive coding, science, instruction following, tool use, and reasoning puzzles.
3. Skill boosters that graft on narrow capabilities: instruction-following booster, code booster.
4. SWE stage 1, a software engineering RL block at 128K context with single-turn rollouts.
5. SWE stage 2, multi-turn software engineering rollouts in a sandbox, with up to 128 environment turns per rollout.
6. Terminal, a multi-turn RL block targeting terminal use at 64K context, with up to 64 environment turns per rollout.
7. Search, a multi-turn RL block targeting web search and retrieval, also with 64-turn rollouts at 128K context.
8. RLHF, final alignment with a preference signal.

Each stage is an independent asynchronous GRPO run that warm-starts from the previous checkpoint. A pool of generation workers keeps sampling trajectories and dropping them into a shared buffer; the trainer pulls a full step’s worth, takes an optimizer step, and streams the updated weights back without pausing the generators. This is the same asynchronous GRPO pattern The Landscape of Agentic Reinforcement Learning for LLMs survey documents as a default for serious agentic RL work in 2026.

Two design choices are worth highlighting. First, advantages are computed with a leave-one-out baseline rather than a value network, which removes a class of training instability that plagues long-horizon agentic RL. Second, the pipeline uses truncated importance sampling to clamp the train-versus-generation log-probability ratio, which keeps a single stale token from dominating an update when an asynchronous refresh lands mid-rollout.

How the agentic data was built

The agentic corpus that feeds SFT and the agentic RL block was generated across a long list of harnesses: OpenHands, OpenCode, Terminus-2, SWE-agent, OpenResearcher, MiniSWE, OpenSeeker, EnvScaler, Gemini CLI, Hermes, Codex, and Goose. Software engineering dominates the agentic mix at 69 percent, with tool calling at 12.1 percent, terminal use at 8.0 percent, math at 3.5 percent, search at 0.8 percent, and action at 0.2 percent.

IBM also added 1 trillion tokens of synthetic code generated by an internal pipeline called CodeAlchemy, which feeds both pre-training and the agentic stages. Quality control ran GPT-OSS-120B and Gemma 4 as LLM judges to filter out hallucinated tool calls, invalid schemas, and other noise, with SHA-256 deduplication across the tools and messages fields. The point is not that any single technique is novel, but that the pipeline combines them into a single coherent post-training chain rather than a one-shot RL pass.

Why the 3B was excluded from agentic RL

IBM does not explain the choice in detail, but the practical reason is clear: a 3B model does not have enough headroom to learn the multi-turn tool-calling trajectories that the agentic block demands, and the same compute budget gets better returns when concentrated on the 8B and 30B. The 3B is still reasoning-native and still benefits from the foundational RL and alignment stages, but it stops short of the agentic block. That decision shows up clearly in the benchmark table below: The 3B has no score at all on SWE-Bench Verified or Terminal-Bench 2.1, because it was never trained to use the harness.

Granite 4.2 Benchmarks: 57.00 on SWE-Bench Verified, and How That Compares

The benchmark numbers IBM published for Granite 4.2 are the cleanest way to understand what each size can actually do. The full table, by model size:

Three patterns stand out.

First, the 30B reaches 57.00 on SWE-Bench Verified and 29.24 on Terminal-Bench 2.1, both of which are measured against real GitHub issues and real terminal workflows rather than synthetic code completion. For a 30B open-weights model, that is a competitive result. A comparable coding agent built around a closed model at similar capability would normally require a much larger deployment or a routed API call.

Second, the gap between 8B and 30B on agentic benchmarks is smaller than the gap between 3B and 8B. The 8B reaches 47.67 on SWE-Bench Verified, which is enough to be useful for real coding agent work. The 3B does not have a score at all. For teams that need agentic behavior on a single GPU, the 8B is the smallest checkpoint worth considering, and the 30B is the one worth considering if you have A100 or H100 class capacity.

Third, on reasoning benchmarks like AIME25, GPQA, and MMLU-Pro, the 30B is strong but not category-defining. DeepSeek V4, Qwen 3.6, and GLM 5.2 all post higher absolute scores at the 100B-plus parameter scale. Where Granite 4.2 wins is the open-license, dense-architecture, agentic-RL intersection, not raw reasoning capacity at any size.

Architecture and the Thinking Switch: Three Modes for Three Use Cases

Granite 4.2 is a decoder-only dense transformer, not a mixture-of-experts design. The architecture components are the same across the three sizes: Grouped Query Attention with 8 KV heads, RoPE position embeddings with theta set to 10,000,000 for long-context stability, SwiGLU MLPs, RMSNorm with epsilon 1e-5, untied input and output embeddings, and bfloat16 precision.

What changes is depth and width:

• 3B: 40 layers, embedding size 2560, attention head size 64, MLP hidden size 8192.
• 8B: 40 layers, embedding size 4096, attention head size 128, MLP hidden size 12800.
• 30B: 64 layers, embedding size 4096, attention head size 128, MLP hidden size 32768.

The published sequence length is 131,072 tokens, but the pre-training run includes a long-context phase that extends the trained context to 512K tokens. As with any long-context claim, the served context is shorter than the trained context in practice, and the RULER 128K scores above are the best single number for how well the model actually uses the upper end of its window.

Pre-training in five phases

Pre-training ran on roughly 15 trillion tokens through a five-phase strategy. Phases 1 and 2 are foundational pre-training, phases 3 and 4 perform mid-training with progressively higher-quality data annealing, and phase 5 extends the context window to 512K tokens. Each phase uses a different data mixture and a different learning-rate schedule, with the corpus gradually shifting from broad web data toward curated high-quality sources.

The pre-training recipe is similar to the previous generation. For a detailed treatment of the data blend, phase schedule, and long-context extension, IBM points to the Granite 4.1 blog as the canonical reference, which keeps the 4.2 release focused on what changed: reasoning and the agentic RL block.

Quantization and serving

IBM shipped FP8 weights without calibration, FP4 weights (NVFP4) for vLLM serving, and GGUF quants down to Q4_K_M for local serving through Ollama or LM Studio. A speculative decoding layer sits on top of the dense transformer, which gives the 30B a faster per-token output rate without changing the model behavior. The combination of FP4 serving on H100 or H200 hardware and speculative decoding is what makes the 30B tractable as a production deployment rather than just a benchmark curiosity.

Granite Speech 5.0 Turbo CTC: The 470M-Parameter Sidekick for Edge ASR

Alongside the language models, IBM released two speech-to-text models under the Granite Speech 5.0 Turbo CTC banner. Both come in at 470 million parameters and drop the LLM backbone entirely, using connectionist temporal classification to map audio to text. The result is a speech model small enough to run on a laptop or a smartphone, with throughput high enough for real-time transcription of long recordings.

The published RTFx score, which measures how many seconds of audio a model can transcribe per second of wall-clock time, is around 12,600 on a single H200 GPU. The current speed leaders on the Hugging Face Open ASR leaderboard post RTFx scores around 6,000, which puts Granite Speech 5.0 Turbo CTC roughly twice as fast as the previous speed leaders in IBM’s testing.

Two variants ship. The standard model is trained on the full data mix. The NC, or non-commercial, variant is trained on restricted-use data and is intended for research use cases where the data license is the binding constraint. The practical use case is high-volume transcription for call centers, video chat, and any pipeline that needs to convert voice to text in real time at low cost.

IBM also published a WebGPU demo that runs the speech model in the browser, which is the easiest way to evaluate the latency profile without setting up a serving stack. A live demo of the new Granite Speech models is available on Hugging Face.

Where Granite 4.2 Fits in the 2026 Open-Weights Reasoning Field

The 2026 open-weights field is crowded enough that any new release has to be positioned by what it can do that the rest of the field cannot. The relevant competitors in mid-2026, sorted by what they optimize for, look roughly like this:

• DeepSeek V4 Pro. 1.6 trillion total parameters, 49 billion active, MIT license, 1M-token context. The efficiency bet, with strong coding and reasoning at a competitive deployment cost.
• Qwen 3.6 and 3.8. Apache 2.0 across most checkpoints, with sizes ranging from a single-GPU 27B up to 2.4T-A95B. The range bet, with the broadest selection of deployable sizes in the open field.
• GLM 5.2 from Z.ai. 754 billion parameters, MIT license, built for long-horizon coding and agentic reasoning. The long-horizon coding bet, currently the default answer for teams that want MIT-licensed frontier coding performance.
• Kimi K3 from Moonshot AI. 2.8 trillion total, 104 billion active, custom Kimi K3 license, 1M-token context. The maximum-capability bet, with a non-standard license that limits where the weights can be deployed.
• Llama 4 from Meta. The Western default, with the deepest ecosystem and the most consequential EU license caveat for European deployments.
• gpt-oss from OpenAI. OpenAI’s own open-weights reasoning model, with a permissive license and a tool-use story that targets the same agentic workloads Granite 4.2 addresses. Google’s August 31 release of TimesFM-3, a 330M-parameter time-series foundation model, lands the same week as Granite 4.2 and extends the foundation-model race beyond text into forecasting. The release takes the top average rank on GIFT-Eval, FEV-Bench, and TIME, but it also gates its pretrained weights under a non-commercial license, marking a step back from the Apache 2.0 open-weights baseline IBM is preserving with Granite 4.2.

Where Granite 4.2 earns its place is at the intersection of three constraints that few competitors meet simultaneously: a fully permissive Apache 2.0 license, a dense architecture that runs predictably on a single modern GPU at the 8B size, and an agentic RL training block that targets real sandboxes rather than synthetic tool-use traces. For regulated industries that need on-prem weights, dev tools teams that need a single-GPU 8B agent, and enterprise platform teams that need to ship without a closed-API dependency, Granite 4.2 is the first release in 2026 that ticks all three boxes in the same family.

It is not the largest open-weights model, and it is not the cheapest to serve at 30B.

It is, however, the cleanest answer to a question many enterprise teams are asking in 2026: which open-weights reasoning model can I run on-prem, with predictable latency, that will reliably drive a coding agent or a terminal automation pipeline without sending my code to a closed provider?

Deployment, Licensing, and Who Should Use Which Size

The deployment story is part of the design. All three language models ship under Apache 2.0, which means a team can download the weights, fine-tune them, and put them into production without negotiating a separate license. The two speech models ship under the same license, with the NC variant under a non-commercial license for research use.

Practical sizing guidance for teams picking a checkpoint:

• Solo developers and small teams: the 3B fits comfortably on a laptop through Ollama or LM Studio, especially with the Q4_K_M GGUF quant. Use it for chat, summarization, and reasoning at a low token budget. Skip it for any task that requires multi-turn tool use.
• Mid-market teams on a single modern GPU: the 8B is the smallest checkpoint that goes through the full agentic RL block, which makes it the right pick for a coding agent or terminal automation pipeline on a single H100 or A100. At FP8 it fits in roughly 16 GB of VRAM, leaving room for a long context and a serving framework.
• Enterprises with A100 or H100 class capacity: the 30B is the flagship. Serve it on FP8 or NVFP4 through vLLM, with speculative decoding on top to keep the per-token output rate competitive with closed models. On-prem deployment is the main reason to pick the 30B over a closed API for a regulated workload.

The companion Granite Speech 5.0 Turbo CTC models fit a different use case. The 470M CTC models handle high-volume transcription for contact centers, video chat, and any pipeline that needs to convert voice to text in real time at low cost. They are not general-purpose speech models, and they are not designed to be paired with the language models in a single multimodal pipeline. They are designed to do one thing, which is convert audio to text fast, and they do it well.

Frequently Asked Questions

Is IBM Granite 4.2 open source or just open weights?

Granite 4.2 is released under Apache 2.0, which is a permissive open-source license. The model weights, the chat template, and the serving recipes are all available. What is not open is the full training data, which is the same posture most open-weights labs take in 2026. For teams that need an OSI-style open source license for the training data as well as the weights, Granite 4.2 does not meet that bar, and the gap between open weights and fully open source is real.

How does Granite 4.2 compare to OpenAI’s o-series reasoning models?

Granite 4.2 exposes the same pattern of controllable reasoning effort that OpenAI popularized with its o-series, with a thinking, non-thinking, and low-effort mode that operators toggle at request time. The difference is the deployment model. The o-series runs as a closed API; Granite 4.2 ships as open weights that a team can self-host, fine-tune, and integrate into a private deployment. On raw reasoning benchmarks, the closed o-series models still post higher absolute scores. On agentic coding and tool use at the open-weights scale, Granite 4.2’s 30B is competitive with similarly sized open-weights models that target the same workload.

Can the 3B model run coding agents?

Not reliably. The 3B was excluded from the agentic RL block, so it was never trained to use the agentic harnesses that SWE-Bench Verified, Terminal-Bench 2.1, and tau3-bench test against. For coding agent or terminal automation work, the 8B is the smallest checkpoint in the family that is worth considering, and the 30B is the right pick if you have A100 or H100 class capacity.

What is the difference between SWE-Bench Verified and SWE-Bench Pro?

SWE-Bench Verified is a curated subset of SWE-Bench where every issue has been manually checked to be solvable from the information present in the issue text. SWE-Bench Pro is a harder variant that requires resolving issues across multiple repositories with longer context dependencies. Granite 4.2’s 57.00 score is on SWE-Bench Verified. Most 2026 open-weights leaders also report on SWE-Bench Pro, and the gap between the two benchmarks is meaningful for any team that needs a coding agent to handle real production repositories rather than single-file patches.

How is the multi-stage RL pipeline different from a one-shot RL pass?

A one-shot RL pass trains a single reward signal across the entire training distribution, which tends to favor whichever signal is loudest. A multi-stage pipeline like Granite 4.2’s trains separate stages for separate capabilities: verifiable-reward RL for math and science, skill boosters for narrow capabilities, then a dedicated agentic RL block for software engineering, terminal use, and web search, then RLHF for final alignment. Each stage warm-starts from the previous checkpoint, which lets the later stages build on the earlier ones without the earlier stages being eroded by the later ones. The result is a model that is strong on a wider set of behaviors than a single-stage pipeline typically produces.

Conclusion

Granite 4.2 is the first open-weights reasoning model family from IBM and the first to ship native chain-of-thought, a thinking switch, and a multi-stage agentic RL training block as a single coherent release. The 30B at 57.00 on SWE-Bench Verified is a competitive result for the open-weights scale, and the 8B at 47.67 is enough to run a real coding agent on a single modern GPU. The 3B is reasoning-native but stops short of the agentic block, which makes it the right pick for chat and summarization rather than coding agent work.

The release lands at a moment when the open-weights field has stopped competing on chat quality and started competing on reliable tool use and software engineering performance. For teams that need a permissive Apache 2.0 license, a dense architecture that runs predictably, and a training pipeline that targets real sandboxes rather than synthetic traces, Granite 4.2 is the cleanest answer available in mid-2026. The next moves to watch are whether the 3B gets a lightweight agentic training block in a future release and whether the RL pipeline’s leave-one-out baseline and truncated importance sampling become a template other open-weights labs adopt for their own agentic RL work.

For an earlier look at how IBM approached dense 8B parameter efficiency without explicit reasoning, the Granite 4.1 release coverage covers the parameter scaling and MoE tradeoff that Granite 4.2 inherits and extends. In the sub-4B open-weights space, OpenBMB’s MiniCPM5-2B now sets the pace, scoring 13 on the Artificial Analysis Intelligence Index with only 2.6 billion parameters while matching models four times its size.