KI-Entwicklung frisst dein Budget

Beitrag von Juni 2026 aus dem Bereich Coding von Arthur Weder

KI spart Zeit, verbrennt aber schnell Budget, wenn Prompts, Modelle und Tokens ausser Kontrolle geraten. KI-Tools wie GitHub Copilot CLI können die Softwareentwicklung massiv beschleunigen. Gleichzeitig wird mit der tokenbasierten Abrechnung immer sichtbarer, wie schnell aus produktiver Unterstützung eine unerwartet hohe Rechnung entstehen kann.

Die neue Kostenfalle der KI-Entwicklung

KI-Tools wie GitHub Copilot CLI verändern die Softwareentwicklung. Sie schreiben Code, analysieren Fehler, erklären Logs, schlagen Refactorings vor und helfen beim Debugging. Das ist beeindruckend und in vielen Fällen extrem nützlich. - auch Vibe coding genannt

Aber genau hier liegt das Problem: Je mächtiger diese Werkzeuge werden, desto schwieriger wird es, ihre Kosten zu kontrollieren.

GitHub führt mit den AI Credits eine tokenbasierte Abrechnung ein. Damit zählt nicht mehr nur, dass man ein Abo bezahlt. Entscheidend wird zusätzlich, wie intensiv ein Modell genutzt wird, wie viele Tokens verarbeitet werden und welches Modell dabei zum Einsatz kommt.

Die neue tokenbasierte Abrechnung zeigt deutlich, wohin sich KI-Entwicklung bewegt: Wer grosse Modelle, Copilot CLI und KI-Agenten intensiv nutzt, muss mit deutlich höheren Kosten rechnen. Besonders Power-User riskieren, dass aus ein paar produktiven KI-Sessions plötzlich monatliche Zusatzkosten im vierstelligen Bereich werden. Es zeigt klar: Die Zeiten der gefühlten KI-Flatrate gehen zu Ende.

Wer Copilot CLI wie einen kostenlosen Junior-Entwickler behandelt, kann plötzlich eine Rechnung wie für einen Senior-Consultant erhalten.

Warum Copilot CLI so schnell teuer werden kann

Das Problem ist nicht nur die Antwort der KI. Das Problem ist der gesamte Kontext.

Wenn ein KI-Agent ein Projekt analysiert, werden nicht nur ein paar Zeilen Code verarbeitet. Je nach Aufgabe liest das Tool Dateien, lädt Projektstruktur, prüft Zusammenhänge, erstellt Zwischenschritte, generiert Antworten und wiederholt den Prozess bei Folgefragen.

Besonders teuer wird es, wenn man Prompts schreibt wie:

Analysiere das ganze Projekt und verbessere alles.

Das klingt praktisch. Ist aber gefährlich.

Ein solcher Prompt ist wie ein Blankoscheck. Die KI weiss nicht, wo sie aufhören soll. Sie analysiert zu viel, schlägt zu viel vor, erzeugt zu viel Text und greift im schlimmsten Fall Bereiche an, die gar nicht geändert werden sollten.

Bei grossen PHP-Projekten mit Login, Rollen, Mandantenlogik, Zahlungsintegration, E-Mail-Versand, Cronjobs, Adminbereich und Datenbankstruktur kann das schnell ausufern.

Die Folge:

• mehr Tokens
• mehr Modellaufrufe
• mehr Kontext
• mehr Risiko
• mehr Kosten

Und am Ende hat man vielleicht nicht einmal eine bessere Lösung, sondern nur eine grössere Rechnung.

Die eigentliche Gefahr: Bequemlichkeit

Der teuerste Prompt ist oft nicht der komplexeste. Es ist der bequemste.

Wer schreibt:

Mach das Projekt besser.

spart vielleicht 30 Sekunden beim Formulieren. Bezahlt diese Faulheit aber mit unnötigem Kontext, unnötigen Tokens und unnötigen Risiken.

KI ist kein Zauberstab. KI ist ein Werkzeug. Und wie jedes Werkzeug muss sie präzise eingesetzt werden.

Ein Bagger ist grossartig, wenn man ein Fundament ausheben will. Aber niemand würde ihn benutzen, um eine Steckdose zu montieren.

