What Resolution Does an AI Design Agent Actually See?

Context

A design agent never judges your page. It judges a resized, tiled, quantized copy of a screenshot of your page. When you ask a model to critique spacing, check a label’s contrast, or spot a misaligned icon, the honest first question is: what does the model actually see? The answer is arithmetic, not aesthetics. Every vendor’s ingest pipeline resamples your pixels before the model processes a single token, and the geometry of that resampling — not the quality of the model’s prose — sets the true resolution ceiling of any screenshot-based design review. This review is based on official documentation, pricing pages, and community reports — we did not run the tool hands-on. But because each vendor publishes its ingest parameters — Anthropic, OpenAI, and Google among them — that ceiling is computable in advance, and computing it changes how you should feed images to an agent.

Agent-perceivable signals: patches, tiles, and tokens

Vision models do not read pixels directly. Each image is chopped into fixed squares — patches — and each patch becomes one visual token in the model’s context. Anthropic’s vision documentation specifies 28×28 px patches where one patch equals one token; OpenAI’s image guide works in 32 px patches; Google’s API tiles larger images into 768×768 px squares. These units are the model’s entire sensory vocabulary.

That vocabulary has a hard floor. If a UI element is smaller than one patch in the ingested image, it cannot occupy a token of its own — it bleeds into whatever shares that patch. A 12 px label, a 1 px divider, a hairline border: all can exist in the DOM and be effectively invisible in the screenshot the model judges. Call this sub-patch invisibility. An agent reviewing screenshots is constrained by ingest math before any reasoning begins, and no amount of prompt engineering recovers detail the pipeline discarded.

Analysis: ingest geometry, vendor by vendor

Claude: 28 px patches under a token budget

Anthropic’s vision documentation defines token cost as ceil(w/28) × ceil(h/28) — 28×28 px patches, one patch per visual token. The standard tier downscales images so the longest edge is at most 1568 px and the total stays within 1568 visual tokens, expressible as s = min(1, 1568/max(W,H), sqrt(1568 × 784 / (W × H))) for a W × H image, where s is the ingest scale. Claude 4.7 and later add a high-resolution tier — a 2576 px long edge and up to 4784 visual tokens — with scale s = min(1, 2576/max(W,H), sqrt(4784 × 784 / (W × H))). The documented examples: 1000×1000 px passes through unresized at 1296 tokens; 1920×1080 is resized to 1456×819 (1560 tokens) on standard, and costs 2691 tokens on high-res; 3840×2160 also lands at 1456×819 (1560 tokens) standard, and 2576×1449 (4784 tokens) high-res. One operational trap from the same documentation: oversized images are silently downscaled unless you set "oversized_image": "error" — while the computer-use and browser-use tools reject oversized images instead. A silent downscale is exactly the kind of failure a design reviewer will not notice.

GPT-5.6: detail levels and tile counting

OpenAI’s images-vision guide describes 32 px patches and four detail levels: low renders a fixed 512×512 view; high processes up to 2048×2048 with a 2,500-patch cap; original accepts inputs up to 65,535 px; auto behaves like original. For high detail the scale is s = min(1, 2048/max(W,H)), then — if the shortest side still exceeds 768 px — s = 768/min(W,H), after which 512 px tiles are counted. Token costs differ by family: gpt-5.x models cost 70 base tokens plus 140 per tile; gpt-4o and gpt-4.1 cost 85 and 170. The previous generation, GPT-5.5, capped high detail at 2,500 patches / 2048 px max and original at 10,000 patches / 6000 px max. Images exceeding 30,000 patches are hard-rejected, with no automatic resize.

Gemini: 768 px tiles, not patches

Google’s image-understanding documentation and token guide describe a different system. Images with both dimensions ≤ 384 px cost a flat 258 tokens; anything larger is tiled into 768×768 px squares at 258 tokens each. The tile grid derives from a crop unit of floor(min(w, h) / 1.5): a 960×540 image has a crop unit of 360, producing 3×2 = 6 tiles. There is no single downsample scale — tile count is simply ceil(W/768) × ceil(H/768) for a W × H image, and the token documentation confirms each tile costs 258 tokens. Gemini 3 introduced the media_resolution parameter for granular control, and a single request can carry up to 3,600 images. Note the consequence: no per-patch pixel unit exists, so tile granularity is coarser — each 258-token tile stands in for 589,824 pixels.

What to learn: compute Agent-Visible Resolution first

Define Agent-Visible Resolution (AVR): the smallest element, in source-page pixels, that still occupies one full patch after ingest. The rule is one line:

min_legible_px = patch_px / s

where patch_px is 28 for Claude and 32 for GPT, and s is the vendor’s ingest scale from the formulas above, each derived from Anthropic’s vision documentation, OpenAI’s images-vision guide, and Google’s token guide respectively. Any text, icon, or affordance rendered below min_legible_px in the source page is sub-patch: it can exist in the DOM and be invisible in the screenshot the model judges.

A 2560×1440 page (3.69 MP).

Claude standard tier: The long-edge rule gives 1568/2560 ≈ 0.61; the token-area rule gives sqrt(1568×784 / (2560×1440)) ≈ 0.58. Scale ≈ 0.58. Ingested at ~1485×855 → ~53×31 patches (~1,643 tokens, which exceeds 1,568, so the area constraint wins: actual ingested ≈ 1456×819, scale ≈ 0.57). A 14 px label arrives as ~8 px = 0.29 of one 28 px patch.

Claude high-resolution tier: Long-edge rule: 2576/2560 = 1.006 → s = 1 (no long-edge downsample). Token-area rule: sqrt(4784×784 / (2560×1440)) ≈ 1.01 → s = 1. The image passes through at full resolution: 92×52 patches = 4,784 tokens — exactly the ceiling. A 14 px label is still only 0.5 of one 28 px patch.

Conclusion: For one clean dedicated patch, a designer needs approximately 28–49 px elements at 2560 px page width, depending on tier. Small UI labels, thin dividers, and icon details below this are sub-patch noise.

The counter-move is architectural: for anything below min_legible_px, do not rely on a full-page screenshot. Hand the agent element-level crops or the DOM and computed-style values directly — a native-resolution crop of a 12 px label, or its computed font-size, gives real signal where full-page ingest guarantees noise. AVR is a threshold to design around: measure the scale, compute the floor, route sub-patch elements to a channel that preserves them.