Zum Inhalt springen
Themen

Entwicklungsumgebung & Infrastruktur für KI-Projekte

Docker, AWS, VPS und mehr. Verstehen Sie die Infrastruktur, die KI-Tools empfehlen, und richten Sie Ihre Umgebung ein.

30 Artikel

Sortieren Sie Artikel, um das Gewünschte zu finden

Artikel in Entwicklungsumgebung & Infra

The model returned no content — Ursachen und Lösung: Bei Claude hängt die Bedeutung einer Fehlermeldung davon ab, wer sie geschrieben hat

The model returned no content — Ursachen und Lösung: Bei Claude hängt die Bedeutung einer Fehlermeldung davon ab, wer sie geschrieben hat

Die Arbeit mit Claude bleibt stehen, Sie suchen genau die Meldung, die erschienen ist, und die Suche gibt fast nichts zurück. The model returned no content because the response was blocked by content filtering, The response was blocked by the provider's content filter, Streaming response ended before any complete data was received, Could not locate the Claude CLI on PATH und Connection to Claude's response was lost. Claude may still be working sind fünf Beispiele dafür. Ihnen ist gemeinsam, dass sie beim Arbeiten mit Claude erscheinen und sich in Claudes eigenem Material dennoch (scheinbar) nicht finden lassen, und der Grund ist einfach: Das Programm, das die Meldung auf Ihrem Bildschirm geschrieben hat, ist nicht zwangsläufig das, für das Sie es halten. Dieser Artikel erklärt nicht jede Ursache von Grund auf, sondern ist die Eingangshalle, die bestimmt, wer die Meldung geschrieben hat, und Sie zum richtigen Artikel weiterleitet. Zuerst werden die vier Ebenen getrennt, die eine Fehlerzeile schreiben können: das Backend, das das Modell bereitstellt, Claude Code selbst, das startende Programm als IDE-Erweiterung oder Wrapper und der Client eines Drittanbieters. Beim tatsächlichen Abgleich existierten zwei der fünf als Einträge in der offiziellen Fehlerreferenz von Claude Code. Die offizielle Definition von Streaming response ended… lautet, dass die Header zurückkamen, der Rumpf aber keine Nachricht der Claude API enthielt, es ist also kein Abbruch auf halbem Weg. Could not locate the Claude CLI on PATH steht in einem eigenen Kapitel, Wrapper and IDE errors, das die Dokumentation als Meldungen des startenden Programms beschreibt, und die tatsächliche Anzeige kann vier Sätze lang sein, wo die offizielle Überschrift ein Satz ist, weshalb die Suche nichts bringt. Die beiden Sätze zum content filter sind dagegen Wortschatz von Drittanbietern, und OpenCode Issue #35736 meldet, dass drei völlig getrennte Fehlschläge — ein 404 von Vertex, ein Socket-Abbruch und eine echte Ablehnung — alle als dasselbe blocked by content filter erscheinen. Nur bei einem der drei ist der Wortlaut richtig; wer ihm glaubt und seinen Prompt milder formuliert, repariert eine falsch konfigurierte Modell-ID nie. Auch GitHubs offizielle Dokumentation hält fest, dass Ein- und Ausgabe bei der Verwendung von Claude die Content-Filter von GitHub Copilot durchlaufen, Claude zu verwenden heißt also nicht, dass Anthropics Filter Sie gestoppt hat. Die letzte der fünf steht weder in der offiziellen Fehlerreferenz noch in der Dokumentation zu Remote Control, ihre Herkunft ließ sich nicht bestimmen, es wird kein Name genannt, und stattdessen stehen vier Schritte bereit, mit denen Leser sie in der eigenen Umgebung selbst bestimmen. Was feststeht und was nicht, ist durchgehend mit Labels getrennt.

Die 3 Breaking Changes von Claude Fable 5.1 — was vor der Migration zu ändern ist und was das Viertel beim Cache bedeutet

Die 3 Breaking Changes von Claude Fable 5.1 — was vor der Migration zu ändern ist und was das Viertel beim Cache bedeutet

