Der API-Werkzeughersteller Postman hat eine grundlegend überarbeitete Version seiner Entwicklungsplattform vorgestellt. Das Update macht die Anwendung vollständig Git-nativ und führt mit dem Agent Mode sowie einem zentralen API Catalog neue Funktionen ein, die auf die Zusammenarbeit mit autonomen KI-Agenten abzielen.

Laut der Ankündigung im Postman-Blog werden APIs immer stärker zur kritischen Schnittstelle zwischen Agenten und der realen Welt. Der zentrale Gedanke dabei: Im Unterschied zum bisher deterministischen Ansatz treffen KI-Agenten zur Laufzeit probabilistische Entscheidungen darüber, welche APIs sie aufrufen, wann und in welcher Reihenfolge. Fehlerhafte oder unzuverlässige Schnittstellen könnten sich in agentengesteuerten Systemen schnell kaskadierend auswirken. Die Neuerungen in Postman sollen Entwicklerteams daher auf die zunehmend agentengetriebene Softwareentwicklung vorbereiten.

Git-native Architektur und neues Collection-Format

Der wohl tiefgreifendste Umbau betrifft die Arbeitsweise mit Versionskontrolle. Die neue Postman-Version ist laut Hersteller von Grund auf Git-nativ aufgebaut. Entwicklerinnen und Entwickler sollen in Postman auf demselben Branch arbeiten können, auf dem sie auch Code schreiben – parallel zu ihrer IDE. Die Git-native Architektur ermögliche zudem Offline-Arbeit.

Ein wesentliches Detail für den Entwickleralltag: Postman führt das neue Collection-3.0-Format ein, das YAML-Dateien statt JSON-Blobs verwendet. Collections werden dabei in einzelne YAML-Dateien aufgeteilt. Die Dateien sollen damit nicht nur für KI-Agenten lesbar und schreibbar werden, sondern sich auch einfacher vergleichen und durch Menschen überprüfen lassen. Sämtliche Postman-Assets – darunter Specs, Flows und lokale Mock-Server – werden zusammen mit dem Code versioniert.

Neu sind außerdem codebasierte lokale Mock-Server, die API-Server simulieren und sowohl lokal als auch in der CI-Pipeline laufen können. Postman verspricht sich davon mehr Flexibilität als von rein statischem Mocking: Mock-Server sollen somit stärker ins Zentrum der Entwicklung rücken, etwa beim Entwurf neuer APIs oder beim Stubbing von Abhängigkeiten.

Multi-Protokoll-Support in einer Collection

Moderne Softwaresysteme nutzen selten nur ein einziges Protokoll, doch die meisten Werkzeuge behandeln jedes Protokoll separat. Postman erlaubt es Teams nun, HTTP, GraphQL, gRPC, MCP, MQTT, WebSockets und KI-Requests in derselben Collection zu organisieren. Automatisierung und Validierung über HTTP, GraphQL und gRPC hinweg sollen im Collection Runner möglich sein, weitere Protokolle sollen folgen. Laut Postman ergibt sich daraus ein systemweites Testen, das das tatsächliche End-to-End-Verhalten von Systemen abbilden soll – ohne den Koordinationsaufwand, der entsteht, wenn jede Komponente in einem anderen Tool validiert wird.

Überarbeitete CLI schließt Lücke zwischen Lokal und CI

Die Postman-CLI soll künftig dieselben Collections, Tests und Mocks sowohl lokal als auch in CI-Pipelines ausführen können, ohne dass Workflows für jede Umgebung neu konfiguriert werden müssen. Das soll CI-spezifische Fehler – etwa, dass Lücken in der Testabdeckung erst nach einem Commit sichtbar werden – reduzieren und Workflows vereinheitlichen.

Agent Mode: KI als aktiver Entwicklungspartner

Unter dem Namen „Agent Mode“ steht ab sofort eine KI-Funktion bereit, die über Postman und angebundene Repositories hinweg arbeiten soll. Der Agent Mode kann laut Ankündigung bestehende Collections, Tests und Mocks bearbeiten, aktualisieren und neue erstellen, die den Standards der jeweiligen Organisation folgen. Entwickler können die KI per Konversation nutzen, ihr komplette Workflows übertragen oder sie direkt auf der Codebasis arbeiten lassen – etwa um Fehler zu beheben, Server-Stubs zu generieren oder Client-Code zu erzeugen. Postman-Assets sollen sich auch komplett neu erstellen lassen, indem die KI auf vorhandenen Code verwiesen wird.

