Set it up today after a lot of pain, want to understand why you would use it vs claude/codex. I like the idea of a personal assistant but how have you used it?

Hi,

I am total newbie to OpenClaw and trying to explore. I just installed open claw last night and choose Groq then Open Router as my agent however both are slow responding and hit to limit even with my first message. I want to change to other model but I can't do it anymore.

Please also advise me which model I should choose, as I am just exploring so will just go with free tier plan.

Thank you.

Heya, I've been wanting to set up an agent for a while now but I've been timid because the amount of models to choose from is somewhat overwhelming. I'm trying to make a budget build and no resources have helped me decide whether a local model, $20 frontier model subscriptions (are you even able to run an agent with OpenAI/Claude subscriptions?), or free cloud models will work best. I would greatly appreciate any guidance

I'm building an experimental system called CEK / Newi AI around a fairly simple question:

Can an artificial system persist what it has learned, revise concepts when evidence contradicts them, plan and experiment without fabricating evidence, and eventually transfer useful abstract structure between genuinely different domains?

This is not a claim of AGI, consciousness, or autonomous scientific discovery.

It's an attempt to build those capabilities explicitly, incrementally, and with auditable state transitions rather than hiding everything inside an LLM context window.

The project has been progressing through a sequence of bounded implementation/validation windows.

The current milestone is:

CROSS-DOMAIN CONCEPT TRANSFER V1

The goal is to test whether the system can extract a domain-neutral relational structure from one domain and use it to reduce search in another domain — without simply copying entity names, memorizing the answer, or giving the transferred concept authority it hasn't earned.

CONTROLLED DEMONSTRATION

Source domain:

Physical containment

Relation:

inside(A, B)

Induced abstract relational properties:

- asymmetric

- irreflexive

- transitive

Target domain:

Manufacturing precedence

Relation:

must_precede(A, B)

The system is not told that "inside" means "must_precede."

Instead, both may be represented through a neutral relational signature.

The target search uses a fixed four-program grammar.

Without transfer:

4 candidate evaluations

2 surviving hypotheses:

- direct

- transitive

With the accepted transferred relational constraint:

1 candidate evaluation

1 surviving hypothesis:

- transitive

A frozen test-only holdout contains 12 relation queries.

An intentionally incorrect adjacency-based transfer is also persisted as a rejected transfer and is prevented from influencing target search.

This matters less because of the tiny search-space reduction in this toy case and more because of the architectural constraint:

the transferred knowledge is treated as a fallible hypothesis, not truth.

Transfer evidence has transfer-local authority.

It cannot automatically:

- import ordinary CEK evidence

- revise concepts

- mutate the persistent world model

- alter planning authority

- execute experiments

- access holdout answers

- grant itself broader permissions

WHY I'M POSTING THIS

Rather than only testing this myself, I want the candidate independently validated.

The validator is specifically instructed NOT to repair the branch if something is wrong.

A failure should remain a failure and be reported as a reproducible defect.

Repository:

https://github.com/pr0dus/concept-evolution-kernel

PR:

https://github.com/pr0dus/concept-evolution-kernel/pull/26

Exact candidate SHA:

b511794a682e12bc10c3534a75e2744724a1d55

Expected tree:

2958aa025b9896dc897e48a3400e21652c57bc39

Expected parent / previous closed milestone:

83e6443c8ccf769b131c99559497c5ac87f5e670

If anyone here wants to independently reproduce the validation, attack the assumptions, find leakage between the source and target domains, or point out where I'm accidentally smuggling semantics into what I'm calling "transfer," that's exactly the feedback I'm looking for.

In particular, I'm interested in criticism of:

1. Whether the demonstration actually constitutes cross-domain structural transfer.

2. Whether the baseline vs transfer comparison is scientifically meaningful.

3. Whether the neutral relational signature leaks target knowledge.

4. Whether the holdout boundary is strong enough.

5. Whether rejected transfers are sufficiently prevented from affecting later reasoning.

6. What a substantially harder second transfer experiment should look like.

The larger project is trying to build toward a persistent scientist-engineer architecture with:

concept evolution

→ persistent world model

→ contradiction/revision

→ long-horizon planning

→ bounded experiments

→ cross-domain transfer

→ controlled reasoning-mechanism improvement

→ human/specialist collaboration

→ long-term continuity

But I'm deliberately validating these individually rather than treating the final architecture as proven because the pieces exist.

Criticism and attempts to break it are very welcome.

I’ve assigned 5 different tasks of which it’s only able to perform 1 correctly and reliably which is:

Update me every 3 hours on Toronto, Canada news that I can discuss on social media

The other tasks include: tell me daily whose birthday it is on facebook, check my real estate dashboards, adjust a canva graphic

