Claude Code, OpenCode, Codex und Copilot CLI mit lokalem Modell: Setup, Modelle und GPUs

Welche Coding-Agenten im Terminal mit einem lokalen Modell laufen

Claude Code, OpenCode, Codex CLI und GitHub Copilot CLI können alle mit einem Modell auf Ihrer eigenen GPU statt mit einer Cloud-API arbeiten. Claude Code verbindet sich mit einem Endpunkt im Anthropic-Format, den Ollama und vLLM anbieten, die drei anderen meist mit einem OpenAI-kompatiblen, und jeder braucht ein Modell mit Tool Calling und mindestens 64.000 Token Kontext. Für einen Entwickler ist eine Workstation mit einer RTX PRO 4500 oder RTX PRO 5000 der Einstieg; eine oder zwei NVIDIA RTX PRO 6000 Blackwell Workstation Edition oder Max-Q tragen ein kleines Team, und für eine Abteilung übernimmt ein Server mit RTX PRO 6000 Server Edition.

Dieser Leitfaden behandelt die Terminal-Agenten und den Schritt von einer Workstation zum gemeinsamen Server. IDE-Erweiterungen, Completion-Modelle und Lizenzen der Coding-Modelle stehen in unserem Leitfaden zum privaten Coding-Assistenten, die Dimensionierung von Servern für 20 bis 100 Entwickler in unserem Leitfaden zum Server für Coding-Agenten. IDE-Tools als Ersatz für GitHub Copilot vergleicht unser Artikel zu selbst gehosteten Copilot-Alternativen, den Editor Cursor behandelt der Leitfaden Cursor mit lokalem Modell.

Lizenzfelder aus der npm-Registry und den Repositorys der Projekte; Anbindung aus der Dokumentation von Anthropic (Claude Code), Ollama, OpenCode, OpenAI (Codex) und GitHub; alles gelesen am 30. Oktober 2026. Alle vier Clients erscheinen in kurzen Abständen neu, daher nennen wir Versionsnummern nur, wo eine Funktion eine Mindestversion braucht.

Claude Code und Copilot CLI sind proprietäre Clients. Anthropics Seite zu Recht und Compliance sagt, dass die Nutzung von Claude Code für Team-, Enterprise- und API-Kunden den Commercial Terms of Service unterliegt und für Free, Pro und Max den Consumer Terms. Die Gateway-Dokumentation hält fest, dass Anthropic das Weiterleiten von Claude Code an Nicht-Claude-Modelle über ein Gateway nicht unterstützt. Die Einrichtung unten funktioniert technisch, wie Ollama sie dokumentiert, läuft aber außerhalb von Anthropics Support. Das README von Copilot CLI nennt ein aktives Copilot-Abonnement als Voraussetzung; GitHubs Changelog vom 7. April 2026 ergänzt, dass mit einem eigenen Modell-Provider keine GitHub-Anmeldung nötig ist. Ihre Rechtsberatung prüft die Bedingungen vor dem Rollout. Unsere Einrichtung umfasst den Modellserver und das Modell; Claude Code oder Copilot CLI installieren Ihre Entwickler selbst, nach den Bedingungen von Anthropic oder GitHub.

Claude Code und die anderen Agenten mit Ollama einrichten

Für einen Entwickler ist Ollama der kürzeste Weg. Seit Version 0.15 startet ollama launch Claude Code, OpenCode, Codex oder Droid mit einem Befehl gegen ein lokales Modell, und Ollamas Blogbeitrag vom 23. Januar 2026 verlangt eine Kontextlänge von mindestens 64.000 Token. Setzen Sie Ollama 0.35.0 oder neuer ein: Ältere Versionen sind von CVE-2026-103663 betroffen, einer Path-Traversal-Lücke in /api/pull, wie unser Leitfaden von Ollama auf dem PC zum KI-Server im Unternehmen erklärt. Ollama wird Stand Oktober 2026 aktiv weiterentwickelt, halten Sie es also aktuell.

