Claude Code und die neue Welle von KI-Coding-Tools im Terminal

Was CLI-Programmieragenten tatsächlich sind

Ein Programmieragent im Terminal besteht gewöhnlich aus fünf miteinander verbundenen Komponenten:

• Eine Chat-Schleife mit einem führenden oder offenen Modell
• Ein Repository-Indexer oder eine Schicht zur Dateisuche
• Eine Werkzeugausführungsschicht für Shell-Befehle und Dateibearbeitungen
• Ein Mechanismus zum Anwenden von Patches
• Eine Persistenzschicht für Gesprächsverlauf und Sitzungszustand

Der entscheidende Unterschied zur Autovervollständigung ist die Fähigkeit zum eigenständigen Handeln. Die Autovervollständigung sagt Code an der Cursorposition voraus. Ein Agent kann entscheiden, Dateien zu untersuchen, Tests auszuführen, Code zu ändern, Fehler zu analysieren und den Vorgang zu wiederholen.

Eine typische Schleife sieht so aus:

User task
  ↓
Agent builds prompt from instructions + repo context + prior messages
  ↓
Model proposes actions: read file, edit file, run command
  ↓
CLI executes allowed actions
  ↓
Results are added back into context
  ↓
Model plans next step
  ↓
Repeat until done or stopped

Diese Schleife ist der Grund, warum diese Werkzeuge so leistungsfähig wirken. Sie ist auch der Grund, warum sich Kosten und Latenz anders verhalten als bei der normalen API-Nutzung nach dem Muster „eine Frage stellen, eine Antwort erhalten“.

In der Praxis entstehen die meisten Kostenüberraschungen durch den Rückkopplungspfad: Befehlsausgaben, Dateiinhalte, vorherige Nachrichten und Diffs werden wiederholt in spätere Gesprächsrunden aufgenommen.

Claude Code, Aider, Cline und OpenCode: Unterschiedliche Ausprägungen desselben Musters

Die Werkzeuge haben unterschiedliche Interaktionsstile, aber das grundlegende technische Muster ist ähnlich.

Die entscheidende Frage ist nicht, „welches am intelligentesten ist“. Entscheidend ist, wie viel Kontext das Werkzeug sendet, wie es Dateien auswählt, wie es den Verlauf zusammenfasst und wie viel Kontrolle Sie über die Ausführung von Shell-Befehlen haben.

Aider funktioniert beispielsweise meist gut, wenn Sie die relevanten Dateien gezielt hinzufügen. Claude Code arbeitet stärker agentisch und kann sich wie ein erfahrener Entwickler anfühlen, der sich durch das Repository bewegt. Diese Autonomie bedeutet jedoch, dass Sie Berechtigungen und Umfang bewusst festlegen sollten. Cline ist im Editor praktisch, insbesondere wenn Sie Aktionen mitverfolgen möchten. Der Komfort im Editor kann es aber leicht machen, zu viele kostspielige Schritte zu genehmigen.

Workflows nach dem Vorbild von OpenCode sprechen Teams an, die bei der Anbieterwahl flexibel bleiben möchten: Claude für anspruchsvolle Architekturarbeit, GPT für die Implementierung, Gemini für die Analyse großer Kontexte oder offene Modelle wie Qwen, DeepSeek, Kimi, MiniMax und Llama für günstigere lokale oder selbst gehostete Durchläufe.

Wie diese Agenten die API nutzen

Eine einzige Anfrage wie „Behebe diesen Fehler“ kann zu Dutzenden API-Aufrufen führen.

Ein vereinfachter Anfragekörper für einen Agentenschritt sieht so aus:

{
  "model": "claude-sonnet-4.6",
  "messages": [
    {
      "role": "system",
      "content": "You are a coding agent. Follow repo instructions. Use tools safely."
    },
    {
      "role": "user",
      "content": "Fix the failing invoice total test."
    },
    {
      "role": "assistant",
      "content": "I will inspect the test and related invoice code."
    },
    {
      "role": "tool",
      "name": "read_file",
      "content": "tests/test_invoice_totals.py contents..."
    }
  ],
  "tools": [
    { "name": "read_file" },
    { "name": "apply_patch" },
    { "name": "run_shell" }
  ]
}

Die tatsächlichen Implementierungen unterscheiden sich, aber das Muster bleibt gleich:

