AI Coding Agents im Vergleich: Claude Code, OpenCode und Pi Coding Agent

Der Markt für KI-gestützte Coding Tools explodiert. Gefühlt gibt es jede Woche ein neues Tool, das verspricht, die Art und Weise, wie wir Code schreiben, zu revolutionieren. In diesem Artikel vergleiche ich drei Tools, die ich selbst ausgiebig getestet habe: Claude Code, OpenCode und den Pi Coding Agent.

Kurz zu meinem Setup: Ich nutze alle Tools hauptsächlich über LiteLLM als Proxy, was mir eine einheitliche API für alle Provider gibt – von lokalen Ollama-Modellen bis zu Claude API.

---

Die Tools kurz vorgestellt

Claude Code

Claude Code ist Anthropics offizieller CLI-Agent. Er ist eng mit dem Claude-Ökosystem verzahnt und bietet direkten Zugriff auf alle Anthropic-Modelle. Das Tool ist in TypeScript/Node.js gebaut und npm-installierbar.

npm install -g @anthropic-ai/claude-code
claude

OpenCode

OpenCode ist ein relativ neues, auf Performance und saubere UX ausgerichtetes Terminal-Tool, entwickelt von den Machern des SST-Frameworks. Es setzt auf Flexibilität bei der Modellwahl und unterstützt OpenAI-kompatible APIs.

npm install -g opencode-ai
opencode

Pi Coding Agent

Pi ist ein Projekt aus Österreich – von Mario Zechner (bekannt für libGDX). Es positioniert sich als leichtgewichtiger, konfigurierbarer Agent mit Fokus auf Developer Experience und lokale Nutzung. Besonders interessant für DSGVO-bewusste Entwickler in Europa.

npm install -g @mariozechner/pi-coding-agent
pi

---

Bewertungsmatrix

Ich habe alle drei Tools nach folgenden Kriterien auf einer Skala von 1–10 bewertet:

Kriterium	Claude Code	OpenCode	Pi
Terminal UX / TUI	8	9	9
Modell-Flexibilität	5	8	9
Codebase-Verständnis	9	7	8
Multi-File Editing	10	8	8
Session Management	7	5	9
Konfigurierbarkeit	6	7	10
Kosten-Kontrolle	5	8	9
Open Source	0	10	10
Community & Docs	8	7	6
DSGVO / Datenschutz	5	8	10
Performance	8	9	9
Erweiterbarkeit	6	6	10

Hinweis: Die Bewertung ist subjektiv und spiegelt meinen Workflow als DevOps Engineer wider. Wer ausschließlich mit Anthropic-Modellen arbeitet und Claude Code-spezifische Features nutzt, wird Claude Code höher bewerten.

---

Pi und OpenCode mit LiteLLM konfigurieren

LiteLLM läuft als lokaler Proxy und exponiert einen OpenAI-kompatiblen Endpunkt – das ist der Schlüssel. Beide Tools können damit so konfiguriert werden, dass sie über diesen Proxy mit beliebigen Modellen kommunizieren: lokale Ollama-Modelle, Claude, GPT-4, oder was auch immer ihr in LiteLLM definiert habt.

LiteLLM vorbereiten

Zunächst brauchen wir eine funktionierende LiteLLM-Instanz. Der Proxy startet standardmäßig auf Port 4000:

# Starten mit minimaler Config
litellm --model ollama/llama3.1:8b

# Oder mit Konfigurationsdatei
litellm --config litellm-config.yaml

# litellm-config.yaml
model_list:
  # Lokale Modelle via Ollama
  - model_name: llama3.1
    litellm_params:
      model: ollama/llama3.1:8b
      api_base: http://localhost:11434

  - model_name: mistral
    litellm_params:
      model: ollama/mistral:7b
      api_base: http://localhost:11434

  # Cloud-Modelle (optional)
  - model_name: claude-sonnet
    litellm_params:
      model: claude-sonnet-4-20250514
      api_key: os.environ/ANTHROPIC_API_KEY

  - model_name: gpt-4o
    litellm_params:
      model: gpt-4o
      api_key: os.environ/OPENAI_API_KEY

