I gave Gemma 4 access to my Google Drive without sending a single file to the cloud

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Gemma Drive is a local AI assistant for Google Drive that runs entirely on your laptop. Files extracted on-device, summaries generated on-device, questions answered on-device. The only data that crosses the network is the Drive API call that downloads the file you've explicitly chosen to analyze.

The problem it solves is straightforward: every "AI for your files" tool I've tried requires me to upload my data to someone else's server. As a patent agent, that's a non-starter. My (patent work) Drive is full of client work, invention disclosures, and prosecution files that aren't going to a third-party LLM no matter how good the marketing copy is.

So I built one that doesn't.

What it does:

• Connects to Google Drive via OAuth with the narrow drive.readonly scope. Tokens stored locally in SQLite.
• Lets you browse your Drive in a custom file browser, search by name, and add individual files or entire folder trees recursively.
• Extracts text from PDFs, DOCX, XLSX, PPTX, Google Docs/Sheets/Slides, plain text, and markdown.
• Generates per-file summaries with Gemma 4 E4B, then rolls those up into per-folder summaries.
• Answers free-form questions across the entire workspace using the summaries as context — "what are the main themes across these folders," "which folder is most relevant to patent prosecution," that kind of thing.
• Surfaces every unsupported file (images, audio, archives) in a dedicated transparency panel with its full metadata, so nothing gets silently dropped.

The stack: Ollama running Gemma 4 E4B with CUDA acceleration on an NVIDIA GeForce RTX 4070 Laptop GPU. Django + DRF for the backend (OAuth, Drive API, extraction pipeline, prompt orchestration). React + TypeScript + shadcn/ui for the frontend. SQLite for storage. No vector database, no Celery queue, no Postgres — the simplest stack that does the job, because for a single-user local tool, anything else is overkill.

Demo

The clip shows the full flow: adding a folder from Drive (which walks all subfolders recursively), clicking "Process workspace" to extract and summarize, then asking Gemma a free-form question about the contents. Total time on my hardware: about 14 seconds for this small example folder (featuring non-patent, non-client work related to conferences); a real workspace with 50+ files takes 1-3 minutes to fully process the first time, after which everything is cached.

Code

GitHub: https://github.com/KISSPatent/gemma-drive

Setup is one terminal session plus one Google Cloud project. The short version:

1. Install Ollama and pull the model
2. Clone the repo
3. Create a Google OAuth client with drive.readonly scope (instructions in the README)
4. Run Django (python manage.py runserver) and Vite (npm run dev)
5. Open localhost:5173, connect your Drive, start adding folders

How I Used Gemma 4

I picked Gemma 4 E4B specifically, and the why matters because it represents a different kind of model-selection thinking than I'm used to.

When I'm building alpha versions of my RocketSmart platform, my default is to reach for the most powerful model available — get the capability right first, optimize later. For a local-first tool, you flip that. The first question is what can run at all on the target hardware, the second is what runs at conversational speed, and only then do you ask whether it's smart enough.

Eighteen months ago, getting GPT-4-class "chat with my PDFs" quality meant renting a big cloud model or running a 30B–70B model on a workstation-class GPU. Today, a ~4B-parameter Gemma 4 E4B-class model can do local PDF QA at conversational speed on a consumer GPU using only single-digit GB of VRAM. My laptop has an NVIDIA GeForce RTX 4070 Laptop GPU — plenty capable, but a long way from the H100s and A100s people benchmark on. I needed a model that gave me real answers about real documents fast, not the smartest model that could grudgingly fit.

Why E4B was the sweet spot:

• 4.5B effective parameters (8B with embeddings) in a Matformer architecture, quantized to ~6 GB at Q4_K_M. Fits comfortably in my GPU's VRAM with room for the OS and browser.
• 128K context window — large enough that I didn't need a RAG layer for v1. Folder summaries fit in context for workspaces under a few hundred files.
• Native multimodality in the weights (text + vision + audio + function calling). I'm only using text in v1, but the vision and audio paths are available one runtime upgrade away.
• ~30 tokens/sec generation speed on my hardware — 11 seconds for a 300-token summary, 1-2 minutes to process a folder of 20 mixed-format files.

