Modelle, Kosten, Betrieb.

10.1 Ein Modell ist kein Modell: Wahl nach Aufgabe

In den ersten Kapiteln hast du gelernt, dass ein Coding-Agent aus einem Sprachmodell, Werkzeugen und einer Schleife besteht. Das Sprachmodell ist dabei die austauschbarste und zugleich teuerste Komponente. Anbieter bieten fast immer mehrere Modellklassen an: große, langsame, teure Modelle mit viel Urteilsvermögen; mittlere Modelle als Arbeitspferde; kleine, schnelle, günstige Modelle für einfache, gut umrissene Aufgaben. Die Namen, Versionen und Preise ändern sich im Monatsrhythmus. Das Prinzip dahinter bleibt stabil.

Das Prinzip lautet: Nicht jede Aufgabe braucht das stärkste Modell. Im Softwarealltag mit Agenten lassen sich drei Aufgabentypen unterscheiden, die sehr unterschiedliche Anforderungen stellen.

Planen

Beim Planen zerlegt der Agent ein Ziel in Arbeitspakete, wägt Architekturvarianten ab, erkennt Abhängigkeiten und Risiken. Fehler in dieser Phase sind teuer, weil sie sich durch alle nachfolgenden Schritte ziehen: Ein falscher Schnitt erzeugt zehn falsche Build-Läufe. Gleichzeitig ist die Ausgabe eines Planungslaufs vergleichsweise kurz — ein paar Markdown-Dateien statt hunderter Zeilen Code. Hier lohnt sich ein starkes Modell: Die Mehrkosten pro Token treffen auf wenige Tokens und vermeiden teure Folgefehler.

Bauen

Beim Bauen setzt der Agent einen gut umrissenen Plan um: Dateien anlegen, Code schreiben, Tests ergänzen, Build ausführen, Fehler beheben. Diese Arbeit ist umfangreich, aber meist mechanischer. Ein solides mittleres Modell schafft sie in der Regel zuverlässig, wenn der Auftrag präzise ist — und genau dafür sorgen Spec und Plan aus den Kapiteln 4 und 5. Hier entsteht der Großteil des Token-Volumens; die Modellklasse wirkt sich daher stark auf die Gesamtkosten aus.

Prüfen

Beim Prüfen liest ein Reviewer einen Diff und meldet Befunde. Reviews sind häufig, laufen oft parallel und arbeiten mit begrenztem Kontext. Ein kleines, schnelles Modell ist hier oft ausreichend, zumal ein guter Prüfprozess ohnehin nicht nur auf ein LLM setzt, sondern regelbasierte Prüfungen (Tests, statische Analyse, Abdeckungsprüfung) danebenstellt. Wo ein Review sehr anspruchsvoll ist — etwa eine Sicherheitsbewertung — kann ein stärkeres Modell sinnvoll sein.

Modellwahl ist eine Konfigurationsfrage, keine Code-Frage

Weil Modelle schnell veralten, sollte kein Modellname fest in Werkzeugen, Skripten oder Prompts verdrahtet sein. Wer die Modellwahl zentral konfiguriert, kann bei einem neuen Modell an einer Stelle umstellen — und weiß hinterher, welcher Lauf mit welchem Modell entstanden ist. Diese Nachvollziehbarkeit ist nicht nur Ordnungsliebe: Wenn ein Ergebnis auffällt, ist „welches Modell war das?“ eine der ersten Fragen.

10.2 Tokens: die Währung der Agenten

Sprachmodelle rechnen in Tokens. Ein Token ist ein Textbaustein — grob ein Wortteil; im Deutschen entfallen auf ein Wort oft mehr Tokens als im Englischen, und Quellcode mit vielen Sonderzeichen ist ebenfalls tokenreich. Abgerechnet wird bei API-Nutzung typischerweise getrennt nach drei Arten:

Grafik in voller Größe öffnenGrafik in voller Größe öffnen

