实测 10 款模型：在 Claude Code 中读一张图，Token 为什么暴涨了 250 倍？

在 Claude Code 里，让模型分析本地截图是一项很常见的操作。

但这次测试发现，同一张图片通过不同入口传入，结果可能完全不同：直接拖进对话窗口时，10 款模型都能正常处理；让 Claude Code 使用 Read 工具读取时，除 Claude 官方模型外，9 款第三方模型全部出现失败或 Token 消耗异常。

正常情况下，一张测试图片大约消耗 2,000 tokens。异常时则会飙升到 40 万～50 万 tokens，相差约 200～250 倍。对上下文较小的模型，这会直接触发 API Error 400 或 context_length_exceeded；对拥有超长上下文的模型，请求可能勉强成功，但不代表兼容性正常。

先说结论

• 使用 Claude 官方模型：Read 工具和拖拽图片均可正常工作。
• 使用第三方模型：不建议通过 Read 工具读取本地图片，优先直接拖拽到对话窗口。
• 本轮拖拽读图成功率为 100%：测试的 10 款模型均正常，Token 消耗约 2,000。
• Read 工具对第三方模型的兼容性明显异常：3 款直接失败，6 款虽然返回结果，但消耗约 40 万～43 万 tokens。
• 底层原因尚未得到官方确认：从现象推测，可能与 tool_result 中嵌套图片块的协议转换有关，Base64 也可能被错误当成普通文本。

本文结论来自当前环境和本轮测试，不代表不同 Claude Code 版本、网关或适配器未来一定保持相同行为。

到底发生了什么？

本轮测试对比了两种本地图片读取方式。

方式一：让 Claude Code 调用 Read 工具

模型先发起工具调用，Claude Code 读取本地图片，再把图片作为工具结果返回给模型。

测试结果：

• Claude 官方模型正常；
• 9 款第三方模型全部出现兼容性问题；
• 部分请求直接失败；
• 部分请求表面成功，但 Token 消耗达到约 40 万～50 万。

方式二：把图片拖进对话窗口

用户直接将本地图片拖拽到输入框，再附上问题发送。

测试结果：

• Claude 官方模型正常；
• 9 款第三方模型也全部正常；
• 10 款模型的 Token 消耗均回到约 2,000；
• 本轮没有观察到 Read 工具路径中的上下文暴涨问题。

两种方式的差别有多大？

从使用结果看，差异非常直接：

• Claude 模型：Read 工具正常，拖拽也正常。
• 第三方模型：Read 工具全部异常，拖拽全部正常。
• 正常图片消耗：约 2,000 tokens。
• 异常图片消耗：约 400,000～500,000 tokens。
• 异常放大倍数：约 200～250 倍。

因此，如果你正在 Claude Code 中使用 GPT、豆包、阶跃、MiMo、Kimi、Qwen、Grok、Gemini 或 MiniMax 等第三方模型，最稳妥的临时方案不是反复重试 Read，而是直接把图片拖到对话框。

本次测试覆盖哪些模型？

本轮共测试 10 款模型：

1. claude-haiku-4.5
2. gpt-5.6-luna
3. doubao-seed-2-1-turbo-260628
4. step-3.7-flash
5. mimo-v2.5
6. kimi-k3
7. qwen3.7-plus
8. grok-4.5
9. gemini-3.5-flash
10. MiniMax-M3

其中，claude-haiku-4.5 是本轮唯一通过 Read 工具正常读取图片的模型，消耗约 2,000 tokens。

另外 9 款第三方模型的 Read 工具结果分成两类：

直接失败

• gpt-5.6-luna：返回 {"read_success": false}，消耗约 400,000 tokens。
• doubao-seed-2-1-turbo-260628：API Error 400，消耗约 450,000 tokens。
• step-3.7-flash：context_length_exceeded，记录约 410,390 tokens。

返回成功，但消耗明显异常

• mimo-v2.5：约 400,000 tokens。
• kimi-k3：约 420,000 tokens。
• qwen3.7-plus：约 430,000 tokens。
• grok-4.5：约 410,000 tokens。
• gemini-3.5-flash：约 400,000 tokens。
• MiniMax-M3：约 420,000 tokens。

