I'm done with terminals

Overview

The speaker argues that, although they’ve long been a “terminal-first” developer (SSH, GNU screen/Tmux, auditing, Minecraft server hosting), modern AI coding workflows no longer fit terminals well—especially as parallel work and multi-project context grow.

---

Key technological/product points

Why they stopped using terminals as the primary workspace

• Reboots and session management

  • They realized they weren’t reliably using their terminal daily.
  • Tracking work across many terminal sessions created high mental overhead.

• Parallelism problem

  • With 3+ concurrent tasks/projects, terminal hotkeys and panel layouts (e.g., in Tmux) become difficult to manage.

• UI/Navigation

  • They prefer GUI advantages such as:
    • easier clicking to switch contexts
    • readable text rendering
    • better visibility into “what’s going on right now”

---

Agent managers / GUI workflows

• They cite anti-gravity’s agent manager as an early proof point:

  • A hotkey opens an “agent manager view”
  • It shows agents across multiple project instances in a single sidebar-style overview.

• They also praise new “activity” views in Codeex, described as inspired by internal ideas from T3 Code—though they’re not fully realized yet.

---

Codeex (now branded as the ChatGPT app) and limitations

Codeex was compelling because it supports:

• multiple projects/worktrees visible and managed together
• opening a terminal only when needed
• better switching/navigation than Tmux/hotkeys
• strong handling of copy/paste and scrolling without formatting lag
• image-based prompting (sending screenshots to models to debug faster)

Main downsides discussed:

• Closed-source nature

  • Regressions or UI/model changes are harder to fix directly.

• Rebranding/merging

  • “Codex” becoming “ChatGPT” is criticized for reducing clarity/control.

• Model/provider/subscription friction

  • They describe tradeoffs between:
    • using cloud-code/Codeex GUIs tied to specific providers/models
    • needing to switch interfaces to access different providers/models at subsidized rates

• macOS security/performance overhead

  • The app reportedly spawns multiple processes per thread/sub-agent, impacting performance.

---

SSH is the remaining big pain point

The speaker’s “biggest complaint” isn’t the GUI or agents—it’s SSH fragility/reliability:

• latency/interference can cause typing issues (e.g., “sticky keys”)
• performance depends on whether they’re on Wi‑Fi vs Ethernet
• mobile terminal usage is described as not viable for “real work”

They mention that remote control via Codex/ChatGPT from a phone helps, but it was limited to certain desktop app ecosystems and came with additional performance/security complications.

---

T3 Code: what it does (features/architecture)

The speaker positions T3 Code as an open-source GUI + agent orchestration layer to escape terminal limitations while still running “Cloud Code/Codeex”-style agent workflows.

Core promise

• A centralized desktop/web/mobile interface to manage multiple agents and models consistently.
• Ability to keep work running on a chosen machine and continue later without repeatedly re-SSH’ing or losing sessions.

---

Remote control across machines

A “little button” enables controlling a machine running T3 Code from:

• another computer via the app/website (app.t3.codes)
• iOS and Android mobile apps

They describe this as reducing workflow disruption caused by:

• timing agent runs around meetings
• overheating/fans
• Wi‑Fi dropouts
• even coding in Ubers

---

Connection workflow / examples

Commands intended to make pairing and sign-in easier:

• npx t3 nightly + Tailscale pairing

  • generates a pairing code (QR or URL)

• t3 nightly serve

  • hosts the instance

• npx t3 connect

  • opens a sign-in flow (GitHub/Google)
  • creates a background instance on the machine

Goal: control a configured machine “forever,” avoiding ongoing SSH/terminal overhead.

---

Security/official support

They emphasize it’s “above board” and follows an “official agent SDK” approach (instead of hacks like forcing flags).

They also claim they coordinated with providers/vendors to avoid getting subscriptions/users banned.

---

Reported impact / review-style outcomes

• They claim the GUI-based agent management improved throughput dramatically:

  • from landing ~3–4 PRs/week
  • to up to ~20 PRs/day on heavy days

• They contrast this with their experience losing track of terminal sessions and having to search across Cloud Code/Codeex worktrees.

---

Main sources / speakers

Primary speaker

• “Theo” (referred to as Theo throughout; also mentions “Julius”)

Other referenced entities/tools

• Blacksmith (CI sponsor)
• anti-gravity (agent manager example)
• Cursor (cursor v2 agent view integration issues; “Cursor glass” performance tradeoff)
• Codeex / Codex (transition to “ChatGPT” app; image sending; remote control)
• T-Mux / GNU screen (terminal workflow background)
• T3 Code (their open-source project)
• OpenAI (feedback/support mentioned)
• Tailscale (used for easier machine connection)
• Cloud Code / Codeex providers (mentioned as running on the user’s machine)
• SSH / mosh / SSH3 (remote access comparisons)