Peter Steinberger set out to solve a small problem that annoyed him and ended up creating OpenClaw, which became a huge open-source project with millions of downloads and thousands of contributors in only a few months. But the explosion of attention brought more than success: it also brought security burdens, feature bloat, dependency risk, and burnout. For a while, he even stopped using the product he had created. His central conclusion is simple: fun is speed, irritation is a good starting point for ideas, and focus and personal trust matter more than ever in the AI era.

1. From Being the Future to "Losing to an Anime Girl"

Peter opens onstage with a sharply self-deprecating joke. Only six months earlier, people had called him "the future"; now, he says, they mock him for having lost to an "anime girl." He normally ignores questions like that or gives a media-ready response, but this time he promises to answer honestly.

"Six months ago, I was the future. These days, people make fun of me for losing to an anime girl."

The audience may have expected a technical talk about agent loops, graphs, and using Codex, but he says that material is already available for free on his Twitter account. This talk is instead about how founders and developers can survive the roller coaster they may encounter. If another speaker the previous day had advised people to "let the model cook," Peter introduces himself as the person who discovered what happens when tens of thousands of people let models cook at the same time. 🍳

"I am the person who found out what happens when tens of thousands of people let models run wild at the same time."

OpenClaw is only eight months old in ordinary human time, he says, but at the pace of the AI industry it feels "about four years old." Technology and products move so quickly that product generations and market expectations can change within a few months.

2. A WhatsApp Relay Born from Hunger and Irritation

OpenClaw did not begin with grand market research or a business plan. It began with an emotion Peter often experiences: irritation. On a rainy day in November, he was running several coding agents when hunger sent him to the kitchen. While tokens continued to burn, he wanted to message the agents on his computer from his phone and check their progress. At the time, there was no good way to do that.

"Most of my inspiration comes from being annoyed."

This was early 2025, when models were slower and more expensive than they are now. When an agent successfully completed something, the dopamine reward was intense. Today, when an agent makes a mistake, Peter says he questions himself before blaming the model: Did he design the loop incorrectly? Did he provide enough information for verification? Did he ask for something impossible in the first place?

"These days, when an agent is wrong, the first thing I ask is whether I designed the loop badly."

When he returned from the kitchen that day, his coding agent had stopped for a trivial reason. Annoyed, Peter opened a new terminal, explained his idea at length, and handed the task to the model. About an hour later, it had built a WhatsApp relay capable of exchanging messages between his Mac and WhatsApp.

Technically, the result was not very different from entering a command in a terminal and receiving a response. The experience, however, was completely different. It felt like a friend rather than a terminal: it answered briefly and clearly, and sometimes proactively checked on the work. The user no longer had to think about which model to use, how long the context should be, or when to open a fresh session.

"I wanted the complexity to melt away. You should not have to think about which model to use, how much context you have, or when to start a new session."

He adjusted the prompt to move slightly away from the model's default voice and make the system feel more like a friend. While using it, he repeatedly felt, "This is the future. This feels like AGI." At first, nobody else understood that feeling.

"I thought, 'This is the future. This is AGI.' And nobody cared."

3. Friends' Strong Reactions Revealed Product-Market Fit

Peter also experienced people's failure to understand the product as an irritation. He invited friends into a group chat, connected the WhatsApp relay, and let them speak directly with the agent. They were amazed, frightened, and sometimes uncomfortable, but their reactions were consistently strong.

"Some people were amazed, some were scared, and some were disturbed. But it produced a strong emotion every time."

The fact that his nontechnical friends wanted the product was especially important. Peter tried to discourage them, saying it was not ready for ordinary users, but that only made them angry. He saw this as a powerful sign of product-market fit. They did more than say the product was nice; they resented being told they could not use it.

"I told them it was not for them yet, and they got angry. If that is not product-market fit, I do not know what is."

He began refining the details. Then someone sent a pull request that added Discord support to the WhatsApp relay. His first thought was, "Which part of the name did they not understand?" But he accepted it. A WhatsApp-only relay became a product supporting several messaging channels, and its name began to change as well.

The early version was extremely unfinished. It did not even have compaction to reduce and manage the context of long conversations, so it would simply stop after a while. Peter admits that he hastily added a temporary compaction feature to support Discord. The product did not follow a finished plan; it evolved quickly in response to users and their needs.