这些“成功”不能理解成兼容性良好。它们只是没有在当前上下文限制下立即报错，但 Token 消耗已经远超正常图片输入。

接下来按模型逐一展示 Read 工具与拖拽读图的完整测试数据和截图。

10 款模型逐一实测

每款模型都展示两条路径：

• Read 工具测试截图与对应缓存/Token 记录；
• 拖拽图片测试截图与对应缓存/Token 记录。

这样既能看到模型是否给出答案，也能判断它是否以合理的 Token 成本处理图片。

1. Claude Haiku：两种读图方式均正常

模型：claude-haiku-4.5
提供商：Anthropic
上下文窗口：200k
Read 工具结果：成功
Read 工具 Token 消耗：约 2,000
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

Claude Haiku 是本轮唯一在 Read 工具路径下表现正常的模型。图片被正确识别为视觉输入，没有出现数十万 Token 的异常膨胀。直接拖拽图片时也同样正常。

这说明 Claude Code 自身具备正常传递图片工具结果的能力，问题更可能出现在第三方模型或中间适配层对该消息结构的处理上。不过，这仍然只是基于对照结果的推测。

Read 工具读图结果

Read 工具缓存与 Token 记录

拖拽图片结果

拖拽图片缓存与 Token 记录

2. GPT：Read 返回失败，拖拽恢复正常

模型：gpt-5.6-luna
提供商：OpenAI
Read 工具结果：返回 {"read_success": false}
Read 工具 Token 消耗：约 400,000
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

通过 Read 工具传图时，GPT 没有正常完成图片理解，并返回读取失败；同时，上下文记录已经膨胀到约 40 万 tokens。

改为直接拖拽同一张图片后，模型能够正常处理，消耗也回到约 2,000 tokens。这组对比说明，模型本身具备图片理解能力，异常集中在 Read 工具传递图片的路径上。

Read 工具读图结果

Read 工具缓存与 Token 记录

拖拽图片结果

拖拽图片缓存与 Token 记录

3. 豆包：Read 触发 API Error 400

模型：doubao-seed-2-1-turbo-260628
提供商：字节跳动
Read 工具结果：API Error 400
Read 工具 Token 消耗：未知，模型直接报400错误，请求也未发送过去
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

豆包在 Read 工具路径下出现 API Error 400，请求未发送过去。结合其他模型的现象看，请求很可能在图片内容进入第三方协议时发生了异常膨胀。

把图片改为直接拖拽后，豆包可以正常理解图片，Token 消耗也恢复到约 2,000。这同样表明问题不在模型有没有视觉能力，而在图片通过何种消息结构进入模型。

Read 工具读图结果

拖拽图片结果

拖拽图片缓存与 Token 记录

4. 阶跃星辰：Read 直接超过上下文限制

模型：step-3.7-flash
提供商：阶跃星辰
Read 工具结果：context_length_exceeded
Read 工具 Token 消耗：总token超出message的最大token数，请求未发送过去
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

阶跃星辰在 Read 工具路径下直接返回上下文超限，直接报400错误。

拖拽图片后，请求能够正常完成，说明图片理解能力本身没有问题。对于上下文窗口无法容纳异常 Base64 文本的模型，这类问题会直接表现为 context_length_exceeded，而不是“成功但费用异常”。

Read 工具读图结果

拖拽图片结果

拖拽图片缓存与 Token 记录

5. MiMo：能够返回答案，但 40 万 Token 并不正常

模型：mimo-v2.5
提供商：小米
Read 工具结果：成功，但消耗异常
Read 工具 Token 消耗：约 400,000
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

MiMo 通过 Read 工具读取图片时能够返回结果，但输入消耗约 40 万 tokens。它没有立即失败，不代表协议兼容正常；更可能是较大的上下文窗口容纳了异常展开的图片内容。

拖拽同一图片后，Token 消耗回到约 2,000。对真实业务来说，应把这种“成功但放大约 200 倍”的结果视为异常，而不是可接受的降级。

Read 工具读图结果

Read 工具缓存与 Token 记录

拖拽图片结果

拖拽图片缓存与 Token 记录

6. Kimi：Read 消耗约 42 万 Token

模型：kimi-k3
提供商：Moonshot
Read 工具结果：成功，但消耗异常
Read 工具 Token 消耗：约 420,000
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

