AI spend that jumps overnight

An LLM bill moves for one of two reasons: more conversations, or more cost per conversation. The first is growth. The second is a regression – a prompt grew, a model changed, a cache stopped hitting, a retry looped. This scout watches your LLM traces for the second kind.

What the scout looks at

The scout looks for patterns like Fig. 1: you deployed a new version of your feature at 09:14. Your conversation costs is rising, but volume is stable. This is a signal that LLM costs are rising. If both were rising, this is just growth.

09:14 deploy

Conversations

flat at ~1,200/day

Cost per conversation

$0.09 → $0.28

Fig. 1What the scout saw: Your newest deploy went out at 09:14. Volume held, but cost per conversation didn't.

The report in your inbox

When your product emits signals that indicate AI costs are rising, a scout opens a report. Fig. 2 breaks the card down part by part. Click Review and the report opens Fig. 3 with the full evidence, the raw signals, and options to take action. Yours would look like this one, but name your events, your deploys, and your users.

P1Cost per conversation up 3.1x while volume is flat Generations per conversation went 1.2 → 3.6 after the 09:14 deploy while tokens and models held steadyScout · AI costReadyActionable4h ago
ArchiveReview
Fig. 2Once surfaced, your inbox surfaces this report card. The card includes its claim and triage, with the evidence sitting inside the report itself.Hover over the figure to learn about each element.
P1Cost per conversation up 3.1x while volume is flat ReadyActionableScout · AI cost· 4h ago
ArchiveCreate PR
Summary

Since yesterday's 09:14 deploy, conversations are flat at roughly 1,200/day but cost per conversation rose from $0.09 to $0.28. Generations per conversation went from 1.2 to 3.6 while input tokens and model distribution held steady. The extra generations carry non-zero cost and a max_tokens stop reason rather than a 429, so the provider billed for every retry – this is a retry loop, not a bigger prompt or a cache miss.

~$230/day above the 14-day norm

Suggested fix: Cap the retry count on the generation path and surface the underlying failure instead of retrying silently.

Evidence2 sources
AI ObservabilityCost, tokens, model, cache reads, and error flags on every generation – enough to spot the change and attribute it.
Your codebaseDeploys, so a cost change can be tied to the commit that caused it rather than just a timestamp.
Fig. 3The report opened. From here, you can review the evidence and open a pull request.Hover over the figure to learn about each element.

The pull request you merge

When you're ready to open a pull request, the agent does it for you, attaching the evidence along the way. You review and merge it like any other – nothing merges without you.

Reports are free. Pull requests are $15 each, with your first three a month free. See self-driving Pricing.

The scout itself

Scouts are the heart of the self-driving system – they're instructions an agent follows on a schedule – Fig. 4 is the actual file for this guide's custom scout.

signals-scout-ai-cost/SKILL.md
---
name: signals-scout-ai-cost
description: >
Watches cost per conversation for AI features and reports when it breaks from its recent norm
while volume holds steady, attributing the change to a model, prompt, cache, or retry cause.
allowed_tools:
- emit_report
- edit_report
---
# AI spend that jumps overnight
Watch unit economics for AI features, not the total bill.
Narrower than `signals-scout-ai-observability`, which rotates through cost, latency, errors,
volume and eval lenses and deliberately does not run every lens each tick. Run this one when
cost is the thing you want watched every day rather than whenever the rotation reaches it. If
you already run the canonical scout and cost regressions are surfacing in time, you don't need
both.
## Discriminator
Emit a report when cost per conversation rises above its trailing 14-day norm **while
conversation volume stays within its own normal range**. Write nothing when total cost rose but
cost per conversation is flat – that is usage growth.
### The bar
A starting threshold, to be tuned against what this team's data actually does:
- **≥1.5× the trailing 14-day median cost per conversation, sustained across two consecutive
complete days**, or
- **≥2× for a single complete day**, where volume is within ±25% of its own 14-day median.
Use complete days only – a partial day reads as a spike every time. If the team's baseline is
genuinely noisy, widen the bar and write what you chose to the scratchpad rather than lowering
it and filing marginal reports.
## Explore
1. Compute daily cost per conversation over the last 14 days: total generation cost divided by
distinct conversations – `$ai_trace_id`, or `$ai_session_id` where a conversation spans
traces – split per feature.
2. Where a day clears the bar, decompose it. Check in this order, roughly the order of
likelihood:
- **Model changed** – compare the model distribution before and after.
- **Cache hit rate dropped** – compare `$ai_cache_read_input_tokens` as a share of input
tokens. A system-prompt edit invalidates the cache prefix and multiplies input cost with no
change to model, token count, or generation count, so every other check here comes back
clean while the bill climbs. Check it early.
- **Prompt grew** – compare median input tokens per generation.
- **Retries** – compare generations per conversation, and check `$ai_is_error` on the same
generation stream.
- **Output grew** – compare median output tokens.
3. If retries look like the cause, confirm the failures actually cost money. A 429 rejection
bills nothing; only failures after the provider started generating do – timeouts mid-stream,
`max_tokens` truncation, malformed tool output, guardrail rejections. Check `$ai_http_status`
and `$ai_stop_reason`, and confirm the failed generations carry non-zero cost before calling
retries the cause.
4. Name the most likely cause in the report. A cost report without a cause is just an invoice.
5. Where a deploy sits in the window, include the commit range.
## Disqualifiers
- Conversation volume moved as much as cost did – that's growth.
- The change is a deliberate, announced model upgrade.
- The change follows a deliberate caching-strategy change – a shortened prefix or a switched
cache TTL raises unit cost on purpose.
- The provider changed its prices. This scout does not watch price lists, so confirm the
per-token rate is unchanged before attributing a rise to your own code.
- The window covers a backfill, replay, or eval run rather than real traffic.
- The feature is new enough that there's no stable norm to compare against.
Fig. 4The scout itself – the file an agent follows on a schedule.

It reads more than one signal source, so the report can name a likely cause, not just a number that moved.

  • AI Observability

    Cost, tokens, model, cache reads, and error flags on every generation – enough to spot the change and attribute it.

  • Your codebase

    Deploys, so a cost change can be tied to the commit that caused it rather than just a timestamp.

The schedule it runs on

This custom scout runs daily by default. You can choose to run it every 30 minutes up to once a day. It only writes when something is wrong, so most days it's silent.

Add this to your scout troop

This is how the scout appears in PostHog once it's running – a scheduled agent that files a report when it finds something.

Preview

  • RequiredAI Observability instrumented, so $ai_generation events are arriving
  • RequiredA property on generations identifying the feature, so you can split cost per surface
  • RecommendedYour codebase connected via GitHub, to correlate a change against deploys
Add this scoutOpens PostHog with it prefilled. Review it, then hit Create.

Not set up yet? One command installs PostHog, connects GitHub, and turns on a default troop of scouts. That troop doesn't include this one – add it above once you're set up.

npx @posthog/wizard self-driving
signals-scout-ai-costAdd this scout