Kernkonzepte

Context-Window-Verwaltung

Erfahre, wie Bobs context window mit 270.000 tokens funktioniert, wie jede Kategorie zum token-Verbrauch beiträgt und welche Best Practices den Fokus bei tasks erhalten und Kosten senken.

Das context window verstehen

Jeder task im Chat-Panel hat ein context window — das token-Budget für diesen Thread. Das Limit beträgt 270.000 tokens. Alles, was Bob lädt, zählt dagegen.

Was das window füllt

Fahre mit der Maus über den token usage indicator oben rechts im Chat-Panel, um eine Aufschlüsselung anzuzeigen, was dein context window belegt:

Context window breakdown panel showing token usage by category
KategorieWas enthalten ist
System promptBobs Kernanweisungen für die Sitzung
Tool definitionsIntegrierte Tool-Schemas und verbundene MCP-Tool-Definitionen
MCP ToolsAnweisungen und Beschreibungen für Tools verbundener MCP-Server
RulesBenutzerdefinierte Anweisungen aus Projekt- und Modus-Rule-Dateien (z. B. AGENTS.md oder .bob/rules-*)
SkillsAnweisungen aus skills, die Bob für das Gespräch geladen hat
MessagesDeine prompts, Bobs Antworten und Tool-Aktivitäten im Gespräch. Das ist der transcript, der als tokens gezählt wird.

@-Erwähnungen, Befehlsausgaben und Tool-Ergebnisse zählen alle zu Messages. Dateiinhalte erhalten keine eigene Zeile.

Unter Estimated breakdown:

  • Reserved for model response: Tokens, die für Bobs nächste Antwort zurückgehalten werden (typischerweise 20,0k).
  • Available space: Verbleibende freie tokens.

Basis-Overhead

Feste Kategorien verbrauchen context, bevor du überhaupt mit Bob zu arbeiten beginnst. Im Galaxium Travels-Beispielprojekt ergibt selbst "Quickly say hi back." etwa 8,5k tokens. Der Großteil davon entfällt auf Tool definitions (5,1k), System prompt (1,5k), Rules (830) und Skills (454). Nur 590 stecken in Messages.

Bob sendet den vollständigen Overhead-Stack bei jeder Anfrage erneut. Mehr MCP-Server oder geladene skills erhöhen MCP Tools, Tool definitions und Skills, bevor du tippst.

Praktische Zahlen und eine Anleitung zum Zurücksetzen findest du unter Create a new context window.

Token-Verbrauch überwachen

Der token usage indicator zeigt den prozentualen Füllstand sowie ein Verhältnis von genutzt/gesamt gegenüber dem 270.000-token-Limit. Klicke darauf, um die context window breakdown zu öffnen. Überprüfe, welche Kategorie wächst.

Die folgende Tabelle zeigt, was jede Kategorie beeinflusst:

KategorieWas sie wachsen lässt
System promptWird beim Start des tasks geladen. Bleibt während der normalen Arbeit konstant.
Tool definitionsIntegrierte Tool-Schemas. Werden beim Start des tasks festgelegt. Bleiben während der normalen Arbeit konstant.
MCP ToolsVerbundene MCP-Server und aktivierte Tools. Wächst, wenn du Server oder Tools hinzufügst, nicht beim Senden von prompts.
RulesProjekt- und Modus-Rule-Dateien (z. B. AGENTS.md). Werden beim Öffnen des tasks festgelegt.
SkillsSkills, die Bob für den task lädt. Kann sich erhöhen, wenn Bob mid-thread einen skill aktiviert.
MessagesDeine prompts, Bobs Antworten, Dateilesevorgänge, Tool-Ausgaben und @-Erwähnungen. Wächst mit jedem Schritt und bei der Repo-Erkundung.

In einem kurzen Austausch beanspruchen feste Kategorien oft den Großteil des Gesamtvolumens. Wenn du Bob bittest, Dateien zu lesen oder Tools auszuführen, wird Messages in der Regel die größte Kategorie. Achte auf diesen Wechsel.

Available space schrumpft, wenn eine beliebige Kategorie wächst. Reserved for model response ist für Bobs nächste Antwort reserviert. Es ist nicht Teil der darüber angezeigten genutzten Gesamtmenge.

Gemessene Beispiele an einem echten Repo findest du unter Create a new context window.

Token-Limits

Das harte Limit beträgt 270.000 tokens pro task. Bob beginnt zu kondensieren, bevor du das Limit erreichst. Die Kondensierung setzt typischerweise bei etwa 190.000 tokens Gesamtverbrauch ein.

Automatische context condensation

