Vigyata.AI
Is this your channel?

Code LLM Context 5.6× Compression, No Performance Loss

14.9K views· 38 likes· 16:27· Oct 21, 2025

🛍️ Products Mentioned (2)

Cut token costs & latency for code LLMs with LongCodeZip compresses long code context up to 5.6× without hurting task performance. We break down the dual-stage pipeline (function-level ranking → block selection) and how to apply it on real projects. ☎️ Do you need any career or technical help? Book a call with me: https://calendly.com/mg_cafe Reference Code in Discord channel under reference section: https://discord.gg/2kcjQFMCr5 ****************** LET'S CONNECT! ******************* Join Discord Channel: https://discord.gg/2kcjQFMCr5 ✅ You can contact me at: LinkedIn: https://www.linkedin.com/in/mohammad-ghodratigohar/ Email: mo.ghodrati95@gmail.com Twitter: https://twitter.com/MG_cafe01 🔔 Subscribe for more cloud computing, data, and AI analytics videos by clicking on the subscribe button so you don't miss anything. #CodeLLM #ContextCompression #LongCodeZip

About This Video

In this video, I break down a really practical research result called LongCodeZip: a code-specific way to compress huge code context (up to 5.6×) without sacrificing the downstream coding performance of your LLM. The whole motivation is simple: as your input context grows, transformer attention gets expensive (latency goes up, token cost goes up), and the model also gets worse at finding the relevant parts inside a massive prompt. And even with “big context” models, real repos can still blow past your budget—plus code isn’t like natural language text because it’s structured and full of cross-file dependencies. Then I show how LongCodeZip actually does the “magic” with a dual-stage pipeline. Stage 1 is coarse-grained function-level filtering: instead of embeddings/similarity (which can fail badly for code), it ranks functions using an AMI-style score based on how much the function reduces the model’s surprise/perplexity when answering your query. Stage 2 is fine-grained block selection inside those functions using perplexity spikes to decide block boundaries and keep only the helpful sub-blocks. The takeaway: you can feed a much smaller prompt (hundreds of tokens instead of thousands), keep accuracy, and cut latency (they show examples like ~15s down to ~6.6s) by doing smart code-aware compression plus dynamic retrieval.

Frequently Asked Questions

🎬 More from MG