The summaries E4B produces are genuinely useful — not "good enough for a demo" but "good enough that I use the tool for actual work." This is one of those moments in AI where the "best model for the job" stops being a synonym for "the biggest model you can afford" and starts being a real engineering tradeoff between speed, cost, capability, and where the workload runs.

How E4B powers each part of the pipeline:

1. Per-file summarization. Each picked file's extracted text gets sent to Gemma with a prompt asking for a 2-4 sentence summary focused on what the document is about, its purpose, and distinguishing names/dates/identifiers.

2. Per-folder roll-up. The file summaries for each folder get fed back to Gemma as a single batch with a prompt asking for a paragraph describing the folder as a whole — common themes, key entities, what someone would use the folder for.

3. Free-form Q&A. The user's question gets prepended to all folder summaries plus all file summaries in a single prompt. The system message constrains Gemma to use only the provided context and to say so directly when the answer isn't in the workspace.

The 128K context window matters here specifically — it means I can dump every summary in the workspace into a single prompt and let Gemma do the synthesis natively, without needing embeddings, vector search, or any retrieval layer. That keeps the architecture radically simple: extraction → summarization → ask. If folder counts grow past where context-stuffing works, I'll add sqlite-vec and embeddings, but I'm not paying that complexity cost until I have to.

Three things I learned about running Gemma 4 in production (in the loose sense of "production"):

Ollama's API doesn't expose audio yet

E4B has native audio understanding in the weights. I tested it on Day 1, expecting to ship audio support in v1. Two failures:

{"role": "user", "content": "Transcribe this audio.", "audios": ["<base64 audio>"]}
{"type": "input_audio", "input_audio": {"data": "<base64 audio>", "format": "mp3"}}

That second error is interesting in a frustrating way — Ollama saw the non-text content block, routed it to the only multimodal pipeline it currently exposes (images), and tried to decode my MP3 as a PNG. The GitHub issue requesting audio support (ollama/ollama#11798) is still open. Audio works today through llama.cpp's server directly with the mmproj file — I just didn't want to add a second runtime for v1. The model has the capability; the runtime API doesn't ship it yet.

Ollama silently truncates at 2,048 tokens by default

After my first round of summarization, I noticed the database had empty strings even though the endpoint reported success for every file. The culprit: num_ctx defaults to 2,048 tokens in Ollama unless you explicitly set it. That's roughly 8,000 characters. My 11,000-character PDFs were getting silently truncated during inference, and the model returned empty content rather than partial answers.

The fix is one line:

"options": {"num_predict": 600, "num_ctx": 32768}

The default makes sense for chat-style interactions; it bites the moment you summarize anything longer than a short email.

Unsupported files belong in a transparency panel

Most AI-on-your-files tools quietly skip what they can't handle. I built a dedicated panel that lists every file in the workspace whose MIME type isn't in the extraction pipeline — with name, folder path, MIME type, modification date, and owner. It changes the implicit contract: instead of "this tool understands your Drive," it's "this tool tells you exactly what it understands and what it doesn't."

For my Drive specifically, the panel surfaces a hundred-plus JPGs of conference photos and a few audio recordings, as this Drive is for non-patent, non-client work. Once Ollama exposes audio and I add image handling for Gemma's vision, those move into the supported list. Until then, they're not hiding.

What's next: audio and video, image-heavy PDFs (via Gemma 4's vision once I add rasterization), RAG with sqlite-vec if context-stuffing stops working, streaming chat responses, and a "watch this folder" mode that auto-extracts on Drive changes.

The whole project is built on a specific claim: edge-class AI is now good enough that you don't have to send your files to someone else's cloud to get useful work out of an LLM. A week of building, four real engineering gotchas, and one working tool later — I think the claim holds up.