The Gemini API now supports increased inline file size limit of 100MB and new file inputs from GCS buckets and any HTTP/Signed URL.
What changed in the Gemini API input model
The Gemini API now accepts larger inline payloads—up to 100MB—and can pull files from Google Cloud Storage buckets as well as any HTTP or signed URL. That shifts how you design multimodal and document-heavy flows. Instead of forcing every asset through a narrow inline path, you can choose the transfer method that matches size, location, and how long the file needs to remain available to the model.
Inline input still suits small, short-lived artifacts: a prompt, a snippet, or a compact media sample you already hold in memory. Once files approach the previous practical ceiling, inline transfer becomes costly and fragile—base64 bloat, request timeouts, and gateway limits start to dominate. At 100MB inline, many mid-size documents, audio clips, and image batches can stay in a single request when that is the simplest path. For anything larger, long-lived, or already stored remotely, URL and bucket references are the better default.
Choosing between inline, GCS, and HTTP or signed URLs
Pick the input path from how the file is produced and where it lives. Inline works when the client already has the bytes and the size is well under 100MB with headroom for encoding and headers. GCS is the natural choice when the object already sits in a bucket your service can access—batch jobs, data pipelines, and shared datasets rarely need a second copy. HTTP and signed URLs fit public assets, partner-hosted files, or private objects where a time-limited link is safer than embedding credentials in the request body.
- Use inline for small, ephemeral inputs generated in the same request cycle.
- Use GCS when the file is already in your cloud storage and access policies are settled.
- Use HTTP or signed URLs when the file is remote, shared across services, or must expire after a short window.
Signed URLs deserve extra care: set expiry just long enough for the model call to complete, scope permissions to read-only, and avoid logging full URLs in application traces. For GCS, confirm the runtime identity can read the object; permission errors surface later and waste quota if you only discover them after the prompt is built.
Practical effects on application design
Larger inline limits reduce the need for a separate upload step for moderate files, which simplifies demos, scripts, and single-shot tools. Production systems still benefit from decoupling storage from inference. Store once, reference many times, and keep the model request thin: system instructions, task text, and pointers to media rather than full binary blobs on every call. That pattern also makes retries cheaper—you resubmit a URL or object path instead of re-uploading megabytes.
Expanded inputs also change preprocessing. You can leave source files in original form more often and let the model consume them directly, but you should still validate type, size, and content before the call. Reject empty objects, unexpected MIME types, and paths outside your allowlist. When multiple files feed one prompt, name them clearly in the text so the model can refer to each artifact without ambiguity.
Operational habits that keep these paths reliable
Treat remote inputs as network dependencies. Timeouts, rate limits, and temporary unavailability of a bucket or origin will fail the model call even when the prompt text is fine. Cache stable assets in a location you control, prefer regional proximity when latency matters, and measure end-to-end time including fetch, not only model latency. For signed URLs, rotate generation logic with your secret management process so keys are not hard-coded in clients.
On cost and privacy, larger inputs raise both token and bandwidth exposure. Prefer the smallest file that still answers the task, strip unnecessary pages or tracks before upload, and avoid sending secrets that only live in attachments when a structured field would do. With 100MB inline support plus GCS and HTTP or signed URL inputs, the Gemini API gives you flexible plumbing—use that flexibility to keep requests simple, storage authoritative, and access short-lived where it should be.