Q: What was the original problem?

V4 Pro can exhibit materially different reasoning and execution trajectories under different harness request surfaces.

In some observed runs, the reasoning follows a reactive, exploratory pattern:

Let me check...
Let me try...
Let me inspect another file...

In others, it follows a more joint-planning pattern:

We need to locate...
We should verify...
We can test this assumption...

These phrases are useful descriptions of an observed trajectory. They are not ability scores. we does not prove that a run is more intelligent, and let me does not prove that a model is degraded.

The important observation is narrower: a model carrying the same product label can take materially different paths when the surrounding harness constructs a different request.

Q: Do we know which variable causes the difference?

No. The available observations do not isolate one universal cause.

A harness can change several variables together:

• the system prompt and persona;
• which tool schemas the model can see;
• how verbose those schemas are;
• skills, repository instructions, and runtime context;
• conversation and tool-call history;
• reasoning configuration and output-token budget;
• the way the provider request is assembled.

Persona may matter. Tool exposure may matter. Their interaction may matter. Token budget or injected skills may also alter the trajectory. Different tasks, languages, model variants, and sample sizes add further uncertainty.

The useful working hypothesis is therefore not simply “the prompt changed” or “the model changed.” It is:

Observed agent behavior is produced by the Model × Harness combination.

Replay Lab is designed to investigate that combination without pretending that one comparison has already established the causal mechanism.

Q: What did xiaobright/modeltest find?

xiaobright/modeltest compared V4 Pro under different harness configurations and reported task-specific differences in trajectory style and results. That work helped turn an informal complaint about model behavior into a testable harness question.

It also exposed a practical DSH tradeoff:

The resulting Anchored Standard preset is a two-stage community workaround: it uses a narrow bootstrap request and later promotes the agent to a broader capability surface.

Anchored Standard is motivating evidence and a useful Replay Lab candidate. It is not proof that phased exposure always improves V4 Pro, that Standard is universally worse, or that one particular tool or persona caused the reported difference.

The comparisons retain important confounders, including maxTokens, skill directory injection, persona, schema verbosity, task selection, small sample sizes, and V4 Flash results that did not show the same outcome pattern.

Q: What is a Request Surface?

Step back from tools and presets for a moment and ask the simplest question:

What actually determines the model's behavior?

It is tempting to imagine an agent request like this:

user prompt → model → output

The actual request is closer to this:

user prompt
+ system prompt and persona
+ visible tool schemas
+ conversation and tool-call history
+ reasoning configuration
+ token budget
+ skills and runtime context injected by presets or plugins
───────────────────────────────────────────────────────────
= Request Surface
        ↓
      model
        ↓
  trajectory and output

Request Surface is everything the model actually receives before it starts generating.

The user prompt is one part of that surface, not the whole surface.

Q: How do presets, plugins, and configuration affect it?

A preset assembles an agent configuration, such as its persona, tools, and runtime behavior. A plugin can add tools, context, or request hooks. Configuration selects and parameterizes those components, including model settings and budgets.

Changing a preset or plugin can therefore produce a chain like this:

change preset or plugin
  → persona, tools, context, history, or budget may change
  → the effective Request Surface changes
  → the model may follow a different execution trajectory
  → checking only the user prompt may lead to an incomplete diagnosis

This is why a preset name such as Minimal, Standard, or Anchored Standard is not sufficient experimental evidence. The name describes an intended configuration; the effective request evidence describes what reached the provider-bound request.

Q: Why are ordinary before-and-after comparisons difficult?

Two independently created sessions may differ in more than the preset being tested. The prompt may have changed slightly, the workspace may have moved on, the injected context may be different, or the provider settings and token budget may no longer match.

Without a shared case and provenance boundary, the comparison often becomes:

change preset
  → behavior changes
  → inspect two loosely related sessions
  → guess which difference mattered

That can generate a useful hypothesis, but it is a weak basis for causal claims.

Q: What does Replay Lab actually replay?

Replay Lab starts from one real, completed DSH turn. That completed source turn becomes the observed baseline; Replay Lab does not execute the baseline again.

For one approved experiment, it:

selects one completed DSH turn
  → freezes its replay case and provenance
  → uses its captured turn-start workspace checkpoint when available
  → selects one preset or agent-scoped plugin candidate
  → requires explicit approval
  → creates one isolated candidate session
  → reruns the completed turn's prompt in an isolated workspace copy
  → restores candidate files to their checkpoint at the terminal boundary
  → records effective candidate request evidence and execution metrics
  → compares the candidate with the observed baseline

This is a new candidate execution of the same completed task/turn, not playback of previously recorded text.

Q: What does “freeze” mean here?

Freeze does not mean that Replay Lab stores and resends a byte-for-byte copy of the old provider request.

It means Replay Lab creates a stable replay case containing the selected turn's identity, prompt and prompt hash, provider, model, reasoning setting, maxTokens, observed preset label, system and tool-schema fingerprints, baseline evidence, source workspace path, and freeze-time workspace hash.

For live turns observed by the plugin, Replay Lab attempts to capture the workspace at turn/start, including dirty and untracked files. Git sources use an internal commit/tree and detached worktree; non-Git sources use a disjoint file snapshot without running git init. The candidate is materialized from that checkpoint. If no historical turn-start checkpoint is available, the current implementation falls back to an isolated checkpoint of the current source state and records its capture provenance; that run is a post-turn-state rerun, not a strict S0 replay.

This wording matters: Replay Lab freezes the case and provenance, then records and compares observed request-surface evidence. It does not claim to freeze the entire old Request Surface as a reusable payload.

Q: Why require explicit approval and an isolated workspace?

Planning a candidate is read-only. Explicit approval is the boundary that authorizes one selected candidate experiment to call the model and execute its available tools.

The candidate runs in a validated workspace copy rather than rewriting the source session or working directly in the source workspace. Path-containment guards keep structured candidate and subagent file operations inside that copy. Success, failure, and abort preserve durable session evidence but restore candidate files to the checkpoint. The source workspace is never a rollback or cleanup target.

Several experiments can be retained for the same source turn, but each approval authorizes one candidate run.

Q: What evidence does Replay Lab compare?

Replay Lab preserves the completed source turn as independently observed baseline evidence. For the candidate, it recovers provider-bound request evidence from durable request/header events, including:

• provider, model, reasoning setting, and maxTokens when present;
• request phase;
• system-prompt fingerprint;
• tool-schema fingerprint;
• visible tool names;
• workspace source, execution, and drift provenance.

When both baseline and candidate contain complete, independent run evidence, Replay Lab produces a baseline/candidate/delta scorecard for:

• fresh input tokens;
• output tokens;
• cache-read tokens;
• duration;
• step count;
• tool-call count.

The scorecard measures recorded execution characteristics. It is not an intelligence score, a correctness evaluator, or currently a monetary-cost calculation.

Q: What can Replay Lab conclude?

Replay Lab can show:

• which completed turn served as the baseline;
• which candidate preset or plugin ran;
• whether the source workspace drifted;
• which effective candidate request evidence was recorded;
• how the independently recorded execution metrics differed;
• whether evidence was incomplete rather than silently filling gaps.

Replay Lab cannot prove from one rerun:

• which individual request-surface variable caused the difference;
• that wording such as we or let me measures ability;
• that V4 Pro is universally degraded under Standard;
• that Minimal or Anchored Standard universally improves intelligence;
• that one task generalizes across models, languages, providers, or harnesses;
• how the model's private internal routing or training mechanism works.

The goal is not to turn one workaround into a universal theory. The goal is to make Model × Harness comparisons narrower, repeatable, provenance-aware, and honest about what the available evidence can establish.