SINGAPORE, 29 AUG 2026 — IBM has released Granite 4.2 in three sizes — 3B, 8B and 30B parameters — with the weights published under Apache 2.0. That licence, not the benchmark score, is the thing worth reading first.
Apache 2.0 means an organisation can download the weights, fine-tune them, deploy them commercially and never speak to IBM about it.
What was released
The three models arrived on 25 August. IBM describes the family as having native step-by-step reasoning that lets the models plan before acting, weigh trade-offs and catch their own mistakes, and says training used multi-stage reinforcement learning: a foundational stage across mathematics, science, coding, reasoning and tool calling, a specialised agentic stage aimed at enterprise tasks, and reinforcement learning from human feedback for alignment.
The larger two sizes were additionally trained inside real software-engineering, terminal and web-search environments rather than on transcripts of such work. Secondary reporting puts the 30B model at 57.00 on SWE-bench Verified.
Distribution is through Hugging Face, GitHub and Ollama, which for a locally deployable model matters more than any launch partner announcement.
The context window is being reported inconsistently
One specification matters here, because it is the kind of number applications are designed around. Secondary coverage of this release variously puts the context window at 128,000 tokens and at 512,000 tokens.
IBM's own announcement does not state it. That is a four-fold discrepancy in a figure that determines whether a document-processing workload fits in a single call, and anybody sizing an application against it should read the model card rather than the coverage.
A blog post is not a specification sheet, so this is not an accusation of vagueness. The caution is that the number now circulating has two values and no primary source behind either.
Read the benchmark against what you can deploy
A SWE-bench Verified score of 57.00 is not a frontier result, and comparing it to a hosted frontier model is the wrong comparison to make.
Anyone considering this model should compare it against the others they can run on their own hardware, under a licence with no field-of-use restriction, with no data leaving their network. Against that set, a 30B open-weight model resolving a majority of a verified software-engineering benchmark is a capability that did not exist at this parameter count eighteen months ago.
The comparison also has to price the alternative honestly. A hosted frontier model scores higher and bills per token, sends your code to a third party, and can change its behaviour, its price or its availability without your consent. Those are not equivalent products being ranked on one axis.
The score itself carries the usual caveat, which is that it comes from secondary reporting rather than from IBM's announcement, and that benchmark figures published by a model's own vendor deserve the scepticism we applied when Alibaba published Qwen3.8-Max's benchmarks and every one of them was Alibaba's.
Training in the environment, not on transcripts
The detail most likely to matter over the next year is buried in the training description, and it is the difference between learning from recordings of work and learning by doing it.
A model trained on transcripts of terminal sessions learns what a correct-looking command sequence resembles. A model trained inside a terminal receives the actual exit code, the actual error, the actual state of the filesystem after it acts, and is rewarded on whether the task completed. The second approach produces a model that recovers from its own mistakes, because mistake recovery is what the training rewarded.
The agentic framing here is therefore more than a label. It also explains why only the 8B and 30B got this treatment: running reinforcement learning inside live environments is expensive in compute and slow in wall-clock time, since every step waits on a real program to execute.
Anyone evaluating the model should look for the difference in multi-step tasks and in failure recovery, not in single-turn question answering. Most informal testing uses single-turn queries, where this model will probably look unremarkable.
Where this sits in IBM's strategy
IBM is doing two apparently contradictory things at once, and they are not actually in tension.
It gives away competent open-weight models under a permissive licence, and separately it sells OpenAI's models through its consultants. The first builds a base of enterprises running IBM-origin models inside their own infrastructure. The second serves customers who want the frontier and will pay for it.
The predecessor release made the same argument more narrowly. Granite 4.1 matched 32B models at 8B parameters, which was a claim about cost per unit of capability rather than about capability itself. Granite 4.2 extends that into agentic work, which is where the enterprise budget currently is.
Neither line is charity. A consulting business benefits from a large installed base of models it understands intimately, and IBM's revenue from this release will arrive as services rather than as licence fees.
Why the licence matters in this region
For organisations in Southeast Asia, the Apache 2.0 terms carry specific advantages that other permissive-sounding licences lack.
It carries no field-of-use restriction, no acceptable-use policy enforceable by the licensor, no revenue or user threshold above which terms change, and an explicit patent grant. Several widely used open-weight releases carry at least one of those constraints, and a compliance function reviewing an AI deployment will find them.
That matters most where data cannot leave the jurisdiction: regulated financial institutions, healthcare providers and government agencies operating under residency requirements. For those buyers the question was never whether a hosted model scores higher. It was whether any capable model was permitted at all, and the list keeps growing — as it did when Meta open-weighted a model under the same licence.