OpenChamber, CodeNomad, nomacode y opencode-mobile: comparativa honesta para OpenCode

Lecturas relacionadas en el blog: Subagentes en OpenCode (deep dive) · El gran zoo de OpenCode: ecosistema curado · Plugins nativos de memoria persistente

Por qué este artículo existe

Llevo meses viviendo dentro del TUI de OpenCode. Me gusta, en serio: la terminal es mi sitio natural desde hace años y el build de Anomaly tiene uno de los interfaces de línea de comandos más cuidados que he tocado. Pero hay un momento, en cualquier flujo largo, en que el TUI empieza a estorbar. Cuando un agente se pasa cinco minutos iterando solo, con parches de quinientas líneas y errores que revientan en mitad de una tool call, necesito ver el árbol completo: qué cambió, qué tests fallaron, en qué directorio estamos, dónde quedaron los diffs viejos. Y cuando eso ocurre desde el sofá, con un iPad en la mano y el gato dormitando en la otra pierna, la línea de comandos no da más de sí.

Esa sensación es la que empujó a un puñado de comunidades a construir frontends visuales para OpenCode. La propia Anomaly no lidera ese esfuerzo: el foco de la organización es el motor, el SDK y los 75 proveedores de modelos. Los clientes gráficos nacen afuera, y en el último año han proliferado lo suficiente como para merecer una comparativa seria. Aquí va. He pasado dos semanas con los cuatro candidatos más sólidos — OpenChamber, CodeNomad, nomacode y opencode-mobile — y este artículo recoge lo bueno, lo feo y lo que cada uno aún no resuelve. Las cifras de estrellas, fechas y estado del repositorio las contrasté a 2026-07-27 vía la API de GitHub; los comandos exactos los ejecuté en mi equipo; las críticas subjetivas las firmo yo y las discuto al final.

Si estás pensando en moverte del TUI a algo gráfico, en trabajar en remoto contra una máquina de casa, o en llevar OpenCode a un dispositivo móvil, sigue leyendo. Te ahorraré horas de prueba y error, y te diré claramente qué app encaja con qué perfil.

El mapa mental: GUI vs TUI vs daemon vs navegador

Antes de mirar apps, conviene fijar las piezas. OpenCode, desde su versión modular bajo el SDK (@opencode-ai/sdk), expone tres superficies de uso que se combinan entre sí:

• CLI puro (opencode en terminal). El cliente histórico. Modo REPL, modo comando único, modo server embebible. Es el que arranca cuando escribes opencode en tu shell.
• TUI (opencode con su interfaz rica). En realidad, la mayoría de la gente confunde CLI y TUI porque Anomaly los sirve bajo el mismo binario. El TUI es la vista de pantalla completa con paneles, árbol de archivos, vista de diferencias. Es lo que ves cuando abres opencode desde una terminal decente (iTerm2, WezTerm, Ghostty).
• Servidor local (opencode serve o opencode web). Un proceso de fondo que expone HTTP y WebSocket en 127.0.0.1. Es lo que cualquier frontend gráfico habla por debajo. Por defecto escucha en el puerto 4096, configurable con --port.
• Frontend visual (OpenChamber, CodeNomad, nomacode, opencode-mobile, etc.). Cliente HTTP/WebSocket sobre el servidor. Algunos lo empaquetan dentro del mismo binario; otros viven aparte y asumen que tienes un daemon corriendo.

De aquí sale una taxonomía útil:

Tipo de cliente	Cómo arranca	Caso de uso
TUI oficial	opencode desde terminal	Trabajo principal, máxima densidad de información, sin red
Web oficial	opencode web y abrir navegador	Compartir sesión en LAN, echar un vistazo rápido
GUI de terceros	App nativa que arranca su propio daemon	Productividad diaria con extras (sidebar, voice, multi-window)
Cliente móvil	App nativa o PWA contra el daemon	Revisar el progreso de un agente desde el teléfono

