Proof
A pull request Loopcost opened
run on 19 July 2026
Every warehouse cost tool ends at a dashboard. This is where Loopcost ends — a draft PR against a dbt repo, opened by the tool itself, off a real report from a real Snowflake account. Open it and read the diff yourself.
models/big_unclustered.sql
- {{ config(materialized='table') }}
+ {{ config(materialized='table', cluster_by=['l_shipdate']) }}One line. The entire question is whether l_shipdate is the right column — which is what the rest of this page is about.
What this is, honestly
- ✓Real Snowflake account, live
ACCOUNT_USAGEdata, a real PR on a public repo. - !The warehouse is mine. Loopcost has no customers and no design partners yet.
- !The models are a fixture, written to be found. That the detectors fired proves the pipeline runs — not that Loopcost finds problems in a warehouse it hasn't seen.
- !Total spend in the window is $5.47. The dollar figures mean nothing at this scale; the mechanism is the point.
Why l_shipdate
Metadata alone can tell you a table is large and unclustered. It cannot tell you which column to cluster on — that depends on how the table is actually queried, and no catalog records it. This is the gap that makes most clustering advice generic.
So Loopcost reads the WHERE and JOIN ON predicates of the queries that read this table, and counts how many distinct queries filter on each column:
| Column | Queries filtering on it |
|---|---|
| l_shipdate | 6 |
| l_returnflag | 3 |
| l_linestatus | 2 |
| l_shipmode | 2 |
The report states the evidence, not just the conclusion: “6 queries in the window filter on l_shipdate, the strongest clustering candidate.” Confidence on this rule rises from 0.5 to 0.65 when that evidence exists — the 0.5 baseline was set by exactly this blind spot.
Query text is read locally and discarded. Only column names and counts survive: no SQL, no predicate values, nothing that could carry data off your machine.
The two fixes it refused to make
Three recommendations, one live code change. The other two abstained, and the report says why rather than dropping them silently — an abstention is an output, not a failure.
hot_orders · convert_to_incremental
Written, but commented out. Flipping a model to incremental without an is_incremental()filter makes it append-only and duplicates every row on each run. That filter can't be placed automatically into an arbitrary query shape, so it stays a human step with the hazard spelled out.
hot_orders · partition_scan_ratio
“config() already sets cluster_by — nothing to add.” The table scans ~100% of its partitions despite having a clustering key, meaning the key isn't matching real query filters. Replacing it is a judgment call about query patterns, so the tool declines rather than guessing.
A tool that always produces a confident fix is a tool that produces confidently wrong ones. Knowing where the evidence runs out is what makes the rest worth trusting.
The report behind it
The PR is the output; this is the input. Spend attributed per dbt model over a 30-day window, reconciled against Snowflake's own billing view.
| Model | Materialization | Est. cost | Jobs |
|---|---|---|---|
| hot_orders | table | $0.96 | 24 |
| big_unclustered | table | $0.59 | 1 |
| healthy_incremental | incremental | $0.05 | 2 |
- coverage — 84% of attributed spend mapped to a dbt model
- reconciliation— 29% of the $5.47 warehouse bill; the rest is idle and cloud-services credits that per-query attribution can't cover, which the report states rather than hides
- freshness — data through 2026-07-18 19:47 UTC, so an incomplete tail reads as lag, not breakage
The fixture is public too — all three models are here, including the healthy control that nothing fires on.
What this doesn't show
It doesn't show what Loopcost would find in your warehouse, or what it would save you. These models were built to be found, on $5 of spend, by the person writing this page. A fixture can only prove the machine works — never that it's useful.
The open questions are the ones only a real warehouse answers: what coverage looks like against BI tools and ad-hoc analysts carrying no dbt identifier, whether the queries stay cheap against millions of rows of history, and whether these are fixes you'd actually merge. Nobody has run it on a production warehouse yet.
Want a PR like this against your own repo?
Read-only access to query history and billing views, and a GitHub token scoped to open draft PRs — no merge rights. Loopcost parses query history locally and discards the SQL; warehouse credentials never leave your side.