Everything below is designed, not shipped. These are six feature families we're building next, described here so the plan is public before the code is. I'll be precise about status throughout: where a family is mostly a new front-end over an engine that already ships in v1.25.0, I'll say so; where it's genuinely new plumbing, I'll say that too. loadr's design bias is to add capabilities as thin layers over a small, sharp core, so the roadmap below is mostly about which existing seams we lean on next.
1. A complete inbuilt Session Recorder
The single biggest gap in the migration story is capture. Today you can turn a recorded session into a parameterised plan — loadr convert reads a HAR file and runs heuristic auto-correlation: when a value returned in one JSON response (a CSRF token, an id, an auth token) reappears in a later request, it plants an extract: on the producer and rewrites the literal to ${var} in every consumer. That importer shipped in v1.14.0 (#27) and is 696 lines of real heuristics in loadr-convert's har.rs. What's missing is the recording step itself — you still have to produce the HAR from browser devtools or a separate proxy.
loadr record closes that loop. It stands up an HTTPS man-in-the-middle proxy (generate a local CA, install it, point a browser or a mobile app at it) and, separately, can drive capture through the headless Chrome we already embed — the loadr-browser crate already owns a CDP-driven Chromium and collects Navigation Timing and Web Vitals per page. The recorder's job is to capture the request/response stream and emit exactly the HAR shape har.rs already consumes. Crucially, none of the correlation logic is new work: the recorder feeds the existing heuristic engine. That's the point of doing it now rather than first — the hard, valuable part (turning literal replay into a correlated, parameterised plan) already exists and is tested. record is the capture nozzle bolted onto the front of it.
2. Spec-Driven Generation & API Fuzzing
Recording captures what a client did. A specification describes what an API allows — and most teams have one lying around. loadr gen will read an OpenAPI document, a GraphQL schema, a gRPC/protobuf service definition, or a Postman collection and emit a runnable plan: every operation as a flow step, path and query parameters as variables, request bodies shaped from the schema. We already reflect gRPC dynamically and speak GraphQL at runtime, and loadr-config already emits its own JSON Schema (loadr schema), so the type machinery to walk a spec and shape a valid request body is largely present; gen is the traversal and mapping layer on top.
The second half marries this to the payload work that just landed. v1.25.0 added loadr payload and the loadr-payload crate (#74, 904b7ff): a pure, deterministic generator of adversarial inputs — deeply-nested JSON, expansion bombs, catastrophic-backtracking strings — each parameterised by a single magnitude so you can scale it and watch for non-linear response-time growth via loadr sweep --assert-complexity. Spec-aware fuzzing is the union: use the schema to know where a string, an integer, an array lives, then inject the payload catalogue's adversarial values into those fields specifically — a malformed body that is still shaped enough to reach the parser you're trying to break. The generator is deterministic and hard-capped, which is exactly what you want when fuzzing has to be reproducible in CI.
3. Results Intelligence & Regression History
The workflow wave (#71, 944ac35) shipped loadr compare — take two run summaries, flag the regressions — and loadr sweep for parameter matrices. Both are pairwise or point-in-time: they answer "is this run worse than that run," not "is p99 drifting up over the last six weeks." Every run already produces a structured summary JSON — what compare and loadr report consume — so the data exists; it just evaporates after each run.
Results Intelligence is a persistent local store of those summaries plus a trends view over them: percentile-and-throughput history per scenario, automatic baselines, and regression detection against a rolling window rather than a single hand-picked prior run. It builds directly on the summary format and the HDR histograms the engine already merges across agents — no new measurement, just retention and a longer time axis. The honest framing: this is a storage-and-visualisation layer, and the interesting design questions are about what a "baseline" means — last green? rolling median? release-tagged? — rather than any new engine capability.
4. An AI Copilot
The desktop app already generates load tests with AI — from a natural-language prompt or by pointing it at a repository (#47, 6aeedac) — and its provider layer already targets Anthropic's Claude among others (desktop/src/shared/providers.ts). The Copilot generalises that from a desktop-only feature into a first-class CLI surface and pushes it in both directions. loadr explain takes a run's summary and thresholds and returns a plain-language read of what happened and where it hurt. Natural-language-to-scenario turns "ramp to 500 VUs over two minutes, hold five, hit the checkout flow" into valid YAML that passes loadr_config::validate before it's ever offered to you.
The design constraint is that the model never invents schema: generation is grounded by the same JSON Schema loadr schema emits, and every generated plan is validated by the real validator, not trusted. On our own infrastructure this runs on Bedrock with Claude. This family is more product than engine work — the mitigation for the obvious risk is that loadr already has a strict, machine-checkable definition of "a valid plan," so the model's output has a hard gate to clear.
5. Trace-Driven Root Cause
loadr can already tell you that a request was slow; it can't yet tell you why, because the "why" lives in your server's traces. Two pieces are already in place. The HTTP client injects a W3C traceparent header on every request when tracing is enabled (loadr-protocols' http.rs, make_traceparent), so loadr-generated load is already correlatable with server-side spans. And we already export metrics over OTLP (loadr-outputs' otlp.rs). What's missing is the return path: pulling the server trace back into loadr's own report.
Trace-Driven Root Cause closes it. loadr records the trace id it minted for the slowest requests, then queries your trace backend (OTLP/Tempo/Jaeger) for those exact spans and folds the server-side waterfall into the HTML report next to the client-side timing. So the report stops at "p99 was 1.4s on POST /checkout" and instead shows the span tree underneath it — the 900ms spent in a downstream call, the retry storm, the lock wait. The new engineering here is the query-and-join step and the report panel; the identifier plumbing that makes the join possible already ships.
6. A Resilience & Game-Day suite
The last family is a composition, not a new primitive. Three ingredients already exist independently. Chaos: the faults: block injects latency jitter and request drops in the load generator — no agent on the target, chaos off is deleting four lines of YAML (shipped in #71). Adversarial payloads: the DoS generator from #74. And SLO budgets and thresholds, which the engine evaluates live during a run.
The Resilience suite orchestrates these into a scripted game-day: a sequence of experiments — inject 100ms of latency, then drop 5% of traffic, then fire the algorithmic-complexity payloads at the fuzzed endpoints — each running under an SLO guard that aborts the moment the error budget is breached, so a game-day can't quietly take down a shared environment. It's the difference between "we have chaos knobs" and "we have a repeatable, budget-guarded resilience run you can put in CI." Because every ingredient already ships, this family is mostly sequencing, guardrails and reporting.
Status, honestly
None of the six is in a released build. They're grouped this way on purpose: each one is a thin new surface over an engine primitive that already ships in v1.25.0 — the recorder over har.rs, fuzzing over loadr-payload, trends over the summary format, the Copilot over the desktop AI layer and the config validator, root-cause over traceparent injection, and game-day over chaos plus payloads plus SLOs. That's the bet: keep the core small and sharp, and buy large new capabilities cheaply by composing what's already there. We'll ship them the way we shipped everything else — in small, tagged releases — and write up what actually landed rather than what we planned.