Budgets und Kosten

Modellnutzung kostet Geld, und ein Coding-Agent in einer Schleife kann davon viel verbrauchen. kanman setzt pro Team harte Ausgabengrenzen, zeigt die Kosten jedes Runs live an und stoppt, bevor eine Grenze überschritten wird, nicht danach.

Die drei Budgets

Budgets legen Sie im Team unter Einstellungen > Grenzen und Budgets fest (/<workspace>/teams/<team>/settings/limits), oder Sie fragen kanman im Chat des Teams: „Zeig mir das Budget“. Alle Beträge sind in EUR. Alte Links auf die frühere Seite Budgets führen zur Karte Ausgaben dieser Seite. Sie enthält alles, was das Team begrenzt:

• Arbeit gleichzeitig: Stories gleichzeitig, mit einer Anzeige, welche Obergrenze gilt: die eigene Einstellung des Teams, der Tarif des Teams oder die Gesamtzahl des Workspaces.
• Ausgaben: das Run-Budget und die Budgets pro Tag und pro Monat, für Monat und Tag jeweils mit einer Anzeige, was das Team bisher ausgegeben hat. Bei Teams, die den Modellzugang des Runners nutzen, zeigt diese Karte stattdessen die Grenzen des Runners in Minuten und Runs.
• Was ich ändern darf: geschützte Pfade und die Secrets, die Runs nutzen dürfen, als Chips. Manche Pfade sind immer geschützt und erscheinen als gesperrte Chips; Namen von Secrets werden aus den Secrets des Workspaces vorgeschlagen.
• Mit der Zeit besser werden: ob kanman frühere Stories des Teams erneut ausführen darf, um in seiner Arbeit besser zu werden, und das monatliche Limit dafür (siehe Mit der Zeit besser werden).
• Erweitert: wie viele fehlgeschlagene Prüfungen eine Story sammeln darf, bevor kanman fragt, und wie oft kanman nach langen Runs sieht.

Jede Änderung wird sofort gespeichert: Daneben erscheint kurz Gespeichert, und Rückgängig holt den vorherigen Wert zurück.

Tage und Monate zählen in der Zeitzone der Team-Arbeitszeiten, ohne Arbeitszeiten in UTC.

Bevor ein Run startet, prüft kanman das Tages- und das Monatsbudget. Ist eines davon aufgebraucht, wartet die Story in Ready und startet, sobald der nächste Tag oder Monat beginnt. Das ist ein Warten, keine Frage, es entsteht also keine Entscheidung. Die Prüfung steht im Audit-Log als policy_decision, jeder Run, der an seinem Budget stoppt, als budget_stop.

Wenn ein Run sein Budget erreicht

Ein Run, der sein Budget überschreiten würde, stoppt an dem Schritt, an dem er die Grenze überschreiten würde. kanman sagt das im Chat des Teams mit den Beträgen, zum Beispiel „Ich habe SBX-12 angehalten: Es hat 0,80 € verbraucht, sein Budget ist 0,50 €. Ich empfehle, es auf 1,00 € zu erhöhen.“, und der Entscheidungseingang fragt, ob das Budget für diesen Run erhöht werden soll, mit den Optionen Auf … erhöhen (das Doppelte des aktuellen Run-Budgets, zum Beispiel 1,00 EUR bei einem Run mit 0,50 EUR) und Abbrechen. Eine Erhöhung setzt den Run fort. Ein Abbruch beendet den Run und verschiebt die Story zurück ins Backlog, mit Ihrer Notiz als Kommentar.

Die Prüfung auf festgefahrene Runs erkennt außerdem Runs, deren Ausgaben zwischen zwei Versuchen das Run-Budget erreicht haben. Ein solcher Run wird geparkt, und der Entscheidungseingang bietet an, sein Budget um ein weiteres Run-Budget zu erhöhen und fortzufahren oder ihn zu stoppen, was kanman empfiehlt.

Dringende Arbeit wird nie blockiert

