The Cost as Code blog https://costascode.com/blog/ Weekly posts on Savings as Code, Spend as Code and right-modeling: practical ways to cut and control cloud and AI spend. en Sat, 07 Nov 2026 08:00:00 +0000 Implement AWS cost recommendations as pull requests https://costascode.com/blog/why-every-cloud-saving-should-be-a-pull-request https://costascode.com/blog/why-every-cloud-saving-should-be-a-pull-request Sat, 07 Nov 2026 08:00:00 +0000 AWS cost recommendations stall between the finding and the change. Turning each saving into a pull request you approve, then measuring it, fixes that. Every AWS account has a list of savings nobody has made: oversized instances, unattached volumes, compute that would be cheaper on a Savings Plan. The list is accurate. The bill has not moved.

The problem is rarely finding the savings. It is the step after: changing production safely, deciding who approves it, and proving later that the saving was real.

Where recommendations stall

  1. A report says a service could run on a smaller instance family and save about $1,100 a month.
  2. Someone agrees it looks right.
  3. Nobody owns the change: the service team is busy, the platform team won't resize someone else's service.
  4. Three months later, the same line is in the next report.

The recommendation arrived as a finding, not as a change.

Make the saving a pull request

A pull request already answers every question that stalled the saving:

  • Who changes it? The pull request is the change; the team only reviews it.
  • Is it safe? The diff shows what moves, CI runs, and the rollback is one revert.
  • Who approves? The same people who approve every other change to that service.
  • Did it work? The pull request is the unit you measure on the bill.

This is Savings as Code: one saving, one pull request, approved by your team, measured after the merge.

A savings pull request description, in five lines 
What changes   orders service: m5.2xlarge to m7g.xlarge (3 instances)
Why            p95 CPU 18% and memory 31% over the last 30 days
Estimate       about $1,100 a month
Risk           ARM build needed; image already multi-arch; load test attached
Rollback       revert this pull request; previous instance type restored on deploy

Measure it on the bill

The estimate gets the change approved. The bill decides what it was worth. About 30 days after the merge, record the result next to the pull request:

Pull request Estimate a month Measured a month
orders: smaller Graviton family $1,100 $1,040
Delete unattached volumes $480 $510
Lifecycle rule for old logs $350 $330

Illustrative example.

Start this week

  1. Export the current recommendations for one account, for example from AWS Compute Optimizer.
  2. Pick the five with the largest estimate and the lowest risk.
  3. Write each as a pull request with the five lines above.
  4. Ask the owning team to review them like any change.
  5. Set a reminder 30 days after each merge to record the measured saving.

No infrastructure as code? Use a small change-log repo: same review, same measurement.

If you want the list found and the pull requests written for you, that is what we do: a free review of your AWS bill, then we implement the savings and you approve every change.

]]> Five LLM cost levers to check before you switch providers https://costascode.com/blog/five-llm-cost-levers https://costascode.com/blog/five-llm-cost-levers Sat, 07 Nov 2026 08:00:00 +0000 Before moving to a cheaper AI provider, check five levers that reduce LLM costs where you are: model routing, caching, batch, output limits and context. When an AI bill grows, the first idea is often to switch providers. A migration costs weeks and new quality risks, and most of the waste stays behind: it comes from how models are used, not whose models they are. These five levers reduce LLM costs with the provider you already have. Prices below are from the providers' own pages, checked November 7, 2026.

1. Route each task to the right model

A ticket classifier and a contract review do not need the same model. Per input token, the most expensive model on Anthropic's price list costs 100 times the cheapest, and OpenAI's list has the same gap (Anthropic, OpenAI). Test cheaper models against real examples per task and keep the cheapest that passes: right-modeling.

Measure: cost per request on each route.

2. Cache the parts of the prompt that repeat

System prompts, tool definitions and shared documents are sent on every call. A cached prompt read costs 10% of the normal input price on most Claude models (Anthropic). Put the stable parts first and the variable parts last.

Measure: the share of input tokens billed as cached.

3. Move work that can wait to batch

Overnight reports, bulk tagging and evaluation runs can wait hours. Batch requests cost half the standard price on Anthropic, OpenAI and the Gemini API (OpenAI, Google), and Amazon Bedrock offers 50% off on-demand for selected models (AWS).

Measure: the share of tokens processed in batch.

4. Limit and shape the output

Output tokens cost five times input tokens on the flagship models of Anthropic, OpenAI and Google (pricing pages above). If the interface shows two sentences, ask for two sentences, and cap the output per route.

Measure: average output tokens per request.

5. Send less context

Send the passages that matter, summarize long histories, and check whether quality changes when you halve the retrieved chunks.

Measure: average input tokens per request.

Make each lever a change you can review

Each lever is one small change with an estimate before and a measurement after: the same way we handle cloud savings in Savings as Code. Then write the chosen model and limits down where they are checked, so the next feature does not undo them: Spend as Code, coming soon.

If the bill is still too high after that, compare providers. You will be comparing the real workload, not the waste.

]]>