Token-Kosten optimieren: Was LLMs über Code-Style verraten

Jim Montgomery hat eine detaillierte Analyse veröffentlicht, wie LLMs ineffizienten Code generieren – und wie das die Token-Kosten treibt. Die Erkenntnis: Modelle greifen auf veraltete Patterns zurück, die von modernen Web-APIs längst überholt wurden.

Das Problem

Output-Tokens kosten 3x bis 5x mehr als Input-Tokens. Modelle generieren oft Code, der:

• Länger ist (mehr Tokens)
• Fragiler (mehr Fehler)
• Weniger sicher (Sicherheitslücken)
• Probleme löst, die die Platform bereits gelöst hat

Konkrete Beispiele

Query Parameter Parsing:

• Model-Default: ~140 Tokens (manuelles Parsing)
• Web API: ~12 Tokens (Object.fromEntries(new URL(rawUrl).searchParams))
• Reduktion: 90%

Form Data:

• Model-Default: ~200+ Tokens (useState pro Feld)
• Web API: ~14 Tokens (Object.fromEntries(new FormData(event.target)))
• Skaliert ohne zusätzliche Tokens

Fetch Timeout:

• Model-Default: ~90 Tokens (manuelles AbortController-Setup)
• Web API: ~12 Tokens (AbortSignal.timeout(5000))

Die Ursache: LLMs wurden mit Node.js-Code trainiert, bevor Web-APIs universell wurden. Sie kennen express, body-parser und manuelle Patterns – nicht die nativen APIs in Deno, Cloudflare Workers und modernen Runtimes.

Die Lösung: Modelle explizit über die Runtime-Umgebung informieren und moderne Web-APIs im Prompt bevorzugen.

Quelle: jimmont.com