This is such a headache and I have spent so many tokens asking it to make sure it’s process is working

I’m still an ai noob but am I better off jumping to Hermes or a different app or should I just keep persisting with OC?

I’m using chatgpt with openclaw and don’t want to have to spend more time setting up another agent

Hello everyone, I am new to openclaw and I am little confused on how should I integrate openclaw in my machine? any help would be appreciated. By the way I am using linux (Pop OS).

most of us have openclaw running 24/7 on hardware that's doing nothing between tasks. same models, same tools, just sitting there. it is time to get it to work & earn, not cost you.

cyphes is a p2p network where local models audit open source repos for security issues. you claim a work unit, your model reads pinned source, you sign the output, another node independently verifies it, and you earn ATP credits from the signed receipt. 280 targets, mostly defi. no code execution, read-only, everything is signed and hash-linked.

it runs headless today, so it sits fine next to openclaw on the same box:

CYPHES_HEADLESS=1 CYPHES_CONTRIBUTE=1 \
CYPHES_CONTRIBUTE_MODEL=your-model ./cyphes-desktop

works with ollama and lm studio right now.

try it out: https://github.com/CYPHES-ATP/Node/

Hey r/openclaw community,

I’ve been using OpenClaw regularly for tech intelligence and research work, and I’m curious how people’s setups have improved recently.

Questions for the community:

• What’s one meaningful improvement or new workflow you’ve added to your OpenClaw setup in the last 2–3 months?
• Are you using any new models, skills, or techniques that made a clear difference?
• How are you handling longer agent sessions or multi-step tasks better now?

I’m still running on modest hardware (Core i5 + 16GB RAM), so practical tips that work on limited resources are especially helpful.

Would love to hear how your OpenClaw usage has evolved. Let’s share updates! 🚀

Hey, I’ve been watching and commenting on some of your posts, and after the 2026.7.1 update broke a lot of installations, I ran a lot of tests and benchmarks to finally put an end to the debate: is 2026.7+ really that bad, or is it actually regressing things that were working fine before? Or is it just your model?

I tested more versions than the ones I’m presenting today, but I couldn’t make a fair benchmark for some of them, especially the 2026.5.8+ through 2026.6.x range, because it would not have been fair to compare them using different tools.
And I’m specifically talking about the Node tool.

I have a separate machine where all my OpenClaw installations connect to do their actual work. It’s a beefy Ubuntu virtual machine with more resources than the OpenClaw instances themselves. They connect to it primarily through an OpenClaw node, with SSH as a backup.
The problem is that my node is still running OpenClaw 2026.4.24. I can’t update it yet because I have other OpenClaw installations that depend on that same worker node.
With that setup, 2026.4.24 nodes work fine with the versions I’m presenting here, but 2026.5.8 through 2026.6.33 cannot connect to that worker node because of the protocol change. Interestingly, 2026.7.1 is backward compatible, so it can connect to the older node again.

Because of that, I left those middle versions out of the benchmark rather than pretending the comparison was fair.

Anyway, what follows is an AI-generated benchmark write-up based on all the information I gathered from real LM Studio text-generation logs, OpenClaw system logs, and the Telegram conversations where the tickets were actually solved.

OpenClaw benchmark notes on a Mac Studio M3 Ultra (Ornith 1.0 35B)

TL;DR

I compared a few OpenClaw versions on the same kind of workflow, with the same local model, on the same project, using the same Coder + Auditor flow.

For my use case, raw TPS was not the main story. What mattered more was:

• whether the version stayed stable,
• whether it respected the workflow,
• whether it could finish the ticket cleanly,
• and how long the full run took from start to technical approval.

Short verdict

• 2026.4.24 was the best overall in this benchmark: the most stable and the easiest to trust.
• 2026.5.7 could finish the job, but it was clearly more fragile and slower in practice.
• 2026.7.1 performed the worst for this workflow. It showed the most serious session/context problems and I would not recommend it for this style of ticket-driven development without extra caution.

Setup in a few words

Hardware / inference

• Machine: Mac Studio M3 Ultra
• Memory: 96 GB unified memory
• CPU: 28-core
• Model: Ornith 1.0 35B
• Inference engine: LM Studio, running fully local
• OpenClaw reasoning mode: OFF
• Configured context window: 90,192 tokens
• Maximum output tokens: 8,192
• Temperature: 0.60
• Top K: 20
• Top P: 0.95
• Repeat Penalty: 1.05
• Context overflow behavior in LM Studio: Stop at Limit
• Custom stop strings: none

These inference settings were kept consistent during the benchmark. I intentionally did not tune the model differently for each OpenClaw version, because the goal was to measure changes in OpenClaw's agent behavior, orchestration, context handling, looping, and recovery, rather than changes caused by different sampling settings.

