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 erzwungen. Dies ist eine harte Obergrenze für die Gesamtausgabe einer Anfrage, also für Denkprozess und Antworttext zusammen. Claude generiert niemals darüber hinaus, und das Modell kann den Wert nicht sehen. Beim Erreichen dieses Werts wird stop_reason: "max_tokens" zurückgegeben, und die Antwort wird abgeschnitten. Für Agenten gilt: Jede Anfrage in einer Tool-Aufrufschleife hat ihr eigenes max_tokens. Dadurch wird jeweils nur eine 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 ein Richtwert. task_budget liegt innerhalb von output_config und teilt dem Modell mit, wie viele Tokens für die gesamte agentische Schleife zur Verfügung stehen. Dabei werden Denkprozess, Tool-Aufrufe, Tool-Ergebnisse und Ausgabe berücksichtigt.

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 weicher Hinweis, keine harte Obergrenze." Claude kann ein Budget während einer Aktion überschreiten. Die erzwungene Ausgabelimitierung bleibt dennoch max_tokens. "Der Countdown ist nur für das Modell sichtbar", und Antworten enthalten kein Feld mit dem verbleibenden Budget. Das kleinste akzeptierte task_budget.total beträgt 20,000 Tokens. Ein niedrigerer 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 beschränkt dann den Umfang der Aufgabe oder beendet sie vorzeitig.

Ein Detail verursacht Kosten, statt sie zu senken. Wenn Ihr Client task_budget.remaining bei jeder Folgeanfrage verringert, wird durch den geänderten Wert jedes gecachte Präfix ungültig, das diesen Wert enthält. Setzen Sie den Wert nur einmal, bei der ersten Anfrage.

Aufgabenbudgets befinden sich bei Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5.5 und Claude Haiku 5.5 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, auch wenn sich die Workspace-Limits auf einen höheren Wert summieren". Aktivieren Sie Ausgabenbenachrichtigungen, damit Sie vor dem Erreichen des Limits bei einem Schwellenwert benachrichtigt werden.

Modellauswahl pro Job und was ein höherer Aufwand tatsächlich ändert

Die Modellauswahl erfolgt pro Job. Stand Oktober 2026 gelten pro 1 Million Tokens folgende Preise, zuerst für Eingabe und dann für Ausgabe: Claude Fable 5.1 und Fable 5 kosten $10 und $50, Claude Opus 5.5 kostet $4 und $20, Claude Opus 5, Opus 4.8 und Opus 4.7 kosten $5 und $25, Claude Sonnet 5.5 und Sonnet 5 kosten $2 und $10, Claude Haiku 5.5 kostet $0.10 und $0.50 für Prompts bis 100,000 Tokens ($0.50 und $2.50 darüber; gecachte Tokens werden mitgezählt), und Claude Haiku 4.5 kostet $1 und $5. Anthropic verkaufte Sonnet 5 zunächst zu diesem Preis als Einführungspreis. Danach wurde er zum Standardpreis, und die geplante Erhöhung auf $3 und $15 wurde gestrichen. Ein Schritt, der nur Logzeilen klassifiziert, benötigt kein Opus.

Verlassen Sie sich auch bei hoher Auslastung nicht darauf, dass die kostenlose Nutzung den Zeitplan abdeckt. Abgesehen von dem kleinen Guthaben, das die Claude API bei der Anmeldung gewährt, gibt es nur das wiederkehrende monatliche API-Guthaben der Claude Max- und Team-Tarife: $100 bei Max 5x, $200 bei Max 20x und bis zu $500 als gemeinsames Guthaben bei Team. Das Guthaben wird in jedem Abrechnungszeitraum erneuert. Sie können es nach 7 Tagen mit einem berechtigten Tarif beanspruchen. Eine Zahlungsmethode ist nicht erforderlich. Das Guthaben gilt für die Claude API, Managed Agents, das Agent SDK und die Playground-Umgebung, aber nicht für Claude Code. Es verfällt am Ende jedes Abrechnungszeitraums und wird nicht übertragen. Die Nutzung wird auf das Ausgabenlimit angerechnet. Sobald das Guthaben aufgebraucht ist, werden Anfragen angehalten, sofern die Organisation nicht zusätzlich erworbenes Guthaben besitzt.

