Nicht mitnehmbare Sessions: Neue Abhängigkeiten durch Inference-APIs

• Inference-APIs verstecken verschlüsselte Inferenz·Suchergebnisse·komprimierten Zustand·Subagenten-Nachrichten innerhalb des Anbieters, sodass der Gesprächsverlauf im Besitz des Nutzers keine vollständige Session mehr ist, sondern nur eine teilweise sichtbare Kopie
• Session-Portabilität bedeutet nicht, mit einem anderen Modell dieselbe Ausgabe zu reproduzieren, sondern einen semantisch vollständigen Verlauf zu besitzen, den man ohne ID-Nachschlagen oder Entschlüsselung beim bisherigen Anbieter prüfen·exportieren·wiedergeben·auditieren·löschen kann
• Gespeicherte Responses und private Inferenz bei OpenAI, Anthropic und Google, gehostete Suche und intransparente Komprimierung erhöhen die Kontinuität innerhalb desselben Ökosystems, häufen aber zugleich anbieter-versiegelten Zustand an, den andere Anbieter nicht übernehmen können
• In Multi-Agent-Systemen werden sogar Delegationsinhalte und Nachrichten zwischen Agenten verschlüsselt; zusammen mit automatischer Komprimierung und versteckten Anweisungen wird es schwierig zu auditieren, welche Aufgaben angewiesen wurden, selbst wenn falsche Dateibearbeitungen oder Geheimnislecks auftreten
• Portable APIs sollten lokale Event-Logs als Referenzprotokoll verwenden und Speicherung zu einer expliziten Entscheidung machen sowie einen vollständig lesbaren Verlauf von Suche, Komprimierung, Agentenkommunikation und Artefakten samt Distillation unter Nutzerkontrolle erlauben

---

Wie Inference-APIs den Besitz von Sessions verändern

• Das Versprechen früher Inference-APIs war: Eingaben senden, Ausgaben erhalten und beide Seiten speichern — dann konnte man Gespräche prüfen, archivieren, wiedergeben oder an ein anderes Modell übergeben
• Diese Abstraktion war von Anfang an nicht vollständig
  • Prompt Caching existiert auf den GPUs des Anbieters
  • Tokenisierung unterscheidet sich zwischen Modellen, und auch Sampling ist absichtlich nicht reproduzierbar
• Trotzdem konnte der semantische Verlauf mit Anweisungen, Nachrichten, Tool-Aufrufen und Ergebnissen dem Nutzer gehören, und ein anderes hinreichend leistungsfähiges Modell konnte bestehende Arbeit verstehen und fortführen
• Neuere APIs liefern neben Text auch anbieterspezifischen Zustand zurück
  • Inferenz-Tokens, für die abgerechnet wird, die aber nur als intransparenter Ciphertext oder eingeschränkte Zusammenfassung zurückkommen
  • Websuche, bei der der Client den Originaltext nicht erhält, den das Modell gesehen hat
  • Komprimierter Kontext, den nur der ursprüngliche Anbieter entschlüsseln kann
  • Subagenten-Anweisungen und -Nachrichten, die in der Anwendung nicht sichtbar sind
  • Verweise auf Dateien, Vektor-Stores, Container und Caches, die in anderen Umgebungen nicht interpretierbar sind
  • Response- und Gesprächszustände, auf die nur per ID zugegriffen wird und die auf den Servern des Anbieters gespeichert sind
• Für jedes einzelne davon gibt es Gründe in Bezug auf Nutzerkomfort oder Qualität, doch zusammengenommen wird das lokale Log nicht zur gesamten Session, sondern zu einer Teilansicht einer Session, deren Betriebszustand der Anbieter besitzt

Fünf Kriterien zur Beurteilung von Session-Portabilität

• Portabel bedeutet nicht, dass beim Modellwechsel das nächste Token identisch sein muss
  • Modelle unterscheiden sich in Fähigkeiten, antrainierten Tendenzen, Kontextfenstern und Tool-Nutzung, und auch Ausgaben selbst sind nicht deterministisch