Genau so sollte man auch mit grossen KI-Modellen umgehen.

Besser prompten statt blind bezahlen

Ein guter Prompt begrenzt die Aufgabe. Er sagt der KI nicht nur, was sie tun soll, sondern auch, was sie nicht tun darf.

Besser ist zum Beispiel:

Bitte analysiere nur den konkreten Fehler und keine vollständige Projektstruktur.

Aufgabe:
[Problem beschreiben]

Betroffene Datei(en):
- [Datei 1]
- [Datei 2]

Fehler/Log:
[Log einfügen]

Ziel:
[Was funktionieren soll]

Nicht ändern:
- Login
- Zahlungslogik
- Mandantenlogik
- Datenbankstruktur

Bitte zuerst nur erklären, was du ändern würdest. Noch nichts ändern.

Dieser Prompt ist nicht nur günstiger. Er ist auch sicherer.

Die KI bekommt klare Grenzen. Sie arbeitet gezielter. Sie lädt weniger Kontext. Sie verändert nicht versehentlich kritische Bereiche. Und sie zwingt sich zuerst zu einer Erklärung, bevor Code geändert wird.

Das ist besonders wichtig bei produktiven Webapplikationen. Login, Zahlungslogik, Mandantenfähigkeit und Datenbankstruktur sind keine Spielwiese für blinde KI-Experimente.

Kosten senken mit lokalen LLMs

Eine der spannendsten Möglichkeiten zur Kostenkontrolle ist der Einsatz lokaler Sprachmodelle.

Nicht jede Aufgabe muss über ein teures Cloud-Modell laufen. Viele alltägliche Arbeiten können lokal erledigt werden:

• Code erklären
• einfache PHP-Funktionen schreiben
• kleinere Bugs analysieren
• Logs zusammenfassen
• einfache Refactorings vorbereiten
• SQL-Abfragen prüfen
• Kommentare oder Dokumentation erzeugen

Dafür kann man zum Beispiel Ollama verwenden.

Ollama erlaubt es, Sprachmodelle lokal auf dem eigenen Rechner oder auf einem Server im eigenen Netzwerk auszuführen. Ein geeignetes Modell für Code-Aufgaben ist zum Beispiel:

qwen2.5-coder:32b

Damit entstehen keine zusätzlichen Token-Kosten bei GitHub oder einem anderen Cloud-Anbieter. Die Kosten bestehen primär aus der eigenen Hardware, Strom und Wartung.

Ollama installieren

Unter Linux kann Ollama so installiert werden:

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

Danach wird das Modell geladen:

ollama pull qwen2.5-coder:32b

Zum Testen startet man es direkt:

ollama run qwen2.5-coder:32b

Wichtig: Ein 32B-Modell braucht genügend Leistung. Auf schwacher Hardware läuft es langsam oder gar nicht sinnvoll. Für produktives Arbeiten lohnt sich ein starker Rechner mit genügend RAM oder GPU-Leistung.

Copilot CLI mit lokalem Ollama verwenden

Wenn das eigene Copilot-CLI-Setup einen OpenAI-kompatiblen Provider unterstützt, kann Ollama als lokaler Endpunkt verwendet werden.

Dazu kann man einen Alias anlegen:

alias copilocal_qwen2_coder_2_5_32b='COPILOT_PROVIDER_TYPE=openai COPILOT_PROVIDER_BASE_URL=http://127.0.0.1:11434/v1 COPILOT_PROVIDER_API_KEY=dummy COPILOT_MODEL=qwen2.5-coder:32b COPILOT_OFFLINE=true copilot'

Den Alias trägt man in die Bash-Konfiguration ein:

nano ~/.bashrc

Danach die Konfiguration neu laden:

source ~/.bashrc

Anschliessend kann Copilot CLI lokal gestartet werden:

copilocal_qwen2_coder_2_5_32b

So läuft die Arbeit nicht über ein teures Cloud-Modell, sondern über das lokale Modell.

Ollama auf einem anderen Rechner im LAN betreiben

Noch interessanter wird es, wenn Ollama auf einem stärkeren Rechner im gleichen Netzwerk läuft.