1. Claude Code. Ollamas Anleitung setzt ANTHROPIC_BASE_URL auf http://localhost:11434, ANTHROPIC_AUTH_TOKEN auf ollama (laut Ollama „required but ignored“) und ANTHROPIC_API_KEY auf eine leere Zeichenkette und startet dann claude --model mit einem lokalen Modell.
2. OpenCode. Ein Ollama-Provider in opencode.json mit dem Paket @ai-sdk/openai-compatible und baseURL auf http://localhost:11434/v1. OpenCodes eigene Dokumentation zeigt dasselbe Muster für LM Studio und llama-server.
3. Codex CLI. codex --oss arbeitet mit Ollama oder LM Studio, zum Beispiel codex --oss -m gpt-oss:120b; das Codex-Profil in Ollamas Anleitung setzt wire_api auf die Responses API.
4. GitHub Copilot CLI. COPILOT_PROVIDER_BASE_URL zeigt auf den Endpunkt, COPILOT_MODEL nennt das Modell, und COPILOT_OFFLINE=true verhindert, dass die CLI GitHubs Server kontaktiert. GitHubs Dokumentation nennt Ollama und vLLM als Provider und meldet einen Fehler, wenn dem Modell Tool Calling oder Streaming fehlt.

Claude Code braucht drei weitere Einstellungen, die in den Kurzanleitungen fehlen. Einen lokalen Modellnamen erkennt es nicht, nimmt deshalb ein Kontextfenster von 200K Token an und komprimiert das Gespräch erst dort; Anthropics Seite zur Modellkonfiguration sagt, in diesem Fall CLAUDE_CODE_MAX_CONTEXT_TOKENS auf das echte Fenster zu setzen, also auf den Kontext, mit dem der Server gestartet wurde. Hintergrundaufgaben nutzen das Modell hinter dem Alias haiku, Subagenten CLAUDE_CODE_SUBAGENT_MODEL; richten Sie deshalb ANTHROPIC_DEFAULT_HAIKU_MODEL und diese Variable ebenfalls auf das lokale Modell, sonst verlangen diese Anfragen Claude-Modelle, die Ihr Server nicht bereitstellt.

Ollamas Anthropic-Schicht listet auf, was sie nicht unterstützt: Prompt Caching, den Endpunkt zum Token-Zählen, tool_choice und PDF-Blöcke. Claude Code zählt den Kontext dann über den Messages-Endpunkt, wie Anthropics Gateway-Referenz beschreibt, und die Cache-Marker, die es im Systemprompt setzt, bleiben wirkungslos. Lassen Sie Ollama auf 127.0.0.1, seiner Voreinstellung; sein Container-Image lauscht dagegen auf allen Schnittstellen.

Sie können die Workstation allein bestellen, die Einrichtung von Ollama oder vLLM und dem Coding-Modell allein oder beides zusammen: die Workstation mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Was den Rechner trotzdem verlässt

Mit einem lokalen Modell bleiben Prompts und Code in Ihrem Netz, die Clients haben aber eigenen Datenverkehr. Unser Artikel zur Telemetrie in selbst gehosteten KI-Tools behandelt die Serverseite; für die vier Clients dokumentieren die Hersteller Folgendes, gelesen am 30. Oktober 2026.

• Claude Code hält seine Nutzungsmetriken standardmäßig eingeschaltet, außer bei den Cloud-Providern, die Anthropic aufzählt; laut Anthropic enthalten sie nie Code, Prompts oder Dateipfade. CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC auf 1 schaltet automatische Updates, Telemetrie, Fehlerberichte, den Befehl /feedback und Release Notes ab. Das WebFetch-Werkzeug schickt trotzdem den Hostnamen jeder angefragten URL, ohne Pfad und Inhalt, zur Sicherheitsprüfung an api.anthropic.com, bis in den Einstellungen skipWebFetchPreflight auf true steht.
• Copilot CLI schaltet im Offline-Modus laut GitHubs Changelog die Telemetrie ab und spricht nur mit dem eingestellten Provider; GitHubs Dokumentation ergänzt, dass volle Netzisolation nur gilt, wenn auch der Provider lokal ist.
• Codex CLI sendet laut OpenAI standardmäßig „a small amount of anonymous usage and health data“; [analytics] enabled = false schaltet das ab, [feedback] hat einen eigenen Schalter. Unter ollama launch führt Ollama die Websuchen von Codex aus, die ollama signin voraussetzen; Ollamas Anleitung zeigt, wie man sie je Sitzung abschaltet.
• OpenCode lädt ein Gespräch nur dann zu opencode.ai hoch, wenn jemand /share aufruft, denn das automatische Teilen ist standardmäßig aus; "share": "disabled" in opencode.json schaltet das Teilen ganz ab.
• Ollama bietet neben lokalen auch Cloud-Modelle an; OLLAMA_NO_CLOUD=1 entfernt sie, wie unser Telemetrie-Artikel beschreibt.

