KI-Tool-Anleitungen, Vergleiche und Neuigkeiten

Die Meldung „You've hit your session limit · resets 3:45pm“ in Claude Code ist kein Fehler, sondern das Nutzungslimit des Abos. Die offizielle Referenz nennt vier Varianten: session (das rollierende 5-Stunden-Fenster), weekly (das Wochenfenster) sowie Opus und Sonnet (Limits nur für eine Modellfamilie); weil Sitzungs- und Wochenlimit für alle Modelle gelten, bringt ein Modellwechsel den Zugang nicht zurück. Dieser Artikel erklärt, was jede Meldung bedeutet und wie sich der Text seit dem alten „Claude usage limit reached“ verändert hat, was den Verbrauch treibt und was im Moment des Limits hilft: bei einem Opus-/Sonnet-Limit mit /model das Modell wechseln, auf den Reset warten (ab v2.1.234 automatisch), Nutzungs-Credits über /usage-credits nutzen oder auf die nutzungsbasierte API umsteigen. Dazu: wie du den Rest mit /usage prüfst und welche ähnlichen Meldungen nicht dein Limit sind.

Claude Code meldet „Prompt is too long“, wenn die gesamte Eingabe einschließlich Verlauf, Dateien und Tool-Ergebnissen das Kontextlimit überschreitet. Der Artikel unterscheidet zwischen dem Komprimieren eines langen Verlaufs, dem Verkleinern einer zu großen ersten Eingabe und dem Beheben der Ursache einer fehlgeschlagenen Komprimierung, etwa eines Authentifizierungsfehlers. MCP-Definitionen werden standardmäßig bei Bedarf geladen; die Verfügbarkeit von 1M hängt von Modell, Verbindung und Tarif ab. Außerdem geht es um Token-Zählung und Stoppgründe bei direkter API-Nutzung.

Wenn ein MCP-Server in Claude Code nicht verbindet, prüfen Sie Status, Verbindungsart und Issue-Details gemeinsam. failed kann einen stdio-Startfehler, eine HTTP-Kommunikationsstörung oder einen abgelehnten festen Authentifizierungsheader anzeigen. Der Artikel erklärt Connection closed, Umgebungsvariablen und undefinierte Verweise, Projektkonfiguration und Freigabe, den npx-Start unter Windows, Debug-Protokolle und die Prüfung der benötigten Operation nach erneutem Verbinden. Null Werkzeuge sind nicht zwangsläufig ein Fehler; ein eigenständiger Start garantiert keine erfolgreiche MCP-Verbindung.

Plötzlich strömt in Claude Code das Wort „court“ zusammen mit rohen <invoke>/<parameter>-Tags auf den Bildschirm, und der Befehl wird nie ausgeführt. Das ist kein Fehler Ihrer Umgebung, sondern eine modellseitige Störung, bei der Claude das Steuer-Token eines Tool-Aufrufs kaputt generiert. Die Harness lehnt es fail-closed ab, also läuft kein falscher Befehl — heikel wird es erst durch die „Kettenreaktion“ im Verlauf. Dieser Artikel erklärt Mechanismus, Ursachen, Irrtümer und die Lösungen für Nutzer und Entwickler.

Ein ChatGPT- oder Claude-Konto kann auch ohne böse Absicht gesperrt werden, und die Rückkehr mit einem anderen Konto macht es schlimmer. Wir haben mit Stand 4. Oktober 2026 die Bedingungen von OpenAI (ChatGPT, Codex) und Anthropic (Claude, Claude Code) – Terms of Use, Usage Policies, Consumer Terms und Usage Policy – sowie die Hilfecenter vollständig gelesen und erklären: die offiziellen Sperrgründe beider Unternehmen; was man nicht tun sollte, jeweils mit Klausel (Konten teilen, die Oberfläche per Skript steuern, Jailbreaks, Sperren umgehen, Claude per VPN aus nicht unterstützten Ländern, Destillation, Weiterverkauf, massenhafte Kontoerstellung); wie sich Anthropics Formulierung zur Nutzung des Logins eines privaten Abos in anderen Tools zwischen Februar 2026 und heute geändert hat (das Agent SDK selbst zu nutzen ist vorgesehen, Tokens fremden Diensten zu überlassen ist verboten); Warnungen und Prüfungen, die keine Verstöße sind; den Unterschied zwischen dem Besitz mehrerer Konten und ihrer Nutzung (Aktualisierung vom 9. Oktober: OpenAIs offizieller Kontowechsler, Anthropics Grenze für die Telefonverifizierung, warum der manuelle Wechsel nach einem Nutzungslimit eine konkrete Antwort erfordert und wie er sich von Teilen, Weiterverkauf und dem Umgehen einer Sperre unterscheidet); eine Checkliste mit acht Punkten; und die Schritte zum Einspruch (OpenAI: Link in der E-Mail oder openai.com/form/appeal; Anthropic: mit dem gesperrten Konto bei claude.ai anmelden; Warnungen: usersafety@anthropic.com).

