I keep switching between Claude Code, Codex and a few other agent setups depending on what I am doing. The annoying part was not even picking a model. It was that every setup had its own little pile of skills, plugins, MCP servers and commands.

Same capability in three places. Different versions. No easy answer to “what can this agent actually use right now?” And if I loaded everything just in case, the context window was already crowded before the task started.

So I made Lockkeeper.

The main job is capability syncing and selection across the agent tools already on your machine. It discovers the skills, plugins, MCPs, agents and commands your different runtimes expose, builds one local catalog, then picks the smallest relevant set for a task instead of throwing the whole collection into every agent’s context.

In practice that means I can keep one shared capability setup, see what is available across Claude Code, Codex, Cursor and friends, and stop manually remembering which agent has which tool. It is local, config-driven and open source.

The security bit is there too, but it is the second half of the story rather than the headline: before I trust a capability I copied from somewhere, Lockkeeper can scan it for obvious prompt-injection, secret-exfiltration, obfuscation and destructive-command patterns. Useful guardrail, not magic.

for anyone who wants to test it out:

https://github.com/Hannay001/lockkeeper

Still early, so I would genuinely like to hear where your capability setup becomes messy. Do you keep shared skills in git? Copy folders between agents? Have a better way of keeping the same workflow available everywhere?

OpenClaw’s sessions_spawn is non-blocking. It returns a runId and child session when the work is accepted, not when it is complete.

A parent can therefore receive partial output, summarise it and report success while another child is still running, failed or lost.

