OpenClaw on KnightLi Blog

How OpenClaw Creator Peter Steinberger Sees AI Software Development: From OpenClaw to Closed-Loop Coding

Sun, 17 May 2026 20:02:26 +0800

Peter Steinberger’s career is a useful lens for understanding what is changing in AI software development.

He is not a newcomer who suddenly became visible because of AI. Before OpenClaw, he was already the founder of PSPDFKit, a company focused on PDF rendering, document processing, and developer tools. Products like that are hard to win with concept packaging alone. They have to deal with performance, compatibility, API design, enterprise customers, and long-term maintenance.

So when Steinberger later built OpenClaw with AI tools and shared views around AI agents, personal automation, and AI coding, the point was not simply that “one person wrote a lot of code.” The more interesting part is how he combined years of software engineering experience with a new generation of AI coding agents and rethought the development process.

AI coding is not a magic button

Discussions about AI coding often fall into two extremes.

One side says AI can already write code, so programmers are almost obsolete.

The other side says AI-generated code is unreliable, so real engineering still has to be hand-written by people.

Steinberger’s experience points to a third view: AI changes the unit of operation in software development, but it does not remove engineering judgment.

In the past, developers mainly worked around editing code. Requirements breakdown, architecture decisions, implementation, testing, and bug fixing all revolved around manual code changes.

Once AI coding agents enter the workflow, developers increasingly manage an execution system:

Explain the goal.
Provide context.
Set boundaries.
Let the agent modify code.
Run tests and checks.
Iterate based on results.

This is not simply handing the keyboard to a model. It is moving humans from “typing every line” toward “defining direction, designing feedback, and judging results.”

Why he is skeptical of calling it vibe coding

One phrase that often appears around Steinberger is vibe coding.

The term originally described a new style of development: developers describe ideas in natural language, let AI generate large amounts of code, then keep adjusting based on runtime results and feedback.

But Steinberger is not entirely sold on the phrase. Public coverage has noted that he sees vibe coding as potentially dismissive, implying that AI-assisted development is just “generating by feel” while ignoring the skill, judgment, and experience behind it.

That criticism makes sense.

Effective AI coding is not about typing a casual sentence and trusting the model’s output. It requires:

Breaking vague requirements into executable tasks.
Detecting when the model misunderstands the goal.
Designing tests and acceptance criteria.
Judging whether the code structure will remain maintainable.
Knowing when to stop generating and switch to human review.

In other words, AI reduces the friction of writing code, but it does not reduce the responsibility of understanding the system.

The loop is the key

One idea often associated with Steinberger’s interviews and writing is the importance of the loop.

Letting AI generate code is open-loop.

Letting AI generate code, run it, read errors, fix problems, and run tests again is closer to closed-loop development.

That difference matters.

Open-loop generation easily creates software that looks usable on the surface. The page opens, features appear to exist, and there is plenty of code. But once it enters a real environment, problems with state management, permissions, exception handling, edge cases, and deployment quickly appear.

Closed-loop development means output must be constrained by feedback. The simplest loop is:

Write down the goal clearly.
Let AI modify the code.
Automatically run tests, type checks, lint, or a build.
Feed errors back to AI.
Repeat until it passes.
Let a human review the critical path.

This is where AI software development can truly improve efficiency. Not because the model gets everything right the first time, but because it can participate quickly in a cycle of generation, validation, and repair.

More experience makes AI more useful

One of the easiest misconceptions about AI coding is that experience no longer matters.

Steinberger’s case suggests the opposite: experience becomes more important, but its role changes.

An experienced engineer is better at deciding:

Which tasks are suitable for an agent.
Which modules need tests first.
Which changes are too risky for broad AI refactoring.
Which generated code merely looks plausible.
Which problems should be solved through architecture rather than more patches.

AI can generate many candidate solutions. The more candidates you have, the more judgment you need. An inexperienced person may be impressed by “it runs.” An experienced engineer asks: can it be maintained? Can it scale? Does it break a security boundary? Can we debug it when something goes wrong?

That is why AI coding agents do not turn software engineering into pure chat. They outsource part of the execution work while amplifying planning, review, validation, and trade-off decisions.

OpenClaw matters beyond the project itself

OpenClaw drew attention not only because it is an open-source AI agent, and not only because it grew quickly.

It is also a signal: developers increasingly want AI to do more than answer questions. They want it to connect to real tools and perform real actions.

