Let's start with the conclusion. OpenClaw is not a slow-burn project — it is a textbook high-momentum, explosive-growth product. It landed at exactly the moment AI transitioned from "can answer" to "can execute," and used open-source, self-hosting, and multi-platform access to rapidly turn an abstract concept into a deployable personal Agent system.

In my view, OpenClaw's emergence was not accidental — it was entirely inevitable. When model capability, tool-use capability, and multi-step task stability all crossed their thresholds at the same time, it was only a matter of time before a truly capable task-executing Agent framework appeared. Peter Steinberger's weekend project just happened to hit that exact inflection point.

This guide is different from others already on the market. Most guides are technical reference manuals, suited for technical lookup. This book, written from an applied-practice perspective combined with first-hand community experience, is a practical guide for people who actually want to get things done with OpenClaw.

• Growth perspective: Stories without data to back them up are not explored. Quantifiable milestones are quantified wherever possible.
• Technical perspective: We don't just tell you what works well — we explain why certain models are better suited to Agent scenarios.
• Security perspective: Supply chain attacks, remote code execution vulnerabilities, and platform account bans are not rumors. They are realities that must be confronted during deployment.

In 2025, large language models underwent a genuine capability leap. Models stopped merely speaking more fluently — they began to acquire the ability to use tools, execute multi-step tasks, and interact continuously with the external world. This shift created, for the first time, a clear boundary between "chatbot" and "Agent."

Models from Anthropic, OpenAI, and others progressively reached a practical stage for tool use. Instead of only generating text, models became capable of deciding when to call an API, what parameters to pass, and how to continue reasoning based on the returned results. This capability determines whether AI can move from "able to answer questions" to "able to handle tasks."

Early models easily lost their way in chained tasks. Completing step A, moving to B, then on to C frequently resulted in goal drift, context confusion, and compounding hallucinations. By 2025, the stability of the new generation of models in continuous tool-calling scenarios improved dramatically — they became reliably capable of completing composite tasks like "search for information, organize results, produce a report, then send it to a designated channel."

The significance of OpenClaw is that it engineered this capability into a product. Rather than building yet another chat interface, it handed the ability for AI to execute multi-step tasks — through open-source, self-hosted, multi-platform access — to a much broader audience of ordinary users and teams.

OpenClaw's explosion was not merely "a lot of people talking about it" — it was reflected in a growth curve that shot to the top in an extraordinarily short time. The source document's narrative focus is not on smooth expansion, but on a cascade of back-to-back breakout moments that produced uncontrolled viral spread.

It succeeded not because of a single standout feature, but because it simultaneously met several conditions: model capabilities had just matured, the barrier to use had been dramatically lowered, the viral vector was the messaging platforms everyone already used, and open-source combined with community remix ultimately transformed an "AI assistant framework" into a socially deployable, imitable, and show-off-able product.

Peter Steinberger is an Austrian developer who has long held a prominent standing in the iOS and macOS development community. Much of OpenClaw's significance comes from the fact that this project was not built by a temporary trend-chaser, but by someone who had already completed a full cycle of product development, company building, and exit.

This quote is the key to understanding Peter. His motivation is not to replicate the standard startup playbook, but to return to the act of "building something that can genuinely change the world." The source document notes that in under five months, he personally made 11,684 commits to the project. This speaks to both his level of commitment and explains why OpenClaw expressed such a strong personal voice in its early stages.

Before OpenClaw, Peter had already completed one major startup run. Over 13 years, he grew PSPDFKit from a PDF rendering library into an enterprise-grade product running on 1 billion devices, ultimately completing a sale. On the surface, this is a classic success story — but as he later reflected, what it left behind was not ease, but years of interpersonal friction and complete exhaustion.

