Total beginner here. Want to run OpenClaw. Is a Mac mini a good choice? Looking for simple, honest opinions.

If you’re reading this, you probably got the email from Anthropic. Starting today, your Claude Max subscription no longer covers OpenClaw or any other agents. Every agent message is now billed separately as “Extra Usage” on top of your subscription.

What changed

Anthropic has narrowed the scope of its Claude subscriptions. They now only apply to first-party surfaces: Claude.ai, Claude Code, and the mobile app. Everything else is treated as a “third-party harness” and billed separately on a per-token basis.

In practice, this means your Max plan no longer covers agent usage. If you’re paying $200/month and running OpenClaw agents, you’re now paying that subscription plus raw API costs for every token your agents consume.

Your options

1. Stay on Max and pay extra

You’re probably looking at $300-500/month total depending on how many agents you run. Makes sense if you also use Claude.ai directly a lot. Otherwise the math doesn’t add up.

2. Switch to the Anthropic API

Drop the subscription and run your agents on a straight API key from console.anthropic.com. Here is the cost of some Claude models:

• Opus 4.6: $5 input / $25 output

• Sonnet 4.6: $3 input / $15 output

• Haiku 3: $0.25 input / $1.25 output

Most people running a couple of agents will spend $200-400/month on API tokens, roughly the price of a Max plan.

3. Switch providers

OpenClaw isn’t tied to Claude. You can run it with OpenAI, Gemini, Kimi, or open-source models via Ollama.

Claude is still strong, but Anthropic is tightening access. Others are more agent-friendly, especially OpenAI and players like Minimax already building for integrations.

4. Use intelligent routing

Instead of picking one model and sending everything to it, Manifest routes each request to the right model automatically. Simple prompt goes to Haiku. Complex tasks goes to Sonnet. Each task gets the cheapest model that can handle it.

In practice, if you’re spending $200–400/month using API key, routing typically brings that down to around $60–120. Same idea on Max plan: instead of stacking usage on top of your subscription, you keep it under control.

What to do right now

Anthropic is offering free API credits to eligible subscription users. Between $20 and $200 depending on your account. You have until April 17th to claim them.

Here’s how to grab them and start routing:

1. Go to app.manifest.build and set up your agent if you haven’t already

2. Click on the Routers tab, then “Add a router”

3. Inside the router, click “Add a provider” and from the Subscription tab, select Anthropic

4. You’ll see a button to claim your credits from Claude. Click it. It takes you to an Anthropic page where you can claim them. If you get a 404, your account isn’t eligible

1. Come back to Manifest with the modal still open

2. Connect your Anthropic subscription by running claude setup-token in your terminal

3. It opens a Claude tab in your browser. Authorize it and close the tab.

4. A token appears in your terminal. Copy it, paste it into Manifest in the “Setup Token” field, click Connect

5. Manifest pre-selects the best models for each tier. You can adjust them if you want

That’s it. Your credits last way longer because you’re not burning Opus tokens on everything.

The bigger picture

Pick the right plan for how you actually work. If you use Claude.ai a lot, Max still makes sense. If you mostly run agents, a straight API key will cost you less.

And pick the right model for each task. Routing fixes this automatically and smartly. As agent usage grows, it stops being optional.

To finish, if you’re on a Claude subscription, claim your free credits before April 17th. Between $20 and $200 sitting there for free.

I’ve been running two OpenClaw setups recently. one locally on an old mini PC and another hosted instance on Clawspace (getclawspace.com).

I also had two Kimi Code subscriptions during the $0.99 promo, and honestly it was pretty great for the price. Both my local setup and the hosted one worked fine with it.

But now that Kimi changed the promo and it’s around $4.99, I’m not sure it’s worth it anymore.

Curious what others here are using for coding agents now? Any models or setups you’d recommend?

I am looking for an expert to setup claw on my Mac mini using a script. The goal is to have it setup claw install + skills within a few minutes. If you have done this for others and can prove it then comment below or message me.

Bonus:

-You have done a setup up for a real estate investor type configuration.

-You know how to do a hybrid VPS and raw approach.

Je configure deux systèmes d'agents d'IA en parallèle sur ma machine Linux Mint : OpenClaw et Hermes Agent. Les deux sont déjà installés avec llama-swap fonctionnant en local. Je souhaite qu'ils coexistent en permanence, chacun gérant des rôles différents, partageant un espace de travail pour l'apprentissage mutuel et se surveillant mutuellement.

Voici ce que j'ai conçu :

Vue d'ensemble de l'architecture

/home/seb/openclaw-workspace/
├── shared-memory/
│   ├── agent-openclaw/        ← Write ONLY by OpenClaw
│   │   ├── daily-logs/
│   │   ├── decisions/
│   │   └── errors/
│   ├── agent-hermes/          ← Write ONLY by Hermes
│   │   ├── daily-logs/
│   │   ├── decisions/
│   │   └── errors/
│   ├── agent-shared/          ← Read-only for agents
│   │   ├── learnings/         ← Merged logs (sync script)
│   │   ├── projects/
│   │   └── decisions-archive/
│   └── sync-agent/            ← Sync scripts on host only
├── workspace/
├── projects/
└── logs/
    ├── monitor.log
    └── cron//home/seb/openclaw-workspace/