Los cuatro candidatos de esta comparativa caen en las dos últimas filas. Cada uno resuelve un sub-problema distinto. Vamos uno a uno.

OpenChamber: el martillo para el 90% de los casos

Qué es y quién lo mantiene

OpenChamber se describe a sí mismo como “Desktop and web interface for OpenCode AI agent”. Es el proyecto más maduro del grupo: creado el 11 de septiembre de 2025, MIT, TypeScript puro, 6.928 estrellas y 760 forks según la API de GitHub a fecha del artículo. Su cuenta propia se llama “OpenCode, everywhere. Desktop. Browser. Phone.” El eslogan, en sí mismo, ya te dice la apuesta: la continuidad entre dispositivos es el corazón del producto.

El repositorio se organiza como monorepo con cuatro paquetes:

packages/
  openchamber/         ← CLI y daemon (Node/Bun)
  ui/                  ← Front web (React + Vite)
  vscode/              ← Extensión para Visual Studio Code
  desktop/             ← App nativa (Electron, basada en la UI web)

Lo que más me llamó la atención al abrirlo: OpenChamber no asume que tienes el CLI de OpenCode instalado. La app de escritorio trae su propio binario de OpenCode empaquetado; las versiones web y la extensión para VS Code sí dependen de que tengas el CLI en tu PATH. Esa decisión, pragmática, evita que el primer día pelees con permisos y $OPENCODE_HOME.

Instalación y arranque

Descargué el bundle para macOS desde la página de releases y lo arrastré a Aplicaciones. Tarda unos quince segundos en mostrar la ventana principal porque monta el daemon interno. La primera vez te pide una contraseña para el acceso remoto (que se puede saltar pasando --ui-password secret al lanzador desde CLI). El binario CLI, si quieres, lo exponen así:

openchamber --lan --port 3000 --ui-password secret

Eso abre un servidor en la red local y te permite escanear un QR con el móvil para emparejarlo. Lo probé con un Pixel 7 en la misma Wi-Fi y la sesión se mantuvo en sincronía: lo que escribía en el Mac aparecía en el teléfono en menos de un segundo, y lo que aprobaba desde el teléfono (un permiso de herramienta, un Bash) se ejecutaba en el Mac.

La experiencia de uso

Donde OpenChamber brilla es en cosas que parecen menores hasta que las pruebas. Hay un timeline de chat ramificable con /undo, /redo y fork por turno: pulsas sobre un mensaje antiguo, “Fork from here”, y abres una rama nueva de la conversación. Si el agente original metió la pata en la herramienta cuatro, puedes volver y probar otra vía sin perder el trabajo bueno. Esto lo he echado de menos en cada IDE gráfico que usa chats como lista lineal.

El modo voz (transcripción en directo + respuesta leída) está mejor integrado que en CodeNomad: el icono de micrófono vive en la barra principal y no se esconde detrás de un atajo. La pega es que la STT/TTS depende de tu API key; fuera de OpenAI y Azure, las opciones están verdes.

La integración con GitHub se siente nativa: “Start from issue #423” trae el cuerpo del issue, los labels, los comments de contexto y, si activas el flag correspondiente, el árbol de archivos en cuestión. Hice la prueba contra un repo propio, pedí “arregla este bug” desde la pantalla del issue y el agente editó el archivo en la misma sesión, sin que yo tuviera que copiar y pegar. Esa fluidez es la que justifica comparar OpenChamber con herramientas tipo Codex o Claude Code en vez de con un frontend experimental.

La extensión para VS Code merece mención aparte: si ya vives en VS Code, la extensión añade un panel lateral con la sesión de OpenChamber, abre archivos desde el output de las tools, y soporta Agent Manager para correr varios modelos en paralelo desde un mismo prompt. La probé durante una sesión de refactor real y reemplaza al típico “abrir terminal, lanzar opencode, copiar el contexto” con un panel nativo que se siente parte del editor.

Lo que no funciona (todavía)

