How to Cut LLM Costs: Compressing Logs and Data Reduces Tokens by 60-95%

I’m Denis Shokhirev, Enterprise AI architect based in Erlangen, Germany. At DennisCraft AI Studio, I deploy AI systems for DACH B2B clients—logistics, fintech, and industrial automation—using a stack of Claude, Supabase, n8n, Doppler, and self-hosted Postgres. Last quarter, one project’s LLM inference bill spiked by 60%—not because of prompts, but because log and session data swelled out of control. Here’s how I cut token usage by 60–95% using structured compression, not hand-waving.

Why Logs and Context Data Swallow Your Token Budget

When you move from demo to production, LLM token costs are rarely driven by prompt length alone. In regulated sectors, you almost always have to pass in traceability context: logs, event histories, transaction chains—often as JSON or verbose text. On several of my deployments, the prompt core was under 400 tokens, but “context” balloons to 3,000–10,000+ tokens per call. For example, in a recent IoT agent, each inference consumed 12,000 tokens—10,000 of which were just trace data. The culprit: raw, uncompressed logs and duplicated state chains.

Compression Methods That Actually Work

1. Semantic Log Aggregation

Instead of passing raw logs (full JSON, stack traces), I aggregate events into high-level state transitions. Example: collapse 100 log lines into 3–5 key state changes, phrased concisely (“User X changed Y to Z, status: OK”). This usually cuts token volume by 60–75%. I automate this with n8n: a workflow node parses logs and summarizes by event type, not line-by-line.

2. Structured Compression With Brotli/zlib

Plain JSON and text logs compress extremely well with Brotli or zlib. For production agents, I use a pattern like this:

import brotli
import json

def compress_log(log_dict):
    json_str = json.dumps(log_dict, ensure_ascii=False)
    return brotli.compress(json_str.encode('utf-8'))

def decompress_log(compressed):
    return json.loads(brotli.decompress(compressed).decode('utf-8'))

This is great for storage, but for LLMs you also need to strip unnecessary fields and shorten keys before serialization. Typical savings: 85%+ if you remove nulls and minimize key names. See Brotli documentation for details.

3. Syntactic and Lexical Minification

Repetitive event chains (“user_id”: “123”, “event”: “clicked”, “timestamp”: “…”) are prime for key shortening (“u”: “123”, “e”: “c”, “t”: “…”). For chains with identical events, I use run-length encoding (RLE):

def rle_events(events):
    compressed = []
    prev = None
    count = 1
    for ev in events:
        if ev == prev:
            count += 1
        else:
            if prev is not None:
                compressed.append({'event': prev, 'count': count})
            prev = ev
            count = 1
    if prev:
        compressed.append({'event': prev, 'count': count})
    return compressed

On real-world workflows, this cuts event chain token counts by 70–90% with no loss of LLM-relevant context.

Integrating Compression Into Your Production Pipeline

Pipeline Stages

In Supabase and self-hosted Postgres, I only store compressed logs. For prompt construction, I decompress and aggregate just the necessary context.

Automating With n8n and Supabase

With n8n, I build workflows where each log update passes through a custom Python node for minification and aggregation, then saves to Supabase. In regulated domains (fintech, industrial), compression is non-negotiable for audit and cost control.

How The Methods Stack Up in Practice

FAQ

What if I need full traceability for audits?

Store full logs in Postgres, but only pass compressed/aggregated context to the LLM. Use event IDs to reconstruct full audit trails as needed.

What are the risks of log aggregation?

You may lose fine-grained details critical for incident investigation. I only aggregate repetitive or routine events, and keep key errors uncompressed.

How do I automate compression in the pipeline?

n8n plus custom Python nodes for minification and aggregation; Supabase for storage. Typical workflow setup is 1–2 days for common use cases.

Any downsides to Brotli/zlib compression?

Slight decompression overhead (10–50 ms per event), but this is negligible in most production loads.

How to integrate with Claude Code or similar LLMs?

Always serialize data before prompt assembly. Never pass raw Brotli binaries into the LLM—aggregate and decompress first, pass only what’s needed.

Where in your LLM pipeline do logs balloon your token counts most—at prompt assembly, or in storage? I’d like to compare. I run a free 30-min stack audit for DACH founders building AI in regulated markets. DM me on LinkedIn or write to @ger_dennis_ai.