In partnership with
SnackOnAI Engineering | Senior AI Systems Researcher | Technical Deep Dive | November 8, 2026
Most of TwIL-8B's math ability was already in its base model. IBM's Granite 4.2 8B reports 86.67 on AIME 2025 before webAI touched it. What webAI added is more interesting and less marketable: a reinforcement learning stage that teaches the model to stop thinking sooner. On AIME 2026, the balanced variant uses about 19.5K output tokens per problem against Qwen3.5-9B's 31.2K. At equal decode speed, that's roughly 53% more problems solved per hour, even though Qwen scores 4.2 points higher.
The promise: by the end you'll know what webAI changed on top of Granite, what length-aware RL actually optimizes, and what an "8B model in 5 GiB" really costs to run when every answer starts with 20,000 tokens of thinking.
The fence: the TwIL-8B model card couldn't be fetched from this environment, so its numbers come from consistent reporting by Tilnote, AlphaSignal and MarkTechPost via daily.dev. The Granite 4.2 8B architecture comes from a config summary in a public GitHub issue and Friendli's model page, and IBM's base benchmarks from an IntuitionLabs guide. webAI hasn't published its training data, compute, reward function or a technical paper. We didn't download or run the weights. Every TwIL number is webAI's own, and competitor numbers were taken from published sources rather than rerun.
What It Actually Does
TwIL-8B is a post-trained version of IBM's Granite 4.2 8B, tuned for math, code and instruction following. It thinks inside a <think> block before it answers.
Property | Value |
|---|---|
Base | ibm-granite/granite-4.2-8b, dense decoder, Apache 2.0, released August 25, 2026 |
Parameters | 8.79B, context 131,072 tokens |
Training | Full-parameter SFT → GRPO/DAPO RL (verbose) → length-aware RL (balanced) |
Variants | Balanced (default, shorter traces) and Verbose (hard problems, more tokens) |
Files | bf16 16.38 GiB · Q8_0 GGUF 8.70 GiB (verbose only) · Q4_K_M GGUF 4.98 GiB |
Headline scores | MATH-500 98.2 · AIME 2026 88.3 · LiveCodeBench 81.6† · IFBench 74.4† · GPQA Diamond 70.2 |
License | webAI Non-Commercial License v1.0 (the base model is Apache 2.0) |
Maker | webAI, Austin, focused on local-first AI on Apple hardware |
† Measured on the verbose variant only. The balanced variant hadn't been run on these benchmarks at release.
One correction to the caption circulating with this release: the 88.3 is AIME 2026, not AIME 2025, in every source we found. And the sources disagree on which variant scored the 98.2 on MATH-500.
The Architecture, Unpacked
What to notice: the only architectural novelty is in training. The network is Granite's, unchanged. The third stage changes how long the model talks, not what it knows.
Three decisions define the model.
Post-train a reasoning base instead of building one. Granite 4.2 already ships with thinking modes and reasoning RL. Starting there means webAI spent its compute on specialization rather than on teaching an 8B model to reason from scratch.
Use verifiable rewards. GRPO, from DeepSeekMath, scores each answer against the other answers sampled for the same prompt, so it needs no learned value model. DAPO adds four fixes for long chain-of-thought RL. Both work only where correctness can be checked automatically, which is why the gains concentrate in math and code.
Fork the model on length. Instead of shipping one compromise, webAI ships two checkpoints. That's honest: a single length penalty can't be right for both a quick arithmetic check and an olympiad problem.
The Code, Annotated
Snippet one: the length-aware reward. webAI hasn't published its formula. This is the published length reward from Kimi k1.5, the best-documented recipe of this kind, written as a drop-in for a GRPO group. Treat it as a reconstruction of the technique, not webAI's code.
import numpy as np
def length_aware_rewards(correct: np.ndarray, lengths: np.ndarray, weight: float = 1.0) -> np.ndarray:
"""correct: 0/1 per sampled answer in ONE group; lengths: output tokens per answer."""
lo, hi = lengths.min(), lengths.max()
if hi == lo: # no spread in length → no length signal
return correct.astype(float)
lam = 0.5 - (lengths - lo) / (hi - lo) # +0.5 for the shortest answer, −0.5 for the longest
# Correct answers earn the length bonus; wrong answers can only be penalized for length,
# never rewarded for brevity. Otherwise the cheapest policy is "answer instantly, be wrong."
len_term = np.where(correct == 1, lam, np.minimum(0.0, lam)) # ← THIS is the trick
return correct + weight * len_term
def grpo_advantages(rewards: np.ndarray) -> np.ndarray:
# GRPO: the baseline is the group itself, so no critic network has to be trained.
return (rewards - rewards.mean()) / (rewards.std() + 1e-6)
# Six sampled solutions to one AIME problem: four correct, of very different lengths.
correct = np.array([1, 1, 1, 1, 0, 0])
lengths = np.array([9_000, 14_000, 22_000, 31_000, 12_000, 32_000])
print(grpo_advantages(length_aware_rewards(correct, lengths)).round(2))
# → [ 1.24 0.93 0.44 -0.12 -0.89 -1.61] shortest correct trace gets the biggest push;
# the 31K correct trace is now slightly discouraged, so verbosity is trained out even when right
Correctness still dominates the reward, but a correct answer that rambles can end up with a negative advantage. That's how length pressure works without a hard cap.
Snippet two: running it with Transformers. Sampling settings follow IBM's Granite 4.2 guidance (temperature 1.0, top_p 0.95), because TwIL keeps Granite's tokenizer. Whether TwIL's chat template keeps Granite's enable_thinking switch is our assumption; check the model card before relying on it.
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
repo = "webAI-Official/TwIL-8B" # balanced variant by default, per the release
tok = AutoTokenizer.from_pretrained(repo)
model = AutoModelForCausalLM.from_pretrained(repo, torch_dtype=torch.bfloat16, device_map="auto")
msgs = [{"role": "user", "content": "Find the number of ordered pairs (a, b) of positive integers with a*b = 2026^2."}]
ids = tok.apply_chat_template(msgs, add_generation_prompt=True, return_tensors="pt",
enable_thinking=True).to(model.device) # Granite-style switch (assumed)
out = model.generate(ids, max_new_tokens=32_768, # ← THIS is the real budget: leave room for ~20K
do_sample=True, temperature=1.0, top_p=0.95) # tokens of thinking, or you score a truncation
text = tok.decode(out[0, ids.shape[1]:], skip_special_tokens=False)
thinking, _, answer = text.partition("</think>")
print(len(tok(thinking).input_ids), "thinking tokens →", answer.strip()[:200])
A max_new_tokens of 2,048, the default in many serving configs, cuts an AIME-length trace off at about a tenth of its length.
Snippet three: what "5 GiB" means at runtime. We derived this from Granite's published config. It reproduces webAI's parameter count and bf16 file size exactly, which is a useful check that the architecture is unchanged.
L, kv_heads, head_dim = 40, 8, 128 # Granite 4.2 8B: GQA, 8 KV heads
V, d, ffn = 100_352, 4_096, 12_800
attn = d * 32 * head_dim + 2 * d * kv_heads * head_dim + 32 * head_dim * d
params = L * (attn + 3 * d * ffn) + 2 * V * d # untied input and output embeddings
print(f"{params/1e9:.2f}B params, bf16 {params*2/2**30:.2f} GiB") # 8.79B, 16.38 GiB ✓ matches the card
kv_per_tok = L * kv_heads * head_dim * 2 * 2 # K and V, f16 → 163,840 bytes = 160 KiB
for tokens in (4_096, 19_500, 131_072):
print(tokens, f"KV {tokens*kv_per_tok/2**30:.2f} GiB",
f"total with Q4_K_M {4.98 + tokens*kv_per_tok/2**30:.2f} GiB")
# 4096 KV 0.62 GiB total 5.61 GiB
# 19500 KV 2.98 GiB total 7.96 GiB ← one balanced AIME trace adds 60% to the weights
# 131072 KV 20.00 GiB total 24.98 GiB ← the full context window is 4x the model file
Quantization shrinks the weights 3.3x. It doesn't shrink the thinking. Plan memory for the trace, not the file.
# Local inference with llama.cpp: f16 KV by default; q8_0 KV halves the trace's memory.
llama-cli -m TwIL-8B-Q4_K_M.gguf -c 32768 -n 24576 \
--temp 1.0 --top-p 0.95 \
-ctk q8_0 -ctv q8_0 -fa # quantized KV cache needs flash attention
The context flag (-c), not the model file, decides whether this fits on a 16 GB machine.
It In Action
Input: one AIME 2026 problem, balanced variant, Q4_K_M weights, llama.cpp on an M5 Max. The decode speed comes from the Granite 4.2 8B base on the same chip, 44.6 tokens per second (measured here). TwIL uses the identical network, so the speed carries over.
Step one, prefill. A roughly 150 token problem statement at about 560 tokens per second takes under half a second.
Step two, think. The model writes about 19,500 tokens inside <think>, webAI's reported average on AIME 2026. At 44.6 tokens per second that's 7.3 minutes. The KV cache grows to 2.98 GiB, so the process holds about 8 GiB.
Step three, answer. After </think>, a few dozen tokens give the integer answer. webAI reports 88.3% pass@1 on the set.
Output, compared at equal decode speed (our arithmetic; Qwen3.5-9B's real speed on this chip will differ because its architecture differs):
Model | Accuracy | Tokens per problem | Minutes per problem | Solved per hour |
|---|---|---|---|---|
TwIL-8B balanced | 88.3% | ~19.5K | 7.3 | 7.3 |
Qwen3.5-9B | 92.5% | ~31.2K | 11.7 | 4.8 |
GPT-5.5 (reference) | n/a here | ~5K | n/a | n/a |
accuracy per 1K thinking tokens (AIME 2026)
TwIL-8B balanced ██████████████████████ 4.5
Qwen3.5-9B ███████████████ 3.0
Giving up 4.2 points of accuracy buys 38% fewer tokens and about 53% more solved problems per hour. That's the real product.
Why This Design Works (and what it trades away)
It works because math and code have verifiers. GRPO and DAPO need a reward a program can compute: the boxed answer matches, the tests pass. That's why LiveCodeBench rises about 8 points over IBM's reported base score while knowledge benchmarks stay behind larger models. RL can sharpen how a model searches. It can't add facts the model never saw.
It works because length is a training target. Long chain-of-thought RL tends to make outputs longer over time. DAPO's overlong shaping and a length-aware stage push back. The Kimi-style rule in snippet one keeps the incentive honest: brevity only pays when the answer is right.
It trades away knowledge. GPQA Diamond: 70.2 vs Qwen3.5-9B's 81.7 and Gemma 4 31B's 84.3. MMLU-Pro and HLE follow the same pattern. HLE lands at about 26% of the best frontier score. Route factual questions elsewhere.
It trades away safety work. webAI added no safety or preference tuning beyond what Granite already had. RL on verifiable rewards optimizes correctness and length, not refusals, so add your own filter in production.
It trades away commercial freedom. The base is Apache 2.0, but TwIL is non-commercial. For a company whose pitch is local deployment, that's the limit most likely to stop a real rollout.
It trades away measurement completeness. The balanced variant, the default, has no published LiveCodeBench or IFBench score. Two of the four headline numbers describe a model you get only by choosing the non-default checkpoint.
Technical Moats
Architecture: thin. The network, tokenizer and context are Granite's, and the RL algorithms are public. Anyone with the base model, verifiable datasets and a GRPO trainer can attempt the same recipe.
The data is the moat that remains. webAI hasn't disclosed its SFT traces or RL prompt mix. In verifiable-reward RL, prompt difficulty selection decides much of the outcome, which is why DAPO filters out groups that are all right or all wrong.
Length calibration takes tuning. Too much length weight and accuracy collapses. Too little and nothing changes. Shipping a balanced variant that loses only 4.2 AIME points against a stronger competitor while using 38% fewer tokens implies careful sweeps, and the weights for that aren't public.
Deployment fit. webAI already builds local inference across Apple devices (Navigator, webFrame). An 8B dense model with a 160 KiB per token KV cache is sized for exactly that hardware.
Insights
One: compare TwIL to Granite, not to Qwen, and the story shrinks. The release compares against Qwen3.5-9B and Gemma 4 and never against the base it was trained from. IBM's reported Granite 4.2 8B scores make the gains look like this:
Benchmark | Granite 4.2 8B (IBM) | TwIL-8B (webAI) | Delta |
|---|---|---|---|
LiveCodeBench v6 | 73.24 | 81.6 (verbose) | +8.4 |
GPQA Diamond | 64.14 | 70.2 | +6.1 |
IFBench | 79.33 | 74.4 (verbose) | −4.9 |
AIME | 86.67 (2025) | 88.3 (2026) | different exams |
The harnesses differ and these come from secondary sources, so read the deltas as directional. Still, the clear win is code. Math was already near the ceiling. On instruction following, the post-training may have made the model worse, the opposite of how "IFBench 74.4" reads on its own.
Two: "runs in 5 GiB" is true of the file and misleading about the workload. A reasoning model's memory and latency come from its traces. One balanced AIME answer adds 2.98 GiB of KV cache, and filling the 131K window adds 20 GiB, four times the weights. At 44.6 tokens per second, one hard problem takes over seven minutes on a top-end laptop. For interactive use, the shorter balanced trace matters more than the model's size, and GPT-5.5's ~5K tokens per AIME problem shows how far small open models still are from cheap thinking.
Surprising Takeaway
The cheapest accuracy is the token you don't generate. TwIL-8B balanced scores 4.2 points below Qwen3.5-9B on AIME 2026 yet solves about 53% more problems per hour at equal speed, because it averages 19.5K thinking tokens instead of 31.2K. Measured as accuracy per thousand tokens, it's 4.5 against 3.0. For local reasoning, length-aware RL beats a few points of leaderboard accuracy.
TL;DR For Engineers
TwIL-8B is Granite 4.2 8B with full SFT, GRPO/DAPO RL and, for the balanced variant, a length-aware RL stage. The architecture is unchanged: 8.79B, 40 layers, GQA with 8 KV heads.
The real gain over the base is code (LiveCodeBench +8.4 by IBM's numbers). IFBench appears lower than the base's, and knowledge benchmarks trail larger models.
Balanced uses ~38% fewer thinking tokens than Qwen3.5-9B on AIME 2026, about 53% more solves per hour at equal speed.
Budget memory for the trace: 160 KiB of f16 KV per token, about 3 GiB per AIME answer. Set
max_new_tokensto at least 24K or you'll benchmark truncations.The license is non-commercial. Check it before you build on it.
Explain It Like I'm New
When you ask a reasoning model a hard question, it doesn't answer right away. It writes out a long scratchpad of working first, sometimes tens of thousands of words, and only then gives the answer. That scratchpad is where most of the time, memory and cost goes.
TwIL-8B is a small model from a company called webAI, built by further training an open model from IBM. Small models matter because they can run on a laptop instead of a data center, which keeps data private and costs predictable.
The clever part is how it was trained. The model practiced on problems with checkable answers, like math problems with a known result or code with tests. Each time, it tried several solutions, and the training nudged it toward whatever worked. For one version, webAI added a second rule: among the correct solutions, the shorter ones count for more. It's like a teacher who gives full marks for a right answer but extra credit for a clean, concise derivation.
The result is a model that is slightly less accurate than some rivals on the hardest math but finishes much sooner, so it gets through more problems in the same time.
As AI moves onto personal devices, the length of a model's thinking may matter as much as its size.
See It In Action
Granite 4.2 model documentation, IBM. Read the docs. Explains the thinking, non-thinking and low-effort modes TwIL inherits, plus the recommended vLLM reasoning parser. This is the closest thing to official serving guidance for TwIL today.
Running Granite 4.2 8B on Apple Metal, OpenAgents issue #12870 on GitHub. Read the measurements. Real decode and prefill speeds for the identical network on an M5 Max, the numbers behind our worked example.
TwIL-8B community GGUF build, prithivMLmods on Hugging Face. Get the quantized files. The fastest way to try it locally with llama.cpp or Ollama.
We found no video walkthrough, talk or independent benchmark run of TwIL-8B as of November 5.
Community Conversation
Tilnote (alpha), model analysis. Gives the most complete numbers, including AIME 2026 88.3 vs 92.5 at 19.5K vs 31.2K tokens. Ends with a practical checklist: retest your own problems, budget for long reasoning, verify knowledge queries elsewhere, add safety filtering.
AlphaSignal, release coverage. Frames TwIL against frontier models (93% of the best LiveCodeBench score) and notes that runtime memory exceeds the file size because of the KV cache.
MarkTechPost, via daily.dev. Counts 7 wins and 6 losses against Qwen3.5-9B across 13 shared benchmarks, and notes that all scores used bf16 weights, so quantized builds may score lower.
Taylor Ortiz, Another Daily AI Newsletter. Credits David Stout with open-sourcing the model and flags that the "93% of frontier" figures are webAI's own.
RuntimeWire, on webAI's TwIL family. Gives context from the earlier 1.7B and 3B formal-logic TwIL models, which Stout called "almost like an auto-correct for AI," and webAI's own warning that TwIL is not a verifier.
Conclusion: Length Control Is the Feature, the Benchmark Table Is the Packaging
TwIL-8B is a sensible piece of engineering with misleading marketing. The network is Granite's, the math ability is mostly Granite's, and the comparison table leaves out the one model that would show what webAI actually added. What webAI added is real and useful: an 8B model that reaches nearly competitive accuracy while thinking a third less, plus a clear gain on code. If you run reasoning locally, test the balanced variant on your own problems and measure solves per hour, not pass@1. If you plan to ship it commercially, read the license first.
References
DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, Shao et al. Introduces GRPO: group-relative advantages with no value network.
DAPO: An Open-Source LLM Reinforcement Learning System at Scale, Yu et al. Clip-higher, dynamic sampling, token-level loss and overlong reward shaping for long chain-of-thought RL.
Kimi k1.5: Scaling Reinforcement Learning with LLMs, Kimi Team. The length reward reconstructed in snippet one.
L1: Controlling How Long A Reasoning Model Thinks With Reinforcement Learning, Aggarwal and Welleck. Length-conditioned RL that targets a token budget given in the prompt.
Let's Verify Step by Step, Lightman et al. The origin of the MATH-500 subset.
Training language models to follow instructions with human feedback, Ouyang et al. The preference-tuning stage TwIL didn't add.
TwIL-8B is IBM's Granite 4.2 8B with SFT, GRPO/DAPO RL and a length-aware RL stage that cuts thinking tokens by about 38% against Qwen3.5-9B on AIME 2026. Its clearest gain over the base is code, while instruction following and knowledge trail. The trace, not the 5 GiB file, decides its real cost.
Sponsored Ad If you enjoy practical AI insights, check out SnackOnAI and support the newsletter by subscribing, sharing, and exploring our sponsored ad—it helps us keep building and delivering value 🚀
The voice-to-text app that built its own speech model
Most dictation apps are a wrapper around someone else's speech model. Wispr Flow trained its own.
It's called Canto, and it was built for the way people actually talk to AI: thinking out loud, changing direction mid-sentence, half-whispering in an open office.
Wispr tested it on 10 hours of real dictations from more than 2,300 speakers. Canto had the lowest word error rate of every model tested, including models from Google, OpenAI, AssemblyAI and Deepgram. That means your prompts to ChatGPT, Claude and Cursor come through the way you said them.
Talk naturally in any app and Wispr Flow types clean, formatted text, 4x faster than typing.