Fable-5.2-Agent: das Modell wechseln und den Arbeitsstand erhalten

Wenn ein Agent von Fable 5.2 auf ein anderes Modell wechselt, bewahren Sie seinen geprüften Aufgabenstand getrennt vom Gesprächsverlauf auf. Das neue Modell benötigt Eingaben, abgeschlossene Tool-Ergebnisse, offene Arbeit und Abnahmekriterien. Eine lesbare Zusammenfassung dessen, was das vorherige Modell „gedacht hat“, ist kein verlässlicher Ersatz.

Wir testeten dieses Muster am 10. November 2026 über Ofox: Fable 5.2 forderte eine lesende Lagerabfrage an, erhielt drei synthetische Zeilen und schloss seinen nativen Tool-Ablauf ab. Danach begannen wir eine neue Opus-5.5-Konversation mit einem von der Anwendung erzeugten Checkpoint. Das endgültige JSON bestand unabhängige Prüfungen für jede SKU und Menge. Dies belegt einen kleinen Ablauf zur Zustandsübergabe, keinen stundenlangen Agent-Benchmark und keine Erhaltung verborgenen Reasonings.

Warum auch ein erfolgreicher Fallback nützlichen Zustand verlieren kann

Die offizielle Dokumentation zu erhaltenem Thinking unterscheidet Modellkompatibilität von Anwendungsfortschritt. Auf den dokumentierten Wegen über die Claude API und Google-verwaltete Angebote können ältere Modelle keine Thinking-Blöcke von Fable 5.2 lesen; nicht unterstützte Blöcke können entfallen, obwohl die Anfrage erfolgreich ist. Die Kontobindung bildet eine weitere Grenze, wenn die Fortsetzung über ein anderes Konto läuft.

Diese Regeln machen nicht jeden Modellwechsel zum Fehler. Sie bedeuten, dass HTTP-Erfolg allein keine Kontinuität des Reasonings belegt. Der Ofox-Katalog nennt Routing-Fähigkeiten, beweist aber nicht das Verhalten jeder Übergabe signierter Historie zwischen Anbietern oder Konten. Kontenübergreifendes Wiederabspielen haben wir nicht getestet; unsere Übergabe ist bewusst nicht darauf angewiesen.

Es gibt zwei unterschiedliche Strategien: eine unveränderte Konversation auf einer kompatiblen, geprüften Route fortsetzen, wenn deren Historie erhalten bleiben soll; oder beim bewussten Wechsel von Modellen, Tools oder Aufgabenkonfiguration mit anwendungseigenem Zustand neu beginnen. Diese Anleitung setzt die zweite Strategie um. Sie verändert keine Signaturen und rekonstruiert kein privates Thinking.

Das kleine reproduzierbare Beispiel herunterladen

Laden Sie checkpoint_demo.py herunter. Es benötigt Python ab Version 3.9 und nur die Standardbibliothek. Seine Standardprüfungen tätigen keine API-Aufrufe. Legen Sie es in einen leeren Ordner, damit erzeugte Dateien keine bestehende Aufgabe überschreiben.

Für die vollständige Folge Fable-Tool-Anfrage → Fortsetzung mit Tool-Ergebnis → neue Opus-Sitzung laden Sie zusätzlich run_handoff.py in denselben Ordner. python3 run_handoff.py führt nur lokale Prüfungen aus. Nach Setzen von OFOX_API_KEY löst python3 run_handoff.py --live ausdrücklich bis zu drei kostenpflichtige Anfragen aus, speichert Anfrage- und Antwortdateien in einem neuen Ordner handoff-run und validiert das Endergebnis. Es wiederholt Anfragen nicht automatisch und verweigert die Wiederverwendung dieses Ausgabeordners. Prüfen Sie fehlgeschlagene oder unklare Versuche, bevor Sie einen neuen Lauf anlegen.

