• Nachrichten
  • Managed Agents
  • Admin
Search...
⌘K
Erste Schritte
ÜbersichtSchnellstartPrototyp in der Console erstellen
Agenten definieren
Agenten-EinrichtungToolsMCP-ConnectorBerechtigungsrichtlinienAgent Skills
Agentenumgebung konfigurieren
Cloud-Umgebung einrichtenCloud-Sandbox-Referenz
Arbeit an den Agenten delegieren
Sitzung startenSitzungsvorgängeSitzungs-EreignisstreamWebhooks abonnierenErgebnisse definierenMit Vaults authentifizieren
Agentenkontext verwalten
Auf GitHub zugreifenDateien anhängen und herunterladen
Memory StoresDreams
Erweiterte Orchestrierung
Multi-Agenten-SitzungenGeplante Bereitstellungen
Referenz
Managed-Agents-Referenz
Arbeiten mit Dateien
Files APIPDF-UnterstützungBilder und Vision
Skills
ÜbersichtBest PracticesSkills für Unternehmen
MCP
Remote-MCP-Server
Claude auf Cloud-Plattformen
Claude Platform auf AWS
Log in
Dreams
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...

Solutions

  • AI agents
  • Code modernization
  • Coding
  • Customer support
  • Education
  • Financial services
  • Government
  • Life sciences

Partners

  • Amazon Bedrock
  • Google Cloud's Vertex AI

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Company

  • Anthropic
  • Careers
  • Economic Futures
  • Research
  • News
  • Responsible Scaling Policy
  • Security and compliance
  • Transparency

Learn

  • Blog
  • Courses
  • Use cases
  • Connectors
  • Customer stories
  • Engineering at Anthropic
  • Events
  • Powered by Claude
  • Service partners
  • Startups program

Help and security

  • Availability
  • Status
  • Support
  • Discord

Terms and policies

  • Privacy policy
  • Responsible disclosure policy
  • Terms of service: Commercial
  • Terms of service: Consumer
  • Usage policy
Managed Agents/Persistenten Speicher erstellen

Dreams

Lass Claude über vergangene Sessions reflektieren, um den Speicher eines Agenten zu kuratieren und neue Erkenntnisse zu gewinnen.

Dreaming ist ein Feature in der Forschungsvorschau. Fordere Zugang an, um es auszuprobieren.

Agenten schreiben während ihrer Arbeit in ihre Memory Stores, aber diese Schreibvorgänge sind lokal und inkrementell: Über viele Sessions hinweg sammeln sich in einem Memory Store Duplikate, Widersprüche und veraltete Einträge an.

Dreams ermöglichen es Claude, das aufzuräumen. Ein Dream liest einen bestehenden Memory Store zusammen mit vergangenen Session-Transkripten und erzeugt daraus einen neuen, reorganisierten Memory Store: Duplikate werden zusammengeführt, veraltete oder widersprüchliche Einträge durch den neuesten Wert ersetzt und neue Erkenntnisse herausgearbeitet.

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

Alle Managed Agents API-Anfragen erfordern den Beta-Header managed-agents-2026-04-01. Dreams erfordern zusätzlich den Beta-Header dreaming-2026-04-21. Das SDK setzt diese automatisch.

Funktionsweise

Ein Dream ist ein asynchroner Job, der Folgendes entgegennimmt:

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

Der Dream erzeugt einen weiteren Output-Memory-Store, getrennt vom Input. Die ID des Output-Stores erscheint in den outputs[] des Dreams, sobald dieser den Status running erreicht.

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...

Die Dreaming-Inputs umfassen den bereits bestehenden Memory Store und ein Array von Sessions. Das ausgewählte Modell führt die Dreaming-Pipeline aus; während der Forschungsvorschau werden claude-opus-4-8, claude-opus-4-7 und claude-sonnet-4-6 unterstützt. Optional kannst du instructions übergeben, um den Dreaming-Prozess zu steuern; siehe Mit Instructions 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_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  },
  "error": null
}

Wenn du nur Session-Transkripte und keinen bestehenden Store hast, erstelle zuerst einen leeren Memory Store und übergib ihn als memory_store-Input.

Mit Instructions steuern

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

