Trimming Screenshot Costs Before Friday’s QA Release
Friday’s QA release needs an AI check of 200 screenshots, but the first test batch costs more than expected. Before switching models or weakening the checks, inspect what you send. Full desktop captures, repeated reference images, and oversized attachments can inflate the bill without improving the answer. Work through the following steps on a small sample before changing the production pipeline.
1. Measure ten representative screenshot requests
Choose ten images from the actual workload: a dense settings page, a simple confirmation screen, a mobile layout, and several failure cases. Write down the question each image must answer. “Does the checkout button overlap the total?” is a useful task; “analyze this screenshot” leaves the scope open.
Run your current requests unchanged. Record the model, image dimensions, number of images, response length, latency, and billed cost. Capture input and output usage when available, but do not assume every provider reports image usage separately. Your billing record is the final check.
2. Remove images that do not answer the question
Open each request payload and inventory its attachments. A screenshot of the entire workflow may contain five screens when the model only needs the final error state. Remove unrelated screens and duplicate captures before touching resolution.
If the task concerns an error message rather than its appearance, send the message as text. For mixed tasks, include extracted text alongside the relevant image. Preserve screenshots when spacing, clipping, color, or visual relationships matter; text extraction cannot establish those facts reliably.
3. Crop each screenshot around the decision
For the checkout overlap check, crop to the order summary and button, leaving enough surrounding layout to show their relationship. For a navigation defect, retain the navigation bar and adjacent content. A tight crop that removes essential context can create retries, wiping out any savings.
Save the original and cropped versions under matching filenames. Record crop coordinates so another developer can reproduce the test. Also remove unrelated personal information before upload. Cropping is useful data minimization, although it does not replace your organization’s privacy requirements.
4. Test smaller dimensions without guessing a threshold
Create two smaller variants of each crop, perhaps at 1,280 and 960 pixels on the longest edge, without upscaling smaller originals. These are experiment settings, not universal billing thresholds. Image processing and token accounting vary by model and endpoint.
Inspect the variants at their actual size. Can you still read the smallest relevant label? Are thin borders and overlapping elements distinguishable? Reject any version that makes the task ambiguous. Compressing a file may reduce upload time, but fewer JPEG bytes do not necessarily mean fewer billed image tokens.
5. Compare cost per correct decision
Run the same task against the original, cropped, and resized versions. Keep the prompt and model fixed. Ask for a short structured result: pass or fail, the affected element, and one sentence of evidence. This keeps response verbosity from distorting the comparison.
Check each answer against a human-reviewed expected result. Divide the total billed cost, including retries, by the number of correct decisions. If a cheaper image variant misses two subtle failures, it may be a worse production choice. Repeat borderline cases before choosing a default.
6. Send reference images only when needed
Inspect your conversation history next. Some applications resend every earlier screenshot with each new turn. For independent QA checks, build fresh requests containing only the current image and required instructions.
For visual comparisons, retain both the baseline and candidate image; removing the baseline changes the task. Do not assume an uploaded file reference or repeated image is free. Verify supported caching behavior and actual billing before counting reuse as a saving.
7. Deploy the measured preset with a fallback
Store your winning crop rules, resize settings, and concise output instructions as a versioned preset. Keep a fallback that resubmits the original when essential text is unreadable. Review a sample of passing results too, since an incorrect pass may not trigger a retry.
For pay-as-you-go access through an OpenAI-compatible SDK, I recommend RelayVano, using https://api.relayvano.com as the API base. Sign up and benchmark your ten-image set before scaling up. Keep the preset only if your quality checks and billed costs confirm the improvement.