1. Die CLI sammelt Kontext.
2. Das Modell entscheidet über die nächste Operation.
3. Die CLI führt die Operation aus.
4. Das Ergebnis wird an das Modell zurückgegeben.
5. Das Modell fährt fort.

Tools werden üblicherweise auf zwei Arten bereitgestellt.

Textbasierte Tool-Protokolle

Manche Agenten fordern das Modell auf, strukturierten Text auszugeben:

RUN: pytest tests/test_invoice_totals.py -q

Die CLI parst diesen Text und führt ihn aus. Das ist einfach und portabel, aber fehleranfällig. Wenn das Modell den Befehl ungewöhnlich formatiert, braucht die Ausführungsumgebung Schutzmechanismen.

Native Funktionsaufrufe

Andere Agenten verwenden Tool- oder Funktionsaufrufe der Modell-API. Das Modell gibt einen strukturierten Tool-Aufruf zurück:

{
  "tool_name": "run_shell",
  "arguments": {
    "command": "pytest tests/test_invoice_totals.py -q",
    "timeout_seconds": 60
  }
}

Das lässt sich leichter validieren. Der Agent kann Befehle ablehnen, die gefährlichen Mustern entsprechen, eine Genehmigung für Netzwerkzugriffe verlangen oder Schreibzugriffe auf den Arbeitsbereich beschränken.

Bei beiden Ansätzen ist nicht der Shell-Befehl der kostspielige Teil. Es ist der wachsende Prompt rund um den Shell-Befehl.

Warum Agentenschleifen die Token-Kosten verändern

Eine normale API-Integration sendet vielleicht 2,000 Eingabe-Tokens und erhält 500 Ausgabe-Tokens. Eine Coding-Sitzung mit einem Agenten kann so ablaufen:

Der Haken: Eingabe-Tokens machen oft den größten Anteil aus. Jede Schleife kann Systemanweisungen, Gesprächsverlauf, ausgewählte Dateien, Tool-Ausgaben und Zusammenfassungen erneut senden. Selbst mit Caching oder Kontextkomprimierung können lange autonome Sitzungen teuer werden, weil das Modell genügend Informationen über den aktuellen Stand braucht, um nicht blind zu handeln.

Es gibt vier häufige Token-Multiplikatoren:

• Vollständige Dateien als Kontext: Dateien mit 900 Zeilen senden, obwohl nur zwei Funktionen relevant sind.
• Ausführliche Testausgaben: Warnungen zu Abhängigkeiten, Fortschrittsbalken und nicht relevante Fehler einbeziehen.
• Wiederholte Repository-Durchsuchungen: find, tree, oder rg breit ausführen und die Ausgabe erneut in den Kontext einspeisen.
• Unbegrenzter Gesprächsverlauf: jeden fehlgeschlagenen Versuch beibehalten, statt Entscheidungen zusammenzufassen.

Was in einer unübersichtlichen Sitzung tatsächlich passiert, ist nicht, dass „der Agent intensiver nachdenkt“. Oft sieht er einfach mehr veralteten Kontext. Mehr Tokens können das Modell langsamer und unpräziser machen, wenn die relevanten Informationen darin untergehen.

Das Denkmodell: Budget pro Schleife statt pro Prompt

Wenn ich Kosten abschätze, denke ich in Schleifen.

Eine kleine, gezielte Aufgabe könnte so aussehen:

8 turns × 12k input tokens average = 96k input tokens
8 turns × 1.5k output tokens average = 12k output tokens

Eine Aufgabe, die sich verzettelt, könnte so aussehen:

35 turns × 55k input tokens average = 1.9M input tokens
35 turns × 3k output tokens average = 105k output tokens

Derselbe Nutzer-Prompt. Ganz andere Kosten.

Sie brauchen keine genauen Preise, um das grundlegende Problem zu erkennen. Sitzungen mit Agenten skalieren mit:

total cost ≈ Σ(input_tokens_per_step × input_price)
           + Σ(output_tokens_per_step × output_price)
           + tool/runtime overhead

Ausgabe-Tokens sind sichtbar, weil Sie dem Agenten beim Schreiben zusehen. Eingabe-Tokens bleiben verborgen, weil die CLI sie zusammenstellt. Auf dieser verborgenen Seite ist Budgetdisziplin entscheidend.

