Ejecuta una tarea real de escritorio con Holo4 27B y mide lo que cuesta el 61,7%

Tienes una tarea de escritorio que un modelo de pago de uso de computadora ya resuelve, y quieres saber si un modelo local puede hacerlo por menos. En OSWorld 2.0, Holo4 27B alcanzó 61,7%, Opus 5.5 alcanzó 81,8% y Holo4 35B-A3B alcanzó 30,9%. La puntuación pública es útil, pero no es tu factura.

H Company publicó los pesos de Holo4 en el blog de Hugging Face el 28 de septiembre de 2026. La familia incluye un modelo denso de 27B y un modelo de mezcla de expertos de 35B-A3B. Puedes descargar pesos en BF16, FP8, NVFP4 o GGUF de 4 bits. H Company reconstruyó el harness de Holo4 para añadir memoria fiable de secuencia larga y una shell en la máquina de escritorio.

Prueba primero el modelo denso de 27B. El otro modelo es una decisión distinta.

La brecha de benchmark es la cuota de entrada

El resultado público dice que Holo4 27B es competitivo. No dice que tu tarea pasará. La Agentic Task Factory de H Company había generado aproximadamente 10.000 tareas que abarcan aplicaciones web, servidores MCP y entornos de escritorio. La amplitud importa porque una tarea real de escritorio rara vez es un trabajo limpio de un solo ámbito. Si tu tarea toca más de uno de esos ámbitos, haz que sea la prueba local.

Tu propia tarea es el benchmark real

Ejecuta el protocolo antes de cambiar tu pila de automatización. La salida es una decisión, no una demo. Tu condición de éxito es la parte de la prueba que controlas. No dejes que el agente improvise la condición de éxito. Un borrador guardado no es éxito si la tarea requiere un archivo final.

• Elige una tarea representativa de escritorio que de otro modo enviarías a tu línea base de pago. Hecho significa un estado inicial claro, un estado final requerido y un plazo que aceptarías en producción.
• Define éxito/fallo antes de la ejecución. Escribe la regla: la tarea pasa solo cuando el archivo existe, el formulario se envía, la ventana se cierra o aparece el valor esperado.
• Ejecuta Holo4 27B en tu máquina local. Elige una precisión que se ajuste a tu memoria y usa el harness. Registra el resultado como una finalización, un fallo o un tiempo agotado, con el estado de la máquina guardado.
• Registra el éxito, las llamadas del agente, los tokens, el coste que habrías pagado y el modo de fallo. Pon la fila en una tabla, no en un párrafo de impresiones.
• Compara la fila con tu línea base de pago actual. Si tu línea base de pago es Opus 5.5, usa la misma tarea y la misma condición de éxito. Termina con una respuesta clara: seguir pagando, autoalojar o rechazar la tarea.

Mantén el entorno estable entre intentos. No cambies la cuenta, los archivos ni las versiones de las aplicaciones. Si la tarea necesita un estado limpio, indícalo en la regla de éxito/fallo. Si no, no limpies la máquina solo porque el primer intento pareció incorrecto.

La ejecución debe producir una decisión

En un ejemplo publicado de Godot estilo Pac-Man, Holo4 27B usó 68 llamadas del agente y 2,4 millones de tokens, mientras que Qwen3.8 27B usó 197 llamadas y 11,4 millones de tokens. Usa eso como una comprobación de sentido para tu propio registro. Si tu tarea necesita muchas llamadas, el recuento de tokens moverá la conversación sobre el coste más rápido que la tasa de éxito.

Trata ese ejemplo como una calibración, no como tu tarea. Muestra que el recuento de llamadas y el recuento de tokens pueden divergir del éxito bruto. Un modelo puede terminar un juego y aun así quemar tokens en una tarea que te importa.

Luego lee la fila como una nota de laboratorio. ¿Holo4 27B pasó? ¿Cuántas llamadas le tomaron? ¿Cuántos tokens quemó? ¿Qué modo de fallo apareció? ¿La shell ayudó o la memoria de secuencia larga falló?

Mantén el modo de fallo separado de la puntuación. Un clic equivocado, un archivo omitido, una ventana obsoleta y una llamada de herramienta incorrecta son problemas distintos. Apuntan a soluciones distintas.

Si la tarea pasa y el coste registrado es menor que tu línea base de pago, el autoalojamiento tiene un caso. Si falla, ya conoces el modo de fallo antes de gastar el mes. Si pasa pero el recuento de tokens es malo, mantén el modelo de pago para esa tarea y prueba otra.