Connect with us

Entwicklung & Code

Preisanstieg bei KI-Coding-Tools: The Free Lunch Is Over


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Dienste wie Cursor, GitHub Copilot, Anthropic Claude Code oder Googles Gemini CLI helfen Entwicklerinnen und Entwicklern dabei, Code schneller zu schreiben, zu debuggen und Aufgaben zu automatisieren. Doch in den letzten Monaten hat sich ein klarer Trend abgezeichnet: Die Anbieter drehen an der Preisschraube. Großzügige Flatrates weichen zunehmend nutzungsbasierten Modellen und strengeren Limits. Für Poweruser entstehen teils erhebliche Mehrkosten.


Rainer Stropek

Rainer Stropek

Rainer Stropek ist IT-Unternehmer, Softwareentwickler, Trainer, Autor und Vortragender im Microsoft-Umfeld. Er ist seit 2010 MVP für Microsoft Azure und entwickelt mit seinem Team die Software Time Cockpit.

Dieser Artikel beleuchtet die aktuellen Entwicklungen bei den Preismodellen der genannten Tools, die Reaktionen der Community und die Frage, was das für Developer und Unternehmen bedeutet.

Cursor: Von der Flatrate zum Kredit-System

Der Editor Cursor vom gleichnamigen Start-up galt lange als einer der besten KI-Assistenzeditoren mit einem fairen, planbaren Preismodell. Bis vor Kurzem war im Pro-Abonnement für 20 US-Dollar im Monat ein Kontingent von 500 KI-Anfragen enthalten, weitere Requests waren gegen Aufpreis erhältlich. Dieses einfache Modell hat Cursor jedoch vor einigen Monaten ziemlich abrupt umgestellt und damit viele vor den Kopf gestoßen.

Ohne große Vorankündigung schaffte Cursor die feste Request-Grenze ab und versprach stattdessen „unbegrenzte Nutzung“ mit dynamischen Rate Limits. Was nach einer guten Nachricht klang, entpuppte sich schnell als Verschleierung einer massiven Kürzung. Aus den ehemals 500 enthaltenen Anfragen wurden plötzlich nur noch etwa 225 zum selben Preis.

Die unbegrenzte Nutzung galt zudem nur, wenn man dem System die automatische Modellwahl überließ. Wer gezielt ein bestimmtes Modell wie Claude Sonnet 4 auswählte, musste jeden Aufruf aus einem begrenzten Guthaben bezahlen. Die Community empfand dieses Vorgehen als Vertrauensbruch und sprach offen von Irreführung. In Reddit-Diskussionen fand sich der Vorwurf, Cursor habe „unlimited“ versprochen, aber stillschweigend stark limitiert.

Viele bemängelten außerdem, dass Cursor unter den neuen Rate Limits deutlich schlechtere Ergebnisse lieferte. Unter anderem hieß es in einem Beitrag, dass der KI-Assistent im begrenzten Modus oft mitten in der Aufgabe stoppte oder nur noch Teilaufgaben erledigte und dadurch mehrere Nachfragen erforderte. Benutzer haben den Verdacht geäußert, dass Cursor absichtlich die Ausgabe rationiert, damit man das inbegriffene Guthaben nicht zu schnell verbraucht. Wechselt man hingegen in die echte nutzungsbasierte Abrechnung, arbeitet das Modell plötzlich wieder wie gewohnt, allerdings zu entsprechend höheren Kosten. Das hat bei zahlenden Kundinnen und Kunden für viel Unmut gesorgt.

Besonders Poweruser von Cursor waren frustriert. Wer das Tool intensiv einsetzte, stieß deutlich früher an die Grenzen. Neben den Nutzungsgrenzen war auch die Agentenfunktion ein Grund dafür. Dieser Modus zerlegt komplexe Aufgaben in Teilschritte, führt aber auch dazu, dass ein einzelner Befehl Dutzende von API Requests im Hintergrund auslöst und massenhaft Token verbraucht. „Cursor hat mit seinem Agent die Formel geändert, sodass riesige Mengen Credits verbraucht werden“ berichtet ein Anwender auf Reddit. Diese Änderung führte dazu, dass manche Nutzer ihr Monatskontingent in wenigen Tagen verbrauchten.

