KI-Agent auf VPS Kosten kontrollieren

So verhindern Sie hohe Kosten bei einem permanent laufenden KI-Agenten

Die Kostenkontrolle für KI-Agenten auf einem VPS (Virtual Private Server) erfolgt über Limits, die Sie vor dem Start des Agenten festlegen. Da der Verbrauch während des Betriebs nicht manuell überwacht wird, müssen Sie Maßnahmen ergreifen. Begrenzen Sie jede Antwort auf max_tokens, definieren Sie eine maximale Anzahl an Schleifeniterationen in Ihrem Code, cachen Sie statische Prompt-Teile und protokollieren Sie die Token-Nutzung jeder Antwort, um die Ausgaben pro Aufgabe zu analysieren. Die Servermiete ist ein fester monatlicher Preis. Die Model-API wird pro Token abgerechnet; eine unbeaufsichtigte Schleife kann sehr effizient Token verbrauchen.

Dies setzt voraus, dass bereits ein Agent existiert, der die Messages API von einem eigenen Server aus aufruft. Erstellung eines KI-Agenten mit Claude auf einem VPS beschreibt die technische Umsetzung.

Warum ein unattended Agent eine andere Kostenstruktur aufweist

Eine interaktive Session beinhaltet einen Menschen. Wenn das Modell einen falschen Pfad einschlägt oder ein 40.000 Zeilen langes Log liest, stoppt die beobachtende Person den Vorgang. Ein unattended Agent hat keine solche Bremse: Er läuft, bis die Schleife endet, und ein Timer startet ihn dann erneut.

Die Häufigkeit ist der Multiplikator, den viele übersehen. Ein Job mit einem Intervall von fünf Minuten läuft 288 Mal pro Tag und etwa 8.640 Mal pro Monat. Der Preis pro Durchlauf ist der Wert, mit dem Sie multiplizieren müssen. Viele "Always-on"-Agenten müssen nicht permanent aktiv sein. Sie müssen innerhalb einer bestimmten Anzahl von Minuten antworten, was einem Zeitplan entspricht.

Ein Agent verursacht zudem Kosten für Dinge, die ein Chat-Fenster nicht benötigt.

• Tool-Definitionen werden bei jeder Anfrage mitübertragen. Der System Prompt für die Tool-Nutzung kostet bei Claude Opus 4.8 290 Tokens mit tool_choice von auto oder none, und 410 Tokens mit any oder tool. Das bash tool fügt weitere 325 Tokens hinzu. Jeder angebundene MCP server fügt seine Schemas zu diesem Gewicht hinzu; MCP steht für das Model Context Protocol.
• Tool-Ergebnisse sind Input-Tokens. Ein Befehl, der 8.000 Zeilen ausgibt, überträgt diese 8.000 Zeilen in die nächste Anfrage und in jede weitere Anfrage innerhalb dieses Turns.
• Abgerufene Seiten sind Input-Tokens. Eine durchschnittliche 10 kB große Webseite entspricht etwa 2.500 Tokens und ein 500 kB großes Research-PDF etwa 125.000 Tokens. max_content_tokens kürzt nur Textdateien, da dies "nur für Textinhalte und nicht für binäre Inhalte wie PDFs gilt". Nutzen Sie stattdessen max_uses und allowed_domains für PDFs.
• Websuche wird pro Suche berechnet, zu $10 pro 1.000 Suchen, unabhängig von der Anzahl der Ergebnisse. Eine fehlgeschlagene Suche wird nicht berechnet.

Nichts davon ist einmalig teuer. Alles davon ist 8.640 Mal teuer.

Hard ceilings und soft ceilings lösen unterschiedliche Probleme

max_tokens wird erzwungen. Dies ist eine feste Obergrenze für die Gesamtausgabe einer Anfrage, bestehend aus Denk- und Antworttext. Claude generiert niemals mehr als diesen Wert, und das Modell kann die Zahl nicht sehen. Das Erreichen führt zu stop_reason: "max_tokens" und einer abgeschnittenen Antwort. Die Schwierigkeit für Agenten: Jede Anfrage in einer Tool-Use-Schleife hat ihr eigenes max_tokens, wodurch nur eine einzelne Antwort und nicht die gesamte Aufgabe begrenzt wird. Zehn Tool-Aufrufe mit jeweils 4.000 Tokens ergeben eine Obergrenze von 40.000 Tokens für den gesamten Durchgang.

