When would you choose a URL image source over base64 in Anthropic's Messages API?

## Three ways to deliver the same pixels All three source shapes end in the same place — pixels tokenised as input — so the choice is entirely operational. What differs is who holds the bytes, who pays to move them, and what can fail. ## base64: the always-works default Inlining bytes has one great virtue: no third party needs access to anything. An image your service rendered a millisecond ago, a screenshot from a headless browser, a crop you computed in memory, a frame from a private video — all of these can be encoded and sent without publishing them anywhere. For one-shot requests over images that do not already exist as URLs, this is the correct default. The costs are payload size and repetition. Encoding inflates by roughly a third, and in a multi-turn conversation the same encoded blob is re-uploaded with every request because the Messages API is stateless — you resend the whole history each turn. A long agent loop over a few screenshots can spend a surprising amount of wall-clock time simply pushing the same megabytes. ## url: small requests, borrowed risk A URL source shrinks the request body to a string and moves the transfer to Anthropic's infrastructure. If your images already live in a CDN or a public bucket, this is efficient and usually faster end to end. The catch is that the fetch must succeed from Anthropic's side, which introduces failure modes your local tests will not reproduce: a private object-storage path that works from your VPC, a pre-signed URL whose expiry is shorter than your retry window, an origin that rate-limits unfamiliar clients, a redirect chain, or a firewall that only allows your own egress ranges. There is also a data-governance dimension — the image must be exposed at a URL that anyone holding the link can retrieve, which some classes of content simply may not be. Retries deserve thought here. If a request fails after the fetch, re-sending it re-fetches; if it fails because of the fetch, retrying the same expired signed URL will fail identically forever. Signed URLs should therefore be minted with lifetimes comfortably longer than your maximum retry window, or refreshed as part of the retry. ## file: upload once, reference many times The Files API is the right shape when the same image is read repeatedly — a reference diagram every session consults, a product photo compared against many inputs, a screenshot revisited across a long agent loop. You upload once, keep the returned identifier, and every later request carries a short string instead of megabytes. The constraints are real and worth naming in an interview. It is a beta surface, so the `files-api-2025-04-14` flag must be present on both the upload call and the `messages` call that references the file. The content-block type must match the file's MIME type — an image goes in an `image` block, a PDF in a `document` block. Uploaded files persist until you delete them, which makes lifecycle management your problem: an org that uploads per request and never deletes will accumulate storage. And the Files API is not offered on Amazon Bedrock or Google Vertex AI, so code that depends on it is not portable to those platforms. ## A decision rule Ask two questions. Is this image reused? If yes, upload it and reference the `file_id`. If no, is it already published somewhere Anthropic can fetch, and is publication acceptable for this content? If yes, use a `url` source; if no, inline it as base64. Then sanity-check the failure story: for `url`, what happens when the fetch fails or the signature expires; for `file`, what deletes the file when the workflow ends; for base64, whether the repeated upload cost across turns is acceptable, and whether stale images should be pruned from history entirely once their information has been extracted.