Ergänzend dazu soll die KI-gestützte Testgenerierung automatisch Contract-, Last-, Unit-, Integrations- und End-to-End-Tests für APIs anlegen. Bei fehlgeschlagenen Tests unter anderem im Collection Runner soll der Agent Mode die Ursache diagnostizieren und direkt in den Ergebnissen einen Fix vorschlagen können – sodass Entwickler Requests, Variablen und Environments nicht mehr aufwendig einzeln inspizieren müssen.

Neuer API-Katalog als zentrale Steuerungsebene

Eines der größten Probleme in Entwicklungsorganisationen: Es gibt keinen einzigen Ort, der grundlegende Fragen zu den eigenen APIs beantwortet – welche APIs existieren, ob sie getestet sind, ob sie den internen Standards entsprechen und wie sie in Produktion performen. Diese Informationen verteilen sich laut Postman über Git-Repos, CI-Dashboards, APM-Tools, Wikis und informelles Teamwissen.

Der neue API-Katalog soll als operative Schicht für das API-Portfolio-Management dienen und als „System of Record“ fungieren, das aktuell bleibt, weil es direkt mit den Orten verbunden ist, an denen APIs gebaut, getestet und betrieben werden. Teams sollen ihre gesamte API-Landschaft unabhängig von der darunterliegenden Infrastruktur und über alle Umgebungen hinweg einsehen können.

Der Katalog integriert API-Governance, sodass zentrale Teams Designregeln durchsetzen können, und bietet Analytics zur Messung der API-Gesundheit. Per Agent Mode sollen Nutzer den Katalog in natürlicher Sprache abfragen können – etwa: „Welche APIs in Produktion haben keine OpenAPI-Spec?“ oder „Welche Endpoints haben eine P95-Latenz über 500 ms im Staging?“ Der Agent Mode hat laut Postman Zugriff auf das vollständige Datenmodell des Katalogs und kann Governance-, Test- und Laufzeitdaten in einer einzelnen Abfrage verknüpfen.

Private API Network und neues UI

Weitere Neuerungen in Postman betreffen unter anderem das Private API Network, das auf Publisher- und Consumer-Seite aktualisiert wurde. Änderungen aus Git synchronisieren sich nun automatisch über die Postman-CLI mit dem Netzwerk. Das ebenfalls überarbeitete UI bietet nun eine einheitliche Workbench, in der Collections, Environments, Specs, Flows und lokale Mock-Server gemeinsam organisiert werden können.

Die Release Notes zu Version 12 (aktuell ist 12.0.3) listen alle konkreten Änderungen im Detail auf.

(map)

Die neue Ausgabe der Developer-Umfrage State of React ist erschienen. Über 3500 Entwicklerinnen und Entwickler teilen darin ihre Erfahrungen mit der JavaScript-Bibliothek React und ihrem Ökosystem. Die Open-Source-Library TanStack Query schneidet in der Nutzergunst sehr gut ab, während die neueren React-Features Server Components und Server Functions recht unbeliebt sind.

Anhaltende Schwierigkeiten mit Server Components

Erneut wurden die Befragten nach ihren größten „Pain Points“ bei der React-Entwicklung befragt. Unter den Haupt-APIs führt hier bereits zum wiederholten Mal forwardRef. Allerdings ist forwardRef seit dem Ende 2024 erschienenen React 19 nicht mehr notwendig, weshalb das React-Team es als deprecated (veraltet) markiert hat. Im Umgang mit neueren APIs bemängeln die Developer in erster Linie Schwierigkeiten in Bezug auf die Kompatibilität mit React und exzessive Komplexität.