Ein riesiges KI-Modell von Grund auf neu zu trainieren ist viel zu teuer, aber man möchte es nur für sich anpassen; LoRA (Low-Rank Adaptation) erfüllt diesen Wunsch, indem es das ursprüngliche Modell einfriert und nur ein winziges Zusatzteil (einen Adapter) trainiert, was die trainierbaren Parameter auf weniger als 1 % des ursprünglichen Modells senkt. LoRA macht Fine-Tuning dramatisch günstiger und schneller und ist in der Bildgenerierung wie Stable Diffusion als kleine Datei, die eine Figur oder einen Stil hinzufügt, enorm beliebt. Dieser Artikel erklärt es mit einer Flicken-Analogie. LoRA ist das Aushängeschild des parametereffizienten Fine-Tunings (PEFT): die riesigen ursprünglichen Gewichte bleiben eingefroren, in jede Schicht wird eine kleine Zusatzmatrix eingefügt und nur diese trainiert (W = W0 + BA, wobei W0 eingefroren ist und BA der kleine hinzugefügte Teil). Es baut auf der Hypothese auf, dass die Anpassung einer KI keine großen Änderungen erfordert (ein niedriger Rang genügt), die die Experimente des Original-Papers stützten (bei Mathematik und Programmierung gibt es Berichte, dass es dem vollständigen Training unterlegen ist). Vorteile: trainierbare Params unter 1 % des Originals (im Original-Paper bei GPT-3 175B etwa ein Zehntausendstel), weniger GPU-Speicher beim Training (dort 1,2 TB → 350 GB), schnelleres und günstigeres Training, keine Inferenz-Latenz nach dem Verschmelzen des Adapters, und die ursprünglichen Fähigkeiten gehen weniger leicht verloren. Die größte Stärke sind austauschbare Adapter: eine gemeinsame Basis behalten und je nach Anwendungsfall kleine LoRA-Dateien sofort tauschen (Support, Unternehmens-Tonfall, eine bestimmte Figur). Viele begegnen LoRA zuerst in der Bildgenerierung, wo Stable-Diffusion-LoRAs, die eine Figur, einen Stil oder ein Motiv gelernt haben, breit geteilt werden (Stil hinzufügen, Figur beibringen, leicht und teilbar). QLoRA kombiniert Quantisierung und trainiert LoRA auf einer 4-bit-Basis; laut Paper lässt sich so ein 65B-Modell, das in 16 Bit vollständig trainiert über 780 GB bräuchte, auf einer 48-GB-GPU feinabstimmen und ein 33B-Modell auf einer 24-GB-Consumer-GPU, mit Ergebnissen gleichwertig zu 16-Bit-Verfahren (ob 33B und 65B mit dem vollständigen Training mithalten, hat das Paper nach eigener Aussage nicht geprüft). Gegenüber dem vollständigen Fine-Tuning (alle Gewichte trainieren) unterscheidet sich LoRA bei den trainierten Gewichten, den Kosten, dem Ergebnis und dem besten Einsatz; für die meisten Arbeiten genügt LoRA. Die Basis behalten, klein würzen. Die Zahlen gelten unter den Versuchsbedingungen des Original-Papers u. a., als Richtwert.

