Why Image Generation Costs 10x

How image tokens are counted, and how a resolution change jumps the bill up a tier.

People sending images to a multimodal model for the first time get a shock at the bill—a single image can cost as much as thousands of words. The reason is simple: images aren't billed per image. They're converted into equivalent tokens by resolution.

Signs you'll recognize:

• Sending one screenshot costs an order of magnitude more than usual.
• The same image, with a slightly different resolution, multiplies the price.
• The "image calls" line in your budget never estimates well.

How images are billed

When a model processes an image, it cuts the image into patches, understands each one, and stitches them back together. The number of patches is basically set by the resolution, so billing naturally follows resolution. Claude, for instance, splits images into 28x28-pixel patches, each counting as one visual token; OpenAI's vision models count billable input tokens from patches or tiles. openai-visionclaude-vision

Algorithms differ by vendor, but the common thread is tiering by the long edge: low, medium, high. Cross a threshold and the price jumps a tier. The same image going from a long edge of 1024 to 2048 may multiply the equivalent tokens several times; going to 4096 multiplies again.

That produces an easy trap: you send the original high-resolution image to ask a question, the model extracts barely more than it would from the low-res version, but your bill is calculated at high-res rates.

Why it's expensive

The cost is in the understanding workload. To make sense of an image, a model needs far more computation than to read text of the same byte size. Pixels are information-sparse but compute-dense—that's where the "tens of times" comes from.

Multimodal requests also tend to be "many images plus text": several screenshots plus one question, and the total clearly exceeds a text-only conversation. More input tokens, higher cost.

Understand the mechanism and the saving direction isn't "use fewer images"—it's making every image count.

Ways to cut the bill

One: lower the resolution to what the task needs. The biggest lever. Reading text or small print in an image? Go high-res. Judging overall composition, style, or whether someone is present? Low-res is enough. Ask first: "does the model really need to see that detail?" Compress the long edge to the tier that just barely suffices, and the cost can drop by an order of magnitude.

Two: send only the relevant part. A whole PDF page as one large image versus cropping to the region with the problem—the latter is far cheaper and often more accurate, since irrelevant content interferes with judgment. Same principle as chunking in text retrieval: the more focused what you feed, the better the result and the lower the cost.

Three: crop out irrelevant areas. Borders, menus, and blank space in screenshots—cut them before sending. Saves tokens and reduces noise.

Four: use discount lanes for batch and offline tasks. Many vendors discount image tasks that don't need a real-time response.

Five: keep "understanding images" and "generating images" on separate books. This article is about the cost of having the model understand images (vision input). Generating images is a separate billing model, usually priced per image, per resolution, and per step. Don't mix them when estimating.

Last: log image calls separately and watch them as their own cost line. They're low in volume, high in unit price, and the easiest thing to quietly eat the budget. Only with separate tracking can you see which feature is burning money.