KI Agenten mit OpenAI: Agents API oder Agents SDK?

OpenAI hat die verwaltete Agents API am 10. September 2026 eingeführt. Wer KI Agenten entwickelt, wählt sie, wenn Sitzungszustand, Kontextkomprimierung und Wiederherstellung den operativen Aufwand bestimmen. Das Agents SDK ist die bessere Wahl, wenn die eigene Anwendung Laufzeit, Bereitstellung und Datenpfad kontrollieren muss. Bei der Entscheidung zwischen OpenAI Agents API und Agents SDK geht es damit vor allem um Kontrolle und Betrieb – für den verwalteten Dienst fällt keine separate Harness-Gebühr an.

Welche Lösung eignet sich für KI Agenten?

Für ein kleines Plattformteam, das langlebige Agenten produktiv einsetzt, ist die OpenAI Agents API meist die bessere Standardwahl. OpenAI betreibt das Codex-Harness, hält die Session samt gespeichertem Arbeitsstand vor, komprimiert den Kontext, koordiniert Subagenten und ermöglicht die Wiederherstellung über asynchrone Turns hinweg. Damit entfällt Infrastrukturarbeit, die ein Produkt nur selten differenziert. OpenAI hat die API am 10. September 2026 als öffentliche Beta veröffentlicht und gibt an, dass sie allen Entwicklern offensteht.

Für einen finanzierten Gründer mit kleinem Backend-Team und einem Agenten zur Dokumentenprüfung, der stundenlang auf Freigaben warten kann, ist die verwaltete Session wertvoller als die Kontrolle über die Schleife. Die knappe Zeit des Produktteams gehört in Richtlinien, Tools, Evaluationen und Nutzererlebnis.

Das OpenAI Agents SDK passt besser, wenn Laufzeitkontrolle eine Anforderung und keine Vorliebe ist. Es läuft innerhalb der eigenen Anwendung; Bereitstellung, Speicher, Freigabelogik, Tool-Implementierungen und Zustandsstrategie liegen damit beim eigenen Team. Ein CTO im Mittelstand mit verpflichtender Zero-Data-Retention-Richtlinie sollte derzeit diesen Weg wählen, weil die öffentliche Beta der Agents API ZDR nicht unterstützt.

Für einen erfahrenen Entwickler mit bestehender Worker-Flotte, eigener Telemetrie und erprobtem Wiederherstellungsweg lohnt ein Wechsel kaum, wenn er nur die Wartung einer überschaubaren Schleife ersparen soll. Das SDK bewahrt diese Kontrolle und liefert weiterhin Agenten, Tools, Übergaben, Schutzmechanismen, Sessions, menschliche Prüfung und Tracing.

OpenAI Agents API und Agents SDK im direkten Vergleich

Der offizielle Unterschied liegt darin, wo die Orchestrierung ausgeführt wird und wer den Zustand zwischen Aufgaben besitzt. Beide Varianten können Modelle und Tools von OpenAI aufrufen; Modell-Tokens werden bei keiner davon kostenlos.

In der Praxis kippt die Entscheidung an einem einfachen Punkt. Erledigt ein Agent eine kurze Anfrage innerhalb eines bestehenden Dienstes, kann der zusätzliche Besitzaufwand des SDK minimal sein. Bearbeitet er Dateien, wartet auf Freigaben, übersteht Verbindungsabbrüche, delegiert Arbeit und setzt sie am nächsten Tag fort, spart die verwaltete API mit jedem weiteren Lebenszykluszustand mehr Infrastruktur ein.

Harness und Sandbox sind zwei getrennte Entscheidungen

Die Agents API verwaltet die Denkschleife, zwingt aber nicht jedes Tool auf OpenAI-Compute. OpenAI bezeichnet diese verwaltete Schleife als Codex-Harness: Es koordiniert Modellaufrufe, Tool-Nutzung, Kontext, Sessions und Subagenten. Die Ausführungsumgebung ist eine separate Ressource, in der Befehle laufen und Dateien liegen.