Verwende instructions für übergeordnete Synthese-Anweisungen wie Schwerpunktbereiche („konzentriere dich auf Coding-Style-Präferenzen"), Inhalte, die unverändert erhalten bleiben sollen, oder Ausgabekonventionen, die du im gesamten Store angewendet haben möchtest. Die Pipeline ist ein Synthese-Durchlauf über die Inputs, kein Editor, der auf den Text des Stores angewendet wird – imperative Anweisungen, die auf bestimmte Zeilen abzielen („ändere Satz X zu Y", „korrigiere die Anzahl in Abschnitt Z"), bewirken daher in der Regel keine Änderung. Um gezielte Änderungen an einzelnen Memories vorzunehmen, verwende die Memory Stores API direkt auf dem Output-Store.

Fortschritt verfolgen

Dreams laufen asynchron und dauern je nach Input-Größe typischerweise Minuten bis zu mehreren zehn Minuten. 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

statusBedeutung
pendingDream erfolgreich erstellt und in die Warteschlange eingereiht.
runningDie Pipeline verarbeitet. usage wird aktualisiert, während die Arbeit voranschreitet.
completedErfolgreich abgeschlossen. Der Wert in outputs[] ist der neue Memory Store.
failedDreaming-Lauf mit einem Fehler beendet. Der Output-Memory-Store bleibt unverändert mit dem, was vor dem Fehler geschrieben wurde.
canceledDreaming-Lauf abgebrochen. Der Output-Memory-Store bleibt unverändert.

Die Pipeline beim Laufen beobachten

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

Die Ausgabe verwenden

Wenn status den Wert completed erreicht, verweist der memory_store-Eintrag in outputs[] auf einen vollständig befüllten Store. Es handelt sich um einen gewöhnlichen Memory Store in deinem Workspace. Überprüfe ihn mit der Memory Stores API oder in der Console, dann entweder:

  • Nutze ihn: Hänge ihn an zukünftige Sessions als memory_store-Ressource anstelle des (oder zusätzlich zum) Input-Memory-Stores an, oder
  • Verwirf ihn: Lösche oder archiviere ihn.
# After the dream ends, the output holds the rebuilt 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 Inputs niemals. Bei failed oder canceled bleibt der Output-Store mit teilweisem Inhalt bestehen, sodass du inspizieren kannst, was vor dem Stopp erzeugt wurde; räume ihn über die Memory Stores API auf, wenn du ihn nicht benötigst.

Während ein Dream pending oder running ist, wird das Archivieren oder Löschen seines Output-Stores mit einem 400 abgelehnt. Das Archivieren oder Löschen eines Input-Stores oder einer Session während des Laufs führt dazu, dass der Dream mit input_memory_store_unavailable oder input_session_unavailable fehlschlägt.

Einen Dream abbrechen

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

Nach dem Abbruch können sich die usage-Felder des Dreams noch einige Sekunden lang aktualisieren, während laufende Arbeit abgeschlossen wird. Frage den Dream ab, bis sich usage stabilisiert, wenn du den endgültigen Wert benötigst.

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

Einen Dream archivieren

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

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

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

Dreams auflisten

Gibt alle nicht archivierten Dreams im Workspace zurück, neueste zuerst. Verwende limit (Standard 20, max. 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

Eine nicht erschöpfende Liste möglicher Dreaming-Fehler findest du unten.

error.typeWann
timeoutDie Pipeline hat ihr Laufzeitbudget überschritten.
internal_errorNicht klassifizierter Pipeline-Fehler.
memory_store_org_limit_exceededDeine Organisation hat ihr Memory-Store-Limit erreicht, während die Pipeline Arbeitsspeicher bereitgestellt hat.
input_memory_store_too_largeDer Input-Memory-Store überschreitet das Größenlimit der Pipeline.
input_memory_store_unavailableDer Input-Memory-Store wurde archiviert oder gelöscht, nachdem der Dream erstellt wurde.
input_session_unavailableEine Input-Session wurde archiviert oder gelöscht, nachdem der Dream erstellt wurde.

Abrechnung

Dreams werden zu den Standard-API-Token-Raten für das von dir ausgewählte Modell abgerechnet; usage auf der Ressource gibt die genauen Summen an. Die Kosten skalieren ungefähr linear mit der Anzahl und Länge der Input-Sessions. Beginne mit einem kleinen Batch von Sessions und skaliere hoch, sobald du mit der Kurationsqualität zufrieden bist.

Limits

LimitWert
Sessions pro Dream100
Länge von instructions4.096 Zeichen
Unterstützte Modelleclaude-opus-4-8, claude-opus-4-7, claude-sonnet-4-6

Standard-Ratenlimits gelten für die Dream-Erstellung, solange dieses Feature in der Beta ist. Kontaktiere den Support, wenn du höhere Limits benötigst.

Was this page helpful?

  • Funktionsweise
  • Einen Dream erstellen
  • Mit Instructions steuern
  • Fortschritt verfolgen
  • Lebenszyklus
  • Die Pipeline beim Laufen beobachten
  • Die Ausgabe verwenden
  • Einen Dream abbrechen
  • Einen Dream archivieren
  • Dreams auflisten
  • Fehler
  • Abrechnung
  • Limits