langgraph-api 0.16.0rc2__tar.gz → 0.17.0.dev1__tar.gz

{langgraph_api-0.16.0rc2 → langgraph_api-0.17.0.dev1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: langgraph-api
-Version: 0.16.0rc2
+Version: 0.17.0.dev1
 Author-email: Will Fu-Hinthorn <will@langchain.dev>, Josh Rogers <josh@langchain.dev>, Parker Rule <parker@langchain.dev>
 License: Elastic-2.0
 License-File: LICENSE
@@ -17,7 +17,7 @@ Requires-Dist: jsonschema-rs<0.45,>=0.20.0
 Requires-Dist: langchain-core>=0.3.64
 Requires-Dist: langchain-protocol<0.1,>=0.0.18
 Requires-Dist: langgraph-checkpoint<5,>=3.0.1
-Requires-Dist: langgraph-runtime-inmem<0.37.0.dev0,>=0.36.0.dev0
+Requires-Dist: langgraph-runtime-inmem<0.38.0.dev0,>=0.37.0.dev0
 Requires-Dist: langgraph-sdk>=0.4.4
 Requires-Dist: langgraph<2,>=0.4.10
 Requires-Dist: langsmith[otel]>=0.6.3

{langgraph_api-0.16.0rc2 → langgraph_api-0.17.0.dev1}/benchmark/README.md

@@ -132,8 +132,8 @@ thread depth. `delta_turns` measures it: one thread per VU, one turn per iterati
 `benchmark-delta.yml` runs four cells nightly, 20 users for 25 minutes each, 1 KB appended per turn (`CHECKPOINT_SIZE`): plain channel, then
 delta snapshotting every 50 (`benchmark_delta_freq`, the deepagents setting), 500
 (`benchmark_delta_500`) and 1000 (`benchmark_delta`, the library default). `delta-report.js` posts
-a headline table (non-delta vs delta at 50: read, write, storage by depth) and one table per metric
-across the three frequencies. The messages and migration cells stay manual. Run the cells one at a time and compare `turn_duration` by depth. Both sides get slower
+one row per cell (write, read and storage at the deepest turn every cell reached) and puts
+the by-depth tables in the thread. The messages and migration cells stay manual. Run the cells one at a time and compare `turn_duration` by depth. Both sides get slower
 with depth for different reasons, the control by re-writing a growing value and delta by
 replaying more writes, so the deliverable is which curve is worse and where they cross.
 
@@ -209,14 +209,7 @@ Each cell also records the deployment's own view of its window (queue and API po
 
 ### Slack reports
 
-Every report follows one shape so the channel reads the same way each morning, on a phone as well as a desktop:
-
-- The first line is the verdict: a dot (green quiet, yellow something regressed or a bottleneck or errors, red something failed), the report name and date, `manual run` when dispatched by hand, the API version, and a clause saying what needs attention. The second line says what the benchmark is, for a reader outside the team.
-- Then `Failed`, `Regressed`, `Improved` and `Bottlenecks` or `Errors` lines, worst first. `Regressed` prints `none` rather than going quiet.
-- One table per deployment, about 40 characters wide so it fits a phone, with `▲ better` / `▼ worse` markers on cells that left their usual range.
-- One legend line (pass rule, arrows, dot colors), then a link to the thread, which holds the per-cell or per-run numbers and the longer *How to read*, and to the run's artifacts.
-
-Both reports compare tonight with the previous scheduled nights (`history.js`, artifacts fetched with `gh`). A figure is flagged only when it leaves that cell's own observed range, and only once five same-kind nights exist; before that the table says how many nights it has. The daily benchmark posts one digest per workflow once its last runner finishes (`daily-report.js`, fed by each runner's artifact), not one message per runner. The delta-channel report (`delta-report.js`) keeps the plain-vs-delta table in the channel and puts the snapshot-frequency sweep in the thread.
+What each post means, for a reader outside the team, is in [REPORTS.md](REPORTS.md); every post links to its section. The channel message carries only the verdict, the lines that need attention and a small table per deployment (with a p95 trend on the daily ones), each fitting a phone; the numbers behind it go to the thread.
 
 Local commands:
 