Eine Firewall, die von den Entwicklerrechnern aus nur den Modellserver und den Paketspiegel erlaubt, fängt ab, was eine Einstellung übersieht.

Welches offene Modell als Backend trägt

Ein Terminal-Agent schickt bei jedem Schritt seine ganze Aufgabe: Anweisungen, Werkzeugdefinitionen, die gelesenen Dateien und die Ausgabe jedes Befehls. Das Modell muss Werkzeuge im erwarteten Format aufrufen, langen Anweisungen folgen und über 50 oder 100 Schritte konsistent bleiben. Die Werte unten stammen von den Herstellern; SWE-bench Verified misst, wie viele echte Issues aus Repositorys ein Agent löst.

Modellkarten, Konfigurationsdateien und Dateilisten auf Hugging Face, gelesen am 30. Oktober 2026 (Qwen3.6, Qwen3.8, Qwen3-Coder-Next, GLM-4.7-Flash) und in unseren Schwesterartikeln (gpt-oss, Größen von GLM, FP8-Größe von Qwen3.8). Werte nach Angabe der Hersteller; der Wert für gpt-oss-20b stammt aus der Vergleichstabelle der GLM-4.7-Flash-Karte. Die Karte von Qwen3.8-27B nennt SWE-bench Pro, nicht Verified. Cache je Sitzung in 16 Bit nach unserer Rechnung aus der jeweiligen config.json, einschließlich des festen Zustands der Linear-Attention-Schichten; ein FP8-Cache halbiert den Anteil je Token. gpt-oss-20b und GLM-4.7-Flash sind bei 64K angegeben.

Alle sieben stehen unter Apache 2.0, außer GLM-4.7-Flash unter MIT. Qwen3.8-27B, von Qwen im August 2026 veröffentlicht, ist das neueste davon und das Modell, mit dem unser Leitfaden zur Vibe-Coding-Workstation rechnet. Seine Karte ist hier die aufschlussreichste: Qwen hat SWE-bench Pro für die eigenen Modelle im Claude-Code-Harness mit 256K Kontext gemessen und nennt 61,7 für Qwen3.8-27B gegenüber 53,5 für Qwen3.6-27B; die 53,4 für Claude Opus 4.6 Max sind der offiziell gemeldete Wert, der Vergleich ist also nicht gleichwertig. In der Praxis zählen drei Unterschiede.

Geschwindigkeit. Ein Mixture-of-Experts-Modell liest je Token nur seine aktiven Parameter. Qwen3.6-35B-A3B rechnet je Token rund 3B seiner 35B Parameter, während das dichte Qwen3.6-27B für jedes Token alle Gewichte liest; nach unserer Rechnung antwortet das MoE-Modell deshalb um ein Mehrfaches schneller. Das dichte Modell erzielt den höheren Wert, und den Unterschied im Tempo spürt ein Agent bei jedem Schritt. Für die dichten Modelle in 8 Bit ist auf RTX-PRO-Karten keine Messung einer einzelnen Anfrage veröffentlicht. Qwen3.8-27B hat dieselben Schichten und Attention-Heads wie Qwen3.6-27B und gleich große 8-Bit-Gewichte, und die Geschwindigkeit einer Anfrage hängt vor allem von den je Token gelesenen Bytes ab, etwa 28 GB: Nach unserer Schätzung erreicht eine Anfrage damit auf einer Workstation Edition oder Max-Q höchstens etwa 63 Token pro Sekunde, auf der Server Edition 56 und auf einer RTX PRO 5000 47. Reale Werte liegen darunter: StorageReviews Test von Qwen3.8-27B in NVFP4, beschrieben in unserem Leitfaden zur Vibe-Coding-Workstation, maß für eine Anfrage auf den getesteten Karten 17 bis 22 Token pro Sekunde.

Cache je Sitzung. Die Modelle Qwen3.6 und Qwen3.8 sowie Qwen3-Coder-Next halten nur in jeder vierten Schicht einen Cache je Token. Eine 128K-Sitzung kostet bei Qwen3.6-35B-A3B oder Qwen3-Coder-Next 2,6 bis 3,1 GiB, bei den dichten 27B-Modellen mit mehr Attention-Heads etwa 8,1 GiB und beim älteren Qwen3-Coder-30B-A3B 12 GiB. Dank des kleinen Caches hält eine Karte viele lange Sitzungen.

