Uploading files and a whole repository to Gemini

Most of what Gemini accepts is unremarkable and the limits are easy to hold in your head. One entry on the list is not: it takes an entire codebase as a single attachment, which changes what the chat surface is useful for.

A repository is one attachment

Gemini accepts one code folder, or one GitHub repository, with up to 5,000 files and a maximum of 100 MB, added to a chat.

That is a different proposition from pasting files one at a time. It puts the chat surface somewhere near the territory of a terminal agent for questions about structure, conventions and where a thing lives, without the setup a terminal agent needs. For a question like where does this project handle retries, it is often the shortest path.

The ceiling is real, though. Five thousand files and 100 MB rules out large monorepos, and a repository with generated artefacts or vendored dependencies committed will hit the file count long before the size.

The ordinary limits

• 100 MB per file for supported types generally.
• 2 GB per video, which is the one exception.
• 10 files in the same prompt.
• ZIP archives are accepted under the same 10-file and 100 MB rules, and cannot contain video or audio.

Media has a duration limit separate from its size, and this is where plan tier shows up. Video runs to 5 minutes and audio to 10 minutes by default. On Google AI Pro or Ultra those extend to 1 hour and 3 hours. If a recording is rejected after a long upload, duration is the more likely cause than size.

What the documentation does not say

Worth stating plainly rather than filling in.

The upload page describes what you may attach and how large it may be. It does not describe what Gemini reads from a file — whether a long document is processed whole or retrieved from in pieces — and it does not state whether uploaded files are retained separately from the conversation, or for how long.

For anything about persistence, the setting that governs the conversation is the one documented on activity, retention, and the review copy. Treat an upload as part of the chat it went into until Google says otherwise, and do not assume that a file has a shorter life than the conversation.

Try this

Attach a repository you know well and ask where a specific behaviour is implemented. Check the answer against the actual path. That tells you whether the whole tree is genuinely in play for your codebase, which is the thing the documentation does not promise.

What goes wrong

Attaching a monorepo. The 5,000-file ceiling arrives before the size one.

Blaming file size when a recording is rejected. Duration is capped separately and moves with your plan.

Putting video or audio in a ZIP. Explicitly unsupported.

Attaching a repository without reading what is committed in it. Secrets and customer material go along with the code.

Assuming an uploaded file is deleted when you delete the chat. The documentation does not say that, so do not rely on it.

How to check it worked

Ask something that can only be answered from a file deep in the tree rather than from a README, and verify the answer against the repository yourself. For anything sensitive, check which account you were signed into when you attached it, because that decides which terms the upload landed under, and no amount of deleting afterwards changes the account it went to.