Your Claude Token Bill Isn’t a Prompting Problem. It’s a Data Engineering Problem.

Companion repo with all four skills: github.com/jay-jain-10/claude-token-savings-data-eng

What actually saves tokens when you’re running the full stack — Kafka/Kinesis/Debezium ingestion, Spark/Flink/Beam processing, Airflow/Dagster/Prefect orchestration, Iceberg/Delta/Hudi storage, and Snowflake/Databricks/BigQuery/Redshift/ClickHouse warehousing — through an agent, and why the trick that went viral on Reddit isn’t the one moving your bill.

A few months ago, a Reddit post in r/ClaudeAI claiming a “caveman mode” system prompt cut Claude’s token use by 75% picked up roughly 10,000 upvotes and got syndicated by Decrypt and PCWorld. Since then it’s been packaged into installable Claude Code skills, spawned siblings like ponytail (a “lazy senior dev” persona for minimal diffs) and grill-me (front-load the clarifying questions), and now there’s headroom — a local daemon that intercepts and compresses tool output before it hits the model, claiming 60–95% reductions.

I lead a data engineering team, and the job isn’t one tool — it’s ingestion (Kafka, Kinesis, Debezium CDC), processing (Spark, Flink, Beam/Dataflow), orchestration (Airflow, Dagster, Prefect), storage (Iceberg, Delta Lake, Hudi), warehousing (Snowflake, Databricks, BigQuery, Redshift, ClickHouse), and transformation (dbt, SQL) on top of AWS or GCP. My Claude sessions aren’t chatty Q&A — they’re reading 30,000-row information_schema dumps, Spark and Flink stack traces, dbt manifest.json, Iceberg snapshot metadata, warehouse query profiles, Kafka/Debezium connector logs. So I went and checked what actually holds up, read Anthropic's own docs on the mechanisms they built for this exact problem, and then built four skills of my own covering the failure modes nobody in the caveman-mode discourse is talking about, because they're specific to this job, end to end.

Here’s what I found, and what I built.

The viral trick saves the wrong 25% of your tokens

The caveman-mode claim is real — the skill exists, people use it, andrew.ooo and others have written reviews of it. But the 65–75% number is the skill author’s own benchmark, not an independent audit, and there’s a specific, well-documented reason it overstates what you’ll see in practice: caveman mode only compresses output tokens. In an agentic coding or data-engineering session, output is usually the minority of the bill. The majority is input — the conversation history, the files you read, the tool results you’re re-sending every turn. One breakdown (pasqualepillitteri.it) puts realistic end-to-end savings closer to 25%, once you count everything actually flowing through the context window. Other critics point out the skill itself adds 1–1.5k tokens of system prompt overhead per turn to buy that 25%.

There’s also a real cost that doesn’t show up in a token counter. Reviewers on LinkedIn and DEV Community who ran it for extended periods both converge on the same complaint: the explanatory context that gets stripped isn’t fluff, it’s the reasoning trail you’d want if something goes wrong later. For a solo dev shipping a small script, maybe that’s an acceptable trade. For a pipeline that decides how a table gets backfilled, it’s the wrong trade.

None of this means terseness is worthless — it means it’s the wrong first lever to pull, and the wrong thing to apply uniformly. More on that below.

What Anthropic actually built for this, and the numbers are better than caveman mode’s

While the community was going viral over a system prompt, Anthropic shipped four real mechanisms for exactly this problem, documented and priced:

Prompt caching. Cache a static prefix — your system prompt, tool definitions, a codebase snapshot — and reuse it across calls. Reads cost 0.1x base input price; writes cost 1.25x (5-minute TTL) or 2x (1-hour TTL) — docs.claude.com/prompt-caching. Anthropic’s own benchmarks: a 100k-token cached prompt drops cost by up to 90% and time-to-first-token from 11.5s to 2.4s (Anthropic’s launch post). This is the single highest-leverage thing you can do if your session re-sends the same schema context or system prompt every turn, and most agent harnesses (Claude Code included) already do this for you by default.

