Agentic session parameters
The session profile fields of agentic mode: meaning, where to measure each and what it moves.
On this page · 3 sections
Agentic mode in the Capacity Planner describes a workload as sessions rather than requests: one task that runs many model calls, grows its context, pauses for tools and sometimes spawns sub-agents. This page is the field reference — one line per input with what it means and where to measure it. How the fields combine into a fleet, with the presets and the readout, is in Agentic mode — sizing session-based workloads.
The fields
Concurrent sessions sit next to the latency targets; the other fields form the session profile. A preset (coding agent, support agent, RAG chat, multi-agent research) fills them all; fields under Advanced can stay blank and fall back to the stated defaults.
Core — the shape of one task
| # | Field | Where to measure it |
|---|---|---|
| 01 | Turns per sessionHow many model calls one task takes from start to finish. Every tool call whose result goes back to the model is a turn; so is every human reply. | Agent traces: calls per completed task (median). Presets: coding 40, research 20, support 8, RAG 6. |
| 02 | Prefix tokens (system prompt + tools)The part every session shares verbatim: system prompt, tool/function schemas, fixed instructions. It opens every context. | Tokenize your system prompt plus the tool definitions you send. Tool-heavy agents are typically 3–10k. |
| 03 | Prompt tokens per turn (p50)New tokens that arrive each turn: the user message, a tool result, or retrieved documents. The median, not the mean. | Gateway logs: input tokens minus the previous turn's context. RAG: chunks per query × chunk size. |
| 04 | Output tokens per turnTokens the model generates per turn: reasoning, the tool call or the answer. | Gateway logs: completion tokens per call (median). Reasoning models are much higher. |
Rhythm — how many streams are live at once
| # | Field | Where to measure it |
|---|---|---|
| 05 | Concurrent sessionsTasks alive at the same time — parents only; sub-agents come from the profile. Set next to the SLA fields, not in the profile. | Peak concurrent tasks from your product metrics (not requests per second). |
| 06 | Active share %Share of a session's wall time spent waiting on the model. The rest is tools running, a human reading, or network. | Trace timing: Σ(model latency) ÷ task duration. Autonomous coding agent ~60%, human-in-the-loop support ~25%. |
| 07 | Burst factorHow peaky the load is: the p99 of simultaneously active turns divided by their mean. 1 = perfectly even. | Per-second active-request counts over a busy hour: p99 ÷ mean. 1.2–1.5 is typical; batch-triggered agents run higher. |
| 08 | Sub-agents per sessionAverage number of sub-agents alive at once per parent session (0.5 = half the time one is running). Each is a short, fresh-context session that shares only the prefix with its parent. | Count spawned sub-agent sessions × their duration ÷ parent duration. Orchestrator/worker research setups: 2–4. |
| 09 | Sub-agent turnsHow many turns one sub-agent runs before returning. Blank = a third of the parent's turns; never more than the parent. | Median call count per sub-agent task in your traces. |
Context — how big the history gets
| # | Field | Where to measure it |
|---|---|---|
| 10 | Prompt tokens per turn (p90)The heavy tail of new tokens per turn: the occasional 10k-token file read or search dump. Blank = every turn is the p50. | Same gateway logs as p50, 90th percentile. Coding agents: 4–6× the median. |
| 11 | Compact context at % of windowThe fill level of the context window at which the agent summarizes its history and starts over (Claude Code, Cursor and most coding agents do this). Blank = never. | Your agent framework's auto-compaction setting; 80% is common. |
| 12 | Summary tokens after compactionSize of the summary that replaces the history. After a compaction the context is prefix + summary. | Length of your compaction summaries; 2–4k is typical. |
Cache — what does not have to be prefilled again
| # | Field | Where to measure it |
|---|---|---|
| 13 | Cache hit rate % (override)Share of the previous turn's history still in the prefix cache when the next turn arrives. Blank = predicted by the planner. | Measured prefix-cache hits on your serving stack (vLLM / SGLang metrics, or your gateway) — use it once you have it. |
| 14 | KV offload to host RAM (GB per unit)Host memory per serving unit that keeps idle sessions' KV when VRAM runs out (LMCache, Dynamo KVBM, SGLang HiCache). | What you configure in the offload layer; bounded by the server's RAM. |
Blank fields and units
- Token counts are per turn and in tokens, not characters; use the tokenizer of the model you size.
- Prompt p90 blank means every turn is the p50 — no heavy tail, the narrowest KV reserve.
- Compaction blank means never: the history grows until the context window and is clamped there.
- Sub-agent turns blank is a third of the parent's turns, and never more than the parent.
- Cache hit rate blank lets the planner predict it from the VRAM each replica has left for idle sessions; set it once you have measured prefix-cache hits on your stack.
- KV offload blank or 0 means no host-memory tier; offloaded KV that comes back adds its PCIe reload time to TTFT.
Measuring them
Most fields come from the same two sources: your gateway or serving logs (input and completion tokens per call, prefix-cache metrics) and agent traces (calls per task, model time against task time, sub-agent spawns). The planner is most sensitive to active share, sub-agents and burst factor, which multiply the active streams, and to prompt tokens per turn and the cache hit rate, which set the prefill load. If you can measure only a few things, measure those; the compaction setting comes from your agent framework's configuration rather than from logs.