Jede Anfrage ist auf 4.096 Ausgabe-Token und einen kleinen synthetischen Body begrenzt. Diese Grenzen beschränken die Demonstration. Sie sind weder ein allgemeines Kostenlimit in Dollar noch eine Garantie, dass eine Anfrage mit Timeout kostenlos war. Das veröffentlichte Programm folgt der getesteten Anfragereihenfolge; seine lokalen Prüfungen und die Serialisierung wurden separat verifiziert.

python3 checkpoint_demo.py self-test
python3 checkpoint_demo.py prepare

Der erste Befehl führt positive und negative Prüfungen aus. Der zweite erzeugt checkpoint.json und handoff.txt und ersetzt keine vorhandenen Dateien. Die Daten bilden einen synthetischen Lagerbestand ab, keine Kundendaten und keine Geschäftsempfehlung:

Die Aufgabe lautet, für jede Zeile max(target − available, 0) anzugeben. Bestellungen sind ausdrücklich verboten. Auch die Zeile ohne Fehlbestand muss erhalten bleiben: Eine Antwort nur mit nachzubestellenden Produkten wäre hier unvollständig.

Belege speichern, bevor ein anderes Modell weiterarbeitet

Der Checkpoint speichert Ziel, Hash der Quellzeilen, eine abgeschlossene Leseoperation, deren tatsächliches Ergebnis und Hash, offene Arbeit sowie das Verbot externer Schreibvorgänge. Die Anwendung erstellt diesen Datensatz aus dem Tool-Ergebnis. Sie bittet nicht das Modell, die eigenen Aktionen zu bestätigen.

{
  "schema_version": 1,
  "task_id": "synthetic-stock-20261110",
  "objective": "Report shortage=max(target-available,0) for every SKU. Do not place orders.",
  "completed": [{
    "operation_id": "read-stock-1",
    "operation": "read_stock",
    "status": "verified"
  }],
  "pending": ["Produce all three SKU shortage rows", "Pass independent validator"],
  "side_effects": []
}

Dieser Ausschnitt lässt zur besseren Lesbarkeit Quell-Hashes und Ergebniszeilen weg; die erzeugte Datei enthält sie. Verwenden Sie für die Ausführung die vollständige Datei. Ein Hash erkennt Abweichungen von einer Quelle, der Sie vertrauen. Er belegt nicht deren Urheber, die Aktualität des Bestands oder die Sicherheit eines nicht vertrauenswürdigen Checkpoints. Bewahren Sie in Produktion auch die maßgebliche Eingabeversion und Zugriffskontrollen auf.

Speichern Sie den Checkpoint bei einem realen Agent dauerhaft an der Grenze einer abgeschlossenen Tool-Operation. Erfassen Sie die Tool-Aufruf-ID für die Zuordnung im Gespräch und eine eigene stabile Operations-ID für das Anwendungsprotokoll. Beide haben unterschiedliche Zwecke. Ein neues Modell kann für dieselbe logische Operation eine andere Tool-Aufruf-ID erzeugen. Eine Anbieter-ID allein verhindert daher nicht allgemein doppelte Aktionen.

Der getestete Fable-Tool-Ablauf

Unsere erste Anfrage verwendete anthropic/claude-fable-5.2, den nativen Ofox-Messages-Endpunkt, output_config.effort: "low", max_tokens: 4096 und ein einzelnes read_stock-Tool mit einem Eingabeschema für ein leeres Objekt. Die Tool-Auswahl stand auf auto.

Die Antwort endete mit tool_use und forderte read_stock mit {} an. Unser Programm prüfte Name und Argumente, lieferte die drei Testzeilen unter der passenden tool_use_id zurück und bewahrte den gesamten Assistenteninhalt auf. Die zweite Fable-Anfrage endete mit end_turn und meldete Fehlbestände von 3, 0 und 4.