Thinking. Laut den Karten von Qwen3.6 und Qwen3.8 denken die Modelle standardmäßig, was jedem Schritt Ausgabetoken hinzufügt; Qwen3-Coder-Next unterstützt nur den Modus ohne Thinking. Qwens FP8-Karte zu Qwen3.6-35B-A3B empfiehlt mindestens 128K Kontext, um das Thinking zu erhalten, ein Grund, warum wir mit 128K rechnen.

Die großen offenen Coding-Modelle wie Kimi K2.7-Code brauchen einen Server mit acht Karten; unsere Seite zu Kimi K2.7-Code auf 8× RTX PRO 6000 Server Edition beschreibt diese Konfiguration.

Welche GPU für einen Entwickler, ein Team oder eine Abteilung

Unsere Regel für Nutzer je Karte nimmt 90 Prozent des Speichers, den der Treiber meldet, abzüglich 3 GiB je Karte und abzüglich der Gewichte, wie in unserem Leitfaden wie viele Nutzer eine RTX PRO 6000 bedient: 25,7 GiB auf einer RTX PRO 4500, 61,5 GiB auf einer RTX PRO 5000 72 GB und 83,0 GiB auf einer RTX PRO 6000 jeder Edition. Die zweite Grenze ist die Geschwindigkeit. Jeder Decodierschritt liest die aktiven Gewichte und den Cache jeder Sitzung, daher zählen wir auch die Sitzungen, bei denen eine Obergrenze von 50 Token pro Sekunde erhalten bleibt, nach der Methode unseres Leitfadens zum Server für Coding-Agenten. Bei Mixture-of-Experts-Modellen ist dieser Wert nach unserer Schätzung eine Obergrenze, weil gebündelte Token unterschiedliche Experten erreichen. Wir zählen eine erzeugende Sitzung je Entwickler in der Spitzenstunde.

Sitzungen zu 128K Token nach unserer Regel für Nutzer je Karte, 16-Bit-Cache (FP8-Cache in Klammern); geplant ist der kleinere Wert aus Speicher und unserer Grenze von 50 Token pro Sekunde, nach unserer Schätzung eine Obergrenze. Bandbreite laut NVIDIA: 896 GB/s (RTX PRO 4500), 1.344 GB/s (RTX PRO 5000), 1.792 GB/s (Workstation Edition und Max-Q), 1.597 GB/s (Server Edition); aktive Gewichte etwa 3 GB je Token. Serverzeilen aus unserem Leitfaden zum Server für Coding-Agenten.

Einstieg: ein Entwickler. Eine Workstation mit einer RTX PRO 4500 Blackwell (32 GB) hält NVIDIAs NVFP4-Version von Qwen3.6-35B-A3B mit einer 128K-Sitzung, mit FP8-Cache zwei. Ollama nennt für GLM-4.7-Flash bei 64.000 Token etwa 23 GB VRAM, was ebenfalls auf diese Karte passt. Eine RTX PRO 4000 mit 24 GB lässt nach unserer Regel 18,5 GiB, genug für gpt-oss-20b mit drei 64K-Sitzungen; in der Vergleichstabelle von GLM löst dieses Modell etwa ein Drittel der Issues von SWE-bench Verified und eignet sich daher für kleine Änderungen. Details stehen in unserem Artikel zu 30B-MoE-Modellen auf Karten mit 24 GB. Die RTX PRO 5000 72 GB hält dasselbe Qwen-Modell in FP8 mit zehn 128K-Sitzungen und passt zu einem kleinen Studio. Sie hält auch ein dichtes 27B-Modell, Qwen3.8-27B oder Qwen3.6-27B, in FP8 mit 4 (7) solchen Sitzungen, doch bei 1.344 GB/s liegt ihre Obergrenze für eine Anfrage mit kurzem Kontext nach unserer Schätzung bei etwa 47 Token pro Sekunde, Bandbreite geteilt durch etwa 28 GB Gewichte, die je Token gelesen werden.

