长上下文任务用 Claude 中转：省钱与超时经验

KingFlow · 国内直连 AI API 中转

写这篇是想把我这大半年折腾长上下文任务攒下来的经验倒一倒。所谓长上下文，就是那种一次要塞几万甚至十几万 token 进去的活儿——整份产品需求文档丢进去让它做分析、把一个仓库的核心代码一股脑喂进去让它读懂再改、或者一段跑了几十轮的长对话还要接着聊。这类任务跟"写个正则""改个函数"完全是两码事，坑也集中在两个字上：烧钱、超时。下面按我踩坑的顺序讲。

一、长上下文为什么又烧钱又容易超时

先说烧钱。长上下文任务的输入 token 通常是输出的几十倍甚至上百倍。你让模型分析一份三万字的文档，它回你两千字，可这三万字的输入是要按输入价计费的，而且每一轮对话如果都把完整历史重新塞一遍，成本是线性往上叠的。我最早不懂事，做一个整仓代码审查，来回聊了二十多轮，每轮都把整个上下文重发，一晚上的账单看得我肉疼——绝大部分钱花在了反复传输同一批前缀上。

再说超时。长输入意味着模型要先"读"完这一大坨内容才开始吐第一个字，首字延迟（TTFT）天然就长。如果你的网络链路本身还不稳，中间再走个不靠谱的代理，那首字还没出来连接就先断了。我用机场代理直连官方那阵子，长任务的失败率高得离谱：高频长连接挂个三五分钟就被识别，接连 403、429，一份长文档分析跑一半掉线，前面烧的 token 全打水漂，还得从头再来。

这两个问题叠在一起就很致命：越是长的任务越贵，越贵的任务越怕跑一半失败，失败一次的沉没成本又特别高。

二、中转怎么帮上忙

后来我转到 KingFlow 这类走官方协议的中转上，长上下文这块的体验改善主要来自两点。

一是国内直连、延迟稳。 我自己这边实测，国内节点的首字延迟一般在一两秒到三秒这个区间，不用再自己挂代理去绕。对比之前走境外链路那种动辄几十秒的 TTFT，长任务的心理压力小了很多——首字来得快，你就知道这条连接是活的，不至于干等着不知道断没断。链路稳，长任务跑到一半掉线的情况也明显少了。

二是 Prompt Cache 对长前缀的省钱效果。 这个是长上下文任务的关键。Claude 的官方协议支持 cache_control，你把那份大文档、那批仓库代码作为一个稳定的前缀标记上缓存，第一次请求正常计费并写入缓存，之后只要前缀不变，命中缓存的那部分 token 就按缓存读取的价格算，比原价便宜一大截。KingFlow 是完整透传这个能力的：带 cache_control 连发两次，第二次看返回的 usage.cache_read_input_tokens 是非零的，就说明缓存真命中了。对于输入远大于输出的长上下文场景，这一项省下来的成本通常相当可观，能砍掉很大一块（具体比例看你前缀复用得好不好，我这边多轮长对话省下来的量是很明显的）。

配置上也没什么门槛，Claude 客户端就是把 ANTHROPIC_BASE_URL 指到 https://www.kingflow.ai、ANTHROPIC_AUTH_TOKEN 填上你的 Key，模型该用哪个用哪个，一个 Key 全模型都能路由。

三、防超时配置（重点）

长任务超时，很多时候不是服务端的问题，是你客户端自己的超时值设得太保守，默认几十秒的超时对付不了一个要读十几万 token 的请求。几个必须调的地方：

Claude Code 用户，把环境变量 API_TIMEOUT_MS 调大。默认值应付短任务够用，但长上下文任务我一般直接拉到几分钟：

export API_TIMEOUT_MS=600000   # 10 分钟，按你任务长短调
export ANTHROPIC_BASE_URL=https://www.kingflow.ai
export ANTHROPIC_AUTH_TOKEN=你的Key

自己写 HTTP 客户端调 API 的，把请求超时和读取超时都放宽，别用库的默认值。以 Python 的 requests 为例：

import requests