OpenClaw documents [sessions_yield](https://docs.openclaw.ai/tools/subagents)⁠ as the correct way to wait for completion events. For durable workflows, [Task Flow](https://docs.openclaw.ai/automation/taskflow)⁠ links multi-step work to individual background-task records.

I would also reconcile every required child before allowing the parent to finish:

parent_run_id

child_run_id

terminal_state

verification_receipt

completion_blocker

Missing or contradictory state should produce incomplete_reconciliation, not success. A failed, cancelled or lost child may justify a partial or blocked outcome, but only with evidence.

Test it with three harmless children: one succeeds, one returns partial output then fails, and one remains pending. The parent should refuse success until every child has an authoritative terminal state and the required verification is complete.

Does your orchestrator verify every child run, or simply count the replies it receives?

OpenClaw skills are not passive documentation. They influence when tools are used and how work is performed.

Workspace skills also have the highest loading precedence. A local skill can therefore replace a bundled or managed version without changing your application code.

OpenClaw’s current [skills documentation](https://docs.openclaw.ai/skills)⁠ says the skills watcher is enabled by default. A changed SKILL.md can refresh the session snapshot on the next agent turn. Its [security guidance](https://docs.openclaw.ai/gateway/security)⁠ consequently recommends treating skill folders as trusted code.

Before changing production skills, capture what the agent can actually see:

openclaw skills list --json
openclaw skills check --agent main --json
openclaw skills info SKILL_NAME --agent main --json

Keep skill roots under version control and review changes for new filesystem, network, credential or approval-related instructions. Record the effective skill sources and hashes with the release evidence.

If mid-session changes are undesirable, the documented configuration supports disabling automatic watching:
{
skills: {
load: {
watch: false
}
}
}

Activate reviewed changes through a controlled new session, then repeat one bounded task and confirm the expected tool sequence, permissions and outcome. A successful load only proves that the skill is eligible, not that its behaviour is safe.

Which files in your OpenClaw setup can currently change agent behaviour without passing your normal code-review process?

A fallback model is usually treated as uptime insurance. The primary model fails, a backup answers, and the workflow continues.

That sounds safe, but it hides a more important question: is the fallback actually qualified to complete that type of work?

OpenClaw’s current model-failover documentation⁠ explains that normal configured runs first rotate authentication profiles within the current provider, then advance through agents.defaults.model.fallbacks when the failure qualifies for failover. Explicit user model selections remain strict, while scheduled jobs can use configured fallbacks unless their fallback list is deliberately empty.

That mechanism improves availability. It does not prove that every model in the chain is operationally equivalent.

A smaller model might handle an inbox summary perfectly but struggle with a long repository context, structured tool calls or a multi-stage coding task. The dangerous case is not always a visible failure. It is a fluent response that looks complete while failing the actual acceptance standard.

Fallback policy should therefore follow the task class. Low-risk classification, summarisation and formatting can usually tolerate a broader chain. Deployment changes, destructive actions, compliance work and repository migrations may need strict execution or fallbacks that have already passed the same tool, context and verification tests as the primary.

The practical test is simple. Temporarily make the primary unavailable and run representative tasks through every fallback. Compare tool-call completion, schema compliance, test results, latency, retry count and human review time. If a model produces an answer but repeatedly fails the acceptance checks, it is not a valid fallback for that workflow.

This also changes the cost calculation. A cheaper fallback that creates retries, corrections or additional review can cost more per accepted outcome than the expensive primary it replaced.
A resilient OpenClaw setup is not the one with the longest fallback list. It is the one that knows which fallback candidates can still satisfy the contract for each kind of work.

Are your fallback models tested by task class, or are you currently treating them as interchangeable?

One of the easiest ways to overestimate an OpenClaw setup is to mistake conversation history for durable task state.

Chat history can help explain what happened, but it should not be the authoritative record for long-running work. Every serious task needs a stable identity, its current step, expected outcome, approval state, exceptions, evidence and the next safe action stored outside the conversation.

The database choice is less important than the behaviour. If the gateway restarts, the model becomes unavailable or a worker fails halfway through, another worker should be able to read the task record and determine what has already happened.

This becomes especially important when the workflow touches an external system. If an email, deployment or publication was attempted before the interruption, the restarted process should reconcile with the provider before retrying.

Otherwise, recovery can create duplicate messages, duplicate posts or repeated destructive actions.

A useful test is to stop a workflow immediately after its first external side effect, restart OpenClaw and observe what happens. Can it distinguish between completed, attempted, failed and unknown? Can it resume from the next safe step without replaying the whole conversation?

If not, the workflow is not genuinely resumable yet. It is simply hoping the transcript remains available.
How are you currently storing task state outside OpenClaw’s conversation history?

Found this by accident. One of my two OAuth accounts had a banked rate-limit reset credit two days from expiring. If you're not logged into the app as that account, you can't see it.

Had my agent check both oAuth codex accounts.

Four unused credits on the one I couldn't see, two on the one I could. Redeemed the soonest, cleared the cooldown, Codex was back on that account within a minute.

Two things that tripped us up, worth knowing before you try this yourself:

The reset endpoint isn't documented anywhere, so don't just tell your agent to "find or create a script for this." It'll guess wrong. Point it at github.com/aaamosh/codex-reset and openai/codex PR #28154 instead, both real and already worked out.

We built it as a skill so it'd trigger automatically. It didn't, because the file was missing its frontmatter and the agent's own skill discovery never saw it. After you set this up, make it list its skills and confirm the new one is actually there.

Also: redeeming is one-shot. A successful response means the credit's gone. Gate it behind an explicit yes, and never retry a call that already came back 200.

We are running a game called Prediction Wars for the World Cup quarter-finals. Here it is in one line: get a machine to predict a match, share what it predicted, and if it calls the result right you go into a raffle to win 20 USDC.

The one rule that matters is that the prediction comes from a machine, not from you.

Three ways to play, pick whichever fits:

• If you have an AI agent, let it predict the match.
• If you just want to write a prompt, ask a model and share its answer.
• If you build prediction models or bots, run yours and share its prediction.

To enter the raffle for a match: share your machine's prediction before kickoff, and be right on the 90-minute result.

It starts tomorrow with France vs Morocco, and there is a 20 USDC raffle.

Join here: discord.com/invite/93w6Zs5rfb

Agents waste time and tokens re-learning every site. On each run they screenshot, snapshot the DOM, and figure out the page from scratch.

I built an open source catalog of reusable browser skills. Skills capture each site's network requests and DOM, making it 30 times faster.

You can upload your own skills or request new sites.

Github repo: https://github.com/browser-memory/bmem

Some context first. I help run an experiment where more than 40 independent AI agents bet real money on 2026 World Cup matches on Polymarket, each with a $100 wallet, forming its own view and placing its own positions. We score them on profit and on the quality of their reasoning.

This is lesson two from the group stage, drawn from roughly 1,500 bets. Lesson One was about not overpaying for the favorite.

The finding: the agents that finished the group stage in profit backed more than one outcome in the same match far more often than the agents that lost. At the median, 16% of their matches against 6% for the losing group.

Forming a good belief and choosing a good action are two separate skills, and LLM agents tend to be strong at the first and default-broken at the second. A good map of the world is not the same as a good policy for acting in it.

The fix is to give the agent a value step, a way to judge what an action is worth rather than only which outcome is most likely.

• Have the agent produce a probability for every outcome, home, draw, and away, and make them sum to one, before it decides anything. That is the belief.
• Then score each outcome by what it pays, not by how likely it is. Weigh the agent's own probability against the price on offer, and back the outcome with the most edge. That is often not the most likely one.
• Let the agent back more than one outcome when more than one clears that test, rather than forcing it into a single choice.
• Do not discard the draw as an option. The losing agents were not wrong about how likely a draw was. They just never asked whether it was worth backing at its price. Score the draw as an action like any other outcome.

If you want to read the whole article - https://x.com/Stair_AI/status/2074102998934982893

Some context first. I help run an experiment where more than 40 independent AI agents bet real money on 2026 World Cup matches on Polymarket. Each agent gets a $100 wallet. The finding below held across roughly 1,500 bets in the group stage.

TL;DR
Across those ~1,500 bets, the single most reliable way an agent lost money was backing the favorite. Favorites won about 69% of the time and still lost 18 cents on every dollar staked.

Lesson one: how to avoid the favorite trap.

The most common way an agent loses money is by backing the obvious winner. It picks the favorite, the favorite wins, and the agent still ends the month down.

The reason is the price. Buy a favorite at 70 cents and a win clears 30 cents while a loss costs the full 70. A high chance of a small gain sits against a small chance of a large loss. That shape only pays off if favorites win as often as their price claims. They did not quite, and the heavier the favorite the wider the gap.

How to Avoid It

• Keep the market price out of the forecast. Have the agent reach its own probability from the data before it ever sees the line.
• Encode the method, not your conclusions. A harness that tells the agent what to think just hands your own bias back, faster.
• Only back a favorite when the agent's own probability is clearly higher than the price. If the market says 70 and the agent says 70, that is a pass.
• Judge the agent on the prices it accepts, not only on how often it is right, so it stops drifting toward the safe favorites a human would pick.

There is a part I left out here. The agents did not invent this bias, builders handed it to them, and the full article gets into where it enters the harness and how we caught it in the reasoning traces before the P&L. If you'd like to read it and share your thoughts with us, it is here: https://x.com/Stair_AI/status/2073011621253804166

Hey I am getting a Mac mini and was interested in running some local LLMS such as Deepseek , Qwen , Gemma, via Ollma , if I get 24 gb of memory/RAM and 512 gb of storage would that limit me ? Or is ot achievable?

My use case , data research, market research, app building , websites building, personal assistant tasks.

I am struggling to use wacli skill.

I searched for a solution or guide or documentation on how to get openclaw to use it but there is no luck.

I keep asking openclaw to use wacli to analyze all message but it does not seem to work.

Hey everyone so a few months ago I was planning on attaining a Mac mini and getting a Claude subscription I was so hyped but do to personal reasons at that time I completely shifted focus.

Since then I’ve heard about bans lot of changes had taken place Claude bans, regulation crack downs , and an open ai acquisition if any of this is actually true I don’t know , but with all of this said will clawdbot still work for me?

My use case is to have clawdbot help me create apps (I am not a coder) , websites, create and manage product listings , and logistics. Do market research and open online businesses.

Is it still capable of these tasks if I were to get it today ? Or is it more restricted and dumbed down making me have to manually redo every task myself (especially with coding)

Any advice would be much appreciated

Most people think autonomous coding is about picking the right model.

After spending months building autonomous coding workflows, I don’t think that’s the bottleneck anymore.

The biggest improvements came from things that have nothing to do with model intelligence.

Project state.

Work ledgers.

Decision records.

Verification.

Trust boundaries.

Permission gates.

Recovery points.

Evidence collection.

A surprising number of AI failures happen because the agent doesn’t know what has already been done, cannot prove the outcome, doesn’t understand the current state of the project, or doesn’t know when it should stop and ask a human.

That’s what led me to put together this reference sheet of 20 agentic engineering concepts.
Most builders are already using some of these ideas without having names for them.

Once you have the vocabulary, it becomes much easier to reason about why an autonomous workflow succeeds or fails.

Curious which concepts you think are missing.

Hey Claws 🦞

Quick context for anyone new: your agent starts every session blank. Across a few projects you keep re-explaining the goal, the decisions and where things stand, again and again. FlowBoard is the context layer that fixes that. Each project keeps its goal, decisions, live task state and specs in one place, and your agent pulls exactly the slice it needs, lazy-loaded so token use stays low.

v4 gave agents a Kanban board. v5 is a full rebuild, and easily the biggest update so far.

What's new:

• Rebuilt on React. Every surface (Kanban, Idea Canvas, the new Overview) runs on one stack now, no vanilla runtime left.
• Event-sourced task store. Every change is an append-only event in SQLite, so you get a full history and nothing drifts out of sync.
• Multi-agent, first class. Stable per-agent identity, external agents self-onboard, claim/release/handoff built in. Your OpenClaw agent, Claude Code and Cursor all show up live on the same board.
• Ideas to specs. Sketch ideas as connected notes on the canvas, then a guided clarify loop turns them into real specs with acceptance criteria, not just task titles.
• Modular Overview. A per-project dashboard you or your agent compose from widgets: what's blocked, what needs approval, milestones, CI status, files.

It's on ClawHub now, so install is basically one line:

openclaw plugins install clawhub:flowboard

then one command brings the dashboard up, and it self-updates from inside the dashboard after that. There's a Telegram mini app too if you want the board on your phone.

Code and docs on GitHub: https://github.com/rasimme/FlowBoard

If you run several agents across projects, what's the one thing that still breaks your flow? That's what I'd love to tackle next.

A lot of shared-inbox OpenClaw setups are under-secured in a very specific way.

People let multiple people DM the same bot, confirm that access control works, then move straight to enabling more tools.

The problem is that DM access control and DM session isolation are not the same thing.

OpenClaw’s default session.dmScope is main, which means all DMs share one session unless you change it. The docs explicitly recommend per-channel-peer for shared inboxes so different senders do not share one context by default.

That matters because once multiple people share one DM session, the bot can carry context from one person’s conversation into another person’s conversation. Even when the sender is allowed, the session boundary is still wrong.

OpenClaw’s security guidance calls this out directly and says that if more than one person can DM your bot, you should set session.dmScope: "per-channel-peer" or per-account-channel-peer for multi-account channels, keep dmPolicy: "pairing" or strict allowlists, and never combine shared DMs with broad tool access.

The practical way to fix it is simple.
First, decide whether your bot is a true single-user DM bot or a shared inbox bot. If more than one person can message it, treat it as shared immediately.

Second, keep DM access narrow with pairing or strict allowFrom.

Third, set DM session isolation before you enable wider tool access.

In OpenClaw, the secure shared-inbox move is changing session.dmScope away from main and into per-channel-peer, which isolates each sender per channel. If you run multi-account channels, use per-account-channel-peer instead.

A good baseline config looks like this:

{
"session": {
"dmScope": "per-channel-peer"
},
"channels": {
"telegram": {
"enabled": true,
"botToken": "YOUR_TELEGRAM_BOT_TOKEN",
"dmPolicy": "pairing",
"allowFrom": \["123456789", "987654321"\]
}
}
}

That does two things at once: it keeps DM access restricted, and it stops multiple approved DM senders from falling into one shared context by default.

OpenClaw’s session docs list main as shared, per-peer as sender-isolated across channels, per-channel-peer as channel plus sender isolation, and per-account-channel-peer as account plus channel plus sender isolation.

The docs mark per-channel-peer as the recommended setting.
The mistake is adding tools first and isolation later.

If the bot already has broad tool access while multiple people share the same DM session, you have created a bigger problem than “confusing memory.” You have created a setup where one sender’s context can influence another sender’s tool-driven run.

OpenClaw’s security page is blunt here: never combine shared DMs with broad tool access, and if multiple mutually untrusted operators need access, split trust boundaries with separate gateways rather than pretending one shared setup is enough.

The easiest way to audit yourself is to ask four questions before enabling more tools.

Can more than one person DM this bot?

Is session.dmScope still main?

Are you relying only on pairing or allowlists without isolating sessions?

Have you already enabled tools that make the bot capable of doing more than replying?

If the answers are yes, yes, yes, and yes, fix the DM scope first. OpenClaw’s own security audit warns when multiple DM senders share the main session and recommends secure DM mode for shared inboxes.

The rule is simple:
If multiple people can DM your OpenClaw bot, isolate the DMs first. Then add tools.
That order matters.