KI-Agent auf VPS: Kosten im Dauerbetrieb begrenzen

So verhindern Sie, dass ein dauerhaft laufender KI-Agent hohe Kosten verursacht

Bei der Kostenkontrolle für einen KI-Agenten auf einem VPS (virtueller privater Server) legen Sie die Obergrenzen fest, bevor der Agent startet. Während des Betriebs überwacht niemand den Zähler. Begrenzen Sie jede Antwort mit max_tokens, beschränken Sie die Schleifendurchläufe in Ihrem eigenen Code, cachen Sie den unveränderlichen Teil des Prompts und protokollieren Sie die Nutzungswerte jeder Antwort. So sehen Sie, welcher Job Kosten verursacht. Die Miete für den Server ist ein fester monatlicher Preis. Die API des Modells wird pro Token abgerechnet. Eine unbeaufsichtigte Schleife kann daher unbemerkt sehr viele Tokens verbrauchen.

Vorausgesetzt wird ein bereits vorhandener Agent, der die Messages API von einem von Ihnen verwalteten System aus aufruft. Einen KI-Agenten mit Claude auf einem VPS erstellen beschreibt die technische Einrichtung.

Warum ein unbeaufsichtigter Agent eine andere Kostenstruktur hat

In einer interaktiven Sitzung ist ein Mensch beteiligt. Wenn das Modell einen falschen Weg einschlägt oder ein Log mit 40,000 Zeilen liest, stoppt die beobachtende Person den Vorgang. Ein unbeaufsichtigter Agent hat keine solche Bremse: Er läuft, bis die Schleife endet, und ein Timer startet ihn anschließend erneut.

Die Häufigkeit ist der Multiplikator, den viele übersehen. Ein Job mit einem Zeitplan von fünf Minuten läuft 288-mal pro Tag und ungefähr 8,640-mal pro Monat. Multiplizieren Sie die Kosten eines einzelnen Laufs mit dieser Zahl. Viele „Always-on“-Agenten müssen nicht ständig laufen. Sie müssen innerhalb einer bestimmten Anzahl von Minuten antworten. Dafür reicht ein Zeitplan.

Ein Agent verursacht außerdem Kosten für Dinge, die ein Chatfenster nicht benötigt.

• Tooldefinitionen werden bei jeder Anfrage mitgesendet. Der System-Prompt für die Tool-Nutzung kostet bei Claude Opus 4.8 mit tool_choice von auto oder none 290 Tokens und mit any oder tool 410 Tokens. Das bash-Tool fügt weitere 325 Tokens hinzu. Jeder MCP-Server, den Sie anbinden fügt seine Schemas zu diesem Umfang hinzu; MCP steht für Model Context Protocol.
• Tool-Ergebnisse sind Eingabetokens. Ein Befehl, der 8,000 Zeilen ausgibt, fügt der nächsten Anfrage 8,000 Zeilen hinzu und jeder weiteren Anfrage innerhalb dieses Durchlaufs ebenfalls.
• Abgerufene Seiten sind Eingabetokens. Eine durchschnittliche Webseite mit 10 kB entspricht ungefähr 2,500 Tokens, ein Forschungs-PDF mit 500 kB ungefähr 125,000 Tokens. max_content_tokens kürzt nur Textinhalte, weil es „auf Textinhalte angewendet wird, nicht auf Binärinhalte wie PDFs“. Begrenzen Sie ein PDF stattdessen mit max_uses und allowed_domains.
• Websuche wird pro Suche abgerechnet, mit $10 pro 1,000 Suchen, unabhängig davon, wie viele Ergebnisse zurückgegeben werden. Eine Suche, die mit einem Fehler endet, wird nicht berechnet.

Nichts davon ist bei einem einzelnen Lauf teuer. Bei 8,640 Läufen summiert es sich jedoch erheblich.

Harte und weiche Obergrenzen lösen unterschiedliche Probleme