Zum Beispiel auf einem Desktop-PC, Mini-Server oder einer Workstation mit mehr Leistung.

Auf dem Ollama-Rechner öffnet man die Systemd-Konfiguration:

sudo systemctl edit ollama

Dann trägt man ein:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Danach wird der Dienst neu geladen und neu gestartet:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Vom Arbeitsrechner aus kann man dann die lokale Netzwerk-IP verwenden:

COPILOT_PROVIDER_TYPE=openai \
COPILOT_PROVIDER_BASE_URL=http://192.168.1.50:11434/v1 \
COPILOT_PROVIDER_API_KEY=dummy \
COPILOT_MODEL=qwen2.5-coder:32b \
COPILOT_OFFLINE=true \
copilot

Die IP-Adresse muss natürlich angepasst werden.

Wichtig: Ollama sollte nicht ungeschützt im Internet erreichbar sein. Diese Konfiguration ist für das interne Netzwerk gedacht. Im Zweifel per Firewall absichern.

Eine sinnvolle Modellstrategie

Wer KI-Kosten kontrollieren will, sollte nicht jedes Problem mit dem teuersten Modell lösen.

Eine pragmatische Strategie sieht so aus:

Für normale Arbeiten am PHP-Projekt:
GPT-5.4 mini

Für etwas anspruchsvollere Code-Aufgaben:
GPT-5.4

Für schwierige Bugs, Architektur, grosse Refactorings:
Claude Sonnet 4.6 nur gezielt

Für Ausnahmefälle:
Claude Opus 4.8 nur dann, wenn es wirklich nötig ist

Oder noch einfacher gesagt:

Kleine Aufgabe = kleines Modell
Normale Aufgabe = Standardmodell
Schwieriger Bug = starkes Modell
Architekturkrise = Top-Modell
Routinearbeit = lokales Modell

Das teuerste Modell ist nicht automatisch die beste Wahl. Oft ist es nur die teuerste Wahl.

Prompt-Regeln gegen explodierende KI-Kosten

Wer mit Copilot CLI, lokalen LLMs oder Cloud-Modellen arbeitet, sollte sich ein paar Regeln angewöhnen.

1. Niemals ohne Grund das ganze Projekt analysieren lassen

Schlecht:

Analysiere alles.

Besser:

Analysiere nur diese Datei und diesen Fehler.

2. Immer betroffene Dateien nennen

Je genauer der Kontext, desto kleiner der Token-Verbrauch.

3. Logs kürzen

Nicht 2’000 Zeilen Log einfügen. Nur den relevanten Ausschnitt.

4. Zuerst erklären lassen

Bevor Code geändert wird:

Bitte zuerst nur erklären, was du ändern würdest. Noch nichts ändern.

5. Kritische Bereiche schützen

Immer klar aufführen:

Nicht ändern:
- Login
- Zahlungslogik
- Mandantenlogik
- Datenbankstruktur

6. Lokale Modelle für Routine nutzen

Nicht jede Frage muss an ein teures Cloud-Modell gehen.

7. Starke Modelle nur gezielt einsetzen

Claude Sonnet oder Opus sind Werkzeuge für schwierige Fälle, nicht für jede kleine CSS-Korrektur.

Fazit: KI bleibt stark, aber sie ist nicht mehr automatisch billig

Copilot CLI und KI-Agenten sind mächtige Werkzeuge. Sie können Entwicklungsarbeit beschleunigen, Fehler schneller sichtbar machen und bei komplexen Projekten enorm helfen.

Aber die neue Realität ist klar: KI-Entwicklung hat variable Kosten.

Wer unpräzise promptet, zu grosse Kontexte lädt und jedes Problem mit dem teuersten Modell lösen lässt, bezahlt am Ende für Bequemlichkeit.

Die Lösung ist nicht, KI zu meiden. Die Lösung ist, KI bewusster einzusetzen:

• kleinere Prompts
• klarere Grenzen
• lokale LLMs für Routine
• starke Modelle nur gezielt
• Kostenkontrolle statt Blindflug

KI ist kein kostenloser Praktikant. KI ist ein Hochleistungswerkzeug. Und Hochleistungswerkzeuge sollte man nicht unbeaufsichtigt laufen lassen.