Als Reaktion auf die Engpässe bot Cursor zwar neue, teurere Abo-Stufen für Vielnutzer an, kommunizierte dies aber kaum transparent. Plötzlich tauchte ein Pro+-Plan für 60 US-Dollar (dreifaches Limit) und ein Ultra-Plan für 200 US-Dollar (zwanzigfache Limits) auf. Dass Bestandskunden mehr zahlen sollten, um wieder auf das ursprünglich Gebotene zu kommen, stieß verständlicherweise vielen sauer auf. Der Begriff Enshittification für Plattformen, die im Laufe der Zeit ihre Leistungen verschlechtern, um Profit zu steigern, liegt nahe.

Cursor hat inzwischen eingeräumt, dass die Preisumstellung nicht gut gelaufen ist. Auf X erklärten die Gründer, man habe das Feedback gehört und das Ziel verfehlt. Fakt ist, dass das Vertrauen vieler früherer Fans erschüttert wurde. Zahlreiche Nutzerinnen und Nutzer sind zu Alternativen abgewandert oder ziehen dies in Betracht.

GitHub Copilot: Premium-Limits und Bezahlen nach Verbrauch

GitHub Copilot galt lange Zeit als „All you can eat“-Service für zehn US-Dollar im Monat. Im Abo waren unbegrenzt Codevervollständigungen und Chatantworten inklusive. Viele wunderten sich anfangs, wie Microsoft das Angebot wirtschaftlich gestalten will. Und tatsächlich kam im Juni 2025 die Wende: GitHub führte ein Limit für Premium Requests ein, das preislich in etwa dem entspricht, was vorher als unbegrenzt galt. Seit dem 18. Juni 2025 hat jeder zahlende Copilot-Kunde pro Monat ein Kontingent von Premiumanfragen, dessen Umfang vom konkreten Preisplan abhängt. Alles darüber hinaus kostet extra.

Unter Premium Requests versteht GitHub alle Anfragen an fortgeschrittene Modelle und Features außerhalb der GPT-Modellreihe von OpenAI. Dazu gehört insbesondere die Nutzung des für Coding besonders beliebten Modells Claude Sonnet innerhalb von Copilot. „Wollen Sie Claude oder Agent nutzen? Zählt als Premium“, fasste ein Nutzer das Vorgehen sarkastisch zusammen.

Das normale Coden mit den Basismodellen (GPT-4.1 und GPT-4o) bleibt zwar weiterhin unbegrenzt, doch alle anspruchsvolleren KI-Funktionen zählen zum Limit des jeweiligen Preisplans. Beim Überschreiten der Grenze fallen für jede weitere Anfrage 0,04 US-Dollar an, oder Copilot stellt die teuren Dienste ein, wenn man kein zusätzliches Budget freigibt. Microsoft hat dafür eigens ein Budgetmanagement in GitHub integriert: Team-Admins können ein monatliches Kostenlimit setzen und optional festlegen, dass Copilot nach Erreichen des Budgets automatisch stoppt. Standardmäßig ist das Zusatzbudget auf 0 US-Dollar eingestellt, sodass man ohne aktives Opt-in nicht mehr ausgeben kann als den Preis für das Basis-Abo.

Für Poweruser gibt es zudem einen neuen Copilot-Pro+-Plan für 39 US-Dollar im Monat, der 300 statt 1.500 Premium Requests enthält. Auch Business- und Enterprise-Kunden haben höhere Kontingente entsprechend ihrer Lizenz, müssen aber ebenfalls für Mehrverbrauch zahlen.