Diese Umgebung kann fehlen, von OpenAI gehostet oder selbst gehostet sein. Ohne Umgebung kann das Harness weiterhin Remote-MCP-Server aufrufen und Funktionsaufrufe an die eigene Anwendung senden, verfügt aber weder über integriertes Bash noch über ein Apply-Patch-Tool oder Arbeitsbereichsdateien. In einer von OpenAI gehosteten Sandbox stellt OpenAI den Linux-Arbeitsbereich bereit. Bei einer selbst gehosteten Umgebung führt der eigene Executor Befehle und Dateioperationen aus, während das verwaltete Harness sie anfordert. Der Architekturleitfaden macht diese Trennung ausdrücklich deutlich.

Diese Unterscheidung verhindert zwei kostspielige Fehler. Erstens wäre es voreilig, allein deshalb das Agents SDK zu wählen, weil Code im eigenen VPC laufen muss: Die Agents API kann eine selbst gehostete Umgebung anbinden. Zweitens wäre auch die Agents API mit der Begründung, OpenAI solle alles ausführen, vorschnell gewählt: Funktionshandler der Anwendung laufen weiterhin im eigenen Code, und bei einem selbst gehosteten Executor bleiben Bereitstellung, erneute Verbindung, Herunterfahren und Dateipersistenz beim eigenen Team.

Für einen privaten Datenanalyse-Workflow könnte das verwaltete Harness SQL-Funktionsaufrufe an einen Anwendungsdienst senden, ohne Zugriff auf eine allgemeine Shell zu erhalten. Ein Coding-Agent könnte eine von OpenAI gehostete Sandbox nutzen. Ein proprietäres Build-System ließe sich mit einem eigenen isolierten Worker verbinden. Das sind drei Ausführungsmuster unter derselben verwalteten Orchestrierungsschicht.

Sitzungszustand: Die Agents API gewinnt bei lang laufender Arbeit

Die Agents API ist im Vorteil, sobald der Lebenszyklus einer Aufgabe über eine einzelne Anwendungsanfrage hinausgeht. Eine Session bewahrt Agentenkonfiguration, Gespräch und gespeicherten Arbeitsstand. Neue Eingaben starten bei inaktiver Session einen asynchronen Turn oder lenken den aktiven Turn während der Bearbeitung. Die Anwendung kann einem Stream folgen oder Zustandsänderungen per Webhook empfangen.

OpenAI verwaltet außerdem die Kontextkomprimierung, wenn sich eine Session ihrem Kontextlimit nähert. Dabei werden ältere Details durch eine kleinere, weitergeführte Darstellung ersetzt, damit der Agent über mehrere Kontextfenster hinweg arbeiten kann. Das klingt einfach, ist im Betrieb aber anspruchsvoll: Die komprimierte Zusammenfassung muss Entscheidungen, Tool-Ergebnisse und offene Arbeit bewahren, ohne jedes frühere Token dauerhaft mitzuschleppen.

Der leisere Vorteil ist die Wiederherstellung. Ereignisstreams spielen verpasste Ereignisse nicht erneut ab. Nach einem Verbindungsabbruch ruft die Anwendung die Session und ihre gespeicherten Elemente ab und arbeitet anhand dieses dauerhaften Datensatzes weiter, statt einen Agenten-Turn aus dem Prozessspeicher zu rekonstruieren. Der Leitfaden zu Sessions erläutert den Unterschied zwischen einem abgeschlossenen, fehlgeschlagenen oder abgebrochenen Turn und einer lediglich inaktiven Session.

Ein Beispiel ist ein Agent zur Vertragsprüfung für einen finanzierten Gründer. Er liest ein Dokument, beauftragt einen spezialisierten Subagenten mit dem Klauselvergleich, pausiert für die juristische Freigabe, erhält später eine Korrektur und erstellt ein Artefakt. Der Produktnutzen liegt in der Prüfung. Wiedergeben von Sessions, Kontextkomprimierung, unterbrochene Streams und Turn-Wiederherstellung sind Betriebskosten. Genau diese Arbeitslast soll die verwaltete API auffangen.

