Markdown tables look nice in a chat window, but if a program is going to consume the output, the formatting is dead weight. Every cell is wrapped in | and , every table has a |---|---| separator row, and aligned columns add padding spaces -- none of which your parser needs.
Before -- a Markdown table for five products:
| Name | Price | In Stock |
|-------------|-------|----------|
| Widget A | 9.99 | yes |
| Widget B | 14.50 | no |
After -- the same data as CSV:
name,price,in_stock
Widget A,9.99,yes
Widget B,14.50,no
The CSV drops the separator row entirely, replaces | / | borders with single commas, and removes alignment padding. Across many rows the header overhead amortizes and the per-row savings are what add up.
Why it works: tokenizers count the punctuation and whitespace, not just the words. A Markdown row like | Widget A | 9.99 | yes | spends tokens on three pipe-space pairs plus padding; the CSV row spends two commas. Multiply by hundreds of rows and the difference is real money and lower latency, since fewer output tokens means faster completion. CSV is also trivially parseable with a standard library, so you remove brittle Markdown-table parsing from your code.
Guidance to keep it clean:
- Tell the model the exact header row and field order, and say "output CSV only, no code fences, no commentary" so you do not pay for a wrapping explanation.
- Specify how to handle commas inside values (quote them) if your data can contain them.
- For deeper nesting CSV breaks down -- reach for compact JSON or JSON Lines instead. CSV wins specifically for flat, rectangular data.
Reserve Markdown tables for output a human reads directly in a chat or rendered doc. The instant a machine is the consumer, the borders are just billed whitespace.