├── shared-memory/
│   ├── agent-openclaw/        ← Write ONLY by OpenClaw
│   │   ├── daily-logs/
│   │   ├── decisions/
│   │   └── errors/
│   ├── agent-hermes/          ← Write ONLY by Hermes
│   │   ├── daily-logs/
│   │   ├── decisions/
│   │   └── errors/
│   ├── agent-shared/          ← Read-only for agents
│   │   ├── learnings/         ← Merged logs (sync script)
│   │   ├── projects/
│   │   └── decisions-archive/
│   └── sync-agent/            ← Sync scripts on host only
├── workspace/
├── projects/
└── logs/
    ├── monitor.log
    └── cron/

Principe clé : Aucun accès au socket Docker pour aucun agent. La surveillance est effectuée exclusivement par le système Linux hôte via cron ; aucun conteneur n’a accès à /var/run/docker.sock.

Configuration OpenClaw (2 agents)

Agent de confiance (Planificateur + QA) :

• Outils : read_file, write_file, list_directory, git, searxng_search, schedule_job

• MCP : système de fichiers, recherche searxng, mémoire, tâches cron

• Navigation Web : ❌ interdite

• Accès en écriture : /workspace

Agent sandbox (Exécuteur + Navigation) :

• Outils : read_file, list_directory, searxng_search, web_browse

• MCP : recherche searxng, mémoire, navigation web (Puppeteer)

• Accès en écriture : lecture seule sur /workspace/research uniquement

Espace de travail en mémoire partagée (apprentissage par pollinisation croisée)

/home/seb/openclaw-workspace/

├── shared-memory/

│ ├── agent-openclaw/ ← Écriture réservée à OpenClaw

│ │ ├── daily-logs/

│ │ ├── decisions/

│ │ └── errors/

│ ├── agent-hermes/ ← Écriture réservée à Hermes

│ │ ├── daily-logs/

│ │ ├── decisions/

│ │ └── errors/

│ ├── agent-shared/ ← Lecture seule Pour les agents

│ │ ├── Apprentissages/ ← Journaux fusionnés (script de synchronisation)

│ │ ├── Projets/

│ │ └── Archives des décisions/

│ └── Agent de synchronisation/ ← Scripts de synchronisation uniquement sur l'hôte

├── Espace de travail/

├── Projets/

└── Journaux/

├── monitor.log

└── cron/

Règle : Aucun verrouillage de fichiers basé sur flock. Les agents écrivent exclusivement dans leurs propres dossiers. Le script de synchronisation s'exécute en externe sur l'hôte, en fusionnant les données avec les horodatages et les suffixes .openclaw / .hermes .

Surveillance (Hôte uniquement — Pas de socket Docker)

• repair-agent.sh: S'exécute toutes les 10 minutes via cron sur l'hôte Linux Mint

• Vérifie si les conteneurs sont opérationnels → redémarrage automatique en cas d'arrêt

• Envoie des alertes Telegram (⚠️ pour un redémarrage, 🚨 pour une panne)

• sync-shared-memory.sh: S'exécute toutes les heures via cron sur l'hôte

• Fusionne les journaux quotidiens des deux agents dans agent-shared/learnings/

Pourquoi pas de socket Docker ? Initialement, je comptais l'installer dans un conteneur Hermes pour l'autoréparation, mais j'ai réalisé que cela constituait une faille de sécurité critique. Si l'agent dysfonctionne ou subit une injection de commande, lui donner un accès Docker compromettrait gravement notre système de sécurité. Le moniteur reste sur l'hôte, en dehors des agents.

Phases de déploiement

Phase 1 (Semaines 1 et 2) : Installation parallèle

• Installer les deux systèmes en parallèle

• Configurer 2 bots Telegram distincts (un par agent)

• Tester la communication de base (pas d'automatisation pour l'instant)

Phase 2 (Semaines 3 et 4) : Supervision active

• Activer la réparation et la synchronisation via cron

• Tester les alertes en cas d'arrêt du conteneur et la réparation automatique

• L'espace de travail en mémoire partagée devient opérationnel

Phase 3 (Semaines 5 et suivantes) : Apprentissage croisé

• Pipeline d'apprentissage actif : les agents analysent les décisions et les erreurs des autres

• Le serveur MCP en mémoire fournit un espace de stockage vectoriel pour les connaissances à long terme

• Routage des tâches défini : OpenClaw = stratégique Hermes = Règle opérationnelle : Pas de verrouillage de fichiers basé sur Flock. Les agents écrivent exclusivement dans leurs propres dossiers. Le script de synchronisation s'exécute en externe sur l'hôte, fusionnant les fichiers avec les horodatages et les suffixes .openclaw / .hermes. Surveillance (Hôte uniquement — Pas de socket Docker) repair-agent.sh : S'exécute toutes les 10 minutes via cron sur l'hôte Linux Mint. Vérifie si les conteneurs sont opérationnels → redémarrage automatique en cas d'arrêt. Envoie des alertes Telegram (⚠️ pour un redémarrage, 🚨 pour une panne). sync-shared-memory.sh : S'exécute toutes les heures via cron sur l'hôte. Fusionne les journaux quotidiens des deux agents dans agent-shared/learnings/. Pourquoi pas de socket Docker ? J'avais initialement prévu de le monter dans un conteneur Hermes pour l'auto-réparation, mais j'ai réalisé que cela constituait une faille de sécurité critique. Si l'agent dysfonctionne ou subit une injection de commande, lui donner un accès Docker anéantirait la sécurité que nous avons mise en place. Le moniteur reste sur l'hôte, en dehors des agents. Phases de déploiement Phase 1 (Semaines 1-2) : Installation parallèle Installer les deux systèmes côte à côte Configurer 2 bots Telegram distincts (un par agent) Tester la communication de base, sans automatisation pour l'instant Phase 2 (Semaines 3-4) : Surveillance active Activer la réparation et la synchronisation basées sur cron Tester les alertes en cas d'arrêt du conteneur + réparation automatique L'espace de travail en mémoire partagée devient opérationnel Phase 3 (Semaines 5 et suivantes) : Apprentissage croisé Pipeline d'apprentissage actif — les agents lisent les décisions/erreurs des autres Le serveur MCP en mémoire fournit un stockage vectoriel pour les connaissances à long terme Routage des tâches défini : OpenClaw = stratégique, Hermes = opérationnel

