DEV Community: Ricardo Martin

How to reduce your Vercel bill

Ricardo Martin — Fri, 17 Jul 2026 13:29:00 +0000

A couple of weeks ago, I got an email from Vercel: 50% of the credits included in my Pro plan were already gone. Only 2 days into my new billing cycle.

For context, I’m working on a pet-project: Framecount, a movie-tracking app, which had been running for almost a year with ~200–300 monthly users and zero issues. However, I recently published a dynamic sitemap with more than 15,000 entries, and a few weeks later, traffic went up like crazy, and that made the bill explode also.

Over the next two weeks, I went through a painful trial-and-error process trying to reduce costs. Some optimizations barely helped, but one in particular reduced my daily spend by exactly 92,37% almost instantly.

This post is a breakdown of some of the things I ran into when optimizing Vercel costs, explained as simply as possible, because a week ago, I didn’t understand any of this either.

My journey to reduce Vercel costs

How Vercel bills you (a mental model)

Most Vercel bills come from 4 buckets:

Category	What it means	Typical causes
Image Transformations	On-demand image resizing & encoding	Abusing `next/image` + many sizes in config
Fast Data Transfer	Static assets served from CDN → user traffic	Large pages + a lot of static assets
Fast Origin Transfer	Functions, ISR, Middleware	Server fetches and unwanted side-effects
Edge Requests	Cached & uncached requests	Big amount or uncached requests (Bots, crawlers)

Vercel Firewall: The Biggest Win

After trying multiple optimizations just to save a few cents per day, I realized the real cost was caused by another thing. A couple of weeks after publishing a huge sitemap, my site started receiving tens of thousands of requests per day. I didn't know at that moment, but most of them were automated, many hitting expensive routes. That alone accounted for ~80% of my daily spend.

When I realized, I assumed this was normal (and even good): more bots meant better indexing, right? Turns out that’s not totally true.

Bot management

Not all bots are good. Search engine crawlers need access to your site to index public pages and usually behave well. The problem starts when bots start aggressively hitting expensive uncached routes, or crawling the same pages endlessly. Those bots add no value, they just burn compute, cache writes and Edge requests.

There are several ways you can protect yourself from malicious bots. The easiest is using Vercel Firewall. Under Firewall → Rules, Vercel provides some key protections.

Bot protection configuration in Vercel Firewall

AI Bots	Bot Protection
Blocks known AI scrapers used to collect training data for LLMs. If you’re unsure what’s hitting your site, start by enabling Logs only. You’ll get visibility without blocking anything. Once confirmed, you can safely enable blocking.	Vercel maintains an allowlist of legitimate crawlers, so Googlebot, Bing, etc. are not affected. ⚠️ this also blocks tools like curl, since they’re not browser-like clients. If you rely on them, combine bot protection with more targeted rules or rate limits.

[!note]
Blocking AI bots does not affect your presence in search engines or LLM recommendations.

Add a "human-safe" rate limit

Even with bot protection enabled, adding a soft rate limit is not a bad idea, especially for expensive or high-traffic paths. If you're unsure about how to configure it, here's a simple starting point:

