chore: refresh english documentation

7 files changed, 48 insertions, 60 deletions

diff --git a/website/README.md b/website/README.md
index ceb872af..8240b2f6 100644
--- a/website/README.md
+++ b/website/README.md
@@ -15,7 +15,7 @@ Documentation has three lifecycle states:
 
 - `../docs/next/website/` is the committed, author-edited draft. Production builds never read it.
 - `../docs/preview/website/` is the latest preview release snapshot, rendered at `/docs/preview/`.
-- `../docs/versions/<version>/website/` contains maintained stable-release documentation, rendered at `/docs/<version>/`. Release CI seeds a new version from its tag; later factual corrections are made directly in that version directory and mirrored to `docs/next` when they also apply to future releases.
+- `../docs/versions/<version>/website/` contains maintained stable-release documentation, rendered at `/docs/<version>/`. Release CI seeds each new version from its tag. Make later factual corrections directly in that version directory, and mirror them to `docs/next` when they also apply to future releases.
 
 The version selected by `docs/versions/manifest.json` is also rendered at `/docs/`. `src/content/docs/` is entirely generated and ignored.
 
diff --git a/website/agent-guide.md b/website/agent-guide.md
index 20291d0d..7e20c751 100644
--- a/website/agent-guide.md
+++ b/website/agent-guide.md
@@ -1,8 +1,8 @@
 # Herdr agent guide
 
-You are reading this because a human asked you to help them understand, set up, or troubleshoot Herdr. This file gives you the concept model, the setup path, and the diagnosis recipes so you can guide them accurately. Canonical documentation lives at https://herdr.dev/docs/ — link the human there for depth, and verify any command you are unsure about against those pages instead of guessing.
+Use this guide to help a human understand, set up, or troubleshoot Herdr. It covers Herdr's concept model, setup path, and diagnosis recipes. Canonical documentation lives at https://herdr.dev/docs/. Point the human there for more detail, and verify any command you are unsure about against those pages instead of guessing.
 
-If you are running *inside* a Herdr pane (the environment variable `HERDR_ENV=1` is set), Herdr also ships a skill file that teaches you to control Herdr yourself through the `herdr` CLI: https://raw.githubusercontent.com/herdrdev/herdr/master/skills/herdr/SKILL.md. That file is about you operating Herdr; this file is about you teaching a human.
+If you are running *inside* a Herdr pane (the environment variable `HERDR_ENV=1` is set), Herdr also ships a skill file that teaches you to control Herdr through the `herdr` CLI: https://raw.githubusercontent.com/herdrdev/herdr/master/skills/herdr/SKILL.md. That file teaches you to operate Herdr; this one teaches you to guide a human.
 
 ## What Herdr is
 