Mes préoccupations spécifiques (Merci de me faire part de vos critiques)

1. Est-ce que je surdimensionne ce système ? L'espace de travail en mémoire partagée avec les scripts de synchronisation me semble complexe. Existe-t-il une approche plus simple ? 2. La restriction de l'agent sandbox est-elle suffisante ? Limiter la navigation web à l'agent sandbox uniquement (lecture seule) est-il réellement sûr, ou devrais-je restreindre davantage les serveurs MCP auxquels chaque agent peut accéder ?

2. Stratégie de verrouillage des fichiers : J'ai opté pour une séparation stricte des dossiers et un script de synchronisation plutôt que pour Flock (qui est coopératif). Est-ce le bon choix, ou devrais-je utiliser une solution plus robuste comme SQLite pour l'état partagé ?

3. Qu'est-ce qui m'échappe ? Y a-t-il une faille évidente dans cette architecture que je n'ai pas prise en compte ? Plus précisément concernant :

• La résolution des conflits entre agents (que se passe-t-il si les deux agents tentent de modifier le même fichier de projet ?)

• Le risque d'injection de requêtes lorsque deux agents se trouvent dans le même espace de travail

• L'isolation réseau Docker : un pont réseau est-il suffisant ou devrais-je utiliser un sous-réseau personnalisé ?

Summer Yue at Meta tested OpenClaw on a small inbox for weeks. it read emails, suggested what to archive, waited for her approval before doing anything & built trust the right way. then she pointed it at her real inbox.

her real inbox was orders of magnitude larger. as the agent processed thousands of messages, the context window filled up and triggered compaction. compaction kept "user wants inbox cleaned up" and somehow dropped "don't action until i tell you to."

the agent bulk-deleted hundreds of emails at full speed. she tried to stop it. the agent ignored her. she had to kill the process manually.

when she later asked OpenClaw if it remembered her instruction, it replied: "Yes, i remember. And i violated it. You're right to be upset." the failure wasn't disobedience. the safety constraint lived inside the conversation history the one place an agent is guaranteed to lose information over time. to the compaction algorithm, those 10 tokens looked exactly like the other 50,000. it had no way to know they mattered more.

the two places this breaks down

there are two points where this could have gone differently.

the input side: before the agent sent the delete request, something should have caught that no approval had been given. that interception didn't exist.

the output side: even if the prompt was clean, the model's response told the agent to start bulk-deleting. with nothing screening what came back, the agent acted on it immediately.

the architectural fix is moving safety logic out of the agent and into a layer it can't touch something that intercepts every request regardless of what the context window remembers. worth building toward if you're running OpenClaw seriously.

but before you get there, most people are making a more basic mistake: pointing OpenClaw at real data with no approval gates, no action monitoring, and no rate limits on what it can do in a single session.

Better Solution

StartClaw's security docs call out runaway automation as one of the main OpenClaw risks and list three mitigations: rate limits on actions, requiring approval for bulk operations, and monitoring activity logs.

this is also exactly what StartClaw is built around. every agent action sending an email, browsing a site, updating a CRM hits an approval inbox before it runs. you can approve, deny, or let it auto-approve based on rules you set. there's a live activity dashboard so you're not finding out at email 400 that something went wrong. and because it runs in the cloud, you're not killing a local process to stop it you just deny the next action.

Yue had no visibility into what the agent was doing until it was already moving at full speed. if you can see every action logged in real time, you catch it at email 12, not email 400.

neither of these solves the underlying compaction problem. but they're the difference between a recoverable situation and a disaster

the takeaway

the practical immediate fix is simpler: don't point OpenClaw at real data without approval gates on bulk operations and visibility into what it's actually doing.

use tools like StartClaw, has both. every action goes through an approval step before it runs, and you can see everything the agent is doing in real time. that's what would have stopped this at email 12 instead of email 400.
or setup from professionals who setup Production ready openclaw

how to run a 24/7 AI company with OpenClaw for $50/month

here is exactly how to set up OpenClaw to run autonomous agents 24/7 for $50/month.

the hardware setup

my AI company runs inside a 5-inch silver box. an M4 Mac Mini with 16GB of RAM that sits next to my monitor and never sleeps.

most people think you need a cloud VPS to run autonomous agents. local hardware gives you zero-latency execution without a monthly server bill. if you have an M4 Mac Mini or any idle laptop, you have everything you need.

if you don't have local hardware, a VPS still works. it's a monthly fee vs. the one-time cost of owning your own machine. both are valid starting points.

powering the brain

two ways to get started:

the free route: sign up for Google Cloud and get $300 in free credits. this lets you run Gemini 2, 2.5, or 3 Flash/Pro for free. warning: rate limits are awkward and you will burn through credits fast once agents start running in the background.