An anderer Stelle konnten die Teilnehmenden angeben, ob sie bestimmte Features und Libraries nutzen oder davon gehört haben, und ob sie diesen positiv, negativ oder neutral gegenüberstehen. Dabei zeigt sich, dass die neueren React Server Components weiterhin wenig Begeisterung auslösen. Bei der Beurteilung aller React-APIs belegen sie den dritten Platz in der Negativwertung, danach folgen Server Functions auf Platz 4. Die Unbeliebtheit der Server Components und Functions ist jedoch laut den Studienmachern bedenklich, denn diese neuen APIs sollen den Weg für Reacts nächsten großen Evolutionsschritt in Richtung eines vollständigeren Fullstack-Frameworks ebnen.

Es zeigt sich auch, dass sowohl Server Components als auch Functions verglichen mit anderen React-Features noch recht selten im Einsatz sind: Sie wurden erst von 45 Prozent beziehungsweise 37 Prozent der Befragten verwendet, was den Plätzen 17 und 19 gleichkommt. Insbesondere Personen, die sie noch nicht verwendet haben, stehen den neuen Features negativ gegenüber. Beispielsweise bewerten fünf Prozent der User von Server Functions diese negativ, aber neun Prozent derjenigen, die nur davon gehört haben.

Positiv treten dagegen die APIs und createContext hervor: Unter ihren Nutzern haben 54 beziehungsweise 48 Prozent den APIs gegenüber eine positive Einstellung, lediglich zwei beziehungsweise sechs Prozent negativ. Auch im letzten Jahr waren diese Features in den Top 3, wobei createContext vom dritten auf den zweiten Platz aufgestiegen ist und den Hook useState mit knappem Vorsprung verdrängt hat. Das beliebteste Feature haben 97 Prozent der Befragten bereits genutzt.

TanStack Query am beliebtesten, Next.js stürzt ab

Nachdem TanStack Query im vergangenen Jahr Next.js überholt hat, verteidigt das quelloffene State-Management-Tool in diesem Jahr den Titel der beliebtesten Library. Darauf folgt Zustand, ebenfalls ein Open-Source-Tool zur Zustandsverwaltung, und auf dem dritten Platz landet die UI-Library shadcn/ui. Diese erzielte in der diesjährigen Studie JavaScript Rising Stars den zweiten Platz, was über 26.000 neuen GitHub-Sternen im Jahr 2025 Rechnung trägt.

Next.js, in der Vorjahresumfrage noch auf dem dritten Platz unter den Libraries, findet sich dieses Mal abgeschlagen auf Rang 9 wieder. Im Vergleich zeigt sich, dass 42 Prozent der TanStack-Query-User diese Library positiv bewerten, während lediglich 27 Prozent der Next.js-User ihre genutzte Library positiv sehen. Ein besonders gutes Image hat anscheinend TanStack Start: Unter denjenigen, die bereits davon gehört haben, es aber nicht einsetzen, liegt die Positivbewertung bei 23 Prozent.

Datengrundlage

Die Online-Umfrage State of React 2025 lief vom 19. November 2025 bis 13. Januar 2026. Weltweit nahmen 3760 Personen daran teil. Dabei geben die Studienmacher Devographics, die auch hinter dem State of JavaScript stehen und nicht mit dem offiziellen React-Team assoziiert sind, zu bedenken, dass unter anderem Anbieter von Frameworks und Libraries ihre User zur Teilnahme animieren konnten. Der State of React erhebt nicht den Anspruch, repräsentativ für das gesamte Ökosystem zu stehen. Als Sponsoren unterstützten unter anderem Google und JetBrains die aktuelle Studie. Die Ergebnisse lassen sich auf der Website des Projekts einsehen.

(mai)

Seit der letzten Model-Schau Ende Januar hat sich einiges bei den Sprachmodellen getan. Eine große Rolle scheint dabei das chinesische Neujahr zu spielen, vor dem die Anbieter nochmal viele Modelle veröffentlicht haben. Doch der Reihe nach!

Coding-Modelle

Schon im September 2025 hat Qwen Modelle mit einer neuen, hybriden Architektur angekündigt. Das einzige verfügbare Modell war Qwen3-Next-80B-A3B-Instruct, das aber mehr als Experiment zu betrachten war. Allerdings hat Qwen die vorgestellte Architektur in das Modell Qwen3 Coder-Next übernommen. Auch die Anzahl der (aktiven) Parameter stimmt genau überein. Hervorzuheben sind die hybriden Attention-Layer, die einen sehr langen Kontext von 262.144 Token erlauben, dabei nicht sehr viel Speicher benötigen und damit auch die Rechengeschwindigkeit kaum reduzieren.

