pingdotgg/t3code

The problem

Coding agents now live in your terminal: Claude Code, Codex, Cursor CLI and friends. They are powerful, but they are tied to the machine, the shell session and the subscription you configured there. If you want to check on a long-running session from your phone, or hand a task to an agent while away from the desk, the usual answer is SSH or a browser tab into a remote box. T3 Code is a control surface that sits on top of whichever agents are already installed and authenticated on your computer, then exposes that control through a web app, an Electron desktop app and native iOS/Android apps.

What's different

The obvious comparison is the vendors' own desktop apps (Codex desktop, Claude Desktop) and terminal multiplexing over SSH. The vendor apps generally assume their own model and their own workflow; T3 Code is deliberately harness-agnostic and lists six providers you can mix on one machine. Two things actually stand out: a remote-first architecture where a local server is the thing you connect clients to, and a hosted phone app, which is rare in this space. It also commits to being forkable under MIT if the direction drifts. Note the trade-off: it manages other people's CLIs rather than replacing them, so your experience is bounded by those CLIs and their auth, and the README is candid that this is early.

Who it's for

Individual developers who already pay for one or more agent subscriptions, work on a machine that stays on, and want to supervise or dispatch agent work from a laptop, browser or phone. It fits small teams comfortable running a local service. It is not for people who want an agent bundled with its own model, teams needing SSO/central administration or audit trails, or anyone who expects a stable, well-documented platform today.

Cost of adoption

You must first install and authenticate at least one supported provider CLI. The main app comes via a curl install script, npx t3@latest, or platform packages (Homebrew, winget, scoop, deb, AUR). Running it as a background service is a documented option, which implies a persistent local server and exposure of remote access you should think about in security terms. The repo is MIT licensed. Maturity signals in the README are explicit ("very very early", "expect bugs"), and maintainers say they are mostly not accepting contributions, so you adopt, not shape.

Verdict

This is a young project: created in February 2026, it gained roughly 6,400 stars in the month HotRepo tracked and about 1,700 in a single week on the TypeScript board, yet it has never appeared on the daily trending board and its Hacker News thread drew 6 points and no comments. That pattern is a concentrated spike rather than organic steady growth. The idea is genuinely useful and the remote/mobile angle is the differentiator; but with an admittedly unstable codebase and closed contribution policy, treat it as something to try on a spare machine, not to standardize a team's agent workflow on.