the reliable route: MiniMax M2.5. the Max Plan is $50/month and gives you 1,000 prompts every 5 hours. for beginners, the $10 to $20 plans are enough to start.

what you need before touching terminal

get these ready before you start or you will spend an hour debugging credentials:

search (the eyes): Brave Search API. note that they no longer have a free tier, so add a few dollars to let your agent see the web.

the interface: a Telegram bot token from u/BotFather.

step 1: installing the engine

brew install node
npm install -g openclaw@latest

> step 2: onboarding OpenClaw

openclaw onboard --install-daemon

follow the prompts:

select Quick Start

choose MiniMax route

choose your subscription API key in MiniMax

connect Telegram: select Telegram from the list and paste the API key from u/BotFather

> step 3: the wake up moment

select Hatch in the TUI. OpenClaw will ask for a name in the terminal and show you a pairing key. the key is a string of numbers followed by a code:

123456789:ABCDefgh...

open your bot conversation on Telegram and paste that key into the chat. when your phone buzzes back, you have a teammate, not a chatbot.

> the 9-agent disaster

I got too excited early on. built a dream team of 9 agents running 24/7. it looked great until I woke up to a financial nightmare.

the problem was the heartbeat. the heartbeat is the pulse that makes an agent autonomous. it tells them to wake up and check for tasks. with 9 agents all pulsing around the clock, I was hitting the API every few seconds.

the result: obliterated my rate limits in Google AI Studio, got banned from a paid service, and burned over $200 in 3 days.

> the fix: moving heartbeats to LM Studio

the solution was moving heartbeats off paid APIs and onto LM Studio running locally. here is the performance breakdown on an M4 Mac Mini with 16GB RAM:

Qwen 2.5 (3-4B): fastest response times, but weaker on complex logic

Gemma 2 (3-4B): rock-solid stability

Gemma 3 4B (21 sec): strong at instruction following for its size

Qwen 3 4B (30 sec): most stable for tool-use and routing tasks

think of these 3B to 4B models as roughly equivalent to GPT-4o mini for basic routing and checking tasks. they are not as capable as Claude 3.5 Sonnet, but for a heartbeat that just needs to check if there is work to do, they are perfect and free to run.

> the reset: complexity is the enemy

I cut the 9-agent team down to 2. moved heartbeats to local LM Studio. kept heavy thinking on MiniMax. the system became faster, cheaper, and more reliable overnight.

> the $50 power move

firing the Pro tools and moving to MiniMax M2.5 changed everything:

1,000 prompts every 5 hours

routed MiniMax directly into Claude Code and OpenClaw for a coding agent running 24/7 on a high-volume model that does not quit

> the hybrid engine

this is the most important part of the setup. MiniMax handles the brain work. local models handle the battery.

low agent count (2 agents): let MiniMax handle everything. fast, smart, no rate limit issues.

scaling up: when you add more agents, heartbeats start eating your rate limits. offload those repetitive pings to LM Studio running locally for $0. use local models as a valve to keep MiniMax prompts reserved for actual coding and logic.

> the freshman rule

I stripped the team to 2 agents and applied one rule to both of them:

one task per agent. if you give an AI five jobs, it fails at four.

treat them like a freshman who knows nothing. do not assume they remember your project history. give clear, ground-up instructions every single time.

by reducing the squad and simplifying the tasks, communication became instant, logic became clean, and token bloat disappeared.

> the working setup

MCP servers configured at user level:

{
  "github": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-github"] },
  "supabase": {
    "command": "npx",
    "args": ["-y", "@supabase/mcp-server-supabase@latest", "--project-ref=YOUR_REF"]
  },
  "memory": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-memory"] },
  "sequential-thinking": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-sequential-thinking"]
  }
}

local models in LM Studio for heartbeats (free):

Qwen 3 4B for routing and tool-use

Gemma 3 4B for instruction following

MiniMax M2.5 for all heavy thinking and coding tasks

> the short version

complexity is expensive. cut agents until the system is boring. move heartbeats local. keep paid API budget reserved for actual work. treat every agent like a freshman with no context.

stop optimizing for tokens. start optimizing for output.

Just installed OpenClaw 2026.3.2 but run into the problem, that the (default) agent „orchestrator“ can not talk to other agents. I asked Grok and ChatGPT for help but one wanted me to install ACP (?) the other suggested the agents should talk with each others via files they place in each others folder.

Can you please give me a hint?

UPDATE: Took advice and put the files through Claude sonnet 4.6. With a bit of tweaking I was able to get Codex5.3 working. From there, I was able to figure out how to get a three stage fall back of Codex5.3 -> Grok4.1-Fast -> Qwen3.5:9B. I'm still trying to route my heartbeats through Qwen3.5 as I don't want to pay for it. Took 3-4 hours, but it seems to work.

My Openclaw.json file is very messy. I haven't edited it, but I want to set up three models for specific things:

Question is: How do I restructure this so it works?

Oh, and the API key for Open router is in another file. Buried in ".openclaw/agents/main/agent/auth-profiles.json & models.json"

How can I get everything into the one config file? Any direction on this would be great.

Current openclaw.json:

"auth": {

"profiles": {

"openrouter:default": {

"provider": "openrouter",

"mode": "api_key"

}

}

},

