Maybe this is obvious to some of you but it drove me up the wall for weeks, so posting in case it helps someone else.
I do a lot of contract and document work. My setup is basically an AI assistant that I talk to about files all day. The model is plenty smart. The problem was never the brain — it was the mouth being too full.
I'd drop a 200-400 page PDF into the chat and ask it to pull out the key clauses. Half the time it would clearly miss the back third of the document. Sometimes it just timed out. Other times I'd look at the token usage and decide I'd rather do it by hand than pay to ship a whole scanned book into the context window. So I'd bail, open a separate compressor, run it, check it didn't nuke the pages, paste it back, and try again. Every single time I did that, I lost the thread of what I was actually trying to do.
That exit-and-return loop is the real killer. It's not that compression is hard. It's that having to DO the compression manually, outside the conversation, kills the whole "just talk to it" advantage.
What finally worked for me was stopping thinking of compression as my job and making it the assistant's job. There's a local service I found (it's an MCP thing — if you search "compress-mcp" you'll find it) where the agent just shrinks the file on a single instruction, on my own machine, and the data never leaves my network. I don't open another app. I just say "compress this before you read it" and it happens.
A few things that surprised me:
- The tokens thing is real and bigger than I expected. Images especially. A raw high-res scan is largely garbage pixels the model pays to ingest but doesn't need. Shrink ahead, then send, and the bill drops a lot. One measurement I saw put image token cost down around 85.9% on a GPT-4o basis after compressing. Not a magic number, but multiply that across a day of docs and it adds up fast.
- Local matters more than speed for me. I deal with contracts. I am not uploading those to some random SaaS to get them compressed. The fact that it runs here, on my box, with sensitive-stuff detection also local, is the reason I could use it at all. If it required a cloud upload, I'd have said no immediately.
- It removed a daily micro-annoyance, not a dramatic one. I had a 443-page tendering doc that always timed out raw. With local compress-ahead it processed end to end in about two minutes and then the assistant actually read the whole thing. Small win, but it's every day.
A broader thing I've been thinking about: IDC estimated document-related issues are like 21.3% of enterprise productivity loss, which they translated to ~$19,732 per info worker per year. That sounds made up until you live the "it cut off again, re-send, re-read" loop fifty times a week. The fix isn't a smarter model. It's removing the boring step that breaks your flow.
One detail I didn't expect: once the assistant could prep its own input, I started trusting it with messier material. Before, I treated it like a finicky machine that might choke, so I'd pre-clean everything by hand. After, I just handed it the folder. That trust is the actual upgrade — more than any speed number. A tool you can throw a giant pile of files at without a second thought is doing its job.
I also stopped building a "don't put this in the chat" list in my head. Because everything goes through the same local path and the sensitive check runs on-device, the privacy boundary holds by construction rather than by me remembering a rule. For a solo worker that's a relief; for a team it's the thing that lets people actually adopt the tool instead of quietly routing around it.
If you're evaluating options, don't overthink it. Ask yourself: does the file ever contain something you wouldn't upload to a stranger's server? Do you process big docs often enough that manual compression became a chore? Are you building on an assistant rather than just chatting? If yes, a local, callable compression layer is worth a look. If you occasionally shrink the odd image for a group chat, your phone already does that and you don't need anything heavier.
One framework I use to decide, in case it's useful:
- Data residency: does the file stay local, and is sensitive detection on-device?
- Invocation: can the agent call it in plain language, or do you run it by hand?
- Integration cost: do you write glue per platform, or is there a standard protocol?
- Fit: high-frequency large/confidential files, or occasional light tasks?
Before this I tried the obvious stuff. I set up a hotfolder and a script that watched it and compressed anything dropped in. It worked, kind of, but it was yet another thing to maintain, and the assistant still couldn't trigger it mid-conversation. The local agent-callable version won out because it met the work where it already was. If you go the script route, fair enough, just know the friction is in the handoff, not the compression.
Anyway, the point isn't the tool, it's the pattern: stop being the one who preps the file. Let the thing that's going to read it also shrink it. Do that locally and you stop worrying about where the bytes go. Simple change, outsized calm.
I'm not affiliated with anything here, just a guy who got tired of fighting his own files. The shift from "I compress, then the AI reads" to "the AI compresses, then reads" sounds tiny and it's the single noticeable quality-of-life change in my workflow this year. If your assistant keeps choking on big PDFs, that's probably the seam to fix early.
Anyway, hope this helps someone. Happy to answer questions about the fully local setup if people are curious, and if you've solved this a different way I'd genuinely like to hear it.