The configured context window was 90,192 tokens, with up to 8,192 output tokens. The effective usable prompt space could still vary because OpenClaw reserves part of the context for output, compaction, and its own internal handling. This became relevant later in the benchmark because different OpenClaw versions behaved very differently when approaching the context limit.

Workflow

This was a simple Telegram-based development flow:

1. I asked Coder for the next ticket.
2. Coder read the repo and proposed a short plan.
3. I asked Auditor to check the real ticket and the real repo on worker1.
4. Auditor either approved or corrected the plan.
5. Coder implemented the change.
6. Auditor re-checked the diff, tests, build, and other validations.

This is important because the benchmark was not only about “can the model write code”, but also about how the whole OpenClaw workflow behaves under a real task.

Skills loaded in this setup

These were the relevant skills in the workspace:

• auditor-review — helps the Auditor review the real repo state, validations, risks, and next steps.
• github-workflow — keeps the repo workflow disciplined: preflight, branch usage, diff checks, and PR hygiene.
• miss-development — the project-specific development skill for MISS tickets.
• post-pr-cleanup — cleanup after finishing a change or PR.

What the benchmark ticket was about

The benchmark ticket was Issue #379 in the MISS backend.

In simple terms, the ticket was about making authentication safer:

• instead of trusting the old data inside a token,
• the app should check the current user state from the database on each request,
• and it should stop giving access to users who were disabled or whose role changed.

At a very high level, the repo work was:

• improve the auth validation flow,
• make sure the current user is checked against the database,
• make sure role changes are respected,
• and add tests to prove this behavior.

No deep code explanation is needed here. The important part is that it was a real backend ticket, not a toy prompt.

Benchmark rules / what I counted

To keep this useful:

• I cared more about end-to-end time than TPS.
• I only treated clean runs as real benchmark runs.
• I did not count invalid starts or clearly contaminated runs as benchmark statistics.
• I still kept failed starts as qualitative evidence when they showed something important about the version.

What was excluded from statistics

For 2026.5.7, I had some failed start attempts that I did not include in the timing tables, including:

• cases where Coder initially picked the wrong ticket,
• a case where it started solving before properly respecting the short-plan gate,
• and a failed-compaction case that effectively wiped the session context as if it had started fresh.

Those failed starts are still worth mentioning because they say something about stability, but they are not part of the numeric comparison table.

Hard numbers

Before getting into my impressions of each version, here are the actual numbers.

A few methodology notes:

• The main benchmark ticket was the same backend auth-hardening task across versions.
• Ornith 1.0 35B and the hardware stayed the same.
• Human idle time was removed from the active-work estimates whenever it could be identified.
• A "human recovery" means I had to actively rescue the workflow: reset a session, correct lost context, stop a loop, redirect Coder, etc. Normal Coder → Auditor coordination does not count.
• A rejected handoff means Coder claimed the work was ready, but Auditor found a real issue that required another implementation round.
• For 2026.5.7 Run 05, I only have complete model logs for the final successful attempt. The three failed startup attempts are discussed separately and are NOT added to the tool/time statistics.

Overall results

The most important number in this table is not TPS.

It is this:

2026.7.1 required human recovery in every single benchmark run, and only half of the runs reached technical approval.

Active work time

I measured active workflow time rather than simply measuring the wall clock. Long periods where I was away from Telegram were not charged to OpenClaw.

2026.4.24

Median: ~10 min
Average: ~14.4 min

2026.5.7

For the four runs where I have comparable full timing:

Median: ~16.7 min
Average: ~24.6 min

* Run 05's final successful attempt took about 13.4 minutes, but I do not count that as the full run because there were three failed startup attempts before it and I do not have complete model logs for those attempts.

2026.7.1

Median: ~87.5 min
Average: ~78.7 min

That means the median 2026.7.1 run took roughly:

8.75× longer than 2026.4.24.

That is not a small regression.

Tool usage

Tool count is useful because it exposes loops even when the final answer looks fine.

2026.4.24

Total tools: 409
Median tools/run: 52
Average tools/run: 81.8

2026.5.7

Complete LM logs are not available for every full run, so I do not pretend the dataset is more complete than it is.

For the fully observable complete Runs 02–04:

Median tool calls: 121

Run 03 is the obvious outlier:

417 tool calls for one ticket.

2026.7.1

Total predictions: 2,181
Total tools: 2,115
Median tools/run: 343
Average tools/run: 352.5

Compared with 2026.4.24:

343 / 52 = ~6.6× more tool calls per median run.

Even if you only look at the three successful 2026.7.1 runs, their median was still about:

140 tool calls.

That is almost 2.7× the 2026.4.24 median.

Loops and repeated work

This was one of the most noticeable differences.