Stories mit der Serviceklasse expedite und Vorfallsarbeit wie eine CI-Regression, ein Ausfall oder ein Sicherheitsfix werden nie durch Budgets oder Drosselung gestoppt. Sie zählen trotzdem zu den Ausgaben, Sie sehen sie also in den Summen.

Was etwas kostet

• Run-Seite: Die Kennzahlen im Überblick zeigen die Kosten des Runs gegen sein Budget; der Reiter Kosten & Details zeigt die Kosten jedes Versuchs.
• Nachweispaket: Kosten und Dauer gehören zu jedem Paket am Pull Request.
• Team-Bericht: Der Wochenbericht im Reiter Berichte des Teams zeigt die Ausgaben des Teams und die Kosten pro gemergtem Pull Request.
• Team-Einstellungen: Einstellungen > Grenzen und Budgets zeigt die Ausgaben des laufenden Monats, einschließlich dessen, was Runs, die noch laufen oder auf Sie warten, bisher verbraucht haben.

Kosten niedrig halten

Der wichtigste Hebel ist das Komplexitäts-Routing: Triviale Stories gehen an ein kleines Modell mit kurzem Turn-Budget, die Spitzenmodelle bleiben komplexer Arbeit vorbehalten. Siehe Runs. Kleine, gut geschriebene Stories kosten weniger und scheitern seltener, siehe Anforderungen schreiben, die kanman abschließen kann.

Mit der Zeit besser werden

kanman wird mit der Zeit besser in der Arbeit Ihres Teams, indem es aus den Stories lernt, die es für dieses Team schon fertiggestellt hat. Die Einstellung Mit der Zeit besser werden ist für jedes Team eingeschaltet, und Sie können sie jederzeit ausschalten.

So funktioniert es:

• Frühere Stories noch einmal ausführen. Wenn das Team ruhig ist (außerhalb seiner Arbeitszeiten und ohne Story, die auf einen freien Platz wartet), nimmt kanman gemergte Stories dieses Teams und führt sie ab dem Punkt erneut aus, an dem der echte Run begann: mit der Story, wie sie damals geschrieben war, dem Code von damals und dem, was kanman damals wusste. Jede Wiederholung probiert eine Änderung an kanmans Arbeitsweise aus, zum Beispiel eine andere Art, vor dem Schreiben von Code Kontext zu sammeln.
• Geprüft wie echte Arbeit. Die Tests, die mit der gemergten Änderung kamen, entscheiden, ob eine Wiederholung die Story gelöst hat. Stories, deren Tests nicht jedes Mal dasselbe Ergebnis liefern, bleiben außen vor.
• Nur behalten, wenn es besser ist. kanman vergleicht die Wiederholungen mit und ohne die Änderung und behält eine Änderung nur, wenn sie mindestens genauso viele Stories löst und deutlich günstiger, schneller oder öfter richtig ist. Danach prüft kanman die Änderung weiter an neuer Arbeit und nimmt sie von selbst zurück, wenn die Ergebnisse des Teams schlechter werden.
• Was kanman ausprobiert, sobald genug Verlauf da ist. Zuerst kleine Änderungen daran, wie kanman Kontext sammelt und eine Story abarbeitet. Mit wachsendem Verlauf des Teams kommt mehr dazu: Eine Vorgehensweise, die kanman aus früheren Stories gelernt hat, nutzt es in echter Arbeit erst, nachdem die Wiederholungen gezeigt haben, dass sie hilft; einfache Stories können zu einem kleineren, günstigeren Modell wechseln; kanmans eigene Prüf- und Planungsschritte bekommen ein paar Hinweise, die für dieses Team geschrieben sind; und die schwierigsten Stories können zwei Versuche bekommen, von denen kanman den behält, dessen Prüfungen bestehen. Jede dieser Änderungen startet erst, wenn das Team genug fertige Stories hat, um sie fair zu beurteilen, und bleibt nur, wenn sie sich bewährt.
• Nie auf Ihrem Code-Host. Wiederholungen lesen das Repository und sonst nichts: Sie pushen nie, öffnen keinen Pull Request, kommentieren nicht und ändern nichts im Tracker.
• Nie auf Kosten echter Arbeit. Eine Wiederholung startet nur, wenn im Team nichts wartet, konkurriert nie mit Stories um einen Platz und stoppt, wenn die Runs des Workspaces gestoppt werden.

