Crush – Ein leistungsstarker KI-Coding-Agent für das Terminal

 (github.com/charmbracelet)
5 Punkte von GN⁺ 2025-08-01 | 2 Kommentare | Auf WhatsApp teilen
  • Als AI-Coding-Agent, der im Terminal läuft, unterstützt Crush die Code-Erstellung, Workflow-Automatisierung und Kontextpflege im Code, indem es mit verschiedenen LLMs (Large Language Models) zusammenarbeitet und so die Code-Produktivität steigert.
  • Es lassen sich mehrere Modelle wählen oder während einer Sitzung frei das Modell wechseln, und es unterstützt die Sitzungskontext- und Projektkontext-Persistenz.
  • Es bietet entwicklerfreundliche Funktionen wie LSP (Language Server Protocol)-Integration, erweiterbare MCP (Model Context Protocol)-Unterstützung sowie Ignorierregeln über .gitignore und separate Dateien.
  • Es läuft auf allen wichtigen Terminal-Umgebungen wie macOS, Linux, Windows, FreeBSD und lässt sich über einen Paketmanager, Go oder Binärdateien installieren.
  • Es unterstützt eine intuitive Konfiguration und gleichzeitig umfangreiche Anpassungsmöglichkeiten, einschließlich Umgebungsvariablen, JSON-Konfiguration und Tool-Whitelist – ein Design, das auch erfahrene Nutzer berücksichtigt.

Crush

  • Ein AI-Coding-Agent, der in der Terminal-Umgebung läuft und sich frei mit den bevorzugten LLMs eines Entwicklers verbindet, um Code-Erstellung, -Bearbeitung und -Automatisierung zu unterstützen.
  • Es können frei verschiedene Modelle (Anthropic, OpenAI, Groq, OpenRouter usw.) ausgewählt und gewechselt werden; der Kontext wird pro Sitzung separat verwaltet.
  • Über LSP (Language Server Protocol) wird je nach Sprache zusätzlicher Kontext abgerufen, sodass die Code-Unterstützung noch intelligenter funktioniert.
  • Über MCP (Model Context Protocol) können zusätzliche Informationen aus externen Systemen, HTTP, der Kommandozeile, SSE und anderen Quellen gesammelt und genutzt werden.

Hauptfunktionen

  • Multi-Model-Support: Integration mit verschiedenen LLMs wie OpenAI, Anthropic, Groq und OpenRouter; zusätzliche Modelle können direkt hinzugefügt werden.
  • Sitzungsbasierte Arbeit: Mehrere Arbeitssitzungen und getrennte Kontexte pro Projekt verwalten.
  • Flexibler Modellwechsel: Freier Modellwechsel auch während einer laufenden Sitzung bei Erhalt des bisherigen Kontexts.
  • LSP-Integration: Verbindung zu LSP für wichtige Sprachen wie Go, TypeScript und Nix zur Stärkung des Code-Kontexts.
  • Erweiterbarkeit: Einfache Erweiterung über MCP auf Basis des Protokolls, z. B. für externe HTTP/CLI/SSE-Funktionen.
  • Umfassender Plattform-Support: Läuft auf den wichtigsten OS-Terminals wie macOS, Linux, Windows (WSL, PowerShell), FreeBSD, OpenBSD und NetBSD.
  • Intuitive Konfiguration: Sofort einsatzbereit ohne separate Einrichtung; bei Bedarf projektbezogene oder globale JSON-Konfiguration verfügbar.
  • Effektive Ignorierfunktion: Verwaltung ausschließender Dateien/Verzeichnisse über .gitignore und .crushignore möglich.
  • Tool-Whitelist: Vorabgenehmigung und Optionen für automatische Ausführung von Tools; mit dem Flag --yolo kann die gesamte Prompt-Eingabe übersprungen werden (mit Vorsicht zu verwenden).
  • Eigene Provider: OpenAI- und Anthropic-kompatible APIs können frei ergänzt und mit Detailoptionen konfiguriert werden.

