IBM introduces Granite 4.2, a new family of language models focused on reasoning, tool use, and task execution in real-world environments. The series includes versions with 3 billion, 8 billion, and 30 billion parameters, all released under the Apache 2.0 license.
What changes compared with a traditional assistant? Granite 4.2 can think before responding, work in fast or deliberative mode, and make native tool calls. In the 8B and 30B models, IBM also trained agents capable of editing code, using a terminal, and searching for information on the web.
Three models with the same foundation
Granite 4.2 uses a dense, decoder-only transformer architecture. In simple terms, each model generates text autoregressively, predicting the next token based on the previous context.
The three sizes share the same core design, although their depth and capacity vary:
- Granite 4.2 3B: 40 layers, 2,560-dimensional embeddings, and approximately 3 billion parameters.
- Granite 4.2 8B: 40 layers, 4,096-dimensional embeddings, and approximately 8 billion parameters.
- Granite 4.2 30B: 64 layers, 4,096-dimensional embeddings, and approximately 30 billion parameters.
The architecture incorporates Grouped Query Attention, or GQA, with 8 heads for keys and values. This technique reduces memory consumption during inference without completely removing the model’s attention capabilities.
It also uses RoPE for positional representation, SwiGLU activations in the feed-forward network, RMSNorm to stabilize training, and bfloat16 precision. The base sequence length is 131,072 tokens, although long-context training expands the capacity to 512,000 tokens.
A 512K-token context makes it possible to work with code repositories, lengthy documents, or large conversation histories without splitting them into so many fragments.
How IBM trained Granite 4.2
IBM trained the models from scratch with approximately 15 trillion tokens. The pretraining process was organized into five phases instead of using a single data mixture throughout the entire process.
The first two phases focus on acquiring general knowledge. Phases three and four progressively increase the proportion of higher-quality data. The fifth phase introduces long-context training and extends the window to 512K tokens.
This strategy allows the model not only to learn information, but also to gradually adapt to more carefully selected data and tasks that require handling very long inputs.
After pretraining came supervised fine-tuning, known as SFT. IBM used around 7.2 million samples, equivalent to roughly 100 billion tokens, of which approximately 65 billion tokens were used directly to train the model.
The mixture included 31.6% agentic data and 68.4% non-agentic data. Agentic tasks included software engineering, tool calls, terminal use, mathematics, search, and action execution.
Non-agentic data covered instruction following, programming, mathematics, languages, science, reasoning, and safety. Before entering the final mixture, IBM normalized the formats, removed duplicates, and used models such as GPT-OSS-120B and Gemma 4 to evaluate sample quality.
Examples containing invented information, calls to nonexistent functions, or invalid tool interactions were also discarded. This is important: training an agent is not just about giving it conversations, but showing it which actions are valid and which ones produce reliable results.
Reasoning with three effort levels
One of Granite 4.2’s most visible features is its switch between thinking and non-thinking. The user or application can decide how much the model should deliberate before responding.
The three main modes are:
- Non-thinking mode: responds directly and reduces latency.
- Thinking mode: generates a reasoning chain before delivering the answer.
- Low-effort mode: uses a brief reasoning budget for straightforward questions.
For example, for a question such as the capital of France, the model can respond directly. To solve a math problem, debug a program, or plan a sequence of actions, it can activate a longer reasoning process.
This separation is useful in real products. Not every query deserves the same amount of computing power. Does it make sense to spend several seconds deliberating over the answer to 2 + 2? Probably not.
The format also allows you to keep or remove previous reasoning from the history. IBM includes options for trimming those parts and saving context space when a conversation continues.
From chatbot to tool-using agent
All Granite 4.2 models support native tool calls through OpenAI’s function-calling schema. The model can analyze the request, choose a function, fill in its arguments, and wait for the result before drafting a final response.
A simple example would be a weather application. If you ask about the weather in a city, Granite can select a function such as get_current_weather, send the city name, and then explain the result it receives.
The advantage is not limited to calling a function. The model can also reason about which tool it needs and chain multiple actions together. This opens the door to assistants capable of querying databases, running code, searching documents, or interacting with enterprise services.
Served through an OpenAI-compatible endpoint, for example with vLLM, Granite 4.2 can connect to different agent environments without creating special adapters. IBM also notes compatibility with SGLang.
Reinforcement learning as a ladder of skills
After supervised fine-tuning, IBM applied a reinforcement learning process in several stages. This is not a single optimization pass, but a ladder in which each phase focuses on a different capability and uses the previous result as its starting point.
The general sequence is:
SFT → RLVR → skill reinforcement → SWE agent → terminal → search → RLHF
RLVR means reinforcement learning with verifiable rewards. At this stage, the model receives an objective signal when an answer matches the correct solution, code passes tests, or the output follows a defined format.
Tasks include mathematics, formal proofs in Lean, competitive programming, science, instruction following, function calls, and reasoning puzzles.
IBM uses GRPO, a method that compares multiple answers generated for the same problem. Instead of training an additional network to estimate the value of each answer, it calculates a relative advantage using the group’s rewards.
In the case of Granite 4.2, a training batch may use 256 prompts and 16 responses per prompt, for a total of 4,096 examples. The system uses asynchronous training: while some workers generate responses, others update the model’s parameters.
To control differences between the version that generates the data and the version that learns from it, IBM limits how far behind each worker can fall and uses truncated importance sampling. Put simply, this prevents overly old examples from having a disproportionate influence.
The larger models learn to act
The 3B model receives training in reasoning, specific skills, and alignment. The 8B and 30B models also go through an agentic reinforcement learning block.
That block is organized into three environments:
- SWE agent: works in real repositories inside isolated containers. It reads files, modifies code, runs tests, and receives a reward if the hidden tests pass.
- Terminal agent: operates in a real terminal. It plans commands, interprets their results, and recovers from errors in tasks that can last up to 64 turns.
- Search agent: investigates complex questions through multi-step web searches and receives an evaluation of the quality of the final answer.
The difference is significant. It is one thing to explain how a software error could be fixed and quite another to open a repository, edit the right files, run the tests, and deliver a working solution.
To train these behaviors, IBM used NeMo-RL on the training side and NeMo-Gym to coordinate tools, environments, verifiers, and rewards. The same interface can represent both a math checker and a complete software engineering environment.
Results: reasoning, coding, and long context
IBM evaluated Granite 4.2 on reasoning, programming, tool use, instruction following, and long context. Results generally improve with model size.
Some highlights include:
- On SWE-Bench Verified, Granite 4.2 scores 47.67% on 8B and 57% on 30B.
- On Terminal-Bench 2.1, it reaches 20.56% on 8B and 29.24% on 30B.
- On AIME25, it records 78.33% on 3B, 86.67% on 8B, and 89.17% on 30B.
- On GPQA, it scores 54.80% on 3B, 64.14% on 8B, and 66.41% on 30B.
- On MMLU-Pro, it reaches 67.84% on 3B, 74.04% on 8B, and 77.60% on 30B.
- On RULER at 128K, it records 55.30% on 3B, 71.41% on 8B, and 81.38% on 30B.
The 30B model leads on agentic benchmarks, which is consistent with its greater capacity and additional training in software engineering, terminal use, and search. The 3B model, meanwhile, may be more attractive for local deployments where memory and inference cost are limiting factors.
Granite 4.2 supports English, German, Spanish, French, Japanese, Portuguese, Arabic, Czech, Italian, Korean, Dutch, and Chinese.
Local deployment and quantized versions
IBM released quantized variants to reduce memory consumption during inference. There are versions in FP8, NVFP4, and MXFP4, as well as GGUF files compatible with llama.cpp.
Available GGUF formats include Q8_0, Q6_K, Q5_K_M, Q4_K_M, Q4_0, Q3_K_L, and Q2_K. In practice, formats with fewer bits allow you to run the model with less memory, although they may slightly reduce quality or precision.
The FP8 versions use dynamic per-channel weights and per-token activations. The NVFP4 and MXFP4 variants were quantized with GPTQ from 2,000 samples in the supervised fine-tuning set.
To get started with Transformers, IBM shows an installation based on PyTorch and transformers:
pip install torch accelerate transformers
The model can be loaded with bfloat16 and use the chat template to activate reasoning. A conceptual example would be:
from transformers import AutoModelForCausalLM, AutoTokenizer
model_path = "ibm-granite/granite-4.2-3b"
tokenizer = AutoTokenizer.from_pretrained(model_path)
model = AutoModelForCausalLM.from_pretrained(
model_path,
device_map="cuda",
torch_dtype="auto"
)
For agentic applications, IBM documents integrations with tools such as OpenCode, Pi, and OpenHands. These systems can connect to an vLLM server through an OpenAI-compatible API and use Granite as a local model for programming, running commands, or coordinating tasks.
What it means for developers and businesses
Granite 4.2 combines three trends that are already changing AI application development: reasoning models, tool calls, and training in real-world environments.
The Apache 2.0 license makes it easier to use in commercial and research projects, as long as its conditions are met. The different scales let you choose between lower inference costs and greater capacity for complex tasks.
But it is worth keeping expectations realistic. The fact that a model can use a terminal or a tool does not mean it is autonomous or infallible. Agents need limited permissions, isolated environments, activity logs, and validation before executing important actions.
The most interesting idea behind Granite 4.2 is not that an AI simply gives better answers. It is that IBM trained part of the family to complete verifiable tasks inside real systems. The practical leap appears when the model stops being only a conversational interface and begins to operate as a functional component within a workflow.