Ein Task-Budget ist unverbindlich. task_budget liegt innerhalb von output_config und teilt dem Modell mit, wie viele Tokens es für die gesamte agentische Schleife zur Verfügung hat, inklusive Denkprozess, Tool-Aufrufen, Tool-Ergebnissen und Ausgabe.

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,
)

"Task-Budgets sind ein weicher Hinweis, keine feste Obergrenze." Claude kann während einer Aktion das Limit überschreiten, wobei die erzwungene Ausgabe-Obergrenze weiterhin bei max_tokens liegt. "Der Countdown ist nur für das Modell sichtbar", und Antworten enthalten kein Feld für das verbleibende Budget. Das akzeptierte Minimum für task_budget.total beträgt 20.000 Tokens; ein geringerer Wert führt zu einem 400-Error. Ein zu kleines Budget führt zu Verweigerungsverhalten, sodass das Modell die Aufgabe reduziert oder vorzeitig abbricht.

Ein Detail verursacht Kosten, anstatt sie zu sparen. Wenn Ihr Client bei jeder Folgeanfrage task_budget.remaining dekrementiert, macht der geänderte Wert jeden Cache-Prefix ungültig, der diesen Wert enthält. Setzen Sie ihn einmalig bei der ersten Anfrage.

Task-Budgets befinden sich in der Beta-Phase bei Claude Fable 5, Claude Opus 4.8 und Claude Opus 4.7. Claude Sonnet 5 und Claude Haiku 4.5 sind als Not supported gelistet, und Task-Budgets gelten nicht für Claude Code. Eine Claude Code session detached in tmux hängt daher von der Session-Hygiene ab.

Die dritte Obergrenze befindet sich in der Claude Console: Geben Sie dem Agenten einen eigenen Workspace und legen Sie dort ein monatliches Ausgabenlimit sowie Rate-Limits pro Minute fest. "Limits können nicht für den Default Workspace gesetzt werden", und "Organisation-weite Limits gelten immer, selbst wenn die Workspace-Limits in der Summe höher liegen". Aktivieren Sie Benachrichtigungen über die Ausgaben, damit Sie vor Erreichen des Limits alarmiert werden.

Modellauswahl pro Job und tatsächliche Aufwandskosten

Die Modellauswahl erfolgt pro Job. Stand Juli 2026 liegen die Kosten pro eine Million Tokens (Input, dann Output) bei: Claude Fable 5 für 10 $ und 50 $, Claude Opus 4.8 und Opus 4.7 für 5 $ und 25 $, Claude Sonnet 5 für 3 $ und 15 $ sowie Claude Haiku 4.5 für 1 $ und 5 $. Der Preis für Sonnet 5 liegt aktuell unter dem Listenpreis, da „Introductory pricing of $2/$10 per million input/output tokens is in effect through August 31, 2026“ gilt. Ein Schritt, der lediglich Log-Zeilen klassifiziert, benötigt kein Opus.

Der Aufwand (Effort) ist der zweite Hebel. output_config.effort akzeptiert low, medium, high, xhigh und max. Der Standardwert ist high; das explizite Setzen von high hat daher denselben Effekt wie das Weglassen. Ein geringerer Aufwand reduziert mehr als nur die Denkzeit (reasoning length): Laut Dokumentation führt dies dazu, dass Claude weniger Tool-Aufrufe tätigt und Operationen zu einer einzigen Operation kombiniert. Bei einem Agenten ist dies die größere Ersparnis, da ein vermiedener Tool-Aufruf eine komplette Anfrage spart, die gar nicht erst erfolgt.

Die Falle besteht darin, dass der Aufwand mit dem Cache kollidiert. Das Ändern des Wertes zwischen Anfragen macht das Prompt-Caching ungültig. Im dokumentierten Beispiel meldete Anfrage 2 cache_read_input_tokens: 3546; Anfrage 3 mit geändertem Effort von high auf medium meldete cache_creation_input_tokens von 3546 und cache_read_input_tokens von 0. Variieren Sie den Aufwand also über verschiedene Workloads hinweg, aber niemals innerhalb einer gecachten Konversation. Um die Tiefe zu steuern, ohne den Cache zu unterbrechen, nutzen Sie den Prompt: Eine Zeile wie „Answer directly without deliberating.“ in der neuesten Benutzernachricht lässt die vorherigen Breakpoints intakt.

Thinking-Tokens werden zu Output-Preisen abgerechnet und werden auf max_tokens angerechnet. Deshalb bedeutet eine abgeschnittene Antwort oft, dass das Denken das Budget verbraucht hat. Lesen Sie usage.output_tokens_details.thinking_tokens für die genauen Zahlen. Was eine Claude-Rechnung tatsächlich ausmacht erklärt die Details.