• Ein exportierter Verlauf muss genug verständliche Information enthalten, damit ein neues Modell die Arbeit fortsetzen kann, ohne dass der vorherige Anbieter IDs nachschlagen, Ciphertext entschlüsseln oder Suchergebnisse und Zusammenfassungen rekonstruieren muss
• Prüfung (Inspection): Nutzer müssen sehen können, welche Informationen das Modell gesehen hat, was Tools getan haben und was Agenten untereinander ausgetauscht haben
• Export (Export): Abgesehen von separat herunterladbaren Artefakten muss die Session selbst vollständig sein
• Wiedergabe (Replay): Eine andere Implementierung muss semantisch äquivalenten Kontext rekonstruieren können
• Audit (Audit): Menschen müssen im Nachhinein erklären können, warum das System ein bestimmtes Verhalten gezeigt hat
• Löschung (Deletion): Alle serverseitigen Kopien, von denen die Session abhängt, müssen identifizierbar und entfernbar sein
• Eine Response-ID als Schlüssel zu Serverdaten ist kein Gesprächsverlauf, und Ciphertext, den der Nutzer nicht entschlüsseln kann, steht nicht unter Nutzerkontrolle
• Eine Liste zitierter URLs kann nicht die Belegtexte ersetzen, die bei der Suche tatsächlich in den Modellkontext eingeflossen sind

Verschlüsselung, die der Nutzer nicht öffnen kann

• Der Name encrypted_content klingt wie ein nutzerkontrolliertes Datenschutz-Feature, ist aber in der Regel eine Kapsel, die der Client nicht lesen kann und nur der Anbieter öffnen kann
• Da der Anbieter die Schlüssel wählt, für seine eigenen Modelle entschlüsselt und festlegt, in welcher Umgebung Wiedergabe möglich ist, wäre die genauere Bezeichnung anbieter-versiegelter Zustand (provider-sealed state)
• Anbieter-Versiegelung kann reale Datenschutzvorteile bieten
  • OpenAI gibt bei store: false verschlüsselte Inferenz an den Client zurück und kann sie bei der nächsten Anfrage im Speicher entschlüsseln, ohne Zwischenzustand zu speichern
  • Gerade für Zero-Data-Retention-Kunden ist das besser als ein Ansatz, der serverseitige Gesprächsspeicherung verlangt
• Diese Verschlüsselung verbirgt Daten jedoch nicht vor dem Inferenz-Anbieter, sondern nur vor dem Nutzer

Wie gespeicherte Gespräche den Verlauf in einen Pointer verwandeln

• Die OpenAI Responses API speichert Responses standardmäßig und bewahrt laut Dokumentation Response-Objekte mindestens 30 Tage auf
• Mit store: false werden Daten nicht auf OpenAI-Servern gespeichert, was näher an der bisherigen Completions-Arbeitsweise liegt
• Auch bei der Gemini Interactions API ist store: true der Standardwert
  • Bezahlte Stufen bewahren Interaktionen 55 Tage auf
  • Kostenlose Stufen bewahren sie 1 Tag auf
• Serverspeicherung reduziert die Datenmenge, die Anwendungen senden müssen, erhält versteckte Inferenz- und Tool-Zustände und erleichtert Cache-Routing
• Wenn eine lokale Anwendung aber nur Nutzernachrichten und finalen Text protokolliert, wird die Response-ID in previousResponseId zum Fremdschlüssel einer externen Datenbank, die sie nicht kontrolliert

Nicht offengelegte Inferenzprotokolle

• Führende AI-Labore sehen Gründe, rohe Gedankengänge (chain of thought) nicht offenzulegen, und legen Inferenz-Tokens von Modellen mit privaten Weights über APIs üblicherweise nicht offen
• Bei OpenAI kann frühere Inferenz gespeicherter Responses über previous_response_id wiederhergestellt werden
  • Bei store: false muss der Client encrypted_content speichern und bei der nächsten Anfrage erneut mitsenden
  • Auch wenn reasoning.context: "all_turns" für spätere Generierung genutzt werden kann, bleibt die gespeicherte Inferenz intransparent
• Anthropic gibt vollständig verschlüsseltes Thinking im Feld signature zurück
  • Aktivierbarer lesbarer Thinking-Text ist nicht der rohe Gedankengang, sondern eine von einem anderen Modell erzeugte Zusammenfassung
  • In Tool-Use-Turns müssen Thinking-Blöcke unverändert zurückgegeben werden
  • Thinking-Blöcke sind an das Modell gebunden, das sie erzeugt hat, und müssen beim Modellwechsel entfernt werden — also ist Portabilität nicht einmal innerhalb von Anthropic das Ziel