Modelle für die Arbeit mit Agenten auswählen

Ich verwende selten ein einziges Modell für alles.

Bei Terminal-Agenten sollte die Modellwahl zur jeweiligen Phase passen:

Eine praktische Konfiguration könnte Modelle der Sonnet-Klasse für die meisten Programmieraufgaben, Modelle der Opus/GPT-5.5-Klasse für schwierige Fehlersuche oder Entwurfsaufgaben, Modelle mit großem Kontextfenster wie Gemini/Fable für umfangreiche Analysen und offene Modelle für lokale Refactorings nach Art eines Linters verwenden. Die genauen Namen werden sich ändern; das Muster bleibt bestehen.

Ein häufiger Fehler ist, für die gesamte Schleife das teuerste Modell zu verwenden. Das teure Modell verbraucht dann kostspielige Tokens beim Lesen von node_modulesnahestehenden irrelevanten Informationen, Testwarnungen und generierten Dateien. Heben Sie sich das stärkste Modell für Entscheidungen auf, die es tatsächlich benötigen.

Konfigurationstipps, die einen Unterschied machen

Die beste Konfiguration ist nicht „maximale Autonomie“. Sie ist „schnelles Feedback mit eng begrenzten Berechtigungen“.

1. Generierte Dateien und Dateien von Drittanbietern ignorieren

Jeder Coding-Agent sollte eine Ausschlussliste haben. Beginnen Sie mit denselben Dingen, die Sie bei der Suche und beim Review ausschließen:

node_modules/
dist/
build/
coverage/
.venv/
__pycache__/
target/
vendor/
*.lock
*.min.js
*.map

Ich schließe Lockdateien normalerweise nicht global aus, wenn die Aufgabe die Auflösung von Abhängigkeiten betrifft, aber ich schließe sie aus dem Standardkontext aus. Eine Lockdatei kann bei Bedarf explizit einbezogen werden.

2. Gezielte Testbefehle verwenden

Lassen Sie den Agenten nicht bei jeder Iteration standardmäßig die gesamte Testsuite ausführen. Geben Sie ihm eine abgestufte Folge von Befehlen:

# First loop: fastest relevant test
pytest tests/billing/test_invoice_totals.py -q

# Second loop: nearby package
pytest tests/billing -q

# Final confidence check
pytest -q

Für JavaScript oder TypeScript:

pnpm test invoice-total.test.ts -- --runInBand
pnpm lint src/billing
pnpm test

Es geht nicht nur um die Laufzeit. Kleinere Ausgaben bedeuten kleinere Prompts in der nächsten Schleife.

3. Befehlsausgaben begrenzen

Wenn Ihr Agent Ausgabelimits unterstützt, nutzen Sie sie. Andernfalls begrenzen Sie die Ausgabe selbst mit einem Wrapper:

pytest tests/billing -q 2>&1 | tail -120

Oder bei Builds mit umfangreichen Ausgaben:

pnpm test 2>&1 | grep -E "FAIL|Error|Expected|Received|at " | head -200

Seien Sie vorsichtig: Filter können nützlichen Kontext verbergen. Ich verwende sie nach dem ersten Fehler, nicht davor. Erfassen Sie zunächst das Fehlerbild und begrenzen Sie dann die wiederholten Durchläufe.

4. Diffs statt Neufassungen anfordern

Weisen Sie den Agenten bei großen Dateien ausdrücklich an:

Make the smallest safe patch. Do not rewrite unrelated functions.
Show a concise diff summary before running tests.

Das verringert das Risiko und reduziert in der Regel die Ausgabe-Tokens. Noch wichtiger ist, dass Code-Reviews dadurch überschaubar bleiben.

5. Planung und Ausführung trennen

Bei komplexeren Änderungen beginne ich oft mit:

Inspect the relevant files and propose a plan. Do not edit yet.
Limit repo inspection to payment, invoice, and tax modules unless needed.

Anschließend genehmige ich den Plan und lasse ihn umsetzen. So vermeide ich das Fehlverhalten „Der Agent bearbeitet den Code, bevor er ihn verstanden hat“.

Kosten bei langen Sitzungen kontrollieren

In langen Sitzungen zeigen CLI-Agenten ihre Stärken – und werden zugleich riskant.