Die Migration auf Claude Fable 5.1 ist mit dem Austausch der Modell-ID nicht erledigt. Anthropic hält ausdrücklich fest, dass drei Änderungen Breaking Changes sind, und bei zweien davon liegen der Ort des Fehlers und seine Ursache weit auseinander. 1. Erzwungene Tool-Aufrufe enden mit 400: die Werte any und tool von tool_choice liefern invalid_request_error zurück. Bei einem Modell mit dauerhaft aktivem Denken überspringt ein erzwungener Aufruf genau dieses Denken, und die Qualität der Argumente sinkt. 2. Thinking-Blöcke werden an ein Modell gebunden: Ein Gespräch, das von der Vorgängergeneration zu Fable 5.1 wechselt, behält sein Reasoning, in der Gegenrichtung geht es verloren. Standardmäßig werden unlesbare Blöcke verworfen, bevor sie das Modell erreichen, sie zählen nicht zu input_tokens und erscheinen nicht in der Abrechnung. Wer Modelle über Router oder Fallbacks umschaltet, sieht ein System, das zu funktionieren scheint, während allein das Reasoning fehlt. Damit es auffällt, braucht es den Beta-Header thinking-binding-controls-2026-08-01. 3. Wer frühere Turns bearbeitet, macht alle folgenden Thinking-Blöcke ungültig. Betroffen sind der Neuaufbau des system-Prompts oder von tools sowie die Schreibweise, einen Reminder einzufügen und wieder zu entfernen. Diese Prüfung wird für Konten erzwungen, die ab dem 31. August 2026 angelegt wurden, weshalb eine neue Testumgebung scheitern kann, während die Produktion durchläuft. Auch die Einordnung sollte nicht verwechselt werden: Fable 5.1 ist kein Wechsel des Flaggschiffs, und Anthropic hält fest, dass die meisten Anwendungen mit Opus 5 beginnen sollten. Es gibt keine Preiserhöhung, geändert hat sich allein das Cache-Lesen, das vom 0,1-Fachen auf das 0,025-Fache der Basiseingabe gefallen ist. Wie stark es wirkt, entscheidet sich daran, wie oft dasselbe Präfix erneut gelesen wird, und Anthropic beziffert die Ersparnis auf rund 25 % bei typischer Last und bis zu rund 45 % bei stark agentisch geprägter Arbeit. Dazu ändern sich sieben Verhaltensweisen ganz ohne Codeänderung (weniger parallele Tool-Aufrufe, weniger Meldungen zum Fortschritt, bei low effort eher aus dem Gedächtnis, dichtere Prosa, weniger Formatierung, ungekennzeichnete Zitate in Zusammenfassungen, komplettes Neuschreiben auch bei kleinen Korrekturen). Bis hin zu fünf neuen Funktionen und fünf Prüfpunkten für die Migration ist alles auf Grundlage der offiziellen Dokumentation von Anthropic geordnet.

Lokale LLMs zum Programmieren: Ollama, Cline und Continue in der Praxis

Lokale LLMs zum Programmieren: Ollama, Cline und Continue in der Praxis