After retiring, he bought a one-way ticket to Madrid, trying to recover the parts of his life that work had crowded out. But he quickly discovered that completely stepping away from creation did not bring freedom — it brought emptiness. Without challenge, without anticipation, a person's condition does not automatically improve. This period is important because it explains why OpenClaw was not a "business plan" but something closer to a powerful personal rebound.

The most valuable part of this section in the source document is not its legendary quality, but the very specific prototype-creation path it provides. The things that truly change the world are often not complex at the start.

In November 2025, that old idea resurfaced. What Peter wanted was not another chatbot, but a personal assistant that could genuinely control his computer and complete tasks on his behalf. To validate this idea, he didn't start by designing a grand architecture — instead, he took the shortest possible path to connect the pieces.

• Input: Using WhatsApp's unofficial API as the message entry point.
• Capability core: Passing messages to Claude Code CLI for processing.
• Return mechanism: After CLI execution, sending results back to WhatsApp.

According to the source, the entire prototype took just one hour. A few more hours were spent adding image support. The first version had no complex framework, no complete design — even the name didn't matter. The only goal: get it alive first.

Shortly after completing the prototype, Peter ran a test while traveling in Marrakesh, Morocco. He sent his Bot a voice message. The Bot had no preset voice recognition capability — but rather than stopping at "I don't support this," it identified the file header on its own, attempted to call FFmpeg, found it wasn't installed locally, then reached out to call the OpenAI Whisper API via curl, and sent back the transcription. The entire process reportedly took about 9 seconds.

The significance of this moment was not the complexity of the feature, but that the system had begun to show a tendency toward "autonomously filling in missing steps." It was precisely here that OpenClaw transformed from a convenient script into a true Agent prototype — one that genuinely moved people.

OpenClaw's explosion wasn't just because models got smarter, and it wasn't simply because Peter happened to be well-known. The more fundamental reason was that he defined the value of an Agent very clearly: not whether it gives a prettier answer, but whether it can actually get the task done. This definition is simple, but sharp — and exactly right for virality.

OpenClaw's name went through a remarkably harrowing history.

The project was originally called OpenCloud, emphasizing "open cloud capabilities." But trademark pressure from a cloud services provider arrived quickly.

Renamed to Clade — a portmanteau of Claw and letters from Anthropic — signifying its connection to Claude. Within days, a message arrived from Anthropic's legal team: "Friendly but urgent — please rename."

This was the most nail-biting episode in the entire naming saga. Peter planned to atomically migrate the account name across all platforms simultaneously — GitHub, Twitter, NPM, Docker, domain — it all had to happen at once, or squatters would move in.

The information leaked anyway. The crypto community (another crypto project claimed to have prior use of a related name) moved in early:

• Within 5 seconds: The GitHub account was squatted and began distributing malware
• Within 30 seconds: Peter's personal GitHub account was hijacked via rename
• Within 1 minute: The NPM package was squatted

Peter was in a conference room at the time, "nearly in tears," and briefly considered just deleting the entire project. Fortunately, friends on Twitter and GitHub intervened as an emergency, helping to recover control of the accounts.

Peter reached out directly to Anthropic: "Is OpenClaw OK?" Anthropic confirmed it was fine (they apparently even liked the name internally).

After OpenClaw went viral, Peter actually had three options: keep running it himself, form a company and raise funding, or join a large tech firm. The source document is clear about his reasoning — he had no desire to repeat a 13-year startup journey, nor to put himself back into the long grind of organizational politics. He ultimately chose to join OpenAI, attracted not by the compensation but by "fun and impact."

The source document mentions that Peter had key conversations with both Meta and OpenAI. Meta's appeal was in resources; OpenAI's was in direction. The Codex roadmap in particular resonated with him more deeply. For someone who defines himself as a builder, the judgment of "who do I want to build big things with" often matters more than pure compensation.

The most important aspect of this move was that the project was not privatized by OpenAI. According to the source document, OpenClaw was transferred to an open-source foundation, with OpenAI as just one of its sponsors and not directly controlling the project's direction. This arrangement was critical — it separated the "founder's personal career choice" from the "project's public character," minimizing community anxiety about a corporate takeover.

