Reading a 400-File Repo with Gemini 3.1 Pro in the Terminal

What to Paste When the Repository Has Two Hundred Modules

Most bad architecture reviews start with a paste buffer stuffed with half the monorepo. You drag in every file with the word service in its name, every schema dump you can find, and a stack trace for good measure, then ask Gemini 3.1 Pro whether the design is sound. The model spends its attention budget on noise and returns a summary of your file tree instead of a judgment about coupling, consistency, or failure modes. Large systems make this mistake expensive, because the prompt fills up before the interesting parts arrive.

Build the review bundle on purpose instead. Start with the boundaries: the public interfaces, the module contracts, the places where data crosses a process or a network, and the invariants the system claims to hold. Then add the two or three files where those claims are actually enforced. A short, honest bundle outperforms a huge, chaotic one, because the model can hold every relevant symbol in mind at once and reason about the seams rather than about formatting.

• Include the interface definitions and skip generated code that only repeats them.
• Add the schema and migration history before you add any handler code.
• Pin the review to one subsystem per request so findings stay actionable.
• Write down the invariants you believe hold and ask the model to falsify them.

When you do need breadth, say so explicitly and keep it separate from depth. A first pass that maps the whole system is a different request from a second pass that audits one hot path, and mixing the two is what produces the vague review notes nobody can act on.

Reviews That Cite Nothing Are Reviews You Cannot Ship

Ask an architecture question without constraints and you get a well-written opinion. Opinions do not fail builds, do not open tickets, and do not survive a design meeting with three skeptical staff engineers. The fix is to make every finding carry evidence: the file and function it points at, the invariant it breaks, the severity you should assign it, and the cheapest test that would prove it right or wrong.

Gemini 3.1 Pro is strong at this kind of structured synthesis when you give it the schema up front, but it will still invent plausible module names and confident load numbers when you leave blanks. Force it to say unknown rather than fill a gap, and you turn a fluent paragraph into a review you can actually file. Ask for numbered findings, one paragraph each, so you can paste them straight into issues.

• Ask for the exact symbol and the exact failure it would cause.
• Require a severity label so the list can be sorted during triage.
• Request one concrete test or observation for every single finding.
• Tell the model to mark any claim it could not verify from the bundle.

A cheap second pass keeps the loop fast. I run a triage sweep on Gemini 3.8 Flash to sort the obvious issues from the speculative ones, then hand the surviving findings to Gemini 3.1 Pro with the relevant files attached for the deep dive. The fast model is wrong more often, and that is fine, because it is only deciding where to spend the expensive attention.

Context Windows, Cache Reads, and the Invoice You Actually Get

Long review prompts are where careless routing turns into a surprising bill. Re-sending the same two hundred kilobytes of interfaces on every turn is not only slow, it means you pay to write and read that context again each time. If your relay bills cache reads and cache writes as real tokens, you can see that cost line by line instead of guessing at it, which is the difference between a review you run weekly and one you run once.

That is the workflow I keep on Fluxo. It is one key and one base URL, https://api.fluxorelay.com, in front of Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and more, billed per real token including cache reads and writes, with no monthly fee. It works with Claude Code, Codex, Gemini CLI and any OpenAI SDK, so the same review script that runs on your laptop runs in CI without a rewrite.

• Send the stable reference material first and let caching cover the repeats.
• Keep volatile findings in small follow-up turns instead of the giant prompt.
• Log token usage per review so regressions in prompt size show up early.
• Compare two models on the same bundle before you trust either opinion.

Cheap attention deserves cheap routing. Use the fast pass for scanning, the careful pass for judgment, and pay only for the tokens you actually send. When a review costs a few cents instead of a subscription commitment, you will review architecture before the migration instead of after it.

Diagrams Without Failure Paths Teach the Model Nothing

The next mistake is feeding a review a diagram plus a paragraph of marketing prose. Boxes and arrows describe the happy path, and every real architecture problem lives in the unhappy ones: the retry that doubles a payment, the queue that fills during a deploy, the cache that goes stale while a migration runs. A model cannot review what the prompt never mentions, so describe the failure paths in the same detail as the components.

Give the review a fixed scaffold so the answers stay comparable between runs. Name the request that matters most, its latency budget, its consistency requirement, and the blast radius when one dependency is slow. Then ask for the top failure modes in order of likelihood, the signal that would tell you each one is happening, and the mitigation you would reach for first.

• Describe the retry, timeout, and backoff policy for every outbound dependency.
• State the consistency guarantee each read path actually provides under partitions.
• List the deployment and migration windows where two versions coexist.
• Ask which single metric would show the system degrading before users complain.

When the failure paths are in the prompt, the review changes character. Instead of praising your layering, the model starts naming the timeouts you never set and the queues without backpressure, and those are the sentences worth pasting into a design doc.

Keeping Each Architecture Decision in Its Own Session

Chat histories rot. By the fourth hour the thread contains three unrelated subsystems, a corrected mistake the model keeps apologizing for, and a stale copy of the interfaces you fixed two turns ago. Every extra turn also re-reads that entire history, which quietly doubles your token bill and dilutes the attention that made the review useful in the first place.

Treat each decision as a fresh session with a fresh bundle. Save the review prompt and the interface snapshot as files in the repository, so the next engineer can rerun the same question and compare answers instead of inheriting your chat. Version the prompt the way you version the code, because a review that cannot be reproduced is only a rumour.

Once the prompts live in the repo, the tooling question gets simpler too. Keep one key and the base URL https://api.fluxorelay.com in your shell, and the same review runs in Claude Code, Codex, Gemini CLI, or any OpenAI SDK without glue code. When you bring someone onto the project and they pay for their own tokens, you earn a referral share of what they spend, which usually covers the reviews you run for the team. If you want to run this loop yourself, create a Fluxo account and point your first review at the repository you already have open.

Start with the smallest subsystem that still crosses a process boundary, and ask for one honest review instead of ten vague ones. The loop is cheap enough to repeat, the findings cite real symbols, and the next design meeting gets a document instead of an opinion. If anything about routing or billing is unclear once you are signed in, leave a note on the contact page and it will be picked up there.