Durability costs a model call 16 to 21 ms.

The first test isolates Temporal. Both arms make the same streamed call, with the same prompt, the same model and the same client pipeline, on one machine. They take turns run by run, so any drift in the model's speed lands on both.

• Client → model. The call made directly, timed from the request to the last token.
• Client → Temporal → model. The same call inside a workflow of one activity, with the answer returned as the workflow's result. Timed from starting the workflow to the result in hand. Nothing of Continuum's is in the path: no Gateway, Postgres, Redis, Relay or fetch.

Every run's Temporal history records when the activity started and finished, so the time the client spent outside it is durability's alone: the start, the dispatch to a worker, the result coming back, and the client's call to collect it. The 2 to 4 ms the activity spends around the model call counts with the call, and the model's own spread can't show up in what is left.

At 200 runs the nearest-rank p99 is the 198th value, so no single slow run sets it. Measured this way, durability's p99 is 25 to 32 ms on every runtime and prompt: 30 ms on LM Studio, 1.5% of a 658-token answer, and 26 ms on vLLM, 0.8% of a 700-token one. Measured end to end instead, each durable run against the direct calls' fit, the long prompt's p99 is 116 ms on LM Studio and 416 on vLLM, which is the model's own spread: its direct calls alone ranged over 191 ms and 527. One run in 1,200 spent more than 100 ms outside the call, LM Studio's 4K run 126, whose workflow start took 433 ms, which fits the reconnect stall under Full service.

The second test sends the same prompt through everything the durable inference page describes: the Gateway's auth, session and writes to Postgres and Redis, the workflow, the answer streamed into Redis as the model writes it, the Relay's notice over SignalR, and the fetch. It ran on LM Studio, 200 runs per arm, because the platform is wired to LM Studio, and at the inference capability's own sampling (temperature 0.7, 4,096 tokens), which is why its answers run 80, 728 and 328 tokens.

Every host exports its spans to the Aspire dashboard, and one trace holds the Gateway's handler, the worker's workflow and activities, and the Relay's handler together. Drawn to scale, each stretch at its own p50, Continuum is two slivers around the model call. The medians sum to 33 ms; measured end to end against the direct call, the platform adds 35 ms on the short prompt and 46 on the long one. The short and long runs' spans agree to within a millisecond everywhere but the call.

Twelve of the 600 platform requests ran more than 100 ms over their median, and every one was a Temporal RPC taking 317 to 447 ms: the Gateway's StartWorkflow, the worker's dispatch, or the activity's completion. Each of those traces has a normal model span. They come about every five minutes per connection, which is when Temporal's frontend closes a client connection (frontend.keepAliveMaxConnectionAge, 5 minutes ± 10%). On the long prompt they set the p99 outside the activity, 344 ms. The short prompt and the 4K document held two each, and nearest rank leaves both past the p99.

The suspected cause is localhost, as in the two-second stall under Fine tuning. Every host reaches Temporal at localhost:7233, and the Temporal SDK's gRPC runs in its Rust core, which the .NET setting under Fine tuning doesn't reach. For a new connection it tries IPv6 first and waits 300 ms before IPv4, which fits the 317-335 ms stalls; the completions' 417-447 ms fit less well.

The Lightning runs of 2026-09-26 made their durable calls with Temporal pinned to 127.0.0.1:7233. The same stall came back at 113 to 129 ms, every time in the workflow's start: 6 of their 1,400 durable runs spent 102 to 113 ms starting the workflow, against a median of 3. All six were on the long prompts, the only runs that lasted past five minutes. That fits the pin removing the 300 ms IPv6 wait and leaving the reconnection itself, and the platform's 317 to 447 ms above is the cost without the pin.

The first run through the platform added 168 ms to the short answer. Each change after it was measured on its own before the next one went in.

Timing trivial workflows, with no Continuum code in them, found why the early runs were slow. The Aspire AppHost now starts Temporal with four settings, each measured on its own, and every run in Like for like and Full service ran on it.

• Eager activity execution (system.enableActivityEagerExecution). The worker receives the activity in the response to the workflow task that scheduled it, one hand-off fewer. It is off by default on the dev server.
• SQLite in WAL mode (journal_mode=wal, synchronous=normal). The default journal synced on every commit, 25-50 ms a hand-off. WAL at normal survives a process crash and can lose the last transactions on a power loss, a trade made for a dev server only.
• The transfer queue's poll rate (history.transferProcessorMaxPollRPS=1000). The 50 ms was the history service's reader moving new tasks to matching, limited by default to 20 polls a second. At 1,000, one remote activity fell from 100 ms to 11.
• One task-queue partition (matching.numTaskqueueReadPartitions and …WritePartitions, both 1). With the 50 ms gone, 1 run in 100 stalled for two seconds on a partition no poller was covering. The p99 went from 2,010 ms to 26. One partition suits one worker, and caps a queue's throughput across many.

These settings tune a single-node dev server. A production cluster persists to Postgres or Cassandra and runs partitions for throughput across many workers, so a cluster gets measured on its own.

On this machine every store listens on 127.0.0.1 only, and LM Studio on IPv4 only. A new .NET connection to localhost tries IPv6 first, nothing answers on ::1, and Windows takes about two seconds to give up and fall back. The connection pools hid it, since they pay it only when a connection opens. LM Studio drops a connection after about four idle seconds, so every model request after a quiet spell paid two extra seconds, and a Postgres connection opened cold took 4.1 seconds.

Every connection to the stores and the model now uses 127.0.0.1, and the AppHost sets DOTNET_SYSTEM_NET_DISABLEIPV6=1 on every project it starts. Temporal's client connects from the SDK's Rust core, which that setting doesn't reach, so it still dials localhost (see Full service). That is for the dev stack only: on an IPv6-only network it would break name resolution, and a deployment configures its own endpoints.

• Interleaved. Warmups first, then the two arms alternate, one request in flight on the whole machine, so drift in the model's speed lands on both.
• Equal output. Each run is compared with a direct call of the same length, from a Theil-Sen fit across the direct runs, so one slow run can't move it. At the fixed seed each runtime repeats one answer, so the two arms are compared at identical output.
• Checked before it starts. A preflight confirms the loaded model and its slot count match the configuration, and every answer is checked against the configured model.
• The tail outside the model. Each run's time outside the activity, from its Temporal history, is the tail measure, and a p99 is quoted only from 200 runs or more.
• Spans. Every host exports its OpenTelemetry spans to the Aspire dashboard, whose telemetry API returns one trace per request.