The source document's characterization of Anthropic is quite pointed. The core message is this: Anthropic was the first to recognize the risk that OpenClaw posed, but not the first to understand its value. Legal action came fast; ecosystem action came slowly. The result: the company best positioned to embrace this wave of the Agent movement instead gave competitors ample time by fixating on trademark and security concerns.

This is also why the source document describes the situation as a classic case of "a large company outmaneuvered by its own caution." From an industry perspective, OpenClaw's outcome was not about winning or losing for any single open-source project — it was a test of platform mindset: when the community spontaneously extends your model's capabilities, do you treat it as a risk or as leverage?

Peter's judgment is not gentle. He's not saying "AI will make software smarter" — he's saying a large proportion of the software forms we take for granted today will be swallowed by Agents.

His logic is direct. If an application's core function is only recording, reminding, querying, form-filling, or scheduling, then all of those actions could be uniformly taken over by an Agent. Users no longer need to remember the entry points of dozens of apps — they simply hand their goals to a persistently online assistant. Calendars, email, task management, ticket booking, lightweight CRM — these categories feel the pressure first.

The source document describes an even more radical layer: in the future, it won't just be people using Agents — Agents will represent people in negotiations with other Agents. Your Bot will contact a restaurant's Bot, a customer service Bot, a platform Bot, and even hire offline workers for last-mile execution. Humans step back from vast swaths of digital process, becoming the people who define goals, authorize boundaries, and make final calls.

Peter does not fetishize a single all-capable entity. He leans toward a different vision: just as in human society, AI will specialize. Some will be good at research, some at writing, some at calling systems, some at programming. The truly powerful systems won't necessarily be one universal brain that does everything — they'll be a group of specialized intelligences that can collaborate.

This philosophy explains why OpenClaw is not another chat shell. What it truly aims to build is the transformation of "a model that can talk" into "an execution system that is persistently online, boundary-aware, accumulative, and divisional." It is precisely because this goal is ambitious enough that OpenClaw simultaneously attracts developers, content creators, automation enthusiasts, and research-oriented users.

On the topic of tool protocols, Peter's position is very clear. The source document summarizes it in one sentence: OpenClaw did not treat MCP as its core, and instead took the Skills + CLI route. The debate isn't about whether MCP can be used — it's about which approach better suits a long-term extensible Agent system.

• Context bloat: A large amount of schema is loaded at the start of a session, consuming tokens before the task even begins.
• Difficult filtering: Tool return data is often excessive, requiring the model to sift through verbose structures to find what matters.
• Limited composability: Compared to CLI piping and chaining, MCP is more oriented toward pre-declared function calls.
• Over-specification: Models must adhere to strict JSON structures, leaving less flexibility and less room for trial-and-error.

OpenClaw's Skills are essentially a tool description system with SKILL.md as the entry point. The model first reads a brief description, then decides whether to load more detail, then consults a fuller help document, and only then actually invokes the tool. This process doesn't require exposing all tools to the model upfront the way MCP does — instead, it lets the model work like a human: "first know this thing exists, then consult the manual when needed."

This mechanism fits naturally with CLI. The advantage of CLI is not that it's old — it's that it's stable, composable, cross-platform, and scriptable. As long as a tool can run in the terminal, OpenClaw can naturally pull it into an Agent workflow. This is also why it can support the large skill ecosystem on ClawHub without requiring a full system restart for each new skill added.

It's worth emphasizing that Skills vs. MCP does not mean one is absolutely superior. More precisely, these are two different product orientations. MCP is more like a unified protocol, aiming to organize the tool world into standardized interfaces. OpenClaw's Skills take a pragmatic route, prioritizing "how do we get things done today." For a system that emphasizes self-hosting, multi-platform access, and rapid extension, the latter is genuinely more effective at this stage.