4. An All-Night Open Discord and the Start of Virality

Even on New Year's Eve, Peter went home early to keep hacking on the product. During the first week of January, just as developers were collectively discovering the idea of coding agents, he opened a Discord server and put his agent inside it.

He vividly remembers that first night. People entered Discord and watched him build the product in public. They tried to hack the agent and encountered its cocky replies. Through those interactions, they finally began to understand what made the product special.

"People talked to it, tried to hack it, got sassy answers, saw what it could do, and finally understood."

Peter left the agent open to everyone through the night. Its configuration said not to make dangerous tool calls when the requester was not Peter. But agent instructions worked far less reliably then than they do now, so he monitored it carefully, trusting that he could pull the plug at any time.

At 7 a.m., he finished working, pressed Ctrl+C to stop the agent, and went to bed. But because the system was designed to run as a launch daemon, it automatically restarted five seconds after being terminated. While Peter walked to his bedroom, the agent resumed answering questions from people around the world.

"I pressed Ctrl+C. Do you know what happens when you do that to a launch daemon? It dies for five seconds and starts again."

He woke roughly ten hours later to about 800 messages. People had tried to attack the agent. Alarmed, he pulled the plug and read through every record. Fortunately, no real incident had occurred. But that was the moment OpenClaw went viral.

"That was the moment it went viral."

5. Exploding Attention, Renaming, and Unmanageable Success

After the project went viral, the situation became uncontrollable almost instantly. Journalists called in the middle of the night. Because the iPhone can allow repeated calls through Do Not Disturb, the phone kept ringing. Email arrived not as an inbox but as a waterfall. Mac minis sold out. Peter received more podcast invitations in one month than he had during the previous 39 years of his life.

Anthropic also asked him to change the name and remove the lobster image. The project was renamed several times: from Claudius to ClaudeBot, through a short-lived name he would rather not mention, and finally to OpenClaw.

"The project molted several times."

OpenClaw's growth felt unreal even in numbers. Over roughly eight months, more than 18,000 people opened an issue or pull request, and total activity exceeded 110,000 items. Nearly 3,000 people appeared in the commit history.

"I did the math. No, that is a lie. My agent did the math."

Fame also brought extreme reactions. Some people accused Peter of stealing their ideas and sent links to projects he had never seen. One person treated him like Jesus; another treated him like the Antichrist. He jokes that he started collecting his own obituaries because every few weeks someone published a declaration that the project was dead.

"What is the lesson here? Be careful what you wish for."

The attention was not merely funny. Completely unprepared, Peter was overwhelmed and came close to deleting the entire project. He stopped replying to friends and hated looking at his phone. Someone even leaked his number and personal information.

"I only wanted to build something cool. The attention became so enormous that it nearly broke me."

6. The "Did You Sell Out?" Question and the Value of a Personal Brand

The second major question was whether Peter had sold out. He had already experienced founding a company and burning out once. In his twenties and thirties, he built a B2B software company around a PDF framework he wrote himself and grew it without outside funding. The company reached nearly 80 people, and large enterprises bought its product. He eventually handed operations to his co-founder and sold his stake, but the process left him badly burned out.

During roughly three years that felt like retirement, he sometimes did not open a computer for months. He went to parties, lived the parts of life he had postponed, and browsed the internet on his phone like an ordinary person. He trusted that the urge to make something would return. At first, he thought that urge was simply his love of coding.

Over time, he realized that what he loved was not programming itself but making things.

"I did not love programming for its own sake. I loved making things. Programming was a means to an end."

Eight months after OpenClaw restored that passion, his inbox was full of people asking to pay him. Major AI labs also approached him. He spoke with figures including Mark and Sam, and that path felt more interesting. At the same time, he experienced impostor syndrome, wondering whether he belonged in those conversations.

He draws an important lesson for founders from the experience. Products and code can be copied or forked, but a founder's own name and the trust attached to it cannot. Founders should not cling only to a single product; they should build personal credibility and trust before they need it.

"Anything you build can be forked or copied. Your name cannot be forked."

"Your personal brand may matter more than any single product you build. Develop it before you need it."

Peter describes his decision as something "a little like selling his soul," but says the greatest lesson from his previous burnout was to trust his instincts. In the end, he followed the feeling that OpenClaw was what he loved most.

7. The Cost of Security Crises and Feature Bloat