Caching des stabilen Präfix verwenden und versehentliches Ungültigmachen verhindern

Ein Cache-Schreibvorgang kostet das 1,25-fache des Basis-Input-Preises beim 5-Minuten-Cache und das 2-fache beim 1-Stunden-Cache. Ein Cache-Lesevorgang kostet 0,1-mal. Daher gilt: „Caching lohnt sich bereits nach einer Cache-Leseoperation bei einer 5-Minuten-Dauer (1,25x Schreibvorgang) oder nach zwei Cache-Leseoperationen bei einer 1-Stunden-Dauer (2x Schreibvorgang)“.

Ein Satz erklärt, warum dies für einen permanent laufenden Agenten geeignet ist: „Der Cache wird bei jeder Verwendung des gecachten Inhalts ohne zusätzliche Kosten aktualisiert.“ Ein Job, der alle zwei Minuten gegen den 5-Minuten-Cache ausgeführt wird, hält sein Präfix den ganzen Tag über mit nur einem Schreibvorgang aktuell.

Drei Arten, den Cache unbemerkt zu verlieren.

Ein sich änderndes Präfix. „Cache-Präfixe werden in der folgenden Reihenfolge erstellt: tools, system, dann messages.“ Jede Byte-Änderung an einer früheren Stelle in dieser Reihenfolge macht alles nachfolgende ungültig. Das Bearbeiten von Tool-Definitionen macht den gesamten Cache ungültig. Die klassische Ursache ist ein Zeitstempel oder eine Run-ID im System-Prompt: Jede Anfrage enthält dann ein anderes Präfix, schreibt einen neuen Eintrag für 1,25x und liest nichts zurück. Das Anzeichen hierfür ist usage.cache_read_input_tokens bei 0 bei identisch aussehenden Aufrufen. Verschieben Sie variablen Text in die neueste User-Message.

Ein zu kurzes Präfix. Jedes Modell hat eine minimale Cache-Länge. Unterhalb dieser Länge wird die Anfrage ohne Caching verarbeitet und „es wird kein Fehler zurückgegeben“. Die Werte beinhalten 1.024 Tokens bei Claude Opus 4.8 und Claude Sonnet 5 sowie 4.096 bei Claude Haiku 4.5. Ein Wechsel des Jobs von Sonnet zu Haiku kann das Caching daher lautlos deaktivieren.

Ein Gespräch, das das Lookback-Fenster überschreitet. „Das Lookback-Fenster umfasst 20 Blöcke.“ Das System prüft maximal 20 Positionen pro Breakpoint und stoppt dann. Im dokumentierten Beispiel prüft ein Turn mit 35 Blöcken und einem Breakpoint bei Block 35 die Blöcke 35 bis 16. Der Eintrag des vorherigen Turns bei Block 15 liegt außerhalb des Fensters, weshalb kein Hit erfolgt. Ein Agent, der pro Turn mehrere Tool-Use- und Tool-Result-Blöcke anhängt, überschreitet die 20 Blöcke bereits nach zwei oder drei Turns. Da pro Anfrage vier Breakpoints zur Verfügung stehen, sollte ein Breakpoint für die aktuellen Nachrichten reserviert werden.

Senden Sie zeitversetzte Aufgaben an die Batches API

"Die Nutzung wird mit 50 % der Standard-API-Preise berechnet", sowohl für Input als auch für Output. Die Batch-Verarbeitung erfolgt asynchron. "Die meisten Batches sind in weniger als 1 Stunde fertiggestellt". Die Ergebnisse liegen vor, sobald alle Anfragen abgeschlossen sind oder nach maximal 24 Stunden. Dies ist ein typischer Wert, keine Garantie.

Überprüfen Sie processing_status, bis der Wert ended erreicht ist. Anfragen, die errored, canceled oder expired zurückgeben, werden nicht in Rechnung gestellt. Ein Hinweis bei der Nutzung von Ausgabenlimits: "Batches können das konfigurierte Ausgabenlimit Ihres Workspaces leicht überschreiten."

Die Rabatte sind kumulativ. Da ein Batch länger als fünf Minuten dauern kann, empfiehlt die Dokumentation die Verwendung des Ein-Stunden-Caches für Batches mit gemeinsamem Kontext. Teilen Sie die Aufgaben auf: Alles, worauf eine Person oder ein Webhook wartet, muss über den Live-Pfad laufen. Ein nächtlicher Digest oder die Klassifizierung von Protokolldaten vom Vortag sollte mit halbem Preis in einen Batch ausgelagert werden.

