Blog

Wir haben einen Fallschirm für Claude Code gebaut. Daraus wurde ein Gurtzeug.

Ricardo Granados

Ricardo Granados

Aktualisiert August 10, 2026
14 Minuten

Vor sechs Monaten erzählte mir ein Kollege von Claude Code als Lösung für ein Projekt, bei dem ich nicht weiterkam, und so beschloss ich, es auszuprobieren. Auch heute noch bin ich ein wenig überrascht: „Wir“ – Claude Code und ich – sind ein Team geworden. Wir führen Planungs- und Besprechungsrunden, Sprints und Retrospektiven durch – dieselben Rituale und denselben Rhythmus, die ich aus jedem menschlichen Team kenne, dem ich bisher angehört habe. Ich habe bereits zuvor über dieses Arbeitsmodell und den Kontext geschrieben, von dem es abhängt. Dies ist die Geschichte des Gerüsts, das dahintersteckt – des Teils, den ich nie bewusst aufbauen wollte.

Der Teamkollege, der immer wieder verschwand

Eines Nachts stellte ich drei Aufgaben für meine Agenten in die Warteschlange und ging schlafen. Gegen 3 Uhr morgens stießen alle drei gleichzeitig an die Ratenbegrenzung. Bis zum Reset waren es noch fünf Stunden, und zwei Stunden ihrer Analyse waren verloren – gefangen in Protokollen, die ich nicht wiederherstellen konnte. Das ist der Aspekt, den viele unterschätzen: Wenn ein Limit bei einem Koordinator greift, der drei Agenten ausführt, verliert man nicht nur einen Teil der Daten. Man verliert alles – der Kontext geht verloren, bevor er gespeichert werden kann, und man muss erneut Token bezahlen, um ihn wiederherzustellen.

Wir wollten einen Partner, der nicht einfach aufhört. Doch ein fester Monatsvertrag, der aufgrund vorhersehbarer Kosten gewählt wurde, hat einen entscheidenden Nachteil: Sobald das Limit erreicht ist, ist Schluss – meist mitten im Experiment und meist spät an einem Freitag.

Also haben wir einen Fallschirm gebaut.

Der Fallschirm: ein transparenter Stellvertreter

Wir nannten es „Anthropic Failover Proxy“ (AFP). Ursprünglich diente es dazu, die Token-Kosten zu senken: Ein Teil der Arbeit wurde an ein kostenloses lokales Modell weitergeleitet, während der Rest über die offizielle API abgewickelt wurde. Es handelt sich um einen transparenten Reverse-Proxy, der zwischen Claude Code und der Anthropic-API geschaltet ist. Sie müssen lediglich eine Umgebungsvariable darauf verweisen:

ANTHROPIC_BASE_URL=http://localhost:8100

Der Haken zeigte sich sofort. Eine Claude-Code-Sitzung lässt sich nicht mitten im Gespräch unterbrechen, und sobald das REPL mit einem Backend gestartet ist, bleibt dieses Backend für die gesamte Sitzung bestehen – ein Wechsel während der Sitzung ist nicht möglich. Daher musste die Entscheidung jedes Mal im Voraus getroffen werden.

Ollama hatte gerade eine native Möglichkeit bereitgestellt, Claude Code direkt auf lokale Modelle auszurichten, und ich habe diese zunächst direkt ausprobiert. Ich konnte jedoch keine zuverlässige Funktion erzielen. Die nächste Option war eine Plattform, die es ermöglicht, verschiedene LLM-Modelle über eine einzige API zu nutzen – eine, die ich ein Jahr zuvor erworben, aber kaum genutzt hatte und die tatsächlich die echten Anthropic-Modelle hostet; theoretisch hätte also auch der volle Funktionsumfang vorhanden sein müssen. Das war jedoch nicht der Fall: Die API hat ein eigenes, proprietäres Format und folgt weder dem OpenAI-Standard noch dem von Anthropic, sodass selbst das richtige Modell im Hintergrund nicht reibungslos über das REPL laufen konnte. Als ich Claude Code fragte, ob wir dies zum Laufen bringen könnten, formulierte die Antwort das Problem neu: Es ging nicht darum, welches Modell antwortete, sondern darum, wie das Backend dieses Modells mit dem Harness und dem REPL kommunizierte – also um das zugrunde liegende Tool-Call-Protokoll. Ein einfacher Wrapper würde dies nicht abdecken.