Diese native Fortsetzung ist wichtig: Ein Checkpoint entschuldigt keine defekte Tool-Schleife. Scheitert die Anfrage an dasselbe Modell an einer nicht zugeordneten ID, reparieren Sie zuerst die Tool-Ergebniszuordnung, englische Anleitung. Nennt der Fehler signierte Historie, helfen die englische Thinking-Signaturdiagnose und die 5.2-Upgrade-Prüfungen.

Für diese winzige Rechenaufgabe verwendeten wir bewusst niedrigen Effort. Daraus lässt sich nicht der nötige Aufwand einer schwierigen Langzeitaufgabe ableiten. Auch ein aws_bedrock-Eintrag im Katalog beweist kein bestimmtes Upstream-Konto für eine konkrete Antwort; dokumentiert sind unser nativer Ofox-Endpunkt und die zurückgegebene Modell-ID.

Das nächste Modell mit einer expliziten Übergabe starten

Die erzeugte Datei handoff.txt enthält:

Resume this read-only task from verified application state.
Do not claim access to prior reasoning.
Do not call tools or place orders.
Return only a JSON object with key rows, containing every SKU
and integer shortage. No Markdown.
Checkpoint: [the complete generated checkpoint JSON]

Erstellen Sie die Anfrage an das empfangende Modell aus dieser Datei. Die Ausführung dieses Beispiels verbraucht API-Guthaben; die oben genannten lokalen Vorbereitungsbefehle tun das nicht.

import json
from pathlib import Path

request = {
    "model": "anthropic/claude-opus-5.5",
    "max_tokens": 4096,
    "output_config": {"effort": "low"},
    "messages": [{"role": "user", "content": Path("handoff.txt").read_text()}],
}
Path("handoff-request.json").write_text(json.dumps(request))

curl --fail-with-body --max-time 180 \
  https://api.ofox.ai/anthropic/v1/messages \
  -H "x-api-key: $OFOX_API_KEY" \
  -H 'anthropic-version: 2023-06-01' \
  -H 'content-type: application/json' \
  --data-binary @handoff-request.json > handoff-response.json

Die Anfrage enthält weder vorherige Assistentennachrichten noch signierte Thinking-Blöcke. Sie setzt die Aufgabe fort, nicht dieselbe Konversation beim Anbieter. Deshalb muss für diesen Modellwechsel kein altes Präfix bearbeitet werden. Eine größere Aufgabe benötigt entsprechend mehr Belege mit Quellenstellen und offenen Fragen statt eines übergroßen, ungeprüften Berichts.

Das gelieferte Ergebnis unabhängig prüfen

Extrahieren Sie ausschließlich abgeschlossene Textausgabe, parsen Sie sie als JSON und führen Sie den mitgelieferten Validator aus:

import json
from pathlib import Path

r = json.loads(Path("handoff-response.json").read_text())
if r.get("stop_reason") != "end_turn":
    raise SystemExit("Incomplete response; inspect before accepting.")
text = "\n".join(b["text"] for b in r.get("content", []) if b.get("type") == "text")
result = json.loads(text)  # Reject prose and Markdown instead of guessing.
Path("result.json").write_text(json.dumps(result, indent=2))

python3 checkpoint_demo.py validate result.json

Unsere tatsächliche Opus-Antwort ließ sich so parsen:

{"rows":[{"sku":"DEMO-001","shortage":3},{"sku":"DEMO-002","shortage":0},{"sku":"DEMO-003","shortage":4}]}

Der Validator akzeptierte drei Zeilen mit einem Gesamtfehlbestand von 7. Er prüft exakte SKU-Abdeckung, doppelte IDs, Ganzzahltypen und jede neu berechnete Menge. Er lehnt Strings wie "3", boolesche Werte, fehlende oder zusätzliche SKUs und falsche Mengen ab. Der Checkpoint-Prüfer weist separat veränderte Quell-/Ergebnis-Hashes, ungeprüfte Leseoperationen und unerwartete Seiteneffekte zurück.