max_tokens wird durchgesetzt. Es handelt sich um eine harte Obergrenze für die Gesamtausgabe einer Anfrage, einschließlich Denkprozess und Antworttext. Claude erzeugt niemals mehr als diesen Wert, und das Modell kann die Zahl nicht sehen. Wird die Grenze erreicht, liefert Claude stop_reason: "max_tokens" und eine abgeschnittene Antwort. Für Agenten gilt: Jede Anfrage in einer Tool-Use-Schleife hat ein eigenes max_tokens. Damit wird eine einzelne Antwort begrenzt, nicht die gesamte Aufgabe. Zehn Tool-Aufrufe mit jeweils 4,000 ergeben für den Durchlauf eine Obergrenze von 40,000 Tokens.

Ein Aufgabenbudget ist eine Richtlinie. task_budget liegt innerhalb von output_config und gibt dem Modell an, wie viele Tokens für die gesamte agentische Schleife zur Verfügung stehen. Dabei werden Denkprozess, Tool-Aufrufe, Tool-Ergebnisse und Ausgabe mitgezählt.

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"Aufgabenbudgets sind ein unverbindlicher Hinweis, keine harte Obergrenze." Claude kann diese Grenze während einer Aktion überschreiten. Die durchgesetzte Ausgabelimitierung bleibt trotzdem max_tokens. "Der Countdown ist nur für das Modell sichtbar", und Antworten enthalten kein Feld mit dem verbleibenden Budget. Der kleinste akzeptierte Wert für task_budget.total beträgt 20,000 Tokens. Ein kleinerer Wert führt zu einem 400-Fehler. Ein für die Aufgabe zu kleines Budget führt zu einem Verhalten, das einer Ablehnung ähnelt. Das Modell grenzt die Aufgabe dann ein oder beendet sie vorzeitig.

Ein Detail verursacht Kosten, statt sie zu reduzieren. Wenn Ihr Client task_budget.remaining bei jeder Folgeanfrage verringert, macht der geänderte Wert jeden zwischengespeicherten Präfix ungültig, der diesen Wert enthält. Setzen Sie den Wert einmal in der ersten Anfrage.

Aufgabenbudgets befinden sich bei Claude Fable 5, Claude Opus 4.8 und Claude Opus 4.7 in der Beta-Phase. Claude Sonnet 5 und Claude Haiku 4.5 sind als Not supported aufgeführt. Für Claude Code gelten Aufgabenbudgets nicht. Eine von tmux getrennte Claude-Code-Sitzung hängt daher stattdessen von einer sauberen Sitzungsverwaltung ab.

Die dritte Obergrenze befindet sich in der Claude Console. Weisen Sie dem Agenten einen eigenen Workspace zu. Legen Sie anschließend dafür ein monatliches Ausgabenlimit und Ratenlimits pro Minute fest. "Für den Default Workspace können Sie keine Limits festlegen", und "Organisationsweite Limits gelten immer, selbst wenn sich die Workspace-Limits auf einen höheren Wert summieren". Aktivieren Sie zusätzlich Ausgabenbenachrichtigungen. Dann werden Sie vor Erreichen der Obergrenze informiert.

Modellauswahl pro Auftrag und was der Aufwand tatsächlich ändert

Die Modellauswahl erfolgt pro Auftrag. Stand Juli 2026 gelten pro 1 Million Tokens, zuerst für Eingabe und dann für Ausgabe, folgende Preise: Claude Fable 5 kostet $10 und $50, Claude Opus 4.8 und Opus 4.7 kosten $5 und $25, Claude Sonnet 5 kostet $3 und $15 und Claude Haiku 4.5 kostet $1 und $5. Sonnet 5 liegt derzeit unter diesem Listenpreis, weil „Introductory pricing of $2/$10 per million input/output tokens is in effect through August 31, 2026“. Ein Schritt, der nur Logzeilen klassifiziert, benötigt kein Opus. Für einen ausgelasteten Zeitplan gibt es außerdem kein kostenloses Kontingent, das die Nutzung auffängt, weil die Claude API keinen kostenlosen Tarif hat, abgesehen von dem kleinen Guthaben, das bei der Registrierung gewährt wird.

