I’ve been watching the agentic AI space develop, and there’s been a persistent assumption: frontier closed models like Claude Opus or GPT-4 handle the hardest automation tasks, while open models play in the sandbox. Holo4 challenges that assumption in a way worth paying attention to.
The new series comes in two sizes (27B dense and 35B-A3B MoE) and does something I haven’t seen executed this cleanly before: it uses the same underlying model across completely different interfaces. It clicks GUI elements, writes and runs code, calls APIs, and uses MCP tools. Not different models for different contexts. The same model.
That matters more than it sounds.
The Interface Problem That Actually Exists
Most agentic models I’ve tested have a major weakness: they’re trained for one interface only. GUI-focused models struggle without a screen. Tool-calling specialists hit dead ends when facing an application with no API. In reality, business workflows don’t fit that mold. A single task might require reading information from a web UI, calling an internal API, writing a custom script to process data, and then updating a spreadsheet.
Holo4 was built on real environments from the start through something called the Agentic Task Factory, which generates tasks from actual software documentation and screenshots. We’re talking roughly 10,000 tasks across web apps, desktop environments, MCP servers, and hybrid setups. That’s not benchmark gaming. That’s training on the messy intersection where real work happens.
The results on academic benchmarks are telling. On OSWorld 2.0, Holo4 27B scores 61.7% compared to Opus 5.5’s 81.8%. But here’s what actually matters: it does this with orders of magnitude fewer parameters and at a fraction of the cost per task. The 35B-A3B variant reaches 30.9% on the same benchmark, which sounds lower until you run the math on cost-per-successful-task.
On AutomationBench, Holo4 competes directly with frontier models at significantly lower inference costs. That gap matters when you’re running hundreds or thousands of automation tasks monthly.
What This Means for Developers
If you’re building automation systems, this shift is important. For years, the playbook was: use Claude or GPT for complex reasoning, then build wrappers around different interfaces. Now you have a genuine alternative that natively handles the interface problem.
More concretely: you get faster iteration on agent workflows because you’re not context-switching between different models or managing separate APIs. The same model works whether you’re deploying on desktop, web, Android, or a code sandbox. That’s operationally simpler.
The training methodology is worth understanding too. Holo4 used both supervised learning and reinforcement learning on environments and tasks from the Agentic Task Factory. Then they rebuilt the entire harness that executes the model’s actions based on what actually failed on OSWorld 2.0. The changes included giving agents reliable memory across hundreds of steps and shell access on desktop machines.
These aren’t novelty features. They’re fixes for real problems developers face when deploying agents.
The Transparency Angle
One detail I found refreshing: they open-source every trajectory behind their scores. You can replay each step at trajectories.hcompany.ai or download from Hugging Face. That level of transparency in benchmarking is rare and makes the performance claims verifiable rather than just marketing numbers.
The weights themselves are available in multiple formats (BF16, FP8, NVFP4, 4-bit GGUF), which means you can run this locally if you want to. The company is also releasing optimized DSpark drafter checkpoints to speed up inference further.
Holotron4 Nano, their follow-up with NVIDIA’s Nemotron 3 Nano Omni base model, shows the recipe isn’t limited to one foundation model. Same training stack, similar gains. That suggests the approach generalizes.
The Bigger Picture
What strikes me most is that this represents a shift in how we should think about open model development. The old frame was: open models are catching up to closed models on general capability. The newer frame should be: open models can be specialized for specific workflows (like agentic automation) and outperform on practical metrics that matter (cost per task, latency, local deployability) even if they don’t match frontier models on every benchmark.
That’s a fundamentally different competitive dynamic. It means the question isn’t “Is Holo4 as good as Opus?” It’s “For my automation use case, is Holo4 the better tool for my constraints and budget?”
For many teams, the answer might finally be yes.