How a networking student ended up writing Rust, beating industry-standard compression, and learning more about computers than any classroom taught me.
The Problem That Started Everything
I was messing around with LLM APIs. Claude, GPT, the usual. And I kept hitting the same wall: context windows cost money. Every token you send costs. Every token the model reads costs. If you’re building anything serious on top of these APIs — agents, memory systems, anything that needs conversation history — you’re constantly fighting the token budget.
The obvious solution is compression. Compress your context before sending it, decompress on the way back. But here’s the thing nobody talks about: standard compression algorithms weren’t built for LLM data. Gzip was designed for web assets. Brotli for HTTP. Neither was trained on the specific patterns that dominate LLM conversations — repeated phrases, structured JSON, code snippets, the same function names appearing dozens of times across a session.
I thought: what if I built something specifically for this?
I have an A+ cert. I’m in school for networking. I had never written Rust. I had never implemented a string matching algorithm. I didn’t know what Aho-Corasick was.
Six months later, GN (Glasik Notation) compresses LLM conversation data at 2.48-3.00x ratio, beats gzip on every corpus tested, and on short IRC-style messages beats brotli by 47%.
Here’s how it happened.
What I Knew Coming In
Networking teaches you to think in bytes. Packets, headers, payloads. MTU limits. Bandwidth vs latency tradeoffs. When you spend time thinking about why a TCP packet is structured the way it is, you develop an intuition for data representation that a lot of software developers never get.
I also knew that compression, at its core, is just finding patterns and encoding them more efficiently. ZIP finds repeated byte sequences. Huffman coding gives frequent symbols shorter codes. That’s it. The magic is in how cleverly you find patterns and how efficiently you encode them.
What I didn’t know: how to implement any of this. So I started reading.
The First Attempt: Embarrassingly Bad
My first compression attempt was a lookup table. I manually collected common LLM phrases and replaced them with single bytes. Classic dictionary substitution.
The ratio? About 1.1x on good days. Gzip does 2.4x. I was losing badly.
But it taught me something important: the dictionary matters more than the algorithm. If you have the right patterns, even simple substitution works. If you have the wrong patterns, nothing saves you.
Learning Aho-Corasick
The problem with simple dictionary lookup is speed. If you have 20,000 patterns and a 2,000 byte message, naively checking every pattern at every position is O(n x m x k) — too slow to be useful.
Aho-Corasick builds a finite automaton from all your patterns simultaneously. You scan the input once, left to right, and the automaton tells you which patterns match at each position. Linear time regardless of how many patterns you have.
This is where my networking background helped. I already understood finite state machines from studying how network protocols work — TCP state diagrams, regex engines in firewalls. Aho-Corasick was the same concept applied to string matching.
I implemented it in Rust. Its type system forced me to think clearly about ownership and memory — things networking had taught me to care about but that most high-level languages hide.
The Vocabulary Problem
An AC automaton is only as good as its vocabulary. I needed to learn what patterns actually appear in LLM conversations.
I downloaded four public datasets:
· ShareGPT v3: 600k human-AI conversation turns
· WildChat: Multi-language LLM conversations, avg 3589B per turn
· LMSYS-Chat: Academic LLM benchmark data, avg 1921B per turn
· Ubuntu IRC: Technical support dialogues, avg 67B per message
I wrote a sliding window tokenizer that learns patterns from the data. After training on 500k chunks, the L0 vocabulary had 20,000 entries covering the most common LLM patterns.
The top entries: 8-space indentation (high frequency in code), ” the”, “and “, “ing “, paragraph breaks, common function names, JSON structure.
Split-Stream Architecture: The Key Insight
After AC matching, you have two streams:
· Token IDs: Single bytes representing matched patterns (1-254)
· Literals: The raw bytes that didn’t match any pattern
These two streams have completely different statistical properties. Token IDs are low-entropy — a small alphabet of 254 symbols, highly repetitive. Literals are higher-entropy — the unique residue.
By deflating them separately and combining the compressed streams, each gets optimally compressed for its own statistics. The token stream deflates at 9.4x. The literal stream deflates at 2.87x.
The frame format:
[2B token_stream_length][token_stream_deflated][literal_stream_deflated]
Combined result: 2.48-3.00x across four public corpora.
The Numbers
I ran 24 independent measurements per corpus. Fair comparison against gzip-6 and brotli-6 at the same batch size.
ShareGPT (avg 846B): 2.483x vs gzip +2% vs brotli -5% p50 0.43ms
WildChat (avg 3589B): 2.833x vs gzip +3% vs brotli -7% p50 1.18ms
LMSYS (avg 1921B): 3.004x vs gzip -0.6% vs brotli -6% p50 0.66ms
Ubuntu-IRC (avg 67B): 2.536x vs gzip +62% vs brotli +47% p50 0.06ms
The Ubuntu-IRC result is the most striking. On 67-byte average messages, gzip achieves only 1.06x and brotli achieves 1.17x. GN achieves 2.54x. On short domain-specific messages, GN is in a different compression tier entirely.
Why? Because GN’s vocabulary is trained on the specific domain. IRC messages about Linux troubleshooting contain ubuntu, sudo apt-get, /dev/sda, terminal — patterns GN knows and general-purpose compressors don’t.
What I Got Wrong
The window update bug. I added per-chunk window updates inside the batch compression loop. This triggered the Aho-Corasick automaton to rebuild at every 10th chunk — a 35x latency regression that took days to find. Fix: update vocabulary once per batch, not per chunk.
Fake benchmarks. Early on I tested with synthetic text — repeated sentences. The ratios looked incredible. When I switched to real corpus data, they collapsed. Real data is the only benchmark that matters.
Dictionary quality. My first trained vocabulary included spam patterns — ubuntu repeated 35 times, Spotify API strings. These filled vocabulary slots with noise. Proper filtering was essential.
What Networking Taught Me That CS Didn’t
Think in bytes, not objects. Every compression decision comes down to: how many bytes does this cost vs save? Networking trains you to count bytes obsessively.
Latency is not throughput. A compression algorithm that achieves 3x ratio but takes 50ms per message is useless for real-time applications.
The protocol mindset. GN’s frame format is just a protocol. I designed it the same way I’d design a packet format: minimize overhead, make it parseable without side information, handle edge cases at the boundary.
Real systems fail in weird ways. My Node.js native addon path was 12x slower than my Python path on identical data. Finding this required the same methodical elimination I use to debug network issues.
Where It Is Now
GN is currently deployed in my OpenClaw setup. It compresses conversation context before storage and retrieval, saving real API costs.
Architecture:
· L0: 20,035 static entries trained on LLM corpora
· L1: Domain-specific per-session vocabulary
· L2: Sliding window that adapts to session content
· L3: Per-chunk ephemeral patterns
· VTC v3: Deterministic SHA256 crystal identity per compressed frame
Codebase is in Rust with Python (PyO3) and Node.js (napi) bindings. An arXiv paper is in preparation.
What I’d Tell Someone Starting Out
You don’t need a CS degree to try to build real systems. You need:
A real problem. Not a tutorial project. Something that costs you actual money or time. The willingness to read papers and I think you don’t need to understand the proofs. You need to understand the idea.
Real data benchmarks from day one. Never test on synthetic data. It will lie to you.
Obsessive measurement. If you can’t measure it, you can’t improve it.
Instrument everything.
The networking mindset. Think in bytes. Count everything. Every abstraction has a cost.
The A+ cert taught me that computers are physical things moving electrons around. That turned out to be exactly the right mental model for building a compression algorithm.
GN is open source at github.com/atomsrkuul/glasik-core.
Robert Rider — Independent Researcher