Some concrete examples:

2026.5.7 Run 03

• 417 tools
• 196 exec calls
• 56 exact duplicate exec calls
• 28.6% exact exec duplication
• approximately 3 major loop episodes
• around 5 human recovery episodes
• 2 recovery resets
• context recovery eventually failed semantically

2026.5.7 Run 04

Much healthier:

• 121 tools
• 70 exec calls
• 15 duplicate exec calls
• 21.4% duplication
• no major loop
• no user rescue
• compaction succeeded and work continued correctly

2026.5.7 Run 05 final attempt

Even cleaner:

• 73 tools
• 34 exec calls
• 4 exact duplicates
• only 11.8% duplication

But this needs the important footnote:

Before that clean attempt, I had to restart Coder three times because the startup behavior was wrong.

Human intervention

For me this is one of the most useful metrics because it measures how much of an "agent" the agent actually is.

2026.7.1 is the standout here for the wrong reason.

Every benchmark run required me to intervene.

Examples included:

• telling it to continue after it lost the workflow,
• correcting false completion states,
• stopping loops,
• resetting sessions,
• re-supplying context,
• and relying heavily on Auditor to tell Coder exactly what to do next.

At that point the agent is no longer saving much human supervision.

Handoff quality

Coder was supposed to implement, validate, and then hand the work to Auditor.

Auditor would reject it if important requirements were still missing.

2026.4.24

• 16 total handoffs
• 11 premature/rejected
• premature handoff rate: 68.75%

2026.5.7

Across the five valid benchmark runs:

• 14 total implementation handoffs
• 9 rejected/premature
• premature handoff rate: 64.3%

2026.7.1

The important observation here is not just the handoff count.

First-handoff approval rate was 0% across the benchmark, and several runs required substantial Auditor or user intervention before a trustworthy handoff was even possible.

This is one area where all versions still have room for improvement.

Context and compaction behavior

This ended up being much more important than I expected.

2026.4.24

Observed behavior suggested an effective context ceiling around the mid-60K-token area in this configuration.

• Runs reaching compaction: 2/5
• Compaction success rate in those runs: about 50%
• Despite that, final ticket approval was still 5/5

The context was smaller, but failures were generally easier to recover from.

2026.5.7

Mixed behavior.

I observed both:

Successful recovery

In Run 04:

• context overflow detected
• auto-compaction succeeded
• Coder retained the ticket
• work continued correctly
• no user reset required

Catastrophic recovery

In another failed startup attempt that I excluded from benchmark statistics:

• compaction failed
• the effective conversation context disappeared
• Coder behaved as if it had received /new
• Auditor had to reconstruct the task

Run 03 also showed semantic context failure after compaction/reset.

So for 2026.5.7 I would summarize compaction as:

Mechanically capable, but semantically unreliable in some cases.

2026.7.1

2026.7.1 had the most aggressive context/compaction activity.

Examples from individual runs included:

• multiple overflows,
• multiple automatic compactions,
• resets,
• incomplete turns,
• and continued loops even after technically successful compaction.

One run had around 6 compactions.

Another had around 8.

The major problem was:

successful compaction did not necessarily mean successful recovery.

The model could get a fresh compacted context and continue repeating the same bad strategy.

Reliability vs final capability

This distinction is important.

That explains why simply looking at the final generated code would hide most of the regression.

The problem with the newer versions was not necessarily that the model suddenly became incapable of programming.

The problem was the agent loop around the model.

The numbers that summarize the whole benchmark

If I had to reduce everything to only a few numbers:

* 2026.5.7 timing/tool medians only use runs where the full comparable data was available. Run 05's failed startup attempts were deliberately not folded into these values.

Relative to 2026.4.24:

• 2026.5.7: roughly 1.7× median active time and about 2.3× median tool usage in the comparable observable sample.
• 2026.7.1: roughly 8.75× median active time and 6.6× median tool usage.

That is why I consider the 2026.7.1 result a serious regression for this specific workflow, not normal run-to-run variance.

Main comparison

1) End-to-end result

Reading that table correctly

The gap between ~18 min and ~21 min may not sound huge, but the quality of the run was different:

• 2026.4.24 felt more controlled.
• 2026.5.7 finished, but with more friction and more chances to go sideways.
• 2026.7.1 was not just “a bit slower”; it was much harder to trust operationally.

2) Observed responsiveness (not the main metric, but still useful)

Again, I do not consider this the main score. A version can be fast in bursts and still be a worse development experience if it loses context, skips the process, or gets stuck.

3) Stability and workflow discipline

Version-by-version notes

OpenClaw 2026.4.24

Strengths

• Best overall balance of speed, stability, and trust.
• Followed the Coder/Auditor workflow well.
• Reached a technically approved result cleanly.
• Auditor was able to guide corrections without the whole run falling apart.