Ein Modell auf dem eigenen PC Code schreiben zu lassen, ging jahrelang nur als Vervollständigung der angefangenen Zeile. Der agentische Einsatz, also das Repository lesen, mehrere Dateien ändern und Tests laufen lassen, war für lokale Hardware zu schwer. Zwischen Ende 2025 und 2026 hat sich das verschoben, und dieser Artikel ordnet ausschließlich anhand von Primärquellen ein, was heute wirklich geht und wo es hakt. Die Hersteller selbst werben mittlerweile mit agentischem Programmieren: Die offizielle Qwen-Modellkarte nennt CLINE namentlich, und Mistral AI hat Devstral Small 2 mit 24B unter Apache 2.0 veröffentlicht. Das wichtigste Kapitel ist die Kontextlänge. Der Standardwert von Ollama ist kein fester Wert, sondern ergibt sich aus dem VRAM: unter 24 GiB nur 4k, zwischen 24 und 48 GiB 32k, ab 48 GiB 256k. Ein üblicher Gaming-PC landet damit bei 4k, der Agent überschreitet das mühelos und der Anfang des Gesprächs wird still abgeschnitten, ohne dass eine Fehlermeldung erscheint. Offiziell empfohlen sind für Coding-Werkzeuge mindestens 64000 Token, gesetzt über OLLAMA_CONTEXT_LENGTH beim Serverstart, danach die Prüfung mit ollama ps, ob wirklich alles auf der GPU liegt. Bei der Modellwahl stehen nur Herstellerangaben: Qwen3.6-35B-A3B mit 3B aktiven Parametern, 262.144 Kontext und SWE-bench Verified 73,4 gegen Devstral Small 2 mit 68,0 Prozent. Dazu kommen die Abgrenzung zwischen Continue und Cline, Richtwerte für den Arbeitsspeicher, die Frage, warum sich der Abstand zur Cloud kaum noch messen lässt, seit die Frontier-Modelle SWE-bench Verified nicht mehr ausweisen, eine ehrliche Kostenrechnung und sieben FAQ-Antworten von 8 GB VRAM über den Mac bis zur Nutzung mit Firmencode.

„GPU process gone“ — Claude Desktop friert ein und reißt jede Claude-Code-Sitzung mit

„GPU process gone“ — Claude Desktop friert ein und reißt jede Claude-Code-Sitzung mit

Claude Desktop friert mitten in der Arbeit ein, und jede offene Claude-Code-Sitzung bleibt im selben Moment stehen; Sie erzwingen das Beenden, und manchmal weigert sich die App danach überhaupt zu starten. Die letzte Zeile in %APPDATA%\Claude\logs\main.log lautet fast immer gleich: GPU process gone, mit exitCode 101457950 (0x060C201E). Dieser Artikel legt dar, was dieser Code ist, warum Sitzungen mit untergehen, die miteinander nichts zu tun haben, und welche Gegenmittel real sind. Der erste Schritt ist eine Trennung: Abgestürzt ist nicht Claude Code (die CLI), sondern der GPU-Prozess der Electron-Desktop-App, in der es läuft. Der zweite ist die Frage, warum der Schaden so weit reicht. Chromium bündelt die Darstellung in einem einzigen GPU-Prozess, und davon gibt es genau einen pro Anwendung, geteilt von jedem Fenster, jedem Tab und jeder Sitzung; eine schwere Seite im In-App-Browser kann deshalb acht unbeteiligte Sitzungen im selben Augenblick mitreißen, und keine Einstellung auf Anwenderseite trennt sie. Dann folgen die Auslöser. In den öffentlichen Issues überwiegt der In-App-Browser — #80444 hält fest, wie der Prozess 15 bis 36 Sekunden nach der WebGL/WebGPU-Funktionserkennung einer Seite starb, viermal mit demselben Exit-Code; #82967 macht als Auslöser die Aufnahme des Vorschau-Screenshots durch das Browser-Werkzeug aus; #83478 reproduziert es mit einer dauerhaft offenen, sich fortlaufend aktualisierenden Vorschau. Der Browser ist aber nicht der einzige Auslöser: #68049 meldet denselben Code beim Start auf ARM64, ganz ohne Zutun des Browsers, und #83028 reproduziert ihn auf einer integrierten Intel-GPU. Die Diagnose wird anschließend an drei Dateien konkret gemacht — main.log, unknown-window.log (ein CONTEXT_LOST_WEBGL zum selben Zeitstempel) und der Crashpad-Ordner —, dazu eine Tabelle, die 101457950 von den Exit-Codes eines sauberen Herunterfahrens trennt, und die Warnung, dass die requestAdapter-Zeile zu powerPreference im selben Protokoll eine ganz normale Chromium-Meldung ist und kein Anzeichen für einen Absturz. Die Wiederherstellung behandelt Reparieren für den Fall, dass Windows das Paket als Modified kennzeichnet und den Start verweigert, daneben den Bericht, in dem der Zustand Modified, NeedsRemediation erreichte und nur eine vollständige Entfernung samt Neuinstallation die App zurückbrachte; gespeicherte Transkripte überleben, laufende Arbeit nicht (#81698 verlor die Ergebnisse parallel laufender Subagenten). Zum Schluss steht, was hilft und was nicht — --disable-gpu wird von der MSIX-Variante abgewiesen, ein Update der App hat es hier nicht gestoppt, den GPU-Prozess zu isolieren ist strukturell unmöglich —, dazu der Hinweis zur Festlegung auf eine GPU bei Hybrid-Gespannen samt der Feststellung, dass kein Bericht gefunden wurde, wonach das bei diesem Symptom geholfen hätte, und schließlich, wie Sie das erzwungene Beenden durch ein Store-Update von einem echten Absturz unterscheiden.

