That works, and if you run one agent it might be all you need. What it doesn't give you: recovery when the process or box dies mid-task (tiny sessions resume from the transcript after a pod kill), more than one agent without inventing your own process supervision, per-session CPU/memory limits, the issue → PR loop, or an audit trail of who approved what. If none of that matters to you, keep the VPS.
Because it already solves the boring parts: restart-on-death, volumes that outlive processes, resource limits, RBAC, image pulling. tiny adds about two CRDs on top instead of re-implementing any of it. The cost is that you need a cluster; kind or minikube on a laptop counts.
Inside a pod with no credentials, less than it sounds — the threat model walks the actual blast radius. The short version: the pod is the sandbox, the gate holds the credentials, and the worst an injected agent can do is waste tokens and write files into its own outbox.
For autonomous work, yes, and the reason is simple: in tiny the agent is not running as you, on your machine.
Overnight work needs permissions bypassed somewhere. On your laptop, an
agent running that way is you: it has your SSH keys, your gh token,
your ~/.aws and ~/.kube (prod contexts included), browser sessions,
every repo you've cloned, and it sits on your LAN and VPN. Prompt-inject
it and it can steal your credentials or pivot into your network with your
identity. In tiny the same agent has a workspace volume and a model
token, and nothing else. No git or cloud credentials, non-root,
resource-limited, egress cut off from private networks, and anything
dangerous parks at the gate until a human's own
credentials perform it. A fully compromised session gets an attacker a
scratch directory and your model quota, not your laptop and not your
network.
For supervised work the comparison is different: local Claude Code in default mode asks before each command, which is its own kind of safe. tiny is for the runs where nobody is watching.
Idle: nothing but the CRD definitions. A running session is one pod sized by you (the default agent image is fine with ~500m CPU / 1Gi) plus a small sidecar. Agent usage bills to whatever plan you signed in with — Claude Pro/Max and ChatGPT Plus both work, which is the point: a fleet on the flat plan you already pay.
Each session has its own workspace and its own branch convention
(tiny/issue-N). The courier rebases every branch onto main before
pushing and skips branches that don't rebase cleanly, so conflicts
surface as a failed push, not a broken main.
Yes — tiny setup mints an ed25519 deploy key; you add the public half
to the repo. Clones happen with that key. Pushes still go through the
outbox, so the key never needs write access.
Both, per session. We don't have a strong opinion; run yours on the plan you already pay for.
It's early. The pieces described in these docs are real and tested (we kill pods on camera), but the project is weeks old, the fleet screen is a TUI not a web app, and you are trusting a young codebase with cluster access scoped by your own RBAC. Read the code; it's small on purpose.
Anthropic now offers self-hosted environments — Claude Code cloud sessions routed to runners you deploy — for Team and Enterprise plans. If you are an enterprise already on those plans and want the first-party, supported path, use it.
tiny is the open-source take, for a different person. It is MIT and runs on any Kubernetes cluster you already have, not a plan tier. It runs Codex the same way it runs Claude Code, so you are not tied to one vendor. And its whole design is the credential posture: the agent holds no git or cloud keys, nothing listens on the pod, and finished work leaves as a bundle a courier pushes — the agent never holds a token that could push. That is the part a hosted or first-party runner does not give you.
Those run isolated machines that execute code — a sandbox per run, usually their cloud, billed by usage. They are built for products that ship an agent and need somewhere safe to run its code.
tiny is not a code sandbox. It runs the real Claude Code and Codex CLIs as long-lived sessions on a cluster you own, with no per-run cloud bill and no code leaving your infrastructure. If you were looking for a self-hosted sandbox SDK, those tools fit better. If you want your own machines running the actual CLI you already use, with no keys in the pod, that is this.
AX is an orchestration platform for agent workloads at very large scale: tasks run on a sandbox runtime (Agent Substrate) under a control plane of their own, driven by AX's runner and a model you configure. It suspends a task by snapshotting it, and it is built for running agents in volume.
tiny is narrower. It runs the actual Claude Code and Codex CLIs, unmodified, as a few long-lived sessions you attach to. It installs CRDs and a CLI, with no control plane, nothing to keep running between sessions, and no router: nothing in a session listens, and you reach it through the Kubernetes API under your own RBAC. The pod holds no git or cloud credentials; finished work leaves through the outbox. And a human stays in the loop: questions park until someone answers them with their own credentials, and a labelled GitHub issue comes back as a pull request.
Both put the model credential in the agent's sandbox, so neither removes that. If you are building a platform that runs agents for many users, AX fits better. If you want your own coding agent on your own cluster with nothing in its pockets, that is this.
Yes — that is the default, not a mode you switch on. A session clones over HTTPS (or a deploy key you choose to add), and finished work leaves as a git bundle that a separate courier job pushes with a short-lived token the agent never sees. Nothing about the session holds a credential that can push to your repos or reach your cloud. See the outbox and the threat model.