Set Image Resolution Budgets Before Vision API Costs Climb

Last reviewed: August 1, 2026

Direct answer

To control vision API image token costs, set a resolution budget before a request reaches the model. The budget should specify the maximum image count, transformed dimensions, permitted fidelity setting, estimated image-input billing units, and number of allowed quality escalations for each task class.

Do not use one universal pixel limit or token formula. Providers meter images differently, and behavior can vary by model family. OpenAI’s images and vision guide describes model-dependent low, high, original, and auto modes, patch-based and tile-based metering, and cases where large images processed at original or auto can consume more input tokens. Anthropic’s vision guide describes visual tokens as 28 x 28-pixel patches and notes that high-resolution processing can use roughly three times as many visual tokens as standard-resolution processing for the same image. Google’s media resolution guide maps low, medium, high, and ultra-high settings to different approximate token allocations that also vary by model family and media type.

Treat those provider settings as implementations of your own policy tiers, not as the policy itself. A useful internal policy has three tiers:

• Coarse: classification, moderation, or obvious-object detection where small text and exact coordinates do not matter.
• Detail: charts, screenshots, forms, and documents where smaller features affect the answer.
• Spatial: coordinate-sensitive automation, dense visual inspection, or computer-use tasks that have demonstrated a need for the highest supported fidelity.

For each tier, calculate projected cost from the provider-specific image-input estimate and the approved rate snapshot. Add text input, output, tools, retries, and other separately billed work before comparing the request with its total budget. The meaningful denominator is cost per accepted result, not cost per first attempt.

Who this is for

This control is for AI platform engineers, FinOps practitioners, product owners, and reliability teams running image-analysis workloads through an API or gateway. It is most useful when applications accept user uploads, process screenshots or documents, send several images in one request, or retry at a higher fidelity after a weak answer.

The control belongs at the request boundary, where dimensions and requested fidelity are still visible. Finance can define cost tolerances, but engineering must enforce the transformation, estimation, and escalation rules.

Key takeaways

• Pin resolution behavior to a model version and provider contract. Identically named settings are not interchangeable across providers.
• Resize or crop before dispatch when the task does not need the entire source image.
• Budget image count and resolution together. Ten inexpensive images can exceed the allowance for one detailed image.
• Make high-fidelity retries explicit. An automatic retry can turn a quality problem into an unobserved second charge.
• Log estimated and reported image-input units separately so estimation drift is visible.
• Review cost per accepted result alongside the quality metric. A cheap request that causes rework is not a saving.

Sources checked

• The OpenAI images and vision documentation was checked for supported detail modes, model-specific resizing behavior, and patch-based or tile-based image metering. It confirms that images count as input tokens and that default behavior can differ across model generations.
• The Anthropic vision documentation was checked for request limits, the 28 x 28-pixel visual-token formula, resolution ceilings, and the effect of high-resolution processing on visual-token use.
• The Google media resolution documentation was checked for global and per-part resolution controls, model-dependent token allocations, and guidance on matching resolution to image, video, or document tasks.

These sources establish the metering mechanisms and available controls. They do not replace a current pricing snapshot or a workload-specific quality evaluation.

Contract details to verify

Start with a short contract for every vision workload. Record the provider, exact model identifier, model revision, endpoint, accepted image formats, image-count limit, dimension limit, default resolution behavior, available fidelity settings, image-input metering rule, current rate source, and response field used for reported usage. Recheck the contract whenever the model or endpoint changes.

Your policy tier should map to a provider setting only after testing:

The labels in this table are internal. For example, Google’s documented settings allocate approximately 280, 560, 1,120, and 2,240 image tokens for low through ultra-high processing on the listed Gemini 3 models, while the same page documents different behavior for Gemini 2.5. OpenAI uses multiple tokenization systems across model families. Anthropic derives visual-token use from patches and model-specific resolution ceilings. Copying a number from one contract into another will produce a false estimate.

Use the following operator workflow.

1. Pin the model contract. Resolve the exact model and endpoint before estimating anything. A floating alias must map to a reviewed contract revision.
2. Classify the task. Choose coarse, detail, or spatial from the actual acceptance requirement, not from the source file’s camera resolution.
3. Inspect the input. Record image count, width, height, orientation, format, and whether a smaller region contains all required evidence.
4. Transform deterministically. Apply the approved crop and resize rule. Preserve the original only in controlled storage when the workload requires it; do not place raw image data in routine logs.
5. Estimate provider-specific usage. Apply the documented rule for the pinned model and selected fidelity. Multiply estimated billing units by the approved input rate, then add the rest of the request estimate.
6. Enforce the gate. Allow the request when both the image-input cap and total request cap pass. Otherwise downgrade, crop, split, or return a review decision. Do not dispatch first and explain the overage later.
7. Measure the result. Capture provider-reported usage, latency, policy tier, retry sequence, and quality outcome. Compare estimates with reported usage by contract revision.

Add this gate to the existing preflight token-count control rather than maintaining an unrelated vision-only ledger.

Happy path

A product-photo classifier needs to identify a broad category from one image. Its benchmark already meets the team’s acceptance threshold at the coarse tier. An incoming 1600 x 1200 image is cropped and resized to 768 x 576. Preflight estimates 300 image-input units against a 400-unit cap, so the gateway allows one request at the validated low-fidelity setting. The provider reports 296 image-input units, the result passes the quality check, and no escalation occurs. The operator records the 4-unit estimation difference for later calibration.