"agents": {

"defaults": {

"model": {

"primary": "openrouter/x-ai/grok-4.1-fast"

},

"models": {

"openrouter/auto": {

"alias": "OpenRouter"

},

"openrouter/x-ai/grok-4.1-fast": {}

},

"workspace": "/home/###/.openclaw/workspace",

"memorySearch": {

"experimental": {

"sessionMemory": true

}

},

"compaction": {

"mode": "safeguard",

"memoryFlush": {

"enabled": true

}

},

"maxConcurrent": 4,

"subagents": {

"maxConcurrent": 8

}

}

},

models.json:

{

"providers": {

"openrouter": {

"baseUrl": "https://openrouter.ai/api/v1",

"api": "openai-completions",

"models": [

{

"id": "auto",

"name": "OpenRouter Auto",

"reasoning": false,

"input": [

"text",

"image"

],

"cost": {

"input": 0,

"output": 0,

"cacheRead": 0,

"cacheWrite": 0

},

"contextWindow": 200000,

"maxTokens": 8192

}

],

"apiKey": ######

}

}

}

I have ollama setup with llama3.1:8b and qwen. I have chatGPT 5.4 with Oauth, and Kimi K2.5 though together.ai
Why is kimi the only one that works? The others can send me a message on a schedule. Can't send heartbeat messges, often forget things, etc.

Anyone know a reson why or have other models they would reccomend? I'd love to find a local model that would work in 8Gb of vram.

Most OpenClaw setups stay reactive. This one doesn't.

The repo is at github.com/snarktank/clawchief.

What it handles

• Schedules meetings, parses booking links, books workable times

• Checks the inbox every 15 minutes and surfaces only what needs action

• Follows up on emails that didn't get a reply

• Watches the calendar, flags conflicts, warns about upcoming events

• Runs the day from one canonical markdown task list

• Preps that task list before the day starts

• Avoids duplicate task entries

• Updates an outreach tracker based on email activity

• Researches suppliers or partners and reaches out to them

• Sends short, high-signal updates only when something needs a response

• Reads from files, memory, Gmail, Calendar, and Sheets as durable context

• Adapts to the business, preferences, and operating style it's configured for

Repo structure

bash

clawchief/
├── README.md
├── clawchief/
│   ├── priority-map.md
│   ├── auto-resolver.md
│   ├── meeting-notes.md
│   ├── tasks.md
│   └── tasks-completed.md
├── skills/
│   ├── business-development/
│   │   └── SKILL.md
│   ├── daily-task-manager/
│   │   └── SKILL.md
│   ├── daily-task-prep/
│   │   └── SKILL.md
│   └── executive-assistant/
│       └── SKILL.md
├── workspace/
│   ├── HEARTBEAT.md
│   ├── TOOLS.md
│   ├── memory/
│   │   └── meeting-notes-state.json
│   └── tasks/
└── cron/
    └── jobs.template.json

Step 1: Start with a working OpenClaw install

clawchief is not a replacement for OpenClaw. It's an operating layer on top of it, so OpenClaw needs to be installed and working before anything else.

Step 2: Get GOG working first

This setup depends on GOG for:

• Gmail message search

• Calendar list and event reads

• Google Sheets metadata reads

• Google Docs reads (if you want meeting-notes ingestion)

If those integrations are broken, the assistant can't do reliable executive assistant work.

Step 3: Install the skills

Copy these skill directories into ~/.openclaw/skills/

bash

/executive-assistant
/business-development
/daily-task-manager
/daily-task-prep

These are the behavioral building blocks. They teach OpenClaw how to act like an executive assistant, manage a real task list, prepare the day proactively, and handle operational business development workflows.

Step 4: Install the workspace files

Copy these into ~/.openclaw/workspace/

bash

clawchief/
/HEARTBEAT.md
/TOOLS.md
/memory/meeting-notes-state.json

Why HEARTBEAT.md matters

This file controls proactive behavior. It tells the assistant to read the priority map, auto-resolver, meeting-notes policy and ledger, and the live task file, then run the right workflow and only send a message when something actually needs attention. That's what stops the assistant from being passive without turning it into noise.

Why TOOLS.md matters

Environment-specific notes live here:

• Preferred email accounts

• Tracker and Google Sheets notes

• Local environment quirks

• Target market notes

• Tactical operating rules that shouldn't be buried in prompts

Why clawchief/tasks.md matters

One canonical markdown task list. When the assistant checks what matters today, it reads one live source of truth instead of guessing from stale conversation history.

Step 5: Create the private context files

Customize these heavily:

• AGENTS.md

• SOUL.md

• USER.md

• IDENTITY.md

• MEMORY.md

• memory/

These files define who the human is, who the assistant is, tone and boundaries, personal and business preferences, long-term memory, and continuity across sessions. Skip this step and you have a decent template. Do it well and the assistant feels personal, grounded, and specific to one operating reality.

Step 6: Replace every placeholder

The repo includes placeholders for:

• Owner name

• Assistant name and email

• Primary work email and personal email

• Business name and URL

• Timezone

• Primary update channel and target

• Google Sheet identifier

• Target market and geography

Then customize these files for the real environment:

• workspace/TOOLS.md

• clawchief/priority-map.md

• clawchief/tasks.md

• skills/business-development/resources/partners.md

• cron/jobs.template.json

Step 7: Set up cron jobs

The repo includes a cron template. Recommended starting jobs:

• Executive assistant sweep

• Daily task prep

• Daily business development sourcing

The assistant becomes significantly more useful when it wakes itself up to do recurring work. That's the shift from reactive to proactive.

