En el ecosistema de agentes de Cloudflare aparecen muchos nombres a la vez: Flue, Think, Computer, shell, just-bash, container, Sandbox.
La pregunta fácil es:
¿Cuál uso?
La pregunta útil es otra:
¿Qué capa del stack necesito para este trabajo?
No son cuatro rivales en el mismo estante. Se apilan. Si los confundes, terminas levantando un container por cada cat, o montando un harness de chat cuando solo necesitabas un agente de tarea por CLI.
El stack en tres capas
framework -> forma del proyecto, CLI, canales, dónde corre
harness -> el loop: modelo → tools → resultados
runtime -> archivos, compute y backends debajo del loopDónde cae cada nombre:
| Capa | Qué resuelve | Nombres |
|---|---|---|
| Framework | Estructura, deploy, headless vs UI | Flue |
| Harness | Conversación, memoria, streaming, tools | Think (first-party); también harnesses tipo Pi |
| Workspace / runtime | Archivos + ejecución | @cloudflare/computer, @cloudflare/shell |
| Platform | Agents SDK, Durable Objects, storage | Debajo de todo |
También puedes armar el loop tú mismo con packages sueltos (shell, codemode, Dynamic Workers) sobre un Agent base. Es válido. No es “gratis”: te toca ser dueño del loop.
Flue vs Think
No digas:
“Flue o Think: elijo el más nuevo.”
Mejor:
“Flue arma el producto-agente; Think es el harness de chat.”
Flue es un framework de agentes en TypeScript. Harness-first (alrededor de Pi). Multi-target: Node (GitHub Actions, VMs, servers) o Durable Objects en Cloudflare. Headless o con UI. En Cloudflare usa primitivas del Agents SDK (Durable Objects, fibers, codemode, shell). Fuera puede seguir multi-cloud.
Think (@cloudflare/think) es el harness de chat de Cloudflare. Maneja el loop, el streaming, los mensajes, la memoria de conversación, las tools y, si quieres, chat por WebSocket o sub-agentes por RPC. No es un CLI genérico de “corre esta tarea y sal.”
Regla simple:
| Quieres… | Empieza con |
|---|---|
| Tarea definida, CLI, CI, deploy multi-target | Flue |
| Agente conversacional abierto que inventa el workflow en el chat | Think |
Misma plataforma debajo. Trabajo distinto arriba.
Shell no es bash
@cloudflare/shell es el package de Workspace durable (SQLite + R2 opcional). Sirve para archivos sandboxed y estado de Code Mode dentro de Dynamic Workers.
No es un intérprete de bash.
En la práctica hace esto:
- corre JavaScript en un Worker aislado
- te da APIs de filesystem (
InMemoryFso Workspace durable) - aplica timeouts de isolate
- bloquea la red de salida por defecto
just-bash es otra pieza: un bash virtual en TypeScript, in-process, con filesystem compartido entre exec(). Red off por defecto. Sin binarios arbitrarios del host. Sin VM completa.
El backend “isolate shell” de Computer usa just-bash en un Dynamic Worker, hablando por Workers RPC con el Workspace en SQLite. Rápido. Sin container. Limitado a built-ins del shell virtual. No es un $PATH de Linux.
No digas:
“Tengo
@cloudflare/shell, entonces puedo hacerapt install.”
Mejor:
“Tengo un FS de agente (durable o en memoria) y JS aislado. Bash de verdad es otra capa.”
Qué es @cloudflare/computer
@cloudflare/computer le da al agente una “computadora”: filesystem virtual en SQLite + backends de ejecución que tú registras.
Puedes:
- quedarte solo con archivos (sin backend de ejecución)
- sumar isolate shell (ruta just-bash)
- sumar container (Linux real)
- dejar que el modelo elija isolate o container por tarea
La idea de diseño de Cloudflare es clara: el container es para una porción chica del trabajo del agente (hablan de ~10%), no para cada edición de archivo.
El backend de container monta el mismo workspace en un Cloudflare Container (FUSE / computerd): userland Linux, binarios reales, package managers, red real. Cold start más lento. I/O más pesado que la ruta solo isolate. Ese costo no es un bug: es el filtro para no usarlo en todo.
Computer se puede combinar con Think: cambias el workspace por defecto y apagas el workspaceBash built-in si las tools de Computer se encargan del exec. Las capas se apilan. No se reemplazan entre sí.
La escalera que Think ya trae
Cada agente Think tiene this.workspace: un filesystem virtual en SQLite del Durable Object. Encima, un tool tipo just-bash monta esos archivos (sin red; con límites de cantidad y tamaño) y escribe los cambios de vuelta.
Eso alcanza para trabajo multi-archivo tipo shell sin instalar packages ni correr binarios nativos.
La escalera de tools se ve así:
Workspace (shell)
-> codemode / Dynamic Worker
-> npm / browser
-> Sandbox / containerSé útil primero en el nivel liviano. Sube de nivel solo cuando el trabajo pide tools de sistema operativo.
Tabla de decisión
| Necesitas | Prefiere |
|---|---|
| Tarea concreta, CLI, GitHub Actions, multi-target | Flue |
| Chat abierto con memoria, streaming y tool loop | Think |
| Archivos durables / workspace, sin Linux completo | @cloudflare/shell (o el workspace bash de Think) |
| Mismo FS durable + elegir isolate o container por tarea | @cloudflare/computer |
| Package managers, runtimes, tests, binarios nativos | Container / Sandbox — no solo el shell virtual |
| Ser dueño del loop y mezclar primitivas | Agents SDK sobre Agent base (sin Think ni Flue) |
Regla corta:
isolate shell -> archivos, texto, git-style
container -> Linux, packages, binarios realesDos errores comunes
1. Confundir chat durable con filesystem durable
El chat puede vivir en SQLite del Durable Object y el FS del sandbox seguir en memoria.
Si los archivos tienen que sobrevivir reinicios, usa un Workspace durable (o un container con historia clara de persistencia). No asumas:
“el chat se guarda” => “el repo se guarda”2. Container por defecto en cada op corta
No es la forma pensada de este stack.
Workspace isolate, codemode y shell virtual cubren la mayor parte del trabajo de texto y shell. El container es la excepción para trabajo a nivel OS, no el reemplazo de cada op de filesystem.
Cuándo NO metería de más
No metería Computer solo porque un blog diga “your agent needs a computer.”
| Necesitas | Empieza aquí |
|---|---|
| Producto de chat con tools | Think + workspace por defecto |
| Agente de CI / CLI / multi-cloud | Flue |
| Archivos que persisten + shell liviano | shell / workspace bash |
A veces cat, a veces npm | Computer con los dos backends |
| Siempre Linux en cada paso | Sandbox/container — y acepta el costo |
Tampoco pondría Flue y Think como si fueran lo mismo con otro logo. Capas distintas. Misma plataforma Agents debajo.
Checklist antes de elegir nombre
- ¿Es conversación abierta o una tarea definida?
- ¿Quién maneja el loop: yo o el harness?
- ¿Los archivos deben sobrevivir entre turns y reinicios?
- ¿Esta semana necesito binarios y package managers, o alcanza con texto + JS?
- ¿Qué porcentaje real de pasos pide un Linux completo?
- ¿Multi-target (Node + Cloudflare) o chat first en Cloudflare?
- Si quito el container, ¿el agente sigue siendo útil?
Si la 7 es “no”, quizá el default del entorno está demasiado grande y las tools demasiado pequeñas.
La frase para recordar
Flue = estructura y deploy del producto-agente
Think = loop de chat (memoria, stream, tools)
shell = FS del agente (no es bash)
just-bash= shell virtual sobre ese FS
Computer = FS + isolate o container según la tareaElige por capa y tipo de trabajo, no por el package que salió último en el changelog.
Serie Cloudflare para builders: Workers · Bindings · Durable Objects · Queues
Docs: Think · Think tools · Flue / Agents platform · @cloudflare/computer · Sandbox · Dynamic Workers · just-bash
@cloudflare/computer y parte de shell/workspace siguen en preview. Esto es un mapa, no un catálogo congelado.