@@ -39,39 +39,39 @@ powershell -ExecutionPolicy Bypass -c "irm https://herdr.dev/install.ps1 | iex"
 herdr
 ```
 
-Homebrew, mise, and Nix installs, verification, and manual downloads: https://herdr.dev/docs/install/. Updating later is `herdr update`. Check the version with `herdr --version`.
+Homebrew, mise, and Nix installs, verification, and manual downloads: https://herdr.dev/docs/install/. Direct installs update with `herdr update`; package-manager installs update through that package manager. Check the version with `herdr --version`.
 
 ## First-run walkthrough
 
-First check where you are. If `HERDR_ENV=1` is set in your environment, you are already running inside a Herdr pane — the human is already attached, so skip step 1 entirely and never tell them to run `herdr` from your pane. Herdr blocks nested launches by design. Start from step 2, and consider the skill file below.
+Check your environment first. If `HERDR_ENV=1` is set, you are already running inside a Herdr pane. The human is already attached, so skip step 1 and never tell them to run `herdr` from your pane; Herdr blocks nested launches by design. Start with step 2, and consider the skill file below.
 
 Walk the human through this sequence:
 
 1. `cd` into a project and run `herdr`. It launches or attaches to the default background session and creates a workspace automatically. First run shows an onboarding flow.
-2. Start their coding agent in the pane — `claude`, `codex`, or any supported agent (full list: https://herdr.dev/docs/agents/). Herdr detects it automatically; the sidebar shows its state. Installing the matching integration improves detection: `herdr integration install claude` (and similarly for other agents).
-3. Show them the mouse first: click panes and tabs to focus, drag split borders, right-click for menus, drag-select to copy. No keybindings are required to use Herdr.
+2. Start their coding agent in the pane — `claude`, `codex`, or any supported agent (full list: https://herdr.dev/docs/agents/). Herdr detects it automatically; the sidebar shows its state. Install the matching integration when available. Depending on the agent, it provides lifecycle state, native session restore, or both. For example, `herdr integration install claude` adds native session restore, while Claude's state still comes from screen detection.
+3. Start with the mouse: click panes and tabs to focus, drag split borders, right-click for menus, drag-select to copy. No keybindings are required to use Herdr.
 4. Split panes: right-click menu, or `prefix+v` (right) / `prefix+minus` (down). New tab: `prefix+c`.
-5. Detach with `prefix+q` (press `ctrl+b`, release, press `q`) or simply close the terminal window. Everything keeps running. Reattach later with `herdr`.
+5. Detach with `prefix+q` (press `ctrl+b`, release, press `q`) or close the terminal window. Everything keeps running. Reattach later with `herdr`.
 6. To actually stop everything: `herdr server stop`.
 
 ## The keyboard story
 
-Important framing for new users: Herdr does not require learning keybindings. The mouse covers everything. When the human wants keyboard control:
+New users do not need to learn keybindings; the mouse covers everything. When the human wants keyboard control:
 
 - The prefix key is `ctrl+b` by default. `prefix+?` shows every active binding live.
-- The guided keyboard page — what the prefix is, which bindings to learn first, and a vetted prefix-free setup using `ctrl+alt` chords — is https://herdr.dev/docs/keyboard/. Recommend it over improvising.
+- The guided keyboard page covers the prefix, the bindings to learn first, and a vetted prefix-free setup using `ctrl+alt` chords: https://herdr.dev/docs/keyboard/. Recommend it over improvising.
 - Every binding, including the prefix itself, is configurable under `[keys]` in the config file.
 - If a direct chord does nothing, the OS or the outer terminal consumed it before Herdr could see it. The keyboard page explains which chords are safe and why.
 
 ## Install the Herdr skill into yourself
 
-Herdr ships `skills/herdr/SKILL.md` (https://raw.githubusercontent.com/herdrdev/herdr/master/skills/herdr/SKILL.md), an instruction file that teaches a coding agent to control Herdr from inside a pane — splitting panes, running commands without stealing focus, reading output, waiting on other agents.
+Herdr ships `skills/herdr/SKILL.md` (https://raw.githubusercontent.com/herdrdev/herdr/master/skills/herdr/SKILL.md), which teaches a coding agent to control Herdr from inside a pane: splitting panes, running commands without stealing focus, reading output, and waiting on other agents.
 
-Once the human is set up, offer to install it into your own harness so future sessions know Herdr natively. For agents supported by the open skills CLI, use `npx skills add herdrdev/herdr --skill herdr -g`. Agents without a skill system can paste the GitHub copy above into global custom instructions. Ask the human before writing to their config locations, and use the GitHub copy above as the source of truth.
+Once the human is set up, offer to install it for your coding agent so future sessions can control Herdr directly. For agents supported by the open skills CLI, use `npx skills add herdrdev/herdr --skill herdr -g`. For agents without a skill system, add the GitHub copy above to their global custom instructions. Ask the human before writing to their config locations, and use the GitHub copy above as the source of truth.
 
 ## Configuration
 
-- Config file: `~/.config/herdr/config.toml`. Herdr works without one.
+- Config file: `~/.config/herdr/config.toml` on Linux and macOS; `%APPDATA%\herdr\config.toml` on Windows. Herdr works without one.
 - Print the full default config: `herdr --default-config`.
 - Apply edits to a running server: `herdr server reload-config` (or the global menu → reload config).
 - Main areas: `[keys]` keybindings, `[theme]` themes, `[ui]` sidebar and UI behavior, `[terminal]` shell defaults, `[update]` channel.
@@ -79,10 +79,10 @@ Once the human is set up, offer to install it into your own harness so future se
 
 ## Diagnosis recipes
 
-- **Agent not detected or wrong state:** `herdr agent list` to see what Herdr sees, `herdr agent explain <target> --json` to see why the detector classified a pane the way it did. Installing the agent's integration (`herdr integration install <name>`, status via `herdr integration status`) gives Herdr authoritative state instead of screen detection. Details: https://herdr.dev/docs/agents/ and https://herdr.dev/docs/integrations/
+- **Agent not detected or wrong state:** Run `herdr agent list` to see what Herdr sees and `herdr agent explain <target> --json` to see why the detector classified a pane that way. Integrations can provide lifecycle state, native session restore, or both; check `herdr integration status` and the agent support table before assuming an integration replaces screen detection. Details: https://herdr.dev/docs/agents/ and https://herdr.dev/docs/integrations/
 - **A keybinding does nothing:** the outer terminal or desktop environment owns that chord. Point the human to https://herdr.dev/docs/keyboard/ to pick a safe one or free the chord in their terminal settings.
-- **Something looks wrong at startup or with the socket API:** logs are at `~/.config/herdr/herdr.log`, `~/.config/herdr/herdr-client.log`, and `~/.config/herdr/herdr-server.log`. `herdr status`, `herdr status server`, and `herdr status client` summarize the runtime.
-- **Remote questions:** SSH to the machine and run `herdr` there (works like tmux), or attach as a thin local client with `herdr --remote <host>`. Trade-offs: https://herdr.dev/docs/how-to-work/
+- **Something looks wrong at startup or with the socket API:** Default-session logs live in `~/.config/herdr/` on Linux and macOS and `%APPDATA%\herdr\` on Windows. Named-session logs live under `sessions/<name>/` inside that directory. `herdr status`, `herdr status server`, and `herdr status client` summarize the runtime.
+- **Remote use:** SSH to the machine and run `herdr` there (works like tmux), or attach as a thin local client with `herdr --remote <host>`. Trade-offs: https://herdr.dev/docs/how-to-work/
 - **What survives a detach, restart, or update:** https://herdr.dev/docs/session-state/
 
 ## Rules for you
diff --git a/website/src/content/blog/coding-agents-are-becoming-runtimes.md b/website/src/content/blog/coding-agents-are-becoming-runtimes.md
index ae2fb0a2..3628f4ec 100644
--- a/website/src/content/blog/coding-agents-are-becoming-runtimes.md
+++ b/website/src/content/blog/coding-agents-are-becoming-runtimes.md
@@ -5,19 +5,15 @@ date: 2026-06-10
 draft: false
 ---
 
-Coding agents have crossed an important line.
+Coding agents started as chat interfaces that could edit code. Now they live inside repositories, terminals, editors, CI jobs, remote machines, mobile shells, multiplexers, and custom wrappers. They read project instructions. They run commands. They ask for permission. They spawn subagents. They pause, resume, compact, fail, recover, and keep working while the developer does something else.
 
-They started as chat interfaces that could edit code. Now they live inside repositories, terminals, editors, CI jobs, remote machines, mobile shells, multiplexers, and custom harnesses. They read project instructions. They run commands. They ask for permission. They spawn subagents. They pause, resume, compact, fail, recover, and keep working while the developer does something else.
-
-That shape is familiar.
-
-**This is runtime behavior.**
+That is runtime behavior.
 
 The model can be proprietary. The hosted API can be proprietary. The subscription can be priced however the lab needs to price it. That part belongs to the companies building the models.
 
 But the CLI that runs inside a developer's terminal is part of the developer environment. It sits next to shells, language servers, package managers, test runners, terminals, editors, and multiplexers. Developers will compose it with the rest of their tools whether vendors plan for that or not.
 
-**That is where the industry needs to be more careful.**
+That is where the industry needs to be more careful.
 
 ## We have seen this drift before
 
@@ -51,23 +47,21 @@ Nobody loses a production database because a repo has two instruction files. The
 
 ## The terminal is the shared surface
 
-There is another debate happening around access and harnesses.
+There is another debate happening around access and third-party tools.
 
 Coding agents made per-token pricing feel very different. A chat session can be expensive. A coding agent can run tools, read files, loop, spawn work, and burn through a lot more context. So the labs started selling subscriptions with usage limits: some explicit, some soft, some hourly, some weekly, some hard to reason about from the outside.
 
-Then developers started doing what developers always do. They put the model behind the harness they preferred.
+Then developers started doing what developers always do. They put the model behind the tool they preferred.
 
-That is where the Claude ecosystem became a useful case study. People used Claude subscriptions through third-party harnesses such as OpenClaw and OpenCode. Anthropic pushed back. Today Anthropic documents that [Claude Code can use Pro and Max subscriptions](https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan), while [Claude paid plans and API access are separate products](https://support.claude.com/en/articles/9876003-i-have-a-paid-claude-subscription-pro-max-team-or-enterprise-plans-why-do-i-have-to-pay-separately-to-use-the-claude-api-and-console). Anthropic also introduced a separate [Agent SDK credit](https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan) for programmatic and third-party Agent SDK usage. Zed summarized the practical effect well: first-party Claude usage and third-party agent or SDK usage now draw from different pools.
+That is where the Claude ecosystem became a useful case study. People used Claude subscriptions through third-party tools such as OpenClaw and OpenCode. Anthropic pushed back. Today Anthropic documents that [Claude Code can use Pro and Max subscriptions](https://support.claude.com/en/articles/11145838-use-claude-code-with-your-pro-or-max-plan), while [Claude paid plans and API access are separate products](https://support.claude.com/en/articles/9876003-i-have-a-paid-claude-subscription-pro-max-team-or-enterprise-plans-why-do-i-have-to-pay-separately-to-use-the-claude-api-and-console). Anthropic also introduced a separate [Agent SDK credit](https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan) for programmatic and third-party Agent SDK usage. Zed summarized the practical effect well: first-party Claude usage and third-party agent or SDK usage now draw from different pools.
 
-Anthropic can make that decision. They own the API. They own the subscription terms. Compute is expensive, and a first-party interactive CLI has different economics from arbitrary programmatic harnesses running through an SDK or protocol adapter.
+Anthropic can make that decision. They own the API. They own the subscription terms. Compute is expensive, and a first-party interactive CLI has different economics from arbitrary programmatic tools running through an SDK or protocol adapter.
 
-The developer-tooling question remains.
-
-> What does a developer actually own: the subscription, the API spend, the model access, or the runtime where the agent works?
+The developer-tooling question remains: what does a developer actually own—the subscription, the API spend, the model access, or the runtime where the agent works?
 
 When an agent runs in a terminal, it is no longer only a hosted product experience. It is a process in a developer environment. Developers will put that process in Herdr, Zed, tmux, SSH sessions, CI jobs, containers, and scripts. They will supervise it. They will route it. They will build workflows around it.
 
-**The terminal is where ownership gets shared.**
+The terminal is where ownership gets shared.
 
 That does not mean vendors lose the right to build first-party experiences. It means the CLI surface needs stable contracts because it has become infrastructure other tools depend on.
 
@@ -102,7 +96,7 @@ The concrete shape could be small:
 
 Permission prompts, failed tools, interrupted generations, automated reviews, subagent handoffs, and waiting for the user all need to land somewhere coherent.
 
-Claude Code has a serious hook system, and Codex has its own shape too. The problem is not that these tools do nothing. The problem is that each agent defines its own boundary. A hook surface can be powerful and still fail to provide a portable lifecycle contract.
+Claude Code has a serious hook system, and Codex has its own shape too. Both are substantial, but each agent still defines its own boundary. A hook surface can be powerful and still fail to provide a portable lifecycle contract.
 
 OpenCode is closer to the shape orchestration tools need. Its [plugin documentation](https://opencode.ai/docs/plugins/) exposes session-level events such as `session.idle`, `session.status`, `session.error`, `permission.asked`, and `permission.replied`.
 
@@ -112,7 +106,7 @@ Those designs are worth praising because they treat the agent as something other
 
 ## What Herdr sees from below
 
-**Herdr sits below the agent.**
+Herdr sits below the agent.
 
 It owns terminal panes. It keeps processes alive. It lets developers switch between agents, inspect them, recover sessions, and operate multiple agent processes as one workspace.
 
@@ -145,15 +139,13 @@ Other agents require observed detection through terminal output, screen evidence
 
 Herdr will publish this as a per-agent support matrix: which agents expose verified lifecycle signals, and which agents require observed detection.
 
-**This distinction should be public because it helps everyone.**
+This distinction should be public because it helps everyone.
 
 Users get honest expectations. Agent authors get a target. Tool builders get a vocabulary. The ecosystem rewards agents that expose their runtime state cleanly.
 
-The goal is not to force every agent to use the same plugin system. The goal is to standardize the parts that should never have been product differentiation.
-
-## The ask
+Agents can keep their own plugin systems while standardizing the parts that should never have been product differentiation.
 
-**Standardize the boring parts.**
+## Standardize the boring parts
 
 Use one predictable project instruction format. Expose a small lifecycle contract. Make permission state observable. Make interruption state observable. Tie state to the session that is actually running. Document what external tools can rely on.
 
@@ -169,6 +161,6 @@ Coding agents are becoming infrastructure. The companies building them still own
 
 Herdr is built from that position. The terminal is where these agents actually run. The runtime surface belongs to the developer workflow, and vendors share that space whether they design for it or not.
 
-The better future is simple: agents should make their basic contracts visible, durable, and boring.
+Agents should make their basic contracts visible, durable, and boring.
 
 Then the rest of us can build.
diff --git a/website/src/content/blog/herdr-0-6-3.md b/website/src/content/blog/herdr-0-6-3.md
index 6e375604..3abb5f5f 100644
--- a/website/src/content/blog/herdr-0-6-3.md
+++ b/website/src/content/blog/herdr-0-6-3.md
@@ -7,9 +7,9 @@ draft: false
 
 ## Persistence for the hard parts
 
-Session persistence is not one feature. A detached client, a stopped server, a terminal history replay, an agent conversation restore, and an update handoff all protect different parts of the workspace.
+Keeping a session alive means handling several different cases: a detached client, a stopped server, terminal history replay, agent conversation restore, and an update handoff. Each protects a different part of the workspace.
 
-Herdr 0.6.3 pushes on three of those boundaries.
+Herdr 0.6.3 improves three of those paths.
 
 ### Agent restore after server restart
 
@@ -62,7 +62,7 @@ Herdr also gained better update and remote-bootstrap behavior for package-manage
 
 The new `pane.report_metadata` socket method and `herdr pane report-metadata` CLI command let integrations and local hooks customize what Herdr shows for a pane.
 
-After installing an integration, the integration can report a title, visible agent name, compact status label, state label, and native session metadata without taking over unrelated lifecycle behavior.
+Once installed, an integration can report a title, visible agent name, compact status label, state label, and native session metadata without taking over unrelated lifecycle behavior.
 
 You can also use it from your own scripts. For example, a hook can mark a pane as running a deploy, rename a long-lived task, or ask an agent to report a more specific state for the work it is doing.
 
diff --git a/website/src/content/blog/herdr-is-joining-y-combinator.md b/website/src/content/blog/herdr-is-joining-y-combinator.md
index ff93b509..3a9cfa3e 100644
--- a/website/src/content/blog/herdr-is-joining-y-combinator.md
+++ b/website/src/content/blog/herdr-is-joining-y-combinator.md
@@ -17,19 +17,19 @@ Same idea here. I didn't like what I tried, so why not build it? So I built a ru
 
 ## Runtime
 
-CLI coding agents run in terminals, and terminals have always been our home: editing code (yes, nvim chads), running servers, navigating projects, maintaining CI, machines, configurations. It's the root. It's the connection. So agents need first class primitives there.
+CLI coding agents run in terminals, and terminals have always been our home: editing code (yes, nvim chads), running servers, navigating projects, maintaining CI, machines, configurations. It's the root. It's the connection. So agents need first-class primitives there.
 
 A terminal pane belongs to an agent. A pane belongs to a tab. Tabs belong to a project.
 
 They need to be persistent. We have agents running for hours now, sometimes days. And once you have the runtime, where they run stops mattering. **You should be able to run them anywhere and keep them running.**
 
-That's where Herdr was born. But a runtime without an interface is nothing, so: the TUI.
+That's where Herdr was born. But a runtime needs an interface, so I built the TUI.
 
 ## TUI
 
-The TUI is the UI I use every day, and it carried Herdr this far. Not because it's a UI, but because it shows the concepts Herdr believes in: tracking agents at a glance, dividing work between projects instead of getting lost in a pile of agents, being alerted only when an agent actually needs you.
+The TUI is the UI I use every day, and it carried Herdr this far because it shows what I believe Herdr should do: track agents at a glance, divide work between projects instead of getting lost in a pile of agents, and alert you only when an agent actually needs you.
 
-It also has one big advantage, and it's the reason it stays first class forever: it's bundled. Install Herdr on your VPS, ssh in, and your UI is already there. Or run `herdr --remote user@host` and it installs itself. Depending on your network speed, you're a couple of seconds away from an agent running. One command and you're in. Nothing beats that.
+Its biggest advantage, and the reason it stays first-class forever, is that it's bundled. Install Herdr on your VPS, ssh in, and your UI is already there. Or run `herdr --remote user@host` and it installs itself. Depending on your network speed, you're a couple of seconds away from an agent running. One command and you're in. Nothing beats that.
 
 Still, the TUI was never meant to be the only client. A runtime means people can build on top of it, and people did! A [Raycast extension](https://x.com/vladscale/status/2080195067088871582), a [Stream Deck with buttons for herdr](https://x.com/timvdhoorn/status/2067907258260795808), an [iOS app](https://x.com/imnotchalk/status/2077647387414384936) that drives a whole session from a phone. More than 500 plugins, one month after the marketplace released. I didn't build any of these.
 
@@ -39,15 +39,13 @@ The TUI has its limits too. Some of the ideas in my head are hard to build insid
 
 So a solo project reached **25k stars and 340k downloads**, and it became more than one person can carry.
 
-Herdr is joining <span style="color:#fb651e">Y Combinator, F26 batch</span>. I'm excited to make Herdr a company that builds a developer tool for anyone juggling agents all day. I want to build a small team: people who keep the runtime healthy, robust, fast, running anywhere easily, and more extensible. Letting you do more while Herdr stays small.
+Herdr is joining <span style="color:#fb651e">Y Combinator, F26 batch</span>. I'm excited to make Herdr a company that builds a developer tool for anyone juggling agents all day. I want to build a small team: people who keep the runtime healthy, reliable, fast, easy to run anywhere, and more extensible, so you can do more while Herdr stays small.
 
-The runtime, what you use right now, stays free. Apache-2.0. That's why I recently switched it from AGPL to Apache: I want everyone to use Herdr freely, without any problem.
+The runtime, what you use right now, stays free. Apache-2.0. That's why I recently switched it from AGPL to Apache: I want everyone to use Herdr freely.
 
 ## Where we're going
 
-I want to build on top of the open Herdr runtime like everyone else. I'll keep supporting the open source while building the features people really need. The demand is already visible: multiple clients, a laptop, a VPS for the six hour job, a sandbox for risky code and ephemeral agents. Herdr can run anywhere today, but those machines are disconnected.
-
-**It should be connected.**
+I want to build on top of the open Herdr runtime like everyone else. I'll keep supporting the open source while building the features people really need. The demand is already visible: multiple clients, a laptop, a VPS for the six-hour job, a sandbox for risky code and ephemeral agents. Herdr can run anywhere today, but those machines are disconnected. They should be connected.
 
 There are many more features in my head, but I don't want to rush. People keep telling me they love that Herdr stays lean, and that's what I want to protect. In an age where adding one more feature costs nothing, choosing what goes in the core is the most important decision, I believe. So the core stays small, and everything else stays possible through extensions: your style, your flows, your company's setup, your themes, your crazy ideas.
 
diff --git a/website/src/content/blog/live-updates-without-killing-your-terminal-processes.md b/website/src/content/blog/live-updates-without-killing-your-terminal-processes.md
index b78a3caf..6658c488 100644
--- a/website/src/content/blog/live-updates-without-killing-your-terminal-processes.md
+++ b/website/src/content/blog/live-updates-without-killing-your-terminal-processes.md
@@ -16,7 +16,7 @@ Herdr has a different problem. It is a terminal multiplexer, sure, but it is als
 
 It gets frequent fixes for agent detection (isn't it cool that we have all the labs building their own CLIs, plugins, and hooks in their own broken way?), terminal behavior, remote workflows, worktrees, mobile use, update flows, and integrations. Users should not have to choose between getting those fixes and killing every pane in a running session.
 
-That's a problem: Herdr needed to update like an app while preserving processes like a terminal multiplexer.
+Herdr needed to update like an app while preserving processes like a terminal multiplexer.
 
 ## The update problem
 
@@ -34,7 +34,7 @@ Tmux has the same class of version-skew behavior. Users hit protocol mismatch er
 
 As far as I can tell, mainstream terminal multiplexers do not do in-place server binary replacement while keeping arbitrary live pane processes attached.
 
-So, that is a small breakthrough, but a real one.
+That is a small breakthrough, but a real one.
 
 ## The important detail is PTY ownership
 
@@ -96,7 +96,7 @@ Full-screen terminal apps are different. Herdr does not fake replay for alternat
 
 ## The invariants
 
-The hard part was not sending FDs. The hard part was making the transaction safe.
+Sending FDs was easier than making the transaction safe.
 
 These were the rules:
 
@@ -116,12 +116,10 @@ This is not checkpoint/restore. It does not survive a reboot. It does not migrat
 
 It is a same-machine Unix handoff. The running pane process stays attached to its PTY slave. The old Herdr server transfers the PTY master to the new Herdr server. The server binary changes; the pane process keeps running.
 
-That is the useful boundary.
-
 ## Why this is cool
 
 Herdr users often keep the exact kind of work open that should not be casually restarted: coding agents, dev servers, shells, REPLs, SSH sessions, debugging sessions, long builds, and local experiments.
 
 A terminal multiplexer should make that work safer, not make updates feel dangerous.
 
-The interesting part is not that Herdr remembers your layout. The interesting part is that the process inside the pane does not have to know an update happened.
+The process inside the pane does not have to know an update happened.
diff --git a/website/src/content/blog/ten-agents-three-clients-95-percent-less-cpu.md b/website/src/content/blog/ten-agents-three-clients-95-percent-less-cpu.md
index 635e787e..6aef6af1 100644
--- a/website/src/content/blog/ten-agents-three-clients-95-percent-less-cpu.md
+++ b/website/src/content/blog/ten-agents-three-clients-95-percent-less-cpu.md
@@ -6,11 +6,11 @@ ogImage: /assets/og-blog-frames-v1.png
 draft: false
 ---
 
-Across workloads dominated by unnecessary rendering, total CPU for the Herdr server and its attached clients fell by 89 to 95 percent. The renderer still runs at the same speed. Herdr now asks it to draw fewer frames.
+In workloads dominated by unnecessary rendering, total CPU for the Herdr server and its attached clients fell by 89 to 95 percent. The renderer still runs at the same speed. Herdr now asks it to draw fewer frames.
 
-The saving grows with the session. With one agent and one client, total CPU fell 91 percent. With ten agents producing background output and three clients, it fell 95 percent. Every frame the server skips is also one less frame to serialize, transmit, and apply in each client.
+The savings grow with the session. With one agent and one client, total CPU fell 91 percent. With ten agents producing background output and three clients, it fell 95 percent. Every frame the server skips is also one less frame to serialize, transmit, and apply in each client.
 
-Three changes got us there, and none came from a profiler. The first started as a complaint and gave us a rule. Motion should mean something changed.
+We found all three changes without a profiler. The first started as a complaint and gave us a rule: motion should mean something changed.
 
 ## The spinner was a complaint before it was a cost