Anthropic's Files API lets first-party applications upload a document once, get back a file ID, and reference that ID in any number of later requests. Per Anthropic's Vertex documentation, the Files API — along with URL input sources — is not supported on Vertex AI. PDF input itself works fine on Vertex; what's missing is the persistence layer. Every document Claude reads must travel inside the request that asks about it.
The working pattern: inline encoding
Documents and images go into the messages array as base64-encoded content blocks. The AnthropicVertex client accepts them exactly as the first-party client does:
import base64
from anthropic import AnthropicVertex
client = AnthropicVertex(project_id="my-gcp-project", region="global")
pdf_b64 = base64.standard_b64encode(open("contract.pdf", "rb").read()).decode()
message = client.messages.create(
model="claude-sonnet-5",
max_tokens=2048,
messages=[{"role": "user", "content": [
{"type": "document",
"source": {"type": "base64", "media_type": "application/pdf",
"data": pdf_b64}},
{"type": "text", "text": "List the termination clauses."},
]}],
)Hard limits apply: request payloads are capped at 30 MB, and image inputs at 5 MB per file, 100 images per request. Documents larger than the payload ceiling need chunking or preprocessing — see handling large payloads.
What repeated full-payload sends cost you
The design consequence is easy to miss in a demo and expensive in production: if users ask ten questions about the same 200-page contract, you send — and are billed input tokens for — that contract ten times. On the first-party API, the Files API plus caching absorbs much of this; on Vertex, your defense is prompt caching, which is fully supported there.
Place the document at the front of the prompt with a cache_control breakpoint. Per Google's Vertex pricing for Claude, a 5-minute cache write costs 1.25x the input rate and a 1-hour write 2x, while every cache hit costs just 0.1x — for Opus 4.8 that's $6.25 or $10.00 per million tokens to write, then $0.50 per million to reuse, against $5.00 to resend uncached. The bytes still travel with each request (caching changes what you pay, not what you transmit), but the token bill for a multi-question document session drops by roughly an order of magnitude on the cached portion after the first call.
Cloud Storage as your staging layer
Without file IDs, your application still needs somewhere durable to keep documents between requests — that's what Cloud Storage (GCS) is for. The pattern: users upload to a bucket; your service downloads the object, base64-encodes it, and inlines it into the Claude request. Effectively, GCS plus your own object naming becomes the "file ID" layer the platform doesn't provide.
One caution: because URL input sources are not supported for Claude on Vertex, you cannot hand the model a gs:// or HTTPS link and expect it to fetch the content (the web fetch tool is also unavailable on this platform). The download-and-inline step happens in your code, every time. Practical refinements that keep this cheap and safe:
Preprocess once, store the processed form. If you extract text from PDFs or downscale images before sending, store that derivative in GCS next to the original so repeat requests skip the work — and stay under the 30 MB ceiling.
Keep buckets inside your governance boundary. A staging bucket inherits your existing GCS controls — IAM, encryption, retention. If you operate a VPC Service Controls perimeter around Vertex AI, note that online inference requests are among the artifacts the perimeter protects; keep the staging bucket in the same perimeter so document flows never cross it.
Cache-key by object generation. Tie your prompt-cache strategy to the GCS object's generation number so an updated document naturally produces a fresh cache entry rather than stale answers.
Where to go next
For the caching mechanics in detail, read prompt caching on Vertex AI; for images specifically, sending images to Claude via Vertex AI. The full list of platform gaps is in the feature gaps overview.