Traditional chatbots stay inside the chat box. They can explain code, write drafts, and give advice, but people still need to copy, paste, open software, and run commands.

The agent direction connects models to tools:

File systems.
Browsers.
Terminals.
Email.
Calendars.
Third-party services.
Project repositories.

Once models can use those tools, the boundaries of software development shift. AI is no longer just code completion. It can participate in project reading, task decomposition, file editing, test execution, PR preparation, and workflow automation.

That is also why Steinberger’s move to OpenAI drew attention. He represents not just a single developer story, but a product direction: personal agents moving from demos into everyday work.

What this means for ordinary developers

For ordinary developers, Steinberger’s experience is not something everyone can copy directly.

Not everyone can manage multiple agents at once. Not every project is suited to heavy AI generation. Not every team accepts a workflow of “generate first, iterate quickly.”

But several lessons are useful.

First, write tasks clearly.

AI is sensitive to vague goals. If you say “optimize this,” it may change style, structure, features, and logic. If you say “change the login failure message from English to Chinese without altering the authentication flow,” the result is usually more controllable.

Second, standardize validation commands.

If a project has no tests, no build command, and no lint, AI has trouble forming a loop. Even basic commands like npm test, go test ./..., pytest, or hugo are better than relying only on visual inspection.

Third, control the scope of changes.

Having AI handle one module, one bug, or one page at a time is usually more reliable than asking it to “refactor the whole project.”

Fourth, keep human review.

For authentication, payments, permissions, data deletion, deployment scripts, database migrations, and security configuration, do not lower the review bar just because the code was generated by AI.

Fifth, review prompts and failure patterns.

If AI often misunderstands a certain type of task, write those constraints into project rules, agent instructions, or skill files. AI coding capability comes not only from the model, but also from the work environment you build around it.

Where AI software development is going

Steinberger’s story suggests that AI software development is moving from “helping write code” toward “organizing software production workflows.”

Early AI coding tools were mainly useful for function completion, error explanation, and template generation. The shift now is that agents can work across files, call tools, run checks, and continue fixing based on feedback.

This points to several trends.

First, the productivity ceiling for individual developers will rise.

One person can push more prototypes, scripts, internal tools, and small products. But higher output does not automatically mean higher quality. The faster code is generated, the more validation matters.

Second, project structure becomes more important.

The clearer the code, tests, and documentation, the easier it is for AI to make correct changes. Messy projects are hard for humans and hard for AI.

Third, software engineers will look more like workflow designers.

In the future, what matters will not only be whether someone knows a programming language, but whether they can organize requirements, context, tools, tests, deployment, and permissions into a controlled loop.

Fourth, security boundaries become more sensitive.

If an agent can do things, it can also do the wrong things. If it can read files, run commands, and access services, then permissions, audit, and rollback become infrastructure for AI development environments.

Summary

The most valuable part of Peter Steinberger’s view of AI software development is not how much code AI generated. It is the development posture he demonstrates.

Humans are no longer only typing line by line inside an editor. They are designing goals, managing agents, building feedback loops, reviewing results, and adjusting the system. Code remains important, but it is no longer the only center of labor.

If traditional software development emphasized “writing the code correctly,” AI software development increasingly emphasizes “making the system continuously produce verifiably correct results.”

This is not just about lowering the engineering barrier. It changes the shape of engineering ability: from manual implementation toward task decomposition, context management, tool orchestration, automated validation, and final judgment.

References

What Is Hermes Agent: Overview, Strengths, Getting Started, and How It Compares to OpenClaw

Sun, 12 Apr 2026 14:07:58 +0800

If you have been following open-source AI agents lately, Hermes Agent is a project worth paying attention to. Built by Nous Research, its main appeal is not simply that it is “another chat wrapper,” but that it tries to bring long-term memory, reusable skills, context files, MCP extensions, a messaging gateway, and parallel sub-agents into one unified agent runtime.

Based on the official README, Hermes Agent has a very clear goal: it can work like a local CLI assistant in your terminal, or like a cloud-hosted personal assistant that stays available through Telegram, Discord, Slack, WhatsApp, Signal, and other channels. For users who want to combine a coding assistant, an automation assistant, and a personal AI workspace into one system, that positioning is compelling.

01 An overview of Hermes Agent

Hermes Agent is an open-source self-improving AI agent from Nous Research. It supports multiple model providers, including Nous Portal, OpenRouter, OpenAI, and custom OpenAI-compatible endpoints. It can also run across different execution backends such as a local terminal, Docker, SSH, Daytona, and Modal.

