docs: scope 'measured' to per-run figures; daily total labeled as cadence-dependent

Per-run captures are measured; the ~26,500/day total multiplies them by assumed
typical run counts (zdeploy/zrestart at 10-15/day dominate). Label that boundary
explicitly in README, ELEVATOR_PITCH, and TOKEN_SAVINGS so the daily figure isn't
read as a direct measurement.

ELEVATOR_PITCH.md

@@ -12,11 +12,11 @@ Licensed under the MIT License. See LICENSE.
 
 ## The 30-second version
 
-Every time your AI coding agent runs your infrastructure for you — a deploy, a restart, a health check — the full output lands in its context window: Docker layers, SSH banners, health-check chatter. We measured it: an active dev day pushes **~26,500 tokens of pure script output** through the agent, and a single full Docker rebuild adds ~35,000 more. The dollars are small; the context is not — every line of infrastructure noise crowds out the code your agent is supposed to be reasoning about.
+Every time your AI coding agent runs your infrastructure for you — a deploy, a restart, a health check — the full output lands in its context window: Docker layers, SSH banners, health-check chatter. We measured it per run — at a typical active-day cadence that's **~26,500 tokens of pure script output** through the agent, and a single full Docker rebuild adds ~35,000 more. The dollars are small; the context is not — every line of infrastructure noise crowds out the code your agent is supposed to be reasoning about.
 
 Token Savers collapses the infrastructure side into short, one-word commands you run yourself: `zdeploy myapp`, `zrepair myapp`, `zstart myapp`. Describe each project once in `zconfig.json` — where it lives, what kind it is, where it deploys — and every command just knows. You run the deploy; your agent edits the code. You run the health check; your agent reads the result and fixes whatever's wrong.
 
-**Measured: ~26,500 tokens of script output per active development day** — kept out of your agent's context entirely when you run the commands yourself. See [TOKEN_SAVINGS.md](TOKEN_SAVINGS.md) for the per-script measurements and method.
+**Measured per-run; ~26,500 tokens of script output per active development day at a typical cadence** — kept out of your agent's context entirely when you run the commands yourself. See [TOKEN_SAVINGS.md](TOKEN_SAVINGS.md) for the per-script measurements and method.
 
 ## Why it's different
 

README.md

@@ -8,7 +8,7 @@ Licensed under the MIT License. See LICENSE.
 
 When an AI coding agent orchestrates your infrastructure — starting dev servers, deploying to EC2, diagnosing 502s — it spends hundreds to thousands of tokens per operation on SSH plumbing, Docker output, and retry logic. Those tokens should go to code.
 
-Token Savers gives you short, one-word commands to run those parts yourself: `zdeploy myapp`, `zrepair myapp`, `zstart myapp`. You handle the deterministic infrastructure; your agent handles code. **Running these scripts manually instead of asking your agent to orchestrate them keeps a measured ~26,500 tokens of infrastructure output per active development day out of your agent's context window.** See [TOKEN_SAVINGS.md](TOKEN_SAVINGS.md) for the per-script measurements and method.
+Token Savers gives you short, one-word commands to run those parts yourself: `zdeploy myapp`, `zrepair myapp`, `zstart myapp`. You handle the deterministic infrastructure; your agent handles code. **Running these scripts manually instead of asking your agent to orchestrate them keeps measured script output out of your agent's context window — ~26,500 tokens per active development day at a typical run cadence.** Per-run figures are measured; the daily total applies typical run counts. See [TOKEN_SAVINGS.md](TOKEN_SAVINGS.md) for the numbers and method.
 
 Every command is a tiny PowerShell script driven by a single JSON config file. The project key you define in that config **is** the command argument — add `myapp` to the config and `zstart myapp`, `zdeploy myapp`, `zbackup myapp` all just work, no script edits needed.
 

TOKEN_SAVINGS.md

@@ -215,9 +215,11 @@ zrepair viteapp
 
 ## Daily Token Savings Summary
 
-Per-run × runs/day, using midpoint run counts. The **measured** column is the real
+Per-run × runs/day. The per-run figures are **measured**; the daily totals multiply
-savings from running scripts yourself; the **est. raw** column approximates what
+them by **assumed typical run counts** (midpoints) — `zdeploy` and `zrestart` at
-Claude would burn orchestrating the same work with no scripts.
+10–15/day dominate the sum, so scale the total to your own cadence. The **est. raw**
+column approximates what Claude would burn orchestrating the same work with no
+scripts.
 
 | Script | Measured/run | Runs/day | Measured/day | Est. raw/day |
 |--------|-------------:|:--------:|-------------:|-------------:|
@@ -232,8 +234,9 @@ Claude would burn orchestrating the same work with no scripts.
 | `zrepair` | 364 | 1–2 | ~550 | ~3,000–6,000 |
 | **Total (active dev day)** | | | **~26,500** | **~115,000–295,000** *est.* |
 
-The **~26,500 tokens/day measured** is the honest, reproducible savings from running
+The **~26,500/day** figure is measured per-run at an assumed typical cadence —
-these yourself during an active tool-development day (mostly cached deploys). The
+reproducible on the per-run side, workflow-specific on the multiplier. It reflects an
+active tool-development day of mostly cached deploys. The
 **~115k–295k est.** upper figure is what it would cost to have Claude drive the raw
 `ssh`/`docker` sequences instead — dominated by per-step reasoning on `zdeploy` and
 `zrestart`, not by output volume. Treat that column as an **upper bound, not a