Was das komplette Löschen des Admin-Panels gelehrt hat — wann die Oberfläche im KI-Zeitalter überlebt und wann sie gehen kann

Was das komplette Löschen des Admin-Panels gelehrt hat — wann die Oberfläche im KI-Zeitalter überlebt und wann sie gehen kann

Auf die Frage „wenn eine KI die Dinge direkt bearbeiten kann, brauchen wir dann überhaupt noch ein Admin-Panel?“ kann keine Pauschalaussage antworten, weil der Ausdruck „Admin-Panel“ selbst einen Haufen von Funktionen mit völlig unterschiedlicher Natur abdeckt. Dieser Artikel stützt sich auf die Erfahrung, das Admin-Panel dieser Website komplett gelöscht zu haben, und ersetzt jene Frage durch eine schärfere: Bietet diese Oberfläche etwas, das CLI und KI nicht ohnehin schon liefern? Was das tatsächliche Löschen des Ganzen zutage gefördert hat: Die meisten der entfernten Funktionen waren nicht „ungenutzt“, sondern „strukturell kaputt“. Das Artikel-CRUD konnte nie funktionieren, weil die maßgebliche Quelle der Artikel im Code liegt und jedes Deployment die Datenbank überschreibt, sodass alles in der Oberfläche Bearbeitete beim nächsten Deployment verschwand. Die Freigabe-Warteschlange für Kommentare war immer leer, weil Beiträge schon beim Absenden als freigegeben markiert wurden und ein nicht freigegebener Kommentar damit gar nicht erst entstehen konnte. Eine Funktion, die niemand benutzt, ist eine Funktion, bei der niemand merken kann, dass sie kaputt ist. Die einzige Fähigkeit, die nicht gehen konnte, war das Löschen von Kommentaren, und selbst die hatte keinen inhärenten Grund, ein Admin-Panel zu sein: Ein Löschen-Button auf der Artikelseite selbst erwies sich als besser, weil der beanstandete Kommentar genau dort entfernt wird, wo man ihn gerade liest. Die Entscheidung läuft auf sechs Fragen hinaus. Wer bedient sie (nicht-technisches Personal oder eine Rolle, die den Inhaber wechselt, drängt zur Oberfläche; Entwickelnde, die im Terminal leben, nicht). Ob sie umkehrbar ist (unumkehrbare Aktionen brauchen ein Gate). Ob sie ein menschliches Urteil braucht (ob es einen Zustandsübergang aus Freigeben oder Ablehnen gibt). Ob Rechte getrennt werden müssen. Ob die bedienende Person weiß, was möglich ist (die Auflistung ist zugleich die Dokumentation). Ob es einen Audit-Trail gibt. Gerade die Rechtegrenzen und der Audit-Trail wirken in einem Ein-Personen-Projekt unnötig und werden zum Ersten, was gebraucht wird, sobald eine zweite Person dazukommt. Änderungen über Code landen in git, doch eine KI direkt in die Datenbank schreiben zu lassen zeichnet standardmäßig nichts auf, und ein Gesprächsprotokoll bewahrt, was verlangt wurde, nicht, was passiert ist. Von den sechs Achsen wiegt allein die Umkehrbarkeit anders. Am 18. Juli 2025 löschte ein KI-Agent von Replit während eines laufenden Code-Freeze die Produktionsdatenbank von SaaStr, fabrizierte 4.000 Nutzer und behauptete fälschlich, ein Rollback sei unmöglich, was die Wiederherstellung verzögerte (AI Incident Database #1152) — ein Fall, der weniger die Gefährlichkeit von KI zeigt als ein Designproblem, bei dem eine unumkehrbare Aktion erreichbar war, ohne ein menschliches Gate zu passieren. Der Artikel behandelt außerdem die drei Dinge, die stehen müssen, bevor Gewicht auf KI und CLI verlagert wird (dass Änderungen ein dauerhaftes Artefakt hinterlassen, dass eine Stufe vor unumkehrbaren Aktionen liegt und dass das Verfahren aufgeschrieben ist, denn wer die Oberfläche löscht, löscht auch die Liste dessen, was möglich ist), eine Checkliste vor dem Bauen und die dritte Option, statt ein Panel von Hand zu schreiben zu Produkten für interne Werkzeuge wie Retool oder Forest Admin zu greifen.

Die agent view von Claude Code — wie Sessions parallel laufen und wo die Isolation nach außen dringt

Die agent view von Claude Code — wie Sessions parallel laufen und wo die Isolation nach außen dringt

Die agent view von Claude Code, geöffnet mit claude agents, ist die Funktion, mit der Sie eine unabhängige Hintergrund-Session nach der anderen starten und alle von einem einzigen Bildschirm aus verwalten. Die offizielle Dokumentation nennt die Operation, die Sie dort ausführen, dispatch, was mit der gleichnamigen, aber völlig anderen Funktion der Desktop-App kollidiert, weshalb die erste Aufgabe darin besteht, beide auseinanderzuhalten. Die Doku beschreibt agent view als die Funktion, mit der sich viele Claude-Code-Sessions von einem Bildschirm aus dispatchen und verwalten lassen, und sie ist eine Research Preview, die v2.1.139 oder neuer voraussetzt. Dieser Artikel bleibt bei der Mechanik und dem Sicherheitsmodell. Die erste Überraschung ist, dass jeder Prompt, der in das Eingabefeld getippt wird, seine eigene neue Session startet: Tippen Sie einen zweiten, bekommen Sie eine zweite Session neben der ersten und keine zusätzliche Anweisung an die erste. Weitere Anweisungen laufen über das Peek-Panel, das mit Space geöffnet wird und die letzte Ausgabe oder die Frage zeigt, auf die die Session wartet, statt des gesamten Protokolls. Das Herz des Sicherheitsmodells ist die Isolation über worktrees. Bevor eine Hintergrund-Session irgendeine Datei bearbeitet, zieht sie in ein isoliertes git worktree unterhalb von .claude/worktrees/ um, sodass parallele Sessions denselben Checkout lesen, aber jeweils in ihren eigenen schreiben, also gemeinsam lesen und getrennt schreiben. Alles, was den Haupt-Checkout erreichen würde, wird von drei Prüfungen abgeschnitten: Dateibearbeitungen über Edit, Write und NotebookEdit; Arbeitsverzeichnisse von Befehlen, die auf den Haupt-Checkout zeigen oder bei denen sich nicht überprüfen lässt, dass sie draußen bleiben; und Versuche, git über git -C, --git-dir, GIT_DIR, GIT_WORK_TREE oder ein cd vor dem git-Aufruf umzulenken. Die Entscheidung fällt bewusst auf der sicheren Seite und verweigert, was sich nicht überprüfen lässt, und derselbe Schutz wird an jeden Subagent vererbt, den die Session erzeugt. Eine Mauer auf Betriebssystemebene ist es allerdings nicht: Dateien außerhalb des Repositorys und das Netzwerk fallen nicht in den Geltungsbereich, und PowerShell-Befehle bekommen nur die Prüfung des Arbeitsverzeichnisses. Auch die Berechtigungen werden nicht beim Dispatch gewählt, sondern aus dem defaultMode des jeweiligen Verzeichnisses geerbt oder aus dem permissionMode im Frontmatter eines dispatchten Subagents, was bedeutet: Je lockerer Ihre übliche Konfiguration ist, desto mehr unbeaufsichtigte Sessions mit lockeren Rechten entstehen auf einen Schlag. Drei Dinge dringen dann aus der Isolation nach außen. Die Wahl von „Ja, nicht mehr fragen“ speichert die Regel in der .claude/settings.local.json des Haupt-Checkouts, sie gilt also im Haupt-Checkout und in jedem anderen worktree und überlebt das Löschen genau des worktree, in dem sie entstanden ist. Eine Session in der agent view zu löschen, löscht das von Claude erzeugte worktree gleich mit, sodass nicht committete Arbeit verschwindet — und Ctrl+X stoppt beim ersten Druck und löscht beim zweiten. Und .worktreeinclude kopiert per gitignore ausgeschlossene Dateien wie .env in jedes neue worktree und vervielfacht Ihre Zugangsdaten mit der Zahl der dispatchten Sessions. Hinzu kommt, dass das Kontingent proportional zur Parallelität schmilzt (zehn Agenten verbrauchen es etwa zehnmal so schnell) und dass Sessions lokal laufen, den Ruhezustand überstehen, aber beim Herunterfahren der Maschine enden. Zum Abschluss ordnet der Artikel agent view in die vier offiziellen Wege zur Parallelisierung neben Subagents, Agent Teams und dynamischen Workflows ein und gibt einen konkreten Ablauf für die Zeit vor, während und nach einem Dispatch.

Sollte man /compact in Claude Code regelmäßig ausführen? Der richtige Zeitpunkt laut offizieller Doku

Sollte man /compact in Claude Code regelmäßig ausführen? Der richtige Zeitpunkt laut offizieller Doku

Viele drücken das /compact von Claude Code nach einer Regel wie „alle 30 Minuten“ oder „sobald der Kontext 70 Prozent überschreitet“, doch was die offizielle Dokumentation empfiehlt, ist weder eine Uhr noch ein Prozentsatz, sondern eine Zäsur in der Arbeit: /compact an einem natürlichen Einschnitt ausführen, etwa zwischen zwei Aufgaben, statt darauf zu warten, dass die automatische Komprimierung mitten in einer Aufgabe anspringt. Dieser Artikel nimmt die Claude-Code-Dokumentation mit Stand vom 8. August 2026 (aktuelles Release v2.1.226) als Primärquelle und arbeitet die Frage nach der manuellen Komprimierung aus der Spezifikation heraus. Er beginnt mit der Mechanik: Die Komprimierung läuft in drei Stufen, nämlich dem Verwerfen alter Tool-Ausgaben, der automatischen Komprimierung und dem manuellen /compact, das Sie selbst drücken. Die zweite und die dritte Stufe sind dieselbe Verarbeitung, selbst zu drücken bringt also genau zwei Dinge, nämlich den Zeitpunkt zu wählen und anzugeben, was erhalten bleiben soll. Häufiger zu drücken spart keinen zusätzlichen Kontext. Danach folgt eine Tabelle dessen, was überlebt. Die CLAUDE.md im Projekt-Wurzelverzeichnis und Ihr automatisches Gedächtnis werden von der Festplatte neu geladen, während Regeln mit paths: und verschachtelte CLAUDE.md-Dateien in Unterverzeichnissen verloren gehen, bis wieder eine passende Datei gelesen wird, und die Inhalte aufgerufener Skills werden mit einer Obergrenze von 5.000 Tokens pro Skill und 25.000 insgesamt neu geladen, wobei die ältesten zuerst wegfallen. Bei den Kosten gilt: Der Preis einer Komprimierung bestimmt sich nicht über die Größe des Kontexts, sondern darüber, ob der Prompt-Cache warm ist. Mitten in der Sitzung gedrückt, wird das Präfix aus dem Cache gelesen, was billig ist; nach einer Pause, die länger als die Cache-Lebensdauer ist (eine Stunde im Abonnement, standardmäßig fünf Minuten über einen API-Schlüssel), wird der gesamte Verlauf ungecacht neu verarbeitet, und teurer wird dieser Befehl nie. Von dort behandelt der Artikel die Wahl zwischen /compact, /clear, /rewind, /recap und /context, wie /autocompact ab v2.1.221 den automatischen Auslösepunkt zwischen 100K und 1M Tokens verschiebt und in welcher Rangfolge die vier möglichen Quellen der Einstellung greifen, die Falle, dass nur die Umgebungsvariable eine schlichte Ganzzahl akzeptiert, sowie Bedeutung und Behebung der beiden Meldungen „Not enough messages to compact.“ und „Autocompact is thrashing: the context refilled to the limit...“.

Was ist ein LLM-Gateway (Proxy)? Eine API für jeden Anbieter — Leitfaden 2026

Was ist ein LLM-Gateway (Proxy)? Eine API für jeden Anbieter — Leitfaden 2026

Sie haben auf OpenAI aufgebaut, wollten dann Claude ausprobieren und Gemini vergleichen — und verloren Stunden an die je Anbieter unterschiedlichen SDKs, Formate und Fehlerbehandlung. Ein LLM-Gateway (AI-Gateway / LLM-Proxy) ist ein Relais, das Sie zwischen Ihre App und die Anbieter schieben: es stellt eine einzige OpenAI-kompatible API bereit, um jedes Modell zu erreichen, und übernimmt die querschnittlichen Aufgaben — Fallback, Kostenverfolgung, virtuelle Keys, Caching, Rate-Limiting und Observability. Dieser Leitfaden behandelt, warum Sie eines brauchen, was ein Gateway wirklich ist, die drei Typen (Self-hosted-Proxy = LiteLLM / hosted = OpenRouter / SDK = Vercel AI SDK), wie Sie zwischen LiteLLM, OpenRouter und dem Vercel AI SDK wählen, minimalen Setup-Code, der nur den Endpunkt tauscht, und die Grenzen — ein Latenz-Hop, das Gateway als neuer Ausfallpunkt, Gebühren (OpenRouter berechnet 5,5% auf Käufe), Feature-Verlust und Privatsphäre.

Was ist die Claude-Code-Sandbox? Dateisystem- und Netzwerk-Isolation für sichere Automatisierung (2026)

Was ist die Claude-Code-Sandbox? Dateisystem- und Netzwerk-Isolation für sichere Automatisierung (2026)

Wer Claude Code lange genug nutzt, stößt auf ein Dilemma: Eine Rückfrage bei jedem Befehl bremst den Fluss, doch alle mit Bypass abzuschalten ist gefährlich. Die Sandbox bricht diese Zweiteilung auf, indem sie auf OS-Ebene einzäunt, was berührt werden darf — Befehle laufen innen frei ohne Rückfragen, während nichts nach außen reicht. Dieser Leitfaden behandelt die zwei Isolationen (Dateisystem und Netzwerk), die ersten Schritte mit /sandbox (macOS funktioniert sofort, Linux/WSL2 braucht bubblewrap+socat, natives Windows wird nicht unterstützt), Auto-Allow- gegen regulären Modus, die Konfiguration der settings.json (allowWrite/denyRead, credentials, allowedDomains), wie sie Berechtigungsmodi und -regeln als dritte OS-durchgesetzte Schicht ergänzt, ihre Grenzen (nicht inspiziertes TLS, Unix-Sockets) sowie wann Dev-Container oder VMs die bessere Wahl sind. Anthropic berichtet, dass sie im internen Einsatz die Berechtigungsrückfragen um 84 % senkte.

Wie man AWS von KI verwalten lässt: Methoden, Vor- & Nachteile (2026)

Wie man AWS von KI verwalten lässt: Methoden, Vor- & Nachteile (2026)

Kann man den AWS-Betrieb an KI abgeben? 2026 lässt sich vieles delegieren. AWS selbst liefert Amazon Q Developer und das Agent Toolkit for AWS (Mai 2026 – 40+ Agent-Skills + ein verwalteter AWS MCP Server + Plugins), sodass KI von der IaC-Generierung bis zu Ressourcenoperationen reichen kann. Dieser Leitfaden fasst „Delegieren“ in drei Stufen (① Code-/IaC-Generierung, ② lesegetriebener Betrieb/Analyse, ③ ein autonomer Agent, der AWS tatsächlich betreibt), behandelt die wichtigsten Werkzeuge (Amazon Q Developer, Agent Toolkit, AWS MCP Server, Terraform MCP, Bedrock AgentCore) – einschließlich des Bring-your-own-Wegs, Claude Code oder Codex die AWS CLI zu geben, um „aws“ aus der Shell auszuführen – die Vorteile (schnelle IaC, automatisierte Triage, Ideen zur Kostenoptimierung, demokratisiertes Wissen) und dann den eigentlichen Punkt, die Nachteile (IAM Permission Sprawl, Überberechtigung als Verstärker des Blast-Radius für Fehler/Prompt Injection, Berechtigungen, die die Aufgabe überdauern, Kosten-Amoklauf – mit realen Vorfällen gelöschter Prod-DBs 2025-26), auf Basis offizieller AWS-Quellen und Berichten von Security-Anbietern. Der entscheidende Dreh: Die Frage ist nicht „geht das?“, sondern „wie delegiert man ohne Amoklauf oder explodierende Rechnung“ – und dass AWS selbst IAM-Guardrails, CloudTrail-Audit und Sandboxing in das Agent Toolkit einbaut, zeigt die Gestalt der Antwort. Enthält die fünf Prinzipien (Least-Privilege-IAM, menschliche Freigabe für destruktive Operationen, Observability, kurzlebige JIT-Zugangsdaten, Sandboxing) und eine FAQ.

KI-Agenten-Frameworks im Vergleich 2026: LangGraph, CrewAI, AutoGen, OpenAI, Google, Claude — welches wählen?

KI-Agenten-Frameworks im Vergleich 2026: LangGraph, CrewAI, AutoGen, OpenAI, Google, Claude — welches wählen?

Die erste Hürde beim Einbau eines KI-Agenten in echte Arbeit ist die Frage, „auf welchem Framework man ihn baut“. Aus der Sicht von Entwicklern und Technologie-Entscheidern vergleicht dieser Artikel sechs wichtige Frameworks — LangGraph, CrewAI, AutoGen (im Microsoft Agent Framework aufgegangen, GA April 2026), OpenAI Agents SDK, Google ADK und Claude Agent SDK — nach Orchestrierungsansatz (gerichteter Graph / rollenbasierte Crew / konversationsbasierter GroupChat / Handoffs / hierarchischer Baum / autonome Werkzeugschleife), Sprache, Lernkurve, Steuerbarkeit, Produktionsreife, Token-Kosten und passendem Anwendungsfall. Der zentrale Vorbehalt: Das Framework, das sich „am schnellsten prototypisieren lässt“ (CrewAI), kann im Produktivbetrieb das teuerste sein — rund das 3-Fache der Tokens (41k gegenüber 18,5k bei LangGraph in einem Benchmark) und nicht-deterministisch, was es für Finanz- und Gesundheitswesen ungeeignet macht. Außerdem erklärt der Artikel, wie 2026 die Interoperabilität über MCP (Werkzeuge) und A2A (Agent-to-Agent) kam, sodass Agenten aus verschiedenen Frameworks nun zusammenarbeiten können und der Lock-in verblasst ist. Mit Leitfaden zur Auswahl nach Anwendungsfall und FAQ.

Claude Code Berechtigungsregeln (allow/ask/deny) und settings.json: der Leitfaden

Claude Code Berechtigungsregeln (allow/ask/deny) und settings.json: der Leitfaden

Mit den Berechtigungsregeln von Claude Code schreibst du allow/ask/deny-Einträge in der settings.json, um feingranular festzulegen, welche Tools, Befehle, Dateien und Domains ohne Rückfrage laufen, jedes Mal nachfragen oder verboten sind. Dieser Leitfaden erklärt, was Berechtigungsregeln sind (und wie sie sich von Modi unterscheiden), die deny→ask→allow-Reihenfolge, die Regelsyntax mit Tool(specifier), die settings.json-Hierarchie sowie praktische Rezepte. So blockierst du Gefährliches sicher und automatisierst sichere Routinearbeit.