Kimi 的情况与 MiMo 类似：Read 工具路径最终给出了结果，但上下文消耗约 42 万 tokens。对于长上下文模型，这类错误有时不会立刻变成 API 报错，却会大量占用窗口并放大成本。

改用拖拽方式后，图片读取恢复正常，说明 Kimi 的视觉能力可用，异常仍然集中在 Read 工具返回图片后的协议适配环节。

Read 工具读图结果

Read 工具缓存与 Token 记录

拖拽图片结果

拖拽图片缓存与 Token 记录

7. Qwen：Read 成功，但消耗达到约 43 万 Token

模型：qwen3.7-plus
提供商：阿里云
Read 工具结果：成功，但消耗异常
Read 工具 Token 消耗：约 430,000
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

Qwen 在 Read 工具路径下没有直接报错，但约 43 万 tokens 是本轮“成功组”中较高的一档。这样的请求会快速挤占上下文空间，也可能影响后续多轮对话和工具调用。

直接拖拽图片后，消耗恢复到约 2,000 tokens。本轮结果不支持在第三方模型上继续使用 Read 工具进行批量图片处理。

Read 工具读图结果

Read 工具缓存与 Token 记录

拖拽图片结果

拖拽图片缓存与 Token 记录

8. Grok：Read 消耗约 41 万 Token

模型：grok-4.5
提供商：xAI
Read 工具结果：成功，但消耗异常
Read 工具 Token 消耗：约 410,000
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

Grok 通过 Read 工具读取图片时能够返回内容，但 Token 消耗约 41 万。拖拽图片后，消耗下降到正常的约 2,000。

同一模型、同一张图片，仅改变图片进入对话的方式，就出现约 200 倍差距。这进一步说明，模型视觉能力并不是本轮问题的主要变量。

Read 工具读图结果

Read 工具缓存与 Token 记录

拖拽图片结果

拖拽图片缓存与 Token 记录

9. Gemini：Read 消耗约 40 万 Token

模型：gemini-3.5-flash
提供商：Google
Read 工具结果：成功，但消耗异常
Read 工具 Token 消耗：约 400,000
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

Gemini 同样能够在 Read 工具路径下返回结果，但约 40 万 tokens 的消耗明显不正常。改用拖拽方式后，模型正常识图，消耗回到约 2,000。

这一结果再次说明，“模型返回了答案”并不是判断图片通道是否兼容的充分条件。还必须同时检查输入 Token、上下文占用和后续对话是否受到影响。

Read 工具读图结果

Read 工具缓存与 Token 记录

拖拽图片结果

拖拽图片缓存与 Token 记录

10. MiniMax：两张 Read 测试图均显示异常消耗

模型：MiniMax-M3
提供商：MiniMax
Read 工具结果：成功，但消耗异常
Read 工具 Token 消耗：约 420,000
拖拽读图结果：成功
拖拽 Token 消耗：约 2,000

MiniMax 的 Read 工具测试保留了两张结果截图。模型能够输出内容，但上下文消耗约 42 万 tokens，与 MiMo、Kimi、Qwen、Grok 和 Gemini 属于同一类异常。

拖拽图片后，识别结果和 Token 使用都恢复正常。对于批量读图或长对话，这种 Read 路径仍然不建议使用。

Read 工具读图结果一

Read 工具读图结果二

Read 工具缓存与 Token 记录

拖拽图片结果

拖拽图片缓存与 Token 记录

看完 41 张截图，可以得到什么？

这组截图展示的是非常一致的对照：

• Claude 官方模型通过 Read 工具和拖拽读图都正常；
• 9 款第三方模型通过 Read 工具时全部异常；
• 第三方模型改用拖拽后全部恢复正常；
• Read 路径下的异常输入集中在约 40 万～50 万 tokens；
• 拖拽路径下的正常输入约为 2,000 tokens。

因此，现阶段最有操作价值的判断是：第三方模型的视觉能力没有普遍失效，真正需要规避的是 Claude Code Read 工具返回图片后的兼容路径。

为什么会出现 40 万 Token？四种可能原因

下面的分析全部来自测试现象，未经 Claude Code、模型厂商或适配器提供方确认。它们用于帮助排查，不应当写成已经证实的底层结论。