Dass ein riesiges 70B-Modell auf einem einzelnen heimischen PC statt auf einem Rack voller Rechenzentrums-GPUs läuft (was nicht in eine Consumer-GPU passt, übernehmen CPU und Arbeitsspeicher), ermöglicht die Quantisierung, die die numerische Präzision der Gewichte eines Modells senkt, um Größe und Speicher drastisch zu verringern. Während die Modell-Destillation Wissen in ein separates kleineres Modell verlagert, macht die Quantisierung dasselbe Modell leichter. Dieser Artikel erklärt sie mit einer Foto-Kompressions-Analogie. Die Quantisierung ersetzt als FP16/FP32-Dezimalzahlen gespeicherte Gewichte durch INT8 (8-bit) oder INT4 (4-bit) Ganzzahlen und reduziert die Bytes pro Gewicht (FP32=4, INT8=1, INT4=0,5); wie beim Komprimieren eines RAW-Fotos zu JPEG opferst du ein wenig Präzision für eine große Reduktion, und überraschend ist, wie wenig man aufgibt. Beim Speicher nutzt 4-bit etwa ein Viertel von FP16: ein 70B-Modell sinkt von ~140GB auf ~35GB, und ein 8B-Modell bei 4-bit liegt bei ~4.5-5GB und passt in eine Mittelklasse-GPU mit 8GB VRAM für lokale Nutzung (die Demokratisierung der LLMs). Bei der Genauigkeit ist INT8 nahezu verlustfrei und INT4 verschlechtert sich Berichten zufolge unter 4% bei allgemeinen Q&A-/Alltagsaufgaben, doch der Verlust ist bei Mathematik, Code-Generierung und schwierigem Schlussfolgern deutlicher (er zeigt sich als kleiner Anstieg der Perplexität), also wähle die Bit-Breite passend zur Aufgabe. Wichtigste Methoden: GPTQ (Vorreiter für genaues 4-bit), AWQ (schützt die ~1% wichtigsten Gewichte; ob es GPTQ übertrifft, hängt von der Evaluation ab), GGUF (llama.cpp/Ollama-Format, Q2_K-Q8_0, CPU+GPU-Hybrid, für lokal) und QLoRA (4-bit-Basis plus LoRA für Consumer-GPU-Fine-Tuning). Sie unterscheidet sich von Destillation (in ein separates kleines Modell verlagern) und Fine-Tuning (Aufgabenwissen hinzufügen), und die drei werden meist kombiniert (ein destilliertes Modell quantisieren; eine quantisierte Basis fine-tunen). Zum Start ein GGUF-Modell mit Ollama in einem Befehl ausführen, Q4/Q8 nach VRAM wählen und INT4 für Code oder exakte Mathematik vermeiden. Die meisten großen Modelle werden bereits quantisiert ausgeliefert, du lädst sie also einfach herunter und nutzt sie. Behalte die Klugheit, lass nur das Gewicht fallen. Die Zahlen sind aus öffentlichen Materialien zitiert, als Richtwert.

Eine riesige, leistungsstarke KI ist klug, aber schwer und teuer; die Modell-Destillation (Knowledge Distillation) löst dies, indem sie das Wissen eines großen Lehrer-Modells auf ein kleines Schüler-Modell überträgt und so eine lehrernahe Leistung bei deutlich kleinerer Größe und höherer Geschwindigkeit erhält. Dieser Artikel erklärt es anhand einer Lehrer-Schüler-Analogie. Der Schlüssel sind soft labels: Gewöhnliches Training lehrt nur „die Antwort ist Katze“ (hard label), während die Destillation die vollständige Wahrscheinlichkeitsverteilung des Lehrers wie „90 % Katze, 8 % Hund, 2 % Fuchs“ übergibt, deren Grad des Zögerns reiche Informationen enthält; ein temperature-Parameter glättet die Wahrscheinlichkeiten, um feine Beziehungen sichtbar zu machen (reales Beispiel: die 2024 eingeführte API-Funktion von OpenAI, kleinere Modelle auf Ausgaben größerer zu trainieren). Vorteile: schnell und günstig, deutlich kompakter bei lehrernaher Leistung (TinyBERT: 7,5-mal kleiner, über 96,8 %), läuft am Edge, stark bei Spezialisierung. Zwei Ansätze: White-Box (voller Zugriff auf Gewichte und interne Repräsentationen, tiefere Übertragung; für eigene oder OSS-Modelle) und Black-Box (nur Ausgaben/API-Antworten sichtbar; die API eines anderen Unternehmens als Lehrer zu nutzen, kann gegen Bedingungen verstoßen). Sie unterscheidet sich von Quantisierung (Kompression der Gewichtspräzision desselben Modells) und Fine-Tuning (Weitertraining eines bestehenden Modells für eine Aufgabe) – die Destillation überträgt Wissen in ein separates kleines Modell, und die drei sind kombinierbar. Die rechtliche/ToS-Realität war 2026 ein großes Thema: Die Technik ist legitim, aber OpenAI, Anthropic und xAI enthalten Klauseln zur wettbewerbswidrigen Destillation, die es verbieten, Ausgaben zum Bau konkurrierender Modelle zu nutzen, sodass das Destillieren eines Konkurrenten aus einer eingeschränkten API gegen die Bedingungen verstoßen kann. Der Streit OpenAI gegen DeepSeek (OpenAI behauptete, mit DeepSeek verbundene Konten umgingen Beschränkungen, um Ausgaben für die Destillation zu erlangen, während DeepSeeks Bedingungen die Destillation seiner Ausgaben Berichten zufolge erlauben) zeigt, dass die Bewertung davon abhängt, wessen API-Bedingungen gelten, und Claude Fable 5/Mythos 5 leiten als Destillation markierte Anfragen an ein weniger leistungsfähiges Opus-Modell um. Tipps: Verwenden Sie eigene oder lizenzierte OSS-Modelle als Lehrer, prüfen Sie Anti-Destillations-Klauseln vor der Nutzung einer kommerziellen API und beurteilen Sie, ob die Nutzung die „Entwicklung eines konkurrierenden Modells“ darstellt. Klugheit vom großen Modell, Betrieb vom kleinen – aber wen man als Lehrer wählt, ändert das Ergebnis technisch und rechtlich. Zahlen sind aus öffentlichen Materialien zitiert, richtungsweisend.

