What a 384-Token Image Budget Buys in Catalogue QA

Vision-model product catalogue QA became a budgeting exercise on August 21, 2026, when DeepSeek released DeepSeek-V4-Flash-Vision-Exp and published the one number that matters for bulk image work: every image costs up to 384 tokens, billed at the same per-token rate as text. No vision surcharge, no separate image tier. Put a price on 384 tokens and you have put a price on looking at a product photo.

That matters because catalogue image QA has always been a job that nobody finishes. A 20,000-SKU store has tens of thousands of hero shots, alternates and lifestyle images, and the rules they must meet are published in detail by Google Merchant Center and Shopify. The rules are not the problem. Reading every image against them is. At a fraction of a cent per image, the reading part stops being the bottleneck, and the checklist and the human sample become the work.

This is a build post from published numbers. Every figure is either a rate DeepSeek printed, a limit Google or Shopify printed, or arithmetic we show on assumptions we state. It covers what the 384-token ceiling actually is, a cost table at three catalogue sizes, a QA checklist derived from the two platforms’ own disapproval rules, a reasoned account of what an 800×800 pixel budget cannot resolve, and a pipeline shape that batches at off-peak with idempotent job keys and a human sample. For the launch itself, read our V4-Flash-Vision-Exp launch and pricing post; this one does not repeat that story.

The figure that makes this post possible is not a marketing claim. It comes from the Token Usage section of DeepSeek’s Vision guide, which describes what happens to an image before the model ever sees it. Images with a total pixel count below roughly 384×384 are scaled up, aspect ratio preserved. Larger images are scaled down, aspect ratio preserved, so that the pixel count after resizing is roughly that of an 800×800 image. The consequence is the ceiling: no image costs more than 384 tokens, however large the original.

Two details in the same guide shape everything downstream. Multiple images in one request are each counted independently under the same rule, so there is no multi-image discount or penalty. And a detail parameter exists on image_url inputs: low downscales to 512×512 before inference and is documented as faster and cheaper, while high, original and auto keep the image at its original size ahead of the resize step. The docs do not state how low interacts with the 384-token ceiling, so every number in this post uses the default path. If you try low, measure the token count yourself.

The rates those tokens are billed at sit on DeepSeek’s pricing page, and a footnote there makes the second structural point: image tokens are ordinary input tokens. There is no vision surcharge. The vision model carries the same table as the text-only V4-Flash: off-peak cache-miss input at $0.22 per million tokens, cache-hit input at $0.007, output at $0.66, with peak exactly double on every line ($0.44, $0.014 and $1.32). Peak hours are 01:00–04:00 and 06:00–10:00 UTC; all other hours bill at half. Seven peak hours a day leaves seventeen at half price, which is the whole scheduling argument for a catalogue job.

One framing note before the arithmetic. DeepSeek describes the model as matching DeepSeek-V4-Flash on text capabilities, which is the vendor’s own characterization and is not something a catalogue QA pass depends on. What the pass depends on is the ceiling, the rate table and the limits, all of which are documented. We cite no benchmark in this post because none is needed to price the job.

Three inputs go into the per-image figure. The first is DeepSeek’s: 384 image tokens, the published ceiling, used as the conservative case because a pipeline cannot assume every image resizes to fewer. The other two are ours and we state them plainly. A compact QA instruction enumerating the checks in Section 03 plus minimal per-SKU context, which we set at 220 input tokens. And a structured JSON answer, a handful of boolean and enum fields plus a short notes string, which we set at 140 output tokens. Change either and the table moves; the formula does not.

The formula is (384 + 220) × input rate + 140 × output rate, applied at cache-miss input rates with no caching credited. Every cell below follows from it.

Two things in that table are worth reading twice. First, the answer costs more than the picture. At off-peak rates the 140 output tokens come to $0.0000924 per image against $0.0000845 for the 384 image tokens, which means output is about 41% of the per-image cost and the image itself about 38%. Every extra sentence you let the model write is worth more than the photo it is describing. Keep the schema tight, forbid prose, and the table holds.

Second, coverage depth is your choice, not a platform requirement. Shopify’s photography guidance recommends multiple angles but states no fixed count, and Merchant Center’s image rules are per-image. If a pass reviews three images per SKU (a hero, one alternate angle, one lifestyle shot), multiply the per-catalogue rows by three: 60,000 images at 20,000 SKUs comes to $13.52 off-peak and $27.03 at peak from the unrounded per-image figure rather than from the rounded $4.51 in the row above. The multiplier is linear because each image is counted independently under the same resize rule.

We did not invent a definition of a “good” product image. Google Merchant Center publishes image link requirements and a separate text-on-image policy whose stated disapproval reasons are the checklist. Shopify publishes photography guidance on one page and file-level limits on another; the two should not be conflated, and we cite each for what it says. Merchant Center’s text-on-image page states the principle in one sentence: “All products on ads and free listings require an image with an unobstructed view of the product.” Products that fail it are disapproved until the image is updated, and the page notes diagnostics can take 24 to 72 hours to reflect a fix.

The table below maps each rule to the question a QA prompt would ask. It is a list of what a pass would ask for. DeepSeek publishes no evaluation of this model on any of these checks, and we ran none. Accuracy on every row is unmeasured here.

The split in that table is the most useful thing in it. Two of the rows need no vision model at all. Pixel dimensions, byte size, aspect ratio and container format are header reads, and running them in code first means the model is only ever asked questions that require eyes. It also means a file that already fails the 500×500 floor never spends its 384 tokens.