Dadurch ist Qwen3-Coder-Next auf eigener Hardware schnell ablauffähig, wenn ausreichend Speicher zur Verfügung steht, was vor allem bei leistungsfähigen Macs mit Apple Silicon der Fall sein dürfte. So hat sich das Modell bei einigen Developern zu einem Lieblingsmodell für den lokalen Betrieb gemausert. Einige sind davon sogar so begeistert, dass sie es auch abseits vom Coding einsetzen.

OpenAI musste nachlegen und hat das Modell GPT-5.3-Codex veröffentlicht. Laut eigener Beschreibung ist es deutlich schneller als das Vorgängermodell und besser für agentische Aufgaben geeignet. Das neue Modell kann Code Reviews durchführen und OpenAI hat es inzwischen durch das kleinere Modell GPT-5.3-Codex-Spark ergänzt. Damit soll es sich auch für Realtime-Coding eignen. Sicher spürt OpenAI allerdings auch den Preisdruck, der durch die offenen Modelle entsteht. Coding-Modelle produzieren (insbesondere wenn sie Reasoning verwenden) notorisch viele Token, was sich in sehr hohen Kosten manifestieren kann.

Auch Coding-Primus Anthropic hat mit Claude Opus 4.6 ein neues Modell geschaffen, das sich hervorragend für Coding-Aufgaben eignet. Zusätzlich kann Opus 4.6 Finanzanalysen durchführen, Präsentationen erstellen und viele Aufgaben des täglichen Lebens übernehmen. Nicht zuletzt deswegen nutzen es viele auch für OpenClaw, was aber schnell zu unabsehbaren Kosten führen kann. Sowohl im Bereich Text als auch beim Coding ist Opus 4.6 unangefochtener Sieger bei den Arena-Leaderboards.

Wie man Coding-Modelle wirklich effizient nutzt und was man damit alles erreichen kann, hat Steve Yegge mit seinem viel beachteten Gas Town erklärt und das entsprechende Tooling gleich mit implementiert. Yegge spart dabei nicht mit Warnungen, dass man das System nur dann nutzen sollte, wenn man über die notwendigen Erfahrungen verfügt und sich auf dieses neue Paradigma auch wirklich einlassen möchte. Teilweise sind die Vorschläge extrem, aber es könnte dennoch einen Ausblick darauf bieten, wie sich agentisches Coding mit LLMs in Zukunft weiterentwickeln kann. Vorsicht ist allerdings geboten, weil Gas Town Token „verbrennt“ – die Kosten können geradezu explodieren, wenn man ein teures Modell verwendet.

OCR-Modelle

Durch die Vision-Language-Modelle ist OCR mehr und mehr zu einer Domäne der großen Sprachmodelle geworden. Nachdem es einige Monate in diesem Bereich ziemlich ruhig war, erschienen nun gleich mehrere neue Modelle.

Sehr beliebt ist das neue GLM-OCR-Modell von Z.ai. Obwohl der Anbieter ein Newcomer bei OCR-Modellen ist, stellt das Modell zumindest nach den Benchmarks die ebenfalls neuen DeepSeek-OCR-2 und PaddleOCR-VL-1.5 in den Schatten. Eine in früheren Tests verwendete iX-Seite kann das Modell nicht ganz fehlerfrei in Text wandeln, kommt aber mit den Spalten bestens zurecht – das Ergebnis liegt nur als Text vor, ist aber gut verwendbar.

Tabellen und Formeln kann GLM-OCR auch interpretieren, die Wandlung von Grafiken in Daten ist aber bisher nicht möglich.

Aber auch DeepSeek-OCR-2 hat sich gegenüber seinem Vorgänger deutlich weiterentwickelt und nutzt nun ein – interessanterweise altes – Qwen-VL-Modell als Encoder. Die iX-Seite wird dabei perfekt erkannt:

Auch das konvertierte Markdown sieht gut aus.