Ich habe AFP zunächst auch nicht mit etwas wie LiteLLM oder OpenRouter verglichen. Etwa zur gleichen Zeit wurde das PyPI-Paket von LiteLLM durch eine manipulierte CI-Abhängigkeit kompromittiert, die das Veröffentlichungstoken eines Betreuers abgriff und bei der Installation Anmeldedaten sammelte. Das stellte die Sache in den richtigen Kontext: Auch hier handelte es sich um ein Sicherheitsrisiko. AFP musste in beide Richtungen übersetzen: Antworten in eine Form, die das REPL versteht, und die Erwartungen des REPL zurück in etwas, das das Modell, das die Sitzung tatsächlich steuert, verwenden konnte.

Wenn Anthropic einwandfrei funktioniert, bleibt AFP unsichtbar. Es leitet die Anfrage weiter, überträgt die Antwort zurück und hält sich ansonsten im Hintergrund. Bei einer Ratenbegrenzung oder einer Überlastung zeigt es den Fehler nicht an; stattdessen leitet es die Anfrage über eine Reihe von Ausweichmöglichkeiten weiter und wandelt die Antwort wieder in das von Claude Code erwartete Format um, sodass das Tool nie bemerkt, dass es den ursprünglichen Server verlassen hat.

Die erste Stufe unterhalb von Anthropic war eben diese Plattform, die auf einem Guthaben an kostenlosen Credits basierte, das ich bisher noch nicht genutzt hatte. Als mein Abonnement also seine Obergrenze erreichte, konnte AFP die Anfragen dorthin umleiten, sodass weiterhin dieselben Modelle die Anfragen beantworteten – dabei wurden diese ungenutzten Credits aufgebraucht, anstatt den von Anthropic festgelegten Überziehungssatz zu zahlen.

Fallback-Ladder-Diagramm. Claude Code ruft AFP über Port 8100 auf. AFP bevorzugt die Anthropic-API; bei einer Ratenbegrenzung oder einem Ausfall greift das System zunächst auf ein gehostetes Fallback-Modell und anschließend auf ein lokales Modell auf unserer eigenen Hardware zurück, bevor ein echter 503-Fehler ausgegeben wird. Die Fallback-Stufen: Zunächst „Anthropic“, dann ein gehostetes Fallback-Modell, anschließend ein lokales Modell auf unserer eigenen Hardware und schließlich ein eindeutiger 503-Fehler, falls alles ausgefallen ist.

Ein Fallback unsichtbar zu machen, ist schwieriger, als es aussieht. Jedes Backend spricht seinen eigenen Dialekt, und Claude Code stützt sich stark auf Tool-Aufrufe – genau dort scheitern naive Fallbacks. Eine Laufzeitumgebung gab Tool-Argumente als rohen String zurück, während der Validator ein geparstes Objekt erwartete, woraufhin der Aufruf stillschweigend fehlschlug. Sobald ein Fallback nahtlos kompatibel sein muss, reicht „es funktioniert meistens“ nicht aus.

Wir verfügen über Ausfallsicherheit. Doch auch die damit verbundenen kostenlosen Gutschriften waren schnell aufgebraucht, und ein gehosteter Fallback ist immer noch die Cloud eines anderen Anbieters.

Sich auf das Lokale besinnen und Souveränität finden

Also haben wir eine weitere Stufe hinzugefügt: ein Modell, das lokal auf demselben MacBook läuft, an dem ich arbeite. Damit war das Problem mit den Credits behoben. Was ich nicht erwartet hatte, war das zweite Problem, das dadurch gelöst wurde.

