Record why autocompact cannot be handed to a driver yet
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
1 parent
aa6d9b256e
commit
9c4df43951
1 file changed
+13
-6
@@ -19,10 +19,17 @@ one in place when it turns out to need a decision.
|
||||
## Session settings
|
||||
|
||||
- [ ] Autocompact belongs in session settings; empty disables it, which is the
|
||||
default. **Needs a decision before building** — nothing called autocompact
|
||||
exists yet on either side. `PLAN.md` has it only as a planned pi-driver
|
||||
feature (`set_auto_compaction`), and Claude Code runs its own. So this is
|
||||
a new server feature, and the open questions are what the empty-or-not
|
||||
value *is* (a token count? a percentage of the context window?) and which
|
||||
drivers it applies to.
|
||||
default. Iris chose "hand it to the driver" — only where a driver has
|
||||
auto-compaction of its own. **That option was offered on a false premise
|
||||
and is not buildable yet.** It named pi's `set_auto_compaction`, but pi
|
||||
was never built as a driver here: `session/llama.rs` talks to
|
||||
`llama-server`'s OpenAI-compatible endpoint directly, and its `compact()`
|
||||
refuses outright. Claude Code's auto-compaction is the CLI's own and
|
||||
nothing in the stream-json control protocol this app uses configures it.
|
||||
So the setting would be stored, passed to a driver, refused by every one
|
||||
of them, and the field would never appear on any session. What is needed
|
||||
first is either a driver that can take it, or a different rule — the
|
||||
server watching `contextTokens` and running `/compact` itself is the one
|
||||
that would work today, for Claude sessions, and it is the option that was
|
||||
not chosen.
|
||||
|
||||
Reference in new issue
Block a user