Designing a Claude API Monthly Budget That Doesn't Blow Up — Cost Management for Solo Developers

For the first few months after I wired Claude API into my apps, I opened the Anthropic billing page before my Stripe dashboard on more mornings than I'd like to admit. The moment an LLM is in your product, your wallet is connected to a usage meter you don't fully control. If you're used to the simple "revenue minus server cost" math, variable API spend feels disorienting.

These are working notes from adding Claude API to a wallpaper app and a wellness app as a one-person developer. I wrote them so you can skip the mistake I made early on: picking Sonnet for a casual feature and finding that it had burned through 8,000 yen in a single day.

What I'd like to say up front is that cost management is not about frugality. It's about a way to measure and a way to stop. Let me walk through both.

Why Solo Developer Budgets Crack

Most LLM cost articles are written for companies, and they sit a little off when read with a solo developer's wallet. Companies plan around unit cost per request. Indie developers reason from a hard ceiling like "I can spend 50,000 yen a month, no more." What we protect is the total, not the unit.

In my experience, budgets break for one of three reasons.

The first is misjudging per-user volume. You assume average users will hit a feature five times a day, but a handful of power users hit it 200 times. While you're enjoying new reviews, the invoice is the only thing quietly growing.

The second is context bloat. If you send the whole conversation every turn, your tenth request carries far more than ten times the input of your first. We worry about output pricing, yet it's the accumulated input tokens that push the bill up.

The third is the retry trap. I once left a short client-side timeout in place with "retry up to three times on failure." The client hung up while a long response was still being generated, then sent the same heavy request again, so duplicates ran side by side. My logs filled with errors and the invoice didn't shrink. Whether a request that ended in an error is billed depends on the circumstances, so I no longer assume that "it failed, so it must be free."

Backing Out a Budget From the Ceiling Down

Start by deciding what you can afford. My own rule: API spend for a feature must not exceed 30% of the gross margin of the app it lives in. If projections cross that line, I trim the feature, put it behind a paid plan, or skip the integration.

Once you have a monthly cap, work backward:

allowed monthly spend (USD) / per-request cost estimate (USD)
= max requests per month

max requests per month / 30 / expected DAU
= max requests per user per day

If I cap a feature at 200 USD per month and Sonnet 4.6 costs about 0.01 USD per request, I can afford 20,000 requests a month. With 100 daily active users, each gets a little over six requests a day.

The useful moment is when you think, "six? That's barely anything." Many of us instinctively want to give the AI feature to everyone for free. Run this once and you'll see why free users probably need to stop at three a day, with the rest of the budget reserved for paying members.

Exchange rates move, so I convert my yen budget once at the start of the month with a fixed rate and leave it alone until the next. Re-running the formula mid-month made me react to noise.

Measure the Unit Cost Before You Trust It

The 0.01 USD above is a placeholder. Before shipping, call the real feature 20 to 30 times with realistic inputs, average the usage numbers, and feed the result back into the formula. If you skip this, the whole ceiling-down design rests on a guess.

For pre-flight estimates, the token counting endpoint (count_tokens) tells you the input size before you send anything, so you can refuse a request that would blow past your cap before any charge occurs.

Per-Model Pricing: Pick the Model Before You Write the Code

The official price page is public, so here is only the sense I carry around. These were the rough figures in my head in the first half of 2026 (prices change, so re-check the official table right before you integrate):

• Claude Haiku 4.5 — $1 input / $5 output per 1M tokens
• Claude Sonnet 4.6 — $3 input / $15 output
• Claude Opus 4.6 — $5 input / $25 output

Sonnet sits at three times Haiku. Build a Haiku-class job on Sonnet and that feature costs three times what it should. Each new generation reshuffles prices and strengths, so rather than memorize the ratio, I run my app's typical requests through each model once a month and compare. That habit outlasts any table.

My process is plain. Before integration, I test whether a smaller model can handle the task. Routine replies and classification go to the small model; code review and tangled summarization, where judgment matters, go to the larger one.

One more lever: work that doesn't need to be real-time, such as nightly batch classification or first-pass translation, can go through the Batch API at a lower rate than standard calls. Anything where nobody is waiting deserves the question, "could this be a batch job?"

Measuring: Token Logging Design

"Budget" makes people think of optimization tricks, but the highest-leverage move is building a layer that tells you exactly what you're spending now. Without it, every other tactic is a guess.

Whenever I add a Claude-powered feature, the logging wrapper comes first. The SDK returns usage on every response, so persist it. Record failures in the same function too.

import Anthropic from "@anthropic-ai/sdk";
 
const client = new Anthropic({ apiKey: process.env.ANTHROPIC_API_KEY });
 
