Fix hallucinated FINAL() answers with Claude 4.6 models

[huiwenn]

Problem

Claude 4.6 models (Sonnet and Opus) behave differently from earlier models when generating RLM responses. Instead of generating a code block and stopping to wait for execution feedback, these models continue generating past the code block — they hallucinate what they think the execution output will be, reason over that hallucinated output, and then commit to a FINAL() answer, all within a single turn.

For example, when asked "Which are the top 10 most spending customers?" with real customer data in context, Sonnet 4.6 would:

1. Generate print(context) inside a ```repl ``` block (correct)
2. Continue generating completely fabricated output (e.g. "Alice: $1200, Bob: $450, Kevin: $5200" — none of which exist in the actual data)
3. Reason over that fabricated output and provide FINAL(1. Kevin: $5200, 2. Hannah: $4500, ...) — a confidently wrong answer based on hallucinated data

The code blocks are executed correctly and produce the real results, but because find_final_answer() finds the FINAL() in the same response, the completion loop exits immediately. The real execution results are never fed back to the model, and the hallucinated answer is returned as-is.

This is a fundamental mismatch: the RLM loop assumes models will stop after generating a code block and wait for feedback, but Claude 4.6 models do not — they eagerly generate the full response, including predicted outputs and final answers, in one shot.

Fix

Skip text-based FINAL() detection when the response contains code blocks. If code blocks are present, the model may have hallucinated the output, so we discard any FINAL() found in the response text and instead feed back the real execution results via format_iteration(). The model then sees the actual data and provides the correct answer in the next turn.

This does not affect:

• FINAL_VAR() from code execution — still works, since it retrieves real variables from the REPL
• FINAL() in text-only responses (no code blocks) — still works, since the model is answering based on results it received in prior turns

Verification

• All 234 existing unit tests pass
• Live-tested with Sonnet 4.6: model hallucinated fake customer data in iteration 1, self-corrected after seeing real execution results in iteration 2, and returned the correct answer (Eve Davis at $31,445.20 as top spender) in iteration 3

[rolson24]

Can't you just use a stop token at the end of the repl block? Set the stop token to be something like "```\n`

[alexzhang13]

This is a weird problem that's quite model dependent, let me think on it more. Ideally we'd like to have less hacky solutions to this...

[LMS927369]

Adding a concrete repro for #127 in case it helps with prioritization.

Repro (rlms 0.1.1, Claude 4.6 Sonnet/Opus, verified 2026-05-04):

• 7 Python source files, 60,663 tokens routed through the recursive pipeline
• Output included 152 tokens of fabricated AES-CBC findings on a file using
  only AES-GCM
• The model committed to FINAL() past a code block without waiting for
  execution feedback — exactly the failure mode this PR describes

Context: this lives in a downstream production code-review pipeline doing

60K-token corpus compression before security review. The hallucinated
cryptography finding would have shipped as a false-positive security
audit result if not caught by a regression test.

The full-mode path is globally disabled in our config until #127 merges.
The branch (fix/skip-premature-final-with-code-blocks) appears to address
this exact case — happy to test it against our repro corpus and report back
if that helps shake review loose.

[LMS927369]

Follow-up to my earlier comment — I dug deeper and want to correct the framing.

PR #127 appears to be superseded by main. Commit a740331 (merged via #162, new_final_answer_format) removed find_final_answer() and the entire text-FINAL parsing path. The model can no longer drive a FINAL() result from prose; the only termination signal is answer["ready"] = True set inside a real REPL execution. That structurally eliminates the hallucination class this PR was patching — post-block prose is now inert.

I verified against main by writing three regression tests that exercise the exact failure mode (model emits a repl block + hallucinated trailing FINAL(...)):

tests/test_premature_final_regression.py::test_hallucinated_trailing_final_does_not_terminate_run  PASSED
tests/test_premature_final_regression.py::test_code_block_without_answer_ready_does_not_terminate  PASSED
tests/test_premature_final_regression.py::test_trailing_text_after_real_repl_completion_is_ignored PASSED

All three pass on main and the full test_multi_turn_integration.py suite still passes alongside them (18 passed in 14s).

Two notes that might be useful:

1. Close Fix hallucinated FINAL() answers with Claude 4.6 models #127 as superseded by New dict-based Final Answer format #162? The targeted patch isn't needed and the diff no longer applies — find_final_answer is gone.
2. Release cut? Current PyPI rlms==0.1.1 (2026-02-18) predates new_final_answer_format, so downstream consumers can only get the fix via a git+main pin. A 0.1.2 / 0.2.0 would unblock that.

Happy to open a PR with the regression tests against main if you'd like them locked in — written to existing conventions (Mock-based, no new deps, mirrors test_multi_turn_integration.py's pattern).

[huiwenn]

Thank you for digging in to this - The problem has been resolved by the dict-based fix. I'll close this PR.