Cutting LLM Input by 98%: How I Built Unpack

Every time I wanted an AI's help with one of my projects, I had to explain the project from scratch: the file structure, how the pieces connect, what I had changed since last time. It took a lot of time, and the explanation was never fully accurate. Unpack is the tool I built to stop doing that. You give it a codebase, and it streams back architecture documentation.

The problem: a codebase does not fit in a prompt

The obvious fix is to send the whole repository to an AI model. That fails quickly. On a large raw repository, the input came to about 6.45 million tokens, far beyond any model's context window. My early attempts with a big project like CyberCube ended with an AI telling me it was too huge and to try a smaller one.

That is not a useful answer for a tool whose job is to understand big projects. So the real problem became deciding what the model should never see.

The scanner: cutting 98% of the noise

Most of a repository is not worth reading. Build artifacts, binaries, lockfiles and generated files add size and no understanding. I wrote a custom scanner in Python that:

• Skips ignored directories, file names and extensions (build output, binaries, lockfiles).
• Enforces size caps on individual files, on the raw upload and on the final text sent to the model.
• Ranks files by importance so the most useful code is kept when the cap is reached.

That is a 98% reduction in model input, and it removes the context-window failures.

Three ways to bring in code

• Folder picker. The browser reads the folder directly. The files are filtered on the client side first, so less data is uploaded, and then zipped with JSZip.
• ZIP upload. The archive is opened in the browser, filtered, and zipped again.
• GitHub URL. The backend fetches a public repository, up to a size limit, and processes it the same way.

Four depths of analysis

Not every question needs a 20-page report, so Unpack offers four analysis depths. Each uses its own prompt and token budget, and the backend picks a model to match:

1. Quick Summary: a short overview of what the project is.
2. Standard Architecture: the main components and how they connect.
3. Deep Dive: everything: stack, data flow, schema, file breakdown.
4. Diagnose: a full audit that also lists security and technical-debt issues.

Streaming the answer

A detailed analysis takes a while to generate, so the backend streams it back as newline-delimited JSON events instead of making you wait for one big response. There are four event types: delta carries new text, ping shows the model is still working, done returns the final report, and error reports failures. On the frontend, a small XMLHttpRequest helper tracks both the upload and the streaming response, so the user sees live progress.

Accounts and cost control

Users sign in with Google or GitHub through Supabase Auth. The first time someone logs in, the backend validates their session, creates an OpenRouter key for that user capped at $0, and stores it in Supabase along with a SHA-256 hash of the key. The key is tied to the user's email, so each person gets their own.

A $0 cap means free models only, so the app cannot produce a surprise bill, and one person's usage cannot use up another's allowance.

Users can also choose between two modes: Temp, where the analysis is not saved, and Persistent, where it is stored in a history table in Supabase so they can come back to it.

Exporting in the browser

Reports can be downloaded as PDF, DOCX or PPTX. All three are generated entirely in the browser, with jsPDF, docx and pptxgenjs, so nothing goes through the server. Every export has the same branding: a purple and gold watermark, an UNPACK footer and page numbers.

Nothing in this project was dramatically hard, but the PDF was the fiddliest, and generating the watermark for all three formats took more time than I expected.

Does it work?

Yes, and I can prove it with my own projects. The architecture notes I keep for CreatorLens AI and CyberCube were generated by Unpack. They include the system architecture, tech stack, database schema, features, file breakdown and a list of technical-debt issues, and that is exactly what I built it to produce.

What I would improve next

• Add rate limiting to the key-provisioning and analysis endpoints.
• Redact secrets such as API keys from source files before they reach the model.
• Add automated tests, starting with the scanner's filtering rules.
• Validate uploaded archives more strictly, beyond checking their size.

Takeaways

With LLM apps, deciding what not to send matters as much as the prompt. Filtering the input removed 98% of the tokens and made large repositories workable, and it came from understanding what a model actually needs to see to describe a project.

• Live app: unpack-tau.vercel.app
• Code: github.com/NartanNaik/Unpack
• Stack: React, FastAPI, Python, Supabase, OpenRouter