resp = requests.post(
    "https://www.kingflow.ai/v1/messages",
    headers={
        "x-api-key": "你的Key",
        "anthropic-version": "2023-06-01",
        "content-type": "application/json",
    },
    json={
        "model": "claude-sonnet-4-6",
        "max_tokens": 4096,
        "messages": [{"role": "user", "content": "……长上下文……"}],
    },
    timeout=(10, 600),   # (连接超时, 读取超时)：读取放到 10 分钟
)

另外强烈建议长任务开流式输出。 流式下第一个 chunk 一到，连接就算"活着"，你的客户端和中间链路都不会因为长时间没数据而误判断连。非流式请求等在那儿几分钟没任何字节返回，很容易被某一层网络设备当成死连接掐掉。开了 stream: true 之后这类"假超时"基本消失。

四、省钱的几个实操习惯

1. 稳定前缀，最大化缓存复用。 把不变的大块内容（文档、代码、system prompt）固定放在消息开头并打上缓存标记，变化的部分（你这轮的具体提问）放在后面。前缀一旦稳定，后续每轮都能吃到缓存读取的低价。反过来，如果你每轮都在前缀里改点东西，缓存就失效了，等于白配。

2. 别每轮都重塞全部历史。 长对话跑久了，历史会越滚越大。我的做法是定期把前面几轮压缩成一段摘要，用摘要替代原始长历史，只保留最近几轮的原文。这样既控制了输入 token，又不至于把上文全丢了。

3. 分级处理：先 haiku 预处理，再 opus 精读。 这招在超长文档上特别省。比如一份很长的资料，我先用 claude-haiku-4-5 做粗筛、抽要点、定位到相关章节，把范围缩小之后，再把这一小部分交给 claude-opus-4-8 做深度分析。用便宜的模型干"读一遍找重点"的粗活，把贵的旗舰模型的算力留给真正需要精读的部分，整体成本能压下来不少。KingFlow 一个 Key 就能在这几个模型间随便切，改个 model 参数的事，不用维护多套 Key。

4. 顺手看后台对账。 长任务花钱快，我习惯定期去后台翻调用明细和 token 用量，看看缓存命中率、哪个模型花得多，用量透明才好优化，也不至于对不上账。

五、模型怎么选

就长上下文这个场景，我的经验是：

claude-sonnet-4-6 是我的默认。长文档分析、整仓代码通读这类"量大但不需要顶级推理"的活儿，它性价比最好，速度也快。
claude-opus-4-8 留给硬骨头。跨多文件的大重构、需要严密推理的复杂分析，才上旗舰，读得更透、改得更稳。
claude-haiku-4-5 当预处理的"前锋"，如上一节所说，负责粗筛和定位，把成本降下来。

真正长又难的任务，就是 haiku 先过一遍缩小范围、sonnet 或 opus 精读收尾这套组合拳，比全程 opus 硬刚划算得多。

FAQ

Q1：Prompt Cache 到底怎么确认真的命中了？ 带 cache_control 标记同一个长前缀连发两次请求，看第二次返回里的 usage.cache_read_input_tokens，非零就是命中了。命中之后这部分按缓存读取价计费，比首次便宜很多。前缀有任何改动缓存都会失效，所以要保持前缀稳定。

Q2：长任务老是超时，是中转的问题吗？ 多数情况是客户端超时值太小。先把 API_TIMEOUT_MS（Claude Code）或 HTTP 客户端的读取超时调到几分钟，再开流式输出。走国内直连的链路首字一般一两秒就到，如果首字很快但整体等很久，那就是任务本身长，把超时放宽即可。

Q3：十几万 token 的超长上下文，用哪个模型？ 量大不太烧脑的用 claude-sonnet-4-6；需要深度推理或大重构的用 claude-opus-4-8。更省的玩法是先用 claude-haiku-4-5 预处理缩小范围，再交给 sonnet/opus 精读。

Q4：换成中转之后原来的代码要大改吗？ 基本不用。Claude 生态改一行 ANTHROPIC_BASE_URL 指到 https://www.kingflow.ai、填上 ANTHROPIC_AUTH_TOKEN 就行；OpenAI/Codex 兼容的话把 base_url 指到 https://www.kingflow.ai/v1、填 OPENAI_API_KEY。一个 Key 多模型，切模型改 model 参数即可。