PaddleOCR-VL-1.5 nutzt einige neue Ansätze wie Text Spotting und kann auch Textboxen erkennen, die nicht rechteckig sind. Ein Fokus liegt außerdem auf Tabellen, die es auch über mehrere Seiten zusammensetzen kann. Als einziges der genannten Systeme kann PaddleOCR-VL-1.5 Daten aus Diagrammen extrahieren. Die iX-Seite verarbeitet es gut und benötigt dabei zwar wenig Speicher, rechnet aber äußerst lange.

Es wäre spannend zu erfahren, ob die Anbieter die aus PDF extrahierten Texte auch als Trainingsdaten für ihre großen Sprachmodelle nutzen. Dazu schweigen sich jedoch alle aus.

Neue Modelle aus China

Die stets aktiven Anbieter aus China haben sich in den vergangenen Wochen selbst übertroffen. Angeblich soll das am chinesischen Neujahr liegen, das traditionell mit Urlaub verbunden ist.

Kimi K2.5 wird von vielen als das aktuell stärkste Modell mit offenen Gewichten wahrgenommen. Moonshot hat das Modell zwar schon vor einer Weile veröffentlicht, die technischen Informationen waren aber nur spärlich. Das hat sich nun geändert, weil der zugehörige technische Bericht jetzt bereitsteht. Das Dokument berichtet ausführlich über das Training und die Evaluation des Modells. Besonders das Training hat es dabei in sich, denn Moonshot hat sowohl im Pre-Training als auch beim Reinforcement Learning multimodale Daten verwendet. Das erklärt möglicherweise auch, warum Kimi K2.5 so weit oben in der Vision-Rangliste bei arena.ai steht. Eine weitere Besonderheit stellt Agent Swarm dar: Das Modell kann Agentenaufrufe parallel durchführen, was die Geschwindigkeit bei komplexen Aufgaben stark erhöht. Diese Anforderungen berücksichtigt Moonshot bereits beim Training. Die Autoren beschreiben auch Details des Trainingsprozesses, verschweigen aber die benötigte Rechenzeit. Im Vergleich zu DeepSeek geht der Bericht weniger in die Tiefe, aber viele Details sind dennoch sehr interessant.

Mit Step-3.5-Flash betritt ein weiterer, bisher weitgehend unbekannter Player die Bühne der großen (chinesischen) Sprachmodelle. Im Vergleich zu Kimi K2.5 ist das Modell regelrecht klein, auch wenn es über 196 Milliarden Parameter verfügt (von denen elf Milliarden aktiv sind). Diese Größe ermöglicht es aber, das Modell auch auf leistungsfähiger (Mac-) Hardware in einer quantisierten Version zu betreiben. Für ein derart kleines Modell produziert es sehr ansehnliche Ergebnisse, ist aber in ersten Tests auch sehr stark chinesisch indoktriniert. Bei der Frage nach dem Heise Verlag liegt es mit dem Gründungsjahr und dem Gründer falsch. Bei politisch sensiblen Fragen verweigert sich das Modell.

Das trifft in diesem Maße nicht auf GLM 5.0 zu. Z.ai ist ein in der Zwischenzeit etablierter Anbieter offener Sprachmodelle, der auch sehr bereitwillig Auskunft über politisch heikle Themen gibt. Die Community hat diesem Modell entgegengefiebert und wurde nicht enttäuscht. Gar nicht lange nach GLM 4.7 liefert Z.ai ein extrem starkes Modell, das es insbesondere beim Coding mit fast allen kommerziellen Modellen aufnehmen kann. Auch sonst hat GLM 5.0 eine starke Performance, aber im Vergleich zum Vorgänger die Anzahl der Parameter auf 744 Milliarden Parameter (davon 40 Milliarden aktiv) mehr als verdoppelt. Es benötigte bei einer geeigneten Quantisierung auf einem Mac Studio stolze 512 GByte RAM, wenn man sich nicht in noch höhere Kosten für GPUs stürzen möchte. In den Arena-Benchmarks schneidet das Modell hervorragend ab. In unseren Tests konnte es (als eines der wenigen Modelle) das Gründungsjahr und den Gründer des Heise Verlags korrekt nennen.

