---
title: The Missing Context That Makes Coding Agents Much More Effective at Cutting Cloud Spend
description: Cost Graphs Are The Missing Context That Makes Coding Agents Much More Effective at Cutting Cloud Spend
image: https://frugal.co/hubfs/Blog%20Banner%202%20%286%29.png
---

[![company-logo](https://cdn.prod.website-files.com/686b121c919ed2b639e30952/686b28b7662f765388c4c0f2_Layer_1.svg)](https://frugal.co/)

[Product](https://frugal.co/) [About Us](https://frugal.co/about) [blog](https://frugal.co/blog) [Contact](https://frugal.co/contact)

[contact us](https://frugal.co/contact)

Explore Sandbox

Book Demo

The Missing Context That Makes Coding Agents Much More Effective at Cutting Cloud Spend

![Mike Weider](https://frugal.co/hs-fs/hubfs/687a9de2429ae6d0f60fa46d_headshot2024.jpg?width=60&height=60&name=687a9de2429ae6d0f60fa46d_headshot2024.jpg)

Mike Weider

 October 7, 2026

“Find ways to cut our cloud bill” sounds like a good job for a coding agent.

The agent can read the repository, inspect a query, and write a fix. But it cannot tell from code alone whether that query runs ten times a day or ten million. Nor can it tell whether the bill is driven by requests, storage, compute time, or something else entirely.

Agents need context to be effective. That is why a FinOps agent needs a Cost Graph.

## **What is a Cost Graph?**

A Cost Graph is a reusable map that connects cloud costs to the code and usage that drive them. It distills billing data, production usage, observability signals, and source code into relationships that engineers and agents can query to understand what costs money, why, and where to make changes.

![](https://frugal.co/hs-fs/hubfs/undefined.png?width=1280&height=610&name=undefined.png)

If you’re looking to find waste or optimize spend, the Cost Graph provides much needed context to Agents so they answer questions like “What’s my highest spending component?” It also lets you work backwards, starting with a growing charge and finding the component and code path behind it.

Agents are not good at reasoning with large volumes of raw data. Instead of connecting to the Cloud provider MCP or Observability MCP to get raw data, the Agent talks to an MCP which leverages the pre-generated Cost Graph to deliver much better answers in a fraction of the time or tokens.

![](https://frugal.co/hs-fs/hubfs/undefined-3.png?width=1600&height=366&name=undefined-3.png)

There are three main uses for a Cost Graph: attribution, optimization and prevention. Attribution breaks costs down to the code level. It can also be used by Agents to perform focused optimization work. Lastly, the same data can be used to power Cost prevention agents to give engineers cost advice as they write new code.

![](https://frugal.co/hs-fs/hubfs/undefined-Oct-07-2026-07-19-47-9260-PM.png?width=1470&height=623&name=undefined-Oct-07-2026-07-19-47-9260-PM.png)

## **Who uses a Cost Graph?**

FinOps and engineering teams use the same Cost Graph to answer different questions.

**For FinOps, it connects spend to engineering ownership and action.** Teams can trace a growing charge to the components and call sites behind it, prioritize opportunities by cost impact, and work with the engineers responsible. As changes reach production, they can track the associated usage and spend to assess the result.

**For engineers, it brings cost context into software decisions.** Engineers and their coding agents can investigate expensive call sites, understand the usage driving them, and identify changes worth making. During development, they can query the graph for context about existing code and services to inform recommendations before adding more spend.

![](https://frugal.co/hs-fs/hubfs/undefined-1.png?width=1400&height=1000&name=undefined-1.png)

The shared graph gives both teams a common starting point: FinOps can explain where the money goes, and engineers can investigate what to change.

## **How is a Cost Graph Different From Traditional FinOps Data Warehouses?**

Many FinOps teams have already built a cost data warehouse, bringing billing, allocation, and usage data together to understand spend. That is a valuable foundation.

A Cost Graph takes this a step deeper by connecting spend to the software that drives it: components, call sites, cloud services, and production usage.

## **![](https://frugal.co/hs-fs/hubfs/undefined-Oct-07-2026-07-19-46-8124-PM.png?width=701&height=221&name=undefined-Oct-07-2026-07-19-46-8124-PM.png)**

In summary, the graph is cost intelligence the agent can act on. It is not simply another dashboard or a larger pile of data.

## **How Frugal uses Cost Graphs for optimization**

Frugal uses the Cost Graph in two complementary ways: finding known cost traps and helping coding agents reason about expensive software decisions.

 

|  | **Optimization Method** | **How the Cost Graph helps** |
| --- | --- | --- |
| **Known Cost Issues** | Reviews code that drives spend for more than 200 predefined types of cost issues. | Provides usage and cost context to determine whether an inefficiency matters and estimate whether the savings justify fixing it. |
| **Unknown Cost Issues** | Identifies high-spending components and call sites, then uses a coding agent to investigate alternatives. | Gives the agent context to reason about implementation changes, estimate potential savings, and propose how to validate the result. |

 

For known issues such as high cardinality metrics or over-provisioned Lambdas, the graph provides the usage and cost context to determine whether a potential inefficiency is a meaningful problem. An unnecessary API call that runs occasionally may barely affect the bill. The same call running millions of times could be worth fixing. Frugal uses that context to estimate the savings from a proposed fix, helping engineers decide whether the opportunity justifies the work.

 

For unknown cost issues where the code works as designed but is simply expensive, the agent can reason about potential changes to the implementation, estimate their savings potential, and propose how to validate them. For example, maybe AI code could be replaced with deterministic code with no loss in functionality. See more examples [here](https://frugal.co/blog/cutting-cloud-costs-when-nothing-is-broken).

 

Both approaches use the Cost Graph to connect a possible software change to its economic value. Engineers can then review the tradeoffs, implement the change, and measure the result.

 

## **Attribution tells you where to look. A Cost Graph helps engineers and agents decide what to change.**

Attribution might show that a specific component is costing $100,000 a month. That points an engineer to the expensive component, but leaves the next question open: *which code should we change?*

A Cost Graph connects that spend to the call sites and usage behind it. It can show that a specific call site accounts for the largest share of this cost, alongside its request volume, token usage, and caching state. The agent can investigate a specific change, then check its effect as new usage data arrives. Because the graph stores these relationships, the agent can reuse them for the next investigation.

![](https://frugal.co/hs-fs/hubfs/undefined-4.png?width=1698&height=926&name=undefined-4.png)

In[our CTO’s walkthrough example](https://www.youtube.com/watch?v=IrRaJiZQM1I), the engineer asks their coding agent to come up with cost reductions to their AI spend. Through the MCP server, the agent finds the highest spending component. Then it identifies the call sites within the component and the numbers behind them, including call volume, tokens, and caching behavior:

- **recommendations/generate.py:84** — $12,400 in the last 30 days; 1.6 million calls; 1,950 input and 140 output tokens per call; 91% prompt cache hit rate.
- **recommendations/explain.py:31** — $1,100 in the last 30 days; 48,000 calls; 4,200 input and 310 output tokens per call; 8% prompt cache hit rate.

The first call site is the priority. Its caching is working, but it runs so often that it dominates the bill. The agent can investigate whether the request needs a model change, whether identical answers can be reused, or whether deterministic code can handle some cases. Improving the second call site’s cache rate may be easier, but it cannot deliver the same impact.

The Cost Graph provides the economic context. The MCP server delivers the relevant part of it to the agent at the moment it is working on the code.

## **Building a Cost Graph**

Building a Cost Graph takes more than handing an agent a bill and a repository. It requires correlating billing data, production usage, observability signals, and source code into a reusable model.

Each service type requires unique signals and processing to map the relationship between cost and code. This requires identifying the key inputs for mapping AI, Storage, Kubernetes, Databases, Lambdas, etc. to build the Cost Graph. For example, for RDS we need:

![](https://frugal.co/hs-fs/hubfs/undefined-Oct-07-2026-07-19-47-0148-PM.png?width=2021&height=778&name=undefined-Oct-07-2026-07-19-47-0148-PM.png)

Collecting the data is the starting point. Frugal maps billed costs to database instances, identifies the components that access each database, and matches SQL statements observed in production to their call sites in the code. Queries are normalized so differences in parameter values or formatting do not prevent a match. Measured database load then provides a basis for allocating compute costs to the components and queries driving that load.

AI helps investigate which code uses which database. Query matching and cost calculations are deterministic. When a direct match is unavailable, Frugal uses other evidence, such as table mappings or access patterns, and records the allocation method. Costs that cannot be mapped remain explicitly unattributed, so the totals still reconcile to the bill.

Creating a Cost Graph for a large codebase can be resource intensive but the payoff is clear. For example, in one recent client scan, Frugal ran 983 agentic calls, 1524 deterministic tasks, 25,368 tool calls, using over a hundred million tokens. The total cost was over $100 but helped to identify optimizations totalling over $600,000 in annual savings. Moreover, each subsequent query of the Cost Graph by an agent uses far fewer tokens to get answers because the data is distilled into ready to use context without repeating complex analysis with each and every prompt.

## **Using the Cost Graph Before and After Deployment**

The same Cost Graph used for cost reduction can also be utilized for cost prevention. Engineers can use the MCP in their Coding Agent during implementation to make cost efficient plans and code. They can also leverage it for PR Review. In PR review, we use the Cost Graph to help estimate the cost of code changes and recommend optimization before the code is merged. [More details here](https://frugal.co/blog/frugal-adds-code-review-for-cost).

 

![](https://frugal.co/hs-fs/hubfs/undefined-2.png?width=709&height=333&name=undefined-2.png)

## **Why Cost Graphs are critical for Agentic FinOps**

Coding agents are good at generating many possible optimizations. The hard part is deciding which one is worth the trade.

A cache can reduce API calls, but it makes answers potentially stale. Batching can reduce request charges, but it adds delay. Moving data to cheaper storage can lower one charge while raising retrieval costs. As we argued in[Why Not Just Optimize Everything?](https://frugal.co/blog/why-not-just-optimize-everything), the right choice depends on actual usage and on the part of the bill you are trying to change.

Without a Cost Graph, your coding agent lacks critical context to perform optimizations, guessing about what’s important and what’s not. Even worse, the agent could be making changes that have negative ROI.

![](https://frugal.co/hs-fs/hubfs/undefined-Oct-07-2026-07-19-45-8931-PM.png?width=1913&height=655&name=undefined-Oct-07-2026-07-19-45-8931-PM.png)

A Cost Graph helps an agent answer three questions before it writes code:

1. Where is the money going? Rank the services and call sites by observed cost, rather than by how expensive they look in source code.
2. What is driving it? Separate request volume from bytes, duration, tokens, or other billing dimensions so the proposed fix addresses the real cause.
3. Is the change worth making? Put estimated savings beside the latency, reliability, freshness, and engineering work the change requires.

The third answer may be “leave it alone.” That is valuable. Engineering time spent optimizing a low-cost path is time lost for a change that would move the bill.

In our small experiment described in[Why Curated Context Beats Raw Data for Coding Agents](https://frugal.co/blog/why-curated-context-beats-raw-data-for-coding-agents), Claude Code produced stronger answers at lower agent cost with Frugal’s prepared Cost Graph than with direct access to general-purpose data tools. The practical lesson is: an agent does better FinOps work when it receives the cost relationship it needs, rather than having to discover it from scratch during every task.

## **Don’t reconstruct the agent’s context every time**

You can connect a coding agent to Cost Explorer, logs, metrics, and a repository. It may eventually piece together the answer. It may also spend much of its effort searching across those systems and reconciling data that was never organized around an engineering decision.

A Cost Graph does that preparation ahead of time. The agent gets the relevant cost path and supporting evidence, then uses its reasoning to evaluate a change.

## **Recursive Cost Improvement**

Some cost problems are obvious mistakes: a retry loop, duplicate requests, or a function doing unnecessary work. Others are software working exactly as designed at a price the team did not expect.

In our[illustrative application exercise](https://frugal.co/blog/cutting-cloud-costs-when-nothing-is-broken), the AI call that looked most expensive in code represented only 1.1% of the example bill. Three other call sites represented about 90%. Production cost and usage context changed both the priority and the proposed fixes.

That is where a Cost Graph becomes especially useful. It can point an agent beyond recognizable bugs to expensive design choices: a model called for every transaction, a query whose cost grows with every customer, or an API response generated repeatedly when it could safely be reused.

The agent can then propose a change, an engineer can review the trade, and the team can measure what happened after release. Fresh production data updates the graph, giving the next round of work a better starting point.

That is the loop we want: find the cost driver, change the software, measure the result, and repeat.

![](https://frugal.co/hs-fs/hubfs/undefined-Oct-07-2026-07-19-44-8804-PM.png?width=1672&height=941&name=undefined-Oct-07-2026-07-19-44-8804-PM.png)

FinOps teams do not need agents that optimize everything. They need agents that know what costs money, why it costs money, and whether a change is worth making. The Cost Graph gives them that context, and Frugal’s MCP server puts it to work in their coding agent.

## **Ready to build a Cost Graph for your codebase?**

Interested in generating a Cost Graph for your codebase? [Reach out](https://calendly.com/d/cvd9-msy-z7f/cloud-waste-audit-with-frugal-30-mins) and we will walk you through what’s involved in building one for your application.

 Share Link

[Back to Top](https://frugal.co/blog/ai-or-engineer-cloud-cost-savings-start-with-the-bill-and-end-in-the-code)

![background Image](https://frugal.co/hubfs/697fa79222025cf13e7bec1e_799f61dfa4790fe0e40a2962d5468335_Group%202040.avif)

![Robo Image](https://frugal.co/hubfs/697fadb140def08f5fc80ed3_Group%202042.avif)

### Take Frugal for a live test drive

 Explore how Frugal scans your code and cloud services to find waste, recommend optimizations, and generate ready-to-use fixes in a secure, read-only environment.

[Enter Sandbox](https://auth.frugal.co/sign-up)

![background Image](https://frugal.co/hubfs/697fa936779f0fd839545616_Group%202041.avif)

![robo image](https://frugal.co/hubfs/697fa79222025cf13e7bec1e_799f61dfa4790fe0e40a2962d5468335_Group%202040.avif)

![frugal image](https://cdn.prod.website-files.com/686b121c919ed2b639e30952/686c44713462acbdaab4a82d_f8418228347e59c4cabb651eb7f5e72b_Frame%20291022.avif)

 An Intelligent Application Cost Engineering platform that optimizes code to reduce cloud costs automatically - empowering engineers without slowing development

[Blog](https://frugal.co/blog) [Contact](https://frugal.co/contact) [careers](https://frugal.co/careers) [About Us](https://frugal.co/about)

[Privacy Policy](https://frugal.co/privacy-policy) [Terms of Use](https://frugal.co/terms-and-condition) [Trust Centre](https://trust.frugal.co/) [Active Status](https://status.frugal.co/)

[X](https://x.com/frugalaico) [LinkedIn](https://www.linkedin.com/company/frugalco/)

[Featured in AI Directory](https://aidirectory.wiki)

[Privacy Policy](https://frugal.co/privacy-policy) [Terms of Use](https://frugal.co/terms-and-condition) [Trust Centre](http://trust.frugal.co/) [Active Status](http://status.frugal.co/)

Copyright Frugal AI Inc.

©2025

```json
{
  "@context" : "https://schema.org",
  "@type" : "BlogPosting",
  "author" : {
    "@type" : "Person",
    "name" : "Mike Weider",
    "url" : "https://frugal.co/blog/author/mike-weider"
  },
  "dateModified" : "2026-10-07T19:29:25.512Z",
  "datePublished" : "2026-10-07T19:29:25.000Z",
  "headline" : "The Missing Context That Makes Coding Agents Much More Effective at Cutting Cloud Spend",
  "image" : [ "https://frugal.co/hubfs/Blog%20Banner%202%20%286%29.png" ],
  "mainEntityOfPage" : {
    "@id" : "https://frugal.co/blog/the-missing-context-that-makes-coding-agents-much-more-effective-at-cutting-cloud-spend",
    "@type" : "WebPage"
  },
  "publisher" : {
    "@type" : "Organization",
    "logo" : {
      "@type" : "ImageObject",
      "url" : "https://frugal.co/hubfs/Frugal%20Logo%20Transparent%20Black.png"
    }
  }
}
```