Der Aufwand ist der zweite Stellhebel. output_config.effort akzeptiert low, medium, high, xhigh und max. Der Standardwert ist high. Wenn high explizit gesetzt wird, entspricht das daher dem Weglassen der Einstellung. Ein geringerer Aufwand verkürzt nicht nur die Länge der Überlegungen: Laut Dokumentation führt er dazu, dass Claude weniger Tool-Aufrufe ausführt und Vorgänge zusammenfasst. Bei einem Agenten ist das die größere Einsparung, weil ein vermiedener Tool-Aufruf eine vollständige Anfrage darstellt, die gar nicht erst gesendet wird.

Die Falle besteht darin, dass der Aufwand mit dem Cache in Konflikt steht. Wenn der Wert zwischen Anfragen geändert wird, wird das Prompt-Caching ungültig. Im dokumentierten Beispiel meldete Anfrage 2 cache_read_input_tokens: 3546. Anfrage 3 änderte den Aufwand von high auf medium und meldete cache_creation_input_tokens von 3546 sowie cache_read_input_tokens von 0. Variieren Sie den Aufwand daher zwischen Workloads, niemals innerhalb einer gecachten Konversation. Um die Detailtiefe zu steuern, ohne den Cache zu beschädigen, setzen Sie dies im Prompt um: Eine Zeile wie „Answer directly without deliberating.“ in der neuesten Benutzernachricht lässt die früheren Breakpoints unverändert.

Tokens für Überlegungen werden zu den Ausgaberaten abgerechnet und auf max_tokens angerechnet. Deshalb bedeutet eine abgeschnittene Antwort häufig, dass die Überlegungen das Budget aufgebraucht haben. Lesen Sie usage.output_tokens_details.thinking_tokens für die Anzahl. Was tatsächlich eine Claude-Tokenabrechnung füllt zerlegt die Berechnung.

Den stabilen Präfix zwischenspeichern und nicht versehentlich ungültig machen

Ein Cache-Schreibvorgang kostet beim Fünf-Minuten-Cache das 1,25-Fache des Basistarifs für Eingaben und beim Ein-Stunden-Cache das 2-Fache. Ein Cache-Lesevorgang kostet das 0,1-Fache. Daher „lohnt sich das Caching beim Fünf-Minuten-Cache bereits nach einem Cache-Lesevorgang (1.25x für den Schreibvorgang) und beim Ein-Stunden-Cache nach zwei Cache-Lesevorgängen (2x für den Schreibvorgang)“.

Ein Satz erklärt, warum sich das für einen dauerhaft laufenden Agenten eignet: „Der Cache wird jedes Mal ohne zusätzliche Kosten aktualisiert, wenn der zwischengespeicherte Inhalt verwendet wird.“ Ein Job, der alle zwei Minuten Anfragen an den Fünf-Minuten-Cache sendet, hält seinen Präfix den ganzen Tag mit einem Schreibvorgang im Cache.

Drei Möglichkeiten, den Cache unbemerkt zu verlieren.

Ein Präfix, das sich ändert. „Cache-Präfixe werden in der folgenden Reihenfolge erstellt: tools, system und dann messages.“ Jede Byte-Änderung an einer früheren Position in dieser Reihenfolge macht alle nachfolgenden Inhalte ungültig. Änderungen an Tool-Definitionen machen den gesamten Cache ungültig. Der typische selbst verursachte Fehler ist ein Zeitstempel oder eine Lauf-ID im System-Prompt: Dadurch enthält jede Anfrage einen anderen Präfix, schreibt mit 1.25x einen neuen Eintrag und liest nichts aus dem Cache. Ein Hinweis darauf ist usage.cache_read_input_tokens mit dem Wert 0 bei Aufrufen, die identisch aussehen. Verschieben Sie den variablen Text in die neueste User-Nachricht.

