You are not the copy‑paste layer between your AI and your terminal.
Starcell connects your chat to your machines. Say “do ABC-123” — the Star dispatches it to Claude Code or Codex in a Cell on your hardware and returns a report and a diff. Queue twenty tasks. Walk away.
Claude Code + Codex today · Your machine, your rules · Every run: prompt + report + diff
The loop everyone runs by hand.
Your chat plans the work and writes the prompt. Then you copy it, switch to a terminal, paste it, wait, copy the result, paste it back, and ask for the next one. The AI plans. The AI executes. You are the transport between them.
chat → copy → terminal → wait → paste → chat → repeat
How it works
one Star · any number of CellsSend work from anywhere
Say “do ABC-123” in Claude or ChatGPT via MCP — the task can come from Jira, nitka, or any tracker you connect. Or post it in a Slack handoff channel, or paste a prompt into the menubar app.
The Star routes it
The Star analyzes each task and routes it by runner fit and your project policy — Claude Code or Codex today — to the right Cell. Related tasks queue behind one another; independent work runs in parallel.
Cells run it, you judge it
Every job gets a disposable workspace inside a Cell on your hardware, and comes back as prompt + report + diff — delivered to your chat, your tracker, or Slack. Review from your desk or your phone.
One Star. Every Cell. One control plane.
example fleet · animatedconceptual view — one Star dispatching jobs to Cells with isolated workspaces and collecting reports; Cells join and leave the fleet as you scale
Why Starcell
Isolated workspaces
Every job gets a disposable workspace inside a Cell. Run Cells in containers when you need a stronger boundary from the host. Your machine, your rules.
Every run accounted for
Prompt + report + diff on every job — everything needed to judge the work, delivered back to your chat, your tracker, or Slack.
Across chats, trackers, and runners
Claude, ChatGPT, Cursor in. Jira, nitka, Slack, Discord around. Claude Code and Codex running side by side. No vendor owns your loop.
Your subscriptions, your hardware
Runners sign in with the coding-agent plans you already pay for — Starcell adds no token meter of its own. One laptop or a container fleet: same Star, more Cells.
Parallel, without collisions
Queue twenty tasks at once. The Star serializes related work and runs independent work in parallel across Cells — fewer collisions, no manual traffic control.
Operate from anywhere
Submit work from chat, follow run status from your phone, and review the report wherever you are. Cells continue while you're away from the keyboard.
The desk becomes optional.
When the roadmap already holds the work — in Jira, nitka, or anywhere — execution stops needing you in the chair. Queue the next tasks from your phone, read the reports wherever you are, approve what's good. The Cells keep building while you're away.
Not one prompt to glory — the engineering way: planned, queued, isolated, reviewed.
prompt, report, and diff — attached to every run
Questions
How is this different from cloud background agents?
Cloud background agents run one vendor's model in that vendor's sandbox. Starcell is the neutral layer: any chat in, Claude Code and Codex runners today (pluggable by design), executing on your own machines or containers, wired to your tracker and your comms — and every run comes back as prompt + report + diff.
Does Starcell upload my repository?
No. Cells and their workspaces stay on infrastructure you control. Your selected runner may send source context to its model provider — the same boundary as running Claude Code or Codex directly. Reports, diffs, and status go only to the destinations you configure.
Which models and runners are supported?
Claude Code and Codex today, running side by side — the Star routes each task to the runner best suited for it. The runner system is pluggable; new runners can be added as they appear.
Do I need API keys?
Not for the default setup — runners sign in with the Claude Code or Codex subscriptions you already use. Those plans keep their own usage limits, and API-key runners remain available for usage-based automation. Starcell adds no separate token meter.
What works today?
Starcell runs its builder's own projects daily — routing, cells, queueing, reports, the full loop. Multi-tenancy is in progress; early access opens gradually as it lands. Request access and tell us how you'd run it.
Is it self-hosted or hosted?
Today the whole system — Star included — runs on your own machine or in Docker. A hosted, multi-tenant Star is in the works; Cells and their workspaces always stay on your hardware.
How do parallel jobs avoid colliding?
The Star serializes related work while independent work runs in parallel across Cells. A Cell can host one or many isolated workspaces, depending on the concurrency you configure.
Is there AI inside Starcell?
Starcell doesn't replace your AI. Planning stays in your chat, coding stays in the runners; the Star handles routing, queueing, isolation, and delivery — the boring, reliable part. Task routing is algorithmic analysis, not a model call.
Does it work for teams?
Team support is in progress. Solo setups run today; the multi-tenant layer will let teammates pool Cells and work under one Star as early access expands.
Queue the work. Walk away.
Enter a valid email address.
Something went wrong — try again or email hello@starcell.sh
No spam. One email when your access opens.