[hallerite]

Why

A prompt that a limit cut short ended with ACP stop reason end_turn unless the limit was the agent's own max_tokens. A client that reads only the ACP stop reason took a run stopped by max_total_turns, max_total_tokens or a failed compaction for one the agent finished. ACP has stop reasons for exactly this: max_turn_requests and max_tokens.

What

last_stop_reason	ACP stop reason before	after
done	end_turn	end_turn
max_total_turns	end_turn	max_turn_requests
max_total_tokens	end_turn	max_tokens
token_budget (the policy's max_tokens)	max_tokens	max_tokens
compaction_failed	end_turn	max_tokens

The snapshot's last_stop_reason still names the exact cause. depth_limit stays end_turn: it only stops a child started past max_depth, never an ACP session's root.

What verifiers sees

Verifiers reads both the ACP stop reason and the snapshot, but for rlm the snapshot wins, so its stop conditions do not change. Checked against verifiers main at eaab317a8. Each rlm turn goes through three steps, in order (verifiers/v1/acp/__init__.py):

1. It stores the ACP stop reason unchanged in trace.info["acp_stop_reason"].

2. The rlm harness reads the snapshot's last_stop_reason and stops the trace (verifiers/v1/harnesses/rlm/harness.py, _TRUNCATION_STOPS):

   last_stop_reason	verifiers stop condition
   max_total_turns	max_turns
   max_total_tokens	max_total_tokens
   token_budget	max_output_tokens
   compaction_failed	compaction_failed

3. The generic ACP mapping (_STOP_CONDITIONS) turns max_tokens into max_output_tokens and max_turn_requests into max_turns.

Trace.stop keeps the first condition it is given, so step 2 always beats step 3. With this change the two agree anyway; only the snapshot can tell max_total_tokens and compaction_failed apart.

The only change verifiers will see: for an rlm rollout cut short by a limit, trace.info["acp_stop_reason"] changes from end_turn to max_turn_requests or max_tokens. Nothing in verifiers or prime-rl reads that field; it is only stored.

The change matters for ACP clients that do not read the rlm snapshot: editors such as Zed, other generic ACP hosts, and the end-to-end suite in #244. They used to be told end_turn for a run that a limit cut short.

Tests and docs

Test. test_acp_stop_reason_names_the_spent_limit runs the real engine behind RLMACPAgent with scripted replies, one case per limit plus a normal answer, and checks both the ACP stop reason and the snapshot. The turn and tree-token cases fail without the fix. A failed compaction is not triggered here; it shares the table. The unit suite passes (400).

Docs. The README states the mapping. #245 moves the README into docs/, and #244's end-to-end budget test checks only the snapshot; whichever lands after this updates docs/runtime-contract.md and can assert the ACP stop reason too.

🤖 Generated with Claude Code

---

Note

Low Risk
Behavior change is limited to ACP PromptResponse.stop_reason for limit cases; snapshot metadata and non-limit paths are unchanged.

Overview
ACP prompt responses now surface limit-driven stops instead of reporting end_turn whenever the engine stopped for tree turn/token caps or compaction failure.

RLMACPAgent maps engine stop_reason values through _ACP_STOP_REASONS: max_total_turns → max_turn_requests, and max_total_tokens, token_budget, and compaction_failed → max_tokens. Normal completions still return end_turn; the session snapshot’s last_stop_reason continues to carry the precise engine cause.

The README documents this mapping. test_acp_stop_reason_names_the_spent_limit exercises the real engine via ACP for normal completion and each limit policy, asserting both the ACP stop_reason and snapshot last_stop_reason.

^{Reviewed by Cursor Bugbot for commit 3b6f844. Bugbot is set up for automated code reviews on this repo. Configure here.}