It works by consuming `terraform show -json` output and evaluating cost changes locally using embedded pricing data. There are no cloud API calls, no IAM roles, and no network access at runtime, which keeps the output deterministic and cheap enough to run in CI.
The motivation came from a specific frustration: cost feedback usually arrives after deploy, when the change is already merged and normalized. Terraform plans already describe irreversible infrastructure decisions, so estimating cost there makes it part of code review instead of a billing post-mortem.
Design constraints I cared about: - deterministic execution (same input → same output) - fully offline (no IAM, no APIs, no telemetry) - intended to run before merge, not after deploy - directional accuracy rather than billing-exact precision
Trade-offs (real ones): - it can’t model runtime behavior like autoscaling or traffic - it’s weak at usage-driven costs (especially egress) - it won’t match provider bills to the cent
What this is explicitly not trying to solve: - unexpected bills from existing infrastructure - org-wide FinOps dashboards - tagging, chargeback, or attribution workflows
This started as a narrow experiment to answer one question: For Terraform-managed infrastructure, is cost estimation more useful before merge than after deploy?
One open design question I’m still unsure about: Right now it stays strictly with `terraform show -json` to preserve determinism. Is the UX win of parsing HCL directly worth the loss in reliability, or is JSON-only the right trade-off?