What happened
Nace AI tagged Kapitsa 0.2.31 on GitHub on November 5. The release notes combine code changes with updates to README performance cells, and distinguish shipped changes from experiments that did not ship. The reported numbers cover several models and Apple devices rather than one general benchmark.
For 27B on M5 Max, the release updates prefill figures from 1,104 to 1,126 tokens per second at 4K and from 1,032 to 1,070 tokens per second at 16K. The notes say the new results are past Splash at both context lengths. For 35B-A3B, one updated M5 Max cell moves from 6,558 to 6,619 tokens per second. These are documented test cells, not a claim that every workload or machine will see the same gain.
A larger M5 Max change is a two-half GPU wavefront for 35B-A3B prefill, processing DeltaNet scan and attention alongside expert GEMMs in 8,192-row chunks. The notes say it produces the same logits as half-size chunks. At 16K, one timing falls from 2,776 to 2,618 milliseconds; the corresponding README cell moves from 5,718 to 6,046 tokens per second, a reported 5.7% increase. At 4K, the notes say performance was unchanged at 6,539 tokens per second. Other trials—including a chunked DeltaNet scan and GPU FFN overlap—are explicitly labeled as not shipped.
The update also reports M4 decode changes: packed GEMMs, lazy GDN folding, and a low-rank DFlash2 head take 4B KFlash from 144.8 to 152.3 tokens per second on a 10-core M4. Separately, DFlash2 history lane is enabled by default for 35B-A3B on M5 Pro; the project describes it as about 13% faster with the same outputs. The release includes a rule that a feature remains off by default across models and Macs unless it is measured as a win for that configuration. That policy matters because the release does not present a single switch as beneficial everywhere; default behavior is intended to follow measured results by model and machine.
The tag also adds support for reading default serving arguments from serve.json for Homebrew services. On the Apple Neural Engine path, it preserves the reason when a program fails to compile or load, rather than losing a C++ exception's text in the service queue. These are operational changes rather than benchmark claims, but they affect how a Homebrew-hosted service can receive defaults and how a failure can be diagnosed. The supplied notes do not specify a new model catalog, a price, a licence change, or a different access path.
What the archive adds
The archive has covered earlier Kapitsa releases: v0.2.15 focused on stability fixes and faster MoE prefill, while 0.2.25 added a model and an in-process C ABI SDK. This is a new release on a known story, with additional performance measurements and a default-on optimization.
Trend signal
This modestly supports agent economics moves to completed work: runtime improvements can make local inference more efficient, but the release reports tokens per second rather than cost per verified task. It is evidence of an optimization layer, not yet evidence that completed-work economics have shifted.
Why now
The release was tagged November 5 and records nine commits to main since the prior release. Its notes emphasize measured per-device wins and explicitly keep some experimental optimizations out of the shipped build, giving users a timely view of what changed in this version versus what remains research or measurement work.
Why it matters
Teams running models locally need to know not only whether a runtime supports a checkpoint, but what throughput to expect at particular context lengths and on particular chips. Kapitsa’s release provides concrete data points for that decision and shows a disciplined deployment rule: enable an optimization where it measured as a win rather than applying it universally. The M5 Pro default-on change is particularly actionable for users of that exact model/device combination, while the M4 and M5 Max figures can inform evaluation plans.
The broader engineering lesson is to preserve workload-specific baselines and validate outputs alongside speed. A percentage improvement without hardware, model, context, and output-equivalence details is not a portable performance promise. Teams should also separate prefill and decode in their capacity planning: this release reports gains in both categories, but they correspond to different stages of a serving workload and different configurations.
Limits and uncertainty
The figures come from the project’s own release notes and README cells; the supplied material provides no independent benchmark, full test protocol, power draw, or repeated-run variance. Results are specific to named models, devices, and context lengths, so they should not be generalized to other Macs or workloads. The notes describe unchanged outputs for the M5 Pro DFlash2 change and same logits for the wavefront, but do not establish broader quality equivalence. No pricing, licensing change, or access change is reported.
Skill to build now
If your team serves these models on Apple Silicon, record a small local baseline for the exact checkpoint, Mac, context length, and decode/prefill split you use. After updating Kapitsa, rerun the same prompt set and compare throughput and output equivalence before treating the published gains as applicable to your workload.
Reader takeaway
Kapitsa 0.2.31 adds measured, configuration-specific speedups for Apple Silicon inference, including a default-on M5 Pro optimization for 35B-A3B. Treat the numbers as useful test targets, not universal guarantees: reproduce them on your model and hardware before changing capacity plans.