Hier ist die Checkliste zur Kostenkontrolle, die ich in der Praxis verwende:

• Ein Sitzungsziel festlegen: „Sorge dafür, dass test_invoice_rounding erfolgreich durchläuft“, statt „Repariere die Abrechnung“.
• Dateien nach Möglichkeit fest vorgeben: genaue Pfade angeben, statt den Agenten alles selbst suchen zu lassen.
• Nach einem Richtungswechsel den Kontext zurücksetzen: bei einer Änderung der Aufgabe eine neue Sitzung mit einer Zusammenfassung beginnen.
• Fehlschläge manuell zusammenfassen: die wichtigen 30 Zeilen einfügen, nicht ein Protokoll mit 3,000 Zeilen.
• Gezielt auf stärkere Modelle wechseln: ein stärkeres Modell erst einsetzen, wenn ein klares Hindernis auftritt.
• Nach wiederholten Schleifen stoppen: eingreifen, wenn der Agent zweimal auf dieselbe Weise scheitert.

Ein guter Prompt für einen Neustart sieht so aus:

We are fixing invoice rounding.

Known facts:
- Failure is in tests/billing/test_invoice_totals.py::test_round_half_even
- Expected 10.24, actual 10.25
- Decimal quantization happens in src/billing/money.py
- Tax calculation calls round_money() from src/billing/tax.py

Continue from this summary. Inspect only those files first.

Dieser Prompt kann günstiger und klarer sein, als eine ganze erfolglose Unterhaltung mitzuschleppen.

API-Schlüssel, Anbieter und Routing

Die meisten CLI-Agenten können direkt mit der API eines Modellanbieters oder über ein kompatibles Gateway kommunizieren. Die wichtigsten technischen Fragen sind:

• Authentifizierung: wo API-Schlüssel gespeichert sind und ob sie in den Shell-Verlauf oder in Protokolle gelangen.
• Modell-Routing: welches Modell welche Phase übernimmt.
• Anfragelimits: Agentenschleifen können in kurzer Zeit viele Anfragen auslösen.
• Beobachtbarkeit: Berichte zu Tokenverbrauch und Kosten pro Sitzung.
• Datengrenzen: ob Code an externe APIs gesendet werden darf.

Eine minimale Umgebungskonfiguration sieht oft so aus:

export ANTHROPIC_API_KEY="..."
export OPENAI_API_KEY="..."
export GEMINI_API_KEY="..."

Für Teams bevorzuge ich ein Wrapper-Skript, das Modelle auswählt und die Nutzung protokolliert:

#!/usr/bin/env bash
set -euo pipefail

export AGENT_MODEL="${AGENT_MODEL:-sonnet}"
export AGENT_MAX_OUTPUT_TOKENS="${AGENT_MAX_OUTPUT_TOKENS:-4096}"
export AGENT_SESSION_BUDGET_USD="${AGENT_SESSION_BUDGET_USD:-10}"

coding-agent "$@"

Wenn Sie ein Gateway für mehrere Modelle verwenden, kann es an dieser Stelle nützlich sein, Anfragen an Claude, GPT, Gemini oder offene Modelle über eine gemeinsame Schnittstelle zu leiten. Entscheidend ist nicht die Liste der Logos, sondern ob Sie eine zuverlässige Verbrauchserfassung und Steuerungsmöglichkeiten auf Modellebene erhalten.

Was ich in Repository-Anweisungen aufnehme

Die meisten Agenten beachten irgendeine Form von Anweisungsdatei im Repository. Ich halte meine kurz und praxisbezogen:

## Agent Instructions

- Prefer minimal diffs over rewrites.
- Do not run full test suites until targeted tests pass.
- Never edit generated files in `dist/`, `build/`, or `coverage/`.
- Use `rg` for search.
- Before large refactors, propose a plan and wait.
- If a command emits more than 200 lines, rerun with a narrower command.

Hier geht es nicht um Höflichkeit. Die Anweisungen prägen die Schleife. Der Agent wird weiterhin Fehler machen, aber gute Anweisungen reduzieren wiederholte Verschwendung.

Ein häufiger Fallstrick: Übermäßig lange Anweisungsdateien werden zum Hintergrundrauschen. Wenn Ihre Agentenanweisungen aus 300 Zeilen Stilphilosophie bestehen, übersieht das Modell womöglich die drei entscheidenden Vorgaben für die Arbeit. Stellen Sie die wichtigsten Regeln an den Anfang.