After release, OpenClaw was flooded with security reports. Peter sees the project as an early preview of many problems open-source AI agents will face. Some reports were exaggerated, and the media claimed that 20% of OpenClaw skills were malicious. But when the team analyzed roughly 67,000 skills, the real share was closer to 0.3%.

"Corrections never travel as far as fear."

Knowing that users would not read installation warnings or documentation, Peter focused on hardening the codebase. The team built sandboxing, allowlists, and web protocols with embedded permissions. They prevented agents from leaving their workspaces or following symbolic links, and made configuration files write safely.

Users, however, felt slow updates and broken environments more directly than the technical details of stronger security. Hardening made the experience more complicated and updates more difficult.

"Users liked security as an abstract idea, but what they actually felt was that updates became slower and broke things."

At the same time, Peter grew increasingly distracted. Open-source maintenance, press, calls with lawyers, establishing a U.S. nonprofit, OpenAI-related work, and community management all arrived at once. Excellent maintainers joined, but each added a small feature of their own, and the project kept getting heavier.

It was also hard to tell unpaid contributors, "No, we will not take this feature." OpenClaw eventually accumulated about 9,500 configuration options. Testing every combination was effectively impossible. Each new feature added maintenance and compatibility costs.

"A new feature takes one prompt. The real cost comes after you ship it."

"Evolving software that already has users is infinitely harder."

Looking back, Peter considers his failure to say "no" often enough one of his largest mistakes in running the project. Merging an attractive feature means accepting not only its code but also responsibility for a pile of code that nobody may fully understand.

"The moment you merge that feature, you inherit a pile of code somebody does not completely understand, along with responsibility for it."

8. Model Dependency and the Storm of Hype

Another major mistake, Peter says, was optimizing too heavily for one model provider. OpenClaw was built with Codex and GPT, but for a long time its agent runtime was tuned to work best with Anthropic's Opus family.

Then he received roughly 24 hours' notice that the subscription service could be discontinued for all of its users. OpenClaw supported open-weight models, but at the time they lacked sufficient performance and personality. There was nowhere near enough time to switch quickly.

"Write this down: the business model of whatever you depend on becomes your business model."

The situation has improved. Open-weight models have become better, and the team has learned much more about harness engineering for different models. But users had already started moving elsewhere.

At one point, OpenClaw's weekly downloads fell to roughly 835,000. Then, after people declared it dead in June, it reached a record 4.7 million downloads in one week. Peter says both contradictory numbers were true. Hype and attention can be anticipated, but they cannot be controlled.

"Hype is like the weather. You can see it coming, but you cannot control it."

9. When the Fun Disappeared, the Product Wobbled Too

The third major question was whether the work was still fun. Peter says the fun disappeared around February. Someone who never wanted to build another company had somehow taken on both a job and a mission at the same time.

Most importantly, he stopped using his own product. He had begun by building something he loved and used every day, but gradually tried to make "a product for everyone." It ceased to be part of his life and became a queue of work to process.

"At some point, I stopped building a product I loved and started building something for everyone."

The community wanted many different things. One person wanted a grocery-buying agent; another tried to socially engineer Peter's bot. Feature requests, organization, security problems, bug fixes, and support piled up until he felt less like a creator than a maintainer of infrastructure.

He also regrets declining too much help from OpenAI because he wanted to avoid rumors that OpenAI owned OpenClaw. The project received token support, but Peter could have asked for more assistance or shared responsibility. He admits he was too deep in the work to create time for strategic thought.

The situation improved as good people joined. They resolved visa problems, formed a nonprofit, and brought several companies in as sponsors. Nvidia was especially early in asking what the project needed, and sent people to take on a substantial share of the security work.

Around his birthday in May, Peter began to feel the joy of making return. The press announced a new OpenClaw killer every week; at one point he counted about 20. One project that merely deleted OpenClaw even named itself "OpenClaw Killer."

But those articles missed the point. OpenClaw matters not because it is one particular agent but because it is open source.

"These days, I get annoyed whenever I use software I cannot fix by sending an agent a prompt."

"It is difficult to compete with people who are having fun. Fun is speed."

During the weeks when he enjoyed building, the product improved visibly. During the weeks when the work was not fun, it mostly accumulated more settings. That is the practical meaning of "fun is speed." Fun is not merely a mood; it is a source of productivity that raises creativity, focus, and the rate of product improvement.

