Hello,
Thank you for reaching out and sharing your test results. This is a very insightful observation, and your results actually perfectly illustrate our internal preprocessing logic.
To answer your questions directly: Yes, the system downscales images that exceed the resolution limit before tokenization—specifically at the gateway level, before the image is even sent to the inference server. Here is a detailed breakdown of how this works and why you are seeing those specific token counts:
1. Gateway Preprocessing (Area vs. Long Edge)
Internally, token counts are roughly proportional to the total number of pixels (the area of the image), combined with some internal padding logic.
During preprocessing at the gateway, an image is evaluated and scaled based on its area. (If an image is exceptionally long and thin, we restrict the long edge first, and then scale it down proportionally). Our algorithm researchers established an upper bound for image inputs as a tradeoff to balance optimal model performance across different image types while managing computational costs.
2. Why the Token Counts are Nearly Identical
Because our core logic evaluates the area, your original massive image significantly exceeds the threshold and is aggressively scaled down exactly to the maximum upper bound at the gateway.
Your cropped image (1654 × 4343) has an area that is slightly smaller than the limit. However, token calculation is not based on a strict 1:1 pixel count. Instead, the model processes images in grid blocks. The scaled dimensions are first divided by 14, and the result is rounded up to the nearest whole integer (ceiling).
Because of this “round up to multiples of 14” logic, marginal differences in raw pixels disappear during grid alignment. The original large image (forced exactly to the maximum ceiling) and your cropped image (sitting just below that ceiling) end up mapping to the exact same number of 14-pixel blocks. This is why their final token footprints converge so closely.
3. Why We Recommend Against Uploading Oversized Images
While the gateway handles oversized images automatically, we strongly advise against relying on this for a few reasons:
- Latency: Passing massive images slows down the preprocessing pipeline at the gateway, which negatively impacts your TTFT (Time To First Token).
- Lossy Scaling & Debugging: Downscaling is an inherently lossy process. If you pass a massive image expecting the model to read tiny, high-density text, the gateway’s scaling will likely blur those details before the inference server ever sees them. Because developers currently cannot see the final “downscaled image” the model actually processes, this can cause significant debugging frustration (e.g., “The text is clear on my screen, why can’t the model read it?”).
- Billing: Rest assured, uploading an oversized image will not result in higher costs. Because tokens—and therefore billing—are calculated based on the image after the gateway has processed and scaled it down, you are only charged for the final scaled size, not your original massive upload. You don’t need to worry about accidentally inflating your bill by passing a large image.
(Note: Different models accept different maximum resolutions. When using the estimate-token-count API, ensure you are testing with the exact same model configurations. Ultimately, the usage returned in the actual API response should be your single source of truth).
How to Actually Reduce Image Tokens
To meaningfully reduce your token count, you need to target a resolution whose total pixel area falls naturally below the gateway’s scaling upper bound. Since your cropped image was still large enough to sit just under the 4K area ceiling, you will want to scale your images down further (e.g., targeting a total area closer to standard 1080p/2K) before sending them to the API.
I hope this clarifies the internal mechanics! Let us know if you have any other questions.
Best regards,
Yu