Managing Self Driving Spend

PostHogOfficialPublished by PostHog

Skill
Workflow
Data and AI
MIT
No issues found

From the author

Explains and controls what Self-driving (Inbox) costs. Use when the user asks what they spent on Self-driving, which signal sources or scouts drive that spend, how spend changes day to day, how many reports a source or scout produced, or how to lower or cap the spend. Breaks spend down by signal source, scout, and day, links it to the reports it produced, recommends changes ranked by savings, and applies them only after the user confirms each one. Trigger terms: inbox spend, self-driving cost, scout cost, why is my bill high, reduce inbox spend, billing limit, daily report limit, turn off a source, pause a scout, scout pre-check.

— the description by PostHog

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a structured workflow for auditing and managing the costs of Self-driving (Inbox) features. It enables users to understand their spending patterns by breaking down credits used by signal sources, scouts, and daily activity. By linking costs to report production and resolution rates, the agent helps identify inefficiencies and recommends specific, user-confirmed actions to reduce or cap expenses without compromising critical data ingestion.

What it does

Calculates and explains monthly Self-driving spend in credits and USD.
Drills down into spend by specific signal sources, scouts, and daily usage.
Evaluates the yield and effectiveness of scouts and sources based on settled reports.
Identifies high-cost areas within sources that account for significant spend.
Recommends actionable controls like pausing scouts, setting limits, or adjusting source configurations.
Applies cost-saving changes only after explicit user confirmation.

When to use it

When you need to understand why your Self-driving or Inbox bill is higher than expected.
When you want to identify which specific scouts or signal sources are driving the most costs.
When you need to implement daily report limits or billing caps to control expenses.
When you want to optimize your configuration by pausing underperforming scouts or sources.
When you need to investigate daily spend spikes or evaluate the ROI of automated reporting.

Advantages

Provides granular visibility into cost drivers by source and scout.
Distinguishes between necessary operational costs and potential waste.
Ensures safety by requiring explicit user approval before applying any configuration changes.
Offers data-driven recommendations based on report resolution and yield metrics.
Helps balance cost-saving measures with the need to maintain data integrity.

Usage examples

“Why is my Inbox spend so high this month?”: The agent will analyze the current month's usage, break down the spend by source and scout, and highlight any specific areas contributing to the high bill.
“Can you help me reduce my scout costs?”: The agent will evaluate scout performance and yield, then suggest specific scouts to pause or optimize based on their contribution to spend and report resolution.
“How do I set a daily limit for my reports?”: The agent will explain how to set the daily report limit in the settings and describe the impact on signal processing and potential data loss.
“Which signal sources are costing the most?”: The agent will provide a breakdown of spend by source, identifying those responsible for more than 10% of the total signal spend and offering a deep dive into their components.

Install

Download the skill as a ZIP:
https://autogineer.com/agent-skills/posthog/managing-self-driving-spend/download

Unzip it into the cross-client skills folder of your project:

mkdir -p .agents/skills && unzip managing-self-driving-spend.zip -d .agents/skills

Documentation by PostHog

Managing Self-driving spend

Start with posthog:inbox-usage-get for monthly recorded usage, including processing, research, repository selection, scout execution, and automatic report implementation. Pass month: "YYYY-MM", or omit it for this month; history starts no earlier than October 2026, and a project's first receipt can be later. Show amounts as AI credits, with the USD value next to them: multiply decimal credits by the returned pricing.usd_per_credit. Recorded usage includes exempt work and is not an invoice; use posthog:billing-limits-get for the billing spend and limit. On a large project these tools can return more than fits in your context. If yours saves the output to a file, parse the file with a script, and keep the fields you need.

Workflow