In „So baust du ein Multi-Agenten-System“ hieß es, jede Übergabe zu instrumentieren, bevor man Agenten hinzufügt; die Technologie, die diese Instrumentierung in der Produktion trägt, ist AI observability. Sie macht sichtbar, was LLMs und Agenten in der Produktion tatsächlich tun (welches Modell mit welchem Prompt, welche Tools und Suchen, was zurückkam und wie lange und wie viel es kostete), damit du bis zur Ursache zurückverfolgen kannst. Der entscheidende Unterschied zum gewöhnlichen App-Monitoring: KI kann 200 OK in 50ms zurückgeben und trotzdem selbstbewusst halluzinieren, sodass die meisten KI-Ausfälle Qualitäts-Ausfälle sind (Halluzination, schwaches Retrieval, unsichere Antworten, unvollständige Aufgaben, schlechte Tool-Nutzung, Regressionen nach Prompt-Änderung) und keine Infrastruktur-Ausfälle. Observability ruht auf drei Säulen: traces (eine Anfrage als Baum aus spans, der LLM-Aufrufe, Tools, Retrieval und Argumentationsketten zeigt; der Star der KI-Beobachtung), metrics (Latenz, Kosten, Tokens, Fehlerrate, Durchsatz) und logs (Detail pro Ereignis). Der Industriestandard OpenTelemetry GenAI-Konventionen erfasst Prompts, Antworten, Token-Verbrauch und Tool-/Agenten-Aufrufe in einem herstellerneutralen Schema, einspeisbar in Datadog/Grafana. Die am häufigsten verwechselte Unterscheidung ist Observability vs. Evaluation (evals): Observability zeigt, was passiert ist (leicht zu messen, kann aber nicht sagen, ob die Antwort korrekt ist), während evals messen, ob die Antwort gut ist (Genauigkeit, groundedness, Sicherheit) und explizite Bewertung erfordern. Da Kosten und Latenz leicht zu messen sind, die Antwortqualität aber nicht, kombinieren Tools von 2026 die trace-Anzeige mit Output-Bewertung und Verschlechterungs-Alarmen. Kennzahlen teilen sich in betriebliche (Kosten, Latenz, Tokens, Fehlerrate) und qualitative (Halluzination, groundedness/faithfulness, am wichtigsten für RAG, Sicherheit, Aufgabenerfüllung), mit Halluzinationserkennung via LLM-as-a-judge, semantischer Ähnlichkeit und groundedness-Scores. Wichtige Tools: LangSmith (LangChain), Langfuse (Open-Source-Self-Host), Arize Phoenix (RAG-Debugging), MLflow (Lebenszyklus), AgentOps (Agenten) und OpenTelemetry (der Standard). Beginne mit dem Erfassen von traces (OpenTelemetry-konform), visualisiere betriebliche Kennzahlen und binde dann evals an, bevor du ausrollst. Für Multi-Agenten-Systeme ist Beobachtung unverzichtbar, da sich Fehler in mehrstufigen Ketten verbergen, die nur in einem vollständigen Session-Trace sichtbar sind. Beobachten plus bewerten macht KI produktionsreif. Abbildungen und Merkmale sind aus öffentlichen Materialien zitiert, als Richtwert.

Die praktische Fortsetzung zu „Was ist ein Multi-Agent-System?“. Die Kernregel: zuerst mit einem einzelnen Agenten bauen und erst nach dem Erreichen einer Grenze minimal erweitern (eine Studie von Google Research fand alle Multi-Agent-Aufbauten bei einer streng sequenziellen Aufgabe um 39–70 % schlechter, und Anthropic berichtet, dass Multi-Agent-Systeme etwa 15-mal so viele Tokens verbrauchen wie ein Chat). Die Grundform ist das supervisor-Muster: Subagenten im Claude Agent SDK, agents as tools im OpenAI Agents SDK. Neben den 5 Schritten (zerlegen, worker definieren, supervisor entwerfen, Übergaben, messen) zeigt der Artikel minimalen Code für beide SDKs nach deren offizieller Dokumentation (ein supervisor mit Rechercheur und Prüfer), wie man die Tools jeder Rolle einschränkt, Obergrenzen auf drei Ebenen (maxTurns, max_turns, Ausgaben), wann ein Handoff besser passt, gute und schlechte Rollenschnitte sowie Fehlschläge, die Anthropic tatsächlich erlebte (50 Subagenten für eine einfache Anfrage, doppelte Recherche), samt Lösungen.