Eine ehrliche Einschränkung betrifft die Genauigkeit der Verbrauchsabrechnung. Agenten können mehrere Modellaufrufe auslösen; Root-Agenten, Subagenten, Wiederholungen, Tools und Sandboxes tragen sämtlich zu den Kosten bei. Laut OpenAI sind die Nutzungsfelder der Agents API bestmögliche Näherungswerte, können null sein oder sich später ändern und stellen keine endgültige Rechnung dar. Reasoning-Tokens zählen als Ausgabe-Tokens, während zwischengespeicherte Eingaben kostenpflichtig bleiben. Der Nutzungsleitfaden eignet sich für die Fehlersuche; für finanzielle Kontrollen sollten die Werte anschließend mit den Abrechnungsdaten abgeglichen werden.

Auch das Dashboard bildet eine Grenze der Beobachtbarkeit. Detaillierte Trace-Abfragen und externe Trace-Exporter sind über die Kundenschnittstelle der öffentlichen Beta nicht verfügbar. Muss die eigene Telemetrie-Pipeline jeden Trace programmatisch exportieren, wiegt diese Lücke schwerer als ein ausgereiftes verwaltetes Dashboard.

Laufzeit und Bereitstellung: Das Agents SDK bietet mehr Kontrolle

Das Agents SDK gewinnt, wenn die eigene Anwendung exakt bestimmen muss, wie ein Lauf startet, pausiert, fortgesetzt wird, Zustand speichert, Tools verteilt und fehlschlägt. Sein Runner führt Agentenschleife und Übergaben aus, doch die Schleife lebt im eigenen Dienst. So kann der Produktcode jeden Übergang mit eigenen Transaktionen, Warteschlangen, Ratenlimits, Freigabedatensätzen und Telemetrie umschließen.

Das SDK ist für TypeScript und Python verfügbar, das Python-Repository steht unter der MIT License. Für das Paket fällt daher keine nutzerbezogene Lizenzgebühr an. Modellaufrufe bei OpenAI, gehostete Tools, Sandbox-Anbieter und der Compute-Betrieb der eigenen Anwendung bleiben separate Kosten. Der SDK-Leitfaden ordnet es codeorientierten Anwendungen zu, die Bereitstellung, Speicher, Freigaben und Laufzeitintegration selbst verantworten.

Der Zustand ist flexibel statt automatisch. Eine SDK-Anwendung kann result.history wiedergeben, eine SDK-Session im eigenen Speicher persistieren, eine OpenAI Conversations ID anbinden oder über die ID einer vorherigen Antwort der Responses API verketten. Jede Variante hat ihren Zweck. Der Leitfaden zur Agentenausführung warnt jedoch, dass die Mischung aus lokaler Wiedergabe und serverseitig verwaltetem Zustand Kontext duplizieren kann, wenn die Ebenen nicht bewusst aufeinander abgestimmt werden.

In einem regulierten internen Dienst zahlt sich diese Flexibilität aus. Eine Freigabe und die Fortsetzung des Agenten lassen sich in derselben Datenbanktransaktion verbinden, der Zustand kann in einer zugelassenen Region liegen, Tools können hinter privaten Netzwerkkontrollen laufen und die Agentenausführung kann sich in ein bestehendes Job-System einfügen. Über die Modellschicht des SDK lassen sich außerdem Modelle oder Anbieter integrieren, ohne das verwaltete Codex-Harness zur dauerhaften Orchestrierungsgrenze zu machen.

Die Grenze ist die operative Verantwortung. Ein Prozessabsturz wird zum eigenen Fortsetzungsproblem. Eine doppelte Zustellung aus der Warteschlange wird zum eigenen Idempotenzproblem. Wachstum der Historie, Komprimierungsrichtlinie, Tool-Wiederholungen, Zustandsmigrationen und Rollback der Bereitstellung werden ebenfalls zu eigenen Aufgaben. Das SDK verschafft die Kontrolle darüber – wertvoll ist sie nur, wenn die Anwendung sie tatsächlich nutzt.

Kostenvergleich: keine separate Harness-Gebühr