Wo sie laufen und wer bezahlt. Wiederholungen nutzen den eigenen Modellzugang des Teams, genau wie seine echten Runs: den eigenen Schlüssel des Teams, die Abrechnung über kanman oder den Runner des Teams mit dessen Modellzugang. Bei Teams, die alles auf ihren eigenen Runnern ausführen, laufen auch die Wiederholungen dort.

Das Limit. Standardmäßig nutzen Wiederholungen pro Kalendermonat höchstens 5 % dessen, was das Team in den letzten 30 Tagen für Modelle ausgegeben hat. Sie können einen anderen Anteil (1 bis 25 %) oder einen festen Betrag pro Monat einstellen. Wiederholungen nutzen nie das letzte Zehntel des Monatsbudgets des Teams, damit Arbeit nie ihretwegen am Budget stoppt. Ihre Kosten zählen zu den Ausgaben des Teams und stehen wie jede andere Modellnutzung auf der Rechnung.

Ihre Daten bleiben in Ihrem Workspace. Es werden nur die Stories dieses Teams verwendet, und nur für dieses Team. Nichts wird mit anderen Workspaces geteilt, und kanman lernt nicht kundenübergreifend.

Wann kanman Bescheid sagt. Wenn es für ein Team zum ersten Mal greift, sagt kanman das einmal im Chat des Teams, mit Wie funktioniert das? und Das will ich nicht (Inhaber und Admins schalten es dort sofort aus, mit Rückgängig). Der Wochenbericht sagt danach in einem Satz, was in der Woche getestet wurde und ob kanman eine Änderung behalten hat.

Wo Sie es ändern. Unter Einstellungen > Grenzen und Budgets des Teams, Karte Mit der Zeit besser werden: der Schalter, das monatliche Limit und was in diesem Monat genutzt wurde, mit der Zahl der Wiederholungen, getesteten und behaltenen Änderungen. Im Local-Plan, der keine Runs startet, ist es nicht verfügbar.

Modellnutzung bezahlen

Jedes Team wählt einen von zwei Abrechnungsmodi (billing_mode):

Einen Schlüssel hinterlegen Sie unter Workspace-Einstellungen > Modellzugang und wählen ihn dann beim Einrichten des Teams. Auf derselben Seite legt Neue Teams nutzen fest, mit welchem Modus neue Teams starten (Was neue Teams nutzen). Claude Code arbeitet mit einem Schlüssel für Anthropic oder Amazon Bedrock, Codex mit einem für OpenAI oder Azure OpenAI. Unter Einstellungen > Agent und Modelle des Teams sehen Sie bei der Abrechnung der Modellnutzung, welchen Modus es nutzt. Schlüssel werden verschlüsselt gespeichert und nach dem Speichern nie wieder angezeigt.

Budgets gelten in beiden Modi. Mit BYOK schützen sie Ihre Rechnung beim Anbieter. Runs auf einem Modell, dessen Preis kanman nicht kennt (bei den Modellnamen eines KI-Gateways häufig), zeigen Modellnutzung in Tokens statt Kosten, und Euro-Budgets können sie nicht stoppen; das Turn-Limit jedes Runs gilt weiterhin.

kanmans Assistenzschritte (Entwürfe, Antworten in der Unterhaltung, der Reviewer, der Spec-Autor) folgen dem Modus des Coding-Agents, außer das Team gibt ihnen unter Einstellungen > Agent und Modelle bei Modellzugang für kanmans Assistenzschritte einen eigenen.

Tarifgebühren sind von der Rechenleistung getrennt. Siehe Tarife und Abrechnung.

Verwandte Seiten

• Richtlinien-Einstellungen: Budgets
• Entscheidungen
• Was Modellanbieter sehen