OpenHands: opiniones y análisis

TLDR: OpenHands es el agente autónomo de referencia entre los que puedes alojar tú mismo. Le pones una etiqueta a una incidencia de GitHub y trabaja solo hasta dejarte el pull request abierto, todo dentro de un contenedor aislado con terminal y ficheros de verdad. La licencia es abierta y el modelo lo eliges tú, así que lo que pagas son los tokens y no la herramienta. El peaje está en la puerta: necesita Docker y soltura con la terminal.

Qué es OpenHands y cómo funciona

OpenHands empezó como la respuesta abierta a los primeros agentes de programación cerrados, y hoy es el proyecto de su clase con más tracción entre desarrolladores. La descripción corta es que ejecuta un agente dentro de un repositorio de verdad, no que sugiere fragmentos en un chat.

El detalle importa. Cada sesión levanta un contenedor donde el agente tiene una terminal, un sistema de ficheros y un navegador, con el acceso limitado al directorio del proyecto. Ahí planifica, edita, ejecuta comandos, mira si los tests pasan y corrige. Al terminar deja una rama y un pull request para que lo revise una persona, y si no consigue resolver la tarea deja el progreso intermedio con un mensaje explicando dónde se quedó.

El flujo que responde a la pregunta que se hace un equipo es el de la integración con GitHub. Se instala la aplicación en el repositorio, se le pone una etiqueta a la incidencia o se le menciona en un comentario, y el agente arranca sin que nadie tenga que estar delante. La documentación oficial lo describe paso a paso, y el propio proyecto lo usa sobre su propio código.

Dos decisiones más definen el producto. La licencia es abierta y permisiva, así que puedes desplegarlo en tu portátil, en una máquina virtual o en tu propia nube privada. Y es agnóstico de modelo: funciona con tu clave del proveedor que quieras, incluidos modelos abiertos ejecutándose en local. Para equipos con requisitos de privacidad, esas dos cosas juntas valen más que cualquier función.

Cómo es usarlo en el día a día

Donde rinde de verdad es en el trabajo tedioso y acotado. Resolver un conflicto de fusión, arreglar lo que el analizador de estilo marca en rojo, empujar hasta la meta un pull request que se quedó a medias, cerrar una incidencia con reproducción clara. En ese terreno la etiqueta y el pull request de vuelta ahorran una tarde a la semana.

Donde no hay que ponerlo es en tareas abiertas de interfaz. Los propios usuarios señalan que el trabajo visual sale menos fiable que el de servidor, y que el agente a veces se enroca repitiendo un enfoque que ya ha fallado en lugar de probar otro. La lectura razonable es tratarlo como a alguien que acaba de llegar al equipo: capaz, rápido y con el código pendiente de revisión.

La fricción real está en montarlo. Hace falta Docker, hace falta memoria libre y en un portátil de empresa con Docker restringido la instalación se atasca. La documentación asume que vienes de la terminal, así que quien no venga de ahí va a pasar un rato malo antes del primer resultado. También conviene saber que arrancar el contenedor de cada sesión añade una espera que no existe en las herramientas alojadas.

Un aviso práctico de mantenimiento: el proyecto ha cambiado de nombre y de dominio en dos años. Los tutoriales antiguos apuntan a sitios renombrados y a versiones de imagen que ya no son las que sirve la documentación oficial, así que conviene ir a la fuente y no a la primera guía que salga.

Precio y planes

Aquí la respuesta honesta tiene dos partes. La herramienta es gratis: el proyecto es abierto y ejecutarlo en tu máquina no cuesta nada. El nivel individual de su servicio en la nube también figura como gratuito, con la opción de traer tu propia clave de modelo o usar la del proveedor de la casa. Para empresa no hay tarifa publicada, hay que hablar con ellos.

Lo que sí cuesta dinero son los tokens que consume cada tarea, y eso depende del modelo que elijas y de lo larga que sea. No hay una cifra única que dar, y quien te la dé se la está inventando. La forma sensata de estimarlo es medir una semana con tu propio repositorio antes de decidir nada.

El otro coste no aparece en ninguna factura y es real: alojarlo, actualizarlo y depurarlo es trabajo. Si nadie del equipo va a hacerse cargo de eso, una herramienta alojada sale más barata aunque su precio de tarifa sea más alto.

Para quién es (y para quién no)

OpenHands es para equipos que quieren un agente que cierre incidencias sin que el código salga de su infraestructura, para quien ya tiene claves de modelos y prefiere pagar consumo, y para quien quiere entender qué hace un agente por dentro en vez de confiar en una caja cerrada.

No es para quien quiere empezar en cinco minutos. Ahí Jules resuelve lo mismo desde el navegador sin montar nada. Tampoco es para quien busca el agente más pulido con respaldo comercial, que es Devin, ni para quien trabaja en local sobre su propia máquina orquestando varias sesiones, terreno de Conductor.

Alternativas a OpenHands

El reparto es claro. Jules si quieres delegar sin instalar, Devin si quieres producto terminado y no proyecto, Conductor si tu forma de trabajar es lanzar varios agentes en paralelo desde el escritorio. Están en alternativas a OpenHands y el conjunto en las mejores IA para programar.

Preguntas frecuentes

¿De verdad abre el pull request solo?

Sí, es su flujo documentado: etiquetas la incidencia o mencionas al agente en un comentario, y él trabaja hasta dejar el pull request abierto. Si no lo consigue, deja la rama con lo que llevaba y explica dónde se quedó. Revisarlo sigue siendo obligatorio.

¿Hace falta Docker?

Sí, y es el requisito que más gente deja fuera. En Windows además pide el subsistema de Linux. Si no puedes instalar Docker en tu equipo de trabajo, esta no es tu herramienta.

¿Qué modelo usa?

El que tú le pongas. Funciona con los modelos punteros de los grandes proveedores y también con modelos abiertos ejecutándose en tu propia máquina, que es la vía de quien no quiere que el código salga de casa.

¿Cuánto cuesta cada tarea?

Depende del modelo y del tamaño de la tarea, y no hay una cifra publicada que sirva para todos los casos. Mide una semana con tu repositorio antes de decidir, porque la diferencia entre un modelo y otro es de varias veces.

¿Sirve para código de producción?

Sirve para preparar el cambio, no para saltarse la revisión. La recomendación que repiten quienes lo usan a diario es revisar cada pull request que abre, igual que se revisaría el de alguien que acaba de entrar.