Nutzen beide Laufzeiten dasselbe OpenAI-Modell, denselben Token-Mix und dieselben Tool-Aufrufe, ist die Rechnung für Tokens und gehostete Tools identisch. Die Preise wurden am 11. September 2026 anhand der Live-Seiten von OpenAI geprüft. Im Standardtarif für kurze Kontexte kostet GPT-6 Astra $10.00 pro 1 Million Eingabe-Tokens und $50.00 pro 1 Million Ausgabe-Tokens. Die Websuche kostet $10.00 pro 1,000 Aufrufe, hinzu kommen die Tokens der Suchinhalte zum Preis des gewählten Modells. Für die verwaltete Agents API selbst fällt keine zusätzliche Gebühr an.

Das folgende normalisierte Arbeitspensum beruht auf Annahmen, nicht auf beobachteten Produktionsdaten:

• 1,000 Agenten-Jobs pro Monat.
• Jeder Job verbraucht insgesamt 10,000 nicht zwischengespeicherte Eingabe-Tokens und 2,000 Ausgabe-Tokens mit GPT-6 Astra. Zurückgegebene Suchinhalte sind im Eingabekontingent enthalten.
• Jeder Job führt einen Websuchaufruf aus.
• Im gehosteten Fall der Agents API wird pro Job eine neue 1-GB-Container-Abrechnungssitzung zum veröffentlichten Preis von $0.03 geöffnet. Die Wiederverwendung einer Sandbox würde diese Position reduzieren.
• Im SDK-Fall wird ein gemeinsam genutzter Worker angenommen, der $40 pro Monat kostet und ausreichend Kapazität hat. Speicher, Netzwerk und Arbeitsaufwand sind ausgeschlossen.

Der Modellanteil beträgt $0.10 für die Eingabe plus $0.10 für die Ausgabe, also $0.20 pro Job. Über den angenommenen Mix von 12,000 Tokens entspricht das $0.0167 pro 1,000 gemischten Modell-Tokens. Ein Websuchaufruf erhöht die gemeinsamen OpenAI-Kosten um $0.01 auf $0.21 pro Job.

Bei 1,000 Jobs kostet die Agents API mit einem neuen gehosteten 1-GB-Container für jeden Job $240: $210 für die gemeinsame Modell- und Suchnutzung plus $30 für Container. Der SDK-Fall kostet $250: dieselben $210 OpenAI-Nutzung plus den angenommenen Worker für $40. Bei den direkten Ausgaben gewinnen gehostete Container in diesem niedrigen Volumenbereich.

Bei 10,000 Jobs erreicht der verwaltet-gehostete Fall $2,400: $2,100 gemeinsame Ausgaben plus $300 für Container. Der SDK-Fall kommt mit dem angenommenen gemeinsam genutzten Worker auf $2,140. Der direkte Compute-Schnittpunkt liegt bei 1,334 neuen Container-Sessions pro Monat – der ersten ganzen Anzahl, bei der $0.03 pro Session die $40 übersteigen.

Am wichtigsten ist der Fall einer selbst gehosteten Agents API. Nutzt die Agents API denselben angenommenen Worker für $40, beträgt ihre Gesamtsumme bei 10,000 Jobs ebenfalls $2,140. Das Codex-Harness bleibt verwaltet, doch die Ausführungskosten entsprechen dem SDK-Szenario, weil OpenAI keine Harness-Gebühr aufschlägt.

Die Geldrechnung lässt die größte Variable weiterhin außen vor: Entwicklungszeit. Oberhalb des Schnittpunkts ist eine Compute-Ersparnis von $260 pro Monat irrelevant, wenn das SDK mehrere Stunden Plattformarbeit verursacht. Darunter kann der Weiterbetrieb eines ausgereiften SDK-Systems nahezu nichts kosten.

Für feste Budgetgrenzen in beiden Architekturen sollten Arbeitsschätzungen mit den Schutzmaßnahmen auf Projektebene aus Budgetkontrollen für KI-Agenten-APIs 2026 kombiniert werden. Eine Schätzung dient der Planung, nicht der Durchsetzung.