• Diese Ansätze schaffen Kontinuität innerhalb desselben Ökosystems, aber keinen portablen Gesprächsverlauf, den Modelle anderer Anbieter interpretieren können

Die Lücken im Verlauf bei gehosteter Suche

• Clientseitige Such-Tools können Query, Suchzeitpunkt, Ergebnis-URLs und Titel sowie extrahierte Passagen protokollieren
  • Nutzer können Ranking und Passagen prüfen, Seiten erneut abrufen oder Kopien speichern, um einem anderen Modell dieselben Belege zu geben
• Bei gehosteter Suche führt der Anbieter eine private Tool-Schleife aus
  • OpenAI, Google und Anthropic liefern Suchverhalten, Zitate und optionale Quell-URLs, aber nicht den vollständigen Textkontext, der für die Antwortgenerierung genutzt wurde
  • URL-Inhalte können sich ändern, und dem Modell wurden womöglich nur kürzere Passagen übergeben, daher ist dies kein stabiles Wiedergabeprotokoll
• Selbst wenn das nächste Modell bestimmte Quellen vergleichen oder strittige Zahlen neu verifizieren will, erhält es weder Ranking der Ergebnisse noch extrahierte Passagen, gefiltertes Material oder die exakten Belege, die das vorherige Modell gesehen hat
• Selbst wenn zitierte Seiten erneut abgerufen werden, lassen sich die damals verwendeten Daten nicht exakt reproduzieren; dadurch bleibt der vorherige Anbieter als Teil der Session bestehen, auch nachdem die nächste Anfrage woandershin gewechselt ist
• Gehostete Suche braucht einen Export in voller Genauigkeit mit Query, Ergebnis-Metadaten, Suchpassagen, Zeitstempeln und konservierten Inhalten; knappe Zitate dürfen nicht das einzige Protokoll sein

Intransparente Kontextkomprimierung

• Lange Agenten-Sessions brauchen Komprimierung, und lesbare, clientkontrollierte Zusammenfassungen sind auch mit Informationsverlust prüfbar, editierbar und übertragbar
• Die serverseitige Komprimierung von OpenAI gibt verschlüsselte Compaction-Elemente zurück, die nicht für menschliche Interpretation gedacht sind
  • /responses/compact liefert ein canonical next context window, das der Client unverändert wieder mitsenden muss
  • OpenAI kann die komprimierte Bedeutung fortführen, andere Anbieter bekommen aber nur Ciphertext und einen Teil des jüngeren Kontexts
• Intransparente Komprimierung ist technisch nicht unvermeidlich
  • Die serverseitige Komprimierung von Anthropic gibt compaction-Blöcke mit lesbarem content-Feld zurück
  • Der Client kann benutzerdefinierte Summary-Anweisungen mitgeben und das Ergebnis prüfen oder an ein anderes Modell weiterreichen
  • Bei allen Anbietern ist auch clientseitige Komprimierung möglich
• OpenAIs versiegelte Artefakte können modellspezifischen Zustand besser bewahren als allgemeine Zusammenfassungen und dadurch auf dem ursprünglichen Modell höhere Leistung liefern, sollten aber als optionale Optimierung angeboten werden und zusätzlich eine lesbare Übergabe-Zusammenfassung bereitstellen

Versteckte Delegation und Kommunikation in Multi-Agent-Systemen

• In Multi-Agent-Systemen existiert nicht ein einzelner Verlauf, sondern ein Session-Baum und ein Fluss von Nachrichten zwischen Agenten, wodurch das Portabilitätsproblem größer wird
• Die OpenAI Responses Multi-agent Beta ergänzt die Einträge multi_agent_call, multi_agent_call_output und agent_message
  • Im spawn_agent-Beispiel ist das Argument message verschlüsselt
  • Nachrichten zwischen Agenten enthalten nur encrypted_content
  • Wenn Multi-agent aktiviert ist, wird auf alle Agenten serverseitige automatische Komprimierung angewendet, auch ohne Anforderung des Clients
  • Reasoning-Summaries werden nicht unterstützt, und Root- sowie Subagent-Anweisungen, die Entwickler weder bearbeiten noch entfernen können, werden ebenfalls injiziert