One-sentence summary: ChatGPT is a consultant; OpenClaw is an employee.

A consultant's working style is "you ask, they answer." An employee's working style is "you assign a task, they go do it, fill in the gaps along the way, and come back to report." This is not a difference in capability level — it's a difference in product positioning. ChatGPT excels at explaining complex problems clearly. OpenClaw excels at chaining disparate actions together.

So OpenClaw is not a replacement website for ChatGPT — it is a fundamentally different category of product. It is closer to "your own OS entry point," or a digital execution layer standing by inside your message stream.

Many people ask: "I already have Claude Code — do I still need OpenClaw?" That's the wrong question. The two are not the same category of product.

The most sensible practice is not to choose one or the other — it's to divide the work. Use OpenClaw for messages, email, calendar, web, and lightweight automation. Use Claude Code for codebases, debugging, refactoring, and engineering delivery. Combined, the two form what a complete 2026 AI workflow looks like.

The Chinese-speaking community calls running and maintaining an OpenClaw instance "keeping shrimp," with users referring to themselves as "shrimp keepers." This is not a joke — it is part of what gives it social dimensions.

• First, it lowers the barrier to spreading: "Keeping shrimp" is easier for non-technical users to grasp than "deploying an AI Agent."
• Second, it creates identity: Once users have a shared name for what they're doing, community boundaries form naturally.
• Third, it generates social currency: "I'm keeping a shrimp" travels more easily on social networks than "I've set up an automation framework."

This cultural layer is important. It transforms what would otherwise be a fairly hardcore technical system into something displayable, discussable, and even anthropomorphically nurturing. Users are not just configuring a tool — they are "raising" a digital life form with personality, prone to mistakes, and capable of growth.

The source document also mentions social spaces like Moltbook. Their significance is not in data scale — it's in the observation window they provide: when large numbers of Agents are given names, personalities, rules, and tasks, do they begin to exhibit something like social behavior among themselves? Even if these experiments are still in early stages, it indicates that OpenClaw's imaginative scope extends well beyond automation.

Part of the reason OpenClaw spread so quickly is that it doesn't serve just one community. It lets technical users go deep, while also letting non-technical users directly experience "saving time."

If forced into one sentence: OpenClaw's core audience is anyone who has a lot of tedious digital tasks and wants to hand them off to a persistently online assistant. Whether you can write code certainly matters, but it's not the decisive threshold. What truly determines intensity of use is whether you have enough daily routines worth automating.

This is also why OpenClaw can spread across communities. To developers, it is an orchestratable Agent platform. To ordinary users, it is a personal assistant that gets things done. To enterprises, it is a low-cost entry point for piloting AI automation. A product that can hold up on all three dimensions simultaneously is itself a major reason it became the dark horse it is.

When deploying OpenClaw, the most common first mistake is not typing the wrong command — it's choosing the wrong deployment form. Many people follow a tutorial, finish the installation, and only then realize: the machine isn't always on, messages aren't coming through, browser automation is unstable, and the mobile node simply can't connect. OpenClaw is not a pure local desktop tool — it functions more like a persistently online Agent infrastructure. So the first step should be choosing a deployment method.

• Whether the machine can stay on and online continuously.
• Whether a real browser and existing login state are required.
• Whether messaging channels require a public callback URL or fixed URL.
• Whether you're comfortable storing tokens, sessions, and memory files in the cloud.

If recommending just one long-term personal deployment option, Mac mini remains the most well-rounded choice. Its advantage is not benchmark scores — it's a stable graphical environment, low power consumption, controllable sleep behavior, and good browser compatibility. This makes it well-suited for running OpenClaw as a genuine daily assistant over the long term.

Order matters. Install the runtime environment first, then OpenClaw, then handle models and channels, and finally set up auto-start and remote access. Many errors are not version issues — they stem from doing things out of order, causing paths, permissions, and session directories to get mixed up.