Ein Muster zieht sich durch diese ganze Geschichte. Nach sechs Monaten befanden sich die meisten meiner Projektideen noch in der Entwicklung, doch ich hatte bereits einen stetigen Strom anderer Dinge fertiggestellt: Hooks, Gates, Router, Fallbacks. Jedes davon war eine Neben Aufgabe, die die Infrastruktur schuf, die für die eigentliche Arbeit erforderlich war. Der Umstieg auf lokale Systeme war eine davon. Ebenso wie die Befürchtung, die darauf folgte.

Beim Testen einer App gab Claude versehentlich ein Token im Chat preis, und nun befand es sich im Kontext, im Verlauf und war auf dem Weg zu Anthropic. Da ging uns ein Licht auf: Wir müssen einschränken, was wir den Agenten preisgeben, ohne sie dabei in ihrer Arbeit zu behindern. Aus dieser Nebenaufgabe entstanden unsere „Hooks“ und „Hard Gates“, ein verschlüsselter Geheimnis-Tresor (der inzwischen durch das Open-Source-Tool „Infisical“ ersetzt wurde) sowie Regeln, um Geheimnisse von vornherein aus der Konversation fernzuhalten.

Dann führten mich fast zeitgleich drei Dinge zum Thema Datenhoheit. Der Vortrag eines Kollegen über souveräne Datenplattformen brachte mich dazu, darüber nachzudenken, wer tatsächlich kontrolliert, wo Daten gespeichert und verarbeitet werden. Ein Gespräch mit dem Brev-Team von NVIDIA brachte einen entscheidenden Punkt auf den Punkt: Für die meisten Unternehmen liegt die Grenze beim Eigenbetrieb von KI nicht im Modell oder im Budget, sondern in der Energieversorgung – nämlich darin, ob Ihr Gebäude die GPUs mit Strom versorgen kann. Und die niederländische Regierung hatte gerade den Verkauf von Solvinity, dem Betreiber von DigiD, aus genau diesem Grund blockiert: Daten auf Infrastruktur in US-Besitz sind gemäß dem US-amerikanischen CLOUD Act zugänglich.

Die auffällige Ausprägung von Souveränität sind Rechenzentren und nationale Kapazitäten. Die praktische Ausprägung liegt auf meinem Schreibtisch: Kann mein Arbeitsablauf sensible Daten auf Hardware speichern, die ich kontrolliere, und im Bedarfsfall reibungslos auf ein niedrigeres Leistungsniveau zurückgestuft werden?

Ein privater Laptop auf einem Schreibtisch zu Hause, umhüllt von einer Kuppel aus sanftem Licht, die warme Datenpartikel im Inneren zurückhält, während ein einzelner dünner Datenstrom in Richtung eines entfernten, kalten Cloud-Rechenzentrums am Horizont entweicht. Souveränität in der Praxis: Bewahren Sie sensible Daten im eigenen Haus auf und lassen Sie nur das nach außen, was zulässig ist.

Dadurch wurde die Prioritätenreihenfolge neu geordnet – zunächst lokale Lösungen, die Cloud als Backup – und eine Regel hinzugefügt: Sensible Daten werden vor dem Versand bereinigt oder gar nicht erst in den Chat aufgenommen. Der letzte Punkt ist der schwierigste. Protokolle und interne Dokumente sind voller personenbezogener Daten, und ein Name lässt sich nicht einfach ausblenden. Ich kann nicht behaupten, dass das System perfekt ist oder dass niemals etwas an Dritte gelangt. Aber es ist weitaus besser als zu Beginn, und wir arbeiten weiter daran, es zu verbessern.

Wenn etwas wirklich nicht den Kunden oder Xebia verlassen darf, lasse ich es überhaupt nicht in den Chat gelangen – auch nicht lokal –, da der Speicher später wieder ausgelesen werden kann. Die meisten Menschen unterschätzen erheblich, wie viele Informationen sie ihren Mitarbeitern täglich anvertrauen.