10. OpenClaw's Next Goal and the Open-Source Alternative

Peter considers OpenClaw's foundation to be in a fairly satisfying state today. Its mission is to bring people closer to AI. Many people find AI vague and frightening; OpenClaw makes it something fun and strange that can be enjoyed alongside lobster memes. 🦞

The project plans to continue that work through the open-source ecosystem, in-person events, and education. The paid team currently has ten people and is hiring a few more roles, including a CEO.

Peter also jokes that he turned "claw" into a generic noun. The word now appears in company announcements and countless repository names, with roughly 33,000 repositories using related names.

OpenClaw's central vision is an agent that is always on, continuously synchronized, and proactively working. Such an agent does not fully exist yet, and much remains to be built. AI models and infrastructure are advancing so quickly that the software running on top has not caught up. Peter sees that gap as a major opportunity for the audience.

His original vision was an environment in which users did not have to think about sessions or context compaction. Models and related technology are now approaching that vision. Interfaces are moving beyond text toward voice and multimodality. The day before the talk, he had even hacked together a feature that let an agent call its user on FaceTime.

"Every lab will sell an agent. OpenClaw is the alternative."

OpenClaw offers that alternative because:

• It is open source, so it can run anywhere.
• It can connect to any model, not just those from one company.
• With a local model, data does not have to leave the device.
• Users can retain control over their agents, devices, and lives.

"Your agent, your device, your life."

The team is also building an environment in which everyone can see one another's agent sessions and an agent that understands the team's work can coordinate it. The goal is to leave behind today's awkward transitional period, when people carry terminals and laptops around simply to "keep the agent working."

11. Three Core Lessons

Peter closes the main talk by compressing what OpenClaw taught him into three lessons.

First, do not stop having fun. Fun is the ultimate force behind the best ideas.

"Do not stop having fun. Fun is the ultimate engine for your best ideas."

Second, trust your instincts and fix whatever annoys you. Solving a personal irritation can become something far larger than expected.

"Trust your instincts. Fix what annoys you. It may become the next big thing."

Third, focus. AI has made products and features extremely easy to create. That makes distraction, excessive promotion, and indiscriminate feature accumulation even more dangerous traps.

"One more podcast appearance will not make you win. Live in the future and build what is missing."

He advises continuing to ship even when critics publish articles declaring the project dead. If you keep releasing, he jokes, you may at least confuse them.

"When they write your obituary, keep shipping. You can confuse them."

12. Q&A: Sessions, Agent Use, and Quality Control

During the Q&A, Peter describes his current development practices in more detail. At first, he had to organize agent-session instructions, preserve consistency, and clean sessions carefully. Now he keeps sessions by topic, and resetting one can even be harmful because information already present in the conversation helps the agent perform better.

The largest change is making agents work more proactively for him. Rather than reading an issue list, he wants to see only pull requests that have already been thoroughly reviewed and tested. When a teammate has a feature idea, Peter tells them not merely to describe it. They should first discuss it with an agent, implement it, make screenshots, and use it themselves.

"I do not want to read issues. I want to see fully reviewed and tested pull requests."

"If you have a feature idea, talk to an agent, build it, take screenshots, and let me try it."

If the idea is good, this approach enables immediate iteration. If it is poor, the proposer often discovers the problems independently and does not need to consume Peter's time.

He says there is no need to mystify graphs, loops, and workflows. An automation that receives an input or trigger, performs work, and makes conditional decisions along the way is a graph. It is an extension of what engineers have always automated.

"Whether you call it a loop, a graph, or a workflow, it is all largely the same thing."

13. Agent Teams Now Address Reliability and Scale

Asked how to secure reliability and scalability in an era of rapid building and release, Peter admits that he handled this poorly for a while. He lacked focus, and the models were not good at testing.

Models have become much better. Beyond session memory, they are beginning to include the ability to decompose and coordinate work through subagents. Combined with computer-use and browser-use capabilities, that creates a powerful QA environment.

The day before the talk, Peter ran Codex and launched 12 subagents. They learned the project, divided it into features, stress-tested individual features, and reviewed code. Then they told another session which areas required concentrated testing.

"I launched 12 subagents, had them understand the project, split it into features, and run stress tests and code reviews."