Ein zu kurzer Präfix. Jedes Modell hat eine Mindestlänge für den Cache. Unterhalb dieser Länge wird die Anfrage ohne Caching verarbeitet, und „es wird kein Fehler zurückgegeben“. Zu den angegebenen Werten gehören 1,024 Tokens für Claude Opus 4.8 und Claude Sonnet 5 sowie 4,096 für Claude Haiku 4.5. Wenn Sie einen Job von Sonnet auf Haiku umstellen, kann das Caching daher unbemerkt deaktiviert werden.

Eine Unterhaltung, die über das Lookback-Fenster hinauswächst. „Das Lookback-Fenster umfasst 20 Blöcke.“ Das System prüft pro Breakpoint höchstens 20 Positionen und beendet die Suche dann. Im dokumentierten Beispiel enthält ein Turn 35 Blöcke, und ein Breakpoint auf Block 35 prüft die Blöcke 35 bis 16. Der Eintrag des vorherigen Turns auf Block 15 liegt außerhalb des Fensters, daher gibt es keinen Treffer. Ein Agent, der pro Turn mehrere Tool-Use- und Tool-Result-Blöcke anhängt, überschreitet 20 innerhalb von zwei oder drei Turns. Pro Anfrage stehen Ihnen vier Breakpoints zur Verfügung. Verwenden Sie einen davon für die aktuellen Nachrichten.

Senden Sie alles, was warten kann, an die Batches API

„Alle Nutzungen werden sowohl für Eingaben als auch für Ausgaben mit 50 % der Standardpreise der API berechnet.“ Die Batch-Verarbeitung erfolgt asynchron. „Die meisten Batches werden in weniger als 1 Stunde abgeschlossen.“ Ergebnisse stehen bereit, sobald alle Anfragen abgeschlossen sind oder 24 Stunden vergangen sind, je nachdem, was zuerst eintritt. Das ist der typische Ablauf, aber nicht garantiert.

Prüfen Sie processing_status, bis der Wert ended lautet. Anfragen mit den Ergebnissen errored, canceled oder expired werden nicht berechnet. Wenn Sie ein Ausgabenlimit verwenden, gibt es eine Einschränkung: „Batches können das konfigurierte Ausgabenlimit Ihres Workspace geringfügig überschreiten.“

Die Rabatte lassen sich kombinieren. Da ein Batch länger als fünf Minuten dauern kann, empfiehlt die Dokumentation für Batches mit gemeinsamem Kontext den Cache mit einer Gültigkeit von 1 Stunde. Teilen Sie die Arbeit daher auf: Alles, worauf eine Person oder ein Webhook wartet, bleibt im Live-Pfad. Ein nächtlicher Digest oder die Klassifizierung der Logs vom Vortag wird dagegen zum halben Preis in einen Batch aufgenommen.

Protokollieren Sie die Nutzungsfelder jeder Antwort in einem eigenen Speicher

Ausgaben, die Sie nicht erfasst haben, können Sie keiner Quelle zuordnen. Jede Antwort zeigt, welche Kosten entstanden sind.

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

Fügen Sie pro API-Aufruf eine Zeile in eine JSON-Lines-Datei ein und versehen Sie sie mit dem Namen Ihres Jobs. Eine Woche später können Sie feststellen, welcher Job Kosten verursacht und welcher nur ausgelastet wirkte. Überwachen Sie cache_read: Eine Spalte voller Nullen ist der häufigste Kostenfehler bei einem selbst gehosteten Agenten.

Ein Feld lässt sich leicht falsch interpretieren. input_tokens zählt nur die Tokens nach dem letzten Cache-Breakpoint. Die tatsächliche Größe des Prompts ist daher total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Wenn ein Agent bei einem großen Prompt input_tokens: 400 meldet, ist das nicht günstig: Der übrige Teil stammte aus dem Cache.