Scope. Use the selected project and requested dates, defaulting to this UTC calendar month. Read posthog:inbox-usage-get and posthog:billing-limits-get. Use the returned canonical project_id for SQL reconciliation; child environments resolve to their parent and require access there.
Inventory. List sources with posthog:inbox-source-configs-list and scouts with posthog:scout-config-list. Explain historical spend even for disabled items; recommend controls only where they still apply.
By source and scout. Use the monthly tool's sources and scouts; their total_credits sum to the overall total. Sources include downstream research and implementation; scouts contain execution only, including runs with no reports.
Drill down. Use posthog:execute-sql with references/queries.md for custom dates, individual runs or reports, and finer source breakdowns. If the monthly tool is unavailable, use the SQL ledger subject to its access controls; report credits if no verified USD conversion is available.
By day. Run "First receipt" and "Spend by day" in references/queries-spend.md, and investigate spikes by source, scout, or kind.
Yield. Run "Baselines", "Yield by signal source", and "Yield by scout" in references/queries-yield.md. Yield is the share of settled reports that were resolved. Compare each item with its baseline on both settled rate and cost per resolved.
Inside each large source. Run "Breakdown inside a source" in references/queries-source-parts.md for every source that holds more than 10% of signal spend. This finds the specific scanners, signal types, evaluations, alerts, or channels behind the spend, which is where most recommendations come from.
Recommend. Go through every control in references/controls.md and decide whether it applies, using references/recommendations.md. Before you judge a scout, find out what kind of scout it is. A quiet run or an unresolved report is not always waste. Name the specific item to change, give a dollar figure, say what the user loses, and say whether you can apply it.
Apply. Change nothing without an explicit yes for that specific change. references/controls.md lists the tool for each control, or where to change it in the app when no tool exists. Read the setting back after you change it.

Present the result with references/report-template.md.

Rules

Sum each system.signal_spend record once. Signal metadata.total_spend, scout spend_credits, and report detail totals are copies or overlapping views, not additional charges.
Filter finalized usage by finalized_at with inclusive start and exclusive end in UTC. Work started earlier can finalize in this period.
Show exempt_credits as a subset, not an additional cost. Use receipt exemptions rather than excluding named sources or scouts; non-exempt usage is still not necessarily invoiced usage.
Report unsettled_credits, untracked_scout_run_count, and any row with incomplete true. Unsettled credits cover work created in the requested month, exclude finalized totals, and are not the outstanding balance across all months. Missing receipts mean unknown cost.
Explain the two summary flags by their cause. incomplete is true when any work is unsettled, any scout run is untracked, or any row is incomplete, so it is usually true while Self-driving is running. attribution_incomplete is true when any spend has no source, which is the null-source row.
Preserve unattributed costs, including implementation for deleted reports. Implementation is attributed to the report's current triggering signal, which can change.
Implementation usage covers automatic runs only. A fix that a person starts from a report is metered as PostHog AI, so it has no receipt here. Do not present implementation usage as the total cost of fixing reports, and do not estimate fix cost from pull request counts.
Use latest signal metadata only for attribution, with one embedding model and rendering. Do not filter metadata by signal arrival date when attributing period spend.
Reports need about 14 days to resolve, so measure yield on settled reports: reports first shown at least 14 days ago. Take them from the last 60 days, even when the spend period is shorter. When a source or scout has fewer than 20 settled reports, call its yield too new to judge, and recommend no cut that rests on it.
Do not treat a low resolved share as waste for a scout that measures, digests, or hands off work. references/recommendations.md says how to judge each kind.
Private scout trials are excluded from the SQL tables. Scout report counts can overlap; deduplicate IDs for project totals, and never add shared scout costs across report details.
A scout that rarely creates reports can still be useful if it edits existing ones. Check edited_report_ids before you recommend pausing it.
A scout with a pre-check can have few runs on purpose, because a skipped run leaves no run row. Read last_precheck_at and last_precheck_outcome before you call its runs missing.
Turn off a source only after you check its narrowing settings and source steering. references/controls.md lists which sources read steering.
Never turn off error tracking ingestion or lower its rate limits to save Self-driving spend. That drops exception data permanently. Change the Self-driving source instead.

Files

ATTRIBUTION.mdAdded by AutoGineer873 B
LICENSELicence file added by AutoGineer1.0 KiB
SKILL.md7.1 KiB
references/controls.md16.2 KiB
references/queries-controls.md4.0 KiB
references/queries-source-parts.md5.3 KiB
references/queries-spend.md5.0 KiB
references/queries-yield.md7.1 KiB
references/queries.md3.2 KiB
references/recommendations.md10.2 KiB
references/report-template.md2.5 KiB

references/controls.md

Spend controls

Read the current value before you change anything, and read it back after. Where no tool exists, give the user the setting name. Most settings are in the Inbox settings, in the Self-driving section. When no tool can read a setting, you do not know its current value. Say so instead of assuming the default.

How spend builds up

Knowing where money is spent tells you which control can reduce it.

