Controls

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

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

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:

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

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

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.