Migration zur Agents API: Was der Wechsel vom SDK kostet

Der Wechsel vom Agents SDK zur Agents API ist eine Laufzeitmigration und keine bloße Umbenennung eines Pakets. Agentendefinitionen und Tool-Schemata mögen vertraut aussehen, doch Session-IDs, SDK-Sessions, Responses-Konversationen, Agents-API-Sessions und Sandboxes sind unterschiedliche Ressourcen. Zustand ist als grenzüberschreitender Datensatz zu behandeln, nicht als Kennung, die sich unverändert portieren lässt.

1. 1

   Verhaltensvertrag festschreiben

   Bestehende Agentenanweisungen, Tool-Schemata, Freigabepunkte, Ausgabeform, Token-Budget und Fehlerrichtlinie dokumentieren. Modell und Tools bleiben während des Vergleichs unverändert, damit eine Qualitätsänderung nicht fälschlich als Laufzeitverbesserung erscheint.

2. 2

   Agenten- und Tool-Konfiguration abbilden

   Modell, Anweisungen, MCP-Verbindungen und Funktionsdefinitionen in die Konfiguration der Agents API übertragen. Funktionshandler der Anwendung benötigen weiterhin einen Dienst, der Aufrufe empfängt und Ergebnisse zurückgibt; allein durch die Verlagerung der Orchestrierung werden sie nicht gehostet.

3. 3

   Zustandsgrenze ziehen

   Neue Gespräche als Agents-API-Sessions beginnen und ihre IDs neben den Gesprächsdatensätzen der Anwendung speichern. Alte SDK-Historien bleiben während des Übergangs lesbar. Muss alter Kontext fortgeführt werden, sollte nur der notwendige Geschäftszustand in eine explizite Eingabe umgewandelt werden, statt eine SDK-Session als Agents-API-Session auszugeben.

4. 4

   Lebenszyklus-Infrastruktur ersetzen

   Den Einstiegspunkt des prozessinternen Runners durch Session-Erstellung, Ereignisse, gespeicherte Elemente, erforderliche Aktionen, Webhooks, Abbruch und Löschung ersetzen. Jeden Webhook und jedes Funktionsergebnis idempotent verarbeiten, denn verwalteter Zustand beseitigt nicht das Risiko doppelter Zustellung am Rand der eigenen Anwendung.

5. 5

   Parallel testen und Regressionen prüfen

   Denselben Evaluationssatz über beide Wege ausführen. Aufgabenerfolg, gesamte Eingabe- und Ausgabe-Tokens, Tool-Aufrufe, Laufzeit, Wiederherstellungsverhalten und menschliche Eingriffe vergleichen. Datenverkehr erst verlagern, wenn der neue Weg den alten Vertrag erfüllt.

Ein beispielhaftes Migrationsbudget macht den Zielkonflikt greifbar. Angenommen, ein bestehender Workflow besitzt drei Funktions-Tools, persistente Sessions und eine menschliche Freigabe. Dafür werden 24 Entwicklungsstunden zu je $150 angesetzt: 6 Stunden für Konfiguration und Tool-Zuordnung, 8 für Session- und Lebenszyklusarbeit, 6 für Webhooks, Wiederherstellung und Idempotenz sowie 4 für Regressions- und Kostenprüfungen. Das ergibt einmalig $3,600.

Spart die verwaltete Kontextkomprimierung, Wiederherstellung, Sitzungsverwaltung und Orchestrierung angenommene 6 Entwicklungsstunden pro Monat, beträgt die Arbeitsersparnis monatlich $900 und die Amortisationszeit vier Monate. Benötigt der bestehende SDK-Weg nur gelegentlich Aufmerksamkeit, kann eine Amortisation ganz ausbleiben. Genau darum geht es bei den Annahmen: Eine Migration rechtfertigt sich durch weniger Betriebsarbeit, nicht durch günstigere Tokens.

Wer nicht zur Agents API wechseln sollte

