Erfahre, wie Bobs 270.000-Token-Kontextfenster funktioniert, wie jede Kategorie zum Token-Verbrauch beiträgt und welche Best Practices es gibt, um Sitzungen fokussiert und kosteneffizient zu halten.

Kontextfenster-Übersicht

Jede Sitzung in Bob Shell hat ein Kontextfenster – das Token-Budget für diese Unterhaltung. Das Limit beträgt 270.000 Tokens. Alles, was Bob lädt, zählt dazu.

Was das Fenster füllt

Kategorie	Was es enthält
System-Prompt	Bobs zentrale Anweisungen für die Sitzung
Tool-Definitionen	Eingebaute Tool-Schemas und verbundene MCP-Tool-Definitionen
MCP-Tools	Anweisungen und Beschreibungen für Tools, die von verbundenen MCP-Servern bereitgestellt werden
Regeln	Benutzerdefinierte Anweisungen aus Projekt- und Modus-Regeldateien (z. B. `AGENTS.md` oder `.bob/rules-*`)
Skills	Anweisungen aus Skills, die Bob für die Unterhaltung geladen hat
Messages	Deine Prompts, Bobs Antworten und Tool-Aktivitäten in der Unterhaltung. Dies ist das Transkript, das als Tokens gezählt wird.

Befehlsausgabe und Tool-Ergebnisse zählen zu Messages. Dateiinhalte erhalten keine separate Zeile.

Der Token-Bericht enthält zwei Zusammenfassungsfelder:

Für Modellantwort reserviert: Zurückgehaltene Tokens für Bobs nächste Antwort (typischerweise 20,0k).

Verfügbarer Speicherplatz: Verbleibende freie Tokens.

Feste Kategorien verbrauchen Kontext, bevor du überhaupt mit Bob arbeitest. Selbst ein einfaches "Sag kurz Hallo." beläuft sich auf etwa 8,5k Tokens. Der größte Teil davon sind Tool-Definitionen (5,1k), System-Prompt (1,5k), Regeln (830) und Skills (454). Nur 590 befinden sich in Messages.

Bob sendet den gesamten Overhead-Stack bei jedem Prompt neu. Mehr MCP-Server oder geladene Skills erhöhen MCP-Tools, Tool-Definitionen und Skills, bevor du tippst.

Token-Nutzung überwachen

Bob Shell meldet die Token-Nutzung am Ende jedes Austauschs. Die folgende Tabelle zeigt, was jede Kategorie beeinflusst:

Kategorie	Was sie wachsen lässt
System-Prompt	Wird beim Sitzungsstart geladen. Bleibt bei normaler Arbeit konstant.
Tool-Definitionen	Eingebaute Tool-Schemas. Werden beim Sitzungsstart festgelegt. Bleiben bei normaler Arbeit konstant.
MCP-Tools	Verbundene MCP-Server und aktivierte Tools. Wächst, wenn du Server oder Tools hinzufügst, nicht wenn du Prompts sendest.
Regeln	Projekt- und Modus-Regeldateien (z. B. `AGENTS.md`). Werden beim Öffnen der Sitzung festgelegt.
Skills	Skills, die Bob für die Sitzung lädt. Kann zunehmen, wenn Bob einen Skill mitten in der Unterhaltung aktiviert.
Messages	Deine Prompts, Bobs Antworten, Datei-Lesevorgänge, Tool-Ausgaben und Befehlsausgaben. Wächst mit jedem Austausch und mit Repository-Erkundungen.

In einem kurzen Austausch verwenden feste Kategorien oft den Großteil der Gesamtsumme. Wenn du Bob bittest, Dateien zu lesen oder Tools auszuführen, werden Messages normalerweise zur größten Kategorie. Achte auf diesen Wandel.

Verfügbarer Speicherplatz nimmt ab, wenn eine Kategorie wächst. Für Modellantwort reserviert ist für Bobs nächste Antwort zurückgestellt. Es ist kein Teil der verwendeten Gesamtsumme darüber.

Token-Limits