Request Path - matches - /your-expensive-route/*
100 requests / minute / IP

Real users will (almost) never hit this, but this gives you an alternative or an extra protection against malitious bots and other attackers.

What about `robots.txt`?

A strict robots.txt helps, but by itself it’s not enough, since many abusive bots ignore it completely. It adds up, but probably not the solution if you're receiving a spike in traffict caused by bots.

Image Optimizations

Vercel strongly encourages using their Image component, and for good reasons: it improves performance, applies modern formats, and handles responsive images automatically. The catch is that it is a bit tricky to understand when transformations are beneficial vs when not, specially because every image transformation costs money.

The first time a specific image variant is requested (for a given size, format and quality), Vercel processes that image through an special optimization pipeline. That process generates a "transformation", which is then cached and reused for subsequent requests of that exact same variant. If the same image is later requested at a different size, format, or quality, Vercel has to generate (and charge for) a new variant.

Image optimization is most useful when:

the same images are requested many times
at the same sizes
by real users

It becomes expensive when configuration restrictions are vague (many sizes or formats allowed) or when images are rarely reused (low traffic or they appear in few unimportant places in your site).

In my case, I was using images from TMDB, which already serves images at predefined sizes (w185, w500, w780, …). By letting Next.js re-optimize them again, I was paying twice for work that was already done.

First rule: don’t optimize what’s already optimized

If your image provider already gives you the exact size you need, disabling optimization is often the cheapest option. You’ll still pay for Fast Data Transfer, but you avoid paying for unnecessary transformations and cache writes.

This is not always possible (and not always obvious) so here’s how to reduce image costs when you do rely on Vercel’s optimizer.

Reduce the number of variants

The biggest cost driver is the number of variants Vercel has to generate. By default, Next.js allows many sizes, formats, and qualities, which multiplies quickly (and most of the times is unnecessary).

Reducing your image configuration to a few sensible options can dramatically cut the number of transformations:

```ts title="next.config.ts"
module.exports = {
images: {
deviceSizes: [640, 1080, 2048],
imageSizes: [64, 384, 1024],
formats: ['image/webp'],
},
}




Fewer sizes means fewer variants. Fewer variants means fewer transformations.

If your images don’t change often, increasing `minimumCacheTTL` also helps by keeping optimized images cached for longer:



```ts title="next.config.ts"
module.exports = {
  images: {
    minimumCacheTTL: 12_592_000, // 30 days
  },
}

Static images are basically free

Local images imported statically at build time are hashed and cached as immutable. Once built, they don’t trigger runtime transformations at all.

If an image is part of your UI or content and doesn’t change, prefer static imports whenever possible:

import img from './images/my-image.jpg'

return (
  <Image src={img} /> // no need to specify 'sizes' for local assets
)

Don’t optimize images no one sees

Images outside the viewport are often requested and optimized even if users never scroll far enough to see them. Adding loading="lazy" prevents a lot of unnecessary work (especially from bots).

This won’t stop all automated traffic, but it significantly reduces wasted transformations:

<Image ... loading="lazy" />

If none of the above works, turning optimization off is the right call

If image costs are still too high, don’t be afraid to selectively disable optimization using unoptimized.

This is especially useful for large lists or galleries where most images are rarely seen:

<>
  {images.map(({ imageId, imageSrc, imageAlt }, index) => (
    <Image key={imageId} src={imageSrc} alt={imageAlt} unoptimized={index < 20} />
  ))}
</>

Sometimes, serving images “as-is” via the CDN can be cheaper than continuously transforming them.

Server-side costs (requests, compute and caching)

One big spend hole on Vercel usually comes from server-side work: requests that trigger code execution, database queries, or cache reads/writes. These usually fall into three categories:

Fast Data Transfer: raw data sent from the CDN to users (assets, images, HTML,...)
Fast Origin Transfer: server-side execution (Functions, Middleware, ISR)
Edge Requests: how often a request reaches the Edge or origin, cached or not

If you’re investigating a cost spike, always start with your top paths. In most cases, the homepage is the main culprit.

The key thing to understand is that server-side costs scale with requests, not users.

One user loading a page once is cheap. Thousands of bots hitting the same page can become extremely expensive if each request triggers server work.

Journey of an Edge Request

Fast Data Transfer

Fast Data Transfer is mostly about how much data you send to users: JS bundles, images, fonts and static assets.

In practice, the biggest wins come from:

not shipping assets that aren’t immediately needed
lazy-loading anything outside the viewport

Fast Data Transfer is relatively cheap and often improves automatically as a side effect of other optimizations (image optimization, caching, etc.).

[!INFO]
Counter-intuitively, if image optimizations go down and Fast Data Transfer goes up, that can be a good sign; it usually means fewer transformations and more direct asset delivery. The key is finding the right balance to avoid FDT from exceeding the cost of transformations.

[!TIP]
If Fast Data Transfer becomes your main cost driver, Vercel may simply not be the best platform for your use case. Consider migrating to Cloudflare or a custom VPS that fits your needs better.

Fast Origin Transfer

What makes this tricky is that most of this work is invisible. Nothing seems broken, everything goes fast, but every request is doing real work on the server. Every time a request:

runs a Server Component
hits a Route Handler
executes Middleware
regenerates an ISR page

you’re paying for compute. The most straightforward optimization we can do here relies on the middleware.

Middleware

Middlewares are functions that run automatically for every incoming request, allowing you to inspect or modify the request data before it reaches your application's routing system. In Next.js, you're charged for every invocation of the middleware, sometimes even twice (preflight + request), so reducing the number of times it runs is one of best way of reducing extra costs.

If your middleware only protects authenticated routes, don’t let it run on public pages. Use a matcher (Next.js comes with that feature built-in - Next.js Matcher).

Less middleware execution = fewer compute costs.

Edge Requests

This was one of the biggest issues in my case. The problem with this is that many of these issues are invisible in development: low traffic hides inefficiencies that only become expensive once real or automated traffic hits production.

My homepage was receiving most of the traffic and was doing 20+ server-side fetches, none of them cached. Every single visit triggered all of them again.That works fine at low traffic, but it scales pretty bad. This is especially easy to miss when using Server Components. Fetching data in the server feels "free" during development, but in production, every fetch runs on every request unless it’s explicitly cached.

Rule of thumb: if data is the same for most users and doesn’t change every minute, cache it.

You can cache at the page level:

export const revalidate = 3600 // 1 hour

Or at the fetch level

await fetch(url, { next: { revalidate: 3600 } })

Make sure “static” pages are actually static

I explicitly marked some pages as static (ISR), but they were still rendered dynamically.

Why? Because calling Prisma directly inside a Server Component forces the page to be dynamic, and Next.js won’t warn you.

Next.js can generate pages as dynamic even when you explicitly tagged them as static. To check it out, review the build output and ensure your routes are generated as "ISR" or Static if that's what you want.

Next.js tells you which routes are dynamic vs static after running npm/pnp/yarn run build

Reduce database calls

Every database query counts as work. Multiple queries per request add up very quickly.

A common pattern I saw many times looks like this (this is a simplified example, but it illustrates a very common pattern in server-rendered pages):

const movie = await prisma.movie.findUnique({ where: { id } })

const director = await prisma.person.findUnique({
  where: { id: movie.directorId },
})

const relatedMovies = await prisma.movie.findMany({
  where: { genre: movie.genre },
})

const watchEvents = await prisma.watchEvent.findMany({
  where: { userId, movieId: id },
})

That’s four separate database calls for a single page view.

In many cases, this can be reduced to one or two queries using include or batching:

// Using Prisma's ORM built-in `include` feature
const movie = await prisma.movie.findUnique({
  where: { id },
  include: {
    director: true,
    relatedMovies: true,
    watchEvents: {
      where: { userId },
    },
  },
})

// OR you can parallelize non-dependent requests
const movie = await prisma.movie.findUnique({ where: { id } })

const directorPromise = prisma.person.findUnique({
  where: { id: movie.directorId },
})

const relatedMoviesPromise = prisma.movie.findMany({
  where: { genre: movie.genre },
})

const watchEventsPromise = prisma.watchEvent.findMany({
  where: { userId, movieId: id },
})

// This still results in multiple database queries,
// but they run in parallel instead of sequentially,
// reducing total request time and compute usage.
const [director, relatedMovies, watchEvents] = await Promise.all([
  directorPromise,
  relatedMoviesPromise,
  watchEventsPromise,
])

Reducing the number of queries is ideal, but when that’s not possible, running them in parallel is still a meaningful improvement.

Avoid duplicate server calls (Metadata is the common trap)

I found this pattern to be extremely common:

fetch data in generateMetadata (for SEO)
fetch the same data again in the page component

That’s two server calls per request.

You can fix this with request deduplication using React’s cache:

import { cache } from 'react'

export const getMovieCached = cache(async (id: number) => {
  return getAPIMovieDetails(id)
})

Now metadata and rendering share the same request.

To close this section, remember that most Vercel bills don’t rocketship because of one big mistake, but because of many small server-side decisions that little by little scale with traffic.

Extra: Add a Spend Management Limit

It seems obvious, but I already saw quite a few people in Twitter complaining after receiving a Vercel Bill of thousands of dollars in just one weekend.

If you're planning to publish your website to the world, configure a limit with which you're comfortable even when your traffic is very low (even if it is only you using your site).

You can also configure several notification thresholds and decide whether to suspend your site when the limit is reached or just get notified.

Cost Optimization Checklist (wrap-up)

If you're under one of this situations, you can expect a surprise in your bill almost for sure:

Cause	Solution
You published a large sitemap	Enable Bot Protection / Rate Limiting
Your most visited pages do a lot of server-side fetching	Cache aggressively (ISR / revalidation) or move logic behind auth
You use Middleware globally	Remove runs from unnecessary pages using a `matcher`
You rely on `<Image>` with many sizes	Reduce sizes + Increase caching time + Add `unoptimized` to some images

Final Thoughts

We all have heard the statement: "Vercel is so expensive", and yes, it is, but most of the times the extra costs come for bad configuration, either coming from unexpected usage of your site or simply because traffic increase was not planned and you never faced this situation before, like it was in my case.

The good part is that I was able to reduce my bill by 92% in just a few days, learned a lot along the way and now my website is more robust and scalable, and it turns out is faster than ever after applying some of the improvements mentioned in this post 🤯. One of the biggest takes from this experience: Optimizing for performance and optimizing for cost are related, but not the same thing.

Lesson learned, Vercel ☝️🤓

Useful resources

Keep your Claude Code cost, usage, and context info always visible

Ricardo Martin — Fri, 10 Jul 2026 17:20:45 +0000

As LLMs become better and our AI usage grows, managing token usage as well as model's context window has become increasingly important.

Three months ago, I switched to Claude Code from Cursor, and I quickly started to miss having that information always visible. A few weeks in, I found myself constantly hitting the /usage command to check how the session was performing in terms of cost, token input/output and overall context window status.

I was wondering: If all that data already exists, I should be able to bring it wherever I want and see it change in real time. And it turns out it is not only possible but also quite easy to do.

The key component we're looking for is the status line. That thin row under your prompt can become a small dashboard, tailored to exactly the numbers you care about (and it is highly customizable!). Here is how to set it up, and a few things the docs do not tell you.

What the status line actually is

The status line is not a fixed set of toggles. It is a command you define. Claude Code runs it, pipes a JSON blob describing the current session into it via stdin, and prints whatever your command writes to stdout.

That is the mental model, and this is the important part: if you can compute it in a script, you can show it. Cost, model, branch, context percentage, failing tests, the ticket you are on, etc.

The JSON output looks roughly like this:

{
  "model": { "id": "claude-opus-4-8", "display_name": "Opus" },
  "workspace": { "current_dir": "/Users/you/projects/app" },
  "cost": {
    "total_cost_usd": 0.4213,
    "total_lines_added": 156,
    "total_lines_removed": 23
  },
  "context_window": {
    "used_percentage": 42,
    "total_input_tokens": 99201,
    "total_output_tokens": 1822
  }
}

The fast way: let Claude write it

Claude Code ships a command that configures a status line for you: /statusline. It takes plain-English instructions, so you can be specific — for example, /statusline show the model, git branch, context percentage and session cost.

Claude writes the script, drops it in ~/.claude/, and wires it into your settings. If you just want to get started, you can stop reading here.

The advanced way: creating and configuring your own script

If you're nitpicky like me, the alternative is to write the script yourself, so it shows exactly what you want and nothing else. I run Claude Code inside Warp, which already surfaces things like the working directory and git branch in its own UI, so I deliberately left those out of the status line and kept only the session numbers I can't get anywhere else: the model, cost, context usage, token input/output, and lines changed by the agent in the current session.

#!/usr/bin/env bash
# ~/.claude/statusline.sh
input=$(cat)

model=$(echo "$input"   | jq -r '.model.display_name')
cost=$(echo "$input"    | jq -r '.cost.total_cost_usd // 0')
ctx=$(echo "$input"     | jq -r '.context_window.used_percentage // 0' | cut -d. -f1)
in_tok=$(echo "$input"  | jq -r '.context_window.total_input_tokens // 0')
out_tok=$(echo "$input" | jq -r '.context_window.total_output_tokens // 0')
added=$(echo "$input"   | jq -r '.cost.total_lines_added // 0')
removed=$(echo "$input" | jq -r '.cost.total_lines_removed // 0')

printf "[%s] \$%.4f | ctx %s%% | in %s | out %s | +%s/-%s" \
  "$model" "$cost" "$ctx" "$in_tok" "$out_tok" "$added" "$removed"

Which renders as a single row:

[Opus 4.8 (1M context)] $6.8190 | ctx 10% | in 99201 | out 1822 | +188/-6

A couple of details worth pointing out:

The // 0 in each jq filter acts as a fallback. Some fields are null before the first API response of a session (and after a /compact), so without it you would get an empty value printed in those cases.
context_window.total_input_tokens and total_output_tokens are the tokens currently in the window (input already includes cache reads and writes), not cumulative session totals — so they track what is actually loaded right now, next to the ctx percentage.

Make it executable:

chmod +x ~/.claude/statusline.sh

And point your settings at it in ~/.claude/settings.json:

{
  "statusLine": {
    "type": "command",
    "command": "~/.claude/statusline.sh"
  }
}

Settings reload on their own, but the line only redraws on your next interaction with Claude Code.

This is what mine looks like in a real session

[!TIP]
Test the script before wiring it up, so you don't end up debugging blind inside Claude Code. Pipe it some mock JSON and check the output:

echo '{"model":{"display_name":"Opus"},"cost":{"total_cost_usd":0.42,"total_lines_added":10,"total_lines_removed":2},"context_window":{"used_percentage":42,"total_input_tokens":99201,"total_output_tokens":1822}}' | ~/.claude/statusline.sh

Tips the docs don't explain

A few things I found out after using it for a while:

Watch context, not just cost. Cost is the number we naturally reach for, but context_window.used_percentage is the one that actually changes how you work. Seeing the window fill up tells you when to /compact or start fresh before quality degrades.

Refresh on a timer for anything time-based. Updates are event-driven (after each message, after /compact, and so on), which means they go quiet when the session is idle (e.g. while background subagents churn). Add "refreshInterval": 5 next to your command to also re-run every N seconds and keep a clock or live git state fresh.

On Pro/Max, you can surface rate limits. The JSON carries rate_limits.five_hour and rate_limits.seven_day with a used_percentage each. This is handy if you're using the latest models in xhigh or higher thinking mode.

[!NOTE]
If you prefer not having to maintain the script yourself, there are some community projects out there like ccstatusline that give you a themeable status line with a configuration UI, no bash required. This will get you much fancier results in no time.

Bonus: an overview of your subagents, too

There's a sibling setting for showing some of the information we have in our statusline for each subagent spawned within the same section too: the subagentStatusLine, which lets you reformat every row in the agent panel the way you reformat the main line:

{
  "subagentStatusLine": {
    "type": "command",
    "command": "~/.claude/subagent-statusline.sh"
  }
}

Before wiring it up, two things worth knowing so you don't end up debugging the wrong thing:

It styles the in-session agent panel, not the sessions manager. These are two different screens. The full-screen dashboard you reach with claude agents lists your independent sessions across projects, and subagentStatusLine does not touch that one. What it customizes is the panel of subagents that appears right below your prompt when you are inside a session and Claude spawns child agents (through its Task tool). So to see your script run: open a session, spawn some subagents, and watch the rows beneath the prompt.
Cost is not one of the fields. Unlike the main status line, the per-agent payload has no cost object at the moment, so you cannot show a dollar figure next to each agent. What you do get per task is id, name, status, model, tokenCount, and contextWindowSize — which is the barely minimum (and to me, more than enough) for a context percentage, arguably the more useful signal for an agent that is still running.

The command runs once per refresh and receives every visible agent at once, as a tasks array on stdin. You answer with one JSON line per row you want to override, in the shape {"id": "…", "content": "…"}. Here is a starting point that shows each agent's name, model, context usage, and status — adapt it to taste:

#!/usr/bin/env bash
# ~/.claude/subagent-statusline.sh
input=$(cat)

# Emit one {id, content} line per agent: name · model · context % · status
echo "$input" | jq -c '
  .tasks[]
  | select(.contextWindowSize and .tokenCount)
  | { id,
      content: "\(.name)  ·  \(.model // "…")  ·  \(((.tokenCount * 100) / .contextWindowSize) | floor)% ctx  ·  \(.status)" }'

Make it executable (chmod +x ~/.claude/subagent-statusline.sh) and it takes over each agent row.

[!NOTE]
The per-agent model and contextWindowSize fields need Claude Code v2.1.205 or later, and are omitted for an agent whose model has not resolved yet. The select(...) above just leaves those rows with their default formatting until it does. Any row whose id you don't return keeps the default name · description · token count, and an empty content hides a row entirely.

Each agent's model and context usage at a glance in the subagent panel below the prompt

Why having this information in real time helps

Even though you have the Max plan, in my opinion it is a good idea to keep track of your context, cost and overall usage for the following reasons:

Real-time cost awareness. Watching spend accumulate nudges better decisions about when to open a fresh session or compact context, as well as understanding how you're being charged based on the model and thinking mode you're using. In my case, I was able to get the same results 95% of the times by reducing the cost ~40%, just by playing with the model and thinking mode. Raising awareness of real API cost usage is an increasingly important skill to develop, to be ready for when the party is over.
Knowing when to reset the context. Cost tells you what a session has spent; the context percentage tells you when it's about to get worse. It has been demonstrated that model quality degrades as the window fills up, as agents tend to reduce thinking cycles if they know the remaining context is small, so watching ctx climb is my clue to /compact or start fresh before the answers start slipping, instead of noticing after it.
Catching a runaway session early. When the token or cost counters climb faster than the requested task complexity suggests, that's usually a sign something is off: an agent stuck in a loop, re-reading huge files, or running a heavier thinking mode than it needs. Having the numbers in front of me means I catch it fast and I can step in.

Go deeper

To deep dive on this feature; every JSON field, the /statusline command, padding, multi-line output, colors, and clickable links, visit the official docs: code.claude.com/docs/en/statusline