• Das Ergebnis ist, dass versiegelte Delegation und Nachrichten, individuell automatisch komprimierter Kontext, versteckte Inferenz und vom Anbieter gehostete Orchestrierung zusammen ein nicht übertragbares Zustandsbündel bilden
• Im Juni 2026 wurde im Open-Source-Codex-Client die Änderung Encrypt multi-agent v2 message payloads übernommen
  • Die Responses API verschlüsselt die Tool-Argumente des Parent-Modells
  • Wenn Codex den Ciphertext weitergibt, entschlüsselt die API ihn intern für das Child-Modell
  • InterAgentCommunication.content in Codex ist leer, sodass die exakten Arbeitsanweisungen nicht in lesbaren Ausführungslogs und Verläufen verbleiben
• Wenn ein Child-Agent die falsche Datei ändert, ein Geheimnis leakt, Arbeit dupliziert oder falschen Annahmen folgt, können Nutzer trotzdem nicht prüfen, was genau angewiesen wurde
• Das öffentliche Codex-Issue fordert, zusätzlich zur verschlüsselten Weitergabe eine lesbare Audit-Kopie zu erhalten
  • Das ist ein Mindestdesign; Klartext-Nachrichten zwischen Agenten sollten der Standard sein

Warum die Freiheit, Sessions zu verlagern, nötig ist

• Selbst wenn die meisten Nutzer nicht mitten in einer Session das Modell wechseln, verändert die Möglichkeit zur Migration das Verhältnis zwischen Nutzer und Anbieter
• Situationen, in denen Session-Migration nötig ist, umfassen Modellstilllegung, Serviceausfälle, Preisänderungen, Richtlinien, die die nächste Anfrage blockieren, lokale Ausführung in vertraulichen Phasen und nachträgliche Rekonstruktion durch Auditoren
• Da Agenten Sessions verlängern, sammeln Coding- und Research-Sessions Entscheidungen und Belege über Tage hinweg an, und persönliche Assistenten können Protokolle über Jahre aufbauen
• Wenn Nutzer woanders weitermachen können, müssen Anbieter über Modellqualität, Preis, Zuverlässigkeit und Vertrauen konkurrieren
• Wenn nur ein Anbieter den akkumulierten Kontext interpretieren kann, entsteht eine nachteilige Anreizstruktur, die das Weggehen der Nutzer erschwert

Prinzipien einer portablen Inference-API

• Das lokale Event-Log sollte das Referenzprotokoll sein
  • Serverspeicherung kann dies replizieren oder beschleunigen, aber der Client muss die Session ohne Nachschlagen von Server-IDs rekonstruieren können
• Speicherung sollte eine explizite Entscheidung sein
  • store: false sollte leicht nutzbar und dokumentiert sein und möglichst der Standardwert
  • Funktionen, die Aufbewahrung benötigen, sollten dies zum Zeitpunkt ihrer Nutzung offenlegen

• Intransparente Elemente dürfen die Bedeutung nicht monopolisieren

  • Verschlüsselte Inferenz, Komprimierung und Tool-Signaturen können zur Qualitätssteigerung beim selben Anbieter enthalten sein, aber es muss zusätzlich eine lesbare, anbieterneutrale Übergabedarstellung geben
  • Gehostete Tools müssen Logs in voller Genauigkeit hinterlassen
    • Exakte Ein- und Ausgaben, Belege, Filterung, Quellen, Zeitstempel und Content-Hashes müssen protokolliert werden
  • Subagenten-Kommunikation muss auditierbar sein
    • Exakte Aufgaben, Nachrichten, Ergebnisse, Herkunftslinie, Modell und Tool-Berechtigungen jedes Agenten müssen lesbar erhalten bleiben
  • Komprimierung muss prüfbar sein
    • Es müssen lesbare Zusammenfassungen, die dafür verwendeten Anweisungen und eine Herkunftslinie zurückgegeben werden, aus der verständlich wird, was verworfen wurde

• Artefakte müssen exportierbar sein

  • Dateien, Container-Ausgaben, Such-Snapshots und generierte Medien sollten in ein inhaltsadressiertes lokales Archiv heruntergeladen werden können

