podiumFI
Apache 2.0 · Eight supported coding agents
podiumFI runs Claude Code, Codex and six more agents for you from a single desk — in plain sight, and nothing builds until you approve the plan.
curl -fsSL https://podiumfi.fun/install.sh | sh
0x7d456807af1df3b157803841c49329dc15dd10c8
Say what you want built. podiumFI reads your repo first, asks about anything still vague, and hands back a plan of tasks you can rewrite. Each change works on its own branch, and you read the diff before anything merges.
Try the planner below ↓No Node.js needed on macOS and Linux · Windows installs with npm · no extra API key if you already run a coding agent
01
podiumFI reads your repo and asks about anything you left open — before a single task exists.
02
Swap any task, agent or model before anything runs. The plan is a draft, not a contract.
3 of 3 tasks done
03
Change tasks work side by side on their own branches. Yours waits for you at the end.
Interactive planner
Type a goal, rearrange who does what, then approve and watch the run.
podiumFI would read your repo and ask one clarifying question first. Here, pick a goal (or write your own) and generate the draft plan.
How it works
Every task is written out with the agent, model and effort that will run it. You can change any of it first.
01 · Plan
The planner reads your repo without changing it, asks about anything unclear, and writes the plan: ordered tasks, each naming the agent and model that will run it.
02 · Run
Each change task gets its own branch and worktree. Independent tasks run at the same time. A dependent task waits until its inputs land on the run's integration branch.
03 · Verify
A task is done when its agent reports completion through podiumFI's own tools, or when a script's exit status says so. No second model judges the work. A task that never reports fails where you can see it.
Why it's different
APPROVAL
The plan is yours to rewrite before anything builds: prompts, agent, model, effort, mode and dependencies.
EVIDENCE
No second model is asked whether the work looks done. The agent's own completion report decides, and a script's exit status decides for scripts.
MIXED CAST
Eight supported agents can share a plan. Each task picks its agent, model, effort and mode — and a task can move to another agent mid-flight.
LIMITS
A task that hits its agent's usage limit pauses and resumes in its saved session when the limit resets. Move a paused task to another agent and its unfinished work comes with it.
Supported agents
podiumFI doesn't sell you another model subscription. It drives the coding agents already installed on your machine, each with its own login, its own models and its own usage limits. Mix them in one plan, per task.
RUNNER · DEFAULT PLANNER
Anthropic's terminal agent. Sonnet and Haiku families, high / medium / low effort. claude on your PATH is enough — podiumFI plans and runs through it with no extra key.
RUNNER
OpenAI's coding agent. Strong on self-contained refactors and test repair. codex signed in once, then available to every plan.
RUNNER
Open-source runner with the widest model catalog — DeepSeek, Qwen, GLM, Kimi and more via OpenRouter or a local endpoint.
RUNNER
Google's agent for long-context research tasks: whole-repo audits, doc sweeps and migration inventories.
RUNNER
Pair-programming veteran. Good fit for small, tightly-scoped edits on a branch you watch closely.
RUNNER
Drives Cursor's agent from the plan when your team already lives in the editor. Tasks land as branches, not chat threads.
RUNNER
Block's open-source agent, extensible with MCP tools. Picks up your Goose extensions inside podiumFI tasks unchanged.
RUNNER
Sourcegraph's agent for fast, parallel exploration. Useful as the research leg before a heavier model builds.
On first run podiumFI scans for installed agents and lists only the ones it can actually start. A runner that isn't signed in, or whose binary is missing, never appears in a plan's picker — so a task can't be assigned to an agent that will fail at launch. Add an agent later and run /runners (terminal) or refresh the panel (editor); it joins the cast without restarting the plan.
Inside a plan
Nothing about a task is implied. Before you approve, each card spells out exactly what will run, where, and in what order — and every field is editable.
Editor extension
Live thinking, every research step, and the plan itself, pinned above the composer in VS Code, Cursor and compatible editors.
INSTALL
code --install-extension podium.podium
Or search podiumFI in the Extensions view. The extension bundles its own core, so there is nothing to install from npm.
FIRST RUN
Choose an installed coding agent to plan for you — read only, using its own credentials.
Model names and interface details may change between releases.
› Listed a directory, read 2 files, searched the code
requestId() and auth(), and nothing sets rate-limit headers yet.The conversation
Your goal, the research folded into one line you can open, and the question the planner asked before it planned.
Planner ctx 38k (19%) · Claude 5h 23% used · Weekly 41% used
The plan
Docked above the composer. Each task names its runner and model before you press Execute Plan. The footer shows the planner's context and your account's limits.
Switch a task's runner and its model, effort and mode follow — picked from what that agent actually offers. An assignment that couldn't start never gets saved.
The picker lists the selected runner's own catalog, so you never type an id that only fails once the task starts.
The levels offered are the ones that model actually has. A docs task doesn't need to think as hard as a migration — and you decide which is which.
Write down how your team works once, as a skill in your repo. The planner attaches it to the tasks it fits, and you see it on every task card. /grilling, /to-spec and /tdd come built in.
Terminal UI
Conversation on the left, live plan on the right. Single keys drive the plan: no menus, no mouse.
INSTALL
curl -fsSL https://podiumfi.fun/install.sh | sh
podium # in your project
One binary, no Node.js on macOS and Linux. On Windows, or if you prefer npm, run npm install -g podium.
FIRST RUN
podium. The opening screen names the planner and the runners it found.An installed coding agent plans by default, with no API key. Change it in place with /planner and /runners.
● Symbol(authenticate)
└ src/middleware/auth.js:1 · 1 reference in src/server.js
● Bash(npm install ioredis)
└ Refused: writes to the workspace belong to the runners, not the planner
● Read(src/lib/redis.js)
└ export const redis = new Redis(process.env.REDIS_URL)
◆ Question: ioredis is already a dependency — should the limiter reuse that connection, or open its own?
My recommendation: reuse it. One connection to supervise, and the bucket keys are namespaced anyway.
› reuse it
◆ Reusing the shared client, then. Seven tasks: the limiter itself, the wiring, the 429 contract, per-route budgets, a burst load test that is yours to run, docs, and a final verification pass.
◇ Plan generated · 7 tasks
Planner ctx 38k (19%) · Claude 5h 23% used · Weekly 41% used
Plan 2/7
● Guarded · supervisor Watch
The planner conversation and the live plan, side by side. Guarded is the default autonomy level.
Autonomy & supervision
Three supervision levels, set per plan — and changeable mid-run. Guarded is the default, and no level ever merges to your branch without a handoff you accept.
DEFAULT
A podiumFI task can pause before the step that can't be undone and hand you the decision with the evidence it gathered — a dry run reporting exactly what would change. Approve and it continues. Reject and it doesn't.
SUPERVISOR
The plan runs end to end while a supervisor keeps an eye on the stream.
HANDS-OFF
For plans you've run before and trust: overnight batches, codemod sweeps, test repair.
Skills
podiumFI shows every dial before a task runs: which skills are switched on — grill-me, TDD, review, verify — and how hard the model thinks. Per task, and yours to change.
/grillingInterrogate the goal before planning: surfaces hidden constraints, edge cases and the questions a senior engineer would ask first.
/to-specTurns a loose goal into a written spec — scope, non-goals, acceptance checks — that the plan is then built against.
/tddTests first, then the change, then the refactor. The task isn't done until the new tests pass and the old ones still do.
/reviewA second pass over a finished task's diff: correctness, naming, dead code, and anything the brief asked for that's missing.
/verifyRuns the project's own checks — test suite, linter, typecheck, build — and attaches the real output to the task.
/debugReproduce first, form a hypothesis, instrument, then fix. No speculative patches stacked on a guess.
WRITE YOUR OWN
# API change When a task changes a public endpoint: 1. Update the OpenAPI spec first. 2. Add a contract test for the old shape. 3. Note it in CHANGELOG.md, Unreleased.
HOW IT TRAVELS
.podium/skills/ and commit it.Skills are instructions to the planner, not code that executes. They shape prompts and checks — they never grant a runner new permissions.
Workflows
The same loop — goal, questions, plan, branches, diff — shaped by three very different kinds of work.
GOAL
“Add rate limiting to the public API”
GOAL
“Checkout suite fails 1 run in 5 — find out why”
GOAL
“Move sessions from cookies to Redis”
CLI
# plan on an agent you already have, no API key export AI_PROVIDER="claude-code" # or codex, opencode and five more podium plan --goal "Add rate limiting to the public API" podium task-model 3 sonnet # change a task before it runs podium run podium handoff review # read the diff first podium handoff merge # then bring it onto your branch
| Command | What it does | Notes |
|---|---|---|
| podium plan --goal "…" | Research the repo and draft a plan without running anything | Exits 0 with the plan on stdout as JSON with --json |
| podium task-runner N agent | Reassign task N to another runner | Model and effort reset to that runner's sane defaults |
| podium task-model N model | Change one task's model before it runs | Only models that runner can start are accepted |
| podium task-mode N mode | Set a task to build, research or manual | Manual tasks are skipped by run and left for you |
| podium run | Execute the approved plan | Parallel where dependencies allow; streams status lines |
| podium status | Show every task's state, branch and last report | Safe to run from a second terminal mid-run |
| podium resume | Resume paused tasks — after a limit reset or a Ctrl-C | Sessions are restored, not restarted |
| podium handoff review | Print the combined diff of all finished task branches | Per-task diffs with --task N |
| podium handoff merge | Merge finished branches onto yours, in plan order | Stops on the first conflict and leaves the rest untouched |
| podium discard N | Throw away one task's branch and mark it discarded | The rest of the plan is unaffected |
PROJECT CONFIG
planner = "claude-code" autonomy = "guarded" [runners] default = "claude-code" research = "opencode" [limits] max_parallel = 3 pause_on_usage_limit = true
COMMIT IT
podium.toml sets the planner, default runners, autonomy level and limits for everyone on the project.~/.config/podium/config.toml wins for your machine only — swap in your own runner without touching the team's file.AI_PROVIDER take precedence for a single run.Exit codes: 0 = plan complete, 1 = a task failed or never reported, 2 = plan not approved. CI can gate on them directly.
FAQ
No — not if you already run a coding agent. podiumFI plans and runs through your installed agents using their own sign-in, so there is no extra key to buy or paste. If you'd rather plan on a direct API provider, set AI_PROVIDER and that provider's key instead.
podiumFI itself is free and open source under Apache 2.0. You pay only for the agents and models you already use, under your own subscriptions and limits — podiumFI adds no markup and holds no billing relationship with you.
Eight: Claude Code, Codex, OpenCode, Gemini CLI, Aider, Cursor Agent, Goose and Amp. A plan can mix any of them per task, and only agents podiumFI can actually start on your machine appear as options.
podiumFI runs locally and sends nothing anywhere itself. Each task runs inside the agent you assigned, so your code goes wherever that agent already sends it — under that agent's own terms, with your own account.
The task pauses in its saved session instead of failing. When the limit resets, it resumes with context intact — or you reassign it to another runner and the unfinished work moves with it.
No. Without git, tasks work directly in the folder, one at a time. With git 2.38 or newer you get the full model: a worktree and branch per task, parallel runs, and Merge all at handoff.
Not at the same time. Each build task works in its own worktree; if two tasks genuinely need the same file, the planner makes one depend on the other so the edits land in order on the integration branch.
By evidence, not vibes: the runner reports completion through podiumFI's own tools, or a check script's exit status says so. No second model grades the work. A task that never reports is shown as failed, with its branch preserved for inspection.
Yes — that's what the CLI is for. Draft with podium plan, execute with podium run, and gate on the exit code: 0 complete, 1 a task failed, 2 the plan was never approved. Guarded mode's checkpoints become a required --approve flag in pipelines.
Supported via npm: npm install -g podium. The terminal UI, CLI and editor extension all work; the one-binary installer is macOS and Linux only.
A runner is missing from the picker — it isn't installed or isn't signed in; podiumFI only lists runners it can start. A task is stuck on RUNNING — check podium status; a runner that never reports is failed visibly, never silently. Merge stops halfway — the first conflicting branch halted the handoff; resolve it, then re-run podium handoff merge and the remaining branches continue in plan order.
Get started
Terminal
curl -fsSL https://podiumfi.fun/install.sh | sh
Installs to ~/.local/bin on macOS and Linux, with no Node.js. Then run podium in your project. On Windows, use npm install -g podium.
Editor
code --install-extension podium.podium
Or search podiumFI in the Extensions view. It bundles its own core, so there is nothing to install from npm.
Pre-1.0 software can change between minor releases, so read the changelog before you upgrade.