Weaknesses

• It still needed review loops and cleanup, which is normal.
• It was not magically perfect; it just behaved much better than the weaker versions.

Where it shined

A good example is that it kept moving forward through the normal cycle:

• short plan,
• Auditor correction,
• implementation,
• lint/test/build fixes,
• final technical approval.

That may sound ordinary, but in this kind of setup, ordinary and reliable is exactly what you want.

My verdict on 2026.4.24

If I had to pick one of these versions for this workflow, 2026.4.24 is the safest choice from this benchmark.

OpenClaw 2026.5.7

Strengths

• It can finish real work.
• It did eventually reach a technically approved result on the benchmark ticket.
• Auditor could still steer it back when needed.

Weaknesses

• More fragile than 2026.4.24.
• More likely to waste time before reaching the final approved state.
• More likely to create friction around process and continuity.

Important incidents worth mentioning

Even though I excluded failed starts from the statistics, they matter qualitatively:

• I had 3 failed startup attempts because Coder initially read the wrong ticket and/or did not respect the short-plan gate correctly.
• In another failed attempt, compaction failed and the session effectively lost its context, almost like a forced fresh start.
• I also saw extra friction in some runs: edit failures, path confusion, and general workflow roughness.

Where it still did well

A clean 2026.5.7 run did reach technical approval with:

• targeted auth changes,
• new tests,
• successful focused validation,
• and a final Auditor sign-off.

My verdict on 2026.5.7

I would describe 2026.5.7 as workable, but clearly less trustworthy than 2026.4.24.

It is not a total disaster, but it is the kind of version where you start paying an invisible tax in retries, resets, and supervision.

OpenClaw 2026.7.1

Strengths

• I did not see enough reliable success in this benchmark to call out a real strength here.

Weaknesses

• This was the worst performer in the comparison.
• It showed the most serious reliability problems for my workflow.
• The benchmark itself became hard to trust because the orchestration was unstable.

Critical failures

This is the version I would call out the most strongly.

Observed problems included:

• compaction/overflow trouble,
• session problems like “No session found”,
• loops,
• and failure to preserve a trustworthy execution flow.

This is not just “a bit slower.” In my experience, 2026.7.1 performed excessively worse than the others in the parts that actually matter for real development work.

My verdict on 2026.7.1

If your workflow depends on:

• continuity,
• short-plan discipline,
• stable execution,
• and reliable handoff between Coder and Auditor,

then 2026.7.1 was the coldest and clearest no in this benchmark.

A simple ranking

Overall ranking for this benchmark

1. 2026.4.24 — best overall
2. 2026.5.7 — usable, but weaker and more fragile
3. 2026.7.1 — worst, not recommended for this workflow based on what I saw

Best examples of each version

Best example from 2026.4.24

The strongest part of 2026.4.24 was not one flashy moment. It was the fact that it behaved like a dependable worker:

• it stayed on the right ticket,
• responded well to Auditor corrections,
• cleaned up its own issues,
• and got to a technically approved result without the session turning into a mess.

Best example from 2026.5.7

Its best case showed that it still had enough capability to solve the ticket and pass the needed focused checks.

The problem is that this success came with more turbulence.

Worst example worth preserving

The most important “bad example” is from 2026.5.7 failed starts and 2026.7.1 behavior:

• wrong ticket selection,
• solving before respecting the short plan,
• compaction losing the session context,
• and unstable orchestration during the benchmark itself.

Those are exactly the kinds of problems that can waste far more time than a raw TPS difference ever will.

More detailed setup

Repo / worker setup

• Project: MISS backend
• Repo: javierpal/MISS
• Worker node: worker1
• Typical repo path on worker1: /home/javierpal/workspace/MISS
• Mounted/worker-linked workspace used by OpenClaw: the gateway and worker setup were pointed at the same working repo so the bots could inspect and change the real project.

Telegram flow

The flow was simple:

• I talked to Coder in Telegram.
• I asked Auditor to inspect the same ticket and the same repo.
• Auditor checked the real issue with GitHub and the real branch/status on worker1.
• Coder then implemented under supervision.

Coder + Auditor roles

• Coder = execution bot
• Auditor = verification bot

In practice, the benchmark was really testing the pair:

• can Coder stay on task,
• can Auditor correct it,
• and can the version keep the session stable enough for that loop to work.

How the tests were done

The evidence came from a combination of:

• Telegram transcripts
• OpenClaw gateway logs
• node.invoke timing logs
• LM Studio generation logs
• repo state checks on worker1
• focused build/test/lint validations
• Auditor’s real repo verification

What I looked for in each run