general_settings:
  master_key: sk-my-litellm-key   # Beliebiger String als Auth-Key

LiteLLM ist jetzt unter http://localhost:4000 erreichbar und spricht perfektes OpenAI-API-Format. Verifizieren:

curl http://localhost:4000/v1/models \
  -H "Authorization: Bearer sk-my-litellm-key"

---

Pi mit LiteLLM konfigurieren

Pi nutzt ~/.pi/agent/models.json für Custom-Provider. Da LiteLLM OpenAI-kompatibel ist, konfigurieren wir es als openai-completions Provider:

mkdir -p ~/.pi/agent

// ~/.pi/agent/models.json
{
  "providers": {
    "litellm": {
      "baseUrl": "http://localhost:4000/v1",
      "api": "openai-completions",
      "apiKey": "sk-my-litellm-key",
      "models": [
        {
          "id": "llama3.1",
          "name": "Llama 3.1 8B (lokal via Ollama)",
          "reasoning": false,
          "input": ["text"],
          "contextWindow": 128000,
          "maxTokens": 32000,
          "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }
        },
        {
          "id": "mistral",
          "name": "Mistral 7B (lokal via Ollama)",
          "reasoning": false,
          "input": ["text"],
          "contextWindow": 32000,
          "maxTokens": 8000,
          "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 }
        },
        {
          "id": "claude-sonnet",
          "name": "Claude Sonnet (via LiteLLM)",
          "reasoning": false,
          "input": ["text", "image"],
          "contextWindow": 200000,
          "maxTokens": 16384,
          "cost": { "input": 3.0, "output": 15.0, "cacheRead": 0.3, "cacheWrite": 3.75 }
        }
      ]
    }
  }
}

Jetzt den Standard-Provider und das Default-Modell in den Settings setzen:

// ~/.pi/agent/settings.json
{
  "defaultProvider": "litellm",
  "defaultModel": "llama3.1",
  "theme": "dark",
  "compaction": {
    "enabled": true,
    "reserveTokens": 16384,
    "keepRecentTokens": 20000
  }
}

Pi starten und Modell wechseln geht dann einfach mit /model im TUI. Alle konfigurierten LiteLLM-Modelle sind sofort verfügbar.

Tipp: API-Key sicher aus Environment lesen

Statt den Key direkt in die JSON zu schreiben, kann Pi Environment-Variablen auflösen:

{
  "providers": {
    "litellm": {
      "baseUrl": "http://localhost:4000/v1",
      "api": "openai-completions",
      "apiKey": "LITELLM_MASTER_KEY"
    }
  }
}

# In .bashrc / .zshrc
export LITELLM_MASTER_KEY="sk-my-litellm-key"

Oder noch sicherer via Shell-Command (z.B. aus einem Password Manager):

{
  "apiKey": "!op read 'op://Private/LiteLLM/password'"
}

Tipp: Verschiedene Endpunkte pro Umgebung

Da Pi auch .pi/settings.json im Projektverzeichnis unterstützt, könnt ihr pro Projekt unterschiedliche Endpunkte setzen:

// .pi/settings.json (Projektverzeichnis)
{
  "defaultProvider": "litellm",
  "defaultModel": "claude-sonnet"
}

// ~/.pi/agent/models.json – Remote-Instanz für Production-Projekte
{
  "providers": {
    "litellm": {
      "baseUrl": "https://llm.mycompany.internal/v1",
      "api": "openai-completions",
      "apiKey": "LITELLM_PROD_KEY",
      "models": [...]
    }
  }
}

---

OpenCode mit LiteLLM konfigurieren

OpenCode verwendet ~/.config/opencode/opencode.json (global) oder opencode.json im Projektroot. Die Provider-Konfiguration nutzt das provider-Feld:

mkdir -p ~/.config/opencode