Der Aufwand ist der zweite Stellhebel. output_config.effort akzeptiert low, medium, high, xhigh und max, wobei nicht jedes Modell jede Stufe unterstützt. Bei den meisten Modellen lautet der Standard high, bei Claude Opus 5.5 und Claude Haiku 5.5 dagegen medium. Wenn Sie den Standard eines Modells ausdrücklich setzen, entspricht das dem Weglassen des Werts. Ein niedrigerer Aufwand verkürzt nicht nur die Reasoning-Länge: Laut Dokumentation führt er dazu, dass Claude weniger Tool-Aufrufe ausführt und mehrere Operationen in weniger Aufrufen zusammenfasst. Bei einem Agenten ist das die größere Einsparung, weil ein vermiedener Tool-Aufruf eine vollständige Anfrage darstellt, die gar nicht erst ausgeführt wird.

Die Falle besteht darin, dass der Aufwand den Cache beeinflusst. Wenn Sie den Wert auf der obersten Ebene zwischen Anfragen ändern, wird das Prompt-Caching ungültig. Im dokumentierten Beispiel mit Claude Opus 5.5 meldete Anfrage 2 cache_read_input_tokens: 3546. Anfrage 3 änderte den Aufwand von medium, dem Standard dieses Modells, auf low und meldete cache_creation_input_tokens von 3546 sowie cache_read_input_tokens von 0. Variieren Sie den Aufwand auf oberster Ebene daher zwischen Workloads, aber niemals innerhalb einer gecachten Konversation. Es gibt zwei Möglichkeiten, die Tiefe zu ändern, ohne den Cache zu unterbrechen. Bei Claude Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 und Haiku 5.5 setzt eine Änderung des Aufwands pro Nachricht (Beta, Header mid-conversation-output-config-2026-07-01) eine neue Stufe, während das gecachte Präfix unverändert bleibt. Bei jedem Modell können Sie stattdessen den Prompt entsprechend formulieren: Eine Zeile wie „Antworten Sie direkt, ohne abzuwägen.“ in der neuesten Benutzernachricht lässt die früheren Breakpoints unverändert. Bei Claude Haiku 5.5 reduziert diese Formulierung das Denken jedoch nicht zuverlässig.

Thinking-Tokens werden zum Ausgabetarif abgerechnet und auf max_tokens angerechnet. Deshalb bedeutet eine abgeschnittene Antwort häufig, dass das Thinking das Budget aufgebraucht hat. Lesen Sie usage.output_tokens_details.thinking_tokens für die Anzahl. Was tatsächlich eine Claude-Tokenabrechnung füllt schlüsselt den Zähler auf.

Den stabilen Präfix zwischenspeichern und ihn 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. Bei den meisten Modellen kostet ein Cache-Lesevorgang das 0.1-Fache. Daher „lohnt sich das Caching nach einem Cache-Lesevorgang bei einer Dauer von 5 Minuten (1.25x für das Schreiben) oder nach zwei Cache-Lesevorgängen bei einer Dauer von 1 Stunde (2x für das Schreiben)“. Bei den neuesten Modellen sind Lesevorgänge noch günstiger: 0.05-Fach bei Claude Opus 5.5 und Claude Sonnet 5.5 sowie 0.025-Fach bei Claude Fable 5.1.

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 auf den Fünf-Minuten-Cache zugreift, hält seinen Präfix den ganzen Tag mit einem Schreibvorgang warm.

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, dann messages.“ Jede Byte-Änderung an einer früheren Position in dieser Reihenfolge macht alle nachfolgenden Einträge ungültig. Änderungen an Tooldefinitionen machen den gesamten Cache ungültig. Der typische selbst verursachte Fehler ist ein Zeitstempel oder eine Lauf-ID im System-Prompt. Dann enthält jede Anfrage einen anderen Präfix, schreibt einen neuen Eintrag zum 1.25-Fachen und liest nichts aus dem Cache. Erkennbar ist das an usage.cache_read_input_tokens mit dem Wert 0 bei scheinbar identischen Aufrufen. Verschieben Sie den variablen Text in die neueste User-Nachricht.