One more line from the Merchant Center page is worth a place in the pipeline even though it is not a detection check: Google asks merchants to ensure AI-generated product images carry IPTC metadata identifying them as algorithmically created. That is the catalogue-side mirror of this post. The same rulebook that defines what a QA pass looks for is starting to anticipate images that were themselves generated, and a metadata read belongs beside the header read.

DeepSeek publishes the resize arithmetic and nothing about detection. So the honest way to talk about limits is to keep the causal chain explicit and label each link. The published fact: a larger image is scaled down so its total pixel count is roughly that of an 800×800 image, about 640,000 pixels. Our arithmetic: a 1500×1500 source, the size Merchant Center recommends as a floor for good listings, keeps about 28% of its pixels; a 3000×3000 source keeps about 7%; a 5000×5000 source keeps under 3%. Our inference: whatever is only visible in the discarded pixels is not available to the model.

None of those three tiers is a DeepSeek statement. They are our reading of what a coarse pixel budget can and cannot carry, grounded in the one thing DeepSeek does publish. The practical move that follows is cheap: for any row in the marginal or beyond-budget tiers, crop the region of interest at source resolution and send the crop as its own image. A crop is its own 384-token line item, so the arithmetic in Section 02 still holds; you are buying a second look, not a bigger one.

The pipeline is a special case of two patterns we have already written up. The scheduling half is the off-peak LLM pricing playbook: DeepSeek’s windows are UTC-denominated and exact, and a catalogue job has no latency requirement, so there is no reason for any of it to run inside the seven peak hours. The engineering half is the million-row LLM job post: a deterministic job key per unit of work, a results store you can resume from, and a QA sample that is sized and drawn before the run starts. Here the unit of work is one SKU-image pair and the key is a hash of the SKU identifier, the image’s content hash and the prompt version. Rerun after a crash, a prompt tweak or a model update and only the changed keys spend tokens.

The limits that bound request shape are on the Vision guide, not the pricing page, with upload quotas on the separate Files API guide. A request may carry up to 600 images. Each side of an image may be up to 8,192 pixels, dropping to 4,096 once a request contains 15 or more images. Total image payload is 64 MiB without Files API references and up to 200 MiB with them. Images are accepted only in user messages; placing one in a system or assistant message returns an HTTP 400. For idempotency we still prefer one image per request, because one request then maps to one job key, one result row and one retry, and the 2,500 concurrency limit is the parallelism ceiling you scale into. We make no throughput or wall-clock estimate; DeepSeek publishes a concurrency limit, not a rate.

Most of the agentic catalogue work we have covered lives on the text side. Our agentic PIM post is about attribute enrichment and feed quality; the cross-channel feed matrix is about titles, GTINs and attribute rules per channel. Image QA is the column those posts leave blank, and it was blank for a reason: until an image cost about the same as a short paragraph, reading every one was not a job you would schedule nightly. Google’s own Merchant Center AI performance insights pilot is adjacent but distinct: it is a Google-side reporting feature, not a merchant-run check, and it does not tell you which image failed before Google saw it.

The interpretive point is about what becomes scarce. When the marginal cost of looking at an image drops to a fraction of a cent, the constraint moves to the three things the model cannot supply: a checklist grounded in the platforms’ actual disapproval rules, a human sample that produces the only accuracy number you will ever have, and an engineering discipline that keeps a 20,000-SKU rerun from spending twice. Teams that already run text-side feed agents have the second and third. The first is in the rulebooks linked above.

Looking forward, we expect the QA prompt to stop being a separate job and become an ingest step, run on every new or changed image the moment it lands in the PIM, with the nightly batch reserved for prompt-version migrations. The “-Exp” suffix is a reason to build that way rather than a reason to wait: DeepSeek has used the suffix before for models under evaluation ahead of a stable name, which is a reported pattern rather than a formal definition, and the defensive reading is that the model ID, the token ceiling and the rates can all change. Keying jobs on prompt version and model ID, and re-drawing the human sample on every model change, is what makes that a non-event. If you want help scoping that into a catalogue operation, our ecommerce engagements start from exactly this arithmetic.

A build post is only as good as its stated edges. Here are ours, in one place, so nothing above gets read as more than it is.

• No conversion-lift or defect-rate figure. We looked for a dated primary source tying product image quality to conversion or disapproval rates on either platform and found none. Neither Google’s nor Shopify’s documentation states one. Rather than borrow a plausible-sounding percentage from a secondary blog, this post uses no such figure. The business case here is cost-side only: the pass is cheap enough to run; whether it pays is yours to measure.
• No detection accuracy. DeepSeek publishes no evaluation of this model on watermarks, wrong-product images, missing angles or any row of the Section 03 table, and we ran none. Every check is what a QA pass would ask for; the human sample in Section 05 is how you find out how often the answer is right.
• The 384 figure is scoped to the default path. The detail: low option is documented as a 512×512 downscale, but the docs do not say what it does to the token count. We do not assert a number for it.
• Caching is inferred. The $3.57 cache-hit scenario rests on a guide that describes caching as default for all users but does not name this model. It is a plausible optimization, not a documented one.
• “Free” Files API is vendor-stated. The launch note says it is available at no cost; the Files API guide does not restate pricing either way.
• Throughput is not estimated. The published 2,500 figure is a concurrency limit. We do not turn it into images per hour, because DeepSeek does not.