// Prices change: keep them in config and review monthly (USD per 1M tokens)
const PRICES: Record<string, { in: number; out: number }> = {
  "claude-sonnet-4-6": { in: 3, out: 15 },
  "claude-haiku-4-5": { in: 1, out: 5 },
};
 
async function callClaudeWithLogging(params: {
  userId: string;
  feature: string;
  model: string;
  messages: Anthropic.MessageParam[];
  maxTokens: number; // output ceiling; force every caller to choose one
}) {
  const startTime = Date.now();
  try {
    const response = await client.messages.create({
      model: params.model,
      max_tokens: params.maxTokens,
      messages: params.messages,
    });
 
    const u = response.usage;
    const price = PRICES[params.model];
    const costUsd = price
      ? (u.input_tokens * price.in + u.output_tokens * price.out) / 1_000_000
      : null; // null for unregistered models so aggregation exposes the gap
 
    await db.apiUsageLog.create({
      data: {
        userId: params.userId,
        feature: params.feature,
        model: params.model,
        status: "ok",
        inputTokens: u.input_tokens,
        outputTokens: u.output_tokens,
        cacheReadTokens: u.cache_read_input_tokens ?? 0,
        cacheCreationTokens: u.cache_creation_input_tokens ?? 0,
        costUsd,
        elapsedMs: Date.now() - startTime,
        timestamp: new Date(),
      },
    });
    return response;
  } catch (err) {
    // Log failures too: "how many calls did I make on the outage day" pays off later
    await db.apiUsageLog.create({
      data: {
        userId: params.userId,
        feature: params.feature,
        model: params.model,
        status: "error",
        elapsedMs: Date.now() - startTime,
        timestamp: new Date(),
      },
    });
    throw err;
  }
}

Three details matter. A feature column tells you which integration spent the money. A required maxTokens gives each feature its own output ceiling. And a price table kept in config means you won't silently miss the day you switch models.

Without feature, when next month's invoice doubles, you can't find the cause. I tag mine at a fine grain, like "image-caption," "conversation-mode," and "translation."

A nightly batch aggregates this log by feature and user. The result goes into a notification to myself each morning, and I only open the details on days when yesterday's number jumped. Lowering the cost of looking has kept me looking more than raising the frequency ever did.

If you only want the day-over-day view, the query stays short. This SQL is what I ran against SQLite to check it; it lines up today, yesterday, and today's error count per feature (swap in the dates at run time).

SELECT feature,
  ROUND(SUM(CASE WHEN date(ts)='2026-10-15' THEN cost_usd ELSE 0 END), 4) AS today_usd,
  ROUND(SUM(CASE WHEN date(ts)='2026-10-14' THEN cost_usd ELSE 0 END), 4) AS prev_usd,
  SUM(CASE WHEN date(ts)='2026-10-15' AND status='error' THEN 1 ELSE 0 END) AS errors_today
FROM api_usage_log
WHERE date(ts) IN ('2026-10-14', '2026-10-15')
GROUP BY feature
ORDER BY today_usd DESC;

I keep errors in their own column because of the retry mistake I described earlier: on the days cost jumps, the error count usually jumps with it. I only noticed that a few weeks after adding the log. Until then I'd been staring at invoices and wondering why.

I also set a monthly spend limit in the Anthropic console. It's the last wall if my own controls break. The exact unit and naming of those limits can change, so check the current console screen.

Stopping: Per-User Caps You Build Yourself

The provider's rate limits cover requests and tokens per minute, which helps stability but not cost. To cap what one user can spend in a day, you enforce it in your own application.

A simple pattern is a daily counter keyed by user ID.

async function checkAndIncrementUsage(userId: string, estimatedCostUsd: number) {
  const today = new Date().toISOString().slice(0, 10);
  const key = `usage:${userId}:${today}`;
 
  const dailyCapUsd = await getUserDailyCap(userId); // 0.05 free / 1.0 paid, etc.
 
  const currentUsage = parseFloat((await kv.get(key)) ?? "0");
 
  if (currentUsage + estimatedCostUsd > dailyCapUsd) {
    throw new Error("DAILY_LIMIT_EXCEEDED");
  }
 
  await kv.put(key, String(currentUsage + estimatedCostUsd), {
    expirationTtl: 86400 * 2, // auto-expire after two days
  });
}

This code has a trap I stepped in myself. Between the read and the write, another request can slip in, so a user who fires several calls at once can pass slightly over the cap. Cloudflare KV is also eventually consistent, so a read right after a write from elsewhere may return an old value.

