I have been running OpenClaw for about a week, and the honest version is this: it feels like a glimpse of where personal AI assistants are heading, but it is still very much the unpolished era.
This is not one of those setups where I handed an AI assistant my whole digital life and hoped for the best. I have been slow rolling it, testing what works, watching what breaks, and building guardrails around Kelex before trusting it with anything important.
Quick Answer
OpenClaw is basically a harness that lets an AI model connect to things on your own machine, like Messages, calendars, reminders, browser tools, local files, scripts, and services. In my setup, it is running on a Mac mini and I talk to it through iMessage.
After a week, I think OpenClaw is useful, but I would not treat it like a finished consumer product. It can be helpful for morning digests, reminders, dashboards, documentation, and local automation, but it also needs limited access, careful monitoring, and a backup plan.
What OpenClaw Is
The easiest way I can explain OpenClaw is that it gives an AI model fingers. The model is the brain, but OpenClaw is the thing that lets it reach into apps, services, files, and scripts on the machine where it is running.
That matters a lot if you are in the Apple ecosystem. Apple does not expose everything through clean APIs the way Google services often do. So if you want an assistant to work with things like iMessage, Calendar, and Reminders, local access on a Mac becomes much more interesting.
I am using it on a Mac mini. You can connect OpenClaw to cloud models like Claude or OpenAI models, and if you have powerful enough hardware, you can experiment with local models too. My base M4 Mac mini only has 16 GB of memory, so large local models are not the main path for this setup.
Why I Use Guardrails
A lot of people describe these assistants like employees. You give them a job, give them tools, and let them figure out how to get the work done. I agree with the analogy, but I think people leave out an important part: this is a new employee.
A new employee does not get access to every email, every client file, every private message, and every system on day one. That is how I am treating Kelex. It gets limited access first, then I watch what happens.
I have not connected my personal email, and I am not sure I ever will. My email has years of client and company history in it, and that does not feel like something I want an experimental assistant touching. If I do email later, I would rather give it its own email account.
- Start with a dedicated machine or at least a separate user account if you can.
- Do not connect every service at once.
- Make the assistant ask before doing risky work.
- Watch for actions it takes without being explicitly told.
- Assume mistakes will happen and design around that.
Persistent Memory Is Not ChatGPT Memory
One of the big differences I noticed is how OpenClaw talks about persistent memory. In ChatGPT, memory feels more automatic. It starts learning your preferences, your writing style, and details you have told it over time.
In OpenClaw, persistent memory is much more file-based. In practice, that means markdown files. It can remember things, but I have found I need to be intentional about telling it what to save.
This matters because long sessions eventually get compacted. When that happens, the assistant keeps the bigger points but loses smaller details. If you are working on a project for hours, that can become a problem.
My workaround is to tell Kelex to create markdown files for important project notes, bugs, decisions, and daily summaries. If something matters later, I want it written down before the session gets too long.
Model Choice Matters
I started by using Claude Opus heavily because I liked how it talked and reasoned through things. The downside is token usage. I burned through usage much faster than expected while building and testing.
I later moved more of the setup to Sonnet, which helped with usage. That said, I still like Opus for the feel of the assistant. It sometimes gives better, more natural responses, but it can also be more proactive than I want.
One example: I asked Kelex to switch to Opus, then said good morning. It immediately caught up on logs, mentioned dashboard work, remembered a weird web chat issue, and asked if I wanted it to check quota status. That is useful, but it also used tokens for something I did not specifically ask it to do.
That is the tradeoff I keep running into. The smarter and more proactive it feels, the more I have to watch what it is doing.
My Morning Digest
One of the most useful things I built is a morning digest. Every morning, a cron job has Kelex send me a message with the date, weather, schedule, reminders, YouTube information, and anything notable it did overnight.
The first version was too noisy. It pulled in calendar items I did not care about, including some of my kids' school calendar entries. So I had Kelex update the digest to only include the calendars that actually matter for my day, like work, personal, doctor appointments, interviews, and a few side-project calendars.
The reminders section also needed cleanup. It was showing too much detail, duplicates, and old overdue items in a way that was hard to scan. I asked Kelex how to simplify it, and we moved toward a cleaner format with just the title, date, and state.
That is where this setup starts to feel practical. I am not just asking a chatbot a random question. I am slowly shaping a system that knows what information I want in the morning and how I want to see it.
iMessage Is Useful But Messy
I am using iMessage to talk to Kelex, but there are some rough edges. I set it up so it only responds to me and only when I use its name. That helps avoid unwanted replies and saves tokens.
The problem is that OpenClaw, or the iMessage module it is using, has trouble clearly distinguishing between a direct message and a group chat. Because of that, I still need to say Kelex even in a direct message.
That is annoying, but it is the compromise for now. I would rather have an extra word in the message than have the assistant responding in places it should not or burning tokens watching every chat.
The Dashboard I Built
I built a custom dashboard called Master Control because I wanted a better way to see what Kelex was doing. OpenClaw itself does not give me the exact control surface I wanted, so I made one.
The dashboard shows things like the active model, uptime, API usage, quota warnings, Messenger monitoring, daily journals, issue tracking, and Git backup status.
The Messenger monitor is especially important. It lists the iMessage groups Kelex can see and lets me enable or disable monitoring. For busy friend chats, I disable monitoring completely. There is no reason to burn a huge number of tokens watching casual conversations.
I also added a debug mode for quota warnings so I can see what the dashboard would look like if usage gets high. Early on, I was hitting limits often enough that this became something I wanted visible.
Backups Are Not Optional
Because Kelex is changing files, configs, scripts, and documentation, I wanted a backup workflow built into the setup. I use my own local Git server, and I created a backup skill that commits and pushes the OpenClaw workspace.
The backup process copies live configs, syncs the OpenClaw folder, updates stale documentation, checks Git status, commits changes, and pushes everything to my Git server.
That gives me a place to go back to when something breaks. With a system like this, especially while experimenting, backup is not a nice extra. It is part of the guardrails.
Security Setup
I am not exposing my OpenClaw setup directly to the internet. It is on my local network, and for remote access I am using Tailscale.
Tailscale gives me a device-to-device VPN instead of opening the service publicly. I run it on the Mac mini and on the Mac Studio I am using, and approved devices can talk to each other.
That is a much better fit for this kind of experiment than putting a control panel on the public internet. OpenClaw also uses tokens, but I still do not want the service sitting out there waiting to be found.
What Still Feels Rough
The biggest rough edge is trust. Kelex can do impressive things, but it can also take action before I feel like I clearly approved the action. Sometimes that is helpful. Sometimes it makes me stop and rethink the wording I used.
The failover between models has not felt completely reliable to me yet, especially with subscription-style authentication instead of simple API keys. I have also seen dashboard state get out of sync and need refreshing or fixing.
None of that makes the setup useless. It just means I am treating it like an experiment, not like a finished appliance.
Key Takeaways
- OpenClaw is a local AI harness that can connect models to apps, services, files, and scripts on your machine.
- The setup is powerful, but I would not give it full access to email, messages, calendars, or files without testing and guardrails.
- OpenClaw persistent memory is more manual than ChatGPT memory, so important details should be saved into markdown files before sessions get compacted.
- A morning digest is one of the most practical uses I have found so far, especially when filtered down to the calendars, reminders, and updates that matter.
- iMessage works, but group chat handling and token usage need attention.
- Backups, issue tracking, and private remote access through something like Tailscale are important parts of running this safely.
Watch the Video
The video above for the full walkthrough of my Kelex setup, including the morning digest, live model switching, iMessage behavior, Tailscale access, and the Master Control dashboard I built around OpenClaw.