Zählen Sie vor dem Senden. Das Zählen von Tokens ist kostenlos, und die Rate Limits dafür sind von der Nachrichtenerstellung getrennt. Verwenden Sie daher count_tokens, um einen zu großen Anhang abzulehnen, statt erst nach dem kostenpflichtigen Senden festzustellen, dass er zu groß ist. Das Ergebnis ist eine Schätzung. Messen Sie deshalb für jedes Modell erneut und verwenden Sie niemals einen Zählwert vom Tokenizer eines anderen Anbieters. Claude Opus 4.7 und spätere Opus-Modelle, Claude Fable 5 und Claude Sonnet 5 verwenden einen neueren Tokenizer, der „für denselben Text ungefähr 30% mehr Tokens erzeugt“. Claude Sonnet 4.6 und frühere Versionen, darunter Claude Haiku 4.5, verwenden den vorherigen Tokenizer.

Die maßgebliche Ansicht liefert die Admin API. Sie meldet die Nutzung unter https://api.anthropic.com/v1/organizations/usage_report/messages und die Kosten unter https://api.anthropic.com/v1/organizations/cost_report. Für beide ist ein Admin-Key (sk-ant-admin01-...) als x-api-key: $ANTHROPIC_ADMIN_KEY mit anthropic-version: 2023-06-01 erforderlich. Außerdem akzeptieren beide bucket_width=1d, group_by[]=model und api_key_ids[]=. Eine Einschränkung lautet: „Die Admin API ist für Einzelkonten nicht verfügbar.“

Der letzte Parameter ermöglicht eine einfache Zuordnung: Geben Sie jedem Job einen eigenen API-Key, filtern Sie mit api_key_ids[] und teilen Sie den Bericht mit group_by[]=api_key_id nach Schlüssel auf. Der Filter ist plural, die Gruppierungsdimension ist singular. Speichern Sie die Schlüssel in der Umgebung und nicht im Code, wie es eine erste Claude-API-Anwendung auf einem VPS macht.

Begrenzen Sie die Schleife, weil es sonst niemand tut

Eine begrenzte Anzahl von Iterationen ist hier nicht optional. Die Schleife stammt von Ihnen, also gehört auch der Zähler Ihnen:

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

Keine der beiden oberen Begrenzungen erledigt das für Sie: max_tokens begrenzt eine einzelne Antwort, und das Modell wird lediglich über ein Aufgabenbudget informiert. Ein gehostetes Produkt würde an dieser Stelle stoppen, so wie Claudes Begrenzung der Tool-Aufrufe innerhalb eines einzelnen Durchlaufs eine Sitzung beendet, die zu viele davon ausgeführt hat. Eine Schleife, die Sie selbst geschrieben haben, verfügt jedoch über keine solche Absicherung, bis Sie eine hinzufügen.

Setzen Sie eine zweite Begrenzung außerhalb des Prozesses. Starten Sie den Job über einen systemd-Timer statt als permanenten Prozess, und setzen Sie RuntimeMaxSec= in seiner Service-Unit. Mit RuntimeMaxSec=600 wird ein hängender Lauf nach zehn Minuten beendet, statt weiterzulaufen, bis Sie ihn bemerken. Ein Programm als systemd-Service und -Timer ausführen beschreibt die Unit-Dateien selbst. Lesen Sie mit journalctl -u triage-agent.service --since "1 hour ago", was ein Lauf ausgeführt hat.

Begrenzen Sie auch die Wiederholungsversuche, weil ein Handler, der endlos wiederholt, jeden Versuch abrechnet. Ein 429- oder 500-Fehler rechtfertigt einige Versuche mit Backoff. Ein 400-Fehler rechtfertigt keinen, weil dieselbe Anfrage auf dieselbe Weise fehlschlägt.

Die Kostenkontrolle für einen KI-Agenten beginnt mit den eigenen Zahlen

Niemand kann Ihnen sagen, was ein dauerhaft laufender Agent kostet. Die Kosten ergeben sich aus den Tokens pro Ausführung multipliziert mit den Ausführungen pro Tag. Für beide Werte sind Sie verantwortlich. Führen Sie den Agenten einmal aus, lesen Sie die protokollierte Nutzungszeile und multiplizieren Sie den Wert mit Ihrem Zeitplan. Prüfen Sie den Kostenbericht zwei Tage später anhand dieser Rechnung. Wenn die beiden Werte voneinander abweichen, liegt die Ursache fast immer in einem fehlerhaften Cache oder einer Schleife, die länger lief als angenommen.