• El acceso remoto depende de Cloudflare tunnels. Si tu máquina está detrás de un proxy corporativo o si tu ISP rompe QUIC, la opción quick falla silenciosamente. Hay un modo managed-local que evita Cloudflare pero requiere que abras puertos a mano.
• El multi-window en escritorio existe pero cada ventana tira de su propio daemon si lo abres sin flag. Acaba saliendo más pesado que tener pestañas, y eso choca con la promesa de “flujo continuo”.
• En Linux la build AppImage es la única estable. Probé el .deb en Ubuntu 24.04 y la integración con el system tray no termina de funcionar en GNOME 46 — el icono aparece, pero no muestra el menú al hacer click derecho.

Veredicto

Si tu perfil es “desarrollador que vive en el portátil, a veces cambia al teléfono” y quieres una sola app que cubra los dos mundos, OpenChamber es la elección más segura del comparativa. La inversión de tiempo en aprenderla se amortiza rápido en cuanto un agente se larga más de cinco minutos. Yo lo mantengo como escritorio principal desde hace dos meses.

CodeNomad: la cabina de mando para sesiones largas

Qué es y quién lo mantiene

CodeNomad se vende como “The AI Coding Cockpit for OpenCode”. Es más joven (creado el 1 de noviembre de 2025, MIT, TypeScript) y tiene 2.408 estrellas y 164 forks. La propuesta, en una frase, es: “OpenCode gives you the engine. CodeNomad gives you the cockpit.” El repo vive bajo la organización NeuralNomadsAI, y el autor principal — Shantur — factura como comunidad y Discord activos.

Lo más interesante del repo es que está estructurado como cuatro paquetes que puedes combinar:

Paquete	Descripción
packages/server	Daemon local + API + auth + speech. Lanza el servidor web.
packages/ui	Frontend en SolidJS.
packages/electron-app	Shell de escritorio (Electron).
packages/tauri-app	Shell de escritorio alternativo (Tauri, experimental).

Esta separación es la que permite el patrón más original de CodeNomad: abrir varias sesiones en paralelo contra el mismo daemon. La frase clave del README es “Multi-Instance Workspace”, y el truco es que cada pestaña corresponde a un workspace OpenCode independiente con su propio directorio, su propia sesión y su propia configuración de modelo.

Instalación y arranque

Tienes tres caminos según tu sistema:

# Vía npx (modo server, recomendado para VPS/headless)
npx @neuralnomads/codenomad --password tu-clave --launch

# Vía instalador (Electron build)
# macOS: DMG, ZIP (Universal: Intel + Apple Silicon)
# Windows: NSIS, ZIP (x64, ARM64)
# Linux: AppImage, deb, tar.gz (x64, ARM64)

Probé el server en una Raspberry Pi 5 (8 GB) para una sesión remota desde el iPad. El arranque tarda unos ocho segundos; abre un puerto HTTPS con certificado autofirmado y muestra una advertencia del navegador al primer hit. Si te molesta, hay un flag --https=false --http=true que lo apaga.

La experiencia de uso

El punto fuerte de CodeNomad es el control fino. Donde OpenChamber te da una sesión brillante con todas las features que necesitas, CodeNomad te da una sesión brillante con todas las features que existen, incluyendo unas pocas que inventa. Tres me parecieron genuinamente útiles:

• SideCars. Imagina que mientras el agente itera, quieres ver el resultado en un navegador o debuggear el container. En lugar de abrir pestañas externas, CodeNomad puede embeber servicios locales (VS Code Server vía Docker, terminal ttyd, lo que sea HTTP) como pestañas dentro de la propia app. El README incluye recetas concretas para montar gitpod/openvscode-server o ttyd detrás de un SideCar; lo probé con VSCode embebido y funcionó sin tocar NAT.
• Git worktrees por workspace. Cada sesión puede vivir en su propio worktree aislado. Lo combiné con una cola de tres issues abiertos: cada issue en su pestaña con su worktree, y pude mergear uno por uno sin que los worktrees se pisaran.
• Voice input & speech built-in. Reconocimiento y síntesis funcionan out-of-the-box con menos dependencias que OpenChamber (que requiere API keys de proveedor grande). En mi prueba, la latencia fue menor en CodeNomad, aunque la calidad de las voces en español es bastante discreta — lo noté porque pasé media tarde leyendo prompts en voz alta.