If you need a hard stop, move to an atomic increment such as Redis INCRBY, or to something that serializes per user, like Durable Objects. For a free tier where a few cents of drift is acceptable, the code above does little harm.

A cap of a few cents a day per free user limits the damage from an abusive user or runaway bot. In my apps, paid users get a cap more than ten times the free one. Almost no real user reaches it, so the limit is invisible to good actors and a lifesaver when something goes wrong.

Keeping Context From Bloating

I said swollen input drives the bill. Three stages make the fix easy to reason about.

At stage 1, trimming one message at a time can leave an assistant turn at the head of the list, which may return a 400 error. Remove user and assistant messages as a pair.

Prompt Caching: Savings That Only Work If You Verify Them

Prompt caching lets you reuse a system prompt or long context at roughly one-tenth of the normal input price on reads. Writing to the cache, however, costs more than a normal call. It pays off only when the same content is reused within a short interval.

One of my wallpaper apps has Claude write a one-line caption for the image a user picks. The system prompt (tone, things to avoid) is long, so I made it cacheable. When one user tries several images in a row, the input side gets lighter from the second one on.

const response = await client.messages.create({
  model: "claude-sonnet-4-6",
  max_tokens: 200,
  system: [
    {
      type: "text",
      text: longSystemPrompt, // mark this block with cache_control
      cache_control: { type: "ephemeral" },
    },
  ],
  messages: [{ role: "user", content: userMessage }],
});
 
// Verify it is actually working
console.log(response.usage.cache_creation_input_tokens, response.usage.cache_read_input_tokens);

What I learned the hard way is that a cache you think you wrote can silently not exist. If the block is under the minimum token count, nothing errors; it just isn't cached. The minimum differs by model, so check the current official documentation.

If cache_read_input_tokens stays at zero, it isn't working. I check those two numbers the day I ship, not on the invoice a month later. The default lifetime is five minutes, and if your traffic comes in wider gaps than that, the write surcharge can cost you more than it saves.

Rethinking Retry Strategy

Unconditional retries are a time bomb in your cost model. When the API is unstable and returning 429 or 529/503, aggressive resending means the moment service recovers, everything queued fires at once.

I follow three rules.

First, cap retries at two. Few production failures I've seen are rescued by a third attempt.

Second, use exponential backoff with a little jitter. For 429, wait at least a few seconds, preferably thirty. If the server sends a retry-after, honor it first.

Third, put a circuit breaker in front. If ten 5xx responses arrive in a minute, stop calling for five minutes and show a "busy" state. It has been the most effective single piece for stopping chain reactions.

Back to the timeout story from the top: for features with long outputs, don't shorten the client timeout. Receive by streaming, or tighten max_tokens so you don't generate long responses in the first place. That removes the resend cost at its root.

class CircuitBreaker {
  private failures: number[] = [];
  private openUntil: number = 0;
 
  shouldAllow(): boolean {
    return Date.now() >= this.openUntil;
  }
 
  recordFailure() {
    const now = Date.now();
    this.failures = this.failures.filter((t) => now - t < 60_000);
    this.failures.push(now);
 
    if (this.failures.length >= 10) {
      this.openUntil = now + 5 * 60_000; // open for five minutes
      this.failures = [];
    }
  }
 
  recordSuccess() {
    this.failures = [];
  }
}

The breaker guards against provider outages, but it also catches your own buggy code hammering the API, which in practice is the more common cause.

What My Monthly Loop Looks Like

Putting it together, here is the rhythm I actually run.

Every Monday morning, I get last week's usage summary. Anything more than 30% above the previous week gets investigated. Nearly always it's a feature launch or one user behaving oddly.

On the 25th, I forecast the month-end total. If it's heading past 80% of the cap, I prepare a soft throttle for the last few days and tell users plainly that this month's usage ran higher than expected and some features will be limited until month-end. People take that well, and it has nudged some toward upgrading.

Each quarter, I compute ROI per feature: revenue contribution divided by API cost. Anything clearly losing money gets retired or moved behind the paywall. A free feature that was popular but ROI-negative went to Pro only; churn was lower than I feared and conversion edged up.

Limiting where I look is part of the discipline. Daily, just one line of day-over-day change. Weekly, by feature. Monthly, ROI and the price table. Since I settled on those three layers, checking stopped feeling like a chore.

Closing Thought

Cost management is not willpower; it's instrumentation and ceilings. If you do only one thing today, add the usage logging wrapper. That turns "I noticed too late" into "I see it before it grows."

Then call your feature's typical request about twenty times and work out the real cost per request. I started over from that number too.

If you want a next step, the companion piece Designing a Revenue-Producing Claude API App — From Token Visibility to Billing Models shows how to extend this logging foundation into a real billing system.