Viele Bestandskunden fühlen sich vor den Kopf gestoßen. Insbesondere die Kommunikation von Microsoft steht in der Kritik. Lange Zeit wurde Copilot Pro als „unbegrenzt“ beworben. Die plötzliche Einführung einer 300er-Grenze empfinden etliche zahlende Nutzerinnen und Nutzer daher als Lockangebot mit anschließendem Wechsel der Bedingungen. Der oben zitierte sarkastische Reddit-Beitrag zum Premium-Modell erhielt viel Zuspruch. Dabei bemängeln User auch, dass GitHub zum Rollout der Limits kaum Transparenz bot. So gab es anfangs keine verlässliche Möglichkeit, den eigenen Verbrauch einzusehen. Dass viele lediglich die Meldung „No usage found“ erhielten, wenn sie ihre Statistiken abrufen wollten, hat das Misstrauen verstärkt. In den offiziellen GitHub-Foren häuften sich Kommentare wie „Es fühlt sich an, als hätte man Pro nur beschnitten, um Pro+ attraktiver zu machen“.

Für Profi-Anwenderinnen und Anwender bedeutet die Änderung vor allem mehr Planungsaufwand und gegebenenfalls höhere Kosten. GitHub wirbt zwar damit, dass alle bezahlten Pläne weiterhin unbegrenzte Vervollständigungen und Chat enthalten, aber wer das volle Potenzial von Copilot ausschöpfen will, beispielsweise mit den Claude-Modellen im Agent Mode, kommt mit 300 Anfragen pro Monat, also knapp 15 Anfragen pro Arbeitstag, nicht weit. viele Entwickler stoßen nun regelmäßig an dieses Limit.

Microsoft ermöglicht mit dem Budgetfeature zumindest, Kosten bewusst zu kontrollieren. Unternehmen können die Copilot-Nutzung so überwachen. Doch letztlich führt kein Weg daran vorbei, für intensivere Nutzung tiefer in die Tasche zu greifen, entweder durch den Wechsel auf teurere Pläne oder durch das Pay-as-you-go-Modell.

Die Stimmung in der Copilot-Entwicklergemeinschaft ist geteilt. Manchen ist klar, dass die KI-Flatrate wirtschaftlich nicht haltbar war. Andere hingegen sind frustriert über die Verschlechterung des Angebots. Auffällig ist, dass Microsoft die Einführung der Limits aktiver kommuniziert hat als Cursor oder Anthropic. Es gab Blogbeiträge, Seiten in der Dokumentation und Hinweise in den FAQs. Dennoch blieb für viele unklar, was genau als Premium zählt. Aus der Dokumentation geht beispielsweise nicht klar hervor, dass der Agent Mode von Copilot intern oft viele einzelne Requests, sogenannte Tool Calls ausführt, und wie sich diese Aufrufe auf das Kontingent von Premium Requests auswirken. Für die Poweruser markieren die Änderungen am Preisplan von GitHub Copilot das Ende der sorglosen Copilot-Nutzung.



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

software-architektur.tv: Teamwork – Müssen wir darüber sprechen?


In der IT müssen die meisten Softwareentwicklerinnen, -architekten und andere Rollen aus verschiedenen Gründen in Teams arbeiten. Wer überzeugt ist, dass das nicht immer einfach ist, und zudem denkt, über Teamwork sei schon alles gesagt worden, der sollte die neue Episode nicht verpassen: denn Aino Vonge Corry und Lisa Maria Schäfer werden gemeinsam nochmals die wichtigsten Aspekte beleuchten – von Team Topologies über psychologische Sicherheit, Persönlichkeitstypen, Körpersprache, Remote-Arbeit in Teams bis hin zur ganz allgemeinen Kommunikation. Aino Vonge Corry und Lisa Maria Schäfer diskutieren all diese Themen und freuen sich auf Eure Fragen.