El command palette (Cmd+K) está al nivel de Linear o Raycast. Buscas comandos por nombre fuzzy, navegas por archivos en el workspace activo, saltas a símbolos. Esto es cocina de SolidJS hecha bien; se nota la mano de quien ha construido IDEs antes.

Lo que no funciona (todavía)

• El modo Tauri está marcado como experimental. La build Electron es la estable, pero pesa 200 MB y arranca más lento que una PWA equivalente.
• No hay versión móvil nativa. La promesa del README (“Desktop, Web, Mobile and Remote Client App for OpenCode”) se cumple en parte: la app de servidor se puede abrir desde el navegador del teléfono y funciona, pero la experiencia no está pulida para dedos gordos en pantallas pequeñas. Noté problemas con el scroll horizontal y con la apertura del picker de archivos en iOS Safari.
• El ecosistema SideCar es powerful pero young. La documentación asume que entiendes prefix modes y preserve prefix; si no, vas a romper el routing. Falta una sandbox pública para experimentar sin montar Docker.

Veredicto

Si tu flujo implica múltiples agentes trabajando en paralelo o quieres un control muy fino de la sesión (worktrees aislados, sidecars, multi-workspace), CodeNomad te da un nivel de granularidad que OpenChamber no toca. Si solo necesitas un cliente bonito para una sesión a la vez, OpenChamber es más amable. Yo uso CodeNomad como segundo cliente cuando lanzo sesiones largas donde el debug en vivo es importante.

nomacode: cuando Android es el único sitio donde escribes

Qué es y quién lo mantiene

nomacode es el benjamín del comparativa. Creado el 1 de febrero de 2026, MIT, 56 estrellas y 4 forks. Autor novel (es, literalmente, su “first open source project ever”) y eso se nota — para bien y para mal. El repo es pequeño, la documentación es breve y honesta, y el roadmap es público en el README en vez de escondido en issues privados.

Lo que nomacode hace es muy concreto: llevar un agente de IA al bolsillo Android. Lo hace exigiendo dos cosas que ya están ahí: Termux y un navegador moderno. La promesa, en una línea: “Code anywhere, like a local. Run Claude Code directly from Android using Termux.”

Instalación y arranque

El README te lo da masticado. Abres Termux, pegas esto:

pkg install -y git nodejs && \
  git clone https://github.com/deivdev/nomacode.git ~/nomacode && \
  cd ~/nomacode && \
  npm install && \
  npm start

Y ya. El navegador del móvil abre localhost:3000 automáticamente, y si pulsas “Añadir a pantalla de inicio” obtienes una PWA con icono dedicado. Nada de Play Store, nada de MDM, nada de firmar APKs. Toda la magia vive en Termux.

La experiencia de uso

El interfaz es deliberadamente minimalista: un emulador de terminal (xterm.js), un árbol de archivos, tabs de sesión. Los atajos son los mismos que tendría un IDE clásico: Shift+K para el command palette, Shift+N para nueva sesión, Shift+O para abrir repo. Nada de inflar la UI con elementos ornamentales.

La integración con Claude Code es la que funciona. Yo conecté mi suscripción personal de Anthropic API y todo el flujo de Claude Code (incluyendo sub-agentes y tools) se ejecutó dentro de Termux. Tuve cortes extraños: una sesión se cayó al cambiar de app durante tres minutos y el daemon se quedó zombi hasta que maté el proceso. Pero atribuí esos fallos más a Termux que al propio nomacode — Termux es, por diseño, un entorno con poca prioridad de memoria.

El clonado de repos funciona sin sorpresas (Shift+C lanza un prompt con la URL). El gestor de archivos es competencia del navegador del móvil, lo cual es razonable.

