如果你最近把主力工作流切到 GPT-5.6 Sol，又觉得账单里输入 Token 掉得特别快，先别急着怀疑计费。大多数情况下，输入 Token 偏高不是平台算错了，而是你的调用结构决定了「读」远多于「写」。
以 CCSub 近 30 天的一组真实用量为例：gpt-5.6-sol 共 720 次调用，输入 3,956,782 token，输出 1,081,416 token，输入输出比约 3.7:1。也就是说，每花 1 份钱在模型「说话」上，就有约 3.7 份钱花在模型「读材料」上。这篇教程就带你用 CCSub 的用量与账单记录，把这三倍多的输入拆到具体来源，再逐项优化并验证效果。
一、先确认：你的输入 Token 是不是真的「异常」
输入比输出高是常态，尤其是带工具调用、带代码上下文的场景。判断是否异常，看两个指标：
- 输入输出比：问答类任务通常在 2:1 到 4:1 之间；代码类、Agent 类可以到 5:1 以上。超过 8:1 才值得重点排查。
- 单次调用平均输入：用账单里该模型的输入 Token 总数除以调用次数。上面那组数据是 3,956,782 ÷ 720 ≈ 5,495 token/次。如果单次平均输入突然翻倍，但你的提问没变长，多半是上下文堆积。
先登录 ccsub.xyz，进入用量与账单页面（可参考 入门使用手册 中「看懂 Token 明细」一节），按模型筛选 gpt-5.6-sol，记录下近 7 天与近 30 天的调用次数、输入 Token、输出 Token 三个数字，后面每一步优化都要回来对比。
二、把输入拆成四类来源
同一个「输入 Token」数字背后，通常混着四种成分。你要做的是把它们分别记账：
1. 系统提示词与工具定义常驻
系统提示词、角色设定、工具（function calling）的 JSON Schema，会在每一次请求里重复发送。一个定义 10 个工具的 Agent，工具描述就可能占到 1,500 到 4,000 token。720 次调用乘以 2,000 token，就是 144 万输入 Token，占了上面那组数据的三分之一还多。
2. 多轮对话历史未裁剪
如果你把完整对话数组原样回传，第 20 轮的请求会携带前 19 轮的全部内容。历史是线性增长的，总输入却是平方级增长的。这是长会话里输入 Token 失控最常见的原因。
3. 代码文件整包注入
把整个仓库或整份文件贴进上下文，是输入 Token 的另一个大头。日��开发里真正被用到的往往只有几个函数，其余都是背景噪音。
4. 重试导致的重复请求
超时、网络中断、客户端自动重试，都会把同一份输入再发一遍。近 7 天 CCSub 侧记录的 connect_error 与 upstream_unavailable 类错误，就可能带来这类「看不见的重复输入」。这类请求同样会消耗 Token。
三、用 CCSub 账单逐项核对
核对的核心思路是：做一次受控实验，看单次调用的输入 Token 底数是多少。
- 在用量页筛选 gpt-5.6-sol，记录当前时间点的累计输入 Token。
- 用最小请求打一发：只发一句「你好」，不带历史、不带工具、不带文件。
- 回到用量页刷新，看这一次调用增加了多少输入 Token。这个数字就是你的「空载底数」，主要由系统提示词和工具定义构成。
- 再发一次带完整系统提示词和全部工具定义的请求，看增量。两者之差即常驻开销。
- 最后用你真实业务里的一次典型请求重放，看增量。与前面的底数相减，就是历史与文件注入的贡献。
用 OpenAI 兼容方式做这个实验最直接：
export OPENAI_BASE_URL=https://ccsub.xyz/v1
export OPENAI_API_KEY=sk-你的CCSub密钥
curl $OPENAI_BASE_URL/chat/completions \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-5.6-sol",
"messages": [{"role": "user", "content": "你好"}]
}'请求地址就是 https://ccsub.xyz/v1/chat/completions，返回体里的 usage.prompt_tokens 即本次输入 Token。把每次实验的 prompt_tokens 记下来，比只看账单总数更直观。
如果你用的是 Codex，配置里把 base URL 指向 https://ccsub.xyz/openai，并把 wire_api 设为 responses，客户端会自动请求 /openai/responses。Responses 接口的输入统计口径与 Chat 接口略有差异，建议固定用同一种接口类型做前后对比，否则数字不可比。
用 Claude Code 的话，把 ANTHROPIC_BASE_URL 设为 https://ccsub.xyz/api，客户端会自动请求 /v1/messages。模型列表随时可以通过 GET https://ccsub.xyz/v1/models 查询，确认你手上的模型 ID 拼写正确，避免因为写错模型名触发失败重试而白白消耗输入。
四、四类来源对应的裁剪动作
- 系统提示词与工具定义：删掉从未被调用过的工具；把冗长的工具描述压成两三行；把固定不变的长指令放到首条消息，并尽量利用缓存读取能力降低重复计费。工具数量从 10 个减到 4 个，往往能直接砍掉一半常驻开销。
- 多轮历史：只保留最近 N 轮，更早的内容做摘要后再带入；或把关键结论写进一条「状态摘要」消息，替换掉原始历史。长会话建议每 5 到 8 轮压缩一次。
- 代码注入：不要贴整文件，只贴相关函数与调用点；先让模型列出它需要的文件，再按需提供。这一步在代码类场景里通常能省下 60% 以上的输入。
- 重试重复：给客户端设置合理的超时与最大重试次数；遇到
connect_error先按 故障排查 检查网络与代理，而不是让程序无脑重试。失败请求的输入同样会计入用量。
经验值：把「空载底数」压到单次 1,000 token 以内，把历史控制在最近 6 轮，多数业务场景的输入输出比能回落到 2:1 附近。
五、验证优化是否真的生效
每改一项，做一次前后对比，别一次全改，否则无法归因：
- 改完后跑 20 次真实业务请求。
- 在用量页记录新增的输入 Token 总量，除以 20，得到新的单次平均输入。
- 与优化前的 5,495 token/次（或你自己的基线）对比，算出降幅。
- 同时观察输出 Token 是否明显变少。如果输出质量下降导致你要追问更多轮，省下的输入可能又被多轮对话吃掉。
成本上也要算一笔账。GPT-5.6 Sol 在 CCSub 的卖价是输入 56、输出 168、缓存读取 5.6（单位与站内定价页一致）。输入单价约为输出的三分之一，但输入量是输出的 3.7 倍，所以输入仍然贡献了总成本的一半以上。只优化输出、不优化输入，收益是有限的。
六、常见排查误区
- 只看总额不看均值：总额高可能只是调用次数多。先算单次平均输入，再判断是否异常。
- 混用接口做对比：Chat 与 Responses 的统计口径不同，前后对比必须同口径。
- 忽略失败请求：错误重试消耗的输入不会在成功响应里体现，但会出现在账单里。
- 过早归因于平台：先用「你好」这种空载请求测出底数，多数疑问在这一步就能自证。
七、下一步行动
如果你还没开始，建议按这个顺序推进：注册账号并充值（见 注册与充值），创建 API 密钥，然后把上面的空载实验跑一遍，建立自己的输入 Token 基线。充值前先估算月度用量，小额多次比一次性大额更稳妥；如果用量波动大，先用少量额度验证优化效果，再决定是否加大投入。
接入完成后，把 Codex 或 Claude Code 的工作流固定下来，定期回来看用量页的输入输出比。输入 Token 偏高不可怕，可怕的是不知道它高在哪一部分。把这四类来源拆清楚，你的 GPT-5.6 Sol 账单就能从「看不懂」变成「可控制」。
CCSub API 调用方法
如果你使用 OpenAI 兼容客户端，把 Base URL 设置为 https://ccsub.xyz/v1，API Key 使用控制台创建的 sk-你的CCSub密钥。
export OPENAI_BASE_URL=https://ccsub.xyz/v1
export OPENAI_API_KEY=sk-你的CCSub密钥Codex 请使用原生 Responses 专用地址。先设置密钥：
export CCSUB_API_KEY=sk-你的CCSub密钥再在 ~/.codex/config.toml 配置自定义 provider：
model = "gpt-5.6-sol"
model_provider = "ccsub"
[model_providers.ccsub]
name = "CCSub"
base_url = "https://ccsub.xyz/openai"
env_key = "CCSUB_API_KEY"
wire_api = "responses"Claude Code 使用专用 Messages Base URL：
export ANTHROPIC_BASE_URL=https://ccsub.xyz/api
export ANTHROPIC_AUTH_TOKEN=sk-你的CCSub密钥需要确认当前可用模型时，可以请求 GET https://ccsub.xyz/v1/models。正式长任务前，建议先用短请求验证 Key、余额和模型是否正常。