Repository navigation
Conversation
Automatic compaction plans for the model's window. An agent can now carry its own, set by a plugin as request.settings.compactionWindow (tokens): the ceiling for that agent's sessions is reckoned from the smaller of the two, with the usual reserve. Agents that share a model compact at different sizes. The trigger runs before any plugin hook in a step, so a plugin that calls session.compact lands a step late; this keeps the decision in one place.
![opencodejr[bot]](https://avatars.githubusercontent.com/in/5497873?s=60&v=4){kind=small}
There was a problem hiding this comment.
The change works as described. With compactionWindow: 50000 on an agent, automatic compaction is skipped at 33,999 tokens and runs at 34,000. Without the key, or with a window bigger than the model's, the model's own ceiling still applies. I checked this with the new test, which fails against the base compaction.ts and passes with the change. The full session-compaction suite passes (36 tests), and so does tsc -b for packages/core.
Public API: no typed or documented API changes. The change adds one new key that agent.request.settings accepts, compactionWindow (a positive integer, in tokens), which only lowers the automatic ceiling. It is backwards compatible: agents without the key behave as before. Only plugins (agent.transform) can set it; agent request blocks in config files copy only headers and body.
Main concern: how the setting is exposed (see the inline comment). Otherwise the logic looks sound: it only lowers the limit, leaves the summary request and native compaction alone, and also applies to the background-precompute ceiling.
| * size to the model's limits. | ||
| */ | ||
| const autoLimit = (context: SessionContext.Loaded): SessionContext.Loaded["model"]["limit"] => { | ||
| const window = context.agent.info.request?.settings?.["compactionWindow"] |
There was a problem hiding this comment.
request.settings is the provider-request settings bag (Provider.Settings). For models, these settings are passed to the SDK as provider options, and the schema already has a typed compaction field there. Putting an untyped compactionWindow key in the same bag has some downsides:
- It isn't in any schema or docs, so it can only be found by reading this function.
- Config can't set it:
config/plugin/agent.tscopies only an agent'sheadersandbody. - If agent request settings are ever merged into the model's settings, the way headers and body are meant to be, this key would be sent to the provider.
A typed setting would avoid all three. That could be a field on the agent (for example compaction: { window } in the agent schema and config) or a typed entry next to Provider.Settings.compaction. Maintainers should decide which shape they want before this is merged.
Issue for this PR
Closes #61696
Type of change
What does this PR do?
Automatic compaction can now plan for an agent's own window. An agent may carry
request.settings.compactionWindow(tokens), which a plugin sets inagent.transform. The ceiling for that agent's sessions is reckoned from the smaller of it and the model's window, with the usual buffer. It never raises the model's window and leaves the summary request alone. Agents that share a model can then compact at different sizes.The change is one function,
autoLimit, used where the automatic trigger computes its ceiling.How did you verify your code works?
packages/core/test/session-compaction.test.ts: an agent's window lowers the automatic ceiling for its sessions only. It fails without the change.bun test test/session-compaction.test.ts(36 pass) andbun run typecheckinpackages/core.Screenshots / recordings
Not a UI change.
Checklist
Added by the opencode bot (AI-generated).
Related: #43703, #56744