Dreams

Agenten schreiben während ihrer Arbeit in ihre „memory stores“ (Gedächtnisspeicher), aber diese Schreibvorgänge sind lokal und inkrementell: Über viele Sitzungen hinweg sammelt ein Memory Store Duplikate, Widersprüche und veraltete Einträge an.

„Dreams“ (Träume) lassen Claude das aufräumen. Ein Dream liest einen bestehenden Memory Store zusammen mit Transkripten vergangener Sitzungen und erzeugt dann einen neuen, reorganisierten Memory Store: Duplikate werden zusammengeführt, veraltete oder widersprochene Einträge durch den neuesten Wert ersetzt und neue Erkenntnisse zutage gefördert.

Der Eingabe-Store wird niemals verändert, sodass du die Ausgabe prüfen und verwerfen kannst, wenn dir das Ergebnis nicht gefällt.

So funktioniert es

Ein Dream ist ein asynchroner Job, der Folgendes entgegennimmt:

• einen bereits bestehenden Memory Store: den Store, den Claude überprüft, dedupliziert und reorganisiert, und
• 1 bis 100 Sitzungen: vergangene Transkripte, die Claude nach Mustern und Erkenntnissen durchsucht, um sie in die Ausgabe einfließen zu lassen.

Der Dream erzeugt einen weiteren Ausgabe-Memory-Store, getrennt von der Eingabe. Die ID des Ausgabe-Stores erscheint in outputs[] des Dreams kurz nachdem der Dream in den Status running wechselt, sobald der Workflow den Eingabe-Store geklont hat; ein Dream im Status running kann kurzzeitig ein leeres outputs[] melden.

Einen Dream erstellen

dream = client.beta.dreams.create(
    inputs=[
        {"type": "memory_store", "memory_store_id": store_id},
        {"type": "sessions", "session_ids": [session_a, session_b]},
    ],
    model="claude-opus-4-8",
    instructions="Focus on coding-style preferences; ignore one-off debugging notes.",
)
print(dream.id)  # drm_01...

Zu den Dreaming-Eingaben gehören der bereits bestehende Memory Store und ein Array von Sitzungen. Das ausgewählte Modell führt die Dreaming-Pipeline aus. Während der Research Preview werden claude-opus-5, claude-fable-5, claude-opus-4-8, claude-opus-4-7, claude-sonnet-5 und claude-sonnet-4-6 unterstützt. Optional kannst du instructions übergeben, um den Dreaming-Prozess zu steuern. Siehe Mit Anweisungen steuern.

Die Antwort ist die vollständige dream-Ressource mit status: "pending":

{
  "type": "dream",
  "id": "drm_01AbCDefGhIjKlMnOpQrStUv",
  "status": "pending",
  "inputs": [
    { "type": "memory_store", "memory_store_id": "memstore_01Hx..." },
    { "type": "sessions", "session_ids": ["sesn_01...", "sesn_02..."] }
  ],
  "outputs": [],
  "model": { "id": "claude-opus-4-8" },
  "instructions": "Focus on coding-style preferences; ignore one-off debugging notes.",
  "session_id": null,
  "created_at": "2026-04-29T17:04:10Z",
  "ended_at": null,
  "archived_at": null,
  "usage": {
    "input_tokens": 0,
    "output_tokens": 0,
    "cache_read_input_tokens": 0,
    "cache_creation_input_tokens": 0
  },
  "error": null
}

Mit Anweisungen steuern

Das optionale Feld instructions steuert, was die Dreaming-Pipeline synthetisiert. Es wird in der gesamten Pipeline angewendet: was genau gelesen werden soll, was zusammengeführt oder verworfen werden soll und wie der Ausgabe-Store strukturiert werden soll.

Verwende instructions für übergeordnete Synthese-Vorgaben wie Schwerpunktbereiche („konzentriere dich auf Präferenzen beim Programmierstil“), unverändert beizubehaltende Inhalte oder Ausgabekonventionen, die im gesamten Store angewendet werden sollen. Die Pipeline ist ein Synthese-Durchlauf über die Eingaben, kein Editor, der auf den Text des Stores angewendet wird. Imperative Anweisungen, die auf bestimmte Zeilen abzielen („ändere Satz X in Y“, „korrigiere die Anzahl in Abschnitt Z“), bewirken daher in der Regel keine Änderung. Um gezielte Änderungen an einzelnen Erinnerungen vorzunehmen, verwende die Memory Stores API direkt auf dem Ausgabe-Store.