Distillation und Abhängigkeiten in der Modellschicht

• Einige große US-Labore mit privaten Weights verschärfen ihre ablehnende Haltung gegenüber externer Distillation
• Anthropic bezeichnete in einem Beitrag vom Februar 2026 Aktivitäten von DeepSeek, Moonshot und MiniMax als distillation attacks
  • Die kommerziellen Bedingungen legen fest, dass Kunden Ausgaben besitzen, verbieten aber die Nutzung von Service-Outputs zum Training konkurrierender AI-Modelle
  • Zugleich erkennt Anthropic im eigenen Beitrag Distillation an, wenn führende Labore sie auf ihre eigenen Modelle anwenden, als verbreitete legitime Trainingsmethode an
• Anthropic sammelte zum Zweck der Modellentwicklung öffentliche Webdaten per Bot und schnitt Bücher auf, um sie zu scannen; auch OpenAI erklärte, mit frei zugänglichen öffentlichen Internetinhalten zu trainieren, und berief sich dabei auf Fair Use
• Beide Unternehmen behandeln Distillation intern als gängige Methode, wenn sie kleinere Modelle erzeugen
  • OpenAI bot sogar einen eigenen API-Distillation-Workflow an, um kleinere OpenAI-Modelle mit Outputs starker OpenAI-Modelle feinzujustieren
• Es gibt eine moralische Asymmetrie: Von der enormen Menge menschlicher Arbeit im Internet sollen Maschinen lernen dürfen, aber von den von Laboren erzeugten Outputs sollen andere Maschinen nicht lernen dürfen
• Distillation kann Fähigkeiten teurer Frontier-Modelle auf kleinere, billigere und schnellere Modelle übertragen
  • Diese können lokal, offline, auf eingeschränkter Hardware oder in nutzerkontrollierten Umgebungen laufen
  • Das erhöht den Wettbewerb, bewahrt Fähigkeiten auch dann, wenn APIs verschwinden, und reduziert Rechen- und Energieverbrauch für allgemeine Aufgaben

Die minimale Freiheit, die Nutzern garantiert sein sollte

• Nutzer sollten Sessions auch nach Schließung ihres Kontos aufbewahren und an andere Modelle übergeben können
• Ein neues Modell darf zu anderen Einschätzungen kommen, Rückfragen stellen oder schlechter performen, aber es sollte nicht statt der vom vorherigen Modell gesehenen Nutzerhistorie, Belege, Pläne und delegierten Aufgaben nur Ciphertext erhalten
• Das Problem sind nicht zustandserhaltende APIs an sich, sondern dass bessere Leistung mit weniger Nutzerkontrolle gekoppelt wird
• Serverspeicherung sollte optional sein, gehostete Tools sollten beobachtbar sein, Komprimierung sollte lesbar und Agentenkommunikation auditierbar sein
• Selbst bei privater Inferenz braucht es mindestens einen portablen Übergabeverlauf, und Distillation sollte kein Tabu sein, das höhere Hürden rechtfertigt, sondern ein Weg, Fähigkeiten breiter verfügbar zu machen

[GN⁺]

Hacker-News-Kommentare