What separates Hermes from many “tool-using chatbots” is that it does not focus only on tool calls within a single session. It puts much more emphasis on building persistent capability across sessions. The official docs break this idea down into several parts:

Persistent memory: stores key information about the environment, project, and user preferences through MEMORY.md and USER.md.
Skills system: turns successful workflows into reusable skills that can be loaded on demand.
Context files: automatically reads files such as AGENTS.md, SOUL.md, and .cursorrules to inject project conventions directly into the session.
MCP integration: can connect to any MCP-compatible tool server to extend database, GitHub, filesystem, and scraping capabilities.
Messaging gateway: beyond the CLI, it can also be used through Telegram, Discord, Slack, WhatsApp, Signal, Email, and other entry points.

In one sentence, Hermes Agent feels more like a general-purpose agent operating layer with memory, skills, extensibility, and multi-channel access.

02 Where it stands out

1. It covers both CLI workflows and messaging workflows

Many agent projects lean either toward terminal-based developer assistance or toward chat-platform bots. Hermes tries to combine both. You can run hermes directly in the terminal, or continue with the same assistant through Telegram or Discord after starting the gateway.

The practical benefit is that Hermes is not limited to being useful only when you are sitting in front of your computer. If you deploy it to the cloud or a VPS, it can become a continuously available personal AI assistant.

2. It is designed for long-term use

Hermes does more than chat and call tools. It is also built around long-term accumulation:

Persistent memory with boundaries, instead of endlessly stuffing more context into each conversation.
A skills system that lets you save and reuse successful workflows.
Search across past sessions for retrieval and recall.
Project context files that reduce the need to repeatedly explain the same background.

This matters a lot for people who work repeatedly inside the same repositories, workflows, and team conventions. It means the agent is not just helping once; it can gradually become more familiar with your environment.

3. MCP support gives it strong extensibility

The Hermes documentation explicitly supports MCP and describes both stdio and HTTP integration modes. In practice, that means if an external system already has an MCP server, Hermes can usually connect to it with much lower integration cost.

That is more flexible than writing a custom plugin for every single system. For users who already have tools built around the MCP ecosystem, Hermes should be much easier to extend.

4. It is friendly to OpenClaw users

This part is especially interesting. The Hermes README directly provides hermes claw migrate, and explicitly says it can import configuration, memory, skills, API keys, and messaging platform settings from OpenClaw.

That suggests Hermes is not trying to ignore the existing ecosystem and start from zero. It is clearly positioning some OpenClaw users as a migration audience.

03 How to get started quickly

The officially recommended Hermes Agent installation method is very straightforward:

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

According to the official README, it supports Linux, macOS, WSL2, and Android Termux. One important note is that native Windows is explicitly not supported right now, so Windows users are advised to use WSL2.

After installation, you would usually refresh your shell first:

`1`	`source ~/.bashrc`

Then you can launch it directly:

hermes

If you want to go through a more complete step-by-step initialization flow, the easiest command is:

`1`	`hermes setup`

Based on the official documentation and README, a simple first-time setup path looks like this:

Run hermes setup to finish the base configuration.
Use hermes model to choose a model provider and model.
Use hermes tools to enable the toolsets you want.
Run hermes to enter the interactive CLI.
If you want channels such as Telegram or Discord, continue with hermes gateway.

If you are already an OpenClaw user, it is also worth previewing the migration command:

`1`	`hermes claw migrate --dry-run`

That lets you inspect what can be migrated before doing a real import.

04 How to think about it versus OpenClaw

From the official docs and README, Hermes Agent and OpenClaw are not simply a case of one replacing the other. Their positioning overlaps, but their priorities are clearly different.

What Hermes Agent feels like

Hermes feels more like a product centered on an agent core and workflow system. It emphasizes:

CLI experience
Memory and skill accumulation
Project context files
MCP extensibility
Parallel sub-agents
Switching execution backends across local, container, remote, and serverless environments

If your main goal is to make the agent understand your project better, reuse capabilities over time, and connect more naturally into MCP and developer workflows, Hermes is likely the better fit.

What OpenClaw feels like

OpenClaw feels more like a platform centered on a personal AI assistant plus a messaging gateway. It emphasizes:

Rich messaging channel integration
A continuously running Gateway
A browser-based Control UI
Device pairing, remote access, and status management
Stronger assistant-oriented surfaces such as voice, mobile access, and Canvas