Ein Wechsel ist nicht sinnvoll, wenn die Datenkontrollen der öffentlichen Beta an der Beschaffung scheitern. Laut aktueller Übersicht der Agents API ist die Datenresidenz auf die Vereinigten Staaten beschränkt und Zero Data Retention wird nicht unterstützt. Eine selbst gehostete Sandbox ändert diese Richtlinie nicht, weil Harness und Session weiterhin im verwalteten Dienst liegen.

Beim Agents SDK sollte bleiben, wer eine dieser Voraussetzungen erfüllt:

• Die Laufzeit muss unter einem eigenen Scheduler, einer eigenen Transaktionsgrenze oder einem Latenzrahmen ausgeführt werden, den die Anwendung direkt kontrolliert.
• Richtlinien für Speicher, Trace-Export oder Datenresidenz lassen sich mit der verwalteten öffentlichen Beta nicht vereinbaren.
• Der Agent nutzt flexible Anbieterwahl oder eine Modellabstraktion, die nicht vom Codex-Harness abhängen soll.
• Das bestehende SDK-System verfügt bereits über zuverlässige Kontextkomprimierung, Wiederherstellung, Beobachtbarkeit und Bereitstellung bei geringem laufendem Wartungsaufwand.
• Der Großteil der Arbeit ist kurzlebig und zustandslos, sodass eine dauerhafte verwaltete Session kaum Infrastruktur einspart.

Auch der Beta-Status ist eine Release-Entscheidung. OpenAI kündigt schnelle Iterationen vor der allgemeinen Verfügbarkeit an. Ein Team mit starrem Änderungskalender kann die Lösung jetzt evaluieren und die Migration auf einen Zeitpunkt nach Stabilisierung des Vertrags verschieben.

Auch beim SDK gibt es einen Grund zum Verzicht. Ein schlankes Startup sollte es nicht allein wählen, um theoretischen Lock-in zu vermeiden, und dabei unbemerkt Sessions, Wiederherstellung, Sandbox-Lebenszyklus und Orchestrierung neu bauen. Kontrolle, die das Produkt nie nutzt, wird zu Wartungsschuld.

Für Agenten mit Codeausführung sollte die Umgebungsschicht separat anhand von Die besten Code-Sandboxes für KI-Agenten 2026 verglichen werden. Die Wahl der Sandbox beantwortet nicht, wem der Orchestrierungszustand gehören sollte.

Kundenergebnisse sind Hinweise, keine übertragbaren Benchmarks

Die ersten Zahlen sprechen für den verwalteten Weg, stammen jedoch aus Kundenberichten im OpenAI-Launchbeitrag vom 10. September und nicht aus einem kontrollierten unabhängigen Benchmark. SafetyKit meldete eine Reduzierung der Kosten pro Fall um 60%. Hypha berichtete von 86% weniger fehlgeschlagenen Agentenantworten, nachdem verwaltetes Harness und Sandbox voneinander getrennt worden waren. Ciridae meldete einen Anstieg des Evaluationswerts von 0.71 auf 0.85 und eine 4x geringere Latenz.

Diese Ergebnisse zeigen, dass die Laufzeitgrenze relevant sein kann. Sie belegen nicht, wie viel eine eigene Migration spart, weil der Beitrag weder vorherige Architektur noch Modell-Mix, Token-Volumen, Aufgabenschwierigkeit oder Entwicklungsaufwand der Kunden vereinheitlicht. Die Berichte rechtfertigen einen parallelen Evaluationstest, aber keine Prognose.

FAQ zu OpenAI Agents API und Agents SDK

Warum sollte man das OpenAI Agents SDK verwenden?

Das OpenAI Agents SDK eignet sich, wenn die eigene Anwendung Bereitstellung, Speicher, Freigabeentscheidungen, Tool-Implementierungen und Laufzeitschleife direkt besitzen muss. Es liefert die Agentenbausteine von OpenAI, ohne die Orchestrierung in die verwaltete Agents API zu verlagern.

Was passt besser: OpenAI Agents SDK oder PydanticAI?

Das ist ein separater Framework-Vergleich. Zunächst steht die Entscheidung an, ob OpenAI das Codex-Harness über die Agents API verwalten soll oder die Laufzeit per SDK in der eigenen Anwendung liegt. Erst im zweiten Fall werden SDK-Frameworks miteinander verglichen.

