Worked example: compress without losing meaning

Assume measurement with the production tokenizer gives this breakdown:

System and policy instructions       820 tokens
Eight-message email thread         3,450 tokens
Order and tracking JSON            2,100 tokens
Shipping policy excerpt            1,600 tokens
Internal notes and signatures        930 tokens
Current question                     180 tokens
Total                              9,080 tokens

The route’s input budget is 5,500 tokens, leaving a separate output allowance under the model’s documented limits. We need to remove 3,580 input tokens.

First identify the required decision: “Should support reship, refund, wait, or escalate?” Then list facts that can change that decision: order identity, payment status, destination, carrier events and times, promised delivery range, prior remedies, policy thresholds, customer request, and exceptions. This list becomes the preservation test.

Compression should be traceable. Keep links or IDs that let the application recover original records, and distinguish exact source facts from generated summaries.

The email thread repeats quoted messages under every reply. It also includes eight copies of a 120-word legal footer. The application can parse messages and retain each unique body once. That reduces the email section from 3,450 to 1,900 tokens without asking a model to decide what matters.

The order JSON contains image URLs, UI colors, analytics labels, empty fields, and duplicate customer display data. A typed projection keeps only:

{
  "order_id": "4812",
  "paid": true,
  "items": [{"sku": "LAMP-BLU", "quantity": 1}],
  "ship_to": {"city": "Salem", "postal_code": "97301"},
  "tracking": {
    "carrier": "ParcelCo",
    "last_event": "Delivery exception: address mismatch",
    "event_at": "2026-07-16T14:20:00Z"
  },
  "prior_refund": false,
  "prior_reshipment": false
}

Measured size falls from 2,100 to 520 tokens. Schema-aware selection is safer than crude character truncation because required fields are explicit and testable.

Removing repeated signatures and obsolete internal routing notes cuts the final noise category from 930 to 210 tokens. At this point, compression has been mostly deterministic.

The unique email bodies still use 1,900 tokens. Rather than requesting a vague summary, produce a structured ledger and verify it against the source:

Customer goal: receive working lamp before 2026-07-22; refund acceptable otherwise.
Address history:
- Original order: 18 Oak St, Salem, OR 97301.
- Customer correction on 2026-07-14: 81 Oak St, Salem, OR 97301.
Timeline:
- 2026-07-13: order marked shipped.
- 2026-07-16: carrier reported address mismatch.
- 2026-07-17: customer asked support to correct address.
Commitments: no refund or reshipment promised.
Open question: can carrier redirect, or must warehouse reship?
Source message IDs: m1, m3, m6, m8.

This ledger uses 310 measured tokens. It preserves the corrected street number—exactly the fact arbitrary truncation could lose. Dates remain absolute, and uncertainty stays visible. A reviewer or automated test should compare critical values with source records.

Do not compress conflicting facts into a false resolution. If one message says 18 Oak Street and another says 81, record both with timestamps and provenance. The model can then reason about which is current.

The 1,600-token policy excerpt covers damaged goods, international customs, lost packages, address errors, refunds, and reshipment. Retrieval or deterministic headings select the address-error and remedy sections, including definitions and one exception. The selected text measures 620 tokens.

Preserve exact policy wording when the recommendation depends on it. A generated summary saying “reshipments are allowed” could omit a waiting period or approval threshold. Here the compact packet includes:

• the exact address-correction rule;
• the carrier-redirection procedure;
• the reshipment eligibility conditions;
• the refund alternative;
• section IDs and policy version.

Policy selection saves tokens by reducing scope, not by weakening constraints.

The revised packet measures:

System and policy instructions       820 tokens
Verified conversation ledger         310 tokens
Projected order and tracking data    520 tokens
Relevant policy sections             620 tokens
Current internal notes               210 tokens
Current question                     180 tokens
Delimiters and source labels          90 tokens
Total                              2,750 tokens

The result is 6,330 tokens smaller than the original and 2,750 below the input budget. That spare capacity is useful headroom; it does not need to be filled.

Before shipping, test answer equivalence across representative cases. Does the compact packet produce the same correct action as the full packet? Specifically test conflicting addresses, prior refunds, policy exceptions, multiple items, missing timestamps, and customer deadlines. Track failures caused by missing context separately from model reasoning errors.

Compression is successful only when it preserves task performance and auditability. A short prompt that produces the wrong refund is not efficient.