Jetzt, da KI-Agenten alltäglich sind, lautet die nächste Herausforderung, wie man Agenten miteinander kooperieren lässt. Wenn MCP einen Agenten mit seinen Werkzeugen verbindet, verbindet A2A (Agent2Agent) einen Agenten mit einem anderen Agenten — ein offener Standard, mit dem sich KIs auf unterschiedlichen Anbietern und Frameworks finden, kommunizieren und über eine gemeinsame Konvention kooperieren. Google veröffentlichte ihn im April 2025, übergab ihn im Juni an die Linux Foundation, und 2026 erreichte er v1.0. Dieser Einsteiger-Leitfaden erklärt, was A2A ist (mit der Analogie der Umgangsformen einer Geschäftspartnerschaft), warum es nötig ist (spezialisierte Agenten reichen Arbeit weiter — ein Planungs-Agent zu einem Hotelbuchungs-Agent zu einem Bezahl-Agent), wie es sich von MCP unterscheidet (MCP ist vertikal, Agent ↔ Werkzeuge; A2A ist horizontal, Agent ↔ Agent; beide übereinanderzulegen ist das zweischichtige Standard-Setup), wie es funktioniert (eine Agent Card — ein JSON als „Visitenkarte“ unter /.well-known/agent-card.json — dient zum Entdecken der Fähigkeiten, dann trägt ein Task die Anfrage durch Zustände wie working, input-required und completed, und ein Artifact liefert das Ergebnis, alles über HTTP, Server-Sent Events und JSON-RPC 2.0, wobei die Agenten ihre Interna verborgen halten) sowie aktueller Stand und Umsetzung (Stand April 2026: 150+ unterstützende Organisationen, 22.000+ GitHub-Sterne, SDKs in fünf Sprachen — Python, JavaScript, Java, Go, .NET — mit Microsoft, Salesforce, SAP und ServiceNow beteiligt). Die Eselsbrücke: mit Werkzeugen verbinden = MCP, mit Partnern verbinden = A2A.

Sie haben RAG aufgebaut, aber die Suchqualität ist mittelmäßig – genau dann hilft Reranking. Reranking bewertet die grob von der Embedding-Suche (Vektorsuche) gesammelten Kandidaten nach ihrer Relevanz zur Anfrage neu und ordnet sie um, behält nur die besten; dieser eine Schritt kann die Antwortqualität eines RAG-Systems dramatisch verändern. Dieser Einsteigerleitfaden behandelt, was Reranking ist (ein Vergleich von Vorauswahl und finalem Vorstellungsgespräch), warum es nötig ist (die Embedding-Suche vektorisiert Anfrage und Dokumente getrennt und beurteilt die Relevanz daher nur grob, und eine schlechte Reihenfolge senkt die Antwortqualität unmittelbar – Studien zeigen, dass Reranking die Retrieval-Genauigkeit deutlich steigern kann, und das Aufsetzen auf eine hybride Suche ist der Standard 2026), wie zweistufiges Retrieval funktioniert („breit sammeln“ mit schneller Embedding-Suche für Recall, dann „klug eingrenzen“ mit dem Reranker für Precision, dann die besten an das LLM übergeben), warum ein Reranker genauer ist (ein Bi-Encoder vektorisiert Anfrage und Dokument einzeln, ist schnell, aber näherungsweise; ein Cross-Encoder gibt beide gemeinsam ein und liefert einen Relevanzwert von 0–1, genau, aber schwergewichtig – daher sammeln Sie mit dem schnellen Bi-Encoder und grenzen mit dem genauen Cross-Encoder ein) sowie die Modelle und Umsetzung (API-Typ wie Cohere Rerank, Voyage und Jina; Open Source wie BGE reranker, mixedbread und FlashRank; und LLM-basiertes Scoring wie RankLLM – einfach 50–100 abrufen und auf die Top 5 eingrenzen). Das Prinzip: breit sammeln, klug eingrenzen und die Anzahlen mit KI-Evaluierungen abstimmen.