// ~/.config/opencode/opencode.json
{
  "$schema": "https://opencode.ai/config.json",

  // LiteLLM als Custom Provider registrieren
  "provider": {
    "litellm": {
      "name": "LiteLLM (local proxy)",
      "baseURL": "http://localhost:4000/v1",
      "apiKey": "sk-my-litellm-key",
      "models": {
        "llama3.1": {
          "name": "Llama 3.1 8B (lokal)",
          "contextLength": 128000,
          "cost": {
            "input": 0,
            "output": 0
          }
        },
        "mistral": {
          "name": "Mistral 7B (lokal)",
          "contextLength": 32000,
          "cost": {
            "input": 0,
            "output": 0
          }
        },
        "claude-sonnet": {
          "name": "Claude Sonnet (via LiteLLM)",
          "contextLength": 200000,
          "cost": {
            "input": 3.0,
            "output": 15.0
          }
        }
      }
    }
  },

  // Standardmodell setzen
  "model": "litellm/llama3.1"
}

OpenCode starten:

opencode

Das aktive Modell ist sofort der lokale Llama über LiteLLM. Mit /model im TUI könnt ihr zwischen allen konfigurierten Modellen wechseln.

Tipp: API-Key aus Environment

OpenCode liest API-Keys auch aus Environment-Variablen, wenn der Wert dem Muster einer Env-Var entspricht:

export LITELLM_API_KEY="sk-my-litellm-key"

{
  "provider": {
    "litellm": {
      "baseURL": "http://localhost:4000/v1",
      "apiKey": "LITELLM_API_KEY"
    }
  }
}

Tipp: Projekt-spezifische Konfiguration

Legt im Projektroot eine opencode.json an – die überschreibt die globale Config für dieses Projekt:

// opencode.json (im Projektverzeichnis)
{
  "$schema": "https://opencode.ai/config.json",

  // Für dieses Projekt immer Claude Sonnet nutzen
  "model": "litellm/claude-sonnet"
}

Tipp: Kompatibilitäts-Flags für LiteLLM

LiteLLM implementiert die OpenAI API sehr vollständig, aber falls Probleme auftreten (z.B. bei Streaming-Usage-Reports), gibt es Compat-Flags:

{
  "provider": {
    "litellm": {
      "baseURL": "http://localhost:4000/v1",
      "apiKey": "sk-my-litellm-key",
      "models": {
        "llama3.1": {
          "name": "Llama 3.1 8B",
          // Falls LiteLLM keine Usage-Daten im Stream liefert:
          "capabilities": {
            "streaming_usage": false
          }
        }
      }
    }
  }
}

---

Zusammenfassung: Pi vs. OpenCode Konfigurationsansatz

Aspekt	Pi	OpenCode
Config-Datei	~/.pi/agent/models.json + settings.json	~/.config/opencode/opencode.json
Format	JSON (getrennte Dateien)	JSONC (alles in einer Datei)
API-Key Auflösung	Env-Var, Shell-Command, Literal	Env-Var, Literal
Projekt-Override	.pi/settings.json	opencode.json im Root
Modell-Syntax	llama3.1 (Provider implizit durch Settings)	litellm/llama3.1
Konfig-Reload	Live beim /model-Öffnen	Neustart nötig

Fazit: Pi’s Ansatz mit getrennten Dateien für Provider-Definitionen und Settings ist etwas sauberer, erfordert aber zwei Dateien. OpenCode hat alles in einer Datei – einfacher für schnelle Setups, aber bei vielen Modellen wird die Config lang.

Fazit

Es gibt keinen klaren “Gewinner” – jedes Tool hat seinen Sweet Spot:

• Claude Code ist der einfachste Einstieg ins Anthropic-Ökosystem.
• OpenCode überzeugt durch UX und Performance.
• Pi ist der flexibelste und datenschutzfreundlichste Agent.

Meine persönliche Gesamtwertung: Pi auf Platz 1, gefolgt von OpenCode und Claude Code.

Habt ihr andere Erfahrungen gemacht? Welches Tool nutzt ihr täglich? Schreibt es mir gerne.

---

Resources

• Claude Code GitHub
• OpenCode GitHub
• Pi Mono GitHub
• LiteLLM für alle Tools nutzen