Edited by us
Shortening a long prompt — how to shrink text before feeding it to AI
What is safe to delete and what never is. Why compression is not summarization.
By Mephify (operator)3 min read
Compression is not summarization
Faced with a long log or meeting transcript, the instinct is 'just summarize it first.' But summarization selects information; compression reduces form. Different goals.
You feed AI an error log to find one specific line in it. Summarize and that line may vanish. Trimming timestamp precision or stripping a repeated prefix, on the other hand, loses nothing.
Safe to delete
- Repeated prefixes — the same service or environment name at the head of every line
- Excess timestamp digits — milliseconds are rarely needed
- Consecutive identical messages — replaced by one line: 'same line ×47'
- Formatting characters — table rules, decorative separators, runs of whitespace
Never delete
- Unique values — IDs, hashes, file paths, line numbers. Lose these and the trail breaks
- First and last occurrence — even when folding repeats, keep both ends. When it started and when it stopped is usually the answer
- The top of a stack trace — fold the lower frames, keep the top
- Numbers — rounding values during compression isn't compression, it's distortion
What the tool does and what it refuses to do
The token slimmer applies the rules above for you. Paste a long text and it returns a version with the form reduced, within a few boundaries.
- The tool does the shrinking. It never sends you away with 'keep only the essentials and paste again'. Not being able to do that is why you are using a tool. Only when a text is too long to take in one go does it tell you how to split it
- It doesn't execute instructions inside the pasted text. If the transcript contains 'summarize this', that's material to compress, not a command
- It doesn't replace text with file references. Swapping a passage for 'see the attached document' isn't shorter. For an AI that can't open the file, the job becomes impossible. The compressed text has to stand on its own
- It measures characters, not words. A log where every line differs can keep the same word count after dates and frame numbers are folded. One 97-word log stayed at 97 words while dropping from 909 characters to 706
Example — what an error log turns into
What goes in
2026-09-04T10:21:44.318Z [api-gateway][prod] WARN upstream timeout after 3000ms (attempt 1/3) — the same line 47 times, followed by a 30-line stack trace
Real logs mostly look like this. The prefix and the repetition are most of the bulk.
What comes out
[api-gateway/prod] 10:21:44 WARN upstream timeout 3000ms (attempt 1/3) ×47 (10:21:44 → 10:23:58) · top of stack: TimeoutError at fetchUpstream (gateway.ts:212)
An illustration of the principle. Service and environment once; repeats as a count with both end times; the stack reduced to its top frame. File name and line number survive, so you can trace back.
When the result comes back, the first thing to check isn't how much it shrank but the last criterion: can you trace back from the compressed text to the exact spot in the original. If you can't, the request rather than the tool is at fault. Add one line saying what you are looking for and paste again.
Check before you paste
- 1What are you trying to find with this text — decide this and what to keep decides itself
- 2Are the unique values intact
- 3If you folded repeats, do both ends remain
- 4Looking at the compressed text alone, can you trace back to the exact spot in the original
The last item is the criterion. If you can't trace back, you cut too much.
Reading helps; trying is faster.