Warum Agentenläufe so viel Input verbrauchen

Erinnere dich an die Agenten-Schleife aus Kapitel 2: Das Modell denkt, ruft ein Werkzeug auf, bekommt das Ergebnis, denkt weiter. Bei jeder Runde wird der gesamte bisherige Kontext erneut verarbeitet — die Anweisungen, der Projektkontext, alle bisherigen Werkzeugaufrufe und ihre Ergebnisse. Ein Lauf mit vierzig Werkzeugaufrufen verarbeitet den Anfang des Kontexts also rund vierzigmal. Liest der Agent dabei eine große Logdatei oder einen langen Testreport ein, wandert dieser Text in alle folgenden Runden mit.

Daraus folgt eine wichtige Einsicht: Die Kosten eines Agentenlaufs wachsen nicht linear mit der Aufgabengröße, sondern eher mit der Zahl der Runden mal der Kontextgröße. Ein unklarer Auftrag, der den Agenten zum Suchen und Ausprobieren zwingt, ist deshalb doppelt teuer: mehr Runden und mehr Kontext.

Prompt-Caching

Viele Anbieter bieten Prompt-Caching an: Ein gleichbleibender Anfang des Kontexts (Präfix) wird beim ersten Mal gespeichert und bei folgenden Anfragen günstiger wiederverwendet. Das passt gut zu Agenten, weil Anweisungen, Werkzeugdefinitionen und Projektkontext von Runde zu Runde identisch bleiben. Die Details unterscheiden sich je Anbieter (Lebensdauer des Caches, Mindestgröße, Preisaufschlag für das Schreiben, Rabatt für das Lesen); allgemein gilt:

• Das Schreiben in den Cache kostet in der Regel etwas mehr als normaler Input, das Lesen deutlich weniger.
• Caching wirkt nur auf einen stabilen Präfix. Wer an den Anfang des Kontexts ständig wechselnde Inhalte stellt (Zeitstempel, zufällige Reihenfolgen), verhindert Cache-Treffer.
• Agent-CLIs nutzen Caching meist automatisch. Du beeinflusst es vor allem indirekt: durch stabile Projektdateien und Anweisungen.

Abo statt Token-Rechnung

Neben der API-Abrechnung pro Token bieten Anbieter von Coding-Agenten auch Abonnements an, bei denen Läufe gegen Nutzungslimits zählen statt gegen eine Rechnung. Die Bedingungen ändern sich häufig und sind an die Nutzungsbedingungen des jeweiligen Anbieters gebunden — insbesondere, für wen und wofür ein persönliches Abo gedacht ist. Für die Fabrik ist der aktuelle Stand im Benutzerhandbuch und auf der Seite Abo-Setup beschrieben.

10.3 Kostenhebel: was wirklich spart

Wer Agentenkosten senken will, denkt oft zuerst an ein günstigeres Modell. Das ist ein Hebel, aber selten der größte. Die wirksamsten Hebel setzen früher an.

Hebel 1: Präzise Aufträge

Ein präzises Ziel mit klaren Akzeptanzkriterien reduziert die Zahl der Runden drastisch. Der Agent muss weniger suchen, weniger raten und weniger nachbessern. Hier zahlt sich die Arbeit aus Kapitel 4 (Specs und EARS) und Kapitel 5 (Planen) direkt in Tokens aus: Ein Build-Run gegen ein gut geschnittenes Backlog-Item mit gebundenen Akzeptanzkriterien ist kürzer als ein Run mit dem Ziel „mach die Auftragsverwaltung fertig“.

Hebel 2: Kontext klein und stabil halten

• Klein: Nur das in den Kontext, was der Auftrag braucht. Riesige Logausgaben, generierte Dateien oder Abhängigkeitsverzeichnisse sind teurer Ballast.
• Stabil: Projektdateien, Anweisungen und Guardrails sollten sich nicht bei jedem Lauf ändern. Das hilft dem Caching und macht Ergebnisse vergleichbarer.
• Kuratiert: Ein gepflegtes Projektgedächtnis mit den wichtigsten Entscheidungen ist besser als ein wachsender Haufen ungefilterter Notizen.