Fortschritt verfolgen

Dreams laufen asynchron und dauern typischerweise Minuten bis einige Stunden, abhängig von der Anzahl der Eingabetranskripte. Frage den Dream per ID ab, um den Status zu prüfen:

while dream.status in ("pending", "running"):
    time.sleep(10)
    dream = client.beta.dreams.retrieve(dream.id)
    print(f"status={dream.status} input_tokens={dream.usage.input_tokens}")

Lebenszyklus

Den Pipeline-Lauf beobachten

Sobald ein Dream running ist, verweist sein Feld session_id auf die zugrunde liegende Sitzung, die die Pipeline ausführt. Du kannst die Events dieser Sitzung streamen, um in Echtzeit zu beobachten, was der Dream liest und schreibt. Die Sitzung wird archiviert (nicht gelöscht), wenn der Dream einen Endzustand erreicht, sodass das Transkript danach verfügbar bleibt.

Die Ausgabe verwenden

Wenn status den Wert completed erreicht, verweist der Eintrag memory_store in outputs[] auf einen vollständig befüllten Store. Es ist ein gewöhnlicher Memory Store in deinem Workspace. Prüfe ihn mit der Memory Stores API oder in der Console und dann entweder:

• Nutze ihn: Hänge ihn an zukünftige Sitzungen als memory_store-Ressource anstelle des (oder zusätzlich zum) Eingabe-Memory-Stores an, oder
• Verwirf ihn: Lösche den Memory Store oder archiviere den Memory Store.

# Nach Ende des Dreams enthält die Ausgabe den neu aufgebauten Memory-Store
output_store_id = next(
    output.memory_store_id for output in dream.outputs if output.type == "memory_store"
)

session = client.beta.sessions.create(
    agent=agent_id,
    environment_id=environment_id,
    resources=[
        {"type": "memory_store", "memory_store_id": output_store_id},
    ],
)

Der Dream selbst löscht oder verändert seine Eingaben niemals. Bei failed oder canceled bleibt der Ausgabe-Store mit Teilinhalten bestehen, sodass du prüfen kannst, was vor dem Stopp erzeugt wurde; räume ihn über die Memory Stores API auf, wenn du ihn nicht benötigst.

Einen Dream abbrechen

Abbrechen versetzt einen Dream im Status pending oder running sofort in canceled. Das Abbrechen eines bereits canceled Dreams ist ein idempotenter No-op; das Abbrechen eines Dreams im Status completed oder failed gibt 400 zurück.

client.beta.dreams.cancel(dream.id)

Einen Dream archivieren

Archivieren setzt archived_at bei einem Dream, der einen Endzustand erreicht hat (completed, failed oder canceled); status bleibt unverändert. Archivierte Dreams werden aus Standard-Listenantworten ausgeschlossen, bleiben aber per ID lesbar. Das Archivieren eines bereits archivierten Dreams ist ein idempotenter No-op. Das Archivieren eines Dreams im Status pending oder running gibt 400 zurück; brich ihn zuerst ab. Es gibt kein Dearchivieren.

client.beta.dreams.archive(dream.id)

Das Archivieren eines Dreams berührt seinen Ausgabe-Memory-Store nicht; verwalte diesen separat über die Memory Stores API.

Dreams auflisten

Gibt alle nicht archivierten Dreams im Workspace zurück, die neuesten zuerst. Verwende limit (Standard 20, maximal 100) und den page-Cursor zum Paginieren. Übergib include_archived=true, um archivierte Dreams einzuschließen.

for listed_dream in client.beta.dreams.list(limit=20):
    print(listed_dream.id, listed_dream.status)

Fehler

Es folgt eine nicht abschließende Liste möglicher Dreaming-Fehler.

Abrechnung

Dreams werden zu den Standard-API-Tokenpreisen für das von dir ausgewählte Modell abgerechnet; usage auf der Ressource gibt die genauen Gesamtwerte an. Die Kosten skalieren ungefähr linear mit der Anzahl und Länge der Eingabesitzungen. Beginne mit einem kleinen Stapel von Sitzungen und skaliere hoch, sobald du mit der Kuratierungsqualität zufrieden bist.

Limits

Für die Erstellung von Dreams gelten Standard-Ratenlimits, solange sich diese Funktion in der Research Preview befindet. Kontaktiere den Support, wenn du höhere Limits benötigst.