Für diese Aufgabe sind solche deterministischen Prüfungen stärkere Belege als die Frage an eines der Modelle: „Bist du sicher, dass die Antwort vollständig ist?“ Sie sind dennoch bewusst eng gefasst: Das Skript validiert keinen beliebigen Geschäftsprozess, ruft keine aktuellen Lagerbestände ab und bietet kein produktives Transaktionssystem.

Was der Lauf belegt und was nicht

Alle drei meldeten null Token für Cache-Lesen und Cache-Erstellung. Mit den geprüften Standardlistenpreisen ergeben sich $0.022008 für die drei Anfragen: einzeln $0.004816, $0.014024 und $0.003168. Das ist eine verbrauchsbasierte Berechnung, keine separat abgeglichene Rechnung. Der Vergleichsartikel erklärt die Tarife und weshalb ein so kleiner Test keine Modellrangliste liefert.

Wir lösten keinen realen Dienstausfall aus, testeten kein kontenübergreifendes Wiederabspielen von Thinking, verglichen keine große Aufgabenmenge und bewiesen keine zuverlässige automatische Ausweichlogik. Die Quelldaten waren synthetisch, das lesende Tool lief lokal und es wurden keine Bestellungen versendet. Die Modellantworten selbst waren echte API-Antworten.

Englischsprachiger Screenshot unseres lokal dargestellten Testprotokolls mit Daten aus echten API-Antworten. Er zeigt keine Ofox-Produktoberfläche.

Unterbrechungen bei Schreibvorgängen anders behandeln

Bei einer lesenden Operation kann eine erneute Abfrage vertretbar sein, wenn Aktualität und Kosten berücksichtigt werden. Bei einer Schreiboperation lässt ein Timeout eine heiklere Frage offen: Hat das externe System die Aktion abgeschlossen, bevor der Client die Antwort verlor?

Ein produktives Operationsprotokoll sollte geplante, laufende, bestätigte, fehlgeschlagene und unklare Vorgänge unterscheiden. Fragen Sie nach einem Timeout das Zielsystem mit Ihrem stabilen Operationsschlüssel ab, bevor Sie erneut ausführen. Unterstützt das Ziel einen Idempotenzschlüssel, verwenden Sie ihn und speichern die Antwort. Andernfalls lässt sich exakt einmalige Zustellung nicht allein durch eine lokale JSON-Datei herstellen.

Markieren Sie eine unklare Schreiboperation nicht als abgeschlossen, weil eine Modellzusammenfassung es behauptet. Lassen Sie das neue Modell sie nicht „zur Sicherheit“ wiederholen. Setzen Sie anhand bestätigter Ergebnisse fort und geben Sie ungeklärte Vorgänge in einen Abgleich. Das Muster gilt auch für abgesendete Formulare, angelegte Tickets, ausgehende E-Mails und Zahlungen; jedes Ziel benötigt jedoch eigene Kontrollen.

Den Checkpoint auf das Ergebnis abstimmen

Für einen Recherchebericht übergeben Sie Quell-URL, abgerufene Belege, Status jeder Aussage und offene Fragen. Bei Tabellen sind es Eingabeversionen, Zeilenkennungen, Transformationsregeln und Ausgabeprüfungen. Bei Codeänderungen gehören Commit oder Diff, tatsächlich ausgeführte Tests, Fehler und offene Arbeit dazu. Bewahren Sie Belege abgeschlossener Arbeit auf, nicht nur einen Fortschrittsprozentsatz.

Beginnen Sie mit einer kleinen Migration: eine lesende Aufgabe, ein Modellwechsel und ein unabhängiges Abnahmekriterium. Erweitern Sie erst, wenn die Fehlerfälle verstanden sind. Der API-Leitfaden behandelt die erste Verbindung; Ofox native Messages und Anbieter-Routing beschreiben die Schnittstellen. Die Kontinuität des Aufgabenstands bleibt Verantwortung der Anwendung, auch wenn die nächste Anfrage erfolgreich ist.