Das harte Limit beträgt 270.000 Tokens pro Sitzung. Bob beginnt mit der Kondensierung, bevor du das Limit erreichst. Die Kondensierung beginnt typischerweise bei etwa 190.000 Tokens Gesamtnutzung.

Automatische Kontext-Kondensierung

Bei der Kondensierungsschwelle:

Bewahrt Bob den aktuellsten und relevantesten Kontext.

Fasst Bob ältere Gesprächssegmente zusammen oder entfernt sie.

Behält Bob kritische System-Anweisungen, Tool-Definitionen, Regeln und Skills bei.

Setzt Bob mit dem kondensierten Kontext fort.

Kondensierung ist verlustbehaftet. Details aus frühen Messages überleben möglicherweise nicht. Starte eine neue Sitzung, 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 Eingabe- als auch Ausgabe-Tokens zählen.

Jede Nachricht sendet den gesamten aktiven Kontext erneut, einschließlich des festen Overheads.

Bob verarbeitet bei jedem Senden erneut, was bereits geladen ist.

Lange Sitzungen mit vielen Messages kosten pro späterem Prompt mehr.

Best Practices

Hinweis:

Das Kontextfenster ist kein Speicher. Es ist Arbeitsspeicher – was Bob bei jedem Schritt verwenden kann. Kontrolliere, was hineinkommt. Setze zurück, wenn die Sitzung mit veralteten Ausgaben gefüllt ist. Prüfe das Ergebnis mit Tests, nicht nur mit Bobs Antwort.

Sitzung und Unterhaltung eingrenzen

Verwende eine Sitzung pro Arbeitsziel und beginne mit einem engen Prompt. Nenne das Ziel, das erwartete Ergebnis und die Einschränkungen, bevor du Bob bittest, das Repository zu erkunden. Nenne Dateien und Funktionen explizit. Vermeide vage Anfragen wie „lies das gesamte Repository" oder „prüfe das Backend". Starte eine neue Sitzung, wenn das Thema wechselt – nicht verwandter Inhalt in Messages verursacht Kosten und kann Bob verwirren.

Stehenden Kontext schlank halten

Feste Kategorien verbrauchen Tokens, bevor du etwas tippst. Um diesen Overhead niedrig zu halten:

Halte benutzerdefinierte Regeln und AGENTS.md kurz – trage dort nur Setup-, Test- und Stil-Befehle ein (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 situative Beweise, die spezifisch für diese Sitzung sind – den Bug, Logs und relevante Dateien. Wiederhole keine stehenden Regeln in jedem Prompt.

Kontext bei Bedarf hinzufügen

Lass Bob gezielte Dateien suchen und lesen, anstatt große Inhaltsblöcke in den Chat-Prompt einzufügen. Verweise auf spezifische Dateipfade und Zeilenbereiche in deinem Prompt und vermeide breite Verzeichnisreferenzen:

✓ Behebe die E-Mail-Validierungslogik in src/utils/validation.ts Zeilen 45-67
✗ Überprüfe alles in src/, tests/ und docs/ und schlage Verbesserungen vor

Arbeite in Phasen – finde wahrscheinliche Dateien, prüfe die relevanten, plane, ändere und validiere. Für breite Repository-Lesevorgänge verwende Subagenten, damit die Sitzung kondensierte Ergebnisse erhält, anstatt dass jeder read_file-Aufruf in Messages landet. Wenn Quellen im Widerspruch stehen, vertraue laufendem Code und Tests gegenüber veralteten Kommentaren oder alten README-Hinweisen.

Weitere Taktiken für große Repositories findest du unter Mit großen Projekten arbeiten.

Zurücksetzen, wenn Messages sich füllt

Im Laufe einer langen Sitzung häufen Messages wiederholte Dateiinhalte, aufgegebene Pläne und veraltete Tool-Ausgaben an. Starte eine neue Sitzung, wenn das Arbeitsziel sich ändert oder wenn die Unterhaltung groß genug ist, um die Qualität zu beeinträchtigen. Behalte Einschränkungen, Beweise und offene Fragen – entferne den Rest.

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

Kontextfenster-Verwaltung