Your $4,200 Weekend: When Prompt Injection Drains Your Anthropic Bill

Uber's CTO told the world they'd exhausted their 2026 AI budget months into the year. The largest line item in many engineering ledgers right now is AI inference, not salaries. One developer burned $4,200 in a single weekend after an autonomous refactor got stuck in a loop.

You don't have Uber's budget. You probably don't have $4,200 of slack in your monthly OpenAI bill either. And the difference between "I'm at $40 this month" and "I'm at $4,200 this month" might be one prompt injection or one missing max_tokens parameter away.

This is the cost-exhaustion attack class. The defenses are not exotic. They are not installed by default on any AI provider's SDK. You have to add them yourself.

1. Why agents are 50× more expensive than chats

A chat app calls the LLM once per user message. ~1K input tokens, ~500 output tokens. One round trip.

An agent does a reasoning loop. Each step sends the entire accumulated context — system prompt + tool descriptions + conversation history + file reads + tool outputs — back to the model. Twenty tool-call steps means twenty round trips, each one larger than the last. Per Gartner's March 2026 analysis, agentic workloads use 5–30× more tokens per task than a single chat response.

For an autonomous coding agent that reads files, edits, validates, re-checks: a single "improve this codebase" task can rack up 200K input tokens easily. On Claude Sonnet 4.6 that's around $0.60 per task. On Claude Opus it's $3.00. Run 1,000 tasks and you've spent your monthly grocery budget on one feature.

Now imagine those tasks aren't requested by you. They're requested by anyone who can hit your API endpoint.

2. Three paths to bill bomb

The same defenses work against all three. You don't need to identify which path is most likely — just install the three layers below and you've capped your worst case.

3. Layer 1 — set max_tokens everywhere

Never call an LLM without an output ceiling. Period.

// ❌ Vulnerable — unbounded output
const completion = await openai.chat.completions.create({
  model: "gpt-4o",
  messages,
});

// ✅ Capped
const completion = await openai.chat.completions.create({
  model: "gpt-4o",
  messages,
  max_tokens: 1024,        // 1K tokens ≈ ~750 words. Adjust per use case.
});

For Vercel AI SDK, Anthropic SDK, and Google's generative AI SDK the parameter names differ but the principle is the same:

• OpenAI / Vercel AI SDK: max_tokens
• Anthropic SDK: max_tokens (required parameter, but devs often set it absurdly high)
• Google generative AI: max_output_tokens

ShipSafe's llm/no-max-tokens rule flags calls missing this. Tighten the value per endpoint — a chat reply might need 512, a summarization 2048, a "give me one word answer" 50. Don't pick one number for the whole codebase.

4. Layer 2 — rate-limit at the edge

Every AI endpoint needs a rate limiter. Reasonable starting points:

• Unauthenticated requests: 10 per IP per minute.
• Authenticated requests: 60 per user per minute.
• Paid tier: 300 per user per minute.

// Vercel/Next.js with Upstash
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const limiter = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, "60 s"),
});

export async function POST(req: Request) {
  const ip = req.headers.get("x-forwarded-for") ?? "unknown";
  const { success } = await limiter.limit(ip);
  if (!success) return new Response("Too many requests", { status: 429 });
  // ... actual generation
}

ShipSafe's llm/no-rate-limit-on-ai-route flags AI endpoints without a recognizable rate limiter in context.

5. Layer 3 — per-user cost caps

Rate limits stop bursts. Cost caps stop slow drains. Track every user's daily token spend and refuse requests above a threshold.

// After every LLM call, log usage and check the cap
const result = await streamText({ ... });
await db.usage.increment(userId, {
  date: today(),
  inputTokens: result.usage.promptTokens,
  outputTokens: result.usage.completionTokens,
});

// Before the next call:
const todaysSpend = await db.usage.dollarsToday(userId);
const TIER_CAPS = { free: 0.50, pro: 10.00, team: 50.00 };
if (todaysSpend >= TIER_CAPS[user.tier]) {
  throw new Error("Daily AI usage cap reached");
}

The threshold is yours to pick. A free-tier user might cap at $0.50/day. A paid user at $10. Whatever you can survive multiplied by your user count is your worst case.

6. Monitoring you should add this week

• Provider-level budget alert. OpenAI, Anthropic, and Google all let you set a hard usage cap and an email alert threshold. Set both. The hard cap is your circuit breaker — when it trips your app stops costing money instead of continuing to burn until you notice.
• Real-time spend dashboard. Even a simple line chart of today's $ spent vs. yesterday at the same hour catches anomalies. Datadog, Grafana, or just a daily Slack message with the running total.
• Per-endpoint cost attribution. Tag every LLM call with which endpoint triggered it. When you see a spike, you want to know which endpoint to throttle without grepping logs at 3am.
• Tool-call iteration counter. For agents, log the iteration depth of each task and alert when it exceeds a threshold (e.g. 20). Loops show up here before they show up in the bill.

The combination of capped output, capped request rate, capped daily spend, and live monitoring means your worst-case scenario is "we noticed the spike in 5 minutes and our hard cap stopped it" — not "we got the bill at the end of the month."

The bottom line

AI cost exhaustion is the easiest "vulnerability" in the AI app stack to fix and the one most often skipped because the failure mode is "weird invoice next month" rather than "data breach today." But the dollar amounts are real, the attack is trivial, and the defense is three SDK parameters plus one cron job.

Set max_tokens. Rate-limit your endpoints. Cap daily spend per user. Add the monitoring. Don't be the $4,200 weekend.