Holo4 for Local Computer Use: Model, Runner, and Permission Boundaries

A general chat model receives text and returns an answer. A computer-use model receives a screenshot and task instructions, then chooses where to click, what to type, or which tool to call next. Holo4’s response is an action plan or structured tool request; it is not itself a mouse click. A separate runner must capture the screen, send it to the model, and turn the response into actual input.

The model, harness, connected tools, and operating-system permissions are separate components. A model’s request to operate a browser will not run if the harness does not support that tool. Conversely, if the harness has broad browser or file permissions, a bad plan can cause real changes. Do not assume a “local model” makes the task safe or offline.

Choose a read-only first test: find a specific phrase on a non-sensitive test page. Confirm that screenshots and tool requests appear in the logs. Exclude real email, purchases, account settings, and important files from the initial exercise.

The Holo4-27B model card describes a Qwen3.8-based 27B dense architecture and a 262,144-token² context setting. That setting does not guarantee enough memory or speed at that context length³. Screenshots and long action histories also consume memory for vision processing and KV cache⁴.

Holo4-35B-A3B is a different MoE⁵ checkpoint based on Qwen3.6. Distinguish its total weight scale from the active amount per token; it does not need only a 3B-sized file. The 27B license is CC BY-NC 4.0, while 35B-A3B is Apache-2.0. Do not confuse them with similarly named models such as Holotron4; check the exact repository ID.

Permission to use model weights does not grant permission to access websites or automate clicks. Review the runner code, connected tools, and model weights separately. For work use, follow your organization’s legal and security policies.

The execution path must combine a format provided for the model with a backend supported by the runner. Check whether the model card documents Transformers, vLLM, or another implementation, and whether that backend also handles screenshot input and tool calls⁶. Text generation alone does not prove that screen understanding works.

GGUF⁷, FP8⁸, and NVFP4⁹ use different weight representations and have different hardware requirements. A format’s availability does not mean every runner supports it on every GPU¹⁰ or Mac. For NVFP4, verify compatible hardware and kernels; for GGUF, check model and vision support in the current llama.cpp-family version. Do not infer runtime¹¹ memory from file size alone; inspect load logs and device usage.

Check the current installation steps and supported models in the hai-agents quickstart, then begin with a separate test profile. If current documentation conflicts with the installed code or checkpoint support is unclear, do not invent a command; check official releases. This guide does not include new device-specific performance measurements.

Create a separate browser profile or test account and remove sensitive login sessions. Limit access to one test domain and run a read-only task such as “Find the return window and report it.” A successful run should show the runner capturing the page, the model finding the relevant sentence, and the tool call and screen appearing in logs.

Next, allow only reversible local work, such as reading files in a temporary folder and listing them. Confirm the runner cannot open paths outside the approved directory, and compare files before and after the task.

Then test a limited write action. You might allow drafting but block sending, or permit saving a temporary file while requiring approval before overwriting. Before deletion, purchases, message sending, or account changes, have a person verify the target and content. Test that pause/stop works even while a tool call is in progress.

Repeat the same test five times and record success, incorrect clicks, time to the first action, completion time, and number of human interventions. Check whether the agent keeps acting when the layout changes or a popup appears. An agent that is fast but repeatedly targets a dangerous button is not operationally acceptable.

Keep model plans and runner logs, but prevent passwords, personal data, and session tokens from being recorded. Limit screenshot retention and access. Check whether the backend or telemetry sends data externally.

If the screen differs from expectations, the agent should stop and ask a person rather than continue automatically. Prepare recovery steps, such as restoring the temporary folder or resetting the browser, before the test. Adoption criteria should include not only success rate but also impact radius, detection time, ability to stop, and least-privilege controls.

Separately verify that the model loads on your device, that the backend handles vision input and tool calls, and that runner permissions behave as intended. For load failures, check checkpoint, format, and memory; for screen misreading, check the capture path; for tool-call failures, check harness compatibility.

Decide whether five repetitions of the task reduce total time after including human review and corrections. If most work is summarization or code questions, a general language model may be simpler. The case for Holo4 is evidence that it safely reduces real screen-and-tool work within defined boundaries.

Architecture, license, and supported formats are based on the latest official card for each checkpoint. This guide does not report device-performance measurements; verify speed and success rate directly with the runner and task you choose.