Product · 2026
PugPort
One for all. PugPort puts the desktop CLIs you already pay for (Claude Code, Codex, Grok, Cursor, Gemini), as many accounts of each as you have, and API models (OpenAI, DeepSeek, Kimi and more) behind one chat. It sends each task to the agent that still has quota, and when that agent runs dry mid-task, hands the work to the next one and keeps going.
Visit pugport.com- Role
- Sole designer and engineer
- Stack
- TypeScript, React, Electron, Express, SQLite
- Scale
- 125k lines · 450+ test files
- Status
- v0.0.34 · Windows · open-source release in progress
The problem
Claude Code, Codex, Grok, Cursor and Gemini each run on their own quota window, and a second account of the same tool has its own window again. When one runs out mid-task, you check the others, wait for a reset, and copy context by hand from one CLI into another. With a few subscriptions, that bookkeeping becomes a part-time job.
PugPort runs the official CLIs you already have installed and logged in. It never proxies or spoofs them; it only decides which one should do the work, and keeps track of what each one did.
API models via Pi
@@ other computers
The parts that were hard
Routing on quota you can trust
Each CLI reports usage differently, and some don't report it at all. Every quota reading in PugPort carries its source and timestamp. When a value isn't known, it stays unknown instead of being guessed, and the router treats it that way.
Handing off half-finished work
When an agent runs out of quota in the middle of a task, PugPort can pass the work to another one. The hard part is writes: the first agent may have changed files before it stopped. The handoff carries verified tool checkpoints, and any write that wasn't confirmed is checked before the next agent continues. An account the user pinned is never swapped out.
Agents calling agents
Write "ask Codex B to review this" in a task, and the running agent hands that sub-task to another executor through a local MCP endpoint and gets the result back. The parent releases its slot while it waits, and sub-tasks are read-only by default and can't call further, so a chain can't run away.
Many accounts of the same tool
Each account signs in on its own, in its own private profile, so two Claude Code or two Codex logins can run side by side. Usage is read per account from the tool itself, and automatic work can move from one account to another of the same provider.
Your other computers, by name
PugPort can run headless on another machine and join over Tailscale with a one-time pairing code. Then "@@ubuntu run the test suite" sends the task there; that machine picks its own agent and the result comes back into the same chat. Remote tasks are read-only unless you allow more. Linux nodes work today; a Mac node is next.
Agents outside the app
@@Muse (a web chat in PugPort's own window), @@Grok Bot and @@Codex Cloud can be asked in the same chat, and their answers combined. Their replies are treated as untrusted text: anything that quotes them runs without tools.
Waiting for the machine, not just the quota
A run starts only when the computer has room: CPU below 85% and enough free memory. On a busy machine PugPort asks before starting, so a heavy job never freezes everything else.
A queue that survives restarts
Different conversations run concurrently; messages inside one conversation stay in order, and writes to the same project are serialized. Deadlines and priorities persist in SQLite, so closing the window or rebooting doesn't lose work.
"Done" is not the same as "verified"
An agent saying it finished is recorded separately from evidence that it did. Partial or blocked work stays unfinished, and missing evidence stays unverified. This one rule removed most of the "it said it was done" surprises.
How it's tested
Over 450 test files run against mocked CLI protocols, so the suite never spends real model quota. CI runs them on Windows, macOS and Ubuntu. CI checks types, formatting, licenses and the build on every change, and can produce a portable Windows build with checksums for testers.
What I'd bring to your project
- Orchestrating several model providers behind one interface, with honest usage accounting.
- Safe retries and handoffs for agents that write to real systems.
- Local-first data, clear permission boundaries, and tests that don't burn API budget.