Installation und Einstieg

  • Installation möglich über verschiedene Paketmanager sowie über Binärdateien oder Go: Homebrew, NPM, Arch, Nix, Debian/Ubuntu, Fedora/RHEL.
  • Beim ersten Start muss ein bevorzugter LLM-API-Schlüssel (OpenAI, Anthropic, Groq usw.) eingegeben werden; er kann auch per Umgebungsvariable gesetzt werden.
  • Repräsentative LLMs, die über Umgebungsvariablen angebunden werden können: OPENAI_API_KEY, ANTHROPIC_API_KEY, GROQ_API_KEY, OPENROUTER_API_KEY, GEMINI_API_KEY, VERTEXAI_PROJECT usw.

Konfigurationsbeispiele

  • Erweiterte Optionen über globale oder projektbezogene JSON-Dateien (./.crush.json, ./crush.json, $HOME/.config/crush/crush.json) anwenden
  • LSP-Konfiguration: Sprachspezifische Befehle können festgelegt werden 
    {  
  "lsp": {  
    "go": { "command": "gopls" },  
    "typescript": { "command": "typescript-language-server", "args": ["--stdio"] }  
  }  
}
  • MCP-Konfiguration: Beispiel für externe Erweiterungen über HTTP/CLI/SSE 
    {  
  "mcp": {  
    "filesystem": {  
      "type": "stdio",  
      "command": "node",  
      "args": ["/path/to/mcp-server.js"]  
    }  
  }  
}
  • Dateiausblendung und Tool-Freigabe
    • Ausschluss bestimmter Dateien/Ordner über .crushignore
    • Tool-Ausführung über Whitelist oder Überspringen der Prompt-Abfrage mit dem --yolo-Flag

Funktionen für Fortgeschrittene Nutzer

  • Registrierung benutzerdefinierter Provider: Hinzufügen von OpenAI/Anthropic-kompatiblen APIs, inklusive Preis- und Kontextdetails als Feinoptionen.
  • Logging: Projektbezogene Logdateien; Zugriff in Echtzeit über CLI-Befehle wie crush logs oder crush logs --follow.
  • Debug-Optionen: Aktivierung detaillierter Logs über das Flag --debug oder die Konfiguration.

Verwandte Beiträge

2 Kommentare

 
kaydash 2025-08-03

aider ist wirklich ziemlich schlecht;;
 