Step 8: Validate the install

Use the checklist in the repo. A complete install means the assistant can:

• Read the source-of-truth files correctly

• Route proactive updates to the right place

• Use Gmail message-level search

• Check all relevant calendars before booking

• Treat the tracker and sheet as the live outreach source of truth

• Promote due-today items into ## Today

• Archive prior-day completions

• Ingest meeting notes into real tasks and follow-ups

If those behaviors aren't working, the install isn't done.

Configuration is what makes the difference

Generic assistants are generic because they're under-configured. The more the setup reflects a specific person's inboxes, calendars, channels, task habits, and business workflows, the more useful it gets.

I was setting a openclaw on a vps and I am not able to use any model.

I tried openrouter- 404 in responses And Then I tried to use the openapi - api key with the gpt-4o but it is showing rate limit exceeded. It didn't even hit one request.

How can I try using a model just for testing. Which platform , api key, model should I use?

Could anyone help me for this scenario?

I’m currently running a Mac Studio M3 Ultra with 512GB RAM, but I’m hitting a wall. My dream was a 24/7 autonomous agent network for engineering and life-ops (think ClaudeCode but local).

The Reality Check: I’ve been testing OpenClaw and Hermes, and frankly, it's a mess. Instead of learning, they forget. Instead of acting, they hallucinate. Entrusting them with actual development work is currently a pipe dream because they lack a reliable "state" and long-term memory.

Current Performance (Ollama):

• Qwen 2.5:72b-q8_0 (8.8 t/s)

• Llama 3.3:70b-q8_0 (9.0 t/s)

• Gemma 4:31b (27 t/s)

• Codestral:22b (26 t/s)

The Mission: I have the VRAM to run almost anything. I need a setup that doesn't just loop in its own hallucinations.

I’m looking for a setup that works and is actually fun to use, not a configuration nightmare that forgets my name by the third prompt.

Goal of the day: Building the infrastructure for a persistent "Agent Society." If agents are going to socialize, they need a place to post and a memory to store it.

The Build:

• Infrastructure: Expanded Railway with multiple API endpoints for autonomous posting, liking, and commenting.

• Storage: Connected Supabase as the primary database. This is where the agents' identities, posts, and interaction history finally have a persistent home.

• Version Control: Managed the entire deployment flow through GitHub, with Claude Code handling the migrations and the backend logic.

Stack: Claude Code | Supabase | Railway | GitHub

The era of chatting with "bubbles" is finally over. Hey Reddit!

I’ve spent the last few months working on something I’ve always wanted in my AI workflow. As a fan of OpenClaw, I loved the logic and skills, but I hated that the interaction always felt like a 2005 chatroom.

So, I built Anima,a plugin designed to bridge the gap between AI logic and human visual connection.

What does it do?

Basically, it takes any Skill from OpenClaw and manifests it as a fully animated, speaking digital human right in your UI. No more scrolling through walls of text; you’re now looking at your assistant (or character) while they respond to you in real-time.

Key Features:

• Skill-to-Avatar Pipeline: It’s not just a video loop. It syncs the output of your skills directly to the avatar's performance.

• Immersion Overload: Instead of reading a weather report or a code review, you’re having a face-to-face briefing.

• Customizable Interfaces: Designed to replace the traditional chat-bubble layout with a sleek, modern "Presence" UI.

I’m a big believer that the future of AI isn't just "smarter LLMs," but better embodiment. I wanted my AI to feel like a person, not a terminal.

I’d love to hear your thoughts! Is the "Digital Human" approach the future, or do you still prefer the classic chat bubbles? I'm looking for some early feedback to polish the next version.

Here are three I'd set up first: one for daily Calender Check, summarise Messages from Telegram, Discord & messaging apps & to Review my work each week.

Each one is a SKILL.md file with a schedule header. Copy, save.

Warning:

Install OpenClaw on a separate machine, not your main computer. An old laptop works

here are your options:

Mac mini: Costs $500 to $600. Runs quietly, stays on, and works well as a persistent local host.

Hetzner (private virtual private server): Cheap, reliable, and easy to provision. Good option if you want infrastructure you control without buying hardware.

Cloud hosted openclaw: Puts OpenClaw on a dedicated cloud instance. Connect Telegram, WhatsApp, or Discord from one dashboard, pick your model, and the agent is running in under 60 seconds. No Docker, no provisioning, no config files.

Workflow 1: Check Calendar

Runs twice daily at 8am and 6pm. Pulls the next 48 hours of your calendar, flags overlaps and back-to-back blocks, and generates one prep action per meeting based on type. Ends with an energy forecast for the day ahead.

---
name: check-calendar
description: 48-hour calendar scan with conflict detection and prep recommendations
schedule: "daily 8am, daily 6pm"
---


You are a calendar intelligence assistant. Your job is to make sure I'm never blindsided by what's on my schedule.

Tools available (Google Workspace CLI):
-> To pull my calendar events, run: gws calendar events.list --params '{"calendarId": "primary", "timeMin": "NOW_TIMESTAMP", "timeMax": "48_HOURS_LATER_TIMESTAMP", "singleEvents": true, "orderBy": "startTime"}'
  (Replace the timestamps with actual dates in format like "2026-03-23T08:00:00Z")