Bei der Kondensierungsschwelle:

  1. Bewahrt Bob den aktuellsten und relevantesten context.
  2. Fasst Bob ältere Gesprächssegmente zusammen oder entfernt sie.
  3. Behält Bob kritische Systemanweisungen, Tool definitions, Rules und Skills bei.
  4. Setzt Bob mit dem kondensierten context fort.

Condensation ist verlustbehaftet. Details aus dem frühen Teil von Messages überleben möglicherweise nicht. Starte einen neuen task mit + (New task), wenn du das Thema wechselst oder wenn Messages groß genug ist, um die Qualität zu beeinträchtigen.

Auswirkungen auf Bobcoins

Bobcoins verfolgen den token-Verbrauch. Sowohl Input- als auch Output-tokens zählen.

  • Jede Nachricht sendet den gesamten aktiven context erneut, einschließlich des festen Overheads.
  • Bob verarbeitet bereits Geladenes bei jedem Senden erneut.
  • Lange Threads mit umfangreichem Messages-Inhalt kosten bei späteren prompts mehr.

Best Practices

Das context window ist kein Speicher. Es ist Arbeitsgedächtnis — was Bob bei jedem Schritt verwenden kann. Steuere, was hineinkommt. Setze zurück oder kondensiere, wenn der Thread mit veraltetem Output gefüllt ist. Überprüfe das Ergebnis mit Tests, nicht nur mit Bobs Antwort.

task und Gespräch eingrenzen

Verwende einen task pro Arbeitsziel und beginne mit einer gezielten Anfrage. Formuliere Ziel, erwartetes Ergebnis und Einschränkungen, bevor du Bob bittest, das Repo zu erkunden. Nenne Dateien und Funktionen explizit. Vermeide vage Anfragen wie „lies das ganze Repo" oder „überprüfe das Backend". Klicke auf + (New task), wenn sich das Thema ändert — nicht verwandter Inhalt in Messages erhöht die Kosten und kann Bob verwirren.

Beständigen context schlank halten

Feste Kategorien verbrauchen tokens, bevor du irgendetwas tippst. Um diesen Overhead gering zu halten:

  • Halte custom rules und AGENTS.md kurz — schreibe dort nur Setup-, Test- und Style-Befehle (z. B. pnpm test, mvn verify).
  • Verbinde nur die MCP-Server, Tools und skills, die die aktuelle Arbeit benötigt. Trenne, was du nicht verwendest, und bevorzuge projektbezogene MCP-Konfiguration gegenüber globaler.
  • Reserviere Messages für situationsbezogene Nachweise, die für diesen task spezifisch sind — den Bug, Logs und relevante Dateien. Wiederhole keine beständigen Rules in jedem prompt.

Context bei Bedarf hinzufügen

Lass Bob gezielte Dateien suchen und lesen, anstatt große Inhaltsblöcke in den Thread einzufügen. Verwende context mentions, um auf eine bestimmte Datei oder einen Zeilenbereich zu verweisen, und vermeide breite Verzeichniserwähnungen:

✓ @/src/utils/validation.ts:45-67 Fix the email validation logic
✗ @/src @/tests @/docs Review everything and suggest improvements

Du kannst auch Text im Editor markieren und Cmd + L (Mac) oder Ctrl + L (Windows/Linux) verwenden, um ihn direkt zum Chat hinzuzufügen.

Arbeite stufenweise — finde wahrscheinliche Dateien, prüfe die relevanten, plane, ändere und validiere. Für breite Repo-Lesevorgänge verwende subagents, damit der task kondensierte Ergebnisse erhält, anstatt jeden read_file-Aufruf in Messages landen zu lassen. Wenn Quellen in Konflikt stehen, vertraue laufendem Code und Tests gegenüber veralteten Kommentaren oder alten README-Notizen.

Weitere Taktiken für große Repos findest du unter Working with large projects.

Zurücksetzen oder kondensieren, wenn Messages sich füllt

Im Laufe eines langen Gesprächs sammelt Messages wiederholte Dateiinhalte, verworfene Pläne und veraltete Tool-Ausgaben an. Starte einen neuen task mit + (New task), wenn sich das Arbeitsziel ändert oder wenn der Thread groß genug ist, um die Qualität zu beeinträchtigen. Behalte Einschränkungen, Nachweise und offene Fragen — entferne den Rest.

Bob kann ältere Segmente auch automatisch kondensieren, aber condensation ist verlustbehaftet und Details aus dem frühen Teil von Messages überleben möglicherweise nicht. Bevorzuge kleine, geprüfte Änderungen gegenüber einem großen autonomen Durchlauf, damit Diffs überprüfbar bleiben und Bob auf Kurs bleibt.

Mehr erfahren

Unter Create a new context window kannst du die Aufschlüsselung im Galaxium Travels-Beispielprojekt öffnen und einen Reset üben.

Wie ist dieses Thema?