Holo4-35B-A3B

Holo4-35B-A3B is Hcompany's second model in the Holo4 series, released September 28, 2026, and it is built for one job: driving software the way a person does. It clicks and types on a screen, writes and executes its own code, and calls MCP or API tools, choosing whichever interface fits the task in front of it. That combination is rarer than it sounds. Most agentic models commit to a single interface. GUI-first models are useless when a task has a clean API, and tool-calling specialists stall in front of a desktop application that never exposed one. Holo4 was trained across desktop, web, Android, and code sandboxes specifically so a single workflow can mix all of them.

The architecture is a Mixture of Experts design with 35B total parameters and 3B active per token. That ratio is the headline for anyone planning to self-host. You pay the memory cost of a 35B model but the compute cost of roughly a 3B one, which means generation speed on local hardware is far better than the parameter count suggests. Hcompany ships it alongside a 27B dense sibling and Holotron4 Nano, and publishes weights in FP16, FP8, and GGUF formats, so this is a model you can genuinely run on your own machine rather than only through the H Models API.

Where it stands out is computer use. It scores 30.9% on OSWorld 2.0, a harder successor to the original OSWorld suite that Hcompany used to report 85.2% for the dense 27B model, so treat those two numbers as separate benchmarks rather than a ranking. If your workload involves operating real applications, navigating GUIs, or orchestrating mixed tool and screen interactions, this is the category to evaluate. If you just need a chat model, you are paying for capabilities you will not use.

Holo4-35B-A3B is a sparse Mixture of Experts transformer. Of the 35B total parameters, only about 3B are activated for any given token, routed through a subset of expert layers. The practical consequences split in two directions:

• Compute scales with active parameters. Matrix multiplications per token are on the order of a 3B dense model, so token generation is fast even on modest GPUs.
• Memory scales with total parameters. Every expert must be resident in VRAM or system RAM, because the router can select any of them at any step. You cannot load only the experts you "need."

This is the single most common mistake people make when sizing hardware for MoE models. A 3B active parameter count does not mean 3B of memory. Budget for the full 35B weight footprint plus KV cache.

Context length is not specified in the published model card, and neither is the license or training cutoff. Check the Hugging Face repository before committing to a deployment, particularly if you need a permissive license for commercial use or a defined context window for long-document agent traces.

The model is multimodal: text and image input, with vision feeding directly into the computer-use loop. Screen understanding is not a bolt-on here, it is the primary input path.

The capability set is code, reasoning, function-calling, instruction-following, and vision. In practice that maps to a specific kind of work:

• GUI automation. Filling forms, navigating internal dashboards, extracting data from applications with no API. This is the core competency and the reason the model exists.
• Mixed-interface agent loops. A task that starts in a browser, calls an MCP tool mid-way, then writes and runs a Python snippet to transform the result. Holo4 switches between these without a separate orchestration model.
• Code execution as a tool. Rather than a pure code-completion model, the coding ability is oriented toward writing scripts that accomplish a step in a larger task.
• Structured tool calling. Function-calling against APIs and MCP servers, with instruction-following strong enough to hold a multi-step plan together.
• Document and screen understanding. Vision input covers screenshots, rendered documents, and UI state.

It is not positioned as a long-form writing model or a general chat assistant. Evaluate it against agentic workloads.

Because GGUF weights are published, local inference is a realistic path. The constraints are memory bandwidth and capacity, not raw compute.

Add roughly 2GB-8GB for KV cache depending on context length and batch size.

• RTX 4090 / 5090 (24GB-32GB): Q4_K_M fits on a 4090 with a modest context window; the 5090 runs Q5_K_M or Q6_K comfortably.
• RTX 3090 (24GB): Q4_K_M is workable, slower memory bandwidth than the 4090 but the 3B active compute keeps throughput respectable.
• 2x RTX 4090 (48GB): Q8_0 or FP8 with long context. The most cost-effective high-quality setup.
• Apple M4 Max (64GB or 128GB unified memory): Q4_K_M through Q8_0 depending on configuration. Unified memory removes the VRAM ceiling but bandwidth is lower than discrete GPUs.
• Mac Studio M3/M4 Ultra (192GB+): FP16 without compromise.

If you are asking how to run a 35B model on a consumer GPU, this is one of the better candidates in 2026 precisely because the active parameter count keeps generation fast.

These are ballpark figures for Q4_K_M with a moderate context, and they depend heavily on backend and batch size:

• RTX 4090: roughly 70-110 tokens/sec generation
• RTX 5090: roughly 100-140 tokens/sec
• M4 Max: roughly 35-60 tokens/sec
• Dual 4090: roughly 90-130 tokens/sec, limited by interconnect

Prompt processing on vision input is the slower phase. Budget for it if your agent takes frequent screenshots.

Ollama is the fastest route to a working local instance once the GGUF quants are pulled from the Holo4 collection. Install Ollama, pull the model tag, and run it. For anything beyond a quick test, drop to llama.cpp or vLLM so you can control context size, KV cache quantization, and expert offload explicitly. If you want the hosted equivalent for comparison, Hcompany exposes an OpenAI-compatible endpoint at https://api.hcompany.ai/v1/ with the model name holo4-35b-a3b, so an existing OpenAI client works with a two-line change.

Against Holo4-27B (dense, same family). The 27B dense model activates all 27B parameters per token, so it is slower and needs a comparable memory budget, but dense models often hold up better on tasks requiring tight, consistent reasoning across long chains. Choose the 27B if your workload is mostly code and text reasoning with occasional screen interaction. Choose the 35B-A3B if throughput matters and computer use is central.

Against Qwen3-30B-A3B. The closest architectural peer: a 30B MoE with roughly 3B active parameters. Qwen3 is stronger as a general-purpose text and coding model and has a well-documented context window and license. Holo4-35B-A3B is the better pick when the task involves operating a GUI or mixing screen, code, and tool interfaces in one loop. For pure text generation, Qwen3 is usually the more predictable choice.

The deciding question is whether you need an agent that can see and drive a screen. If yes, Holo4-35B-A3B is one of the few open-weight options in this size class. If no, a dense model or a general MoE will serve you better for the same memory budget.