Error path

A dense receipt image enters the same coarse route, but the required line items are unreadable at the low setting. The application must not silently resend the original at maximum fidelity. It returns a quality-escalation decision, crops to the required table, maps the task to the detail tier, and estimates the revised request. If the revised estimate is 740 units against an 800-unit escalation cap, one retry is allowed and logged as retry sequence 1. If the estimate exceeds the cap, the request is stopped or routed for an approved exception. A second quality failure ends the automated path.

A sanitized request record can look like this:

{
  "request_ref": "req-042",
  "workload_ref": "invoice-review",
  "policy_version": "v3",
  "model_contract": "vision-standard",
  "task_class": "coarse",
  "image_count": 1,
  "source_dimensions_px": [1600, 1200],
  "transformed_dimensions_px": [768, 576],
  "provider_setting": "low",
  "estimated_image_input_units": 300,
  "reported_image_input_units": 296,
  "budget_cap_units": 400,
  "decision": "allow",
  "retry_sequence": 0,
  "quality_outcome": "accepted",
  "response_status": 200
}

Do not include raw image bytes, full source locations, request bodies, extracted personal data, or user-entered text in this operational record. Use a short correlation reference and keep any restricted diagnostic artifact outside routine cost logs.

Failure modes

Relying on an automatic default. A model change can alter what omitted or auto fidelity means. OpenAI’s documented defaults already differ across model families. Pin the model and send an explicit setting when the API supports it.

Treating file size as the billing unit. Compressing a file can reduce transfer size without changing the dimensions, patches, tiles, or configured media allocation used for model metering. Estimate from the provider’s documented method after transformation.

Sending the full frame when only one region matters. A small table, chart, or screen control may occupy a fraction of the image. Crop to the evidence-bearing region when the quality test permits it, and record the transformation rule.

Using high fidelity for every image. This avoids classification work but transfers the cost decision to the most expensive path. High fidelity should have a named requirement and an acceptance test.

Ignoring image fan-out. Page rendering, thumbnail expansion, or attachment handling can turn one user action into many model inputs. Enforce image count and aggregate estimated units at the final dispatch boundary.

Retrying without a separate allowance. A low-quality answer followed by an unbounded high-resolution retry can more than erase the initial saving. Record every attempt and use the retry evidence workflow to attribute the full cost of the accepted result.

Applying one provider formula everywhere. Patch size, resizing, token multipliers, resolution labels, and defaults vary. Store the estimator with the model contract and reject unknown revisions instead of guessing.

Watching only total tokens. A stable total can hide a rising share of image-input usage offset by shorter output. Track image count, resolution tier, estimated image units, reported image units, and retry units as separate measures.

Losing quality evidence. A cost reduction is not validated if the team cannot show that extraction accuracy, classification agreement, or spatial success remained within its acceptance threshold.

FAQ

Is a larger source image always billed for more tokens?

No. Some model contracts resize or cap images before tokenization, while others preserve more of the original dimensions at particular settings. The source image still affects latency, request limits, and the chance that a higher-cost path is selected. Estimate the transformed input under the pinned contract instead of inferring cost from megapixels alone.

Should every workload start at the lowest resolution?

Start at the lowest tier that has already passed a representative quality test. Dense OCR, chart reading, small-object detection, and coordinate-sensitive work may need more detail. The goal is the lowest validated setting, not the lowest available setting.

Does JPEG compression solve image token cost?

Do not assume it does. Compression may reduce bytes in transit, but the cited provider methods focus on processed dimensions, patches, tiles, or configured media resolution. Resize or crop when those changes are compatible with the quality contract.

What belongs in the budget calculation?

Include estimated image-input charges, text input, output, separately billed tools, and the permitted retry path. Compare the sum with both a per-request cap and a cost-per-accepted-result target. Keep pricing units and effective dates in the model contract so an estimator does not outlive its source rate.

How should an operator handle an unknown model revision?

Fail closed for expensive or high-volume paths. Route the request to a reviewed fallback contract or return a configuration error. Guessing that a new revision shares the old image-metering rule defeats the preflight control.

Which metrics show whether the policy works?

Track accepted results, quality failures, high-tier share, retry rate, estimated versus reported image-input units, and cost per accepted result. Review the distribution by workload and model contract, not only the fleet-wide average.

Can several images use different tiers in one request?

Only when the provider and endpoint support per-image control. Google’s cited guide documents per-part media resolution for Gemini 3, while also distinguishing it from global request configuration. Where per-image settings are unavailable, split requests only after accounting for the added text, output, and orchestration cost.

Reader next step

Select one high-volume vision workload and build a representative evaluation set. Define its acceptance metric, classify each task as coarse, detail, or spatial, and run the set at every supported fidelity that could satisfy the requirement. Record transformed dimensions, estimated image-input units, reported usage, quality outcome, and retry cost.

Then set a default tier, an explicit escalation cap, and a stop condition in the request gateway. Retain the results with the token-usage evidence checklist . Re-run the evaluation before changing the model, endpoint, preprocessing rule, or provider setting. That turns image resolution from an incidental request option into a controlled budget decision.