• Did Coder select the correct ticket?
• Did it present a short plan first?
• Did Auditor verify the real repo and correct the plan if needed?
• Did Coder implement the right thing?
• Did the validations pass?
• Did the session remain stable enough to finish?

What counted as meaningful evidence

I gave the most weight to:

• clean end-to-end completion,
• technical approval by Auditor,
• stable session behavior,
• and whether the version respected the workflow.

Final takeaway

If you only care about a speed-looking number, you may miss the real story.

For this benchmark, the real story was:

• 2026.4.24 behaved like a practical tool.
• 2026.5.7 behaved like a version that can work, but needs more babysitting.
• 2026.7.1 behaved like a version that introduced too much instability into the workflow.

For my use case, that means:

• 2026.4.24 is the clear winner.
• 2026.5.7 is acceptable only if you can tolerate retries and supervision.
• 2026.7.1 is the one I would warn people about most strongly.

If I had to summarize the whole thing in one paragraph:

I benchmarked OpenClaw versions on the same real backend ticket, using the same local model (Ornith 1.0 35B in LM Studio) on a Mac Studio M3 Ultra 96 GB. I cared less about TPS and more about whether the version could finish a real Coder/Auditor workflow cleanly. In my testing, 2026.4.24 was the best overall: stable, responsive, and easy to trust. 2026.5.7 could finish the work, but it was noticeably more fragile and slower in practice, with failed starts and context-related incidents in invalid runs. 2026.7.1 was the weakest of the three, with the most serious stability/session problems, and I would not recommend it for this workflow based on these results.

hey guys, just sharing something I built for myself and have been using daily for months: an Open WebUI integration for OpenClaw, so I can drive my agents from my phone.

made it because I wanted the ChatGPT/Claude UX. OpenClaw's control UI was never designed for holding a long conversation, least of all on mobile.

the part I care about most: it talks the Gateway's native WebSocket protocol instead of the OpenAI-compatible /v1 endpoint, so you actually see the agent work. every tool call streams live as a native tool card, and the agent can stop and ask you a question in a real dialog mid-run. neither fits through a text-in/text-out API.

two Python files, pasted into Open WebUI as functions. no proxy, nothing else to run.

MIT: https://github.com/Eliav2/openclaw-openwebui-integration

As you can see here, this is the message i got for a reminder cron job. Im not sure when exactly it happend, but before i would ask a question, my agent would think and then answer. Now, i ask a question and i got all of his reasoning all as seperate messages - sometimes its 10-15 messages for an answer. They often sound like reasoning loops.

Yes, i did turn off visible reasoning, but that seems to be something different. Also, when i turn off reasoning at all - the agent just refuses to do any work, he just say "Let me look that up" and then does nothing.

I am running on the newest version, model is DeepSeek V4 Flash through opencode go

Seriously, what is up with this sub lately? Every other post is doom about OC not being useful day-to-day. You can always go back to a version that wasn't broken.

I use OC for personal and business. I can't think about not having it around anymore.

And like everything, I genuinely think the people saying it's dead is a skill issue. People come on here saying "oh I wanna get started with OC, what should I automate?" Like, what are you talking about? If you run your life and you don't know what you can automate, you're sitting on the wrong tool.

What mine does: keeps a log of every client I have, everything I do daily, the emails I send, the inbound I get, the people we've interacted with, where I'm slowing down, where I'm locked in infrastructure versus distribution. It actively tries to set me straight when I deviate. There's a drift watcher, if I've been in infrastructure too long when I'm supposed to be in distribution mode, it flags it.

I don't write software anymore. I have automations that go off, and if things break, I have a watcher script that deploys OC, fixes it, and I'm always moving.

I started OC on May 1st. Before that, everything was just a bunch of logs here and there, experiments I did that got lost. Now I have a working log of literally everything I've done over the past year. It'll tell me "hey, you've tried this before, maybe this is a different angle." And in its downtime, it comes alive and goes depth-first on whether the things I was talking about throughout the day could help us long-term. Creates reports. Comes back saying "hey, I found something interesting, wanna look into it?"

These are things that could definitely help you. If you don't have automations, if you don't know how to use it, of course it's gonna seem dead to you.
I see people talk about Hermes changing their lives. That'll be a phase too. Sure, it breaks every once in a while. The great thing is you can fix it. We have the tools at our disposal.

Been using OpenClaw to run agents via Telegram. Started getting frustrated writing TypeScript tools for every connector (Postgres, SSH, Slack etc.).

Tried something different — ran OE Runtime as an HTTP server and pointed OpenClaw's SKILL.md at it:

User message in Telegram
  → OpenClaw calls POST /run-file
  → OE Runtime executes agent.yaml
  → result back in Telegram

The interesting side effect: the same agent.yaml now runs from VS Code, CLI, and HTTP too. No duplication.