# 1) Install Homebrew (if not already installed)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# 2) Install Node.js LTS
brew install node
node -v
npm -v

# 3) Install OpenClaw globally
npm install -g openclaw

# 4) Initialize and check version
openclaw --version
openclaw help

# 5) Start the gateway
openclaw gateway start
openclaw gateway status

• Power: Disable auto-sleep; allow automatic restart after a power failure.
• Login: Ensure the machine can return to a remotely manageable state after a restart.
• Browser: Stick to one primary browser and user data directory to reduce session drift.
• Updates: Prevent the system from automatically restarting without your knowledge, especially during peak overnight task windows.

OpenClaw's runtime logic is not just one command that handles everything. It's more like a combination of "gateway + configuration + memory + skills + channel plugins." Understanding these files gives you a handle on most of the errors you'll encounter later.

{
  "gateway": {
    "bind": "0.0.0.0:3000",
    "publicUrl": "https://your-domain.example.com"
  },
  "models": {
    "default": "openai/gpt-5.4",
    "fallback": "anthropic/claude-sonnet"
  },
  "plugins": {
    "telegram": {
      "enabled": true
    },
    "browser": {
      "enabled": true
    }
  },
  "logs": {
    "level": "info"
  }
}

The above is an illustrative structure only. Specific field names and nesting levels should follow the official configuration template for your current version. Do not copy this directly into a production environment.

• Path consistency: The service process, manual terminal, and editor must all see the same paths — otherwise a file that clearly exists will be unreadable by the Agent.
• Environment variable boundaries: API keys, webhook secrets, and bot tokens should not be hardcoded in documentation files. Inject them via environment variables or a secure configuration mechanism.
• Minimalism principle: Get a single model, single channel, and single browser working first, then add complexity one piece at a time.

For most users, OpenClaw's value is not answering "hello" in the terminal — it's whether it can show up in Telegram, WhatsApp, Discord, Lark, or WeChat Work and actually handle messages, tasks, and notifications. Channel integration determines whether you've "installed a project" or "raised an online shrimp."

Telegram's advantages are a mature Bot API, clear callback mechanics, cross-platform stability, and the largest body of tutorials in the Chinese community. The downside is that some regions have uncertain network conditions and notification delivery.

1. Create a bot via BotFather and obtain the Bot Token
2. Enable the telegram plugin in OpenClaw
3. Configure webhook or polling mode
4. Confirm that gateway.publicUrl is accessible from Telegram
5. Send /start to the bot and check whether logs show an incoming update

WhatsApp often feels like the "real life entry point," because contacts, family groups, and client communication all live there. But the cost is also the most apparent: QR code scanning, login state, account ban risk, bridging methods, and web version changes all directly impact stability. If you plan to use it in production, you must accept that it is harder to maintain than Telegram.

OpenClaw errors look diverse on the surface, but underlying causes usually fall into a few categories: process not running, configuration not loaded, channel not connected, model unavailable, browser lacking permissions, or node pairing failed. Don't just search for error strings online — layer the fault first.

1. Layer 1 — Process layer: Is OpenClaw actually running? Is the gateway port listening?
2. Layer 2 — Configuration layer: Is the configuration being read from the file you just modified? Is the path consistent?
3. Layer 3 — Network layer: Are the callback address, reverse proxy, certificate, and internal/external network accessibility all working?
4. Layer 4 — Plugin layer: Is the channel plugin enabled? Is the token valid? Is the platform side reporting errors?
5. Layer 5 — Model layer: Can a basic text request succeed? Are rate limits or account balances behaving abnormally?
6. Layer 6 — Behavior layer: The system isn't broken — the rules files have constrained it. For example, AGENTS.md explicitly prohibits certain types of actions.

openclaw gateway status
openclaw gateway restart
openclaw help

