token_efficient_responses v1.0.0

name: "token_efficient_responses" description: "Cut LLM output tokens without losing quality: measured compression techniques (Chain of Draft, Chain of Density, structure-over-prose, preamble removal, hard length constraints), when brevity wins, and how to measure the savings with a token-diff helper. Triggers on 'reduce output tokens', 'cut token costs', 'make the model more concise', 'responses are too verbose', or designing prompts for high-volume agent loops."

Purpose

Give an agent a practical playbook for spending fewer output tokens while keeping answer quality. Covers the techniques that have published measurements behind them, the rules of thumb that hold up in practice, and when compression is the wrong call.

Workflow

1. Decide if this task is compression-safe. Compression wins on: reasoning-heavy agentic work with a checkable answer, summarization, status updates, classification, data extraction. It loses on: explanations that need nuance for a human reader, legal or safety-sensitive content, first-run debugging where you want the full reasoning trace. When unsure, compress and spot-check quality on a small sample first.
2. Pick one technique from references/techniques.md matched to the task type:

• Multi-step reasoning with a verifiable answer -> Chain of Draft (5-word steps).
• Summarization -> Chain of Density (iterative entity fusion).
• Recurring reports or lists -> structured output (table, bullets, JSON) instead of prose.
• Chatty assistants -> preamble/postamble ban + concrete length constraints.

1. Apply it in the prompt. Use the templates in the reference file. Keep one prompt variant per change so you can attribute the effect.
2. Measure. Run a fixed set of 10-20 representative prompts through baseline and compressed variants. Count output tokens with bin/tokcheck.py and check answer quality by hand or a grader. Ship only if quality holds.
3. Re-verify on model changes. Published numbers (e.g. Chain of Draft's ~80% cut at ~4 points of accuracy on GSM8K) were measured on specific model versions. Re-run your own A/B when the model behind you changes.

Output Contract

The agent produces:

• A compressed prompt or prompt template for the target task, using one measured technique.
• A before/after token comparison (from bin/tokcheck.py) plus a quality check on the same sample set.
• A one-line call: ship it, or keep the baseline with the reason.

Example compression target and how to frame it:

# Before (verbose):
"Please carefully analyze the following log file and give me a detailed
explanation of what went wrong, being thorough and complete."

# After (compressed):
"From this log: list each distinct error as one bullet. Per bullet: error
name, first line number, likely cause. Max 5 bullets. No preamble."

Operating Rules

• Never compress away the checkable part of the answer. The error name, the number, the final answer stays; the narration goes.
• One technique at a time per test. Stacking tricks before measuring means you cannot tell which one paid off.
• "Be concise" alone is the weakest lever. Prefer numbers: word counts, bullet counts, step limits.
• Do not use compression to dodge a hard problem. If the model is wrong, shorter wrong is not better.
• When reporting savings, report tokens AND quality on the same sample set. A token count without a quality check is a guess.
• Respect API reality: output token counts depend on the model's tokenizer. Measure with the tokenizer that matches the model you bill against (tiktoken encodings for OpenAI; the provider's own usage fields otherwise).