Welches SDK für KI-Agenten ist das beste?

Kein SDK ist für jede Architektur das beste. Das OpenAI Agents SDK ist eine überzeugende Wahl, wenn seine TypeScript- oder Python-Schleife, Tools, Übergaben, Schutzmechanismen, Sessions und OpenAI-Integrationen zur Anwendung passen und die Bereitstellung in eigener Hand bleiben soll.

Ist das OpenAI Agents SDK kostenlos?

Das Python Agents SDK ist MIT-lizenziert, daher kostet das Paket keine Lizenzgebühr. Modellaufrufe, kostenpflichtige Tools, Sandbox-Dienste und die Infrastruktur für den Betrieb der eigenen Anwendung bleiben kostenpflichtig.

Wie lassen sich mit dem OpenAI Agents SDK KI Agenten erstellen?

Das offizielle TypeScript- oder Python-Paket installieren, einen Agenten mit Anweisungen und Tools definieren, eine Zustandsstrategie wählen und ihn in der eigenen Anwendung ausführen. Freigaben, Persistenz, Tracing und Sandboxing kommen nur dort hinzu, wo der Workflow sie benötigt.

Was kostet ein OpenAI-Agent?

Einzurechnen sind Modelleingabe, zwischengespeicherte Eingabe, Ausgabe, Tool-Aufrufe, Sandbox- oder Anwendungs-Compute, Dienste von Drittanbietern und Betriebsarbeit. Es gibt keine separate Harness-Gebühr für die Agents API; unter den Annahmen dieses Artikels kippen die direkten Umgebungskosten bei 1,334 neuen 1-GB-Container-Sessions pro Monat gegenüber einem gemeinsam genutzten Worker für $40.

Ist die OpenAI API kostenlos oder kostenpflichtig?

Die Nutzung von Modellen und kostenpflichtigen Tools der OpenAI API wird nach API-Preisliste abgerechnet. Ein ChatGPT-Abo ist ein separater Produktvertrag und deckt die API-Nutzung einer Anwendung mit Agents API oder Agents SDK nicht ab.

Warum $20 für ChatGPT bezahlen?

Das ist eine Entscheidung über ein ChatGPT-Abonnement und nicht über Agents API oder SDK. Ein ChatGPT-Abonnement gewährt Zugang zum ChatGPT-Produkt gemäß den jeweiligen Tarifbedingungen; die Nutzung der OpenAI API wird separat abgerechnet.

Ist OpenAI Agent Builder kostenlos oder kostenpflichtig?

Agent Builder war in den Standardpreisen der API-Modelle enthalten, ist aber keine der hier verglichenen Laufzeiten. OpenAI gibt an, Agent Builder einzustellen; die Abschaltung ist für den 30. November 2026 vorgesehen.

Der nächste Schritt am Montag

In der kommenden Woche einen lang laufenden Workflow auswählen und beide Wege parallel vergleichen. Modell, Anweisungen, Token-Budget, Tools und Evaluationssatz bleiben konstant. Neue Testgespräche laufen über die Agents API, bestehende Nutzerhistorien bleiben auf dem SDK-Weg. Wer den Wert des verwalteten Harness isolieren möchte, nutzt auf beiden Seiten dieselbe Ausführungsumgebung.

Aufgabenerfolg, gesamte Tokens, kostenpflichtige Tool-Aufrufe, Sandbox-Abrechnungssitzungen, Wiederherstellungsfälle, menschliche Eingriffe und Entwicklungszeit erfassen. Die Agents API ist die richtige Wahl, wenn die eingesparte Sitzungs- und Wiederherstellungsarbeit den Kontrollverlust überwiegt. Das Agents SDK bleibt, wenn der verwaltete Dienst eine Datenanforderung nicht erfüllt oder zu wenig Betriebszeit spart, um die Migrationskosten wieder einzuspielen.

Vor dem Wechsel einer Agentenlaufzeit hilft die Checkliste für das Audit von KI-Geschäftsprozessen.