Hebel 3: Die richtige Modellklasse

Wie in 10.1 beschrieben: starkes Modell für Planung, Arbeitspferd für den Bau, kleines Modell für Reviews. Wichtig ist, die Wahl zu messen, nicht zu raten. Wenn ein günstigeres Build-Modell doppelt so viele Korrekturschleifen braucht, ist es am Ende nicht günstiger.

Hebel 4: Keine blinden Wiederholungen

Ein fehlgeschlagener Lauf, der unverändert noch einmal gestartet wird, kostet dasselbe noch einmal — mit ähnlicher Erfolgsaussicht. Eine Wiederholung lohnt sich nur, wenn eine neue Information hinzukommt: Compiler-Ausgabe, Testfehler, Reviewer-Befund, Merge-Konflikt, eine geänderte Anweisung. Genau dieses Prinzip setzt die Fabrik bei ihrer Korrekturschleife um (Kapitel 6): Sie speist das Build- oder Gate-Feedback in den erneuten Lauf ein und begrenzt die Versuche.

Hebel 5: Kleine Schritte

Ein großer Lauf, der nach einer Stunde an einer Kleinigkeit scheitert, verbrennt viel. Mehrere kleine Läufe mit je einem prüfbaren Ergebnis scheitern billiger und lassen sich gezielter korrigieren. Das ist dieselbe Logik wie bei kleinen Pull Requests — nur dass hier zusätzlich Geld am Spiel ist.

10.4 Mandanten, Rollen und das Vier-Augen-Prinzip

Sobald mehr als eine Person mit Agenten arbeitet, stellen sich zwei Fragen: Wer darf was? und Wer sieht was? Die erste beantwortet ein Rollenmodell (RBAC, Role-Based Access Control), die zweite eine Mandantentrennung.

Rollen: abgestufte Rechte

Gute Rollenmodelle für Agentenplattformen trennen mindestens drei Dinge: Lesen, Ausführen und Freigeben. Ausführen heißt, Agenten Code schreiben zu lassen — das kostet Geld und verändert Repositories. Freigeben heißt, die Verantwortung für ein Ergebnis zu übernehmen. Wer diese Rechte nicht trennt, verliert das Vier-Augen-Prinzip: Dieselbe Person beauftragt den Agenten und winkt sein Ergebnis durch.

Mandanten: harte Sichtgrenzen

Ein Mandant ist eine abgeschottete Einheit — etwa eine Abteilung, ein Kunde oder eine Tochtergesellschaft. Daten eines Mandanten dürfen für andere nicht sichtbar sein, auch nicht über geratene IDs. Das ist mehr als eine Komfortfunktion: Agentenläufe enthalten Quellcode, Anforderungen, Logs und Kosten, also häufig vertrauliche Informationen.

Single Sign-On

In Unternehmen kommt die Identität meist aus einem zentralen Identitätsanbieter (OIDC). Ein wichtiger Sicherheitsgrundsatz dabei: Die Anbindung darf Zugriff nie versehentlich erweitern. Neue, automatisch angelegte Nutzer sollten minimal berechtigt starten; die eigentliche Zuordnung bleibt eine bewusste administrative Handlung.

10.5 Betriebsformen und Betriebsmodi

Agentenplattformen werden sehr unterschiedlich betrieben: von der Einzelperson am eigenen Laptop bis zur abgeschotteten Behördeninstallation ohne Internet. Die Betriebsform entscheidet über drei Fragen:

• Wie kommt das Modell ins Spiel? Persönliches Abo, API-Key, Cloud-Gateway oder lokales Modell.
• Wie viele Menschen teilen sich die Instanz? Davon hängen Rollen, Mandanten und Budgets ab.
• Wie viel Netz ist erlaubt? Von „alles“ bis „nichts“ (Air-Gap).

