Gemini API expands file limits and accepts GCS and URLs | Keryc
Google announces practical changes in how you bring data to the Gemini API: now you can use external URLs (public or signed) and register objects in Google Cloud Storage (GCS), in addition to raising the inline file limit. What's the goal? Avoid unnecessary re-uploads and speed up moving multimodal apps to production.
What changes (technical summary)
Support for external URLs: you can pass a public URL or a pre-signed URL from providers like AWS S3, Azure Blob or others. The Gemini API securely retrieves the content during processing.
Registering files in Google Cloud Storage (GCS): if your data is already in GCS, register it with the Files API and you don't need to move bytes. The registered URI can be reused across multiple requests.
Inline limits increased: the maximum size for inline data rises from to (base64 encoded; specific limits vary by data type). Ideal for prototypes, large images or short audio clips without intermediate storage.
20 MB
100 MB
In short: less friction to bring your data —from wherever it lives— directly to the API.
How to use it — practical examples
Using an external URL
Imagine you have PDFs in a private S3 bucket. Instead of downloading and uploading again, you generate a signed URL with an expiration and pass it in the generation request. Gemini downloads the file during processing. That reduces latency and transfer costs.
Typical cases: large documents, heavy images, short audio/video files.
Practical advantage: you don't need intermediary infrastructure to rehost files.
Registering files in GCS
If your pipeline already writes to Google Cloud Storage, register the URI with the Files API. Single registration, repeated use. You don't move bytes, you only grant access.
Requirement: OAuth authentication with IAM credentials that have read permission to the bucket.
Ideal for: data that is queried frequently (RAG models, repeated multimodal analysis).
Using inline when it makes sense
For prototypes or real-time apps where you prefer simplicity, you can now embed up to 100 MB base64. It's fast, but not recommended at scale due to costs and large payload latency.
Technical and security considerations
Authentication: registering GCS requires OAuth from an account with read permissions on the bucket. Apply least privilege.
Signed URLs: control expiration and permissions. Don't use long expirations without justification.
Validation: validate MIME types and sizes before sending the URL or the inline payload. Avoid surprises in production.
Costs and latency: avoiding re-uploads doesn't remove transfer costs — the API fetching from external URLs implies egress from the origin provider. Measure latency and cost in your setup.
Persistence: registering in GCS removes the previous 48-hour ephemeral storage limit in the Files API.
Recommendations for production
Use registered GCS for persistent, frequently accessed data.
Use signed URLs for integrations with other clouds (S3, Azure) and keep short expirations.
Keep inline (100 MB) for prototypes or real-time responses; not the most economical at scale.
Implement auditing and rotation for IAM credentials.
Test end-to-end with representative files (long video, audio, image-heavy PDF) before scaling.
Direct benefits for your app
Less operational work: zero re-uploads and less temporary storage.
Cleaner scaling: you can aim for production without restructuring where you store data.
Multimodal flexibility: video, audio, images and documents can arrive via the path that best fits your infrastructure.
And now what? Update your SDKs to the latest version, review permissions and start testing with signed URLs and a simple GCS registration. If you already work with cloud pipelines, this can save days of engineering.