If your main goal is to keep a personal AI assistant reliably available across multiple chat channels and devices, with a control panel to manage it, OpenClaw has a stronger product feel in that direction.

A more practical rule of thumb

You can roughly think of the two like this:

Hermes Agent: more of a “growing general-purpose agent workspace”
OpenClaw: more of a “multi-channel always-on personal AI assistant platform”

That distinction is not absolute, because both projects are still expanding and Hermes also offers a migration path from OpenClaw. But based on the currently public material, Hermes is more prominent on the memory, skills, context, MCP, and developer-workflow side, while OpenClaw looks more mature on the gateway, multi-channel, Control UI, and device-access side.

05 Who should try it

Hermes Agent is especially worth trying first if you fit one of these profiles:

You already rely heavily on AI tools in the terminal and want an agent that better understands your codebase and project rules.
You want to combine AGENTS.md, skills, memory, and MCP into one workflow.
You do not want to be locked into a single model vendor and prefer flexible provider switching.
You already use OpenClaw and want to explore a direction that is more centered on agent workflows.

If you care more about mobile reach, broad IM platform integration, a browser control console, and the feeling of an always-online personal assistant, OpenClaw still has a lot of appeal.

References

Hermes Agent GitHub: https://github.com/NousResearch/hermes-agent
Hermes Agent Docs: https://hermes-agent.nousresearch.com/docs/
Hermes Features Overview: https://hermes-agent.nousresearch.com/docs/user-guide/features/overview
Hermes MCP: https://hermes-agent.nousresearch.com/docs/user-guide/features/mcp/
OpenClaw GitHub: https://github.com/openclaw/openclaw
OpenClaw Getting Started: https://docs.openclaw.ai/start/quickstart
OpenClaw Control UI: https://docs.openclaw.ai/web/control-ui

OpenClaw Dreaming: Machines Start Dreaming While Humans Lose Sleep

Sun, 12 Apr 2026 12:41:34 +0800

Long-term memory has always been a weak point for large models. As context grows, memory becomes harder to manage. An agent may appear to remember everything, yet become worse at judging what matters and what should be forgotten.

On April 5, OpenClaw introduced an experimental feature called Dreaming. It is not just a catchy label. It is a background memory-management system modeled on human sleep, designed to help agents wake up with cleaner and more useful memory.

01 A sleep-based pipeline for memory consolidation

Dreaming does more than index data. It breaks memory processing into three stages that mirror different functions of human sleep.

Light Sleep: the system scans recent conversations and retrieval traces, removes duplication, and builds a candidate list. At this stage, it only buffers information and does not modify the core memory file MEMORY.md.

Deep Sleep: the system applies stricter filters to identify durable information. Only entries that pass thresholds for score, recall count, and distinct query count move forward. Before writing anything, it checks the latest logs again to remove stale content. The final result is appended to MEMORY.md, while a deep-sleep summary is written to DREAMS.md.

REM: after memory consolidation, the system looks for hidden links across recent behavior traces. It extracts patterns and reflective summaries, then stores them in a dedicated REM section to help the agent respond with better structure and broader context.

Dreaming also produces a human-readable dream journal. Once enough material accumulates, a background sub-agent calls the default model and appends a short natural-language entry to DREAMS.md.

02 A scoring system for deciding what deserves to stay

The real point of Dreaming is not just organizing memory, but filtering it. Instead of keeping everything, OpenClaw uses a weighted scoring model to decide what belongs in long-term storage.

The six dimensions are:

Relevance (30%): how useful the information is when retrieved.
Frequency (24%): how often the item appears in short-term signals.
Query diversity (15%): whether it shows up across different prompts and contexts.
Recency (15%): whether the information is still fresh and actionable.
Integration (10%): whether it remains stable across multiple days.
Concept richness (6%): how dense and connected its concept graph is.

In practice, this means the system tries to keep information that is repeated, useful, current, and broadly applicable, while letting lower-value noise fade away.

03 Why it reminds people of Claude’s “dreaming” approach

Some developers have noted that Dreaming resembles the automated dreaming logic described in leaked Claude Code material around the KAIROS system. Older approaches that repeatedly rewrote the entire MEMORY.md could become messy over time. By splitting the flow into light sleep, deep sleep, and REM, Dreaming makes the pipeline more explicit: consolidate first, preserve next, and derive higher-level patterns last.