GN⁺ 2025-08-01
Hacker-News-Kommentare

  • Es fühlt sich merkwürdig an, dass die meisten terminalbasierten AI-Coding-Agenten versuchen, ihre Text-UI möglichst schick zu gestalten. Es gibt viel Leerraum, Line-Art, Widgets, ASCII-Art, Farbverläufe und sogar Animationen. Aber grundlegende Funktionen wie frei wählbare Keybindings, Tab-Autovervollständigung, konsistentes Scrollback oder flimmerfreies Text-Rendering fehlen. Immerhin ist dieses Tool nicht in node.js geschrieben, sodass man in Sachen Performance hoffen kann, etwa weil unnötige Redraws der Terminalausgabe reduziert werden. Wenn man es aber in Erwartung eines REPL oder einer CLI benutzt, stellt man fest, dass sich das Interaktionsmodell zwar ähnlich anfühlt, aber trotzdem völlig anders verhält, und auch deutlich anders als Unix-TUIs aus der Editor- oder Reader-Ecke. Ich frage mich, ob dieser Trend einfach nur Claude Code nachahmt oder schon früher begonnen hat. Deshalb bevorzuge ich weiterhin Aider. Es bietet ein Erscheinungsbild und eine Bedienung, die näher an einem REPL sind

    • Dieses Tool wurde von einer Firma namens Charm entwickelt, deren Mission es ist, Kommandozeilen attraktiv zu machen. Sie sind schon seit Jahren aktiv, also lange vor dem LLM-Hype. Das Unternehmen baut CLI-Frameworks und Tools für golang

    • Was ich am Terminal mag, ist dieser scroll-orientierte Workflow, bei dem man einen Befehl eingibt und dann die Aktionen und Ausgaben verschiedener Quellen und Programme der Reihenfolge nach wie in einem Log durchlaufen sieht. Was ich wirklich will, ist ein leistungsfähiger HTML-basierter Multi-Programm-Scroll-Workflow. Stattdessen kombinieren viele der heutigen Versuche die Nachteile beider Seiten. Gute UI würde ich lieber in einem besseren Rendering-System sehen

    • Dieser Trend zu Text-UIs war tatsächlich schon vor den AI-Agenten der typische Stil von charmbracelet. Mir gefällt daran, dass sich Keybindings dort im Gegensatz zu traditionellen TUIs intuitiv entdecken lassen

    • Ein Grund, warum diese Interfaces derzeit so schnell Fans und Entwickler anziehen, ist wohl, dass viele Menschen ursprünglich an grafische IDE-artige Editoren gewöhnt sind. Nicht alle Entwickler arbeiten ausschließlich im Terminal. (Ich habe allerdings immer noch Tage, an denen ich nicht einmal X/Wayland starte)

    • Man kann Claude Code zumindest aus emacs heraus nutzen https://github.com/stevemolitor/claude-code.el

  • Einer der guten Punkte an diesem Tool ist, dass es noch in einer frühen Phase ist und der Code deshalb sehr klar und modular wirkt. Wenn man selbst Agenten entwerfen möchte, ist es ein hervorragender Bauplan, etwa für Tool-Aufrufe, Sessions, automatische Zusammenfassungen und Persistenzverwaltung. Diesen Commit-Link sollte man sich unbedingt abspeichern

  • Für alle, die im Demo-GIF tatsächlich lesen möchten, was passiert, hat jemand es mit ffmpeg verlangsamt, als Video konvertiert und hochgeladen https://share.cleanshot.com/XBXQbSPP

  • Ich habe es etwa 15 Minuten lang ernsthaft benutzt. Im Vergleich zu Claude Code sind die Vorteile die schöne UI, eine nützliche Sidebar zur Nachverfolgung geänderter Dateien und der Kosten sowie eine angenehme UX zum Übernehmen von Änderungen (Hotkeys, gut lesbare Diffs). Die Nachteile sind dagegen, dass man nicht mehrere Modelle kombinieren kann und dass viele unnötige Binärdateien ins Verzeichnis gelegt werden. Beim initialen Init wird eine Datei namens CHARM.md erzeugt, die aber nicht zu den Informationen passt, die ich dem Modell mitteilen möchte. Zum Beispiel wird nicht vermittelt, dass meine Go-Testfälle PascalCasing verwenden. Außerdem crasht mein Terminal, wenn ich mit Ctrl+C beende

    • Zu dem Punkt, dass beim initialen Init CHARM.md angelegt wird: Ich wünschte wirklich, alle würden sich endlich auf einen bekannten einheitlichen Standard für Agent-Instruction-Dateien einigen, etwa AGENT.md. Das ist zwar ein Standard, den Amp für sein eigenes CLI-Tool bewirbt, aber trotz dieser Ironie bin ich dafür https://ampcode.com/AGENT.md. Oder man nutzt solche indirekten Hacks https://kau.sh/blog/agents-md/

  • Die wirklich wichtige Frage ist, welche der neuen Agenten lokale Modelle vernünftig unterstützen. Ich möchte die Abhängigkeit von externen APIs loswerden und wäre bereit, dafür gewisse Performance-Einbußen in Kauf zu nehmen

    • Für Crush gibt es ein laufendes Issue zur Unterstützung von Ollama (seit 2 Wochen)

    • Die meisten Agenten laufen mit OpenAI-kompatiblen Endpoints

    • OpenHands lässt sich mit jedem beliebigen LLM konfigurieren https://github.com/All-Hands-AI/OpenHands

    • Bei Aider steht ebenfalls, dass lokale Modelle unterstützt werden, ich habe es selbst aber noch nicht ausprobiert https://aider.chat/docs/llms.html

  • Es wäre wirklich großartig, eine Tabelle zu haben, die all diese neuen Tools wie Claude Code, opencode, aider und cortex miteinander vergleicht. Wie die einzelnen Tools arbeiten oder worin sie sich unterscheiden, ist nicht leicht auf einen Blick zu erkennen

    • Vergleiche oder Benchmarks mit kommerziellen Modellen sind wegen der Kosten extrem schwierig. Als ich kürzlich eine wissenschaftliche Arbeit geschrieben habe, habe ich über 10.000 Dollar ausgegeben, nur um mehrere kommerzielle SOTA-Modelle zu evaluieren. Vergleiche mit Open-Modellen waren günstig, aber die Reviewer wollten unbedingt einen Vergleich mit den „Besten“, also blieb nichts anderes übrig. Darüber hinaus sind die internen Strukturen oder Stacks kommerzieller Modelle weder transparent noch stabil und können sich jederzeit ändern, was das alles extrem ineffizient macht. Ich halte es nicht für sinnvoll, in der Forschung pauschal Vergleiche mit kommerziellen Modellen zu verlangen

    • Soweit ich mich erinnere, war opencode der ursprüngliche Name, wurde aber nach Konflikten unter den Entwicklern geändert

    • Die Performance hängt nicht nur vom Tool selbst ab, sondern auch vom verwendeten Modell, der Codebasis (Kontext) und der gestellten Aufgabe (Prompt). Diese Faktoren sind nicht unabhängig voneinander, und je nach Kombination gibt es große Leistungsunterschiede. Zum Beispiel waren Claude Sonnet 4 und Claude Code gut bei der Implementierung von Backend-Python-Funktionalität, während Gemini 2.5 Pro besser bei Änderungen an Frontend-React-Code war. Man kann also nicht einfach alle Variablen konstant halten und nur Tools vergleichen; man braucht Kombinationen aus ToolModellKontext*Prompt. 16x Eval behandelt Teile davon, aber Faktoren wie das Tool selbst sind dort noch nicht enthalten https://eval.16x.engineer/

  • „glamorous“ ist auch im britischen Englisch ein gebräuchlicher Ausdruck https://dictionary.cambridge.org/dictionary/english/glamorous

  • Ich benutze Crush seit einigen Wochen und bin wirklich sehr gespannt darauf. Ich verfolge Charm schon lange, und sie gehören zu den wenigen Teams, die die Developer Experience wirklich verstehen und konsequent Tools bauen, die Menschen gern benutzen. Dass sie so früh in das AI-Coding-Rennen eingestiegen sind, ist ebenfalls ein gutes Zeichen. Man merkt klar, dass dieses Tool von Leuten gebaut wurde, die es selbst wirklich benutzen

  • Schon wieder ein neues Tool, aber dieses Mal ist das Design wirklich gut. Ich werde es auf jeden Fall testen. Was mir bei allen Tools fehlt (EDIT: opencode kann GitHub-Authentifizierung), ist die Möglichkeit, mich mit meinem bestehenden Abo direkt bei Monatsdiensten wie GitHub Copilot, Claude Code, OpenAI Codex oder Cursor zu authentifizieren. Ich bezahle zwar für die Dienste, aber wenn mir das Interface nicht gefällt, wäre es großartig, es frei austauschen zu können

    • Die meisten Tools unterstützen nicht, dass ein anderes Programm ein Monatsabo einfach „mitbenutzt“. Deshalb braucht man einen separaten API-Key und zahlt tokenbasiert. Sogar Claude Code konnte sich eine Zeit lang nicht mit dem eigenen Abo verbinden

  • LSP-gestärkt: Crush nutzt, wie es generell üblich ist, LSP als zusätzlichen Kontext. Das ist für mich die spannendste Funktion. Auch die Multi-Session- und Projektfunktionen finde ich interessant

    • Es gibt LSP MCP, sodass man es auch zusammen mit anderen Agenten verwenden kann