loopcostTry it on your warehouse

Find out which dbt model is actually costing you money.

Loopcost reads your warehouse's own billing data, maps every dollar to the exact dbt model that caused it, flags the anti-patterns that are provably wasting credits, and opens a PR with the fix. It runs as a CLI inside your own environment — your credentials and SQL never leave your infrastructure.

Try it on your warehouseSee how it works
loopcost report --warehouse snowflake

# attributable spend mapped to a dbt model

coverage: 99%

top attributed models (30d)

hot_orders$412.30no_incremental_on_hot_model
big_unclustered$268.15missing_clustering_key
healthy_incremental$41.02no flags

2 fixes available → loopcost remediate

99% coverage is from our live validation run — shape of a real report, not a specific customer's data.

0%

attribution coverage confirmed on a live Snowflake account

0

warehouses live-validated — Snowflake, Databricks, BigQuery

0

customer credentials ever touch a Loopcost server

0%

raw SQL parsed and discarded at the edge, never stored

You know the warehouse bill. Nobody knows which model caused it.

Credit and DBU pricing hide the real cost driver behind warehouse size, runtime, and auto-suspend — not a clean scanned-bytes number you can just read off a query. By the time the bill lands, it's a lump sum across hundreds of dbt models with no obvious owner.

Data teams end up guessing: killing a warehouse tier, nudging a schedule, hoping it helps. Loopcost replaces the guess with an answer — the exact model, the exact anti-pattern, and a PR that fixes it.

Unattributed

warehouse_invoice.csv · jun 2026 · snowflake

$14,208.62?

6 models billed · 0 owners identified

$4,830.93
$3,125.90
$2,557.55
$1,705.03
$1,278.78
$710.43

How it works

Four steps, run entirely inside your own environment.

attribute.log
query_tag→mart_orders

$268.90 · 412 credits

01

Attribute

Reads billed jobs straight from your warehouse's own query history and maps each one to a dbt node — query tag first, SQL comment second, destination table last. Priced on the actual billed unit (credits, DBUs), not raw bytes scanned.

detect.py
!missing_clustering_key

table metadata scan

02

Detect

Runs a small set of high-confidence detectors against table metadata — missing clustering keys, models that should be incremental but aren't, and more. No regex-on-SQL guessing that false-positives; quality over quantity.

fix.diff
materialized='table'
+ materialized='incremental'
03

Fix

Opens a draft PR against your dbt repo with the actual fix, gated on your existing CI. Never auto-merges. Then measures whether spend on that model actually dropped afterward.

PR #142
✓ safe to merge
04

Explain

Every PR writes its own summary — what changed, the expected saving, and whether it's safe to merge as-is. AI-drafted from your report, so it reads like a teammate opened it, not a bot.

One adapter interface, three warehouses proven against real accounts.

Snowflake

Live-validated

QUERY_HISTORY + QUERY_TAG give clean job-to-model mapping, priced on actual credits — opaque credit pricing is where the pain is sharpest.

Databricks

Live-validated

Unity Catalog system tables. Spend is apportioned per query by duration share of each warehouse's actual billed DBUs.

BigQuery

Live-validated

INFORMATION_SCHEMA.JOBS_BY_PROJECT, priced on total bytes billed — metered directly, the tightest confidence band of the three.

Built so your data never has to leave your infrastructure.

Your environmentself-hosted
raw query · in your warehouse
SELECT u.id, u.email, o.total
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.created_at > …

✕ query text + compiled SQL — dropped at ingest

parse · discard
What crosses
ingested by loopcost
{
  node_id: "mart.orders",
  bytes_scanned: 4.2e9,
  rule_flags: ["unclustered"],
  sha256: "9f1c…4e"
}

✓ non-reversible — nothing here can reconstruct a query

Parse-and-discard

Raw query text and compiled SQL are parsed at the edge and dropped at ingest. Only a node id, numeric metrics, rule flags, and a hash ever cross a boundary — nothing central can reconstruct a query.

Self-hosted CLI, always

The CLI runs inside your own environment against your own warehouse. Your credentials never go to a Loopcost server — that's a design invariant, not a setting.

Draft PRs, gated on your CI

Only metadata-provably-safe fixes are proposed. Every PR is draft-by-default and gated on your existing dbt CI and tests. Nothing auto-merges.

Point Loopcost at your own dbt project and see what it finds.

The engine runs against live Snowflake, Databricks, and BigQuery. We'll set it up on your actual warehouse, show you exactly what's driving your spend, and open the fixes as PRs you review — no commitment, just real data.

You get

  • 01

    Free, white-glove setup against your actual dbt project and warehouse

  • 02

    Direct input into which detectors and fixes ship next

  • 03

    A Loopcost engineer on the other end of every PR, not a support queue

We ask

  • 01

    Read access to your warehouse's query history (via a read-only role you control)

  • 02

    Honest feedback on what the report gets right and wrong

  • 03

    Permission to reference the realized spend delta, anonymized, if the results are worth sharing

Set it up on my warehouse

self-hosted CLI · your credentials never leave your infrastructure

Questions and answers

  • 01Does my SQL or data ever leave my infrastructure?

    No. The CLI runs inside your own environment. Raw query text and compiled SQL are parsed at the edge and discarded immediately — only a node id, numeric metrics, rule flags, and a hash ever cross a boundary.

  • 02Do you take my warehouse credentials?

    No. You point the CLI at a read-only role you create and control. Nothing is ever sent to a Loopcost-hosted server on your behalf.

  • 03Which warehouses do you support?

    Snowflake is the lead adapter. Databricks and BigQuery are also live-validated against real accounts. All three share one warehouse-agnostic core, so adding a fourth doesn't touch existing behavior.

  • 04How is this different from Snowflake cost tools like SELECT or Keebo?

    Those tools optimize at the warehouse-configuration layer — auto-sizing, auto-suspend, cluster tuning — without touching your dbt code. Loopcost attributes cost down to the specific dbt model and opens a draft PR against your own repo to fix the anti-pattern (add a clustering key, convert to incremental). Different layer, same warehouse bill.

  • 05What does the auto-generated fix actually change?

    Only metadata-provably-safe changes — things like adding a clustering key or converting a model to incremental. Every fix ships as a draft PR gated on your existing dbt CI and tests. Nothing auto-merges.

  • 06Is this open source?

    Not publicly released yet. It's built as a self-hosted CLI by design — runs entirely inside your environment so we never need your credentials — but the source is still private while we onboard our first design partners. Ask us for early access.

  • 07How long does it take to get a first report?

    Once you've granted a read-only role and pointed the CLI at your dbt manifest, a first report typically runs in minutes. Coverage improves further once you add the optional query-tag macro to your dbt project.