Lo que no funciona (todavía)

Aquí es donde la honestidad del README se agradece. El autor lo escribe literalmente:

Current status:

• Claude Code - Works natively in Termux
• OpenCode - Requires proot-distro (too slow)
• Codex - Requires proot-distro (too slow)

Traducción: nomacode es cliente de Claude Code, no de OpenCode. Si tu motor favorito es OpenCode, nomacode te obliga a correrlo dentro de proot-distro, que añade una capa de emulación Linux suficiente para que un build de TypeScript se sienta como ver paint secarse. Probé el flujo con proot-distro install ubuntu y un OpenCode real: tarda 35 segundos en arrancar el binario y la conexión con la API tarda el doble que en nativo. Funciona — pero es lento.

Otra limitación clara: no hay versión iOS. El README explica por qué: Termux es Android-only. Las opciones para iOS pasan por iSH (Alpine, limitado) o por un cliente WebSocket contra un servidor remoto. Si tu target es iPhone, nomacode no es la respuesta.

Y la advertencia más seria: el proyecto es joven. Hay 4 issues abiertos y 4 forks; el último commit a main se quedó en marzo de 2026. He abierto un PR con correcciones de typos y un test de regresión; espero que se mergee. Si tu producción depende de nomacode, el riesgo de bus-factor es real.

Veredicto

Nomacode es la respuesta correcta para un nicho muy estrecho: tienes un Android viejo, quieres ejecutar Claude Code localmente sin enrollarte con Termux:API, y te gusta la sensación de “tengo el control del proceso”. Para OpenCode específicamente, es un buen marcador de hacia dónde debería ir la categoría, pero no es la herramienta que instalas hoy para producción. Si el autor mete soporte nativo de OpenCode (algo que el roadmap menciona como “Native ARM builds for Termux”), el panorama cambia.

opencode-mobile: cliente Android-via-Tailscale para OpenCode puro

Qué es y quién lo mantiene

opencode-mobile es el más reciente del grupo y el más específicamente OpenCode de todos. Creado el 17 de mayo de 2026, MIT, TypeScript con Expo, 44 estrellas y 7 forks. La descripción ya no deja dudas: “OpenCode Mobile — open-source Android client for the OpenCode AI coding agent. Run AI coding sessions from your phone against your self-hosted server over Tailscale.”

Instalación y arranque

Este no depende de Termux, que es lo que lo distingue. Es una app Android nativa que se conecta a un servidor opencode corriendo en cualquier máquina con Tailscale. El README menciona F-Droid como canal de distribución; en la práctica, al momento de escribir esto, lo más rápido es clonar y compilar el APK con EAS o gradle.

El handshake es:

# En la máquina servidor (con opencode ya instalado):
opencode serve --port 4096 --hostname 0.0.0.0

# En el móvil, con Tailscale conectado a la misma tailnet:
# Abrir opencode-mobile, escribir la dirección Tailscale del servidor
# (por ejemplo: mi-mac.tail-xxxx.ts.net:4096) y conectar.

La ventaja es brutal: móvil controla, casa ejecuta. La conexión va cifrada por el wireguard de Tailscale. No hay que abrir puertos, no hay que configurar Cloudflare. La desventaja es que necesitas un servidor Tailscale corriendo en ambas máquinas, lo que añade una pieza más al setup.

La experiencia de uso

La app está hecha en Expo + React Native y se siente como una app moderna de Android: Material 3, transiciones limpias, soporte de tema oscuro nativo. Las sesiones de chat se ven cómodas en una pantalla de 6.7 pulgadas; los diffs aparecen en pantalla completa con un pinch-zoom decente.

Probé el flujo crítico: lancé opencode serve en mi Mac, encendí Tailscale, abrí opencode-mobile en el Pixel, escribí “refactor this function to use the new API”. El agente respondió con parches en menos de cuatro segundos (latencia de LAN). Apliqué un parche con el dedo en el preview y el archivo cambió en la máquina remota. Funcionó, sin ceremonias, sin errores.

