如果你已经在 CCSub 上用 Claude Opus 4.8 或 Sonnet 4.6 跑主力任务，大概率会遇到一个尴尬问题：真正贵的不是写代码那几次调用，而是那些本来不值得动用大模型的重复请求——格式化日志、给函数补 docstring、把一长串报错压成三行摘要、把 80 个文件重命名成统一风格。这些活儿交给 Opus，账单会很难看；交给一个便宜模型，效果几乎没差别。
claude-haiku-4-5 就是为这个场景准备的。它已经在 CCSub 的模型列表里（同时存在 claude-haiku-4-5 和带日期的 claude-haiku-4-5-20251001 两个条目），但很多人还没把它接进自己的调用链。下面按「怎么接 → 怎么分工 → 出错怎么查」三步说清楚。
为什么值得单独给 Haiku 留一个位置
从 CCSub 后台的真实用量看，压力高度集中：gpt-5.6-sol 近 30 天被调用 2200 次，输出 328 万 token，花费约 1504 美元；gpt-5.5 则是 184 次调用、约 194 美元。也就是说，绝大多数成本来自少数高频的大模型调用。
这类用量里通常有一半以上的请求是「低判断力需求」：不需要复杂推理，只需要稳定的格式输出和足够快的响应。把它们迁到 claude-haiku-4-5 上，是用同样的接口、同样的密钥、同样的客户端，换一个 cost 更低的分工方式。
分层不是省钱技巧，而是容量管理。把便宜模型放在入口做过滤、摘要、分类，把贵模型留给真正需要判断的那一步，整体质量不会掉，账单会掉。
第一步：确认模型可用，再准备密钥
接入前先用一次请求确认模型 ID，避免后面拿着一堆参数到处怀疑。CCSub 提供统一的模型查询接口：
curl https://ccsub.xyz/v1/models \
-H "Authorization: Bearer sk-你的CCSub密钥"
返回列表里应该能看到 claude-haiku-4-5、claude-opus-4-8、claude-sonnet-4-6 等条目。如果只看到 Opus/Sonnet 而没有 Haiku，通常是你用的密钥或分组与模型分组不匹配，而不是模型下架了。
密钥在 CCSub 控制台创建，形如 sk-你的CCSub密钥，建议按用途分开建：一个给主力大模型，一个给 Haiku 批处理，方便后面单独看用量和成本。
第二步：三种接入方式，选你正在用的那种
Claude Code（Anthropic 原生协议）
Claude Code 走的是 Anthropic Messages 协议，只需要把 base URL 指到 CCSub：
export ANTHROPIC_BASE_URL=https://ccsub.xyz/api
export ANTHROPIC_AUTH_TOKEN=sk-你的CCSub密钥
客户端会自动向 https://ccsub.xyz/api/v1/messages 发请求，不需要你手写 endpoint。模型名在启动参数或项目配置里指定，把子任务模型写成 claude-haiku-4-5，主模型仍保持 Opus 4.8 或 Sonnet 4.6。
OpenAI 兼容客户端（Cursor、VS Code 插件、CherryStudio、Windsurf、OpenCode、OpenClaw 等）
这些工具多数支持自定义 OpenAI 接口，填两个值即可：
OPENAI_BASE_URL=https://ccsub.xyz/v1
OPENAI_API_KEY=sk-你的CCSub密钥
# 实际请求地址：
# https://ccsub.xyz/v1/chat/completions
模型字段直接写 claude-haiku-4-5。如果客户端有「小模型 / 补全模型 / inline model」这样的独立设置项，那里就是放 Haiku 的最佳位置。
Codex（Responses 协议）
Codex 用的是自己的 Responses 协议，需要单独配置：
base_url = "https://ccsub.xyz/openai"
wire_api = "responses"
配置完成后 Codex 会自动请求 https://ccsub.xyz/openai/responses，你不需要手动拼接路径。需要提醒的是：Codex 侧重代码代理任务，Haiku 4.5 更适合承担其中的检索、摘要、命名类子步骤，主推理步骤仍建议留给大模型。
第三步：写一套能落地的分层调用链
真正省钱的不是「把模型换成 Haiku」，而是「哪些请求不出 CCSub 就直接降级」。一个简单可用的映射规则：
- 入口分类 / 意图识别：Haiku 4.5。判断这条请求是改代码、查文档还是纯闲聊。
- 长上下文整理：Haiku 4.5。把几十个文件、几万行日志压成结构化摘要。
- 代码补全与重命名：Haiku 4.5。模式明确、单文件范围内的小改动。
- 批量小任务：Haiku 4.5。生成 commit message、写注释、按模板改写。
- 架构设计、跨文件重构、疑难 bug 定位：Opus 4.8。
- 常规功能实现、需要中等推理的任务：Sonnet 4.6。
用伪代码表示就是这样一条链：
def route(task):
if task.is_simple() or task.is_batch():
return "claude-haiku-4-5"
if task.needs_deep_reasoning():
return "claude-opus-4-8"
return "claude-sonnet-4-6"
关键点是：Haiku 不是「降级到没办法了才用」，而是默认的第一站。只有被它判定为复杂的请求，才上升到大模型。至于 Haiku 的适用边界，经验上可以用一句话切分——它擅长读懂已经确定的目标，不擅长自己确定目标。长上下文整理、代码补全、批量小任务属于前者；开放式架构决策属于后者，别硬塞给它。
Haiku 4.5 不适合硬上的场景
- 需要跨十个以上文件做一致重构，容易漏改。
- 需要长链条因果推理的排障，比如「为什么线上只在周二晚上出现超时」。
- 需要仔细遵从复杂约束的生成任务，约束一多就容易丢条件。
遇到这些，直接升到 Sonnet 4.6 或 Opus 4.8，比反复重试 Haiku 更省钱。
常见报错：模型不存在与上下文超长
模型不存在（model not found / 无可用渠道）
先区分两种可能。一是模型 ID 写错了，比如写成 claude-haiku-4-5-2025-10-01 这种带短横线的日期格式，正确写法是 claude-haiku-4-5 或 claude-haiku-4-5-20251001。二是密钥分组与模型不匹配，到控制台确认该密钥能访问 Haiku。
上下文长度超限
切到 Haiku 后最容易踩的坑，是把原本喂给 Opus 的超大上下文原样丢过去。上线前先检查三件事：
- 输入里是不是塞了整仓库的文件内容，而不是检索后的片段。
- 是否开着自动携带全量对话历史，长会话会越滚越大。
- 批处理任务是否把多条请求合并成一次调用。
解决办法是接入前做一次检索裁剪，只把相关片段传给 Haiku；长会话定期压缩；批任务拆成单条或小批。记住一个原则：Haiku 的价值在于处理大量小而干净的请求，不是处理一个巨大的请求。
连接类错误
如果报的是连接失败而不是模型错误，多半是本机网络、代理设置或客户端超时导致的，与模型选择无关。近期 CCSub 侧的错误统计里，connect_error 和 upstream_unavailable 是主要类型，前者通常出在本地链路，可以先用一条最简 curl 验证是否通得过。
成本与充值提醒
接入完成后，建议按模型分开看用量。Haiku 单次调用便宜，但如果入口分类逻辑写得不好，可能出现「一次用户请求触发五六次 Haiku 调用」的情况，总量反而上去了。上线前先用小批量真实流量跑一天，对比 Haiku 与 Sonnet 在同样任务上的输出质量与 token 消耗，再决定阈值。
另外提醒一句：切模型不会改变账户余额的消耗速度，只改变同样任务花掉多少钱。如果你当前的用量集中在少数大模型上，先做分层，再评估是否需要调整充值额度。
现在就可以做的三件事
- 用
GET https://ccsub.xyz/v1/models确认claude-haiku-4-5在你账号下可用。 - 在你正在用的客户端里把「小模型 / 补全模型」一栏改成
claude-haiku-4-5，主模型保持不变，先跑一天看看效果。 - 把上一周最贵的那批重复请求列出来，逐条判断能不能迁到 Haiku；不能迁的，留给 Opus 4.8 或 Sonnet 4.6。
如果你还在配置阶段，可以先看 CCSub 文档里的安装配置与价格说明，再回来调整模型映射；接入过程中遇到报错，故障排查页里有按症状分类的速查表，能省掉不少试错时间。