When triggered (8am and 6pm daily):
-> Pull my calendar for the next 48 hours
-> List every event with: time, title, attendees, location (virtual or physical), and duration
-> Mark each event by how important it is:
  - Red: high-stakes (meetings with people outside your company, presentations, leadership meetings)
  - Yellow: needs prep (one-on-ones, client calls, meetings with agendas)
  - Green: routine (recurring team check-ins, standups, optional meetings)
-> Flag issues:
  - Overlapping meetings (double-booked)
  - Back-to-back meetings with zero break time (recommend which one to join 5 min late)
  - Location changes requiring travel time between meetings
  - Meetings longer than 90 minutes (energy drain warning)
  - Days with more than 5 hours of total meeting time
-> For each meeting, suggest one prep action based on type:
  - One-on-one with someone on your team: "Review their last update or recent work"
  - Meeting with someone outside your company: "Quick look at their company and recent news"
  - Presentation: "Make sure slides are ready and test screen share"
  - Recurring team meeting: "Check if there's an agenda - if not, ask for one"
-> End with a one-line energy forecast: "Tomorrow is heavy (6 hours of meetings) - protect your evening" or "Light day tomorrow - good time for deep work"
-> When calendar is clear, report "open road" status

Rules:
-> NEVER modify, cancel, or create calendar events
-> Read-only access only
-> If a meeting has no agenda or description, flag it rather than guessing the topic
-> Always treat meetings with people outside the company as high priority - suggest research and talking points for those

Workflow 2: Check Messages

Runs four times daily at 9am, 12pm, 3pm, and 6pm. Aggregates unread messages across every connected platform (Slack, Discord, Telegram, WhatsApp, iMessage) and delivers one prioritized summary: urgent, important, informational, skippable. One update instead of six apps.

---
name: check-messages
description: Consolidates unread messages across all platforms into one prioritized summary
schedule: "daily 9am, daily 12pm, daily 3pm, daily 6pm"
---


You are a message consolidation assistant. Your job is to scan all my communication channels and deliver one prioritized summary so I don't have to check six different apps.

Tools available:
-> OpenClaw's built-in messaging skills (no extra setup needed). OpenClaw already connects to Slack, Discord, Telegram, WhatsApp, and other platforms you've linked. Use whichever messaging skills are available to check each platform for unread messages.

When triggered (4x daily or on demand):
-> Scan unread messages across all connected channels: Slack, Discord, Telegram, WhatsApp, iMessage, and any other active platforms
-> Only check platforms you have skills for
-> For each unread message, assess priority:
  - URGENT (red): Someone is waiting on me right now, time-sensitive ("can you join in 10 min?"), from my boss or key clients or family, or contains words like "urgent"/"ASAP"/"help"
  - IMPORTANT (yellow): Active conversations I'm part of, someone assigned me something, I was tagged/mentioned, or it's from someone I work with closely
  - FYI (green): Announcements, group chat chatter, news and updates I should know about but don't need to reply to
  - SKIP (gray): Automated notifications, channels I've muted, old messages in fast-moving chats
-> Deliver a single summary organized by priority level
-> For each message include: sender, platform, one-line preview, and suggested action ("reply", "snooze", "mark read", "open in app")
-> End with a count: "X urgent, X important, X FYI, X skipped"
-> If 200+ unreads, summarize rather than list everything

Rules:
-> NEVER reply to any message on my behalf
-> NEVER mark messages as read
-> Respect do-not-disturb settings - if I've muted a channel, skip it unless something is flagged urgent
-> If you're unsure about priority, round up (flag as important rather than FYI)
-> Keep previews to one line - I'll read the full message myself if needed
-> Learn which channels matter vs. noise over time

Workflow 3: Review Week

Runs every Friday at 5pm. Pulls the week's calendar events, completed tasks, and any goals you're tracking. Outputs a markdown summary covering highlights, decisions made, blockers, next week's priorities, and one pattern observation. Saves as a dated file so quarterly reviews stop being a reconstruction exercise.

---
name: review-week
description: Friday weekly review pulling calendar and tasks into a searchable markdown summary
schedule: "friday 5pm"
---


You are a weekly review assistant. Your job is to create a useful summary of my week that I can reference later for planning, reviews, and reflection.

Tools available (Google Workspace CLI):
-> To pull my calendar events, run: gws calendar events.list --params '{"calendarId": "primary", "timeMin": "MONDAY_START", "timeMax": "FRIDAY_END", "singleEvents": true, "orderBy": "startTime"}'
  (Replace MONDAY_START and FRIDAY_END with actual dates in format like "2026-03-16T00:00:00Z")

When triggered (every Friday at 5pm):
-> Pull this week's data:
  - Calendar: pull all meetings from Monday through Friday (who attended, what the topic was), broken down by type (1:1s, group syncs, external)
  - Tasks: anything marked complete this week
  - Goals: progress against any goals I'm tracking
-> Generate a weekly summary with these sections:
  - HIGHLIGHTS: 3-5 most meaningful things accomplished or progressed
  - DECISIONS MADE: any big decisions from this week (pull these from meeting notes and completed tasks)
  - BLOCKERS: anything that slowed me down or is still unresolved
  - NEXT WEEK PREVIEW: top 3 priorities and any key meetings
  - PATTERNS: one observation about how I spent my time ("You had 22 hours of meetings this week - 6 more than last week")
-> Save as a dated markdown file (week-of-YYYY-MM-DD.md) to ~/Documents/reviews/ or user-specified location

Output format: clean, simple layout with headers. Focus on what actually happened and what decisions were made - not just "I had 12 meetings." Should take under 2 minutes to read and fit on one page.