Weiterlesen nach der Anzeige

Aino Vonge Corry wird außerdem Ende November einen Vortrag beim Software Architecture Gathering halten, mit dem Titel „Was wir aus ‚Der Herr der Ringe‘ gelernt haben (sollten)“.

Da Lisa Maria Schäfer vor der Kamera ist, wird sie dieses Mal keine Sketchnotes malen.

Livestream am 6. November

Die Ausstrahlung findet am Donnerstag, 6. November 2025, live von 13 bis 14 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat, Bluesky, Mastodon, Slack-Workspace oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, Blogger sowie Podcaster auf iX und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff solo. Seit mittlerweile mehr als zwei Jahren bindet iX (heise Developer) die über YouTube gestreamten Episoden im Online-Channel ein, sodass Zuschauer dem Videocast aus den Heise Medien heraus folgen können.

Weitere Informationen zur Folge finden sich auf der Videocast-Seite.

Weiterlesen nach der Anzeige


(map)



Source link

Weiterlesen

Entwicklung & Code

Daily am Morgen vertreibt Kummer und Sorgen. Oder nicht?


Ein Daily, auch Stand-up oder Daily Scrum genannt, ist kein Status-Meeting. Es dient einerseits dazu, den Fortschritt in Richtung Sprint-Ziel zu hinterfragen. Das bedeutet schon mal, dass es ohne Sprint-Ziel kein Daily benötigt, oder? Der andere Zweck des Dailys besteht im Planen des bevorstehenden Arbeitstags. Wer macht was, um das Team dem Ziel näherzubringen? Aufgrund dieses Zwecks habe ich das Daily lange Zeit am frühen Vormittag verortet.

Weiterlesen nach der Anzeige


Escape the Feature Factory: Stefan Mintert

Escape the Feature Factory: Stefan Mintert

(Bild: 

Stefan Mintert

)

Stefan Mintert arbeitet mit seinen Kunden daran, die Unternehmenskultur in der Softwareentwicklung zu verbessern. Das derzeit größte Potenzial sieht er in der Leadership; unabhängig von einer Hierarchieebene.

Die Aufgabe, dieses Potenzial zu heben, hat er sich nach einem beruflichen Weg mit einigen Kurswechseln gegeben. Ursprünglich aus der Informatik kommend, mit mehreren Jahren Consulting-Erfahrung, hatte er zunächst eine eigene Softwareentwicklungsfirma gegründet. Dabei stellte er fest, dass Führung gelernt sein will und gute Vorbilder selten sind.

Es zeichnete sich ab, dass der größte Unterstützungsbedarf bei seinen Kunden in der Softwareentwicklung nicht im Produzieren von Code liegt, sondern in der Führung. So war es für ihn klar, wohin die Reise mit seiner Firma Kutura geht: Führung verbessern, damit die Menschen, die die Produkte entwickeln, sich selbst entwickeln und wachsen können.

Für Heise schreibt Stefan als langjähriger, freier Mitarbeiter der iX seit 1994.

Nach und nach hat sich mein Blick verändert, und das hat vor allem damit zu tun, dass in meinen Beratungsaufträgen ein Phänomen häufiger vorkommt: In den vergangenen Jahren treten immer mehr Entwickler an mich heran, um nach persönlichem Rat zu fragen. Es geht also nicht um Teamprobleme oder Fragen der gesamten Organisation, sondern um individuelle Herausforderungen, denen die einzelnen Personen gegenüberstehen. Dazu gehören Projektdruck, fehlende Wertschätzung und daraus resultierendes mangelndes Wohlbefinden.

Die häufigsten Fragen, die Antworten und die Tipps, die meine Kollegen und ich geben, haben wir unter dem Titel „Develop Happiness in 30 Weeks“ zusammengetragen; die Nutzung ist kostenlos. Und ein Tipp in dieser Sammlung betrifft meinen Umgang mit dem Daily.