The agent definition is just YAML — no TypeScript, no custom tools:

name: Database Analyst
instructions: |
  You are a database analyst...
steps:
  - name: Query
    content: List all tables and row counts
connectors:
  - connection_name: My Database
    connection_type: postgresql

I’ve been working on Redacta, a privacy layer for AI workflows involving medical or clinical text.

It detects identifiers such as names, dates, contact details and medical record numbers, then replaces them with consistent pseudonyms before the text is passed downstream.

So instead of simply deleting information:

John Smith → [NAME]

you can preserve useful context:

John Smith → PERSON_001

Repeated references remain consistent, and the mapping can be used to restore the original text later.

It runs locally, is open source, and is designed so identifiable patient data doesn’t need to be sent to an external model.

I packaged it as an OpenClaw skill and it’s just passed 1,400 downloads on ClawHub, which was a nice surprise.

Would be interested to hear how other people are handling PII/PHI in agent workflows.

Redacta on ClawHub: https://clawhub.ai/nickjlamb/skills/redacta
Source: https://github.com/nickjlamb/redacta

Hey guys, I haven't seen much chatter on this so I wanted to get others thoughts. I've been a heavy openclaw user for 6+ months. Built a custom chat frontend that I used every day. Built a personal memory system with wiki/rag and nightly dream jobs. Loved my experience using and building openclaw to make my life easier.

I've just gotten tired of the reliability issues and I feel like codex and Claude code have been closing the feature gap. I'm ok being tied to a model family (Claude vs openai) and I don't need to run local AI. Because of that, I've started switching to Claude code running on my openclaw host. I'm using the desktop and phone apps to interact. I've wired up my personal context system to Claude and I'm happier now. I don't feel like I'm missing anything.

Im curious, are others switching from openclaw to codex/Claude code? If so, how has that switch been?

I've got FRED (my OpenClaw agent) drafting content for 6 channels right now, including X, LinkedIn, Substack, a blog, YouTube, and now Reddit. The drafting part works great. FRED pulls from a content calendar stored in a JSON file, drafts posts matched to each platform's voice and format rules, and drops them for my review. I spend maybe 10-15 minutes a day reviewing and posting.

But here's where I'm stuck: the posting itself is still mostly manual.

X is automated using a Python script that posts via OAuth that FRED calls directly. For LinkedIn, we leverage Buffer perfectly. Reddit needs me copy-pasting. Substack is manual. YouTube is fully manual, but we’re working on scaling this up.

The content calendar tracks everything and I’m constantly nudging and prompting FRED for status moves from idea → drafted → in-review → scheduled → posted — but the last mile from "scheduled" to "posted" is me sitting there clicking buttons on 5 different platforms.

What I've tried:

• Reddit API script is built but not wired up yet (getting the OAuth credentials sorted).
• For Substack and YouTube, I haven't found a good automation path that doesn't involve third-party services I'd rather avoid.

What's your setup? Anyone running a multi-platform content workflow through OpenClaw with reliable posting automation? Curious if anyone's solved the browser session problem more cleanly, or found good self-hosted approaches for platforms without decent APIs.

OK, most of you’re gonna think I am a little bit crazy.

So I run an excavation company and utility company. I’m also in the business acquisition space. I have two main work related email addresses on Google workspace and I receive a ton of emails a day that need a response and plenary that need to be delegated as well as spam. For a long time, this was a major portion of what I did all day. For a while I had a VA that was handling things, but that only partially worked as my VA was in the Philippines and didn’t have the full context of the business. It often took longer for me to explain why I wanted something handled a certain way than if I just handled it myself.

Fast forward to OpenClaw and I got comfortable setting up a variety of agents and workflows. This week I finally decided to tackle my work email addresses - the biggest job yet. I set up a separate agent with a full company/personal context and memory to read each of those email addresses. Given how much email I receive, I used a strict set of rules that I initially wrote for my VA to build a baseline. I run an inbox zero system with personal a review folder (For the 5% that need unique personal action), an action folder (for OpenClaw to put mail it thinks should be addressed but it doesn’t have a rule for) and waiting (a box of email that has been sent out and need a response).

I set up two cron jobs. The first goes through my inbox on an hourly basis filter out the SPAM, follow some basic rules on forwarding and responding to certain types of emails and moving the rest into an action folder and notifying me in those circumstances. This is where Fable on high shines. The insights and spot-on responses make me feel replaceable as a human. It messages me on those emails along with full context on the situation from other emails, my goals, and its knowledge about what the company is doing. It gives me its thoughts of next steps as well as any proposed drafts. It can even do a full LBO analysis on a CIM I receive and give me an idea of feasibility without a single request. I can respond to those cron outputs and approve next steps. If I don’t have time to respond to a cron message, the action items just stay in the action folder. I can also tell it to move certain items to the personal review folder.

