Devin was good. I just wanted to pick the model.
So I am building Shiba: an open-source, approval-gated coding coworker that runs in your own Cloudflare account, on the harness and model you choose for each task — and shows you the work, including when it fails.
Honest status: a local prototype. Typecheck, lint, tests, and build pass locally. No cloud end-to-end run is recorded yet — see Readiness.
Two subscriptions, one $20 plan, and no say in the routing
For the past while I have been living in Devin and my own Claude Code setup at the same time. Both on the $20 tier. The arrangement is not the problem — I like both. The problem is the one decision I could not make.
Devin's SWE-2 is genuinely good. Its coding quality is close to what I get from Fable and Astra on my own setup, and it handles medium-to-heavy backend work without drama. I do not want to trash it, and I do not hand it everything.
It also feels slower than I want, and for frontend work I would rather point at a frontend model. There are tasks I simply do not want to hand to it. I have Opus and Astra on my own side, and I want to use them — not be locked into whichever model Devin decides I get that day.
I wanted Devin-style autonomy and computer use — inside my own harness, on my own routing, with my own account.
That sentence is the whole reason this project exists.
Three things I kept hitting, none of them about coding quality
The quality was fine. Everything that actually frustrated me was about control and access.
I could not pick the model
One model for every task. A heavyweight model is right for a large refactor and wasteful for a small frontend tweak. I wanted the frontend task on the frontend model, the heavy refactor on whatever holds up, the cleanup on the cheap fast one — and I wanted to be the one choosing.
I could not give it real access
I run the Cloudflare CLI on my own machine. When an agent gets a genuine task, it needs a genuine account, scoped tokens, and a real machine to run on. Devin did not let me set that up, so I made an agentic dev account for it myself — because the feature was missing, not because I wanted another login.
I could not see what actually happened
When background work hits an infrastructure error, I need the truth: which files changed, whether tests ran, what still needs a human decision. A cheerful "done" is not evidence. I hit this enough that it became a design requirement, not a feature request.
There was a fourth, smaller thing: MCP gave me trouble, and some parts I honestly cannot do yet. Slack is the one people ask about first — the lane exists in code, but I am not going to stand here and tell you everything works until I have a dated run that proves it.
Here is what I actually wanted
Not a cheaper clone. A different ownership model, with the decision I was missing put back where it belongs.
- Devin-style autonomy and computer use — hand off a task, let it run while you do something else.
- Inside your own harness — any supported harness, any mode, not one locked-in CLI.
- Your routing, per run — you name the harness and model for the task in front of you.
- Your account, your plan — your keys, your Cloudflare subscription, your bill.
- Your own agentic dev account — scoped tokens and a real machine, not your personal credentials.
- Evidence, not vibes — approval before a sandbox starts, and honest failure when something breaks.
A shiba is in it because a pet you can watch work is a better pet than a spinner. The engineer should be visible — you should be able to look at what it is doing, not stare at a status dot and hope.
The name itself? A Shiba Inu is a famously loyal Japanese dog — small, independent, stubbornly its own. That felt right: a software engineer that lives like a pet inside your Cloudflare account, with infrastructure and model costs depending on your configuration and usage.
A routing table is the whole product
If you take one thing from this page, take this. A cloud engineer you cannot point at a different model is not a coworker — it is a subscription with a spinner.
The sandbox image ships four pinned agent CLIs — OpenCode, Claude Code, Codex, and Devin. For any given task you name the one you want:
Mechanically, resolution walks per-run override → the automation's setting → the purpose policy → your deployment default, and it fails closed. An unknown connection, a disabled connection, or a model outside the connection's namespace is rejected before the approval card is minted — never inside a container, never halfway through a run.
To be precise about scope: per-run selection and per-purpose policies are implemented today. Automatic classification — reading the task, deciding it is frontend work, picking the model — is the part still on the roadmap. I would rather draw you that line now than let you find it later.
Three unsatisfying extremes
My specific complaints were personal. The gap underneath them is not:
Hosted coding-agent trade-offs
Hosted coding agents offer managed infrastructure; users should review each provider's current terms, privacy controls, and pricing before choosing a service.
The Local CLI Bottleneck
Running CLI agents on your personal MacBook is private, but it locks up your terminal, drains your battery, dies when your laptop sleeps, and cannot collaborate with your team via Slack or GitHub webhooks.
The Heavy DevOps Nightmare
Self-hosting can involve infrastructure and services to operate and maintain alongside product development.
Some teams prefer a managed service; others want to operate their own tools and infrastructure. Shiba is built for the second group: people who want an approval-gated coding coworker in their own Cloudflare account.
Why it runs on your Cloudflare account
Cloudflare provides the Workers and Sandbox building blocks Shiba uses. Shiba is designed to be deployed into an operator's own Cloudflare account; cloud deployment and acceptance still depend on account configuration and verification.
Cloudflare Workers: Task Orchestration
The planning brain runs as a Cloudflare Worker using TypeScript and the Cloudflare Agents SDK. It handles supported dashboard, chat, webhook, and scheduled triggers.
Cloudflare Sandbox containers
Each task runs in an isolated Cloudflare Sandbox container with the configured Docker toolchain. It creates an isolated task workspace, clones the requested branch, runs the harness you picked, captures output and changes, then ends the task container. The image pins every agent CLI version, so the harness is part of the run record rather than an assumption.
Credential Handling at Egress
Your real API keys never enter the container. Inside the sandbox, the agent CLI uses dummy credentials. Provider requests are intercepted at egress and authenticated through your configured gateway; the Devin harness uses Worker-side credential forwarding. These boundaries have local test coverage, which is not the same as proof of a cloud deployment.
Durable Objects & SQLite: state and approvals
Durable Objects provide atomic coordination: the Human Approval Queue, WebSocket hibernation for real-time log streaming, and session history in private embedded SQLite tables. Long-term memory is indexed via Vectorize, and runs are capped at five concurrent tasks.
Cloudflare Access (Zero Trust)
No JWT or OAuth servers to run yourself. Access fronts your dashboard and runner APIs with SSO, email pins, or hardware keys. Machine callers authenticate with cryptographic signatures — and forged Access identity headers are rejected, which we verified against a deployed Worker.
How Shiba Compares to Devin Cloud
Devin Cloud is a good product, and this page started as ordinary enthusiasm for it. The model lock is what turned that enthusiasm into a build. Shiba explores a different ownership model: open-source software you run in your own Cloudflare account.
Devin Cloud
- Hosted coding-agent experience, with managed infrastructure.
- Review Devin's current published plans for up-to-date pricing and feature details.
- Model and harness selection are the provider's to make.
- Designed for users who prefer a managed service over operating their own infrastructure.
Shiba (Cloudflare Native)
- AGPL-3.0 source deployed in your Cloudflare account; model and Git traffic still go to configured external providers.
- Cloudflare infrastructure and model costs depend on your account configuration and usage.
- Pick a supported harness and model per run or automation, with purpose policies as the default.
- Human approval is required by default; an opt-in unattended mode is limited to PR-only automations on an explicit repository allowlist.
Delegate from wherever you already are
A coding agent you cannot reach is not a coworker — it is a tool you have to babysit. The point of a cloud engineer is handing it work from anywhere and checking in later. So the same engine has to answer to more doors than a dashboard.
Built and tested
- Dashboard + CLI (manual runs)
- Cron schedules (five-minute floor)
- GitHub webhooks
- Slack mentions & slash commands
- Telegram and Discord bot triggers
- Per-automation webhook triggers
- MCP gateway — queue runs and read state; it can never approve
Not proven in a live run
- Provider-backed inference — the local run reached the boundary and got a 401, with no gateway credential configured
- Claude Code and Codex against live APIs — neither has run
- Peak memory, cold start, WebSocket hibernation
Next in the plan: iPhone and mobile as a first-class surface, plus the automatic task-to-route classification described above. Any of them can trigger a job, and the agent picks up the thread.
And the one people ask me about: Slack. The lane is implemented, unit-tested, and was exercised locally from a signed Slack approval into a Durable Object dispatch. It is not the part I have least confidence in — but it is not yet the part I can show you working in the cloud, so it stays in the honest column until a dated run says otherwise.
Run Shiba locally
You need Node 22.12+, pnpm 10+, and a Docker daemon — a missing Docker daemon fails even the local dry run. Cloud deployment depends on your account configuration and is not yet verified end-to-end.
git clone https://github.com/princepal9120/shiba.git
cd shiba && pnpm install
cp apps/backend/.dev.vars.example apps/backend/.dev.vars
pnpm dev
pnpm typecheck && pnpm lint && pnpm test && pnpm build
For detailed instructions on Slack setup, GitHub App configuration, and Cloudflare Access SSO policies, consult the Quickstart Documentation. Licensed AGPL-3.0-only.
Don't get locked into one vendor, one model, or one login.
That is the takeaway I keep coming back to. Bring the harness with you, and hand the work to whoever does it better that day — including a model that is not mine. Shiba is open source under AGPL-3.0-only, and it is not finished. If this gap sounds like one you have hit too, the fastest ways to close it are an issue, a PR, or telling me which trigger surface you actually need first.