Das Ausführen eines Modells mit 35 Milliarden Parametern auf einem Laptop, den Sie auch für Ihre Arbeit nutzen, stellt eine ganz eigene Herausforderung dar: Das Auslagern der Experten, sodass nur die aktiven Parameter im GPU-Speicher verbleiben, und das Zwischenspeichern der enormen, konstanten Präambel von Claude Code, damit diese nicht bei jedem Durchlauf erneut verarbeitet wird. Das verdient einen eigenen Beitrag, und ich habe die Einrichtung separat beschrieben; ein Begleitartikel mit dem Titel „Ein lokales LLM-Tier für Claude Code auf Ihrem Mac betreiben“ erscheint in Kürze.

Wir hatten einen ersten Entwurf zum Thema Souveränität. Doch mittlerweile liefen bereits alle Anfragen über diesen einen kleinen Proxy, was eine andere Frage aufwarf: Was gehört noch hierher?

Der Wendepunkt: Aus einer Naht wird ein Gurtzeug

Die Ratenbegrenzung hatte mir gezeigt, wo Arbeit fortbesteht: Ein Hilfsagent verliert seinen Kontext in dem Moment, in dem er unterbrochen wird, während eine vollständige Sitzung ihren Verlauf und ihr Gedächtnis beibehält. Daher wollte ich zwei vollständige Sitzungen, die miteinander koordinieren, und nicht eine, die instabile Helferagenten erzeugt. Die naive Version stieß auf zwei Hindernisse, und Claude äußerte sich zu beiden ganz offen: Er kann aus sich selbst heraus keine weitere Claude-Code-Sitzung starten, und aufgrund seiner Konzeption reagiert er nur auf Anweisungen von mir, dem Menschen in seiner Sitzung, nicht auf Nachrichten von einem anderen Prozess.

Dann las ich von einer Funktion, die Anthropic eingeführt hatte: „Channels“ – eine Möglichkeit für einen Server, Nachrichten als Ereignisse, auf die Claude Code reagieren kann, in eine laufende Claude-Code-Sitzung einzuspeisen. Das war die fehlende Hälfte. Ein weiteres Nebenprojekt: Wir bauten einen Server, Claude-Nexus. Da dämmerte es uns: AFP ist bereits die Ebene, die jede Anfrage durchläuft – also machen wir sie zum Broker. Nur ein autorisierter Server darf Nachrichten einspeisen, und zwar hinter einer HMAC-signierten Authentifizierung, und ein Mensch bestätigt weiterhin pro Sitzung, dass ein Kanal vertrauenswürdig ist, bevor auf dessen Nachrichten reagiert wird. Die Sicherheitsregel wird nicht umgangen; sie bleibt gewahrt.

Dadurch wurde „Parachute“ zu einer Drehscheibe. Instanzen auf verschiedenen Rechnern in meinem LAN können nun miteinander kommunizieren; ich habe dies genutzt, um ein Konfigurationsproblem auf einem Rechner von einem anderen aus zu beheben. Andere Tools wie „Codex“, „Antigravity“ und „copilot-cli“ können sich derselben Kommunikation anschließen. Und als ich Claude für einen Vortrag auf die Bühne holen wollte, habe ich dem Avatar (Amica) kein eigenes Modell zugewiesen und damit nicht noch eine weitere Sicherheitsmaßnahme erforderlich gemacht. Stattdessen habe ich Claude darüber geleitet. Gleiche Sicherheitsvorkehrungen, gleicher Speicher, nur ein neues Gesicht.

Anschlussschema. Drei Bereiche – der Claude-Code-Editor, Sitzungen auf anderen Rechnern über einen Relaisknoten und der Amica-Avatar – werden alle in AFP eingespeist, das Anschlussmodul am Port 8100. Von dort aus führt ein Pfad zu den Modellen und der lokalen Fallback-Ladder, ein weiterer zum gemeinsamen Speicher und zu den Schutzmechanismen, wobei der Zugriff an einer einzigen Stelle gesteuert wird. Eine Schnittstelle, viele Oberflächen. Jede Oberfläche greift über dieselbe Ebene auf die Modelle, den gemeinsamen Speicher und die Sicherheitsmechanismen zu, sodass der Zugriff an einer einzigen Stelle gesteuert wird.