可能原因一：协议转换层没有正确处理工具结果中的图片

Claude Code 原生使用 Anthropic 消息协议。第三方模型通常需要经过网关或适配层，再转换成 OpenAI、Google 或其他厂商的请求格式。

拖拽图片时，图片可能直接作为用户消息中的顶层视觉内容块出现；Read 工具返回图片时，图片则可能嵌套在 tool_result 中。适配层如果只处理前一种结构，就可能在后一种路径中出错。

排查时可以抓取转换前后的请求，重点查看：

• 是否存在有效的 image_blocks；
• 文本字段 text_length 是否突然达到数十万字符；
• 图片内容是否同时出现在 image 和 text 两类字段中；
• 同一张图片是否在历史消息里被重复附加。

可能原因二：适配器只认识顶层 image，不认识嵌套 image

适配器可能支持这样的结构：

message.content[].type == image

却没有递归处理这样的结构：

tool_result.content[].type == image

一旦缺少嵌套内容块转换，常见的错误处理方式可能包括：

1. 对整个 tool_result 执行 JSON.stringify 或 json.dumps；
2. 把 Base64 原文放进普通 text 字段；
3. 图片块和 Base64 文本同时保留，造成重复输入；
4. 在多轮历史中反复附加同一张图片。

可能原因三：Base64 被按普通文字计算 Token

正常的视觉模型不会把整段 Base64 当作自然语言逐字符编码，而是先解析为图片，再根据尺寸和视觉编码规则计算 Token。

本轮数据呈现出非常明显的数量级差异：

• 正常识别为图片：约 2,000 tokens；
• 疑似按 Base64 文本处理：约 400,000～500,000 tokens；
• 两者相差约 200～250 倍。

这个差异能够直接解释两种异常：上下文较小的模型立即报错，拥有大上下文的模型勉强返回结果，但成本和上下文占用严重失控。

可能原因四：多轮历史重复携带图片数据

另一种需要排查的情况，是图片 Base64 在多轮工具调用中被重复放回历史消息。

如果单次图片已经被错误展开成几十万字符，再重复一遍，很快就会超过上下文上限。验证时应逐轮比较请求体，确认图片数据只保留一份，并且始终位于目标厂商规定的视觉字段中。

现在怎么解决？

方案一：第三方模型直接拖拽图片

这是当前最简单、兼容性也最好的临时方案，适用于本轮测试的所有第三方模型。

操作步骤：

1. 打开 Claude Code 对话窗口；
2. 在文件管理器中找到图片；
3. 将图片直接拖到对话输入框；
4. 确认图片已经作为附件出现；
5. 输入问题，例如“请描述这张图片的内容”；
6. 发送后检查模型回答与上下文用量。

本轮测试中，10 款模型通过拖拽方式均能正常读图，Token 消耗约 2,000。

它的优点是操作直观，不依赖模型正确解析 Read 工具返回的嵌套图片结构。缺点是人工操作更适合少量图片，不适合完全自动化的批处理。

方案二：必须使用 Read 工具时，切换到 Claude 官方模型

如果任务需要模型自主读取文件、批量处理图片，或者必须通过工具调用控制流程，当前更稳妥的选择是 Claude 官方模型。

可根据当前账号和平台实际可用情况选择：

• claude-haiku-4.5
• claude-sonnet-5
• claude-opus-5

本轮实际验证的是 claude-haiku-4.5。其他型号仍建议在当前环境中用同一张图片做一次 Token 对照。

在 Claude Code 中可以通过 /model 命令切换模型，也可以在配置文件里设置默认模型。

方案三：优化图片尺寸和格式

这项优化不能修复协议转换问题，但可以减少正常视觉输入的 Token 与传输开销，也能降低大图触发超时的概率。

建议参数：

• 分辨率尽量不超过 1920×1080；
• 文件大小尽量不超过 5MB；
• 界面截图优先使用 PNG；
• 照片优先使用 JPEG；
• 不需要细节时先裁剪无关区域；
• 多张大图尽量分批发送。

可以使用图片编辑或压缩工具调整分辨率和文件大小，再按用途选择 PNG 或 JPEG。

需要特别强调：如果 Base64 已经被错误放进文本字段，即使把图片压小，问题也只是从“非常严重”变成“稍微少一点”，根因仍然存在。

