﻿# Decide whether a plan belongs in conversation history

- **Status**: Todo
- **Kind**: Chore
- **Authors**: jp
- **Date**: 2026-09-18
- **Label**: domain=conversation
- **Label**: domain=llm
- **Label**: package=jp_cli
- **Label**: type=question

This workspace's `plan` tool (`.jp/mcp/tools/plan.toml`) writes its state into
tool call responses, which live in the conversation stream.
Every call leaves a copy, so a long task accumulates stale plans in history, and
the built-in compaction rule (`tool_calls = "strip"`) targets exactly those
events.

The harness study in T-0n0nwz3 deliberately does neither.
Its planning component holds the plan in external state and re-injects the
current version before each model call, "rather than appending previous copies
to the persistent trajectory".

## Why it might matter

Their planning result for the two strongest models is a cost result: roughly 30%
cheaper on SWE-Bench, with success rates 2.0 and 0.4 percentage points lower.
The saving is almost entirely post-edit verification, not localization or
repair.
Those are the cells that correspond to JP's users, who run frontier models.

Their weak-model result (+11.6 points for Nemotron-3 30B, at higher cost) does
not transfer.

## Why it might not

- The evidence is one prompt and one update mechanism, ablated only at their
  default T4/128k setting.
  The paper says so in its limitations.
- JP is interactive.
  The human is often the planner, and the value of a machine-maintained plan is
  correspondingly lower.
- Re-injection needs a slot in `Thread` for per-request ephemeral content that
  does not exist today.
  It would have to sit after the cached prefix so prompt caching survives, which
  is a constraint the paper never faced.

## What to do

Nothing yet.
Record per-turn usage first (T-0n0pgw6), then look at whether verification churn
and accumulated stale plan copies show up in real sessions.
If they do, the design question is where per-request ephemeral content lives in
`Thread`, which is worth an RFD rather than a patch.

Filed to keep the question findable, not to schedule it.

Findings and the rest of the proposals: T-0n0nwz3.