Abschalten nach der Arbeit

Es geht darum, dass es bei hohem Projektdruck nicht leicht ist, nach der Arbeit abzuschalten. Viele Menschen nehmen die unerledigten Gedanken mit nach Hause und dort führen sie zum Grübeln und Nachdenken; ausgerechnet in einer Zeit, die sogar per Gesetz eine „ununterbrochene Ruhezeit von mindestens elf Stunden“ umfassen sollte.

Um diese Last zu vermeiden, empfehlen wir den Menschen, mit denen wir arbeiten, folgendes Vorgehen: Die letzten 15 Minuten der täglichen Arbeitszeit sollte jede Person der persönlichen Planung des nächsten Tages widmen. Von den üblichen 8 Stunden Arbeitszeit dürfen maximal 6 verplant werden. Der Plan soll aus einer kurzen Liste von To-dos bestehen. Wenn jede Aufgabe geschätzte 60 Minuten erfordert, wäre das also eine Liste von sechs Punkten; natürlich sind 6 Punkte à 60 Minuten ein Default.

Weiterlesen nach der Anzeige

Für manche Tätigkeiten passt vielleicht besser ein Punkt mit 360 Minuten. Die Zahl der To-dos darf und soll sich an die eigene Situation anpassen. Mehr als sechs Stunden dürfen es aber nicht werden. Die restlichen zwei Stunden sind für Unerwartetes reserviert. Doch damit nicht genug: Wenn die sechs Punkte abgearbeitet sind, muss man die Arbeit für den Tag beenden; vorausgesetzt der Arbeitgeber spielt mit, versteht sich. Stellt man im Laufe der Zeit fest, dass sechs Punkte und sechs Stunden nicht aufgehen, ändert man die Planung entsprechend. Wer regelmäßig nach vier Stunden fertig ist, fängt langsam an, mehr einzuplanen. Gleiches gilt für den Puffer von zwei Stunden für unerwartete Dinge.

Die Methode wirkt aus zwei Gründen:

Man bekommt an einem Arbeitstag endlich mal „alles“ fertig; nicht alles, was im Backlog steht, aber alles, was der Tagesplan enthält. Gerade für Menschen, die eine „Ever-Growing To-Do List“ haben und sich damit belasten, was sie alles nicht geschafft haben, ist das sehr wertvoll. Es funktioniert aber nur, wenn man die Arbeit wirklich beendet, sobald die geplanten Dinge erledigt sind.

Sauberer Abschluss

Die Planung am Ende des Arbeitstags sorgt nicht nur für einen Abschluss. Sie vermittelt darüber hinaus das Gefühl, dass man sich auch um die nicht erledigten Dinge gekümmert hat. Diese Dinge sind zwar nicht „done“, aber man hat sie in geeigneter Weise behandelt.

Und wie passt das mit dem morgendlichen Daily zusammen?

Je mehr Leute im Team gegen Ende eines Arbeitstags mit der 6-Punkte-Planung den nächsten Tag planen, umso mehr bietet es sich an, das Team-Daily damit zu verbinden und es zum Beispiel auf den Nachmittag zu legen. Neben dem mentalen Vorteil für jedes einzelne Teammitglied kommt hinzu, dass man am nächsten Morgen ohne Regelmeeting in einen bereits geplanten Arbeitstag starten kann. Hier kann jeder die Startzeit nach seinem persönlichen Rhythmus wählen, falls nicht ein anderes Meeting die freigewordene Daily-Lücke füllt. Zusammengefasst bin ich immer mehr geneigt, meine ehemalige Best Practice „Daily am Morgen“ aufzugeben.

Was denkt Ihr darüber? Schreibt doch mal in die Kommentare, ob und gegebenenfalls zu welcher Uhrzeit Euer Team ein Daily durchführt.

Erst Lesen, dann Handeln

