Flue, Think, Computer, and shell: which Cloudflare agent layer you actually need

Cloudflare’s agent surface got crowded fast.

Someone asks: Flue or Think? Computer or shell? just-bash or a container? The wrong mental model is “pick one product.” The useful model is:

which layer of the stack do I need for this job?

These names are not rivals on the same shelf. They sit above and below each other. Mixing them up is how you boot a container for every cat—or ship a chat harness when you only needed a CLI task agent.

The stack in three lines

Cloudflare’s own framing is roughly:

framework  -> project shape, CLI, channels, where it runs
harness    -> agentic loop: model → tools → results
runtime    -> files, compute, backends under the loop

Rough placement:

Standalone packages (shell, codemode, Dynamic Workers) can also hang off a base Agent if you own the loop yourself. That is a valid path—just not a free lunch.

Flue vs Think

Flue is an open TypeScript agent framework. Harness-first (around Pi). Multi-target: Node (GitHub Actions, VMs, servers) or Cloudflare Durable Objects; headless background work or UI. On Cloudflare it maps Agents SDK primitives (Durable Objects, fibers, codemode, shell). Elsewhere it stays multi-cloud. Cloudflare’s first-party “open the box and chat” product is still Think; Flue is the programmable multi-target frame around a harness.

Think (@cloudflare/think) is the opinionated chat harness. It owns the agentic loop, streaming, message persistence, conversation memory, tool use, and optional browser WebSocket chat or sub-agent RPC. It is not a generic task/CLI product.

Rule of thumb that matches that split:

Same platform underneath. Different job at the product surface.

Shell is not bash

@cloudflare/shell is the durable Workspace package (SQLite + optional R2): sandboxed file ops and Code Mode state inside Dynamic Workers. It is not a bash interpreter.

What it actually does:

• run JavaScript in an isolated Worker
• typed filesystem APIs (InMemoryFs or durable Workspace)
• isolate timeouts
• outbound network blocked by default

just-bash is a separate idea: an in-process TypeScript virtual bash with a shared filesystem across exec() calls, network off by default, no arbitrary host binaries, no full VM isolation. Official guidance still points at a real VM/sandbox when you need arbitrary native binaries.

Computer’s “isolate shell” backend runs just-bash in a Dynamic Worker over Workers RPC against the authoritative SQLite Workspace. Fast. No container. Limited to virtual-shell built-ins—not a full Linux $PATH.

No digas: “shell package = I can apt install.”
Mejor: “shell package = durable (or in-memory) agent FS + isolated JS.”

What @cloudflare/computer adds

@cloudflare/computer is the agent runtime that gives each agent a “computer”: SQLite-backed virtual filesystem plus pluggable backends (isolates and Linux containers).

You can:

• use filesystem-only (no execution backend)
• register an isolate shell backend (just-bash path)
• register a container backend for real Linux
• let tools/models pick isolate vs container per task

Cloudflare’s design goal is blunt: containers for a small slice of agent work (they talk about ~10%), not the default for every file edit.

The container backend projects the same SQLite workspace into a Cloudflare Container (FUSE / computerd style): full Linux userland, real binaries, package managers, real network—with slower cold start and heavier I/O than a pure isolate path. Treat that cost as a feature filter, not a tax you always pay.

Computer can compose with Think: override Think’s default workspace, disable built-in workspaceBash when Computer’s tools own exec. Layers stack; they do not cancel each other.

The ladder Think already ships

Every Think agent gets this.workspace—a Durable Object SQLite virtual filesystem—plus a just-bash-style tool that mounts workspace files (network disabled; practical bounds on file count/size), then writes changes back. That path is enough for multi-file shell-style work without package installs or native binaries.

Think’s tools form an additive ladder:

Workspace (shell)
  -> codemode / Dynamic Worker
  -> npm / browser
  -> full Sandbox / container

Be useful at the lightweight tier first. Escalate when the job truly needs OS-level tools.

Decision table

Short operational rule:

isolate shell  -> file / text / git-style work
container      -> Linux, packages, real binaries, heavy install

Two misconceptions that burn money

1. Durable chat is not a durable filesystem.

Conversation state can live in Durable Object SQLite while the sandbox FS is still in-memory. If files must survive restarts and process boundaries, use a durable Workspace (or a container with a clear persistence story)—do not assume “chat is stored” implies “repo is stored.”

2. Container is not the default for every short op.

Booting Linux for every short code or file touch is not the intended shape of this stack. Isolate workspace, codemode, and virtual shell cover most text/shell work. Containers are the exception for OS-level work—not a substitute for every filesystem task.

When I would not over-buy

I would not pull Computer just because I saw a blog title about “your agent needs a computer.”

I would not treat Flue and Think as mutually exclusive brands either. Different layers. Same underlying Agents platform.

Design checklist

Before you pick a name from the marketing soup, answer:

1. Is this open conversation or a defined task?
2. Who owns the agentic loop—me or the harness?
3. Must files survive across turns and restarts?
4. Do I need real binaries / package managers this week, or only text + JS?
5. What fraction of steps truly needs a full Linux userland?
6. Am I multi-target (Node + Cloudflare) or Cloudflare-first chat?
7. If I remove the container path, does the agent still do useful work?

If answer 7 is “no,” you may have over-scoped the default environment instead of under-scoping the tools.

The line to remember

Flue     = how you structure and deploy the agent product
Think    = chat loop (memory, stream, tools)
shell    = durable agent FS (not bash)
just-bash= virtual shell on that FS
Computer = FS + pluggable isolate / container execution

Pick by layer and job shape, not by whichever package shipped last on the changelog.

Cloudflare series for builders: Workers · Bindings · Durable Objects · Queues

Docs and sources: Think · Think tools · Flue / Agents platform · @cloudflare/computer · Sandbox · Dynamic Workers · just-bash

Note: @cloudflare/computer and parts of the shell/workspace surface are preview/experimental; APIs and package boundaries may still move. Treat this as a map, not a frozen catalog.