langgraph_api-0.17.0.dev1/benchmark/REPORTS.md

@@ -0,0 +1,181 @@
+# Reading the benchmark reports
+
+The LGP Benchmark Reporter posts four benchmark reports to #test-reports-lsd.
+Each post keeps to the numbers; this page explains what they mean. Every post
+links to its own section below with "What is this?". The weekly image-pull post
+in the same channel is separate and not covered here.
+
+## Reading any report
+
+- **The dot.** 🟢 nothing to look at. 🟡 look at it: a regression, 10 or more
+  failed requests, a bottleneck, a correctness check or a warning line. 🔴 something failed: a
+  run crossed its pass bar, or never produced results.
+- **The first line** is the verdict: report, date, `manual run` when someone
+  dispatched it by hand, the API version that was tested, and what needs
+  attention.
+- **Failed / Errors / Regressed / Bottlenecks** lines only appear when there is
+  something to say, worst first.
+- **Regressed / Improved.** A figure is flagged only when it leaves its own
+  usual range over the recent nights: the 9 before tonight for the daily
+  reports, the last 7 for capacity and delta, where ▲ better and ▼ worse also
+  mark the cell in the table. The usual range is half the spread
+  between the best and worst of those nights, and never less than 10%, so a
+  series that swings 40% night to night is not flagged for moving 15%.
+  Flags start once five nights of history exist; until then the post says how
+  many it has.
+- **The thread** holds the full numbers: per-run or per-cell detail and
+  improvements with before and after values; the daily threads also give the
+  load that ran.
+- **Run** opens the GitHub Actions run, with the raw k6 summaries and charts.
+- `-` in a cell means there is no number: the run produced no results, nothing
+  succeeded, or no thread reached that depth.
+
+## Daily benchmark
+
+**Question it answers:** did latency or errors change for the three core
+request paths, compared with the recent nights?
+
+**How it runs.** [k6](https://k6.io/docs/) starts virtual users (simulated
+clients). Each one repeats one request path as fast as the server answers: it
+sends a request, waits for the response, then sends the next (a "closed
+model"). Users are added in two steps of 60 s, then held for 5 minutes. Each
+path runs as its own k6 run against the benchmark staging deployment. Every
+scheduled night starts from a fresh revision of that deployment; it runs the
+server version staging is on, which is the API version in the first line.
+
+| Row | Runner | What one iteration does | Users |
+|---|---|---|---|
+| `wait` | `wait_write` | start a run and wait for its result (`POST /runs/wait`): run execution and checkpointing | 1,000 |
+| `stream` | `stream_write` | start a run and read its event stream to the end (`POST /runs/stream`) | 1,000 |
+| `search` | `threads_search` | create two threads, set their metadata, then search for them by it: database and metadata search | 300 |
+
+Tables use the one-word row names so they fit a phone; the lines above the
+table use the runner names.
+
+`threads_search` does not delete the threads it creates; the deployment's
+60-minute thread TTL removes them, so each night searches a table of about
+that run's threads, not a growing history.
+
+**The table.**
+
+- `p95 s`: 95% of iterations finished within this many seconds tonight. When
+  it left its usual range, the Regressed or Improved line says so, with the
+  before and after.
+- `last 10`: p95 over the same 10 nights the flags use, oldest on the left,
+  tonight on the right. Taller is slower. Each row has its own scale, so a full
+  bar means that runner's slowest night of the ten, not a number of seconds:
+  compare a row with itself, not with the row below. The bars never stretch
+  small noise to full height, so a real step stands out.
+
+**Pass bar.** Request errors under 1%, p95 under 13 s, and more than 99% of
+iterations succeeding. Missing any of them fails the run and turns the dot red.
+
+**Errors line.** Failed requests by HTTP status, and how many nights in a row
+that runner has had any, as `N+` when every fetched night had them, since the
+streak then started before the history does. 10 or more in one night turn the dot yellow even when
+the run passes.
+
+**Thread.** Average, p95 and p95 of successful iterations only; run and
+failure counts; every figure against the 9 nights before tonight, including average
+latency and run count (run count follows latency under a fixed user count, so
+it is shown but never flagged).
+
+## Scale to zero
+
+The daily benchmark against a second deployment that scales to zero when
+idle. Scheduled runs redeploy it first, so the first minute includes the cold
+start; a manual run skips the redeploy unless it is asked for. 200 users per
+path instead of the daily's 1,000 (300 for search), and the pass bar is p95
+under 25 s to allow for the cold start. Read it like the [daily benchmark](#daily-benchmark).
+
+## Capacity
+
+**Question it answers:** how much traffic can each deployment size handle
+before it breaks its latency target, and what runs out first?
+
+**How it runs.** Two staging deployments, one dedicated and one serverless,
+are resized to each tier (L, M, S) in turn. For each tier and path, k6 sends a
+fixed request rate regardless of how fast the server answers (an "open
+model", the way real traffic arrives), and raises it every 60 s: dedicated by
+50 req/s starting at 50, serverless by 5 starting at 10.
+
+**The table.** Each cell is the highest request rate the tier held for two
+steps while staying on target: at least 99% success, p50 at most 3 s, p95 at
+most 10 s. `0` means no step met the target, `ERR` means the cell crashed,
+`-` means it never ran.
+
+**Bottlenecks.** A component (queue, api, database, redis) running at or over
+95% of its CPU request during the steps the tier passed. That is what stops
+the tier going higher. Over 100% means it is bursting above its request.
+
+**Keep in mind.** The graph is one step with no LLM call, so this measures the
+server's own ceiling, not a customer workload. Every tier starts at one queue
+pod and autoscales during a cell, so a capacity number is partly a pod-count
+number.
+
+**Thread.** Improvements with before and after values, then per deployment
+two small tables grouped by tier: peak CPU as % of the pod's request, and pods
+at the start and end of the cell. Both cover the whole cell, including steps
+that failed. Last, the request rate actually served at the top step.
+
+## Delta channel
+
+**Question it answers:** as a thread grows to thousands of turns, does
+`DeltaChannel` keep reads and writes cheaper than a plain channel, and how
+much storage does it save?
+
+**Background.** A plain channel saves the whole value at every checkpoint. A
+`DeltaChannel` saves only what changed, plus a full snapshot every N turns,
+and rebuilds the value on read by replaying the changes since the last
+snapshot. That moves cost from write to read, and read cost grows with the
+distance to the last snapshot.
+
+**How it runs.** 20 k6 users, one thread each, for 25 minutes. Every
+iteration adds one turn to the user's thread (`POST /runs/wait`), appending
+1 KB to its state, so threads reach about 1,500 turns. Every 50 turns each user also does a cold state read
+(`GET /threads/{id}/state`) and reads the thread's storage size
+(`GET /threads/{id}/storage`). Four cells run the same graph logic:
+
+| Row | Channel |
+|---|---|
+| `non-delta` | plain channel, the control |
+| `snap 50` | delta, snapshot every 50 turns (the deepagents setting) |
+| `snap 500` | delta, snapshot every 500 turns |
+| `snap 1000` | delta, snapshot every 1000 turns (the library default) |
+
+**The table.** One row per cell at the deepest turn every cell has a cold read
+for, named in the header (`at 1400`). A slower cell gets less deep in 25
+minutes, so the table stops where the slowest one did; the thread says how far
+each cell got. Values are seconds, except `KB`.
+
+- `write`: median checkpoint save at that turn, timed by the worker as the
+  gap between the graph's two steps, with saves made synchronous so nothing
+  overlaps it. `-` with a note means the deployed benchmark graph is too old
+  to report it.
+- `read`: median cold state read at that turn, timed to the server's first
+  byte, so sending the state back is not counted.
+- `KB`: storage the thread occupies at the deepest turn. Missing when the
+  deployment's API predates the storage endpoint.
+
+**Pass bar.** Request errors under 1% and success over 99% per cell. Two
+correctness checks turn the dot yellow on any failure: at turn 2 each cell
+confirms delta is on (or off, for the control), because a too-old langgraph
+silently degrades a `DeltaChannel` to a plain one; and every cold read is
+compared with what the run returned.
+
+**Thread.** Per-cell turn and failure counts against past nights; the plain
+channel and delta-at-50 as two stacked tables every 250 turns, with the
+deepest turn each cell reached; and the snapshot-frequency sweep, whose
+columns are the snapshot interval (50, 500, 1000). The sweep shows read,
+write and storage at the turn before and at each snapshot, where read peaks
+and resets, plus the write at the row's own turn: snapshots land on those
+turns, so it is the full-value write the median hides.
+
+## Changing a report
+
+The builders are `daily-report.js` (daily and scale to zero),
+`capacity-ci.js --aggregate` and `delta-report.js`, all posting through
+`slack.js`. The daily workflows post one digest after their last runner finishes, built from each runner's artifact. History comes from previous scheduled runs' artifacts via
+`history.js`. Each has a `*.test.js` beside it (`npm test`). A dispatch of the
+workflow with `post_to_slack` reproduces a post: about 30 minutes for the
+daily reports, about 2 hours for delta and capacity.

{langgraph_api-0.16.0rc2 → langgraph_api-0.17.0.dev1}/benchmark/benchmark-runners/threads_search_metadata.ts

@@ -13,11 +13,12 @@ interface ThreadsSearchMetadataData {
 }
 
 /**
- * Delete the threads each iteration creates, or leave them to accumulate.
+ * Delete the threads each iteration creates, or leave them to the deployment.
  *
- * Off by default: letting the table grow is how this benchmark shows whether
- * search degrades as thread count rises, and it is the realistic case since
- * deployments do not delete threads per request.
+ * Off by default, since deployments do not delete threads per request. The
+ * nightly deployments' 60-minute thread TTL (langgraph.json in
+ * langgraph-server-benchmarks) removes them after the run, so the table holds
+ * about one run's threads rather than growing night over night.
  *
  * The capacity staircase turns it on, because there the table grows *while*
  * load is ramping, so a slower step cannot be attributed to load or to size.

{langgraph_api-0.16.0rc2 → langgraph_api-0.17.0.dev1}/benchmark/capacity-ci.js

@@ -18,7 +18,7 @@ import {
   requireApiKey,
   setResourceTiers,
 } from "./host-v2.js";
-import { RUNNERS, readApiVersion } from "./daily-report.js";
+import { RUNNERS } from "./daily-report.js";
 import {
   MIN_HISTORY_NIGHTS,
   cellKey,
@@ -26,14 +26,9 @@ import {
   formatMove,
   loadCapacityHistory,
 } from "./history.js";
-import {
-  describeRunnerBriefly,
-  runnerColumnName,
-  runnerGloss,
-  runnerShortName,
-} from "./runner-descriptions.js";
+import { runnerColumnName, runnerShortName } from "./runner-descriptions.js";
 import { cellWindow, peakCpu, podRange, summarizeServerMetrics } from "./server-metrics.js";
-import { dotFor, postReport } from "./slack.js";
+import { dotFor, footer, postReport } from "./slack.js";
 
 const __dirname = path.dirname(fileURLToPath(import.meta.url));
 
@@ -86,11 +81,6 @@ function unitFor(executor) {
   return executor === OPEN_MODEL ? "req/s" : "users";
 }
 
-// Mirrors staircase.py's SLO defaults, for the report header only. Kept here
-// rather than parsed out of a summary so the header still renders when every
-// cell failed and there is no config to read.
-const SLO = { minSuccessRate: 99, maxP50Ms: 3000, maxP95Ms: 10000 };
-
 /**
  * Parse a comma-separated allowlist from an env var.
  *
@@ -332,23 +322,6 @@ function plural(n, word) {
   return `${n} ${word}${n === 1 ? "" : "s"}`;
 }
 
-function stepSecondsOf(summaries) {
-  const seen = [...new Set(
-    summaries.map((s) => s.config?.plateauDurationSeconds).filter((v) => v != null).map(String),
-  )];
-  if (seen.length === 0) return STAIRCASE_PLATEAU_DURATION;
-  return seen.sort((a, b) => Number(a) - Number(b)).join("/");
-}
-
-/** A dispatch can override the configured geometry; the report describes the run. */
-function geometryOf(deployment, cells) {
-  const ran = ranGeometry(cells) ?? deployment.staircase ?? {};
-  return {
-    start: Number(ran.startLoad ?? STAIRCASE_START_LOAD),
-    step: Number(ran.stepSize ?? STAIRCASE_STEP_SIZE),
-  };
-}
-
 function capacityTable(deployment, rows, unit) {
   const labels = deployment.tiers.map((tier) => tierLabel(deployment, tier));
   const labelWidth = Math.max(2, ...labels.map((l) => l.length)) + 1;
@@ -391,7 +364,6 @@ export function formatAggregateTable(
   const regressed = rows.filter((row) => row.change && !row.change.better);
   const improved = rows.filter((row) => row.change?.better);
   const bottlenecks = bottleneckLines(rows);
-  const checked = analysed.some((a) => a.nights >= MIN_HISTORY_NIGHTS);
   const allWarnings = [...warnings, ...toolOverheadWarnings(summaries)];
 
   const executor = executorOf(summaries);
@@ -414,7 +386,6 @@ export function formatAggregateTable(
   });
   const lines = [
     `${dot} *Capacity · ${date}*${manual ? " · manual run" : ""}${apiVersion ? ` · API ${apiVersion}` : ""} · ${ran} · ${verdict.join(", ")}`,
-    describeCapacity(analysed, summaries, executor),
   ];
 
   const failedParts = crashed.map((tier) => tier.detail);
@@ -425,57 +396,25 @@ export function formatAggregateTable(
   if (failedParts.length > 0) {
     lines.push(`*Failed:* ${failedParts.join(" · ")} · treat the table as incomplete`);
   }
-
-  if (!checked) {
-    const nights = Math.max(...analysed.map((a) => a.nights));
-    lines.push(`*Regressed:* not checked, ${nights} of ${MIN_HISTORY_NIGHTS} nights of history`);
-  } else {
-    lines.push(`*Regressed:* ${regressed.length > 0 ? regressed.map((row) => moveLine(row, unit)).join(" · ") : "none"}`);
-    if (improved.length > 0) lines.push(`*Improved:* ${improved.map((row) => moveLine(row, unit)).join(" · ")}`);
-  }
-  lines.push(`*Bottlenecks:* ${bottlenecks.length > 0 ? bottlenecks.join(" · ") : "none reported"}`);
+  if (regressed.length > 0) lines.push(`*Regressed:* ${regressed.map((row) => moveLine(row, unit)).join(" · ")}`);
+  if (bottlenecks.length > 0) lines.push(`*Bottlenecks:* ${bottlenecks.join(" · ")}`);
   for (const warning of allWarnings) lines.push(`:warning: ${warning}`);
 
   for (const { deployment, rows: deploymentRows, nights } of analysed) {
     lines.push("", ...capacityTable(deployment, deploymentRows, unitFor(executorOf(deploymentRows.map((r) => r.summary).filter(Boolean)))));
-    if (checked && nights < MIN_HISTORY_NIGHTS) {
+    if (nights < MIN_HISTORY_NIGHTS) {
       lines.push(`_${nights} of ${MIN_HISTORY_NIGHTS} nights of history, no change flags yet_`);
     }
   }
-
-  lines.push(
-    "",
-    `▲ better ▼ worse than the last ${MIN_HISTORY_NIGHTS}+ nights · \`0\` no step passed · \`ERR\` crashed · \`-\` never ran · 🟢 quiet · 🟡 regression or bottleneck · 🔴 cells failed`,
-  );
   return lines.join("\n");
 }
 
-function describeCapacity(analysed, summaries, executor) {
-  const open = executor === OPEN_MODEL;
-  const unit = unitFor(executor);
-  const climb = analysed
-    .map(({ deployment, rows }) => {
-      const cells = indexCells([deployment], rows.map((r) => r.summary).filter(Boolean))[deployment.slug] ?? {};
-      const { start, step } = geometryOf(deployment, cells);
-      return `+${step} from ${start} (${deploymentName(deployment).toLowerCase()})`;
-    })
-    .join(" or ");
-  const where = analysed.length === 1 ? "one staging deployment" : `${analysed.length} staging deployments`;
-  return (
-    `k6 ${open ? "open-model" : "closed-model"} staircase, ${where} resized per tier: ${open ? "request rate" : "virtual users"} ${climb} every ${stepSecondsOf(summaries)} s, per path: ${RUNNERS.map(runnerGloss).join(", ")}. ` +
-    `Cell = highest ${unit} where success ≥ ${SLO.minSuccessRate}%, p50 ≤ ${SLO.maxP50Ms / 1000} s, p95 ≤ ${SLO.maxP95Ms / 1000} s held for two steps. ` +
-    "One-step graph, no LLM: server ceiling, not customer traffic."
-  );
-}
-
-export function howToRead() {
-  return [
-    "*How to read*",
-    `• *Tests:* ${RUNNERS.map((r) => `${runnerColumnName(r)} = ${describeRunnerBriefly(r)}`).join(" · ")}.`,
-    `• *Regressed / Improved:* a cell outside its own usual range over the last ${MIN_HISTORY_NIGHTS}+ nights measured the same way.`,
-    `• *Bottleneck:* a component at or over ${BOTTLENECK_CPU_PCT}% of its CPU request while the tier held its top step. It is what stops the tier going higher.`,
-    "• Graph is one step, no LLM, so this is server overhead, not a customer workload.",
-  ].join("\n");
+export function formatImprovements(deployments, summaries, history = {}) {
+  const byDeployment = indexCells(deployments, summaries);
+  const rows = deployments.flatMap((d) => analyseDeployment(d, byDeployment[d.slug] ?? {}, history).rows);
+  const unit = unitFor(executorOf(summaries));
+  const improved = rows.filter((row) => row.change?.better);
+  return improved.length > 0 ? `*Improved:* ${improved.map((row) => moveLine(row, unit)).join(" · ")}` : null;
 }
 
 function servedRate(summary) {
@@ -485,20 +424,19 @@ function servedRate(summary) {
   return ceiling != null ? `0 (ceiling ${Math.round(ceiling)})` : "-";
 }
 
-function serverColumns(summaries) {
-  const columns = [];
-  for (const [label, name] of COMPONENTS) {
-    const groups = summaries.map((s) => s?.serverMetrics?.groups?.[label]).filter(Boolean);
-    if (groups.length === 0) continue;
-    if (groups.some(podRange)) columns.push({ label, kind: "pods", width: 7 });
-    if (groups.some((g) => peakCpu(g) != null)) columns.push({ label, kind: "cpu", width: 6 });
-  }
-  return columns;
+function serverColumns(summaries, kind) {
+  const has = kind === "pods" ? podRange : (g) => peakCpu(g) != null;
+  return COMPONENTS.map(([label]) => label).filter((label) =>
+    summaries.some((s) => {
+      const group = s?.serverMetrics?.groups?.[label];
+      return group && has(group);
+    }),
+  );
 }
 
-function serverCell(summary, column) {
-  const group = summary?.serverMetrics?.groups?.[column.label];
-  if (column.kind === "pods") {
+function serverCell(summary, label, kind) {
+  const group = summary?.serverMetrics?.groups?.[label];
+  if (kind === "pods") {
     const range = podRange(group);
     return range ? `${range.min}→${range.max}` : "-";
   }
@@ -506,6 +444,29 @@ function serverCell(summary, column) {
   return cpu != null ? String(Math.round(cpu)) : "-";
 }
 
+// Tier rows head their runners so each line fits PHONE_WIDTH; a "L search" label column would not.
+function serverTable(deployment, cells, kind) {
+  const present = deployment.tiers.flatMap((tier) => RUNNERS.map((r) => cells[tier]?.[r]).filter((s) => s?.serverMetrics));
+  const columns = serverColumns(present, kind);
+  if (columns.length === 0) return null;
+  const labelWidth = Math.max(...RUNNERS.map((r) => runnerColumnName(r).length)) + 1;
+  const widths = columns.map((label) =>
+    Math.max(label.length, ...present.map((s) => serverCell(s, label, kind).length)) + 1,
+  );
+  const lines = ["```", `${"".padEnd(labelWidth)}${columns.map((label, i) => label.padStart(widths[i])).join("")}`];
+  for (const tier of deployment.tiers) {
+    const runners = RUNNERS.filter((r) => cells[tier]?.[r]?.serverMetrics);
+    if (runners.length === 0) continue;
+    lines.push(tierLabel(deployment, tier));
+    for (const runner of runners) {
+      const row = columns.map((label, i) => serverCell(cells[tier][runner], label, kind).padStart(widths[i]));
+      lines.push(`${` ${runnerColumnName(runner)}`.padEnd(labelWidth)}${row.join("")}`);
+    }
+  }
+  lines.push("```");
+  return lines.join("\n");
+}
+
 export function formatServerView(deployments, summaries) {
   const byDeployment = indexCells(deployments, summaries);
   const blocks = [];
@@ -517,39 +478,23 @@ export function formatServerView(deployments, summaries) {
       .map((tier) => `${tierLabel(deployment, tier)} ${RUNNERS.map((r) => servedRate(cells[tier]?.[r])).join(" / ")}`)
       .join(" · ");
     const servedLine = `Runs/sec actually served at the top step, as ${RUNNERS.map(runnerColumnName).join(" / ")}: ${served}`;
-    // The served rate is k6's; the pod and CPU columns are the dashboard's, which is best effort.
-    const columns = serverColumns(present);
-    if (columns.length === 0) {
-      blocks.push(`*${deploymentName(deployment)}*\n${servedLine}`);
-      continue;
-    }
-    const labelWidth = Math.max(...deployment.tiers.map((t) => tierLabel(deployment, t).length)) + 8;
-    const spans = [];
-    for (const column of columns) {
-      const last = spans[spans.length - 1];
-      if (last && last.label === column.label) last.width += column.width;
-      else spans.push({ label: column.label, width: column.width });
-    }
-    const lines = [
-      `*${deploymentName(deployment)}*`,
-      "```",
-      `${"".padEnd(labelWidth)}${spans.map((s) => s.label.padStart(s.width)).join("")}`,
-      `${"".padEnd(labelWidth)}${columns.map((c) => c.kind.padStart(c.width)).join("")}`,
-    ];
-    for (const tier of deployment.tiers) {
-      for (const runner of RUNNERS) {
-        const summary = cells[tier]?.[runner];
-        if (!summary?.serverMetrics) continue;
-        const label = `${tierLabel(deployment, tier)} ${runnerColumnName(runner)}`;
-        lines.push(`${label.padEnd(labelWidth)}${columns.map((c) => serverCell(summary, c).padStart(c.width)).join("")}`);
-      }
-    }
-    lines.push("```", servedLine);
-    blocks.push(lines.join("\n"));
+    // The served rate is k6's; the pod and CPU tables are the dashboard's, which is best effort.
+    const cpu = serverTable(deployment, cells, "cpu");
+    const pods = serverTable(deployment, cells, "pods");
+    blocks.push(
+      [
+        `*${deploymentName(deployment)}*`,
+        cpu ? `_CPU, % of request_\n${cpu}` : null,
+        pods ? `_Pods, start → end_\n${pods}` : null,
+        servedLine,
+      ]
+        .filter(Boolean)
+        .join("\n"),
+    );
   }
   if (blocks.length === 0) return null;
   return [
-    "*Pods and CPU per cell*, peak over the whole cell including the steps that failed. Pods are start → end. CPU is % of the pod's request, so over 100 means bursting above it.",
+    "*Pods and CPU per cell*, peak over the whole cell including the steps that failed. CPU over 100 means bursting above the pod's request.",
     ...blocks,
   ].join("\n\n");
 }
@@ -570,19 +515,6 @@ function toolOverheadWarnings(summaries) {
   return lines;
 }
 
-/** A dispatch can override the configured geometry; the report describes the run. */
-function ranGeometry(cells) {
-  for (const byRunner of Object.values(cells)) {
-    for (const summary of Object.values(byRunner)) {
-      const config = summary?.config;
-      if (config?.startLoad != null && config?.stepSize != null && config?.numSteps != null) {
-        return config;
-      }
-    }
-  }
-  return null;
-}
-
 function warningsPathFor(deploymentSlug) {
   return path.join(__dirname, `staircase_warnings_${deploymentSlug}.json`);
 }
@@ -911,6 +843,22 @@ function collectSummaries(directory) {
   );
 }
 
+/** The checked-out repo is usually ahead of staging, so the version comes from the deployments. */
+export async function deployedVersion(deployments, fetchImpl = fetch) {
+  const versions = await Promise.all(
+    deployments.map(async ({ baseUrl }) => {
+      try {
+        const response = await fetchImpl(`${baseUrl}/info`, { signal: AbortSignal.timeout(15000) });
+        return response.ok ? ((await response.json())?.version ?? null) : null;
+      } catch {
+        return null;
+      }
+    }),
+  );
+  const known = [...new Set(versions.filter(Boolean))];
+  return known.length > 0 ? known.join("/") : null;
+}
+
 async function runAggregate(summariesDir, { postToSlack, historyDir }) {
   const summaries = collectSummaries(summariesDir);
   const warnings = collectWarnings(summariesDir);
@@ -921,12 +869,13 @@ async function runAggregate(summariesDir, { postToSlack, historyDir }) {
     warnings,
     new Date(),
     history,
-    process.env.API_VERSION || readApiVersion(),
+    await deployedVersion(CAPACITY_DEPLOYMENTS),
     process.env.MANUAL === "true",
   );
-  const artifactUrl = process.env.GITHUB_RUN_URL;
-  text += `\n*Thread:* pods and CPU per cell, and how to read${artifactUrl ? ` · <${artifactUrl}|Artifacts:> raw k6 summaries` : ""}`;
-  const thread = [[formatServerView(CAPACITY_DEPLOYMENTS, summaries), howToRead()].filter(Boolean).join("\n\n")];
+  text += `\n\n${footer("capacity", process.env.GITHUB_RUN_URL)}`;
+  const thread = [
+    [formatImprovements(CAPACITY_DEPLOYMENTS, summaries, history), formatServerView(CAPACITY_DEPLOYMENTS, summaries)].filter(Boolean).join("\n\n"),
+  ];
   if (postToSlack) {
     await postReport({ text, thread });
   } else {