Context editing. A beta feature (context-management-2025-06-27) that automatically clears stale tool-call results and old extended-thinking blocks once a threshold is hit, instead of letting them accumulate forever. Anthropic's own 100-turn web-search eval measured an 84% token reduction (docs.claude.com/context-editing). If your session involves dozens of tool calls per hour — which any Spark/dbt/warehouse debugging loop does — this matters more than any prompt style.

Code execution with MCP. Anthropic’s own engineering team found that exposing MCP tools directly can dump enormous, mostly-irrelevant intermediate results into context — and fixed it by having the model write code that calls tools and filters results in a sandbox before anything reaches the context window. Their own example: 150,000 tokens down to 2,000 — a 98.7% reduction (anthropic.com/engineering/code-execution-with-mcp). If you’re running dbt-mcp, Snowflake’s or Databricks’ MCP servers, and a couple of others in the same session, this is the difference between a usable context window and one that’s 18k+ tokens of tool schemas before you’ve typed anything (measured independently here).

Sub-agent isolation. Anthropic’s context-engineering writeup (anthropic.com/engineering/effective-context-engineering-for-ai-agents) describes sub-agents doing tens of thousands of tokens of exploration in a clean context and returning a 1,000–2,000 token summary to the parent. This is exactly the shape of a “go read every model in this dbt project and tell me which ones touch orders" task — do it in a sub-agent, not the main thread.

None of these require a personality change. They require you to actually use the caching, compaction, and execution features that are already there. That’s the boring part of this article, and it’s the part that moves the number.

The part nobody’s writing about: data engineering has its own context-burners

Generic advice on trimming logs and schemas exists, but almost nothing specific to our stack does. A few things I’ve confirmed are real, underdiscussed problems:

Schema dumps are enormous and mostly irrelevant to the task at hand. One developer measured a 500-table database’s full DDL at roughly 93,000 tokens against a pruned, task-relevant schema map at about 4,000 (dev.to/eitamos_ring). A separate tool, dbdense, reports a 64% token reduction on multi-table joins just from compiling schema into compact JSON/DDL instead of letting the model explore it live. dbt’s own manifest.json/catalog.json are, by design, a full graph representation of your entire project — great for tooling, brutal for a context window if you paste the whole thing in for a one-model question. This gets worse, not better, once an open table format is involved: an Iceberg table with hourly commits can accumulate 2–4GB a year of snapshot and manifest metadata, versus roughly 200–500MB for the equivalent Delta Lake transaction log (flexera.com) — read that history into context and you've burned your budget before you've looked at a single row.

Stack traces, orchestrator logs, and warehouse query profiles are almost pure noise around a small causal core, across every engine, not just Spark, and I could not find a single existing write-up that names this directly — which is either a gap in the discourse or a sign that most of the “reduce your Claude bill” content is written by people who’ve never had to paste a 14,000-line executor log into a chat window. A Spark OOM trace repeats the same JVM frames across five retry attempts before failing; Flink adds its own version of this with checkpoint and backpressure chatter; a Beam/Dataflow job log can run into millions of per-element lines with zero public discussion of the problem anywhere I searched. An Airflow, Dagster, or Prefect run log is 90% scheduler/sensor polling. A Snowflake, BigQuery, Redshift, or ClickHouse query profile’s operator tree is mostly nodes that took 40 milliseconds out of an 8-minute query.

MCP tool definitions stack up fast once you’re running the real toolchain. dbt, Snowflake, Databricks, BigQuery, and ClickHouse all have official or Google-managed MCP servers (ClickHouse’s is ClickHouse/mcp-clickhouse; Redshift’s best option is currently a community multi-database server, not an official one); Airflow, Dagster, and Prefect each have MCP servers too (Prefect’s official one, Dagster’s). Every one of them adds its full tool schema to every request whether you use it that turn or not — run four or five in one session and you’ve paid a real tax before typing a word.

