AI answers are easy to get but expensive to read — a CLI that filters them down

You ask an AI assistant a question and an answer comes back. Reading it is the expensive part. I find the long round-trips tiring.

Ask it how to remove duplicates from a CSV in Python and you get 800 characters covering BOMs, encodings, and pandas design philosophy. What you actually need is twelve lines of code and one way to check it works.

Telling the assistant "be concise" ahead of time doesn't always help. Asking "tldr pls" costs another round-trip.

So I built a CLI that filters the answer after it's produced. Feed it a Markdown answer and it emits three sections: conclusion, minimal code, and verification. It takes stdin, so you just pipe it.

https://github.com/sunnydachs/concise-md

$ concise answer.md
## Conclusion
- The standard approach is exponential backoff with jitter:
## Minimal code
<emits the code block, verbatim>
## How to verify
- Test it with a mock that returns 429 three times and then 200.

The code section carries the actual code block from the answer, unchanged:

RETRYABLE = {429, 502, 503, 504}

def get_with_retry(url, **kwargs):
    for attempt in range(4):
        try:
            r = requests.get(url, timeout=30, **kwargs)
        except requests.RequestException:
            time.sleep(2 ** attempt)
            continue
        if r.status_code not in RETRYABLE:
            return r
    raise RuntimeError("gave up")

Zero dependencies, Python 3.11+, no LLM calls. Runs in 0.02 seconds.

I built that version first and tried it.

On a long Japanese input, the summary itself came out clean, but the code was broken.

In the deduplication example, the model generated a line that re-ran the same duplicate-count calculation on an already-deduplicated DataFrame, as part of "reorganizing" the code. Run it and you get removed 0 rows.

For a learning artifact, that is fatal.

Summarizing prose is what LLMs are good at. Code is a different story, so I drew the line there: don't touch code. With rule-based parsing, code blocks come out byte-for-byte identical. If the goal is keeping an AI answer as study material, that guarantee is the whole point.

The implementation is plain Markdown parsing.

It splits the input into heading-delimited sections, detaches code fences from prose, joins wrapped paragraphs, and breaks prose into sentences.

The conclusion is the first sentence containing a marker such as tl;dr, "in short", or "the standard approach", falling back to the opening sentence of the first section.

Code is capped at three blocks of 25 lines each. A block that opens with "DON'T" is treated as an anti-pattern and placed after the preferred example, not before.

For verification, a "Verification" / "How to verify" heading wins first; otherwise it picks up sentences containing words like "verify" or "check" from the prose.

Finally, if the prose is under 10 lines and there's at most one code block, the input is short enough already and passes through unchanged. Restructuring a short answer just costs the reader.

All of these decisions are covered by tests. Twelve of them run in CI on every commit (Python 3.11-3.13).

The Markdown parser is a collection of regexes, not a full CommonMark implementation.

Table rows are treated as prose, so a table-heavy answer can produce an odd conclusion.

Also, the tool only shortens how the document looks. It can't judge whether the content is correct. A wrong answer comes out as a shorter, wrong answer. If you are using this for study, run the trimmed code yourself.

On my own sample set, an 88-line English answer came out as 46 lines, and a 57-line Japanese answer as 26 lines. Both in 0.02 seconds.

Feed it an answer that is already to the point and nothing happens — it comes back unchanged. That's the spec.

When I use AI for learning, I realized I was losing time on reading, not thinking. This CLI is my one-lane fix for the "read it again" tax.

It's a personal OSS project with no warranty, but if something breaks, an issue is welcome.