Ein Präfix, das zu kurz ist. Für jedes Modell gibt es eine Mindestlänge für das Caching. Unterhalb dieser Länge wird die Anfrage ohne Caching verarbeitet, und „es wird kein Fehler zurückgegeben“. Die Werte sind 512 Tokens bei Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5, Sonnet 5.5 und Haiku 5.5, 1,024 bei Claude Opus 4.8 und Claude Sonnet 5 sowie 4,096 bei Claude Haiku 4.5. Wenn Sie einen Job von Sonnet 5 auf Haiku 4.5 umstellen, kann das Caching daher unbemerkt deaktiviert werden.

Eine Konversation, die über das Rückblickfenster hinauswächst. „Das Rückblickfenster umfasst 20 Blöcke.“ Das System prüft an jedem Breakpoint höchstens 20 Positionen und beendet die Suche anschließend. Im dokumentierten Beispiel enthält ein Turn 35 Blöcke und hat einen Breakpoint auf Block 35. Das System 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 Blöcke nach 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 protokolliert haben, können Sie keinem Verursacher 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. Achten Sie auf cache_read: Eine Spalte voller Nullen ist der häufigste Kostenfehler bei einem selbst gehosteten Agenten.

Ein Feld kann leicht falsch interpretiert werden. 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. 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 vor dem Senden. Das Zählen von Tokens ist kostenlos und hat eigene Rate Limits, die von der Nachrichtenerstellung getrennt sind. Verwenden Sie daher count_tokens, um einen zu großen Anhang abzulehnen, statt erst durch den Versand Kosten zu verursachen. Das Ergebnis ist eine Schätzung. Messen Sie deshalb für jedes Modell neu und verwenden Sie niemals einen Zählwert vom Tokenizer eines anderen Anbieters erneut. Claude 4.7 und spätere Modelle, darunter 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 Modelle, darunter Claude Haiku 4.5, verwenden den vorherigen Tokenizer.

Für die maßgebliche Übersicht meldet die Admin API die Nutzung unter https://api.anthropic.com/v1/organizations/usage_report/messages und die Kosten unter https://api.anthropic.com/v1/organizations/cost_report. Beide Anfragen verwenden einen Admin-Key (sk-ant-admin01-...) als x-api-key: $ANTHROPIC_ADMIN_KEY mit anthropic-version: 2023-06-01. Der Nutzungsbericht akzeptiert bucket_width=1d, group_by[]=model und api_key_ids[]=. Der Kostenbericht ist nur täglich verfügbar und gruppiert nach workspace_id oder description. Eine Einschränkung lautet: „Die Admin API ist für Einzelkonten nicht verfügbar.“

Der Parameter api_key_ids[] ist ein einfacher Trick zur Zuordnung: Geben Sie jedem Job einen eigenen API-Key, filtern Sie den Nutzungsbericht mit api_key_ids[] und teilen Sie ihn mit group_by[]=api_key_id nach Schlüssel auf. Der Filter steht im Plural, die Gruppierungsdimension im Singular. Speichern Sie die Schlüssel in der Umgebung und nicht im Code, wie es eine erste Claude-API-Anwendung auf einem VPS macht.

Die Schleife begrenzen, weil es sonst niemand tut

Eine begrenzte Anzahl von Iterationen ist hier nicht optional. Die Schleife stammt von Ihnen, also liegt auch der Zähler bei 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 Obergrenzen übernimmt diese Aufgabe für Sie: max_tokens begrenzt eine einzelne Antwort, und das Modell erhält lediglich einen Hinweis auf ein Aufgabenbudget. Ein gehostetes Produkt würde die Ausführung an dieser Stelle beenden, ähnlich 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 Notbremse, bis Sie eine hinzufügen.