Wenn Du die Themen, die ich im Blog anspreche, in Deiner Firma verbessern möchtest, komm‘ in unsere Leadership-Community für Softwareentwickler. Sie wirkt auch ohne Führungsposition. Mit dem Code „heisedev“ gibt’s den Heise-Rabatt für Interactive Members.


(rme)



Source link

Weiterlesen

Entwicklung & Code

Insomnia 12: Kong erweitert API-Tool um MCP-Unterstützung und KI-Hilfen


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Kong hat Version 12 seines Open-Source-Werkzeugs Insomnia freigegeben, ein Open-Source-Tool für die Entwicklung, das Testen und die Dokumentation von APIs. Das Update erweitert die Software um native Unterstützung für das Model Context Protocol (MCP) sowie um zwei experimentelle KI-Funktionen. Außerdem vereinfacht Kong den Zugang zu Kollaborationsfunktionen wie Git-Sync.

Weiterlesen nach der Anzeige

Ziel des Releases ist laut Ankündigungsbeitrag, API- und MCP-Entwicklung stärker zu vereinheitlichen und Routineaufgaben bei Tests und Dokumentation zu automatisieren.

MCP-Client für das Testen von Agentenschnittstellen

Das neue MCP-Feature ermöglicht es, sogenannte MCP-Server direkt aus Insomnia heraus zu testen. Diese Server stellen Werkzeuge und Prompts für KI-Agenten bereit. Über die gewohnte Oberfläche lassen sich Aufrufe ausführen, Parameter verändern und Nachrichten auf Protokollebene nachvollziehen.

Der MCP-Client soll dieselbe Art von Test- und Debugging-Workflows ermöglichen, die Insomnia bereits für klassische APIs bietet.

Automatische Mock-Server per KI

Ebenfalls neu ist die Möglichkeit, Mock-Server automatisch zu erzeugen. Nutzerinnen und Nutzer können in natürlicher Sprache beschreiben, wie die API funktionieren soll, oder eine URL, JSON-Datei oder OpenAPI-Spezifikation angeben. Auf dieser Basis erstellt Insomnia ein funktionsfähiges Mock-Setup. Der Blogbeitrag bietet hierfür anschauliche Demo-Videos.

Weiterlesen nach der Anzeige

Das Feature richtet sich an Teams, die APIs noch in der Entwurfsphase testen möchten oder keinen Zugriff auf produktive Systeme haben. Laut Kong sollen sich so einfache Simulationen in Sekunden anlegen lassen, ohne separate Skripte oder manuelle Konfiguration.

KI-Unterstützung bei Commits

Insomnia 12 schlägt außerdem Commit-Nachrichten automatisch vor. Die Software analysiert Änderungen im Repository und generiert passende Beschreibungen, die angepasst oder verworfen werden können. Ziel ist es, die Nachvollziehbarkeit von Änderungen zu verbessern, ohne zusätzliche Schreibarbeit.

Wie bei den Mock-Funktionen können Nutzer entscheiden, ob die KI-Funktion aktiviert wird und ob dafür ein externer Cloud-Anbieter oder ein lokales Sprachmodell zum Einsatz kommen soll. Kong weist darauf hin, dass KI-generierte Ergebnisse überprüft werden sollten.

Anpassungen bei Kollaborationsfunktionen

Beim Kollaborationsmodell ergänzt Kong vor allem den kostenlosen Essentials-Tarif: Git-Sync ist darin jetzt für drei Nutzende enthalten. Wer erweiterte Funktionen wie SSO, SCIM oder rollenbasierte Zugriffskontrolle testen will, kann eine 14-tägige Enterprise-Testphase starten und bis zu 50 Plätze selbst verwalten.

Mit diesen Anpassungen will Kong die Nutzung von Insomnia in kleinen Teams erleichtern, ohne dass sofort ein kostenpflichtiges Abo nötig wird.


(mdo)



Source link

Weiterlesen

Beliebt