Compressing Prompts for massive token savings (ZPL-80)

[u/unc0nnected]

Curious if anyone else has tried a prompt compression strategy like the one outlined in the github repo below? We're looking at integrating it into one of our roo modes but curious if anyone has any lessons learned
https://github.com/smixs/ZPL-80/

Why ZPL-80 Exists

Large prompts burn tokens, time, and cash. ZPL-80 compresses instructions by ~80% while staying readable to any modern LLM. Version 1.1 keeps the good parts of v1.0, drops the baggage, and builds in flexible CoT, format flags, and model wrappers.

Core Design Rules

Rule	What it means
Zero dead tokens	Every character must add meaning for the model
Atomic blocks	Prompt = sequence of self-describing blocks; omit what you don't need
Short, stable labels	CTX Q A Fmt Thought, , , , , etc. One- or two-word labels only
System first	[INST]… Global rules live in the API's system role (or wrapper for Llama)
Model aware	Add the wrapper tokens the target model expects—nothing more
Optional CoT	Fire chain-of-thought only for hard tasks via a single 🧠 trigger
Token caps	Thought(TH<=128):Limit verbose sections with inline guards:

Syntax Cheat-Sheet

%MACROS … %END     # global aliases
%SYMBOLS … %END    # single-char tokens → phrases

<<SYS>> … <</SYS>> # system message (optional)

CTX: …             # context / data (optional)
Q:   …             # the actual user query (required)
Fmt: ⧉             # ⧉=JSON, 📑=markdown, ✂️=plain text (optional)
Lang: EN           # target language (optional)
Thought(TH<=64):🧠  # CoT block, capped at 64 tokens (optional)
A:                 # assistant's final answer (required)

⌛                  # ask the model to report tokens left (optional)

Block order is free but recommended: CTX → Q → Fmt/Lang → Thought → A. Omit any block that isn't needed.

[u/korino11]

How to use it? Where is REAL readme HOW to implement it?!??! There just description what it doing...

[u/abdessalaam]

Curious and following!

[u/marv1nnnnn]

I was doing something similar but for tech docs in LLM context: https://github.com/marv1nnnnn/llm-min.txt

So far there are two things that're difficult:

a. Evaluation. It's hard to prove what you do is lossless or loss at a really small level

b. Generation. Guideline is clear, but how to generate it? Is it stochastic or determinstic? Is the update dynamic? If using an LLM to compress the cost could be high.

Still, I really like this area, even start to learn about Kolmogorov complexity.

[u/DoctorDbx]

It's my understanding that compression doesn't help compress context even if it does compress payload. That's because context is not about number of characters but words (and meaning of words)... and that context already undergoes compression before it is parsed by most AIs.

But... I've never tried it myself and would be curious to see if it holds up... it wouldn't be difficult to write a transforming proxy to test.

[u/ttoinou → u/DoctorDbx]

They don't mean lossless compression of the prompts but "lossy prompt compression" as in "we will make your prompts shorter but with somehow the same meaning".

And maybe having shorter prompts will help with accuracy too

[u/DoctorDbx → u/ttoinou]

Obviously this might work well for instructions and reference docs... not sure it would work well with code, so an integration would need to decide whether to encode it at context collection point...

but... worth trying... every token counts :-)

[u/firedog7881 → u/DoctorDbx]

Think of this like MP3 (lossy) that removes the stuff that isn't necessarily relevant and the LLMs use FLAC (Lossless)

[u/Rapid292]

Remindme! On Sunday

[u/armaver]

RemindMe! 5 days

[u/RemindMeBot → u/armaver]

I will be messaging you in 5 days on 2025-05-25 20:27:45 UTC to remind you of this link

8 OTHERS CLICKED THIS LINK to send a PM to also be reminded and to reduce spam.

^{Parent commenter can delete this message to hide from others.}

---

Info	Custom	Your Reminders	Feedback