Ein Punkt verdient besondere Aufmerksamkeit: Persönliche Abos sind persönlich. Ein Abo, das für die individuelle Nutzung eines Coding-Agenten gedacht ist, ist kein Zugang, den sich ein Team über eine gemeinsame Plattform teilen sollte. Sobald mehrere Personen eine Instanz nutzen, gehören die Läufe auf API-Keys oder ein Gateway — mit sauberer Abrechnung und klaren Nutzungsbedingungen.

Konfiguration ohne Neustart

Für den Alltag hilfreich ist eine Konfigurationshierarchie: allgemeine Vorgaben global, Abweichungen pro Nutzer oder Projekt. So muss nicht jedes Projekt alles neu festlegen, und Sonderfälle bleiben sichtbar an ihrem Ort.

10.6 Zusammenfassung

• Modellklassen nach Aufgabe wählen: stark für Planung, Arbeitspferd für den Bau, klein für Reviews — und die Wahl messen.
• Agentenkosten wachsen mit Runden mal Kontextgröße. Präzise Aufträge und kleiner, stabiler Kontext sind die größten Hebel.
• Prompt-Caching belohnt stabile Präfixe; Cache-Schreiben kostet etwas mehr, Lesen deutlich weniger.
• Wiederholen nur mit neuer Information.
• Die Fabrik löst das Modell nach Override → Team → Rollen-Default (nur Claude) → CLI-Wahl auf und attestiert die Quelle.
• Euro-Werte im Claude-Abo-Modus sind Schätzungen zum API-Tarif, keine Rechnung.
• Budgets erst beobachtend, dann als Hard-Cap je Mandant; Seat-Sicht wertet aus, begrenzt aber nicht.
• Rollen trennen Ausführen und Freigeben; ADMIN ist kein Daten-Super-Admin; SSO-Nutzer starten als VIEWER ohne Mandant.
• Persönliche Abos gehören in den Einzelplatz; Teams arbeiten im TEAM_API_POOL.

Kapitelfragen

1. Warum lohnt sich für Planungsläufe oft ein teureres Modell als für Build-Läufe?

   Musterantwort

   Planungsfehler vervielfachen sich, weil alle folgenden Build-Läufe auf dem Plan aufbauen. Gleichzeitig erzeugt ein Plan-Lauf vergleichsweise wenig Output. Die Mehrkosten pro Token treffen also auf wenige Tokens und verhindern teure Folgefehler. Build-Läufe erzeugen dagegen das meiste Volumen bei eher mechanischer Arbeit, wo ein mittleres Modell meist genügt.

2. Erkläre, warum die Kosten eines Agentenlaufs nicht linear mit der Größe der Aufgabe wachsen.

   Musterantwort

   In jeder Runde der Agenten-Schleife wird der gesamte bisherige Kontext erneut verarbeitet: Anweisungen, Projektkontext, alle Werkzeugaufrufe und ihre Ergebnisse. Die Kosten wachsen daher grob mit der Zahl der Runden mal der Kontextgröße. Unklare Aufträge erhöhen beides, große eingelesene Ausgaben blähen jede Folgerunde auf.

3. Ein Build-Run mit dem Adapter claude lief mit Sonnet, obwohl du am Developer-Agenten Opus eingetragen hast. Welche Ursache ist am wahrscheinlichsten, und wo prüfst du das?

   Musterantwort

   Ein Routing-Override run.routing.build-model hat Vorrang vor dem Wunschmodell des Teams. Alternativ wurde ein anderes Team gewählt. Im Warum-Trace (/runs/{id}/trace) zeigt RUN_MODELL_AUFGELOEST mit quelle=override, team, rollen-default oder adapter-default, woher das Modell kam.