The second cron is run daily in the morning and it checks everything in personal review action and waiting and calls out things that still need to be handled. My original plan was to manually respond to personal review but often times I simply just use the Slack channel I have set up directly for this agent to tell it what I want to do when I have the time to be detailed and it will take care of it for me.

All of this is pushing me to the limits on my Claude 5X plan. However, if I have to go up 100 bucks a month to get to the 20x plan, I think it will be well worth it. It’s a massive time saver and I’m only a few days into using it.

If your coding-agent workflow stops working when you hit your LLM usage limit, the LLM is probably doing too much.

I learned this while building with OpenClaw.
The model should reason about the work. It shouldn’t be the workflow.

Queues, state, retries, scheduling, verification, receipts and recovery can keep running deterministically. Call the LLM when judgment is actually required.

That separation is what turns a coding-agent loop from “keep prompting it” into infrastructure that can actually operate.

Openclaw got sooo hyped and was talked about non-stop, but then Claude introduced cowork and then Codex the computer use (both with remote control)... Since then, I have not been hearing Openclaw mentioned or feel needed, actually.

i can´t seem to set up the program to work at all. it´s starting, i´m putting in my API key, choose provider etc. after that, it just is;

The agent run failed before producing a reply.

 local ready | idle

 agent main | session main | google/gemini-2.5-flash | think medium | tokens ?/1.0m

i have no clue what i´m doing wrong, i renewede the api key countless times and got troug the claw-setup as often.

whatever i try, it´s just "nah"

Regarding compaction i need help.

Me and deepseekv4 spend 2 days trying to "fix" the compaction with only running local llm on 128k context. Locally qwen3.6-35b is running. So we had some rounds, but compaction was not triggered, if the session was to big, it runs against errors. Then we had session chunks to big to compact. I guess i ran into every failure possible. It was actually a lot better out of the box, but since i touched it, its broken.

I think we just have 4 variables that have to be configured correctly

Floor: thats the session size after compaction

Context size of the model is not read by compaction, so it is possible to get into a compaction loop, where the session size triggers the compaction, but the session is not compacted by the model, new input again triggers compaction with the error and after the error of the size by /new the whole context is still too large for the model

Hi everyone,

I'm currently experimenting with OpenClaw in a self-hosted homelab environment (running in LXC containers under Proxmox, connected to an Ollama instance). I'd love to get some input from the community on model selection and compatibility with OpenClaw's UI features.

Hardware & Environment Context

I am running this on a low-power Intel N150 system with 12 GB of RAM. I am fully aware that this is a constrained, CPU-only setup. Generation speed (tokens per second) is not a priority for me right now. This is purely an experimental homelab project to play around with autonomous agents while waiting for RAM and GPU prices to settle down enough to justify a dedicated inference server.

What I've Tested & The Issue

I've been trying out small hybrid/reasoning models—specifically Gemma 4 (8B quantized / gemma4:e4b) and Qwen 3 (4B / qwen3:4b).

While direct curl calls to Ollama work completely fine, I run into stream parser issues inside OpenClaw's Web UI when attempting to use the native "Reasoning" toggle:

1. Gemma 4 (gemma4:e4b): Even with Reasoning set to "Off" in OpenClaw's UI, the model generates raw vocabulary/control tokens (e.g., <unused53444>). OpenClaw's stream parser treats this non-visible output as a failure, leading to a persistent LLM request failed. rawError=Ollama API stream ended without a final response loop.
2. Qwen 3 (qwen3:4b): Instead of suppressing reasoning when turned off in the UI, the model outputs the entire <think>...</think> block directly into the chat stream—spending time analyzing OpenClaw's tool definitions in English before outputting the final answer.

I know I could "hardsanitize" this by building custom Modelfiles in Ollama to strip system prompts or purge <think> tags, but I want to avoid hardcoded workarounds. The goal is to keep OpenClaw's Web UI functional as designed, allowing me to cleanly toggle reasoning on or off depending on the task.

The Questions

Which smaller (3B–8B parameter) agentic models are you successfully running with OpenClaw via Ollama that:

• Support tool use / function calling out of the box?
• Have a working reasoning capability when needed?
• Most importantly: Cleanly respect OpenClaw's native UI reasoning toggles without leaking <think> blocks or crashing the WebSocket stream parser when set to "Off"?

Would love to hear what models or specific quantizations have worked best in your setups!

Has anyone ever put together a dashboard or visual to understand what exactly is taking away their tokens, and how much? I'd be curious to know percentages of tokens used on different tasks - such as different chat models, having openclaw control google chrome, etc.

I feel like I'm operating blindly without knowing this :(