Signals. Each signal a source sends costs a little to process and group. When signals form a report, researching that report costs more, and that cost lands on its signals. So a source that sends many signals costs money even when few of them become reports, and a source whose reports get researched costs more per report.
Scout runs. Each scheduled run costs money whether it finds something or not. Scout spend grows with the number of runs, so a scout's schedule matters more than what it finds. A pre-check can skip a scheduled run before it costs anything.
Automatic pull requests. An implementation run for an actionable report costs money. Its finalized usage appears in the monthly tool's implementation_credits and in system.signal_spend. A fix that a person starts from a report is metered as PostHog AI, so it is not in these numbers.

There are two kinds of control:

Volume controls cut how much work happens: turning a source or scout off, running a scout less often, skipping its empty runs with a pre-check, narrowing a source to some of its parts, and the limits. Their savings can be estimated from past spend, except for source steering, which you must measure after two weeks. For a pre-check, past spend gives only an upper limit.
Focus controls change what the agents spend effort on: project steering instructions. Their savings cannot be estimated in advance. Check them again after two weeks.

Limits

Control	How it works	How to change it	What the user loses
Spend limit	A monthly cap on Self-driving spend, on the `inbox` row. When spend reaches it, new signals are dropped, scheduled scout runs are skipped, and research pauses until the next billing period. It caps the bill but does not make spend more useful.	Read with `posthog:billing-limits-get`. Set it on the billing page. No tool.	Signals that arrive after the limit are lost for good. They do not come back next period.
Daily report limit	Caps how many new reports become visible each day, in the project timezone. When the cap is reached, new signals are dropped, scheduled scout runs are skipped, and research pauses until midnight. It only saves money on days with spikes.	"Daily report limit" setting. No tool.	Signals that arrive after the cap are lost for good. They are not held for the next day.

Both limits drop signals rather than queue them. When you recommend one, say that issues found after it is reached never reach the inbox.

Sources

Control	How it works	How to change it	What the user loses
Turn off a source	Stops new signals from that source. Reports that already exist stay in the inbox. Each signal type has its own config to turn off.	`posthog:inbox-source-configs-partial-update` with `enabled: false`	Everything that source would find
Source steering	Plain-language rules on what to skip in one source. A model checks each record against them and drops matches before they become signals. It applies to new records only.	`posthog:inbox-source-configs-partial-update` with `config_set.steering`, up to 2,000 characters. Read the current text with `posthog:inbox-source-configs-retrieve`	Records the rules exclude. A broad rule can hide real issues

Prefer config_set and config_remove to config on every source update, because config replaces the whole object.

These sources read steering: error tracking, health checks, product analytics alerts, support tickets, and most data warehouse imports, such as GitHub, Linear, Zendesk, and pganalyze. Other sources store the text but do not read it, including Replay Vision, LLM analytics, and Search Console. When the check is unavailable, it keeps the record. New rules do not remove signals that already exist.

Before you turn off a whole source, check whether one of its parts drives the spend. These controls narrow a source without turning it off:

Source	Control	How it works	How to change it	What the user loses
Error tracking	Signal types	New issues, reopened issues, and spiking issues are three separate signal types, each with its own config.	`posthog:inbox-source-configs-partial-update` on the `issue_created`, `issue_reopened`, or `issue_spiking` config	Turning off new issues means an issue reaches the inbox only when it spikes or reopens
Session replay (Replay Vision)	Scanners	Each scanner watches recordings for one thing. `emits_signals` sends one signal per matching recording to the inbox. `sampling_rate` sets the share of recordings it scans. `enabled` stops the scanner completely.	`posthog:vision-scanners-update`. Turn off `emits_signals` to keep the scanner's observations in Replay Vision without sending them to the inbox.	Findings from the scanners you turn down
LLM analytics	Evaluation reports	Each evaluation report runs on a schedule and can send a signal when it finds a problem.	`posthog:llma-evaluation-report-update` with `enabled`, `frequency`, or `daily_run_cap`	Also changes that report's email and Slack delivery
Product analytics	Anomaly alert investigation	When an alert fires, an agent can investigate it and send the result to the inbox.	Per alert: `alert-update` with `investigation_agent_enabled: false`, or `investigation_inconclusive_action: "suppress"` to hold back unclear results. For all alerts, turn off the `anomaly_investigation` source.	Fewer anomaly reports
Product analytics	Alert scope	`alert_scope` selects which firing alerts become signals: `investigated_only` (default), `all_firing_alerts`, or `off`. `alert_allow_patterns` and `alert_block_patterns` filter by alert or insight name.	`posthog:inbox-source-configs-partial-update` on the `anomaly_investigation` config with `config_set`	Alerts the scope or patterns exclude. Alert checks and notifications still run
Linear	Teams	Only issues from the chosen Linear teams become signals.	`posthog:inbox-source-configs-partial-update` with `config_set.linear_team_ids`	Issues from other teams