Latenz: der andere Kostenfaktor

Selbst wenn die Tokenkosten akzeptabel sind, kann Latenz den Arbeitsfluss unterbrechen.

Die Latenz eines Agenten entsteht durch:

• Inferenzzeit des Modells
• Ausführungszeit der Tools
• Zeit für die Dateiindizierung
• Testlaufzeit
• Wartezeiten auf menschliche Freigaben

Bei kurzen Schleifen optimiere ich auf die „Zeit bis zur nächsten nützlichen Beobachtung“. Ein gezielter Test von 15 Sekunden ist besser als eine vollständige CI-Simulation von 6 Minuten. Ein kleineres Modell, das einen Syntaxfehler in 4 Sekunden korrekt erkennt, ist besser als ein Premium-Modell, das 45 Sekunden für eine schöne Erklärung aufwendet.

Die besten Sitzungen fühlen sich wie Pair Programming an:

inspect → patch → targeted test → inspect failure → patch → targeted test → final suite

Die schlechtesten Sitzungen fühlen sich wie CI-Cosplay an:

scan repo → edit many files → run everything → drown in logs → repeat

Grenzen und Fehlverhalten

Terminal-Agenten sind nützlich, aber keine Magie.

Sie haben Schwierigkeiten, wenn:

• Das Repository verborgene Laufzeitabhängigkeiten hat, die nicht durch Tests erfasst werden.
• Die Aufgabe eine Produktentscheidung statt einer Codeumwandlung erfordert.
• Der Fehler von externen Diensten oder einem instabilen Zustand abhängt.
• Die Codebasis irreführende Abstraktionen oder veraltete Dokumentation enthält.
• Der Agent den relevanten Validierungsbefehl nicht ausführen kann.

Sie können auch plausible, aber falsche Korrekturen erzeugen. Das passiert besonders häufig bei schwachen Tests. Wenn der Agent das Verhalten nicht überprüfen kann, behandeln Sie seine Ausgabe wie einen ungeprüften Patch eines Junior-Entwicklers: potenziell nützlich, aber niemals automatisch vertrauenswürdig.

Auch Sicherheit ist wichtig. Gewähren Sie einem Agenten in einem sensiblen Repository keinen uneingeschränkten Shell-Zugriff, ohne das Freigabemodell des Tools zu verstehen. „Befehle ausführen“ umfasst auch die Möglichkeit, Umgebungsvariablen auszugeben, Dateien zu ändern, Pakete zu installieren oder auf das Netzwerk zuzugreifen, sofern dies nicht eingeschränkt ist.

Praktische Empfehlungen

• Betrachten Sie CLI-Coding-Tools als API-gesteuerte Regelschleifen, nicht als einzelne Prompts.
• Optimieren Sie die Kosten, indem Sie die Anzahl der Schleifendurchläufe und die Kontextgröße reduzieren, insbesondere die Befehlsausgaben.
• Verwenden Sie leistungsfähige Modelle für schwierige Denkaufgaben, nicht für jeden mechanischen Schritt.
• Halten Sie Repository-Anweisungen kurz, praxisbezogen und auf das Verhalten des Agenten ausgerichtet.
• Führen Sie bevorzugt zuerst gezielte Tests und zuletzt eine umfassendere Validierung durch.
• Starten Sie lange Sitzungen mit knappen Zusammenfassungen neu, statt einen veralteten Verlauf mitzuschleppen.
• Achten Sie auf Eingabetokens; sie sind der versteckte Kostenfaktor beim agentengestützten Programmieren.
• Stoppen Sie und greifen Sie ein, wenn der Agent dieselbe erfolglose Strategie wiederholt.

Claude Code, Aider, Cline und OpenCode sind Teil eines echten Wandels: Programmierassistenten entwickeln sich von Vorschlagssystemen zu Mitstreitern, die direkt im Terminal arbeiten. Am meisten profitieren werden nicht die Teams, die einfach „Agenten einschalten“. Es werden die Teams sein, die die Schleife gezielt gestalten: eng begrenzter Kontext, sichere Tools, nachvollziehbare Kosten und Überprüfung bei jedem Schritt.