I started Clawd as a joke and less than two days later I had stopped opening Claude Code as my primary interface for Claude models.

The setup was nothing super special. I just wanted to chat with the Claude Code instance running on my dev-box at home, and I didn't love the Claude Code mobile interface for remote control. It works fine, but is tied to one session and collects all that context with no way to clear/compact, so it just isn't how I want to talk to my machine. So I wired a Discord bot to the machine, told myself it would be fun to see how much use I'd get out of it, and did not expect to switch over fully as quickly as I have.

I have been a huge proponent of pair-programmers/pair-programming since aider first shipped. My argument has always been that the best work is output when a human and a model work on the same code together, and that handing the whole job off gives up the part worth doing. I still believe most of that. But there is something kind of… thrilling(?) spinning off an agent and letting it write whatever slop it wants for the next hour, and watching it go (or rather coming back to it to see what shenanigans it got up to).

I.

Slop is fun to watch, but is not sustainable, so I shifted to instead ask myself: what if a Discord bot could build itself? On the fly, with hot reloading, under a second of downtime per deploy. That worked so well that when Clawd wants to change itself, a second model (mostly Opus, because I like the vibes of Opus) spins off a sandboxed copy of the bot, mimics Discord as best it can, and runs the new version against that until it passes. Then it swaps the real bot over and waits for something to break. The first error becomes the next instruction: keep working on this until it is gone. That sounds trivial until you watch it close a bug faster than I would have, on roughly one percent of my 20x Max plan, because it never has to wait for me to notice and type "it's not working."

The handoff is fairly simple with a process supervisor and a queue in front of it. It cuts over only at safe points, after the current turn finishes or after a tool call, never in the middle of one, since interrupting a tool call mid-flight breaks things (don’t we just love how stable LLMs are?). For three or four seconds there are two bots alive at once, but they share the same bot token, so Discord only ever sees one. The old process retires after the turn, the new one takes the session, and the swap is invisible from the outside. I say "under a second of downtime" rather than zero because Python occasionally decides to take its time installing or spinning something up, and I would rather quote the number I can hit. What is still broken is the messaging. During that overlap window both instances sometimes answer, so you get two replies that are almost but not quite identical, drifting apart because the model is non-deterministic, and untangling that cleanly is the current annoyance. But I generally don't foresee this being an issue in the future, as you’ll read later.

For scale, I started this on the 23rd of June. It is the 27th now. So in four days Clawd has gone from a toy to my primary way of using Claude Code, across fourteen versions of itself, most of them shipped over two days of real development (if that), since the other days I just didn't need anything from it.

II.

Hello, Beckett.

The idea behind it is the oldest one in the agent playbook: give your agent a computer. Beckett takes the whole sentence seriously. It is built from the ground up to run in the cloud on my own infra, with Claude Code and Codex both as first-class citizens, and it treats the agent as something closer to an account-holder than a feature.

How you talk to it is the first thing you feel. Beckett is built to be a coworker, and you brief a coworker differently than you drive a tool. You hand it a spec if you have one, but you don't have to; "implement this" is often the whole prompt, and it comes back with "on it" and starts building, asking questions only when it hits one. My input tokens dropped sharply moving from Claude Code to Clawd to Beckett for exactly this reason. It is primed to act on anything reversible without checking in, and to branch hard across worktrees while it does, so if you don't like where a branch went you revoke it and nothing else is touched.

Underneath that is the closely guarded secrets, literally. The credentials. Beckett's secrets live in a vault that is deliberately awkward to reach, hidden elsewhere (shhhhh) rather than under /home/beckett or ~/, which is the only place Beckett is allowed to operate. It cannot cd .. out of its own directory, and the box will only accept a login from my MacBook, so if I lose that MacBook I am, in the technical sense, cooked. That is fine for now; I have no reason to over-engineer the security before anyone is even using it. Credit where credit is due, despite how much I dislike GPT 5.5 in terms of “vibes”, 5.5 Pro helped a lot with crafting a robust safety model for my at home device.

This is what "org-level for people with no org" cashes out to. Beckett owns its own GitHub account, its own system, its own tooling. It can open repositories under its own name or work inside yours, and it holds that identity across services the way a colleague would rather than borrowing yours each time. The account is empty today because it is days old; what will land on it are the projects built during the beta and the primitives I am writing specifically for Beckett to stand on, all of which stay private for now. And maybe some really cool features I have down the road.

Context works the same way, as something Beckett manages rather than something fixed at the start. It pools context when sharing helps, and otherwise tags each message on its own so it can act as an individual collaborator instead of one blurred group memory. It can also rewrite that call after the fact: if it assumes you were working as a group and you actually wanted it to be one-to-one, it can prune the shared context back out and pull in only what that thread needs. Which is, I think, pretty damn cool.

The infrastructure is nothing exotic. Right now Beckett runs on my glamorous 10 yr old home server, containerised, so moving it to a VPS or out to Daytona is a config change rather than a rebuild, but today it is the home box and nothing fancier. Although I would love to talk about the specifics of what kind of container I am using, I realise this is on the interwebs, and I don’t want to open myself to targeted attacks on my system if I don't have to.

That said, Beckett is not the first thing to work this way. There is a big inspiration from Claude Tag in here, which is what nudged me to start this whole thing. I would like Beckett to be the best version of it.

III.

So: a limited alpha. Ten people, free (for now), because I only have so much money and I would rather give a few people real room to work than a hundred people a demo. It opens today and all you have to do is get Beckett to grant you access. How hard could it be?

You can put your name in on the discord found: https://0xbeckett.me. What you get is a share of the roughly $250 in credits I am putting up, stretched by the fact that Beckett already provisions across several models and leans on caching to hold costs down. With five people potentially leaning on a model priced around $5 in and $25 out per million tokens, my best guess is that the pool lasts about a month before I have to top it up, but we will see how it holds once real usage hits it.

I am not fussy about who you are. Any experience level, any timezone, any stack, and the more your stack differs from everyone else's the better, because part of what I want to stress-test is Beckett installing what it needs on the fly: standing up Postgres, pulling a third-party library, whatever your project drags in. The work will be mostly asynchronous, but I am looking for people who will collaborate, who will use Beckett to build Beckett and report back where the seams show, and who think a step ahead rather than waiting to be told what the tool is for.

IV.

On pricing I will say what I plan to do, because I also realise nobody wants another AI subscription for a black box they can't evaluate (it will be open source, later). Once Beckett is out of beta I will charge enough to keep the project funded with a fair margin on top, and no more than that.

The number I have in mind is 20 dollars a month for about twenty dollars of usage, as the baseline expectation. If I can give you more than that I will, but I want the deal to be legible. I do not have the capital to run the OpenAI move, where a $20 plan quietly floats 800 to 1000 dollars of inference. I would rather you know exactly what your money buys. As we switch to capable cheaper models (such as GPT 5.6 Luna or Terra when it becomes available) or even Chinese models such as (but not limited to): GLM 5.2, Kimi K2.7, MiniMax M3, etc. your 20 dollars will/can go further. However currently, credits only apply to Claude.

That is also why I will not sell a hundred-dollar plan unless I can sustain a hundred dollars of usage behind it, and a hundred dollars does not buy a hundred dollars of API credits anyway, not once you subtract energy, domains, and hosting. So the plans will be the ones I can back.

This is the idea. Let's beck it.