NAME — tiny · Claude Code & Codex sessions on your own Kubernetes
tiny runs the real Claude Code and Codex CLIs as pods on your own Kubernetes — the tools you already use, not a copy of them. Close the lid and the session keeps working. Already mid-conversation on your laptop? tiny handoff moves that session into the cluster. Attach from any terminal; and when you want the team flow, a labeled GitHub issue comes back as a pull request.
The session lives in the cluster, not on your machine. Mid-conversation locally? tiny handoff moves it there, uncommitted changes and transcript included. Close the lid; attach from any terminal later.
tiny runs the real CLI, so you sign in the way you do on your laptop: Claude Pro/Max or ChatGPT Plus, the same plan you already use. (Automated or customer-facing work should use a metered API key under the provider's terms.)
When a session hits your plan's usage limit, its fleet row shows ⏸ resuming 5:20am, and it resumes then on its own.
The fleet screen shows who is waiting on you. You can answer inline, message a session without attaching, or drop a file onto its row.
.mcp.json. tiny does not wrap or proxy the agent, so new agent features work without us doing anything.golang:1.26, buildah, your own dev image: an init container injects the agent into whatever you name. You do not maintain a special image./workspace/uploads/.--agent codex runs OpenAI’s Codex. The fleet screen, the gate and resume behave the same for both.claude --model / codex -m underneath). Also a field on the options form.[b] on the fleet screen, or tiny broadcast from cron and CI.Pull-through image cache in your namespace. golang:1.26 downloads once instead of once per session, which also keeps you under docker.io rate limits. An optional DaemonSet installs its CA on the nodes.
S3-compatible store next to the sessions, for things too big for git: builds, screenshots, datasets.
In-cluster Actions runner, so delivery jobs can reach the sessions. A labeled issue lands in an inbox in about five seconds.
The fleet as a page, plus each session’s blast radius: files changed, lines, branch, and the files two sessions are both editing. Port-forward to reach it; it can only read.
Recorded against a real cluster, including the kubectl delete pod. Tapes in the repo.
File a GitHub issue and add the tiny label. That is the whole ceremony. Anyone on the team can do it from the GitHub UI.
An Actions job on the in-cluster runner pipes the issue into the root session's inbox. It usually takes about five seconds.
The root session plans, spawns specialists in the right toolchains, and raises a ✳ when a decision needs a human. Overnight is fine; we test session recovery by killing pods mid-task.
Agents hold no credentials. Finished branches leave as git bundles through the outbox, and a short-lived courier token opens the pull request and comments on your issue.
PROOF — this loop produced a real pull request in our demo repo: github.com/tiny-systems/seedling
The second agent took an afternoon. The two bugs it surfaced were nowhere near the model.
Job tokens die with their jobs and deploy keys sprawl, so our agents stopped pushing entirely.
Kubernetes already replaces dead pods. Why were we running a manager, with a standing secrets-reader Role, to do it again?
One binary, one wizard, no pods until your first session.
$ brew install tiny-systems/tap/tiny $ tiny setup # cluster · runtime · claude token $ tiny new "make the tests not lie"
tiny pins one cluster per machine, chosen with an arrow-key picker on every start — enter‑enter repeats yesterday's choice. Read the full manual →
tiny is MIT-licensed. We are early, and stars are the main way people find small projects like this one — if you want this to keep growing, a star genuinely helps.