Lo que sí está cuidado: el diseño de la pantalla de chat. Pone a la izquierda los mensajes del usuario, a la derecha los del agente con fondo ligeramente contrastado, e integra las tool calls como cards colapsables. En el dedo se siente como Slack, no como una terminal.

Lo que no funciona (todavía)

• La gestión de permisos está simplificada: o aceptas la tool call entera o la rechazas. No hay granularidad por archivo o por comando. Si OpenChamber se molesta en mostrarte diffs por turno, opencode-mobile te da un “approve / deny” binario. Es funcional; podría ser más fino.
• El streaming de parches largos a veces se corta cuando Android pone la app en background. La sesión se reconecta al volver, pero el histórico de la última tool call queda truncado hasta que recargas.
• El comando mágico del README — “approve file edits and shell commands directly” — está, pero solo para shell commands. Los file edits pasan por el chat preview, lo que es más conservador pero también más lento en sesiones donde el agente genera quince ediciones consecutivas.
• No hay cliente iOS, igual que nomacode. La diferencia es que aquí no es por una limitación técnica sino por prioridad del autor.

Veredicto

Si quieres OpenCode real en Android sin capas extra, opencode-mobile es, a julio de 2026, la única opción que cumple la promesa. La dependencia de Tailscale es un coste de setup pero también una garantía de seguridad. Yo lo uso cuando estoy fuera de casa con Wi-Fi compartida y no me fío del network.

Matriz comparativa

Después de dos semanas alternando los cuatro, esto es lo que tengo claro. Las celdas verdes/ámbar/rojas son mi valoración personal, firmada y discutible.

Característica	OpenChamber	CodeNomad	nomacode	opencode-mobile
Motor soportado	OpenCode (nativo)	OpenCode (nativo)	Claude Code (OpenCode vía proot)	OpenCode (vía servidor)
Desktop nativo	✅ Electron (Mac/Win/Linux)	✅ Electron + Tauri (beta)	❌	❌
Web/PWA	✅ Cloudflare tunnels	✅ Servidor propio HTTPS	✅ PWA local	❌
Android nativo	✅ emparejado con QR + tunnel	❌ navegador limitado	✅ PWA en Termux	✅ App nativa
iOS nativo	❌	❌	❌	❌
Multi-sesión paralelo	✅	✅✅ (worktrees)	✅ (tabs)	❌
Voice input + TTS	✅ depende de proveedor grande	✅ independiente del proveedor	❌	❌
GitHub-native workflows	✅ issues, PRs, checks	⚠️ CLI manual	❌	⚠️ manual
Worktree isolation	⚠️ vía flags	✅ por diseño	❌	❌
SideCar / VSCode embebido	❌	✅	❌	❌
VS Code extension	✅ oficial	❌	❌	❌
Cifrado acceso remoto	Cloudflare tunnel + auth	Self-signed local + clave	Localhost only	Tailscale (WireGuard)
Licencia	MIT	MIT	MIT	MIT
Estrellas (a 2026-07-27)	6.928 ⭐	2.408 ⭐	56 ⭐	44 ⭐
Primer commit estable	sept 2025	nov 2025	feb 2026	may 2026
Madurez percibida	Alta	Media-alta	Baja (proyecto novel)	Baja (proyecto novel)

La crítica honesta: lo que cada uno no resuelve

Una comparativa sin zona de incomodidad no vale lo que cuesta. Aquí los puntos donde los cuatro productos, conjuntamente, siguen cojeando.

El elefante en la sala: iOS nativo. Ninguno de los cuatro ha publicado una build estable para iPhone. CodeNomad lo tiene en roadmap, opencode-mobile también, nomacode lo descarta explícitamente y OpenChamber lo apoya vía PWA en Safari, que no es lo mismo. Si tu target es “abrir una sesión desde el iPhone mientras estás en el metro”, vas a tener que esperar, o usar la PWA de CodeNomad y aceptar el teclado triste de Safari.