Da konnte MiniMax nicht zurückstehen und hat auch noch ein neues Modell veröffentlicht. MiniMax 2.5 ist mit 230 Milliarden Parametern (davon zehn Milliarden aktiv) deutlich kleiner und kann in einer geeigneten Quantisierung auch mit 128 GByte RAM auf der CPU laufen. Noch ist es nicht in vielen Benchmarks vertreten, aber die ersten Resultate sehen gut aus. In ersten Tests gibt auch MiniMax 2.5 falsche Antworten zum Heise Verlag. Bei Fragen zu politisch heiklen Themen in China bleibt es neutral, aber sehr kurz angebunden.

Weniger stark beachtet, aber dennoch interessant ist das Modell Nanbeige4.1-3B. Es handelt sich um ein „kleines“ Reasoning-Modell mit lediglich drei Milliarden Parametern, das aber in bestimmten Benchmarks die viel größeren Qwen3-Modelle mit bis zu 32 Milliarden Parametern schlägt. Als erstes kleines Sprachmodell beherrscht es auch Deep Search und kann in bis zu 500 Runden Tools aufrufen. Es wird spannend, ob andere Modelle nachziehen können, beziehungsweise welche Fähigkeiten die großen Modelle erlangen, wenn sie ähnliche Mechanismen einsetzen.

Lange erwartet und vor ganz kurzem erschienen ist nun auch Qwen3.5. Das Modell steht in unterschiedlichen Größen zur Verfügung, allerdings fehlen aktuell noch die kleineren Modelle. Schon jetzt zeigt sich allerdings, dass Qwen3.5 sehr leistungsfähig ist und gegenüber der vorherigen Version sehr viel Boden gutgemacht hat. Die großen Qwen3.5-Modelle (wie 122B) spielen dabei fast schon in der gleichen Liga wie (das viel größere) Stepfun. Eine genauere Analyse folgt im nächsten Artikel.

Open Responses

Als Interoperabilitätsstandard hat sich die OpenAI-API etabliert. Fast immer wird dabei die completions-Ressource angefragt, obwohl der Name eigentlich nicht mehr zeitgemäß ist. Auch die Übergabe weiterer Parameter ist eher historisch gewachsen als inhaltlich motiviert. Verschlüsselung beherrscht das Interface in dieser Form gar nicht.

All diesen Problemen hat sich ursprünglich OpenAI angenommen und dafür die Responses-API geschaffen, deren Weiterentwicklung unter dem Namen Open Responses die Community übernommen hat. Auch den Umgang mit Agenten beherrscht das neue Format besser und kann somit Reasoning-Zyklen umgehen. Dabei legt das Protokoll unter anderem fest, wie viele Tools maximal aufgerufen werden dürfen.

Viele Werkzeuge unterstützen die neue API bereits. Eine Standardisierung ist nicht nur sinnvoll, sondern wichtig, weil durch die agentische Interaktion eine immer bessere Konfigurierbarkeit der Schnittstellen dringend notwendig wird.

Rasante Neuerungen, aber mit Grenzen

Die Geschwindigkeit, mit der die Anbieter neue Modelle vorstellen, hat sich in den letzten Monaten eher noch einmal erhöht. Ob das so weitergehen kann, sei dahingestellt. OpenAI stellt jedenfalls schon weniger neues Personal ein. Bei den chinesischen Anbietern ist es wesentlich intransparenter, wie lange sie sich das leisten können. Insbesondere fehlt es dort auch an Umsatz, der sich mit den offenen Modellen deutlich schwerer (und vor allem extrem schwer außerhalb Chinas) erzielen lässt.

Hinzu kommt der Hype um OpenClaw als Agent. Dessen Betrieb ist mit offenen Modellen sogar autark möglich, allerdings sind auch dann die Sicherheitsprobleme erheblich. Wenn man die Berichte darüber liest, fragt man sich, ob die Technologie wirklich schon reif genug ist, sie so „von der Leine“ zu lassen. Die Diskussionen über die Guardrails bekommen so eine ganze neue Dimension. Das trifft nicht für alle Anwender zu: Das amerikanische Verteidigungsministerium wollte Anthropic dazu zwingen, genau diese Guardrails in den von ihnen genutzten Modellen abzuschalten. Anthropic blieb standhaft. Zwar sind sie nun ihren Auftrag los, haben aber ChatGPT in den Popularitätswerten überholt.

(rme)