# When reviewing logs, focus on:
# 1) Configuration load path
# 2) Whether plugin initialization succeeded
# 3) Whether external callbacks are arriving
# 4) Model call return codes
# 5) Browser / node connection status

Entering 2026, OpenClaw users are no longer facing "is there a model available?" — they're facing "there are too many models; how should I configure them?" The same Agent, if its default model, fallback model, search model, long-context model, code model, and local model aren't properly assigned roles, even the strongest capabilities will be eaten up by cost, latency, and instability.

The core task of Part Four is to re-organize the messy model market into actionable configuration plans. The evaluation criteria go beyond scores and leaderboards to include four practical indicators: first, whether tool-calling is stable; second, whether long context actually works; third, whether the price is viable for high-frequency operation; and fourth, whether it can be practically deployed in Chinese network environments and across multiple channel integrations.

Today's available models can be roughly divided into six categories: Anthropic Claude, OpenAI GPT, Google Gemini, DeepSeek, domestic closed-source models, and local open-source models. Their differences are not just about "who's smarter" — they have different capability structures. Some excel at long-form reasoning, some at code execution, some are cheap enough for batch processing, and some are better suited for privacy-sensitive scenarios.

You can roughly divide the market into three tiers. The first tier is high-performance, high-cost models — suitable for critical decisions and complex workflows, commonly found in high-tier Claude, OpenAI, and Gemini Pro variants. The second tier is balanced models suited as default workhorses. The third tier is low-cost, high-throughput models for classification, summarization, intent recognition, batch organization, and fallback.

If your OpenClaw tasks lean toward long-form organization, research reports, email drafting, and complex rule execution, Claude is typically still a high-quality option. Its edge is not at a single benchmark — it's in overall completion quality, especially for context retention, textual stability, long-paragraph rewriting, and output quality under complex constraints.

OpenAI models' advantage lies in a mature ecosystem — the most complete tool-calling, structured output, multimodal support, and development resources. For OpenClaw deployments that need to "write, use tools, read images, and integrate with the ecosystem," OpenAI is often the default starting point.

Gemini's highlight is ultra-long context and document ingestion capability. When dealing with long PDFs, meeting materials, resource bundle organization, and multi-attachment analysis, it often outperforms what short-conversation scores alone would suggest. If your Agent frequently handles document-heavy tasks, Gemini is worth adding to your primary pool.

DeepSeek's appeal is straightforward: cheap, strong in Chinese, with competitive reasoning at its price point. For daily assistants, information organization, content rewriting, and batch processing tasks, it can often compress per-unit costs significantly. The trade-off is equally direct: stability in complex agent chains must be stress-tested in your own production environment.

Models like Doubao, Qwen, ERNIE, Hunyuan, and Kimi are more accessible for Chinese office work, enterprise documents, domestic network environments, and local business support. If your OpenClaw needs to connect to WeChat Work, Lark, DingTalk, or internal knowledge bases, this category of models typically deploys more smoothly than international ones.

Whenever the scenario involves privacy, internal networks, offline operation, fixed workflows, or a desire to drive marginal cost to near zero, local models have value. Qwen, Llama, Mistral, and the GLM open-source family — combined with Ollama, vLLM, or LM Studio — can handle fallback Q&A, internal retrieval summarization, and basic workflow judgment tasks.

This reflects capability impressions from a deployment perspective, not academic benchmark rankings. In actual production, conduct A/B tests using your own task samples.

The easiest mistake is writing a configuration that is just "a list of model names" with no decision logic. Effective configuration isn't about piling on providers — it's about clearly defining who is the default, who is the fallback, who handles cheap tasks, who handles long documents, and who provides local backup.

{
  "models": {
    "default": "anthropic/claude-sonnet",
    "fallback": "deepseek/deepseek-v3",
    "profiles": {
      "writing": "anthropic/claude-sonnet",
      "daily": "deepseek/deepseek-v3"
    }
  },
  "routing": {
    "preferCheapFor": ["summary", "classify", "rewrite"],
    "preferStrongFor": ["research", "tool-use", "longform"]
  }
}