Mittelklasse: ein Team an einer Workstation. Eine RTX PRO 6000 Workstation Edition oder Max-Q (96 GB) trägt Qwen3.6-35B-A3B in FP8 für bis zu etwa elf Entwickler bei der geplanten Geschwindigkeit. Wer das dichte Modell bevorzugt, das in Qwens Tabellen höher abschneidet, bekommt auf derselben Karte Qwen3.8-27B in FP8 mit 6 (13) Sitzungen zu 128K, mit einer Obergrenze von etwa 63 Token pro Sekunde für eine Anfrage nach unserer Schätzung (1.792 GB/s geteilt durch 28,4 GB). Qwen3-Coder-Next passt mit zwei Sitzungen (fünf mit FP8-Cache), eher ein Einzelplatz mit dem größeren Modell. Zwei Karten betreiben Qwen3-Coder-Next als TP=2-Paar, wie die Modellkarte mit --tensor-parallel-size 2 zeigt, mit etwa 20 geplanten Sitzungen zu 128K. Zwei Workstation-Edition-Karten ziehen bis zu je 600 W, zwei Max-Q je 300 W; NVIDIA erlaubt bis zu vier Max-Q in einer Workstation, doch drei oder vier gehören nur in ein Gehäuse, das dafür mit starkem, gerichtetem Luftstrom gebaut ist, wie unser Leitfaden zur Workstation mit 2× RTX PRO 6000 Max-Q erklärt.

Groß: eine Abteilung. Ab etwa 20 Entwicklern übernimmt ein Rack-Server mit RTX PRO 6000 Server Edition: zwei Paare auf vier Karten ergeben 36 geplante Sitzungen zu 128K, vier Paare auf acht Karten 72. Der Leitfaden zum Server für Coding-Agenten enthält den Strombedarf, die Variante mit H200 NVL für Qwen3-Coder-480B und die Messgrößen für einen Piloten.

Wir bauen RTX-PRO-Workstations und KI-Server für jede dieser Stufen; senden Sie uns die Zahl der Entwickler, die genutzten Agenten und den nötigen Kontext, und unser Team antwortet mit einer Konfiguration.

Von einem Entwickler zum Teamserver

Auf einem gemeinsamen Server ersetzt vLLM Ollama. Seine stabile Dokumentation mit Stand 8. Oktober 2026 nennt eine Anthropic Messages API (/v1/messages und /v1/messages/count_tokens) neben der Chat Completions API und der Responses API, sodass eine Engine alle vier Clients bedient. Starten Sie es mit dem Tool-Parser aus der Modellkarte, etwa --enable-auto-tool-choice mit --tool-call-parser qwen3_coder für die Qwen-Modelle und glm47 für GLM-4.7-Flash, wie unser Leitfaden zu den Tool-Calling-Parsern in vLLM erklärt, und setzen Sie --max-model-len auf den Kontext, den Sie dimensioniert haben.

Prefix Caching. Ein Agent schickt bei jedem Schritt denselben langen Anfang, und vLLM verwendet diesen Teil des Caches wieder, solange er im Speicher liegt. Claude Code stellt dem Systemprompt einen kurzen Attributionsblock mit seiner Version und einem Fingerabdruck des Gesprächs voran; laut Anthropics Gateway-Referenz bleibt er seit Version 2.1.181 innerhalb eines Gesprächs stabil, und CLAUDE_CODE_ATTRIBUTION_HEADER=0 lässt ihn weg. Nach unserer Lesart lässt sich der gemeinsame Systemprompt nur ohne diesen Block über Gespräche hinweg wiederverwenden; testen Sie beide Einstellungen im Piloten.

Schlüssel und Protokoll. vLLMs --api-key schützt nur die Pfade unter /v1, /v2, /inference und /cohere und verwaltet keine Benutzer. Ein LLM-Gateway mit Schlüsseln, Budgets und Abfrageprotokoll vergibt einen Schlüssel je Entwickler; der Proxy von LiteLLM nimmt Anfragen im Anthropic-Format /v1/messages an und leitet sie an die unterstützten Provider weiter. Die verwalteten Einstellungen von Claude Code können das Gateway festschreiben: Mit allowedProviders auf ["customEndpoint"] und der ANTHROPIC_BASE_URL des Gateways in derselben Datei verweigert Claude Code ab Version 2.1.285 Sitzungen, die woanders hinzeigen.

Kontextgrenzen. Claude Code erkennt keine niedrigere Grenze, die der Server durchsetzt, wie Anthropics Dokumentation festhält. Verteilen Sie CLAUDE_CODE_MAX_CONTEXT_TOKENS mit den verwalteten Einstellungen, damit jeder Client komprimiert, bevor der Server eine Anfrage ablehnt.

Wir richten vLLM und das Gateway auf dem Server im Rahmen unseres Private-AI/ML-Service ein; beschreiben Sie uns, wie Ihre Entwickler heute mit Agenten arbeiten, und wir schlagen Server und Modell-Einrichtung vor.

FAQ