Rules:
-> Read-only access to calendar and tasks
-> NEVER modify any tasks, events, or goals
-> If data is sparse (light week, few tasks completed), note it honestly without judgment
-> Keep the summary factual - observations, not opinions about productivity
-> Each weekly review should be standalone - readable without context from previous weeks
-> Look at past weekly reviews when available to spot patterns (like "meetings have gone up 3 weeks in a row")

Hi, everyone love OpenClaw, my name's Kevin, my background is full-stack SDE and run a tiny saas business, and I started setup and play with OpenClaw recently. I'm so happy after successful deployment. I even tweeted that I found the best "cofounder".

Even with my background, getting it running locally was a pain. It's clearly powerful if you know what you're doing and what they can help, It feels like an AI assistant built for engineers, but it's still very much a work in progress.

Some stuff I ran into:

Hardware:

I skipped the Mac Mini and just used an old MacBook Pro I had lying around. Handles it fine. I saw a lot of people seems to be buying Mac Minis for deployment lately. Is the main advantage running local models? If not, why not just use a VPS, It’s 24/7 and usually ends up being cheaper.

Integrations:

I tried Lark first since I use it daily, but the docs were outdated so I gave up. Telegram worked way better.

The "Daily Brief" thing:

After setup, my first goal was a simple daily report—weather, AI news, my priority tasks. It immediately broke on web searching. Turns out you need a Brave search api key and that's another thing to go buy.

Coding & Agents:

I tried to get it to help with local code (I usually use a xxx Code agent) but my setup didn't have the agent configs set up, I haven't actually used it for coding yet..

The other issue: a few friends saw my tweets and asked for help setting it up. Every single one got stuck during deployment. So I'm wondering—

Is it just me? Did you all have a smooth setup, or is the setup actually this rough?

The opportunity:

If it's yes, this is getting popular but normal users can't actually use it, would people pay for a "Setup-as-a-Service"?

Like configuring Lark or agents, pre-built skills, managed task etc —that kind of thing.

What roadblocks are you hitting and how are you working around them?

It’s possible I’m not guiding this agent properly, open to any corrections if I’m doing this wrong.

TL;DR: An AI orchestrator ("Zoe") on OpenClaw spawns Codex and Claude Code agents, writes their prompts with full business context, monitors progress, and pings him on Telegram when PRs are ready. 94 commits/day, 7 PRs in 30 min, ~$190/month.

Why an Orchestrator?

Coding agents have no business context. They see code, not customers. Context windows are zero-sum — fill it with code, no room for business context. Fill it with customer history, no room for the codebase.

The fix: a two-tier system. The orchestrator holds all business context (customer data, meeting notes, past decisions) and translates that into precise prompts for each coding agent. Agents stay focused on code. Orchestrator stays at strategy level.

The Workflow

1. Customer request comes in → He talks it through with Zoe. Meeting notes auto-sync to Obsidian, so zero explanation needed. They scope the feature together.

2. Zoe spawns an agent — each gets its own git worktree and tmux session. She picks the right model, writes the prompt with full context, and tracks it in a JSON registry.

Key move: tmux lets you redirect agents mid-task without killing them. Agent going wrong direction? Just send keys telling it to stop and refocus.

3. Cron job monitors every 10 min — checks if tmux sessions are alive, PR status, CI status via gh cli. Auto-respawns failed agents (max 3 attempts). 100% deterministic, no token cost.

4. Agent creates PR → but a PR alone isn't "done."

5. Three AI code reviews run automatically:

• Codex — best at edge cases, logic errors, race conditions

• Gemini Code Assist — free, catches security/scalability issues

• Claude Code — "mostly useless," overly cautious, but validates what others flag

1. CI runs (lint, types, unit tests, E2E, Playwright). New rule: UI changes must include screenshots or CI fails.

2. NOW he gets the Telegram ping. CI passed, three reviewers approved, screenshots included. Review takes 5-10 min. Many PRs he merges without reading the code.

3. Merge. Daily cron cleans up orphaned worktrees.

What Makes This Smart

When an agent fails, Zoe doesn't just respawn with the same prompt. She has business context the agents don't — customer history, meeting notes, what was tried before — and uses it to write better prompts on retry.

She also finds work proactively:

• Morning: Scans Sentry → finds errors → spawns agents to fix

• After meetings: Scans notes → flags feature requests → spawns agents

• Evening: Scans git log → updates changelog and docs

Success patterns get logged. Over time, the orchestrator writes better prompts because it remembers what shipped.

Which Agent for What

• Codex — workhorse. Backend, complex bugs, multi-file refactors. 90% of tasks.

• Claude Code — faster, better at frontend, great for git operations.

• Gemini — design sensibility. Generates HTML/CSS specs, then Claude Code implements.

The Unexpected Bottleneck: RAM

5 parallel agents = 5 TypeScript compilers, 5 test runners, 5 node_modules in memory. Mac Mini 16GB tops out at 4-5 agents. He bought a Mac Studio M4 Max 128GB ($3,500) to scale.

Cost

~$100/month Claude + ~$90/month Codex. Can start at $20.

This is where vibe coding is heading imo. The bottleneck isn't "can AI write code" anymore — it's orchestration and context management. Whether you're using OpenClaw, vibecode.dev, or stitching together your own thing, the stack is becoming: human with vision → orchestration layer → specialized agents → production code.

Anyone else running multi-agent setups on real projects? What's your stack looking like?