方案四：等待并推动适配层修复

更彻底的解决方案，需要 Claude Code、网关或第三方适配器正确转换工具结果中的图片。

可能的修复方向包括：

1. 递归识别 tool_result.content[].image；
2. 将嵌套图片转换成目标厂商要求的视觉内容块；
3. 确保 Base64 只出现在图片字段，不进入 text、prompt 或序列化工具结果；
4. 避免图片块与 Base64 文本同时存在；
5. 避免在多轮历史中重复附加同一图片。

修复后的请求至少应满足：

image_blocks >= 1
text_length = 正常的几百或几千字符

同时还应检查 Token 是否回到正常视觉输入的数量级。

一分钟决策流程

需要读取图片？
    |
使用 Claude 官方模型？
    |-- 是 -> Read 工具或拖拽均可
    |
    |-- 否 -> 使用第三方模型
             |
             |-- 少量图片 -> 直接拖拽
             |
             |-- 批量或自动化 -> 暂停使用 Read，
                                  切换 Claude 模型或等待适配修复

兼容性速查

Read 工具读图

• claude-haiku-4.5：支持，约 2,000 tokens，推荐。
• mimo-v2.5：异常，约 400,000 tokens，不推荐。
• kimi-k3：异常，约 420,000 tokens，不推荐。
• qwen3.7-plus：异常，约 430,000 tokens，不推荐。
• grok-4.5：异常，约 410,000 tokens，不推荐。
• gemini-3.5-flash：异常，约 400,000 tokens，不推荐。
• MiniMax-M3：异常，约 420,000 tokens，不推荐。
• gpt-5.6-luna：失败，约 400,000 tokens，不推荐。
• doubao-seed-2-1-turbo-260628：失败，约 450,000 tokens，不推荐。
• step-3.7-flash：失败，约 410,390 tokens，不推荐。

拖拽读图

本轮测试中，以下 10 款模型均成功，Token 消耗约 2,000：

• claude-haiku-4.5
• mimo-v2.5
• kimi-k3
• qwen3.7-plus
• grok-4.5
• gemini-3.5-flash
• MiniMax-M3
• gpt-5.6-luna
• doubao-seed-2-1-turbo-260628
• step-3.7-flash

最后的提醒

这轮测试最容易被误读的一点，是“有些第三方模型明明成功回答了”。

能回答不等于兼容正常。MiMo、Kimi、Qwen、Grok、Gemini 和 MiniMax 的 Read 请求虽然返回了结果，但输入消耗仍在约 40 万～43 万 tokens。它们更像是依靠大上下文窗口勉强容纳了异常数据。

因此，现阶段可以直接执行的建议是：

1. 使用第三方模型时，优先拖拽图片；
2. 需要 Read 工具或批处理时，先切换 Claude 官方模型；
3. 不只检查回答，还要检查 Token 和上下文；
4. 等适配层明确支持嵌套图片块后，再重新验证。

在多模型工具里，图片“能传进去”只是第一步。真正可靠的兼容，还必须保证图片被当作图片处理，而不是被展开成几十万 Token 的文本。

如果在你的 AI 工具链（如 Claude Code、Cursor 等）中需要频繁调度多个第三方模型，这类涉及 tool_result 嵌套块的跨协议适配缺陷，往往会导致隐蔽的上下文膨胀和推理成本失控。这时候为团队建立一套覆盖多协议兼容性与 Token 用量监控的评估校验机制会很有价值。 非线智能 API（nonelinear.com）深度兼容了 OpenAI、Anthropic 与 Gemini 三大主流 API 协议规范，现已接入 480+ 款全球主流大模型，支持在统一端点下为 Claude Code 等开发者工具提供原生的跨协议路由与请求级 Token 明细监控，可以作为多模型工程化落地与工具链兼容排查的统一接入网关如果在你的 AI 工具链（如 Claude Code、Cursor 等）中需要频繁调度多个第三方模型，这类涉及 tool_result 嵌套块的跨协议适配缺陷，往往会导致隐蔽的上下文膨胀和推理成本失控。这时候为团队建立一套覆盖多协议兼容性与 Token 用量监控的评估校验机制会很有价值。