chore: refresh english documentation

5 files changed, 32 insertions, 44 deletions

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