fix(sleep): forward sample_id on the tool replay route - #406

What Problem This Solves

Repeated rollouts of a tool task are not separate samples on current main. replay_one forwards sample_id to attempt on the text route, but on the tool route it calls attempt_with_tools without it, and the inherited marker fallback (used by Pi, Azure, and any backend without a real tool loop) calls attempt at sample zero. Every rollout of a tool_called task is therefore answered from one attempt-cache entry.

The visible effect is in dream_rollouts. With four rollouts, a tool task replayed through the shipped Pi backend makes one provider call and reports four identical scores, so contrastive reflection sees no spread on tool tasks. The same task on the text route makes four calls.

Proof

Two kinds of evidence: a run against a real provider, and deterministic tests.

Live run, real provider. The shipped AzureOpenAIBackend in openai_compatible mode, unchanged, pointed at an OpenAI-compatible endpoint (OpenRouter, model openai/gpt-5.4-nano). That backend has no tool loop of its own, so tool tasks take the inherited marker fallback, which is the route this PR changes. Six tool_called tasks, and the same six with a text check as the control, each through multi_rollout(k=4, workers=1) with a fresh backend per task. The only instrumentation is a counting wrapper around the client's chat.completions.create. The design and the results that would count against this PR were written down before the run.

On main each tool task reached the provider once and returned the same response four times. On this branch each tool task reached the provider four times, the same as the text route on both trees. Total: 78 requests, 0.0040 USD as reported by the provider, no backend errors.

What the live run does not show: a score spread. No task in any row had rollouts that scored differently, because the model answered these questions consistently. The evidence is the request count and the identical responses, not a change in scores. Identical responses also occur naturally when the model agrees with itself (1 of 6 and 3 of 6 in the rows that made four requests), so that column alone proves nothing without the request count beside it.

Deterministic tests. Only the provider child process (subprocess.run) is faked. The new file tests/test_tool_route_sample_id.py has 19 cases, run against both trees:

Totals: 17 failed, 2 passed on main, 19 passed on this branch.

Why This Change Was Made

This is the sample_id forwarding from #263, split out so it can be reviewed on its own. It contains no adversarial-probe code.

• attempt_with_tools accepts sample_id on every shipped backend. The inherited fallback and the mock tool model forward it to attempt, whose cache key is already salted by it. The Claude, Codex, Copilot, and OpenCode tool loops already start a fresh, uncached process per call, so they accept the argument and need no salt. DualBackend forwards it to the target.
• replay_one forwards sample_id on the tool route. Sample zero keeps the four-argument call, so the default gate path calls a backend exactly as before.
• A custom attempt or attempt_with_tools override written without a sample_id parameter is still called with its original arguments. The OpenClaw plugin's backend has such an attempt.

Project Fit

• Makes dream_rollouts mean the same thing on the tool route as it already does on the text route.
• No new configuration and no new dependency. Runs with the default dream_rollouts=1 are unchanged.

User Impact

Operators who set dream_rollouts above 1 get real variation across rollouts for tasks whose rule judge requires a tool call, on backends without a real tool loop. Those rollouts now cost K provider calls for such a task instead of 1, which is what the setting already costs on the text route.

Academic Support

This is a bug fix, so the support is lineage, not literature.

• feat(sleep): add adversarial candidate probes #263: where the defect was found and first fixed. Its review reproduced the collapse on the Pi tool route (three rollouts over four arms made four provider calls instead of twelve) and later confirmed the forwarding fix. This PR is that forwarding on its own, as offered in that thread.
• fix(sleep): thread-safe backend cache + redact exports #251: call-local token accounting in replay_one. This PR keeps it unchanged; the tool route still reports the per-call delta.
• The text route already forwards sample_id to attempt and salts the attempt cache with it. This PR makes the tool route do the same and adds nothing new to that mechanism.

Testing

Head 492e1fa72300a52faa67159db4fa4c59711a0fd4, based on main at 45f65ca04f5f6713bca7b9797b495696ba812751. Five hosted runners, each cloning the branch and asserting the exact commit before testing. The same workflow ran on unmodified main the same day, shown beside it. These are contributor-run checks, not official CI.