Dies setzt einen API-Schlüssel voraus, weil der Agent Ihr eigenes Programm ist, das die Messages API aufruft. Für Ihre eigene interaktive Arbeit behandelt welcher Claude-Tarif zu Ihrer Arbeitsweise passt die Seite des Abonnements. Alle Preise und Limits wurden im Juli 2026 anhand der Dokumentation von Anthropic geprüft. Lesen Sie daher die Preisseite erneut, bevor Sie ein Budget erstellen.

FAQ

Wie viel kostet es, einen ständig laufenden AI-Agent auf einem VPS zu betreiben?

Es gibt zwei Kostenpositionen, aber nur eine davon ist vorhersehbar. Der Server hat einen festen monatlichen Preis. Die Model-API wird pro Token abgerechnet. Die Kosten ergeben sich daher aus dem Verbrauch eines einzelnen Laufs multipliziert mit der Ausführungshäufigkeit. Anthropic veröffentlicht keine Zahl für einen selbst gehosteten, ständig laufenden Agent. Betrachten Sie jeden genannten Betrag daher als Schätzung. Protokollieren Sie usage aus einem realen Lauf und multiplizieren Sie den Wert mit Ihrem Zeitplan.

Was ist der Unterschied zwischen max_tokens und einem Aufgabenbudget?

max_tokens wird erzwungen und ist für das Modell nicht sichtbar. Der Wert begrenzt die Ausgabe einer einzelnen Anfrage einschließlich des Denkens. Wird das Limit erreicht, liefert die Anfrage stop_reason: "max_tokens". Ein Aufgabenbudget funktioniert umgekehrt: Das Modell erhält die Zahl und passt die agentische Schleife daran an. „Aufgabenbudgets sind ein unverbindlicher Hinweis und keine harte Begrenzung.“ Das tatsächlich erzwungene Limit bleibt max_tokens.

Warum ist cache_read_input_tokens bei meinem Agent immer null?

Weil sich das Präfix zwischen den Aufrufen ändert oder zu kurz für das Caching ist. Häufig wird ein Zeitstempel oder eine Lauf-ID in den System-Prompt eingesetzt. Der Cache verwendet das Präfix als Schlüssel. Daher macht jede Byte-Änderung alle nachfolgenden Inhalte ungültig. Eine Änderung der Tool-Definitionen oder des Werts effort hat denselben Effekt. Andernfalls liegt es an der Größe: Kürzere Prompts werden nicht gecacht, und es wird kein Fehler zurückgegeben.

Wie verhindere ich, dass ein AI-Agent endlos läuft?

Zählen Sie die Iterationen in Ihrem Schleifencode und beenden Sie die Schleife bei einem festen Maximum. max_tokens begrenzt nur eine Antwort, während ein Agent viele Antworten erzeugt. Setzen Sie außerhalb des Prozesses zusätzlich ein Zeitlimit. Starten Sie den Job über einen systemd-Timer mit gesetztem RuntimeMaxSec=, damit ein blockierter Lauf planmäßig beendet wird. Begrenzen Sie auch die Wiederholungsversuche, da jeder Versuch Kosten verursacht.

Kann ich ein Ausgabenlimit für einen einzelnen Claude-API-Schlüssel festlegen?

Das dokumentierte Ausgabenlimit gilt pro Workspace und nicht pro Schlüssel. Weisen Sie dem Agent daher einen eigenen Workspace zu und begrenzen Sie dort die monatlichen Ausgaben. „Für den Default Workspace können Sie keine Limits festlegen.“ Aktivieren Sie Ausgabenbenachrichtigungen, damit Sie bei Erreichen eines Schwellenwerts zuerst informiert werden. Weisen Sie zur Zuordnung jedem Job einen eigenen Schlüssel zu und gruppieren Sie anschließend den Nutzungsbericht mit group_by[]=api_key_id.