• Dieser Beitrag zeigt, dass die Lage wohl schon ernster ist als gedacht. Man muss Freiheit auch tatsächlich nutzen, damit sich die Beziehung zum Anbieter verändert, daher ist es wichtig, nicht von einem bestimmten Ökosystem abhängig zu sein
  Ich habe Codex trotz des guten Outputs bewusst akzeptiert, obwohl es den Inferenzprozess verbirgt, aber die fehlende Auditierbarkeit ist schon jetzt ein großes Problem, sodass ich mein Abo für den Privatgebrauch überdenke. Deshalb entwickle ich auch eine mobile App für OpenCode

  • Mit Blick auf das Problem, dass wertvolle Agenten-Sitzungsgespräche verschwinden, habe ich https://www.agentkanban.io gebaut. Es speichert Kontext zu Aufgaben auf dem Board und kann ihn später in einer neuen Agenten-Sitzung wieder laden; derzeit werden Claude und Github CoPilot in VS Code unterstützt
    Proprietäre Nutzungsverläufe von Tools habe ich bewusst ausgeschlossen, weil sie die Sitzungsportabilität zerstören
  • Ich bin optimistisch, dass Dark Patterns nur eine kurzfristige Erfolgsstrategie sind und langfristig von Ansätzen verdrängt werden, die Nutzer respektieren und dem Gemeinwohl dienen. Angesichts möglicher schneller Verschiebungen könnte jetzt der Zeitpunkt sein, sich auf Modelle mit offenen Gewichten zu konzentrieren, die sich wirtschaftlich betreiben lassen
  • Während ich auf fallende Preise warte, sammle ich möglichst viele Sitzungsdaten von Claude und Codex, um sie später für das Fine-Tuning offener Modelle zu nutzen. Dafür habe ich auch eigene Parser und Archivierungs-Tools für Sitzungen gebaut
  • Ich habe sogar 96 GB VRAM beschafft, um lokale Modelle zu betreiben, aber es gibt noch keines, das an GPT-basiertes Codex herankommt. Laguna S2.1 NVFP4 ist beim Coden schon ziemlich nah dran, aber bis lokale Modelle eine ernsthafte allgemeine Alternative sind, scheint es noch weit zu sein
  • https://indieweb.org/POSSE ist die Lösung

• Das ist ein guter Beitrag über ein Problem, das die meisten AI-Nutzer kaum bewerten. Führende Inferenzanbieter verpacken Nicht-LLM-Funktionen wie Websuche und Code-Ausführung als bloße Tools, tatsächlich erzeugen sie aber starke Eintrittsbarrieren und Bindungen
  Theoretisch könnte man sie vom Inference API trennen und als MCP-Server externalisieren, aber Anbieter liefern das selten so aus, und die Funktionen alternativer Anbieter sind meist schwächer. Beim Bau der On-Premises- und anbieterunabhängigen Chat-Plattform https://github.com/EratoLab/erato war selbst eine scheinbar einfache Funktion wie Bilderzeugung im Chat schwierig umzusetzen; ein Grund ist auch, dass MCP noch keine grundlegende Spezifikation für Dateiübertragung hat: https://github.com/modelcontextprotocol/modelcontextprotocol...
  Ich hoffe, dass mit dem wachsenden Interesse an Modellen mit offenen Gewichten mehr leichter austauschbare alternative Implementierungen entstehen

  • Agenten lokal auszuführen, bei denen man Prompts überhaupt nicht prüfen kann, etwa wegen verschlüsselter Subagenten-Nachrichten, ist grundsätzlich unverantwortlich. Dass Anbieter gehostete Tools bereitstellen, sehe ich dagegen nicht als Problem; das ist eher wie Impulsartikel an der Supermarktkasse
    Bilderzeugung sollte man nicht über MCP umsetzen, sondern einfach ein eigenes Tool dafür schreiben. Anbieter wie Fal für Bild- und Medieninferenz sowie Anbieter für Websuche und Deep Research gibt es mehr als genug

• Vielleicht braucht es offene Standards oder Dateiformate für Kontext. Ich frage mich, ob offene Modelle sich zur Portabilität auf dasselbe Format einigen könnten und ob man es SQLite-basiert bauen könnte, damit auch andere Programme darauf zugreifen können

