这条 Reddit 讨论显示，Claude Code 的长 Agent 会因为工具结果和对话历史持续留在上下文中，很快跨过 100k token 价格档位；把 Haiku 5.5 用作短任务子代理、限制工具和拆小工单，可能比让一个 Agent 长时间累积上下文更适合，但这些数字来自少量用户的自报，不能外推到所有工作流。
适合判断的任务：Claude Code 中的 Agent/子代理工作流、工具较多的代码仓库任务、上下文持续增长的长循环，以及需要估算 100k token 价格门槛影响的早期排查。
不适合外推的任务：把单个 Reddit 帖子的 token 记录当成 Haiku 5.5 的固定成本或普遍性能；把评论中的“约 5 倍”当作官方定价；用该帖替代自己的账单、API 用量和上下文测量。
适用的模型版本：Claude Haiku 5.5；评论中还提到 Opus 作为 orchestrator，以及 Sonnet 作为部分用户的对照，但没有统一实验。
测试环境或客户端：帖主明确标注 Claude Code Workflow；一位评论者描述了 Opus 编排 Haiku 子代理的长任务，并给出模型调用日志；未公开操作系统、Claude Code 版本、完整 system prompt、工具清单和价格账单。
推理档位和参数：未公开。评论建议通过减少工具、关闭 MCP、拆小任务和控制上下文来降低用量，但没有报告固定 effort、采样参数或随机种子。
这不是受控基准，而是一条 Reddit 主题帖及其可见评论中的个人使用报告：
原帖作者称自己在 Claude Code 的 Agent 工作流中，即使是“简单、快速”的任务，也无法把 Haiku 5.5 控制在 100k token 以下，常见范围为 100k–200k；原帖没有给出任务数量、日志截图、完整提示词或账单。
评论者 ohrajaaa 描述了从 Opus 启动 Haiku 子代理的一个实际任务：上下文约 269k token，在约第 20 次模型调用时跨过 100k；164 次调用中有 145 次（88%）超过 100k；累计输入约 31.6M token，其中大部分为缓存读取。该评论没有提供可下载的原始日志或完整任务仓库。
同一评论者建议把工单拆成迁移、任务、UI 等更小切片，指定文件范围，并让测试使用安静输出，以减缓上下文增长；这些是个人建议，不是控制变量后的实验结论。
其他评论者报告了相反或不同的体验：有人称短任务可达到更低订阅用量，也有人称把 Haiku 用于阅读和分类书籍行时出现错误归因，或更适合单轮高频任务。它们没有统一输入和评分方法，应作为观点单独看待。
使用场景：Claude Code Agent 工作流。
主要观察：无法在 Agent 场景中稳定保持低于 100k token；即使简单、快速任务也落在 100k–200k 范围。
帖主问题：询问其他用户是否遇到相同情况，或是否存在降低用量的方法。
| 指标 | 评论者自报数值 | 说明 |
|---|---|---|
| 当前上下文 | 约 269k token | 该长任务仍在运行时的日志值 |
| 首次超过 100k | 约第 20 次模型调用 | 之后上下文继续增长 |
| 超过 100k 的调用 | 145 / 164（88%） | 评论者称一旦跨过后，后续调用都会留在该区间 |
| 累计输入 | 约 31.6M token | 评论者称大部分为缓存读取 |
| 任务类型 | 迁移、夜间任务、管理页面、评测等 | 评论者以 “N16 size” 举例，未提供任务原文 |
有评论者建议移除不用的工具、关闭 MCP，并说明完整工具栈可占用 30k token 以上；这是一条评论中的估计，没有测量方法。
有评论者报告使用 Opus orchestrator、Haiku 子代理时，多数子代理在 90k–120k token；另一次任务约消耗 300k–400k Opus token，结果约 100k。该评论没有完整日志。
有评论者称短任务、新会话和精简 system prompt 可能把上下文控制在 20k–30k；没有给出可复现输入和统计周期。
有评论者称 Haiku 5.5 更适合单轮、重复次数很多的任务，并自报速度约 3 倍、订阅用量下降约 11 倍；原帖没有实验细节，不能与其他评论直接比较。
原帖正文：Claude Code Workflow；Agent 场景通常超过 100k；简单、快速任务约 100k–200k。
子代理日志评论：上下文约 269k；约第 20 次调用越过 100k；145/164 次调用超过 100k；累计输入约 31.6M token，大部分为缓存读取。
可见建议：每个短任务启动新的 Haiku 子代理；将工单拆小；只让 Agent 访问相关文件；减少工具和 MCP；测试使用安静输出；对旧工具结果使用摘要加可重新获取的 ID。
价格门槛讨论：评论者把超过 100k 的用量描述为更高价格档位，并有评论概括为“5x prices”。原帖没有附官方价目表或账单，本文只把它记录为社区说法。实际价格必须按具体平台的 input、cache read、cache write、output 计费规则，以及是否超过 100k token 分档重新核算。
这条讨论最明确的信号是：长时间运行的 Agent 会把工具结果、文件内容和历轮消息留在上下文里，导致一次任务持续跨过 100k token；对这种工作流，限制工具范围、拆分工单、指定文件和使用短生命周期子代理是值得验证的配置方向。它不能证明 Haiku 5.5 在所有 Agent 任务上都会超过 100k，也不能证明短任务一定落在某个固定 token 区间。
100k 是本帖讨论的成本分界线，但“超过后约 5 倍”只出现在评论者的口头概括，不是本帖提供的官方价格数据。缓存读取、输入 token、输出 token 和不同平台的价格档位可能不同；应以目标平台账单和 API 用量为准。
帖内还出现了性能和质量相反的体验：有人认为它适合机械性子任务，有人认为 Sonnet 更适合真实工作，也有人报告短任务效率提升。由于输入、模型档位、工具、上下文和评价标准都不一致，这些内容只能作为选型假设，不能合并为模型排名。
在 Claude Code 中固定一个短任务和一个长任务，记录模型 ID、effort、system prompt、工具清单、MCP 状态、仓库范围和每轮 input_tokens、cache_read_input_tokens、output_tokens。
分别运行单一长会话、每个子任务新建 Haiku 会话、限制工具和指定文件四种配置，记录首次跨过 100k 的调用次数、跨过后的调用比例、总成本和任务完成情况。
将测试输出改为安静模式，并对不再需要的工具结果只保留摘要和可重新获取的 ID，再重复相同任务。
按目标平台的官方价格表分别计算不超过和超过 100k token 的输入、缓存读取、缓存写入和输出费用；不要用 Reddit 评论中的“5x”替代实际计费公式。
对代码迁移、UI、夜间任务和评测等不同工单单独统计，报告样本数、失败类型、工具步数、token 分布和成本，避免用一条长任务概括所有 Claude Code 使用场景。
Claude Haiku 5.5