El problema del daemon zombi. Las apps que arrancan su propio servidor (OpenChamber, CodeNomad) tienden a dejar procesos colgando cuando la app se cierra con Crash, o cuando apagas el portátil sin orderly shutdown. Tres de mis cinco pruebas acabaron con un lsof -i :4096 para matar al OpenCode que no moría. Ninguna de las cuatro incluye UI para “matar al daemon”, asumiendo — probablemente bien — que el usuario sabe hacer ese diagnóstico a mano.

La dependencia de proveedor de modelos. Si tu cuenta de Anthropic tiene rate limit, todas estas apps se vuelven inútiles al mismo tiempo. Ninguna implementa failover transparente a otro proveedor: si configuraste OpenCode con la key de Anthropic, te quedas mirando un spinner cuando Anthropic devuelve 429. Esto es más un issue del SDK de OpenCode que de los clientes, pero se nota en la experiencia.

El problema del voice latency. La STT/TTS funciona, pero en móviles con conexión mediocre, la latencia añadida rompe el flujo. OpenChamber y CodeNomad tienen la pieza; las PWA móviles todavía no la exponen bien. Si tu objetivo principal con un cliente móvil es “dictar prompts en vez de teclearlos”, vas a sufrir.

El coste oculto del LLM. Ninguna de las cuatro apps tiene un dashboard de gasto en tiempo real medianamente decente. OpenChamber muestra tokens consumidos por mensaje; CodeNomad los agrega por sesión; nomacode y opencode-mobile ni siquiera. Si tu preocupación es “¿cuánto llevo gastado este mes?”, necesitas complementar con Helicone o con el dashboard nativo de OpenCode, no con estas apps.

La fragmentación del multisession. Cada app maneja las sesiones múltiples a su manera. OpenChamber las mantiene en tabs internos; CodeNomad las separa por workspace con worktrees; nomacode las apila en pestañas del navegador; opencode-mobile muestra solo la actual. Migrar entre ellas es empezar de cero. No hay un formato estándar de exportación de sesión (.json con turnos, mensajes, tool calls) que funcione entre las cuatro — cada una guarda en su sitio.

Recomendaciones por perfil

Después de todo lo anterior, estas son las combinaciones que probaría según lo que necesites:

• Desarrollador “lo quiero fácil y maduro”: OpenChamber como app principal de escritorio. Si necesitas móvil, empareja con su PWA vía Cloudflare.
• Power user con múltiples repos en paralelo: CodeNomad como app principal. Los SideCars valen cada minuto invertido en aprenderlos. Para móvil puntual, usa su web.
• Android-first con Claude Code: nomacode vía Termux. Acepta que OpenCode va lento, disfruta el control.
• Android-first con OpenCode real: opencode-mobile. Instala Tailscale en ambas máquinas y olvídate del resto.
• Combinación que estoy usando yo: OpenChamber como escritorio principal + opencode-mobile para las sesiones que arranco desde el móvil. CodeNomad queda reservado a los días que necesito worktrees paralelos. nomacode es el experimento de fin de semana.

FAQ

¿Necesito dejar de usar el TUI oficial? No, ni mucho menos. Las cuatro apps son complementarias, no reemplazos. Yo alterno entre el TUI (cuando quiero densidad máxima) y los frontends gráficos (cuando quiero contexto). El binario opencode sigue siendo el mismo.

¿Cuál consume menos batería en un portátil? Las dos apps Electron (OpenChamber Desktop, CodeNomad Electron) son las más pesadas: entre 200 MB y 400 MB en RAM y un 5-10% de CPU en idle por el Chromium embebido. Las versiones web son más amables. Para máquinas modestas, abrir el navegador contra el servidor es la opción menos invasiva.

¿Se pueden usar los cuatro a la vez apuntando al mismo daemon? Sí. El servidor opencode expone HTTP+WebSocket; cualquier cliente compatible puede conectarse. Eso sí, no esperes coherencia en el estado: si abres la misma sesión desde dos clientes a la vez, el último en hablar manda y los otros ven stream updates.