Protokollieren Sie die Usage-Felder jeder Antwort in Ihrem eigenen Speicher

Ausgaben können nicht zugeordnet werden, wenn sie nicht aufgezeichnet wurden. Jede Antwort enthält Informationen zu den entstandenen Kosten.

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 an eine JSON-lines-Datei an, die mit Ihrem Job-Namen markiert ist. Eine Woche später können Sie so unterscheiden, welcher Job Kosten verursacht hat und welcher nur eine hohe Auslastung simulierte. Achten Sie auf cache_read: Eine Spalte mit Nullen ist der häufigste Kostenfehler bei selbst gehosteten Agenten.

Ein Feld ist leicht falsch zu interpretieren. input_tokens zählt nur die Tokens nach dem letzten Cache-Breakpoint, daher entspricht die tatsächliche Prompt-Größe total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Ein Agent, der bei einem großen Prompt input_tokens: 400 meldet, ist nicht kostengünstig: Der Rest stammte aus dem Cache.

Zählen Sie die Tokens vor dem Senden. Das Zählen von Tokens ist kostenlos und die Rate-Limits sind von der Nachrichten-Erstellung getrennt. Nutzen Sie daher count_tokens, um einen zu großen Anhang abzulehnen, anstatt für die Entdeckung der Größe zu bezahlen. Das Ergebnis ist eine Schätzung; messen Sie daher pro Modell nach und verwenden Sie niemals die Token-Anzahl eines Tokenizers eines anderen Anbieters. Claude Opus 4.7 und neuere Opus-Modelle, Claude Fable 5 und Claude Sonnet 5 verwenden einen neueren Tokenizer, der "für denselben Text etwa 30 % mehr Tokens erzeugt". Claude Sonnet 4.6 und älter, einschließlich Claude Haiku 4.5, verwenden den vorherigen Tokenizer.

Für eine verbindliche Auswertung meldet die Admin API den Verbrauch unter https://api.anthropic.com/v1/organizations/usage_report/messages und die Kosten unter https://api.anthropic.com/v1/organizations/cost_report. Beide benötigen einen Admin-Key (sk-ant-admin01-...) als x-api-key: $ANTHROPIC_ADMIN_KEY mit anthropic-version: 2023-06-01 und akzeptieren bucket_width=1d, group_by[]=model und api_key_ids[]=. Eine Einschränkung: "Die Admin API ist für Einzelkonten nicht verfügbar."

Dieser letzte Parameter ist ein effizienter Trick zur Zuordnung: Geben Sie jedem Job einen eigenen API-Key, filtern Sie mit api_key_ids[] und teilen Sie den Bericht pro Key mit group_by[]=api_key_id auf. Der Filter ist im Plural, die Gruppierungsdimension ist im Singular. Speichern Sie die Keys in den Umgebungsvariablen anstatt im Code, so wie es eine erste Claude API App auf einem VPS handhabt.

Begrenzen Sie die Schleife, da sonst nichts anderes dies tut

Eine begrenzte Iterationsanzahl ist hier zwingend erforderlich. Die Schleife liegt in Ihrer Verantwortung, daher liegt auch der Zähler in Ihrer Verantwortung:

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 oben genannten Obergrenzen übernimmt dies für Sie: max_tokens begrenzt nur eine Antwort, und das Modell erhält lediglich ein Budget für die Aufgabe.

Implementieren Sie eine zweite Begrenzung außerhalb des Prozesses. Führen Sie den Job über einen systemd timer statt als permanenten Prozess aus und setzen Sie RuntimeMaxSec= in der Service-Unit. Mit RuntimeMaxSec=600 wird ein hängender Prozess nach zehn Minuten beendet, anstatt ununterbrochen weiterzulaufen, bis Sie ihn bemerken. Ausführen eines Programms als systemd service und timer behandelt die Unit-Files selbst. Lesen Sie mit journalctl -u triage-agent.service --since "1 hour ago", was ein Durchlauf bewirkt hat.

Begrenzen Sie auch die Wiederholungsversuche (retries), da ein Handler, der unendlich oft wiederholt, für jeden Versuch Kosten verursacht. Ein 429 oder ein 500 Fehler rechtfertigt einige Versuche mit Backoff. Ein 400 Fehler rechtfertigt keine weiteren Versuche, da dieselbe Anfrage auf dieselbe Weise fehlschlägt.

