Two models to combine interaction methods
H Company presented Holo4 as a family of models for agents that work with software. The core proposal is not just controlling a screen: the model can click and type on a graphical interface, create and run code, and call tools connected via MCP or API. Depending on the task, it can resort to one or the other path and combine them.
The family has two variants: Holo4-27B, a dense model with 27 billion parameters, and Holo4-35B-A3B, a mixture of experts with 35 billion parameters in total. The company states that both are available through the H Models API and that weights for download have also been published. The availability of weights does not mean that usage conditions are identical: before integrating either variant, one must review the current card and license of the specific model.
Which interfaces and tasks the proposal covers
H Company mentions use on desktops, the web, and Android, as well as isolated spaces for running code and connections to business APIs. The approach aims to prevent an agent from relying on a single interface: a task can start in a graphical application, continue with code, and end via a tool or API, if the environment provides those resources.
This is relevant because a graphical interface and an API do not offer the same possibilities. On a screen, the agent must interpret what it sees and act on controls; an API, by contrast, allows data exchange through defined operations. MCP is a protocol for connecting models with tools. The publication presents Holo4 as a single model that can use these options, but it does not establish that every application, account, or service is automatically compatible: integration and permissions depend on the environment executing it.
Benchmarks: useful results, but not interchangeable
The publication reports that Holo4-27B achieved 61.7% on OSWorld 2.0, an evaluation of desktop control tasks, and that Holo4-35B-A3B reached 30.9%. It also compares models on AutomationBench, a test focused on tool and API use. The company indicates that its AutomationBench v1.0.6 results were measured in an internal environment and that it will report Holo4's results on the private set once that evaluation is complete.
These figures must be read alongside the conditions of each test. The publication warns that comparisons may combine different model versions, harnesses, task subsets, and effort levels. In OSWorld 2.0, part of the costs is estimated from the tokens of each run; in AutomationBench, some models are compared with scores from public sets, while reference costs may come from a leaderboard based on the private set. Therefore, an isolated figure does not allow concluding that one model is better in all scenarios or directly comparing the real cost of a business operation.
How to interpret the published evidence
| Evidence | What it allows observing | What it does not prove on its own |
|---|---|---|
| OSWorld 2.0: 61.7% for Holo4-27B and 30.9% for Holo4-35B-A3B, according to the publication | Reported performance in a desktop task evaluation | Uniform success on any operating system, application, or real flow |
| AutomationBench v1.0.6 in H Company's internal harness | Results under the configuration and set described by the company | Fully equivalent comparison with figures obtained in other harnesses or partitions |
| Published execution trajectories for benchmarks | Allows inspecting specific steps of some runs | That all runs are reproducible or that there are no failures outside those examples |
Demonstrations and traces: what can be checked
H Company shows examples in FreeCAD and Godot alongside comparisons against a base model. Tasks include building a 3D representation of the Eiffel Tower and a Pac-Man-style game that runs without keyboard intervention. These are concrete demonstrations of software development and tool control, not a sufficient measure of general performance: a task may require many calls, consume a large amount of tokens, and still not represent average behavior in production.
The company also states that it publishes trajectories of its benchmark results so they can be reviewed or downloaded. This transparency can help examine actions and errors of a particular run. To turn demonstrations into reproducible evidence, one must check the model version, prompt, environment, available tools, number of attempts, and criteria used to declare a task completed. The publication does not eliminate the need to repeat tests in the system where the agent is to be deployed.
Practical process to evaluate Holo4 in a custom flow
- 01Define representative tasks and a verifiable result for each, not just open-ended instructions.
- 02Prepare a test environment with the same applications, tools, data, and permissions planned for real use.
- 03Record model, configuration, calls, time, consumption, and errors; include tasks the agent should not complete.
- 04Repeat each task several times and compare the result with an alternative and a human reference run.
- 05Review traces and test interface changes, incomplete data, and tool failures before considering deployment.
Access, licenses, and deployment limits
The official publication states that both sizes are available on the H Models API and that weights are offered in formats such as FP16, FP8, and GGUF. It also mentions a small variant called Holotron4 Nano and announces optimized DSpark checkpoints in the days following the publication. Availability via API and weight download are distinct paths: the former depends on the service and its conditions; the latter requires infrastructure to run the model and to review the license conditions of each version.
The announcement does not offer a guarantee of safe autonomy or specify a universal permission system for actions. In a real integration, the operator must decide which applications, files, APIs, and actions are within the agent's reach. It is advisable to separate read and write, restrict sensitive operations, require human confirmation for irreversible changes, and keep logs. These are prudent deployment measures, not safeguards that should be assumed to be built into Holo4 without specific documentation.
What changes and what remains to be proven
Holo4 proposes a practical architecture for tasks that jump between screen, code, and tools, and publishes weights, examples, and evaluation results. For teams studying automation, the news is an additional option that can be tested in delimited flows, especially if the necessary tools are available and their results can be objectively evaluated.
The announced evidence is not enough to claim that Holo4 is a universal-purpose agent, that it outperforms other models under identical conditions, or that it operates reliably without supervision. Differences between tests, harnesses, and task sets limit direct comparisons. The reasonable decision is to treat the figures as results communicated by H Company and to validate the model on custom tasks, with access controls and failure tests before trusting it with important actions.
Open questions
- Benchmarks and cost estimates depend on versions, harnesses, task subsets, and configurations that are not always equivalent between models.
- H Company indicates it will publish Holo4's results on the private partition of AutomationBench after evaluating it; this data is not confirmed in the available information.
- The provided documentation does not allow establishing a general failure rate in production or a guarantee of safe and autonomous operation.
- The specific licenses of each variant must be verified in the current model cards; they are not inferred here from secondary sources.
Keep exploring
Sources consulted
Corrections and transparency
If you spot incorrect or outdated information, send us a correction with the page and source we should review.
Submit a correction