The alert_firing signal type has no config row of its own. The anomaly_investigation row controls it: its enabled flag, alert_scope, and patterns all apply. The signals_check source comes from report monitoring and has no config row.

Other sources, such as support tickets and pganalyze, have no setting that selects a fixed part of the source, so use source steering to describe the records to skip. Search Console has neither, so the choice is to keep it or turn it off.

Scouts

Control	How it works	How to change it	What the user loses
Pause a scout	Stops its scheduled runs. Its past reports stay.	`posthog:scout-config-update` with `enabled: false`	Everything that scout would find
Run a scout less often	Spend falls in proportion to runs. Going from hourly to every 6 hours cuts that scout's spend by about five sixths.	`posthog:scout-config-update` with a larger `run_interval_minutes`, or a cron schedule	Findings arrive later
Add a pre-check	A HogQL query runs before each scheduled run. When it finds nothing new, the run does not start, so there is no sandbox or model call.	Test with `posthog:scout-config-precheck-test`, then save with `posthog:scout-config-update` and `precheck_query`	A query that is too strict hides real activity from the scout

When run_cron_schedule is set, it decides when the scout runs, not run_interval_minutes. Read the schedule from the one that applies, and change that one.

Pre-checks

A pre-check suits a scout that watches data a query can read, such as new events or tickets. Findings do not arrive later, because the next run that starts still sees everything since the last run that started. It suits a scout poorly when a query cannot tell whether a run would matter, such as a sweep through a codebase.

precheck_query_source in posthog:scout-config-list shows the current state: config, skill_default, or off. Only off means no pre-check runs.
A pre-check gates scheduled runs only. Manual and workflow runs always start.
A query that fails starts the run, so a broken pre-check saves nothing.
The dry run reads as you, and a scheduled check reads as the scout's acting user. A query that passes the dry run can still fail on schedule, so read last_precheck_outcome after the next scheduled tick. It holds only the latest result.
Add a backstop when the scout should still run from time to time.

The authoring-scouts skill has the query rules and placeholders in references/scheduled-precheck.md. Read it before you write a query.

Project steering instructions

Project steering instructions tell the agents what to focus on and what to skip. There are three, and each applies to the whole project:

scout_instructions: added to every scout run.
research_instructions: used when a report is researched.
implementation_instructions: used when a pull request is written.

They change focus, not volume. Signals still arrive and are processed, so do not promise a dollar saving. To stop records from one source before they become signals, use source steering instead. Where a source does not read steering, name it in the research instructions, for example "Skip scanner findings about the settings page."

Read the current text with posthog:inbox-steering-instructions-get, then send the full new text with posthog:inbox-steering-instructions-update.

Automatic pull requests

Control	How it works	How to change it	What the user loses
PR generation	Whether actionable reports open a pull request automatically	"PR generation" setting. No tool.	Fewer fixes arrive ready to review
Priority threshold	The lowest report priority that opens a pull request automatically (P0 is highest). Users can set their own.	"Priority threshold" setting, for the project or under "Your overrides". No tool.	Lower-priority fixes need a manual start

Use implementation receipts for historical cost. Estimate future savings only for the reports the proposed control would exclude, separating exempt credits and acknowledging that future implementation costs vary. To judge them, compare pull requests linked and merged with "Pull requests linked and merged" in queries-controls.md.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by

PostHog

Publisher

PostHog (Official)

Source

PostHog/skills · skills/omnibus/managing-self-driving-spend · commit a5d30e7

Licence

MIT License (redistribution allowed)

LICENSE (added by AutoGineer from LICENSE)
ATTRIBUTION.md (written by AutoGineer)

Synced

2026-11-09

AutoGineer is not affiliated with or endorsed by PostHog or PostHog.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download managing-self-driving-spend.zip