Roadmap for provider-native reasoning state and compaction comparable to the ARC-AGI-3 Provider Adapter harness

[Dusan2709]

Context

ARC Prize recently reported a substantial performance difference for the same GPT-6 Astra model on ARC-AGI-3:

• 62.7% with the provider-neutral Standard harness
• 99.9% with the Provider Adapter harness

ARC describes the Provider Adapter as preserving opaque reasoning state between requests and using provider-native compaction for longer conversations:

• https://arcprize.org/results/openai-gpt-6-astra
• https://arcprize.org/blog/astra
• https://github.com/arcprize/arc-agi-3-benchmarking

These results do not isolate the individual contribution of reasoning-state preservation versus compaction, but they strongly suggest that provider-native context management can materially affect the reliability, speed, and token efficiency of the same model.

Question

Does DSH plan to support a comparable provider-adapter execution mode?

In particular, are any of the following capabilities planned?

• continuous provider conversations across multiple model requests within one DSH agent session;
• preservation and reuse of opaque provider reasoning state;
• provider-native compaction where the provider API exposes it;
• a common DSH capability seam with provider-specific implementations;
• session events and metadata that make the active context-management mode observable.

OpenAI's Responses API appears to be one possible initial implementation target, while other providers would presumably require their own adapters and capability declarations.

DSH already provides harness-side summarization through dsh-compaction-basic, but that is semantically different from preserving provider-native opaque reasoning state and using the provider's own conversation and compaction mechanisms.

Motivation

We are integrating DSH into a deterministic orchestration workflow and need to decide whether this functionality should be developed as a separate DSH extension or whether DSH intends to provide it upstream.

If this is on the roadmap, is there already an issue, design proposal, target release, or preferred architectural seam for contributing it? If it is not planned, would the maintainers consider a provider-specific plugin or upstream contribution in this area?

[VillagerUncle02]

补两条和"推理状态如何跨压缩存活"直接相关的实测，都是从本机长会话里量出来的。

环境：dsh 0.1.5-rc.1 / deepseek-flash / contextWindow 1048576 / Windows。

1）压缩后，旧轮的推理项整段不再回传。

抓包对照（隔离 DSH_HOME + 本地代理，逐请求比对）：

请求	历史里的 reasoning item	字符数
req-0003 → req-0009（压缩前，逐轮累积）	1 → 7 条	128 → 11,344
req-0011（第一个带 checkpoint 前言的请求）	旧 7 条全部不在	只剩 1 条 5,247 字符的本轮新推理

也就是说 checkpoint 一落地，之前所有轮的推理链就整体消失了，不是被压缩，是不在请求里。
DeepSeek 在带 tools 时是要求回传 reasoning_content 的，所以这块丢的是模型的连续性，
不是报错。

2）被丢掉的推理，在摘要器输入里占了大头。

本机 9 次压缩的摘要器输入合计 11,530,164 字符，其中推理 6,784,438 字符 = 58.8%；
摘要合计 95,907 字符（推理:摘要 ≈ 70.7:1，输入:摘要 ≈ 120.2:1）。

而 COMPACTION_INSTRUCTION（dsh-compaction-basic/lib/index.js:220-255）的保留清单列的是
路径 / 命令 / 错误串 / 标识符 / 数值 / 函数签名 / 语法片段 + 用户反馈，
完全不要求保留推理。README 里也写明 "Only returned text enters the checkpoint,
excluding reasoning and tool calls"——所以这更像是"保留清单没覆盖到"，而不是有意排除。

结果：压缩掉的内容里近六成是推理链，而摘要规则并不要求留下它。

没做的部分：我只证明了"推理链被删"这个机制和文本对照，没有测"推理链丢失 → 行为退化"的
因果。如果 roadmap 里要做这块的评估，这条缺口需要单独设计实验。

（如果这个方向已经有对应的 issue/讨论，请告诉我编号，我去那边补数据。）

影响的能力

• 推理链连续性 / 跨轮上下文：压缩落地后旧轮推理整体不再回传，影响的是模型
  "接着上一轮的想法继续"的能力，而不是它知不知道做了什么决定。
• 长任务相关：是（压缩只发生在长任务）。

[Dusan2709]

Thanks for sharing these measurements — this is very helpful and directly relevant to the question I was trying to raise.

What I find particularly important here is that this now demonstrates a concrete semantic difference between the current DSH compaction path and provider-native conversation state:

• before compaction, DeepSeek reasoning state is carried across requests;
• after the checkpoint is created, the previous reasoning items disappear entirely from the request;
• the checkpoint therefore preserves selected observable information, but not the provider's reasoning continuity itself.

As you correctly point out, this does not yet prove causality between losing that reasoning state and degraded agent behavior. But it gives us a much better basis for designing the missing experiment.

I think the next useful step would be an A/B test with the same model, task set, tools and orchestration:

A: current DSH compaction behavior
B: provider conversation/reasoning state preserved across requests, with provider-native compaction where available

Then compare at least:

• task success rate / correctness;
• recovery after compaction;
• repeated or contradictory decisions;
• number of model calls;
• total input/output tokens;
• wall-clock latency.

If there is a measurable difference, that would make the architectural question much clearer: provider-native state handling should probably become an explicit DSH capability rather than being treated as an implementation detail of compaction.

This also reinforces my original question about whether DSH should expose a common capability seam such as:

conversation state / reasoning state / native compaction

with provider-specific implementations and a harness-side fallback when a provider does not support them.

If maintainers are interested, I would be happy to help define the experiment or contribute to a first provider-specific implementation.