Wir haben ein Framework: eine Nahtstelle, viele Oberflächen, eine zentrale Stelle zur Zugriffssteuerung. Doch wenn der wertvolle Teil die von mir entwickelte Schicht ist – das Routing, die „Local-First“-Verarbeitung, die Steuerung, die Verbindungen –, was macht das dann aus dem Modell?

Worum es sich hierbei tatsächlich handelt: Kabelbaumtechnik

Nun zur ehrlichen Wahrheit: Ich hatte nicht vor, „Harness-Engineering“ zu betreiben. Jedes einzelne Teil war eine Neben Aufgabe, die sich aus einem konkreten Projekt ergab, und ich wollte einfach nur weiterarbeiten. Nach sechs Monaten befanden sich die meisten meiner ursprünglichen Ideen noch in der Entwicklung, doch ich hatte bereits die gesamte Infrastruktur um sie herum aufgebaut und ausgeliefert. Erst als ich in meinem Newsletter darüber schrieb, stellte sich heraus, dass diese Nebenprojekte einen Namen hatten, dass ich die ganze Zeit über empirisch „Harness Engineering“ betrieben hatte und dass die großen Forschungslabore nun darum wetteifern, dasselbe zu entwickeln.

Nate B. Jones bringt es in einem aktuellen Video treffend auf den Punkt : „GLM 5.2 ist kostenlos und übertrifft Claude bei den meisten Aufgaben – warum können Unternehmen also nicht umsteigen?“ Ein Modell sei „ein Gehirn im Glas“ ohne Anbindung, und der Engpass liege derzeit in der „letzten Meile“, nicht im Modellaufruf. Ich möchte noch eine Umkehrung hinzufügen. Für ein Pionierlabor ist die Anbindung ein Schutzwall: Ihr Kontext, der an deren Plattform gebunden ist. Bei mir ist es genau umgekehrt. Da das System auf ein lokales Modell oder einen anderen Anbieter ausweichen kann, verhindert es, dass ich an einen einzelnen Anbieter gebunden bin. Dasselbe Wort, gegensätzlicher Zweck.

Und nichts davon ist ein Hobby. Mein Homelab ist zwar eine Testumgebung, doch die Anforderungen stammen aus der realen Kundentätigkeit – wie beispielsweise bei einem Kunden, der seinen sensiblen Datenstrom in ein lokales, reguliertes Modell leiten lassen möchte, während alles andere an eine kostengünstigere Cloud-Lösung gesendet wird. Ich hätte das lieber schon geklärt, bevor die Frage aufkam. Sobald ich weiß, was sicher ist und was sich bewährt, fließen die einzelnen Elemente in die praktische Arbeit ein: Die Arbeitsweise, die Agenten, die Überprüfungsschritte und die Sicherheitsvorkehrungen sind nun alle Teil eines echten Projekts.

Die Vor- und Nachteile, ganz ehrlich

Die lokale Ebene ist tatsächlich eingeschränkt: Ein quantisiertes 35B sorgt dafür, dass Sie sich innerhalb eines Begrenzungsfensters bewegen, ersetzt jedoch nicht Opus. AFP ist von Grund auf als Ein-Prozess-System konzipiert, was den Betrieb des Systems aufrechterhält, jedoch keine horizontale Skalierung zulässt, ohne die Speicherung des gemeinsam genutzten Zustands neu zu überdenken. Und Sie betreiben nun eine Infrastruktur.

