Coding agents should scale you.
A dozen tasks, each in its own sandbox. Stop watching turns. Start making decisions.
One agent. Every turn, you wait.
An agent reads, edits, runs the tests and tries again. You half-watch a terminal.
Run a dozen on your laptop, and you're juggling a dozen worktrees, dev servers fighting over ports, and one database every branch steps on.
Even when that works, your attention becomes the limit. The question is what it costs to check on one.
If it's a transcript, a dozen is worse than one. If it's the diff, the failing test and a terminal already open, a dozen is easy.
A sandbox for every task.
Your config declares the services. Tinsmith starts each in its own container and waits for its health check before anything runs against it.
{"version": "1","devbox": {"dockerfile": ".tinsmith/devbox/Dockerfile","env": {"DATABASE_URL": "postgres://app:app@postgres:5432/app","REDIS_URL": "redis://redis:6379"},"services": {"postgres": {"image": "postgres:17-alpine","env": { "POSTGRES_USER": "app", "POSTGRES_PASSWORD": "app", "POSTGRES_DB": "app" },"health_check": { "cmd": "pg_isready -U app -d app", "interval": "5s", "retries": 20 }},"redis": {"image": "redis:7-alpine","health_check": { "cmd": "redis-cli ping", "interval": "5s", "retries": 20 }}},"launch_commands": ["pnpm install --frozen-lockfile","pnpm db:migrate"],"processes": {"web": {"command": "pnpm dev --host 0.0.0.0","auto_start": true,"ports": [{ "port": 5173, "public": true }]}}}}
- Place on host—
Four ways in.
This task failed the same test three times and asked for help. Open it, and you're inside its sandbox.
Four views of one sandbox. No transcript to piece together.
Look away. Nothing stalls.
Nothing lands without you. Your absence just doesn't stall it.
Big job? The agent splits it.
Audit a dozen packages. Port forty call sites. Try three fixes at once. Each piece becomes its own task.
Work that starts itself.
A new Sentry error. A Linear ticket labelled agent. A new GitHub issue. A failing check on main. Each can start an agent.
3 a.m. A new error. By morning, an agent has read the trace, found the commit, reproduced the bug and written it up, on the ticket and in a draft pull request.
You decide what merges.
A rule reads like a sentence.
When this arrives, if this holds, unless it's handled: start an agent, and tell it this.
"automation": { "rules": { "agent-label": { "name": "Linear: ticket labelled agent", "on": "linear.Issue.update", "edge": "became", "if": "payload.data.labels.exists(l, l.name == 'agent')", "mode": "armed", "instruction": "Implement this ticket. Put `Fixes` and the ticket identifier in the pull request body so Linear links them." } } }
Automations start the work. You still decide what lands.
One connection, both directions.
Events come in and start agents. Agents reach back out over MCP to read the trace, the thread or the timeline, and to comment or move the ticket on.
No rule needed to ask, either. Paste a Sentry link into a task, and the agent goes and looks.
Declared once. Built the same every time.
Configuration is declarative. One committed file names the image, the services, the launch commands and what every agent should know.
Sandboxes are deterministic. Each one is built from that file on the task's branch, the same way every time. Same config, same sandbox.
Every agent reads it, so nobody re-teaches. A repository can add to the prompt, never replace it.
{
"version": "1",
"agent": {
"append_prompt": "Run lint, format and typecheck before every commit, and fix what they report rather than silencing it."
},
"devbox": {
"dockerfile": ".tinsmith/devbox/Dockerfile",
"services": {
"postgres": { "image": "postgres:17-alpine" },
"redis": { "image": "redis:7-alpine" }
},
"processes": {
"web": {
"command": "pnpm dev --host 0.0.0.0",
"ports": [{ "port": 5173, "public": true }]
}
}
}
}Your hardware, our control plane.
How parallel you can be is a question about your hardware, not your plan.
The control plane stays awake when you don't, so a failing check at 3 a.m. still reaches an agent. Hosting it means one GitHub App, not one per company.
Self-hosted is for security reviews that rule out anything hosted.
What leaves your hardware
| Cloud | Hybrid | Self-hosted | |
|---|---|---|---|
| Code runs and the checkout lives | Tinsmith runners | Your hardware | Your hardware |
| Chat, diffs and terminal output are stored | Tinsmith | Tinsmith | Your servers |
| Preview traffic passes through | Tinsmith | Tinsmith | Your servers |
| Repository secrets are stored, encrypted | Tinsmith | Tinsmith | Your servers |
| Model inference | Anthropic API | Anthropic API | Anthropic API |
Three ways to run it.
Model usage is billed by Anthropic to your own API key.
Questions?
Does our code leave our hardware?
On Hybrid, the code runs and the checkout lives on your hardware. Chat, diffs and terminal output are stored by the control plane, and previews pass through it. On Self-hosted, nothing leaves except what the agent sends to the model. On Cloud, everything runs on ours.
What does a runner need?
A server or VM with Docker that can reach the control plane. Install a small daemon, give it a one-time key, and it connects out.
How many agents can run at once?
As many sandboxes as your runners hold. By default a runner offers one per vCPU.
Who pays for model usage?
Anthropic bills your API key directly.
Which models are supported?
Anthropic's models, for now. If you need another provider, tell us which and we're happy to add it.
Which Git hosts?
GitHub, for now.
Which tools can start an agent?
Sentry, Linear and GitHub, plus PagerDuty, Datadog, Jira, Zendesk and Snyk.
What stops an automation from running up a bill?
It's off until an admin turns it on. Every rule has concurrency and rate caps, can't re-trigger itself, and switches off when it misbehaves. Shadow mode shows what it would do first.
Do the agents merge without us?
No. They open pull requests and respond to CI and review. You decide what merges.
Let's scale you.
Tinsmith isn't open yet. Got a repository and a box to run it on? Write to us at hello@tinsmith.dev.
Write to us