Frugal recently added Call Sites and we are hearing from developers that its a view that is really helping them understand how their code is spending and what to do about it.

The anatomy of modern applications

As cloud-native engineers, we are all creating applications that run in the cloud and make use of various services. We are storing files to S3 or Cloud Storage. We are using managed database services. We are calling out to AI services for inference. All that usage costs something. A lot of the places in the code cost very little, but for some it is really expensive. Where there is a real cost problem, engineers can often spend some cycles and make changes to reduce the costs.

The first challenge is knowing where it matters. Of the dozens of places in the application that work with an external service, which places are actually driving significant cost?

Then the second challenge, once you have found the line of code that is driving the cost, is understanding why and what can be done to reduce that cost.

"We are spending $42,000 a month on Anthropic, that's too much" isn't very actionable for an engineer. That's how you start a research project.

"This line of code is spending $21,000 a month on Anthropic, and here's data that breaks down that cost further" is something an engineer can immediately work with.

So the second one is the view we set out to deliver in Frugal.

What's a call site?

A call site is a location in the application code that invokes a usage-billed service. At its simplest its the line of code that does the SDK invocation. However that isn't always very informative to an engineer, there are times where the distinct usage of the service is really a level or two up in the call stack, for instance in the case where there is a shared wrapper for the service. So the useful call site is the code location where the application's intent becomes distinct. At that level an engineer or a team should recognize that code as theirs.

Let's see it

Here's a call site from one of our demo repos: get_recommendations, a Python function that calls the Anthropic Messages API to generate product recommendations.

Top of the page, the money: $8,937 a month. That's 85% of what the Recommendations component spends on Anthropic, and 21% of what the whole organization spends on the Anthropic Messages API. One function. Before you've scrolled, you already know whether this call site deserves your afternoon.

Then the code itself, with the calling line highlighted and a link to open it in GitHub. Right below, the configuration Frugal detected from that code: the model, the token limits, how responses are structured, whether streaming and caching are in play. This is the "what did we ask for" half of the story.

The rest of the page is the "what actually happened" half:

Cost trend. Six days at roughly $230, one day at $860. When your AI bill jumps and somebody asks why, this chart is the difference between an answer and a shrug. You're not staring at a service-level line item wondering which of forty components moved. You're looking at the exact function that did it.

Volume and tokens. 15,200 calls last week, about 76 input tokens and 12 output tokens per call, with cache reads, cache writes, and a third of the traffic batched. This is where waste hides, not in any single call but in the shape of millions of them.

Prompt efficiency. How much of the output cap responses actually use, how stable the prompt prefix is for caching, how much of the prompt is noise. These are the numbers that turn "maybe we could tune this prompt" into a to-do list.

Latency and errors. Not because Frugal is trying to do APM, but because context matters when you're deciding what to change. A call site with a 0.2% error rate and sub-second latency is safe to tune aggressively. One that's already struggling deserves more care.

The question all of this data answers is the one that matters: what does this code actually do in production? Most developers have never seen their code described this way with cost, usage, and behavior, pinned to a line number they recognize.

Not just AI

Everything above happens to be an AI example, but nothing about a call site is AI-specific. Anywhere your code touches a usage-billed service, the same page exists, with the details swapped out for what matters on that service.

Here's a storage call site: WriteOrderSummaryAsync, which writes an order summary to Google Cloud Storage.

For storage, the story starts with what Frugal reads out of the code itself: this call does PUTs (Class A operations, the expensive kind) against a specific bucket, resolved from the deployment config rather than guessed. It even recovers the object naming pattern, orders/?/?/order-?.json. One JSON object written per order, and you know that before looking at a single production number.

Then the money: $629 a month in request charges attributed to this call site. Per-item writes at order volume is a classic storage cost trap, and this call site has a Frugal Fix attached for exactly that: batch the writes instead of paying a Class A operation per order.

Databases get the same treatment. Here's a call site named main, in a component that hits PostgreSQL through the pg library.

Frugal recovers the statement itself from the code: a SELECT that joins orders to order items and aggregates revenue per product. Worth noticing what the code around it says: the query runs in a loop, and the comment right above it admits it "returns 10 rows, same numbers every call." Every codebase has one of these.

The cost side is where it gets interesting. Frugal matches the measured query load on each database instance back to this call site: 78% of one AlloyDB primary's load and 37% of a Cloud SQL primary's, $540 a month between them. Same code, two databases, one owner. And since the query returns the same ten rows every time, the attached Frugal Fix is the one you'd guess: cache it.

From reading code to measuring it

There are two levels to this. From your source code, bill, and existing observability data, Frugal finds your call sites, detects their configuration, and connects them to cost. Add Frugal's lightweight instrumentation and the picture sharpens: production behavior measured at each individual call site, including telling apart the call sites that converge on the same underlying client, and the richer per-call metrics you saw above.

Where does the location come from? At the moment your code makes a call, the instrumentation walks up the stack and takes the nearest frame that isn't Frugal's own code or the provider's SDK, then records exactly two things: the repo-relative file and the function name. That pair is the call site's identity. Line numbers are deliberately left out: they churn on every edit, and a call site whose identity changed every deploy would be useless for tracking cost over time. If your codebase routes every model call through a shared helper, one line of configuration tells Frugal to skip it, and attribution lands on the business code that called the helper, the level where intent lives. Batched calls get a similar courtesy: spend is attributed to the site that submitted the batch, not the site that later fetched the results, because the spend belongs to the code that decided to batch.

The highlighted line you see on the detail page comes from somewhere else entirely. No line number is ever transmitted from production. Instead, Frugal locates the call in your source as it exists today and links straight to it. The runtime tells you which function in which file is spending the money; the source tells you where exactly that is right now. Splitting those two jobs is why a call site survives ordinary edits without losing its history, and why the page can show you the current code even for a site whose telemetry is weeks old.

Find the code, understand the usage, measure the behavior precisely. Each step makes the next fix more obvious.

Where this goes

Call sites are becoming a load-bearing concept in Frugal. The Cost-to-Code Explorer walks you from a service down to the components responsible; call sites take the last step, down to the code. Frugal Fixes attach to the call sites they'd change. And Frugal's cost review catches expensive changes at the pull request. Call sites cover the other side: the code you already shipped, spending money in production right now.

The bill was never going to tell you which line of code to change. Now something does.

Here I am talking about it: https://www.youtube.com/shorts/ksfX637wiCQ

Looking for help with cost optimizations like these? Book a Demo or Explore the Sandbox to see Frugal in action.