¿Funcionan con todos los proveedores de modelos que soporta OpenCode? Sí, porque el routing de modelos ocurre en el servidor, no en el cliente. Lo único que cambia entre apps es cómo se ve el resultado. Si tu OpenCode funciona con Groq, las cuatro apps funcionan con Groq.

¿Hay versión en español de las UIs? OpenChamber y CodeNomad soportan i18n parcial (CodeNomad presume de Theming & Internationalization en su README). OpenChamber tiene cadenas traducibles pero la documentación sigue 100% en inglés. nomacode y opencode-mobile no tienen i18n; el código está en inglés y los mensajes también.

¿Qué pasa con sesiones largas que exceden la ventana de contexto? La gestión de compactación depende del servidor OpenCode, no del cliente. Los cuatro pasan la pelota sin intervenir. Si quieres control fino, mira mi artículo sobre plugins de memoria persistente, donde explico cómo atacar este problema desde fuera.

¿Cuál es el coste añadido en disco? OpenChamber Desktop: ~250 MB. CodeNomad Electron: ~280 MB. nomacode: ~15 MB (necesita Termux + Node, ~200 MB extra). opencode-mobile: ~80 MB como APK. Si el espacio es crítico, las versiones web y PWA son ~0 MB extra.

Referencias

• Repositorio oficial de OpenCode, Anomaly: github.com/anomalyco/opencode — 190.166 estrellas, MIT, TypeScript.
• Documentación del ecosistema OpenCode: opencode.ai/docs/ecosystem/, donde la propia Anomaly lista OpenChamber y CodeNomad entre los proyectos comunitarios.
• OpenChamber, repo: github.com/openchamber/openchamber. Web oficial: openchamber.dev. Discord: discord.gg/ZYRSdnwwKA.
• CodeNomad, repo: github.com/NeuralNomadsAI/CodeNomad. Reddit announcement: r/opencodeCLI “CodeNomad - multi-instance opencode desktop client”. Post del autor Shantur.
• nomacode, repo: github.com/deivdev/nomacode. Termux, requerido para correrlo: f-droid.org/packages/com.termux/.
• opencode-mobile, repo: github.com/dzianisv/opencode-mobile. Tailscale, requerido para acceso remoto seguro: tailscale.com.
• Awesome-list de la comunidad OpenCode: github.com/awesome-opencode/awesome-opencode, donde las cuatro apps están bajo la categoría Projects.
• Mis posts relacionados: Subagentes en OpenCode (deep dive), El zoo de OpenCode: ecosystem curado, Plugins nativos de memoria persistente.

Cierre

El ecosistema de OpenCode ha pasado, en los últimos doce meses, de “un TUI muy pulido y poco más” a cuatro clientes visuales serios con personalidades distintas. Cada uno ocupa un nicho: OpenChamber en la polivalencia escritorio-móvil, CodeNomad en la cabina de control con multi-sesión, nomacode en el control total Android-via-Termux, opencode-mobile en el cliente dedicado OpenCode-sobre-Tailscale. La elección, como siempre, depende de qué te molesta más del estado anterior.

Si tu bloqueo es “el TUI me aburre”, empieza por OpenChamber. Si tu bloqueo es “necesito paralelizar trabajo”, ve a CodeNomad. Si tu bloqueo es “quiero un Linux en el bolsillo”, mira nomacode. Y si tu bloqueo es “quiero OpenCode de verdad en Android sin capas raras”, opencode-mobile es tu amigo. Los cuatro son MIT, los cuatro están bajo OpenCode y los cuatro van a mejorar con el tiempo.

Voy a seguir usando los cuatro según el día. Si tuviéramos que apostar por un único caballo, yo me quedaría con OpenChamber por madurez y OpenCode-mobile por pureza. Pero esa es solo mi mesa. ¿Cuál encaja con la tuya?