16KiB 上限的由来

16KiB 是什么的上限

单条消息正文的默认上限：16384 字节（UTF-8 计）。它不是随便拍的数——一条正文要同时穿过三层东西：你敲命令的 shell（引号矩阵）、crosschat 的命令行解析、对端会话的投递管道（claude 腿更窄，64KiB 封顶）。16KiB 是“一段认真写的任务描述或代码片段“的从容体量，再大的内容本质上是文件——就该走文件的路（落盘发路径），而不是塞进消息正文硬扛每一层。

默认值只管“没配置时的兜底“；它从来不设上限——上限是你自己一层层提的。

三层来源与静默降级

上限三层来源，优先级从高到低：

--max-body-kb 64        ← 单条消息（这一条要大）
CROSSCHAT_MAX_BODY_KIB  ← 环境变量（这台机器常态要大）
16384（16KiB）           ← 兜底默认

设计细节在非法值的行为里：非正整数（abc、0、-8、1.5）不报错，静默降级到下一层。理由是威胁模型的选择——“配置是给操作者的旋钮，不是给攻击者的面”：一个被污染的环境变量最多让上限回到默认，不该让命令崩掉。同一旋钮在启动器（crosschat claude --max-body-kb）上却是当场报错——那里是人在终端前的一次性输入，报错立刻可改；send 侧面对的是 agent 的自纠循环，报错反而打断它。同旋钮两种脾气，都是刻意的。

端点硬顶与绝对上界

配置再大，两道天花板收口：

• 端点硬顶：claude 投递腿 64KiB、codex 腿 1MiB——这是传输通道的物理天花板，生效上限 = min(你的配置, 端点硬顶)。到硬顶的报错明说“提额无效“，不指一条走不通的路。
• 绝对上界：配置值封顶 16MiB——无论哪层来源，再大的数字都按此截断。存在的意义是确定行为：任何配置组合的上限都有界，系统里没有“理论上无限“的路径。

跨机另有 1MiB 的出发前预检线（远端形态未知，按最宽端点预检、对端复检），见投递语义与限制。

报错只指走得通的路

超限报错的教学文案是分层生成的，原则一句话：只教当前传输能兑现的。单机未到硬顶 → 教提额；到端点硬顶/绝对上界 → 明说提额无效、教落盘发路径；跨机 ssh → 教 scp 三步；tcp → 教文件通道；远端来件被拒（读报错的是发送方）→ 绝不教发送方提额（管不到接收方），只教接收方操作者或 scp 旁路。这套分支的用户确认版文本被测试逐字锁死——改一个字都是回归。

它不保护上下文

⚠️ 最常被误解的一条：16KiB 与限流都不是“上下文保护“。crosschat 不管理任何 agent 的上下文窗口，一条 16KiB 的正文照样占对方上下文的一万六千字符——大小上限管的是传输层走不走得通，不是对话该不该这么长。对话长度的治理是轮次：turn 计数是里程表，--max-turn 预算是收尾提醒（软的、双方可见的）。把这两个概念讲反，整个系统的设计就讲反了——这也是本书反复回到这条红线的原因。