Compaction fails with 400: maxOutputSize not passed to resolveCompletionBudget in compaction path

[li-xiu-qi]

Compaction fails with 400 when using third-party model with large context window

What version of Kimi Code is running?

0.16.0

Which open platform/subscription were you using?

Self-configured third-party provider (ZhiPu / GLM 5.2 via OpenAI-compatible API)

Which model were you using?

zhipu/glm-5.2 (GLM 5.2, 1,000,000 context window, 131,072 max output)

What platform is your computer?

Windows 11 x64

What issue are you seeing?

When context compaction is triggered, the LLM API returns a 400 error:

Compaction cancelled
Error: [compaction.failed] APIStatusError: 400
max_tokens参数非法：限制数值范围[1,131072]

The root cause is that the compaction path in full.ts does not pass maxOutputSize to resolveCompletionBudget(), so the computed max_completion_tokens cap falls back to max_context_tokens (1,000,000 in this case), which exceeds the API's hard limit of 131,072.

What steps can reproduce the bug?

1. Configure a third-party model with a large context window and a smaller max output limit:

[models."zhipu/glm-5.2"]
provider = "zhipu"
model = "glm-5.2"
max_context_size = 1000000
max_output_size = 131072
capabilities = [ "thinking" ]

[loop_control]
reserved_context_size = 50000
compaction_trigger_ratio = 0.99

2. Set this model as default_model.

3. Use Kimi Code normally until context compaction is triggered.

4. Observe the 400 error: max_tokens exceeds the allowed range [1, 131072].

What is the expected behavior?

Compaction should respect max_output_size as a hard cap on max_completion_tokens, just like the main loop does.

Root Cause Analysis

There are two code paths that call resolveCompletionBudget():

Main loop path (correct) — packages/agent-core/src/agent/index.ts lines 221-224:

const completionBudgetConfig = resolveCompletionBudget({
  maxOutputSize: this.config.maxOutputSize,      // ✅ passes maxOutputSize
  reservedContextSize: loopControl?.reservedContextSize,
});

Compaction path (buggy) — packages/agent-core/src/agent/compaction/full.ts lines 264-270:

const provider = applyCompletionBudget({
  provider: this.agent.config.provider,
  budget: resolveCompletionBudget({
    reservedContextSize: this.agent.kimiConfig?.loopControl?.reservedContextSize,
    // ❌ maxOutputSize is NOT passed
  }),
  capability: this.agent.config.modelCapabilities,
});

Because maxOutputSize is not passed, resolveCompletionBudget() skips the hardCap branch (line 32-34 of completion-budget.ts) and falls through to reservedContextSize as fallback. Then in computeCompletionBudgetCap() (line 62-64), since there is no hardCap, it uses max_context_tokens (1,000,000) instead:

const cap =
  args.budget.hardCap ??
  (maxCtx > 0 ? maxCtx : args.budget.fallback ?? DEFAULT_UNKNOWN_CONTEXT_FALLBACK);

This results in max_completion_tokens = 1,000,000 being sent to the API, which rejects it.

Suggested Fix

In packages/agent-core/src/agent/compaction/full.ts, add maxOutputSize to the resolveCompletionBudget() call:

const provider = applyCompletionBudget({
  provider: this.agent.config.provider,
  budget: resolveCompletionBudget({
    maxOutputSize: this.agent.config.maxOutputSize,  // ← add this line
    reservedContextSize: this.agent.kimiConfig?.loopControl?.reservedContextSize,
  }),
  capability: this.agent.config.modelCapabilities,
});

Workaround

Set the environment variable KIMI_MODEL_MAX_COMPLETION_TOKENS=131072 — this env var has the highest priority in resolveCompletionBudget() and acts as a hardCap for both paths.

Additional information

• This bug affects third-party models with large context windows (e.g., 1M tokens) where max_context_size greatly exceeds max_output_size. Kimi's own models (e.g., K2.7 with 262K context) are less likely to trigger it.
• The code comment in computeCompletionBudgetCap() says "The provider backend computes the safe request-specific value from the serialized prompt" — but this assumption does not hold for third-party OpenAI-compatible providers that enforce a strict max_tokens limit.

[li-xiu-qi]

更新：已有相关 PR

PR #482 尝试修复此问题，方向正确（在 compaction 路径补传 maxOutputSize），但未覆盖所有场景。

PR #482 修复了什么

在 full.ts 的 compactionRound() 中补传 maxOutputSize，对齐主循环 index.ts 的做法。当模型配置了 maxOutputSize 时，compaction 的 max_completion_tokens 会使用该值而非整个上下文窗口。

未覆盖的场景

maxOutputSize 在 schema 中是 optional 的（schema.ts line 44）：

maxOutputSize: z.number().int().min(1).optional(),

大多数模型配置中没有显式设置 maxOutputSize。此时：

1. resolveCompletionBudget 收到 maxOutputSize: undefined，跳过该分支
2. 回退到 reservedContextSize，返回 { fallback: 50000 }
3. computeCompletionBudgetCap 发现没有 hardCap，且 maxCtx > 0
4. 直接返回 max_context_tokens 作为 cap ← 原始 bug 依然触发

也就是说，只要模型没配 maxOutputSize（这是默认情况），compaction 仍然会把整个上下文窗口大小当作 max_completion_tokens 发给 API。

额外发现：off-by-one

即使 API 服务端尝试自动钳制 max_tokens，Moonshot 的服务端估算存在 off-by-one 误差。实测案例：

• 服务端估算 input = 79,721 tokens → 算出 max_output = 262,144 - 79,721 = 182,423
• 但实际 input 校验值 = 79,722
• 182,423 + 79,722 = 262,145 > 262,144 → 400 错误

差 1 个 token 就炸。这个细节在 PR #482 中也未处理。

建议的完整修复

除了 PR #482 的改动外，还需要在 maxOutputSize 为 undefined 时提供保守兜底：

const maxOutputSize = this.agent.config.maxOutputSize;
const maxCtx = this.agent.config.modelCapabilities.max_context_tokens ?? 0;

const provider = applyCompletionBudget({
  provider: this.agent.config.provider,
  budget: resolveCompletionBudget({
    maxOutputSize: maxOutputSize ?? (maxCtx > 0 ? Math.min(Math.floor(maxCtx / 4), 8192) : undefined),
    reservedContextSize: this.agent.kimiConfig?.loopControl?.reservedContextSize,
  }),
  capability: this.agent.config.modelCapabilities,
});

compaction 是摘要操作，输出不需要超过上下文窗口的 1/4，8192 tokens 足够生成高质量摘要。

临时 workaround

在环境变量中设置（在 PR 合并前可用）：

export KIMI_MODEL_MAX_COMPLETION_TOKENS=8192

该环境变量在 resolveCompletionBudget 中优先级最高，会作为 hardCap 生效，同时覆盖主循环和 compaction 路径。