KI-Agent-Kostenkontrolle beginnt mit der Analyse Ihrer eigenen Kennzahlen

Niemand kann die Kosten für einen permanent laufenden Agenten vorhersagen. Die Kosten berechnen sich aus der Anzahl der Tokens pro Durchlauf multipliziert mit der Anzahl der Durchläufe pro Tag. Beide Werte liegen in Ihrer Verantwortung. Führen Sie einen Durchlauf aus, lesen Sie die protokollierte Zeile zur Nutzung aus und multiplizieren Sie diesen Wert mit Ihrem Zeitplan. Vergleichen Sie den Kostenbericht zwei Tage später mit diesem Ergebnis. Wenn die Werte abweichen, liegt die Ursache fast immer an einem fehlerhaften Cache oder einer Schleife, die länger lief als angenommen.

Dies setzt einen API-Key voraus, da der Agent Ihr eigenes Programm ist, das die Messages API aufruft. Für Ihre eigene interaktive Arbeit bietet welcher Claude-Plan zu Ihrer Arbeitsweise passt Informationen zur Abonnement-Seite. Alle Preise und Limits wurden im Juli 2026 mit der Dokumentation von Anthropic abgeglichen. Lesen Sie die Preisliste erneut, bevor Sie ein Budget erstellen.

FAQ

Wie hoch sind die Kosten für den Betrieb eines Always-on-KI-Agenten auf einem VPS?

Es entstehen zwei Rechnungen, von denen nur eine vorhersehbar ist. Der Server hat einen festen monatlichen Preis. Die Model-API wird pro Token abgerechnet; die Kosten entsprechen also dem Verbrauch eines Durchlaufs multipliziert mit der Häufigkeit der Ausführung. Anthropic veröffentlicht keine Zahlen für selbstgehostete Always-on-Agenten. Betrachten Sie daher jede genannte Zahl als Schätzung. Protokollieren Sie usage aus einem realen Durchlauf und multiplizieren Sie diesen mit Ihrem Zeitplan.

Was ist der Unterschied zwischen max_tokens und einem Task-Budget?

max_tokens wird erzwungen und ist für das Modell unsichtbar. Es begrenzt die Ausgabe einer Anfrage inklusive der Token für die Verarbeitung; das Erreichen des Limits führt zu stop_reason: "max_tokens". Ein Task-Budget ist das Gegenteil: Das Modell erhält die Zahl als Vorgabe und passt die agentische Schleife daran an. "Task budgets are a soft hint, not a hard cap" und das erzwungene Limit bleibt weiterhin max_tokens.

Warum ist cache_read_input_tokens für meinen Agenten immer null?

Weil sich der Präfix zwischen den Aufrufen ändert oder der Präfix zu kurz für das Caching ist. Die häufigste Ursache ist ein Zeitstempel oder eine Run-ID, die in den System-Prompt interpoliert wird: Der Cache basiert auf dem Präfix; jede Änderung eines Bytes macht alles Folgende ungültig. Das Ändern von Tool-Definitionen oder des effort-Werts bewirkt dasselbe. Eine weitere Ursache ist die Größe, da kürzere Prompts nicht gecacht werden und kein Fehler zurückgegeben wird.

Wie verhindere ich, dass ein KI-Agent in einer Endlosschleife feststeckt?

Zählen Sie die Iterationen in Ihrem Loop-Code und stoppen Sie bei einem festen Maximum, da max_tokens nur eine Antwort begrenzt, ein Agent jedoch viele generiert. Fügen Sie ein Zeitlimit außerhalb des Prozesses hinzu: Starten Sie den Job über einen systemd-Timer mit gesetztem RuntimeMaxSec=, damit ein hängengebliebener Prozess planmäßig beendet wird. Begrenzen Sie auch die Retries, da jede Wiederholung Kosten verursacht.

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

Das dokumentierte Ausgabenlimit gilt pro Workspace statt pro Key. Geben Sie dem Agenten daher einen eigenen Workspace und begrenzen Sie dort die monatlichen Ausgaben. "You cannot set limits on the Default Workspace". Aktivieren Sie Benachrichtigungen bei Erreichen eines Schwellenwerts, um frühzeitig gewarnt zu werden. Zur Kostenzuordnung sollten Sie jedem Job einen eigenen Key zuweisen und den Nutzungsbericht mit group_by[]=api_key_id gruppieren.