What I built instead of adopting caveman mode wholesale

I didn’t want a personality skill. I wanted the input side of the bill handled, with the domain knowledge caveman mode doesn’t have, and I wanted the one place where front-loaded questions genuinely pay for themselves — pipeline design, where a wrong assumption about grain or backfill costs a full rebuild, not a re-prompt. Four skills, each aimed at a specific, real cost:

[**schema-diet](https://claude.ai/cowork/)** — compresses schema- and metadata-shaped tool output (manifest/catalog JSON, DESCRIBE, information_schema, Iceberg/Delta/Hudi table metadata) the way dbdense does, but with warehouse-and-lakehouse-specific knowledge: it collapses audit columns (_loaded_at, _fivetran_synced), collapses a family of identically-shaped partitioned tables into one representative instead of repeating the schema N times, collapses an open table format's snapshot history to a count and date range instead of reading the whole commit log, and always preserves keys (or Redshift dist/sort keys, ClickHouse ORDER BY/PARTITION BY, BigQuery partition/cluster columns) and row-count order of magnitude. It also tells you what it cut, every time — a lossy compressor that hides what it dropped is a liability in a warehouse.

[**trace-triage](https://claude.ai/cowork/)** — the skill for the gap above, generalized across the whole stack. System-specific noise rules for Spark and Flink stack traces (keep the exception chain and final retry, drop repeated JVM/checkpoint frames), Beam/Dataflow job logs (keep the failed stage, drop per-element processing lines), Airflow/Dagster/Prefect run logs (keep state transitions and the first error, drop scheduler/sensor polling), Kafka/Kinesis/Debezium logs (keep rebalances, final lag, first crash-loop error), and query profiles across Snowflake/Databricks/BigQuery/Redshift/ClickHouse (keep the top 3 costliest operators, drop the tree). Same principle as schema-diet: never touches the actual error message, row count, or cost figure.

[**spec-grill](https://claude.ai/cowork/)** — my version of the grill-me pattern, but walking an actual end-to-end dependency chain instead of generic project questions: ingestion mode (batch/CDC/stream) → grain → freshness/SLA → incremental strategy → storage/table format → partition key → backfill/idempotency → schema evolution → data quality tests → orchestration & cost. Each answer constrains the next question, each question comes with a recommended default so you can just say "yes" through the whole list. This is the one place I think front-loaded interrogation is worth more than the tokens it costs — a pipeline with the wrong grain, or CDC bolted on after the fact, doesn't cost you a re-prompt, it costs you a rebuild and a bad backfill.

[**ledger-terse](https://claude.ai/cowork/)** — the honest answer to caveman mode. Compress narration and explanation, same as caveman mode does. But never compress a number, a key, a DDL statement, a backfill date range, or a cost figure, and never let a confirmation before an irreversible action (a DROP, a full-refresh on a big table) get compressed into a fragment. Caveman mode's own critics are right that stripped context is sometimes the lesson you needed — in this job, it's sometimes the guardrail that stops a bad backfill.

Where headroom fits, honestly

Headroom is real — it’s an Apache-2.0 project by a Netflix engineer, Tejas Chopra, reported by The Register at roughly 2,000 GitHub stars. That’s worth separating from the wave of near-identical Medium/SEO posts currently citing 40,000+ stars and specific dollar-savings figures — those numbers trace back to the creator’s own README and haven’t been independently reproduced. The mechanism (a local proxy with format-specific compressors for JSON, code, and logs) is directionally the same idea as schema-diet and trace-triage above, at the infrastructure layer instead of the skill layer. If you want that at the proxy level for every tool call across your whole team, it's worth a look — just run it with logging off, since a local proxy sitting in front of your model traffic is exactly the kind of thing a security review should see before it's on every engineer's laptop.

The actual priority order

If you’re optimizing a Claude Code setup across ingestion, processing, orchestration, storage, and warehousing, in the order I’d do them:

1. Turn on and structure for prompt caching — put your system prompt, schema context, and tool definitions first, dynamic content last. This is free and automatic in most harnesses; you’re likely already paying for cache writes you’re not benefiting from if your prompt structure changes every turn.
2. Use sub-agents for anything that means “go explore a lot of files/tables/DAGs and tell me the answer” — keep the exploration out of your main thread.
3. If you’re running multiple MCP servers (dbt, Snowflake, BigQuery, Databricks, ClickHouse, Airflow, Dagster, Prefect) in one session, look at whether code execution / progressive tool disclosure is available to you before accepting the full tool-schema tax on every request.
4. Stop pasting full schema dumps, full table-format metadata histories, and full logs — whatever the engine. This is the one that’s genuinely underserved by existing tooling — it’s why schema-diet and trace-triage exist.
5. Front-load design questions on anything with state (a new table, a new incremental model, a new CDC pipeline) — not because it’s about tokens, but because it’s cheaper than a bad backfill or a rebuild onto the wrong table format.
6. Only after all of that, consider a terse output mode — and make it one that knows the difference between a paragraph and a DROP TABLE.

Caveman mode isn’t wrong. It’s just optimizing the smallest line item on a data engineer’s bill while the schema dump, the stack trace, and the tool-schema tax sit there uncompressed. Fix the boring stuff first.

Caveman mode isn’t wrong. It’s just optimizing the smallest line item on a data engineer’s bill while the schema dump, the stack trace, and the tool-schema tax sit there uncompressed. Fix the boring stuff first.

This is v1

Four skills is a starting point, not the finished shape of this. The stack keeps growing — Trino/Presto, Redshift Spectrum, Elasticsearch/OpenSearch, dbt Cloud-specific metadata, Terraform-managed infra logs, and probably a Postgres/MySQL OLTP-side skill for the CDC source end of the pipeline are the obvious next additions, and I’d rather ship the four that are already battle-tested than hold the whole thing back waiting to cover everything at once. If you hit a context-burner in your own stack that isn’t covered here, that’s exactly the kind of gap this repo is meant to fill next — open an issue or a PR.

References

Official Anthropic sources

• Prompt caching — docs.claude.com
• Prompt caching launch post — anthropic.com
• Context editing (beta) — platform.claude.com
• Code execution with MCP: building more efficient agents — anthropic.com/engineering
• Effective context engineering for AI agents — anthropic.com/engineering

Caveman mode and the terse-persona trend

• Devs Taught Claude to Talk Like a Caveman to Cut Costs — Decrypt
• Claude users are teaching it to talk like a caveman — PCWorld
• ponytail skill — GitHub
• grill-me skill — MCP Market
• Caveman Claude Code skill: a token savings review — andrew.ooo
• Claude Code caveman mode: real token savings breakdown — pasqualepillitteri.it
• “Don’t use Caveman in Claude Code Until You Know This” — LinkedIn
• I ran Claude Code in caveman mode for 48 hours — DEV Community

headroom

• headroom — GitHub
• Netflix engineer’s side project slashes AI bills, then he open-sources it — The Register

Data engineering context-burners

• Stop sending 93K tokens of schema to your LLM agent — dev.to
• dbdense — GitHub
• Apache Iceberg vs Delta Lake: metadata management and indexing — Flexera
• Claude Code MCP server token overhead — MindStudio

MCP servers referenced

• dbt-mcp — GitHub
• Snowflake-Labs/mcp — GitHub
• Databricks managed MCP servers — docs.databricks.com
• Using the fully managed remote BigQuery MCP server — Google Cloud Blog
• ClickHouse/mcp-clickhouse — GitHub
• Prefect MCP server — docs.prefect.io
• Dagster’s MCP server — dagster.io

Skills referenced (schema-diet, trace-triage, spec-grill, ledger-terse) are available as installable Claude Code SKILL.md files, along with this article, in the companion repo: github.com/jay-jain-10/claude-token-savings-data-eng.