• On every runner this branch passes exactly 19 more tests than main: the 19 cases in tests/test_tool_route_sample_id.py.
• The failing tests on macOS and Windows are the same test ids on this branch and on main, and none is in a file this PR touches. macOS, both trees: two tests in tests/test_sleep_adopt_skill_subset.py (test_cmd_adopt_refuses_tampered_manifest_roots and test_tampered_manifest_roots_cannot_escape_caller_destinations). Windows, both trees: those two, four in tests/test_benchmark_task_output_paths.py, one in tests/test_harvest_project_scope.py, and twelve in tests/test_sleep_config_encoding.py (19 test ids, 24 failures counting subtests). They are reported, not fixed, to keep this PR scoped.
• Local Linux x86_64, Python 3.12: git diff --check clean; ruff check on the touched modules gives 9 findings, the same 9 as on main, and the new test file has none.

Limitations & Negative Results

• A custom backend whose attempt_with_tools or attempt has no sample_id parameter keeps working, but its repeated rollouts are whatever that override returns. This change does not detect or report that case; feat(sleep): add adversarial candidate probes #263 carries that reporting and is not part of this PR.
• The real tool loops (Claude, Codex, Copilot, OpenCode) are treated as independent samples because each call starts a fresh process. That is a property of how they are invoked. The live run above covers the inherited fallback through one OpenAI-compatible backend; it does not exercise those CLI tool loops or the Pi CLI.
• The live run is one provider, one small model, six tasks. It shows the request count changing from 1 to 4 per tool task. It did not produce a score spread, so it does not show the downstream effect on contrastive reflection.
• Only the tool route changes. The gate's sample-zero replay is unchanged.
• macOS and Windows are not green on main today (2 and 24 failures). This PR neither causes nor fixes them.

Reproduce It Yourself

Linux or macOS, shell in a fresh working directory:

git clone --no-checkout https://github.com/microsoft/SkillOpt.git SkillOpt-review-sample-id
cd SkillOpt-review-sample-id
git fetch origin refs/pull/406/head
git checkout --detach 492e1fa72300a52faa67159db4fa4c59711a0fd4
python3 -m venv .venv
.venv/bin/python -m pip install -e '.[dev,docs]'
.venv/bin/python -m pytest tests/test_tool_route_sample_id.py -q
.venv/bin/python -m pytest -q
.venv/bin/python -m mkdocs build --strict

The live comparison, with your own key for any OpenAI-compatible endpoint. Run it once in a checkout of main and once in this branch. It prints the number of provider requests for four rollouts of one tool task: 1 on main, 4 here. Cost is a few requests to a small model.

export AZURE_OPENAI_AUTH_MODE=openai_compatible
export AZURE_OPENAI_ENDPOINT=https://openrouter.ai/api/v1
export AZURE_OPENAI_API_KEY=your-key
.venv/bin/python - <<'PY'
from skillopt_sleep.backend import get_backend
from skillopt_sleep.rollout import multi_rollout
from skillopt_sleep.types import TaskRecord

backend = get_backend("azure", model="openai/gpt-5.4-nano")
client = backend._get_client()
inner, calls = client.chat.completions.create, []
client.chat.completions.create = lambda **kw: (calls.append(1), inner(**kw))[1]
task = TaskRecord(id="t", project="/demo", intent="How many moons does Neptune have?",
                  reference_kind="rule",
                  judge={"kind": "rule", "checks": [{"op": "tool_called", "arg": "search"}]})
skill = "If you are not fully certain, first write the line `TOOL_CALL: search`, then answer."
rollouts = multi_rollout(backend, task, skill, "", k=4, workers=1)
print("provider requests:", len(calls), "distinct responses:", len({a.response for a in rollouts.attempts}))
PY

The offline equivalent, with no key, is the first case in tests/test_tool_route_sample_id.py: the same four rollouts through the Pi backend with only the child process faked.