Why Glue

designed by subtraction

Most coding assistants get bigger over time — more modes, more panels, more knobs. We're trying something else: each feature we did not add is something we chose to give up, for a specific reason. These are the six that shaped the product.

1. 01

   No IDE bolt-on.

   What we didn't build

   A panel, an extension, a webview, or a cursor-integrated chat.

   What we gave up

   Inline previews, click-through to definitions from the transcript, AI popups on highlight.

   What we got

   Glue runs in the terminal you already have open. The transcript is the UI — nothing moves outside it.

2. 02

   No interaction modes.

   What we didn't build

   A code/architect/ask picker or a "planning" state.

   What we gave up

   A "safer" mode you can put into other people's hands without thinking.

   What we got

   One surface. Behaviour is steered by the prompt, by tool approval, and by the runtime — not by a hidden toggle you forgot to flip.

3. 03

   No hosted dashboard.

   What we didn't build

   A SaaS observability layer, account system, or telemetry upload.

   What we gave up

   Team-wide analytics, replay UI out of the box, org-level usage metering.

   What we got

   Every session is an append-only JSONL file under ~/.glue/sessions/. tail -f works. No upload. No account. No vendor can take your history away.

4. 04

   No sprawling model list.

   What we didn't build

   A startup-time "fetch every model from every provider" sweep.

   What we gave up

   Instant visibility of every legacy or preview model a provider ever listed.

   What we got

   A curated catalog you can read in one screen. Startup is fast. Anything missing goes in via adapter: openai.

5. 05

   No mandatory cloud runtime.

   What we didn't build

   A remote execution layer you have to route through to get useful work done.

   What we gave up

   Zero-setup remote code execution as the default path.

   What we got

   Work runs on your host, or in a local Docker container you own. If a remote runtime is the right tool, it's a backend — never a requirement.

6. 06

   No autonomous mode.

   What we didn't build

   An "agent that runs for hours while you sleep" default, or a parallel-agents swarm.

   What we gave up

   The fantasy of set-it-and-forget-it. Unbounded background work.

   What we got

   Approval is on by default. You see the tool call, you see the output, you decide the next step. When Glue writes to your repo, you know why.

Who this isn't for

These trade-offs cost real things. It's only fair to say who's better off with something else.

• If you want deep IDE integration — Cursor, Zed, and IDE-side AI panels are more cohesive in that seat.
• If you want a hosted observability dashboard — Langfuse and LangSmith do that well, and Glue's JSONL is trivial to forward to either.
• If you want an autonomous multi-hour agent — Devin and similar products are a different category.

If the six trade-offs above line up with the way you already work, Glue will feel small and direct. If they don't, that's fine — use the tool that fits.

Still curious? Features → · Models → · Runtimes →