Snapkin has an engineering blog now

Snapkin launched an engineering blog whose first post reports that appending one sentence to the system prompt — "Write the JSON minified: one line, no spaces or line breaks outside string values." — cut output tokens and made calls up to 30% faster and up to 28% cheaper on models that pretty-print JSON. Testing the same meal photo, prompt and JSON schema across ten models, Snapkin found five indent every answer, with 27 to 34% of output tokens being spaces and line breaks, while Claude Opus 5.5, Kimi K3 and Grok 4.7 already write single-line JSON. Gains shrink to 5 to 9% on reasoning models such as DeepSeek and Qwen because thinking tokens are billed as output and minifying does not touch them, and Snapkin now requests minified JSON on every meal analysis and correction.

Building Snapkin https://ma.ttias.be/introducing-snapkin/ means running a lot of experiments. Which AI model reads a plate best, what a prompt change does to the accuracy, how long you wait for an answer, what each call costs, … Those results get a home of their own now: Snapkin Engineering https://getsnapkin.app/en/engineering?utm source=ma.ttias.be&utm medium=referral&utm campaign=blogpost-snapkin-engineering-blog . Every post is one idea, built around a figure. The experiments that didn’t work go on there too, because those are often the more useful ones to read. There’s also a research section https://getsnapkin.app/en/research?utm source=ma.ttias.be&utm medium=referral&utm campaign=blogpost-snapkin-engineering-blog that covers the nutrition science behind the app. The engineering blog is the other half: how it’s built. Your LLM is billing you for whitespace your-llm-is-billing-you-for-whitespace The first post is about JSON. Snapkin asks an AI model to describe a meal as structured output: the dish, the items on the plate, the calories, and the follow-up questions it wants to ask you. Turns out most models pretty-print that JSON. Every field gets its own line, every line gets indented. You pay for each of those spaces and newlines as output tokens, and you wait while the model writes them, one token at a time. I sent the same meal photo, prompt and JSON schema to ten models. On seven of them, a big chunk of the answer was whitespace: Five models indent every answer, and on those, 27 to 34% of the output tokens are spaces and line breaks. Claude Opus 5.5, Kimi K3 and Grok 4.7 already write single-line JSON. The fix is one sentence, appended to the system prompt: Write the JSON minified: one line, no spaces or line breaks outside string values. On the models that indent, the whole call got up to 30% faster Gemini 4 Argon went from 30.5 to 21.4 seconds and up to 28% cheaper: The gain shrinks on reasoning models. Thinking is billed as output too and minifying doesn’t touch it, so DeepSeek and Qwen only save 5 to 9%. On the three models that already write one line, there’s nothing to gain at all. Grok even thought longer with the instruction, so leave it out there. Whether a model indents also depends on the request, not just the model. On a tiny test prompt, Gemini 3.8 Flash, GPT-6.1 and DeepSeek wrote single-line JSON without being asked. On the real production prompt, with its long system prompt and large schema, they indented. A quick test in a playground tells you very little: look at the raw output of your actual request. The full post https://getsnapkin.app/en/engineering/your-llm-is-billing-you-for-whitespace?utm source=ma.ttias.be&utm medium=referral&utm campaign=blogpost-snapkin-engineering-blog has the per-model numbers, the latency breakdown and how it was measured. Snapkin now asks for minified JSON on every meal analysis, and on every correction you make to one. Following along following-along There’s an Atom feed https://getsnapkin.app/en/engineering/feed.xml if you want new posts in your feed reader. No newsletter, no tracking. If you run structured output in production and you’ve measured something similar or the opposite , let me know. I’d love to compare notes.