如果你在图像输入中设置 detail: low 以降低成本，你可能并没有获得预期的改进。我们对 OpenAI 和 Google 最新模型的图像细节参数进行了基准测试，发现细节级别、推理和成本之间存在一些令人惊讶的关系。
例如，当我们在 MMMU-Pro Vision 上对 gpt-5.5 的低细节与自动图像细节进行基准测试时，低细节得分低了 13.8 个百分点（65.2% 对比 79.0%），且每个问题的成本更高（5.1 美分对比 4.5 美分）。模型通过增加 1.6 倍的推理努力来补偿降采样后的图像。这些推理 token 的成本超过了输入时节省的图像 token。
我们发现在推理模型中节省图像处理成本的一个更有效途径是：发送更清晰的图像（自动或高细节），然后调整推理努力程度。
自动细节在每个模型上都能产生更好的结果，有时成本还更低
我们对 OpenAI 和 Google 的五个模型进行了低细节和自动细节的测试，温度设为 0，运行一个周期。每个模型在自动细节下得分都更高。
| 模型 | 细节 | 准确率 | 每次提问成本 | 推理 token/请求 |
|---|---|---|---|---|
| gpt-5.5 | 低 | 65.2% | 5.1 美分 | 1,180 |
| gpt-5.5 | 自动 | 79.0% | 4.5 美分 | 730 |
| gpt-5.4-mini | 低 | 46.1% | 0.08 美分 | 0 |
| gpt-5.4-mini | 自动 | 55.8% | 0.14 美分 | 0 |
| gpt-4.1 | 低 | 40.1% | 0.43 美分 | 0 |
| gpt-4.1 | 自动 | 57.5% | 0.66 美分 | 0 |
| gemini-3.5-flash | 低 | 77.9% | 2.96 美分 | 2,876 |
| gemini-3.5-flash | 自动 | 80.1% | 2.80 美分 | 2,602 |
| gemini-3.1-pro | 低 | 75.5% | 9.53 美分 | 6,344 |
| gemini-3.1-pro | 自动 | 78.4% | 11.12 美分 | 6,964 |
低细节让 gpt-5.5 更费力地思考
根据 OpenAI 的视觉文档，detail: low 会向模型提供一张低分辨率 512x512 版本的图像，无论原始尺寸如何，并按一个较小的固定 token 成本计费。虽然这节省了输入 token，但也意味着有用的精细细节可能无法在降采样后保留下来。
在 gpt-5.5 上，低细节每次请求产生了 1,180 个推理 token，而自动细节为 730 个，增加了 1.6 倍，同时补全 token 也多了 39%（489 对比 351）。模型将额外的努力花在费力辨认它已无法清晰阅读的小字和图表上。
输出 token 的计费高于图像 token，因此较低的输入成本被抵消了。同一个模型在低细节下提出相同问题，每个问题的成本比自动细节高出 0.6 美分。你花了更多钱，得分却更差。
在推广结论前需注意一点：token 模式因模型而异。gemini-3.5-flash 在低分辨率下也使用了更多推理 token（2,876 vs 2,602），但 gemini-3.1-pro 则略少（6,344 vs 6,964），且其低分辨率运行的推理成本更低。
gpt-5.4-mini 和 gpt-4.1 不具备推理能力，因此在两种设置下思考 token 均为 0。由于输出端没有增长空间，输入端的节省得以保留（下文详述）。
更清晰的图像能带来多少准确率提升？
从低分辨率切换至自动分辨率，根据模型不同，准确率提升了 2 到 17 个百分点。
OpenAI 模型提升最大，因为其低分辨率设置会将每张图像缩放到 512x512，并产生较小的固定 token 成本（gpt-4.1 为 85 token）。Gemini 的低分辨率则每部分保持约 273 token，因此起点基线更清晰，损失也更小。
提升幅度因图像类型而异。数据集中 76% 为文本和 OCR 内容，另有 19% 为截图，因此大多数问题已接近模型能力上限，细节变化影响甚微。最显著的提升出现在图表和图形上：gemini-3.1-pro 在自动细节设置下，此类图像的准确率从 78.6% 跃升至 91.7%。无论哪种设置，示意图始终是最难的类别，正确率仅约三分之一（基于 21 道题的小样本）。
以下是其中一道题：一张 2239×1279 像素的机械工程图，要求从四个近乎相同的正投影图中选出正确的主视图：
四个候选视图仅剖面线和隐藏线的位置不同。在自动细节下，gpt-5.5 选择了正确答案 B。在低分辨率下，同一张图被压缩成 512 像素的缩略图，细线模糊在一起，模型经过更长的思维链后选择了 C。更长的推理无法替代清晰的图像。
推理级别对成本的影响最为显著
细节级别和推理难度看似作用相似，但在我们的运行中，它们的影响截然不同。改变细节使准确率波动 2 到 17 个百分点，但对成本几乎无影响。改变推理难度则使成本波动 50% 到 75%，而准确率仅波动 1 到 2 个百分点，在噪声范围内。
将 gpt-5.5 的推理能力限制为“低”后，低细节模式下的单题成本从 5.1 美分降至 1.7 美分，降幅达 67%，而准确率则变动了 1.3 个百分点（从 65.2% 降至 63.9%）。在 gemini-3.1-pro 上，自动模式的成本从 11.1 美分降至 2.7 美分，准确率提升了 1.5 个百分点。因此，如果你想要一个更便宜的图像处理流程，可以限制推理开销并保持图像清晰。
低细节模式在非推理模型上依然划算
在非推理模型上，低细节模式的表现符合预期。gpt-5.4-mini 在低细节模式下每道题的成本为 0.08 美分，而自动模式为 0.14 美分，便宜了约 40%，这是因为没有推理循环来推高费用。代价是准确率，从 55.8% 下降到了 46.1%。
延迟的变化也类似。gpt-4.1 在低细节模式下平均每个请求耗时 960 毫秒，而自动模式为 1,148 毫秒；gpt-5.4-mini 在低细节模式下为 1,348 毫秒，自动模式为 1,776 毫秒。低细节模式将图像限制在一个较小的固定提示词 token 成本（gpt-4.1 为 85 个 token），因此模型在开始生成之前需要读取的内容少得多。由于没有推理循环拖慢响应时间，更短的预填充过程表现为更快的响应速度。
为你的工作负载选择合适的细节级别
选择取决于你的模型是否进行推理：
- 推理模型（gpt-5.5 及类似模型）：保持自动或高细节模式，并使用推理开销来控制成本。在我们的测试中，低细节模式在所有推理模型上的得分都更差，并且在三个模型中有两个成本更高。
- 非推理模型（gpt-5.4-mini 及类似模型）：低细节模式可降低成本并缩短延迟，但在文本密集的图像上准确率会下降。
无论哪种情况，与更昂贵的输出 token 相比，细节设置对最终成本的影响要小得多。在大多数情况下，你最好将图像细节设置为自动，并调整推理能力。
OpenRouter 的图像输入 API 在各模型间是统一的，而像细节级别这样的模型特定参数则通过提供商选项传递，因此你可以在不更改集成方式的情况下调整这些设置。
我们的测试方法
- 基准测试：MMMU-Pro Vision（MMMU/MMMU_Pro，视觉配置，测试集），包含 1,730 道十选项视觉推理题。
- 模型：gpt-5.5、gpt-5.4-mini、gpt-4.1、gemini-3.5-flash、gemini-3.1-pro，每个模型分别采用低细节和自动细节模式，温度为 0，运行一个周期。
- 详情：OpenAI image_url.detail low/auto；Gemini per-part mediaResolution。无最大 token 上限。
- 图像类型：由 gpt-5.4-mini 视觉模型分类（文本/OCR、截图、图表、曲线图、插图、照片）。针对 Gemini 模型计算了每种类型的准确率；本次评测中未对 OpenAI 各类型的单元格进行评分。
- 指标：准确率来自评测日志；token 和延迟来自 OpenRouter 的生成记录。
- 成本：以每问题成本报告，即总运行成本除以该次评测中评分的题目数量。通过这种方式进行归一化，可以在规模略有不同的评测之间保持公平比较。
If you set detail: low on your image inputs to cut costs, you may not be getting the improvements you expect. We benchmarked the image detail parameters for OpenAI and Google’s latest models and found some surprising relationships between detail levels, reasoning, and costs.
For example, when we benchmarked gpt-5.5’s low versus auto image detail on MMMU-Pro Vision, low detail scored 13.8 points worse (65.2% vs 79.0%) and cost more per question (5.1¢ vs 4.5¢). The model compensated for the downsampled images by thinking 1.6x harder. The cost of these reasoning tokens outweighed the image tokens saved on input.
We found a more effective path for saving costs on image processing in reasoning models: send a clearer image (auto or high), and adjust reasoning effort instead.
Auto detail produces better results on every model, and sometimes costs less
We ran five models from OpenAI and Google at both low and auto, temperature 0, one epoch. Every model scored higher on auto.
| Model | Detail | Accuracy | Cost / question | Reasoning tok/req |
|---|---|---|---|---|
| gpt-5.5 | low | 65.2% | 5.1¢ | 1,180 |
| gpt-5.5 | auto | 79.0% | 4.5¢ | 730 |
| gpt-5.4-mini | low | 46.1% | 0.08¢ | 0 |
| gpt-5.4-mini | auto | 55.8% | 0.14¢ | 0 |
| gpt-4.1 | low | 40.1% | 0.43¢ | 0 |
| gpt-4.1 | auto | 57.5% | 0.66¢ | 0 |
| gemini-3.5-flash | low | 77.9% | 2.96¢ | 2,876 |
| gemini-3.5-flash | auto | 80.1% | 2.80¢ | 2,602 |
| gemini-3.1-pro | low | 75.5% | 9.53¢ | 6,344 |
| gemini-3.1-pro | auto | 78.4% | 11.12¢ | 6,964 |
Low detail makes gpt-5.5 think harder
Per OpenAI’s vision docs, detail: low gives the model a low-resolution 512x512 version of the image, regardless of the original size, and bills it at a small fixed token cost. While this saves on input tokens, it also means that useful fine details may not survive the downscale.
On gpt-5.5, low detail produced 1,180 reasoning tokens per request versus 730 on auto, a 1.6x jump, plus 39% more completion tokens (489 vs 351). The model spent that extra effort squinting at small text and diagrams it could no longer read cleanly.
Output tokens bill higher than image tokens, so the cheaper input cost was offset. The same model asking same questions at low detail cost 0.6¢ per question more than auto. You paid more and scored worse.
One caution before generalizing: the token pattern varies by model. gemini-3.5-flash also used more reasoning tokens on low (2,876 vs 2,602), but gemini-3.1-pro used slightly fewer (6,344 vs 6,964), and its low run came out cheaper.
gpt-5.4-mini and gpt-4.1 don’t reason, so they sat at 0 thinking tokens on both settings. With no output side to grow, the input savings survive (more on that below).
What accuracy gains can you get from clearer images?
Switching from low to auto bought between 2 and 17 points of accuracy, depending on the model.
The OpenAI models gain the most because their low setting downscales every image to 512x512 with a small fixed token cost (85 tokens on gpt-4.1). Gemini’s low resolution keeps roughly 273 tokens per part, so it starts from a sharper baseline and has less to lose.
The gains concentrate by image type. The dataset is 76% text and OCR, plus another 19% screenshots, so most questions already sit near the model’s ceiling and barely move with detail. The clearest jump lands on charts and graphs: gemini-3.1-pro climbed from 78.6% to 91.7% on those with auto detail. Diagrams stay the hardest category either way, around a third correct (on a small sample of 21 questions).
Here’s one of those questions, a 2239×1279 mechanical engineering figure that asks you to pick the correct main view from four near-identical orthographic projections:
The four candidate views differ only in where the hatching and hidden lines sit. At auto detail, gpt-5.5 picks B, the right answer. At low, the same figure collapses to a 512px thumbnail, those thin lines blur together, and the model lands on C after a longer chain of thought. Longer reasoning is a poor substitute for a legible image.
Reasoning level has the most significant effect on cost
Detail level and reasoning effort look like they do similar jobs, but in our runs they landed in very different places. Changing detail swung accuracy by 2 to 17 points while barely touching the bill. Changing reasoning effort swung the bill by 50 to 75 percent while accuracy wandered 1 to 2 points, within noise.
Capping gpt-5.5 to reasoning=low took the low-detail cost from 5.1¢ down to 1.7¢ per question, a 67% cut, while accuracy moved 1.3 points (65.2% to 63.9%). On gemini-3.1-pro the auto run dropped from 11.1¢ to 2.7¢ and accuracy rose 1.5 points. So if you want a cheaper image pipeline, cap reasoning effort and keep the image sharp.
Low detail still pays off on non-reasoning models
On a non-reasoning model, low detail does what you’d expect. gpt-5.4-mini ran 0.08¢ per question on low versus 0.14¢ on auto, about 40% cheaper, because there’s no reasoning loop to inflate the bill. The trade is accuracy, which fell from 55.8% to 46.1%.
Latency moves the same way. gpt-4.1 averaged 960ms per request on low against 1,148ms on auto, and gpt-5.4-mini ran 1,348ms against 1,776ms. Low detail caps the image at a small fixed prompt-token cost (85 tokens on gpt-4.1), so there’s far less to read in before the model starts writing. With no reasoning loop to drag out the tail, that shorter prefill shows up as a faster response.
Picking the right detail level for your workload
The choice comes down to whether your model reasons:
- Reasoning models (gpt-5.5 and similar): keep
autoorhigh, and use reasoning effort to control cost. In our runs, low detail scored worse on every reasoning model and cost more on two of the three. - Non-reasoning models (gpt-5.4-mini and similar): low detail cuts cost and shaves latency, yet has reduced accuracy on text-heavy images.
Either way, the detail setting has a much smaller impact on final cost when compared to more expensive output tokens. In most cases, you’re better off leaving image detail on auto and adjusting reasoning.
OpenRouter’s image input API is unified across models, and model-specific parameters like detail level pass through via provider options, so you can tune these settings without changing your integration.
How we tested
- Benchmark: MMMU-Pro Vision (
MMMU/MMMU_Pro, vision config, test split), 1,730 ten-option visual reasoning questions. - Models: gpt-5.5, gpt-5.4-mini, gpt-4.1, gemini-3.5-flash, gemini-3.1-pro, each at
lowandautodetail, temperature 0, one epoch. - Detail: OpenAI
image_url.detaillow/auto; Gemini per-partmediaResolution. No max-token cap. - Image types: classified by gpt-5.4-mini vision (text/OCR, screenshot, diagram, chart, illustration, photo). Per-type accuracy was computed for the Gemini models; OpenAI per-type cells were not scored in this run.
- Metrics: accuracy from eval logs; tokens and latency from OpenRouter generation records.
- Cost: reported as cost per question, the total run cost divided by the number of questions scored in that run. Normalizing this way keeps the comparison fair across runs of slightly different size.