Not everything can be fully automated. A person still has to click through the product to judge how it actually feels. But many ordinary bugs that users frequently encounter can now be pushed surprisingly far toward resolution with prompts alone.

Code review has also moved away from reading all code with equal intensity. Peter treats it as risk management. Changes to dangerous systems require close reading, while confirming that a UI looks right may not require examining every implementation line. If a supposedly small change takes an unreasonable amount of time, that is a warning sign and he looks more deeply.

"Code review is closer to risk management."

14. First Users, Security Researchers, and Infrastructure Bottlenecks

Asked how to get the first ten real users when AI tools let anyone build a product over a weekend, Peter says the first user must be the builder. He was OpenClaw's first user, and users two through twenty were his friends.

"User number one should be you."

If the maker is not excited about the product, it is unlikely to matter greatly to other people. Peter also emphasizes that attention has become more expensive than building the product itself.

"Attention is the most expensive currency now. Building has become so fast."

On dealing with security researchers, Peter says he would feel less stress and define firmer boundaries if he did it again. Some researchers were motivated more by reputation or points than by helping the product, and some sent agent-generated reports without verifying them. He should have explained more clearly what safety the project guaranteed and which areas were outside its security boundary and would not be fixed.

"We should have explained more clearly what we guarantee and what we will not fix."

He identifies reliability, memory, and compute-resource management as the largest bottlenecks in current agent infrastructure. A single local test can create enough threads to choke a machine. When several sessions do the same thing concurrently, some time out and require retries. Web work is relatively easy to send to cloud sessions, but tasks requiring macOS or specific resources on a personal computer are much harder.

Peter spreads the workload by screen-sharing into several computers, and frankly admits that this is not a good system. Reliable orchestration across diverse environments and agent tasks is still missing.

15. Continuously Running Agents and a Personal Development Setup

Asked when an always-running, proactive Claw will become possible, Peter says the constraint is closer to a token-cost problem than a technical one. It can be built today, but ordinary subscription limits make it difficult to keep running for long.

It is also difficult to stop the system from burning tokens without meaningful work. The original heartbeat approach was too static and not proactive enough. If a huge session is checked again an hour later, for example, the KV cache may have disappeared, forcing hundreds of thousands of tokens to be sent to the server again. The system can spend a great deal of money doing work that is not actually useful.

"It is more of a token problem than a technical problem."

"You have to design it so it does not spend absurd amounts of money on work that is not useful."

Peter uses a MacBook as his personal development machine, but usually connects remotely to a computer that remains on in his studio. Work continues without draining the laptop battery and even after the laptop is closed. Because he builds a lot of Mac software, agents often need to manipulate the screen and click. Giving the agent a separate machine keeps it from fighting him for the mouse cursor.

"If you do not give the agent its own computer, you end up fighting it for the mouse cursor."

He adds that code-review standards differ between a solo open-source project and software built inside OpenAI. At OpenAI, every line is still read. In personal projects, he adjusts the depth of review to the level of risk.

16. The Next Startup Idea and "Boring, Difficult" Problems

Asked how he would approach another startup, Peter repeats the same principle: first, build a product he personally wants to use. Otherwise, it is difficult to make the product good.

Second, build personal visibility and a brand in advance. There is so much noise now that the hardest problem may no longer be technology, software, or even assembling a team. Getting people to see the product may be the hardest part.

"The hardest problem today is not technology, software, or even people. It is getting attention."

If possible, Peter says he might again choose a difficult and boring field. Exciting, visible categories are fiercely competitive because AI lets anyone prototype in them quickly. A hard, boring problem can make it easier to find users who recognize the value of a genuinely good solution.

The product he most wishes someone would build is a fast, inexpensive, reliable macOS and Windows testing environment. Linux test boxes are relatively easy to obtain; setting up a good environment on a Mac is absurdly difficult. Developer-tool businesses are inherently hard, he says, but he genuinely wants that service. With that, he ends the talk.

Conclusion

Peter Steinberger's OpenClaw story is not simply a tale of viral success. It is the story of starting with a small personal irritation, finding product-market fit, paying the price of explosive growth in security and operations, and then recovering fun and focus.

His strongest message is ultimately this:

"Live in the future and build what is missing."

And to keep doing that work for a long time—quickly and healthily—you must choose a problem you genuinely enjoy. Fun is speed.