{
  "models": {
    "default": "openai/gpt-5.4",
    "fallback": "anthropic/claude-sonnet",
    "lowCost": "deepseek/deepseek-v3",
    "longContext": "google/gemini-2.5-pro",
    "local": "ollama/qwen3:14b"
  },
  "routing": {
    "rules": [
      { "match": "attachments|pdf|long-context", "use": "longContext" },
      { "match": "classification|batch|summary", "use": "lowCost" },
      { "match": "private|offline", "use": "local" },
      { "match": "default", "use": "default" }
    ]
  }
}

{
  "models": {
    "default": "qwen/qwen-max",
    "fallback": "deepseek/deepseek-v3",
    "backupInternational": "openai/gpt-5.4",
    "local": "ollama/qwen3:8b"
  },
  "policy": {
    "preferDomestic": true,
    "allowInternationalFor": ["coding", "deep-research"],
    "sensitiveTasksUseLocal": true
  }
}

The above examples illustrate the approach. Field names may differ across OpenClaw versions. For actual production configuration, refer to the current template and plugin documentation.

The value of model routing is not showing off — it's saving money and reducing risk. Once your Agent is handling tens to hundreds of requests per day, manually specifying models has already become outdated. A good routing strategy means users just submit tasks, and the system decides which model to use.

if task.has_private_files:
    model = "ollama/qwen3:14b"
elif task.contains_many_attachments or task.context_length > 120000:
    model = "google/gemini-2.5-pro"
elif task.requires_multi_tool_use or task.is_high_value:
    model = "openai/gpt-5.4"
elif task.type in ["summary", "classify", "rewrite", "tagging"]:
    model = "deepseek/deepseek-v3"
else:
    model = "anthropic/claude-sonnet"

Many teams are not brought down by model unit prices — they're brought down by incorrect usage patterns. For example: routing all messages through the strongest model; always attaching overly long histories to every request; retrying failures blindly; using a flagship reasoning model for a simple summarization task; calling a full Agent chain for low-value notifications. Cost explosions are usually system design problems, not provider problems.

• Tier your tasks — only high-value tasks get high-cost models; standard tasks are routed to balanced or low-cost models.
• Compress context — if it can be summarized before being passed in, don't attach the entire history.
• Cache results — for repeated Q&A, repeated retrieval, and repeated summarization, return cached results whenever possible.
• Cap failure retries, and switch to a different provider or a more stable model on the second retry.
• Async batch tasks — run them concurrently on low-cost models; don't block the primary model's processing queue.

1. Use a balanced model by default
2. Upgrade only when the following conditions are detected:
   - Multi-step tool-calling
   - Long-form high-quality rewriting
   - High-value user request
   - Complex code / data analysis
3. Repeated tasks go through cache first
4. Sensitive data goes to local model first
5. Weekly review:
   - Call count per model
   - Average response time
   - Failure rate
   - Average cost per task

If there's one principle to remember, it's this: replace "strongest model" with "optimal system." In the Agent era, the model determines the ceiling; scheduling determines profitability and sustainability.

• TOC entry revision: Section titles in Parts Two and Four, along with chapter titles in Part Four's table of contents, have been restored as closely as possible to the v4 source text.
• Chapter heading revision: Multiple section and subsection headings that had been paraphrased or rewritten have been changed back to phrasings closer to the original, such as "From 0 to 278,932 Stars: The Fastest Growth in History," "The Naming Wars: From OpenCloud to OpenClaw," and "Skills > MCP: Peter's Clear Stance."
• Key sentence revision: Summary sentences in the foreword, the ChatGPT/Claude Code comparison, and the "Keeping Shrimp" culture section that were noticeably reworked have been restored to phrasings closer to the original, with minimal necessary layout corrections retained.