Others have highlighted the neuroscience angle. Terms like Dreaming, Light Sleep, Deep Sleep, and REM are not random branding. They directly borrow from human models of sleep-based memory consolidation.

OpenClaw already uses files like IDENTITY.md, USER.md, and HEARTBEAT.md to preserve identity, user context, and continuity. DREAMS.md fills in the missing piece: deciding which memories are actually worth keeping.

04 The most ironic part: machines dream, humans stay awake

The value of Dreaming is not that AI remembers everything. It is that AI learns to review short-term traces, extract patterns, and discard noise. A strong agent should not behave like a dumb storage device. It should become better over time at understanding a user’s preferences, recurring goals, and long-term context.

From an engineering perspective, the most interesting part is that the system is not presented as a mystical black box. It is a structured backend process with stages, thresholds, reflection, and forgetting rules. That makes AI memory feel less like uncontrolled context bloat and more like a designed system.

That is also what makes the whole thing feel ironic. We are spending enormous effort teaching machines how to dream, while many people are losing sleep over being replaced by those same increasingly capable systems.

OpenClaw and Agent Harness: Why It Looks Like AGI

Fri, 10 Apr 2026 09:16:17 +0800

When many people first try OpenClaw, it feels more like a teammate who can get work done than a chatbot.

That feeling is not mysterious. The key is this: OpenClaw is not a jump in one model capability; it is a complete Agent Harness.

Core Conclusion

The essence of OpenClaw can be summarized as:

the model handles understanding and decisions
the harness handles memory, tools, triggers, execution, and outputs
the two collaborate through a loop to create continuous action

So the core reason it “feels like AGI” is not that the model suddenly became all-powerful, but that systems engineering amplifies what the model can execute.

What Is a Harness

You can think of a harness as an exoskeleton for the model.

A standalone LLM usually provides an answer in a single request. A harness adds these capabilities:

session and state management: link multi-turn tasks
memory mechanisms: store and retrieve context when needed
tool system: call browsers, terminals, files, and external APIs
trigger mechanisms: wake on timers or events instead of waiting for a human prompt every time
output channels: write results back to systems, not just return a paragraph

When these capabilities are connected in one loop, the model shifts from a responder to an executor.

Why OpenClaw Feels Different

A traditional chatbot is “ask once, answer once”.

OpenClaw is more like a closed loop of “observe -> use tools -> inspect results -> decide next”. Once this loop is established, the system can keep moving a task forward.

This is also the most valuable lesson from OpenClaw:

it proves the agent experience mainly comes from architecture design
it decomposes “autonomy” into modules that can be engineered

Value and Boundaries

OpenClaw is general and flexible, but the trade-offs are also clear:

the more context and tool definitions you include, the higher the cost
the more general the system is, the more complex debugging and governance become

In production scenarios, many teams choose smaller, more specialized agents instead of one universal agent.

Anthropic and OpenClaw Timeline: The Full Sequence of Events

Wed, 08 Apr 2026 19:48:42 +0800

Background

On April 4, 2026, Anthropic announced that Claude subscriptions would no longer cover third-party tools such as OpenClaw.

The direct user-level impact was that third-party workflows previously relying on the subscription path for Claude access had to move to alternative access methods or switch to other models.

Timeline (January to April 2026)

January 2026

According to public reports, Anthropic asked the project formerly known as Clawdbot to change its name, citing pronunciation similarity to Claude.

During the same period, community feedback began to appear regarding restrictions on third-party access via subscription credentials.

February 2026

The relevant restrictions were written into the terms of service, further clarifying the boundary between subscriptions and third-party automated invocation.

In the same month, OpenClaw released v4.0 and refactored its underlying architecture into a pluggable model backend. In other words, the model was no longer a single hardcoded entry point and could be switched across multiple providers.

March 2026

Anthropic released Claude Dispatch and Computer Use, covering capabilities such as remote task execution and desktop operation.

In subsequent updates, OpenClaw continued building its compatibility layer, unifying differences across model providers in authentication, tool-call formats, and response schemas, thereby reducing migration costs when switching models.

Public reports also noted that OpenClaw and Anthropic communicated in late March, but the overall strategic direction remained unchanged.

April 4, 2026

Anthropic formally executed the subscription coverage cutoff for third-party tools.

This marked the execution phase of policy adjustments that had been underway for several months.

April 5, 2026

OpenClaw released v4.5 with several main actions:

Reprioritizing model entry points in the onboarding flow
Integrating alternative model paths such as GPT-5.4
Continuing adaptation work for task flow and interaction experience

Based on the release timing, OpenClaw’s switchover capability was not built entirely ad hoc, but rested on the multi-model architecture work launched since February.

Two Parallel Directions in the Process

Viewed along the timeline, both parties advanced different priorities during the same period:

Anthropic: tightening subscription boundaries and integrating official product capabilities
OpenClaw: strengthening model replaceability and cross-model compatibility

These two routes are not inherently contradictory, but they do create competition over entry-point ownership and where user workflows accumulate.

Current Status (as of April 2026)

Based on publicly available information, the following can be confirmed:

The subscription coverage cutoff has been executed
OpenClaw has completed its primary model-path transition and continues iterating
Whether users perceive major changes depends on how strongly their workflows rely on any single model

What to Watch Next

Going forward, the more meaningful signals are not from this single event itself, but from three areas:

Whether boundaries between subscription plans and API usage become more explicit
The long-term performance of multi-model agents in stability, cost, and user experience
Whether user workflows settle primarily at the model layer, tool layer, or a hybrid layer between the two

Connect OpenClaw to Local Gemma 4: Complete Setup Guide

Wed, 08 Apr 2026 18:18:00 +0800

This guide shows how to connect OpenClaw to a local Gemma 4 model through Ollama.

If you have not deployed Gemma 4 locally yet, start here:

How to Run Gemma 4 on a Laptop: 5-Minute Local Setup Guide

Step 1: Start the Ollama API Service

Start Ollama first:

`1`	`ollama serve`

Then verify the API quickly with:

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "Hello"
}'

If you get a model response, your local API is ready.

Step 2: Configure OpenClaw to Use Ollama

The OpenClaw config file is usually located at:

`1`	`~/.openclaw/config.yaml`

Edit config.yaml and add a local model entry under models:

models:
  # Your existing model config...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

Step 3: Set Default Model (Optional)

If you want Gemma 4 as the default model:

`1`	`default_model: gemma4-local`

Step 4: Restart and Verify OpenClaw

Restart OpenClaw:

`1`	`openclaw restart`

List available models:

`1`	`openclaw models list`

Run a quick chat test:

`1`	`openclaw chat --model gemma4-local "Hello"`

If the chat returns normally, OpenClaw is successfully connected to local Gemma 4.

Common Troubleshooting

connection refused: make sure ollama serve is running.
Model not found: check model name with ollama list (for example gemma4:12b).
Timeout: increase timeout and test a smaller model first.

OpenClaw on KnightLi Blog

How OpenClaw Creator Peter Steinberger Sees AI Software Development: From OpenClaw to Closed-Loop Coding

AI coding is not a magic button

Why he is skeptical of calling it vibe coding

The loop is the key

More experience makes AI more useful

OpenClaw matters beyond the project itself

What this means for ordinary developers

Where AI software development is going

Summary

References

What Is Hermes Agent: Overview, Strengths, Getting Started, and How It Compares to OpenClaw

01 An overview of Hermes Agent

02 Where it stands out

1. It covers both CLI workflows and messaging workflows

2. It is designed for long-term use

3. MCP support gives it strong extensibility

4. It is friendly to OpenClaw users

03 How to get started quickly

04 How to think about it versus OpenClaw

What Hermes Agent feels like

What OpenClaw feels like

A more practical rule of thumb

05 Who should try it

References

OpenClaw Dreaming: Machines Start Dreaming While Humans Lose Sleep

01 A sleep-based pipeline for memory consolidation

02 A scoring system for deciding what deserves to stay

03 Why it reminds people of Claude’s “dreaming” approach

04 The most ironic part: machines dream, humans stay awake

OpenClaw and Agent Harness: Why It Looks Like AGI

Core Conclusion

What Is a Harness

Why OpenClaw Feels Different

Value and Boundaries

Anthropic and OpenClaw Timeline: The Full Sequence of Events

Background

Timeline (January to April 2026)

January 2026

February 2026

March 2026

April 4, 2026

April 5, 2026

Two Parallel Directions in the Process

Current Status (as of April 2026)

What to Watch Next

Connect OpenClaw to Local Gemma 4: Complete Setup Guide

Step 1: Start the Ollama API Service

Step 2: Configure OpenClaw to Use Ollama

Step 3: Set Default Model (Optional)

Step 4: Restart and Verify OpenClaw

Common Troubleshooting

Related Posts