Setzen Sie außerhalb des Prozesses eine zweite Notbremse. Starten Sie den Job über einen systemd-Timer statt über einen dauerhaft laufenden Prozess, und legen Sie für die zugehörige Service-Unit eine maximale Laufzeit fest. Ein Timer-Job ist normalerweise Type=oneshot, und RuntimeMaxSec= „hat keine Wirkung auf Type=oneshot-Services“. Setzen Sie den Wert daher dort auf TimeoutStartSec=600. Verwenden Sie RuntimeMaxSec=600 nur für eine Type=simple-Unit. In beiden Fällen wird ein hängender Lauf nach zehn Minuten beendet, statt so lange weiterzulaufen, bis Sie ihn bemerken. Ein Programm als systemd-Service und Timer ausführen behandelt die Unit-Dateien selbst. Mit journalctl -u triage-agent.service --since "1 hour ago" können Sie prüfen, was ein Lauf ausgeführt hat.

Begrenzen Sie auch die Wiederholungsversuche, weil ein Handler, der unbegrenzt 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 ständig laufender Agent kostet. Die Kosten ergeben sich aus den Tokens pro Ausführung multipliziert mit den Ausführungen pro Tag. Beide Werte legen Sie selbst fest. Führen Sie den Agenten einmal aus, lesen Sie die protokollierte Nutzungszeile ab und multiplizieren Sie den Wert mit Ihrem Zeitplan. Vergleichen Sie den Kostenbericht zwei Tage später mit dieser Berechnung. Wenn die beiden Werte voneinander abweichen, liegt die Ursache fast immer in einem fehlerhaften Cache oder in 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 beschreibt welcher Claude-Tarif zu Ihrer Arbeitsweise passt die Seite mit den Abonnements. Alle Preise und Limits wurden im Oktober 2026 anhand der Dokumentation von Anthropic geprüft. Lesen Sie daher die Preisseite erneut, bevor Sie ein Budget erstellen.

FAQ

Wie viel kostet der Betrieb eines ständig aktiven AI-Agenten auf einem VPS?

Es gibt zwei Abrechnungen, aber nur eine davon ist vorhersehbar. Der Server hat einen festen monatlichen Preis. Die Model-API wird pro Token abgerechnet. Die Kosten entsprechen daher dem Verbrauch eines einzelnen Laufs multipliziert mit der Ausführungshäufigkeit. Anthropic veröffentlicht keine Zahl für einen selbst gehosteten, ständig aktiven Agenten. Betrachten Sie daher jede genannte Zahl als Schätzung. Protokollieren Sie usage aus einem echten 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 der Denkprozesse. Bei Erreichen des Limits wird stop_reason: "max_tokens" ausgegeben. Ein Aufgabenbudget funktioniert umgekehrt: Das Modell erhält die Zahl und passt die agentische Schleife daran an. „Task budgets are a soft hint, not a hard cap“; das weiterhin erzwungene Limit ist max_tokens.

Warum ist cache_read_input_tokens bei meinem Agenten immer null?

Der Präfix ändert sich zwischen den Aufrufen oder ist zu kurz für das Caching. Häufig wird ein Zeitstempel oder eine Lauf-ID in den System-Prompt eingesetzt. Der Cache verwendet den Präfix als Schlüssel. Daher macht jede Byte-Änderung alle nachfolgenden Inhalte ungültig. Änderungen an den Tool-Definitionen oder am Wert effort auf der obersten Ebene haben 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 nach einer festen Höchstzahl. max_tokens begrenzt nur eine Antwort, während ein Agent viele Antworten erzeugt. Fügen Sie außerhalb des Prozesses ein Zeitlimit hinzu. Starten Sie den Job über einen systemd-Timer und setzen Sie TimeoutStartSec= bei einer oneshot-Unit oder RuntimeMaxSec= bei einer einfachen Unit. Dadurch wird ein blockierter Lauf nach dem Zeitplan beendet. 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 für einen Workspace und nicht für einen einzelnen Schlüssel. Weisen Sie dem Agenten daher einen eigenen Workspace zu und begrenzen Sie dort die monatlichen Ausgaben. „You cannot set limits on the Default Workspace“. Richten Sie zusätzlich Ausgabenbenachrichtigungen ein, damit Sie bei einem Schwellenwert zuerst alarmiert werden. Verwenden Sie für die Zuordnung einen eigenen Schlüssel für jeden Job und gruppieren Sie anschließend den Nutzungsbericht mit group_by[]=api_key_id.