Imagine you hand someone the job of building a YouTube channel analytics dashboard in the evening, you go to sleep, and in the morning the dashboard is ready. That's exactly how Clawdbot works — a tool that turns an AI model into a self-directed assistant running in the background. You message it like a person, and it carries out tasks even while you sleep. I'll show you what such an assistant actually does, how it's built, what it costs and what you need to keep in mind before you give it access to your data.
What Clawdbot actually is
Let me start with the vocabulary, because without it the rest blurs together.
An agent is a program built on an AI model that doesn't just answer questions but runs steps on its own: it reads files, uses tools, takes actions. Clawdbot is the wrapper that turns an AI model into exactly that kind of agent — you run it on your own computer (a Mac Mini, say) or on a cloud server (a VPS — a rented machine that runs nonstop). Once started, Clawdbot lives in the background and waits for instructions.
In practice you give an assistant like this a name and treat it like a member of the team, not a chat window. That's not a flourish: the whole concept rests on the assistant having its own identity, its own accounts and its own remit, like a new administrative assistant.
The difference from an ordinary chatbot is concrete. A classic assistant has a rigidly programmed set of features — to add a new one, someone has to build it by hand. Clawdbot works differently: you describe a feature in words, and it checks for itself whether it can be done, and if so — it builds it. "Can you send voice notes?" — "Let me check how it works… I can do it like this. Shall I set it up?" What's left on your side is what the machine can't handle on its own: buying a plan, supplying an access key to some service, approving a spend.
What working with it looks like day to day
You steer the assistant through Telegram — you write messages as if to a friend, and replies come back on the same channel. On top of that you build yourself a dashboard, to see what's going on. Three parts of that dashboard are key, because they show how the whole thing works.
A task board in a "to do / in progress / done" layout. The assistant updates it on its own as it works. Importantly: if you add a new task to the "to do" column yourself, the assistant picks it up and starts on it — with no extra instruction.
An activity log — a record of every action, with a timestamp. This is how you know what happened overnight: the assistant can get going at night and return to work every half hour or so — for example just after midnight, then again toward morning. Without a log like this, there's no way to verify what really happened.
A status panel — it shows whether the assistant is, at a given moment, thinking, working or sitting idle. You can also see when it spins up a so-called sub-agent — a helper agent fired off for one specific task, for example for deeper research.
The second pillar of day-to-day work is the heartbeat — literally that. It's a recurring signal that "wakes" the assistant every 30 minutes. On each such wake-up the assistant checks whether the dashboards are working, runs a sync, looks in on new notes, monitors the inbox and email. That way it doesn't sit passively waiting for an instruction — it regularly checks for itself whether there's anything to do.
Memory: the strongest and the most unreliable part
This is where the most important caveat of the whole concept comes in, so it's worth taking it head-on: the assistant wakes up with no memory every time. It doesn't remember the previous conversation off the top of its head — its memory is the files it writes and reads itself.
It works on several levels. There's an identity file ("soul" in the original — who the assistant is and what its role consists of) and a file about the user (who you are and what you do). They're created at the start, during a long onboarding conversation in which the assistant simply questions you. On top of that come three kinds of notes: a daily log (raw jottings from a given day), long-term memory (selected, durable facts about you and the company) and memory tied to a specific project.
The trouble is that it's the assistant that decides what to save — and sometimes it doesn't save the very things it's about to forget. Let me put it plainly: it happens that you write "hi," then give your name, and a moment later the assistant asks "what's your name?" The practical takeaway is simple: you have to tell it outright where to save something ("save this to long-term memory," "add this to the log"). The memory works, but it isn't hands-off — it needs leading by the hand.
Security: treat it like a new hire
This is a thread I'll repeat a few times, and rightly so — because the assistant is given access to real tools.
The most important rule: separate accounts for the assistant. You don't log it into your main email, calendar or task system. You set up its own — a separate inbox, its own drive, its own account in the task tool. Then you hand work over to it the way you would to a real assistant: you forward an email, add it to the cc. A control question worth asking yourself: on day one, would you give a new hire your card details, your passwords and access to everything? Probably not.
The second rule: you keep access keys (so-called tokens) in a separate configuration file, never in the body of a conversation. A token is a string that confirms a given application has the right to use a service — something like a password for programs. You enter it into the file once; you instruct the assistant to use placeholders only (markers along the lines of "[key here]"), so the key never appears in the chat history.
The third rule: read-only by default. The assistant can see the calendar, read tasks, pull data from social media — but not delete, not publish and not change anything without explicit consent. The right to act is granted case by case, and where there's spending, you set a limit. Let me say honestly: this isn't advice from a security specialist, so stick to a simple rule — don't connect random services if you don't understand what's going on.
What it really costs
Here come the numbers, because it's the numbers that cool the excitement. With very intensive use — an Opus-class model, working almost nonstop — a few days' bill can reach the order of several hundred dollars. Treat that as an order of magnitude, not a rule. (A token is a fragment of text the model operates on; you're billed for how much text you feed the model and how much it returns.) With calm, personal use the real cost can be on the order of a few tens of dollars a month, though in my view it'll come out higher in practice. A cheaper model, or one run locally, would bring that cost down.
One important practical note. You run Clawdbot over the API (the interface that connects your program directly to the model and bills for actual usage), not through a Max-style subscription. The reason is concrete: the model provider was blocking subscription accounts for breaching the terms of service with this kind of use. For the initial setup, set aside 4–6 hours of work over a weekend.
Five practical working rules
To finish, the lessons that emerge after a few days of working with this tool. These aren't tricks, they're habits.
- Plan first, execute second — and save everything to files. Have the assistant prepare a plan and save it as a document, and only then say "execute this document." That way the assistant has the whole context to hand and doesn't lose the thread between one message and the next.
- Bet on proactivity. Without it the tool is little different from an ordinary chat. The point is for the assistant — knowing you and the company — to spot on its own where it can save you time, and to act before you ask. A good question to put to it: "what takes me more than 20 minutes today that you could shrink to a two-minute check?"
- Let it learn from its mistakes. The assistant will get things wrong — more often than you expect. Instead of writing "wrong again," have it analyze why something didn't work and save the conclusion in a document. The mistake then becomes a lesson for the future, not just an irritation.
- Manage memory deliberately. This comes back like a boomerang: say outright what to save and where. Understanding how the assistant remembers comes with time and repetition — not from a single setting.
- When you get stuck, reach for Claude Code. Claude Code is the tool in which Claude works on programming and configuration tasks with a view of the whole project — files, settings, keys. When you get lost in configuration or in security questions, it's easier to work out the solution there first and then hand it to the assistant.
The whole thing is worth reading through the same filter I'd apply here myself: the tool can be very sharp and very dim-witted within the same hour. Someone else's use case isn't your use case — before you build your own assistant, start with the question of which specific repetitive chore you want taken off your plate. That, not a flashy dashboard built overnight, will tell you whether it's worth it.