4. Warum bekommt ein Lauf mit dem Adapter Aider keinen Claude-Rollen-Default?

   Musterantwort

   Aider (wie auch Bedrock/Vertex/Azure, Local-LLM und Kimi) reicht --model unverändert an seine eigene CLI bzw. sein Backend durch. Ein Claude-Modellname wäre dort falsch oder bedeutungslos. Für diese Adapter gelten das Standardmodell je Adapter oder die Wahl der CLI.

5. In der Kostensicht steht für einen Claude-Lauf ein Euro-Betrag mit dem Vermerk „Schätzung (API-Tarif), nicht abgerechnet“. Was bedeutet das, und zählt der Betrag gegen das Budget?

   Musterantwort

   Der Lauf lief im Abo-Modus und zählt gegen die Nutzungslimits des Abos, eine API-Rechnung entsteht nicht. Die Fabrik bewertet die Tokens trotzdem zum API-Tarif, um die erzeugte Last sichtbar zu machen. Der Betrag zählt im Verbrauch und damit gegen Budget und Hard-Cap.

6. Ein Lauf mit mehreren hunderttausend Tokens erscheint mit 0 €. Welche zwei Erklärungen gibt es?

   Musterantwort

   Entweder ist es ein Flatrate-Modell (z. B. k3, kimi-for-coding), für das bewusst 0 € geführt werden, oder das Modell hat keinen Eintrag in der Preistabelle in application.yml und wird konservativ mit 0 € bewertet. Im zweiten Fall sollte die Tabelle ergänzt werden.

7. Eine Administratorin beschwert sich, dass sie die Projekte eines anderen Mandanten nicht sieht. Ist das ein Fehler? Was ist zu tun?

   Musterantwort

   Kein Fehler: ADMIN ist in der Fabrik kein Super-Admin für Daten. Projekte, Runs, Logs und Kosten bleiben mandanten-gescopt. Isolationsfrei sind nur Kontenverwaltung und Projektzuweisung. Lösung über die Mandantenzuweisung (Konto bzw. Projekt dem richtigen Mandanten zuordnen) oder eine bewusste organisatorische Regelung.

8. Warum erhalten per SSO neu angelegte Nutzer die Rolle VIEWER ohne Mandant, und welches allgemeine Prinzip steckt dahinter?

   Musterantwort

   Eine SSO-Anbindung darf Zugriff nie versehentlich erweitern. Minimale Rechte beim ersten Login und eine bewusste administrative Zuordnung von Rolle und Mandant setzen das Prinzip der geringsten Rechte (least privilege) und der fail-safe defaults um.

9. Transfer: Du sollst die Agentenkosten deines Teams um ein Drittel senken. Nenne drei Maßnahmen in der Reihenfolge, in der du sie prüfen würdest, und begründe die Reihenfolge.

   Musterantwort

   Beispiel: (1) Aufträge präzisieren und kleiner schneiden (Specs mit Akzeptanzkriterien, Backlog-Items statt Mega-Ziel), weil das Runden und Kontext zugleich reduziert. (2) Wiederholungen ohne neue Information abstellen und Korrekturschleifen auswerten, weil blinde Retries reine Verschwendung sind. (3) Erst danach die Modellklassen je Aufgabe anpassen und die Wirkung in /analytics messen, weil ein günstigeres Modell mit mehr Korrekturen am Ende teurer sein kann.

10. Welche drei Dinge musst du sichern, und warum gehört der Attestierungs-Schlüssel dazu?

    Musterantwort

    Die PostgreSQL-Datenbank, das Workspace-Verzeichnis mit den Git-Repositories und den Attestierungs-Schlüssel samt Secrets-Master-Key. Ohne den Attestierungs-Schlüssel lässt sich die signierte Audit-Kette später nicht mehr verifizieren; ohne Master-Key sind gespeicherte Secrets nicht mehr lesbar. Nach dem Restore zeigt die Kettenprüfung unter /attestierung, ob die Sicherung vollständig war.