• In der Praxis sind Gespräche oft voller Rauschen, sodass es häufig besser ist, dieses aus dem Kontext zu entfernen. Ich lasse die AI im Memo-Verzeichnis des Repositories Markdown-Dateien anlegen, in denen festgehalten wird, was sie gelernt, erledigt und was noch offen ist, damit ein anderes Modell im nächsten Gespräch übernehmen kann
  Bei Bedarf kann ich die Memos zuerst auch selbst bearbeiten

  • Deshalb nutze ich inzwischen mehr Agent Coding. Ich beschreibe die Aufgabe, verlange Tests und das Bestehen strenger Lint-Regeln und lasse dann das langatmige Gerede des Modells vorbeiziehen
    Es soll erst zurückkommen, wenn alle Prüfungen bestanden sind, sodass ich weniger unter den überflüssigen Gesprächen der Chat-Oberfläche leide
  • Wenn man die Sitzung wegwirft, verliert man Funktionen zum Prüfen, Exportieren, Wiederholen und Auditieren. Die großen Modellanbieter haben keine echten Eintrittsbarrieren, und OpenAI sowie Anthropic schreiben bei der operativen Marge tiefrote Zahlen und haben auch nicht so viel Kapital wie die Big-Tech-Konzerne
    Deshalb versuchen die Anbieter künstlich Abhängigkeiten zu schaffen; das ist im Kern ein Fall fürs Kartellrecht. Im heutigen Amerika wird es aber geduldet, weil die FTC geschwächt ist
  • Man sollte Modelle ohne Verluste leicht wechseln können; das würde für mehr Wettbewerb und bessere, günstigere AI sorgen. Wenn durch verlorenen Kontext der Wechsel schmerzhaft wird, schaffen Anbieter Vendor Lock-in, verschlechtern die Nutzererfahrung und können die Preise erhöhen
    Selbst wenn es heute Umgehungen gibt, bleiben die Anreize groß, freies Wechseln schwieriger zu machen, daher ist es besorgniserregend, dass AI-Unternehmen beginnen, die Grundlage für Service-Verschlechterung zu legen
  • Lange Sitzungen verlieren oft den Fortschritt aus den Augen, und je weitschweifiger das Modell, desto niedriger ist das Signal-Rausch-Verhältnis. Wertvoll ist nicht das Rohprotokoll der Sitzung, sondern das Ergebnis wie Code-Änderungen oder Pläne und Zusammenfassungen

• Man muss zwei Phänomene unterscheiden. Erstens wächst verborgener Zustand, den Nutzer weder prüfen noch übertragen können; das ist klar schlecht. Zweitens driften Implementierungen und APIs je nach Anbieter auseinander; das macht Portierung nicht unmöglich, sondern nur schwieriger
  Die Zeit, in der die OpenAI Completions API wie ein allgemeiner Standard genutzt wurde, geht zu Ende, und abgesehen von den geschlossenen Teilen könnte die neue Responses API sogar besser sein. Produkte, Bibliotheken und SDKs müssen nicht weiter zwanghaft eine einheitliche Abstraktion über alle Anbieter hinweg verfolgen
  Wie bei Datenbanken, wo vereinheitlichende Abstraktionen undicht wurden und man am Ende doch implementationsspezifische Unterschiede akzeptierte, wird es auch bei Modellanbietern sein; es reicht, wenn nur Teile einer Sitzung portierbar sind

  • Dieser Beitrag behandelt von den beiden Phänomenen nur den verborgenen Zustand

• Ich entwickle gerade https://github.com/pantoniou/fyai, noch roh, aber mit direkter Aufbewahrung von Sitzungsdaten und Verwaltung in einem git-ähnlichen Modell

  • Dieses Tool kann das im Beitrag behandelte Problem nicht lösen und strukturell auch gar nicht lösen

• Eine vertragliche Zusicherung, dass man Sitzungen auch nach dem Schließen des Kontos behalten und an andere Modelle weitergeben kann, wäre sinnvoll. Im Idealfall sollte man auch leicht Modelle mit ähnlichen Embedding-Eigenschaften finden können
  Als GPT-4o erstmals eingestellt wurde, gab es Leute, die exportierte Gespräche einspielten und nach Modellen mit ähnlichem Tonfall und ähnlicher Persönlichkeit suchten, um einen alten Freund zurückzubekommen, aber andere OpenAI-Modelle vermittelten nicht dasselbe Gefühl. Offene Modelle mit Gewichten haben den Vorteil, dass man sie dauerhaft bewahren kann, sodass ein großer Konzern einem nicht einseitig einen Wegweiser, Freund oder Berater wegnehmen kann

• Ich frage mich, was nötig ist, um diese Diskussion über den Status eines HN-Blogthemas hinauszubringen

• Die heutigen Modelle haben begrenzte Kontextfenster und vergessen Inhalte ab einem gewissen Punkt, daher ist der Wert von Sitzungen nicht so hoch. Wenn Modelle in Zukunft durch Interaktionen tatsächlich selbst lernen und sich verändern, dann lassen sich diese Veränderungen ohnehin nicht auf andere Modelle übertragen; deshalb halte ich das Problem nicht für besonders bedeutend

• Zusammen mit diesem Beitrag ist https://gwern.net/complement eine hervorragende Ergänzung

  • Es braucht einen Grund, warum das eine Ergänzung sein soll