Das Ganze hat sogar etwas Absurdes an sich. Wenn der Proxy selbst eine Korrektur benötigt, kann ich diese nicht immer von innen heraus vornehmen. Wenn Claude versucht, AFP zu reparieren, während der eigene Datenverkehr über AFP geleitet wird, wirft er sich mitten in der Änderung selbst heraus. Deshalb halte ich eine einfache Sitzung außerhalb des Proxys aufrecht, nur um den Proxy zu reparieren und uns wieder den Zugang zu ermöglichen. Ich beobachte nach wie vor jedes Terminal, wenn die Multi-Agent-Konfiguration in Betrieb ist, da ich ihr noch nicht genug vertraue, um sie unbeaufsichtigt laufen zu lassen.

Sollten Sie also einen bauen?

Ich habe gemischte Gefühle bei diesem Thema. Ich habe einen Großteil von sechs Monaten mit etwas verbracht, das eigentlich ein „Quick Win“ sein sollte, daher hier meine ehrliche Antwort: Im Großen und Ganzen nein. Für die meisten Nutzer reichen das „Harness“, das Claude Code standardmäßig mitliefert, und die neuen Funktionen, die die großen Labore fast wöchentlich veröffentlichen, völlig aus. Wenn Sie an einen SLA gebunden sind und das, was Sie bereitstellen, warten müssen, ist die Eigenentwicklung ein schlechter Tausch; es ist praktischer, die Lösung zu kaufen. Wenn Sie Entwickler sind oder sich im technischen Bereich weiterentwickeln möchten – vielleicht sogar einen Karrierewechsel in diese Richtung anstreben –, lohnt es sich dennoch, die Konzepte zu erlernen; Sie müssen die Infrastruktur nicht unbedingt selbst aufbauen.

Und wenn Sie sich doch für den Eigenbau entscheiden: Seien Sie sich der Kosten bewusst. Jede Stunde, die ich für den Kabelbaum aufgewendet habe, war eine Stunde, die ich nicht für das Projekt nutzen konnte, das ihn eigentlich benötigte. Es ist nicht kostenlos, und es ist nicht immer die richtige Entscheidung – wählen Sie also Ihre Projekte mit Bedacht aus. Doch wenn Sie die Zeit dafür aufbringen können, macht sich das im Laufe der Zeit bezahlt.

Das haben wir schon einmal erlebt. Zunächst verfügten nur die großen Forschungslabore über ein brauchbares Modell; dann holte Open Source schnell auf; mittlerweile gibt es viele davon, und die Frage lautet nicht mehr „Wessen Modell?“, sondern „Wie nützlich ist es, was kann es in meinem Fall leisten?“ Zunehmend liefert ein spezifisches Framework die Antwort darauf, weshalb die großen Forschungslabore nun darum wetteifern, ihre eigenen zu entwickeln.

Eine schummrige, futuristisch anmutende Galerie, in der mehrere unterschiedliche modulare Exoanzüge in einer Reihe beleuchteter Nischen stehen, die jeweils mit verschiedenen Werkzeugen und Ausrüstungsgegenständen ausgestattet sind, während eine einzelne, von hinten gezeigte Gestalt überlegt, welchen sie verwenden soll. Ein Kern, viele Hüllen. Unterschiedliche Aufgaben erfordern unterschiedliche Konfigurationen; Sie wählen die für die jeweilige Aufgabe geeignete Konfiguration aus, während die darin enthaltene Intelligenz unverändert bleibt.

Das Modell wird zunehmend zu einer Massenware. Das „Harness“ – der Teil, den Sie nach Ihren eigenen Vorstellungen entwickeln, steuern und verwalten – ist der Teil, der tatsächlich Ihnen gehört. Nehmen Sie Claude Design als Beispiel: Keines der Modelle von Anthropic erzeugt von sich aus Bilder – erst der „Harness“ verleiht ihnen die Fähigkeit, so zu agieren, als ob sie es täten. Wenn Sie diese Fähigkeit für Ihre eigenen Werkzeuge nutzen möchten, lohnt es sich, diese gezielt zu entwickeln.

Verfasst von

Ricardo Granados

Contact

Let’s discuss how we can support your journey.