LLM drift detection

A provider can update a model behind an API, a prompt edit can alter responses, or quality can decline gradually while every request still succeeds. LLM drift detection measures these changes by sampling live traffic, tracking defined behaviour dimensions, and comparing each current window with a pinned baseline. Replay evaluation runs captured sessions through the same or another Surface, so you can investigate a regression or assess a model, prompt, or safety-pipeline change before changing production traffic. Governance records →

Drift monitoring

Drift monitoring compares an LLM Surface’s current behaviour with its approved baseline. A model can continue to return successful responses while becoming slower, more expensive, more likely to refuse requests, less safe, or less semantically consistent. The comparison makes these changes visible before they become difficult to trace to a particular model, prompt, retrieval, or configuration change.

It samples real interactions and tracks key behavior dimensions such as:

• Refusal rate
• Safety-flag rate
• Latency
• Response length
• Output tokens
• Cost
• Schema validity
• Semantic stability (quality score & semantic distance).

These measurements are stored over time and compared against a pinned baseline for that surface. The main purpose is operational awareness: detect behavioral change, compare it to a known-good baseline, and optionally trigger alerts or block problematic changes from being saved.

Enable drift monitoring

Drift monitoring is off by default. Add the Drift Harness to an LLM Surface and enable monitoring to start deriving dimensions from sampled traffic. The same sampled interactions provide the prompts and completions used by replay evaluation.

In the surface builder, drag the Drift Harness enhancement from the Palette onto the Surface’s LLM drop target. The enhancement runs alongside the other optional LLM Surface components.

Set the sample rate to define the percentage of live Surface traffic captured for monitoring and replay. A lower rate reduces the volume of captured sessions on high-traffic Surfaces while retaining a representative workload.

Choose a rate that reflects the traffic volume, evaluation needs, and cost of replaying captured sessions. The selected rate determines how much live traffic contributes to the monitoring data and replay corpus.

Configure the warning and drift thresholds that classify changes from the baseline:

The LLM Drift monitoring page displays the captured measurements for each Surface. Use the current measurement window to review normal behaviour, then set a baseline that represents the behaviour you want to preserve.

Drift dimensions

Each dimension is its own time-series line, so a surface can drift on one axis while staying stable on the others:

Every dimension marked Production sampling above derives from data the gateway already produces on the request path, so it fills in from ordinary traffic with no extra cost or dataset. Quality score and semantic distance are graphable only once a replay evaluation has actually run against the surface’s captured sessions. Response length, refusal rate, and the session capture that feeds replay evaluation all need a buffered, non-streaming response to measure; a streamed call is skipped for these three, while the other production dimensions still fill in either way.

Replay evaluation requires an embeddings model to calculate semantic distance. A dimension with no eligible samples or no pinned baseline has unknown status, rather than stable or drift. Quality score and semantic distance remain unpopulated until a replay evaluation runs.

Baselines and the warn/drift verdict

A baseline is a snapshot: pressing Set baseline pins the mean of each dimension over the window that is current at that moment as the surface’s “normal.” Every later window is compared back to it as a relative change, classified against two per-surface thresholds (25% and 50% by default): within the warn threshold is stable, past it but short of the drift threshold is warn, and past the drift threshold is drift. The surface’s overall status is always its worst dimension, so one regressing axis is enough to flag the whole surface. A near-zero baseline (an idle refusal rate of 0, say) is floored per dimension before the relative change is computed, so a tiny absolute move can’t read as infinite drift.

A surface can optionally block saves on regression: while it is currently drifting past its baseline, saving its configuration is refused until the baseline is re-pinned or the guardrail is turned off, so a change can’t ship over an unacknowledged regression.

Alerting through Integrations

Crossing into drift fires a drift.detected event carrying the surface, the dimension, the baseline, the current value, and the delta. It routes through the same Integrations subsystem used elsewhere in Agent Stream, to whichever integrations are chosen under the dedicated LLM Drift category, or to the surface’s own event mappings when none are chosen. The cadence is per-surface: the alert fires once on entering drift, re-fires no more often than a configured interval, stops after a configured maximum count, and goes quiet once the surface recovers to stable.

Replay evaluation and cross-surface comparison

While monitoring is on, sampled interactions are also captured as indicative sessions: real prompts and completions, retained per surface. A replay evaluation, run on demand or on a schedule, re-executes those captured sessions through a surface’s full governed pipeline, comparing each new answer to the one originally captured, and folds the result into the quality and semantic-distance dimensions.

Testing and evaluating other models and configurations

The replay separates the source of the captured sessions from the target surface or variant that actually executes them, defaulting to the same surface as a self-check. Pointing the target at a different surface or variant replays real, previously-captured traffic through a different model, prompt, or Judge/Jury pipeline: an evidence-based way to see how a candidate change would have performed before switching over. A self-run folds into the surface’s own dimensions; a cross-surface run is inspect-only, shown and saved to run history without touching the baseline it is compared against.

Enterprise use cases

• Provider and model changes. Replay captured sessions through a candidate surface or variant before changing production routing.
• Prompt and pipeline changes. Examine the effect of prompt, model, Judge, Jury, or Expert Witness changes against a representative workload.
• Operational monitoring. Watch customer-facing or compliance-sensitive surfaces for changes in latency, cost, refusals, safety flags, schema validity, or semantic stability.
• Governance and incident response. Use baselines, dimension history, replay results, and drift alerts as evidence when investigating a change in AI behaviour.

Retention

Captured sessions and run history are each retained per surface, capped by count (defaults of 200 sessions and 50 runs) enforced on every write, with an optional age limit re-applied by a periodic sweep so a surface that has gone idle still gets pruned. Both are encrypted at rest.

Why this matters

Drift dimensions turn a silent model update or a slow quality regression into a graph, not a customer complaint:

• Sampling from data the gateway already produces means the production-sampling dimensions above cost nothing extra to collect.
• Cross-surface replay means an upgrade decision, a new model, a tweaked prompt, a different Judge or Jury, can be tested against a surface’s own real, captured workload instead of a guess.

Related

• Variants and progressive rollout: How a cross-surface replay’s target surface or variant compares to routing rules and canary splits as a way to evaluate a change.
• Observability: How drift’s dimension charts stay on their own dedicated page rather than the main telemetry dashboard.
• Cost and usage governance: How a replay run spends through the same budgets and limits as any other call.
• Surfaces: Where the Drift Harness sits alongside a surface’s other optional configuration.
• Governance records: The signed, per-interaction transcript that drift monitoring’s sampled traffic complements.