Aaron Bronow

Last week, I installed codeburn on my primary Ubuntu development VM to see what my coding agents were actually doing. You probably already tried asking chat. You have dashboards provided by Anthropic that only tracks their model. Knowing how many tokens you burned in a folder is a vanity metric. Knowing what it cost to ship working code is engineering telemetry.

I first learned about CodeBurn and the PRISM D1 observability suite at an AWS workshop in Santa Monica during LA Tech Week. The architecture immediately clicked for me.

When I ran codeburn on my VM, it scanned 43 providers, found 244 Antigravity CLI sessions, and reported $106.56 in 30-day token volume across 574.74 million tokens and 5,032 API calls.

Then I looked at the project breakdown. 87% of that spend ($92.60) was lumped into a single, generic bucket named "antigravity-cli".

I run multiple ventures out of separate multi-repo workspaces on this machine—Packablock (my supply-chain attestation and SBOM registry) and Tuesday.sh (package update and home network stability telemetry). Having 90% of my agent telemetry dumped into a generic CLI bucket was like getting an itemized restaurant receipt that just says “Food: $92.60.”

I wanted to know two things: how much compute was going into each venture, and what my true unit economics looked like per shipped commit.

Here is what I found when I tore into the parser, wired up PRISM D1 git attribution, and tested AWS CloudWatch Omni against my live agent streams.

1. The 5-Line Bug Hiding 87% of My Spend (getagentseal/codeburn#1841)

When I tried to manually map my directories using codeburn project link, it failed. It insisted those repositories didn’t exist in my history.

So I cracked open the SQLite conversation databases (~/.gemini/antigravity-cli/conversations/<id>.db). Inside the trajectory_Summaries table, Antigravity CLI stores a base64 protobuf blob (trajectory_metadata_blob) containing the exact file:/// workspace URI for every session.

Here was the kicker: codeburn already had a function (extractWorkspacePath) that decoded that exact protobuf and extracted the project name (packablock, tuesday-sh).

Why wasn’t it working? Because five lines later in applyAntigravityProject(), there was a hardcoded early return:

if (source.project === "antigravity-cli") {
  call.project = source.project;
  delete call.projectPath;
  return;
}

Every time extractWorkspacePath did the hard work of pulling the real repository path out of the SQLite protobuf, that 5-line check threw it in the trash and overwrote the project back to "antigravity-cli".

I patched my local install and opened PR #1841 upstream (which maintainer @iamtoruk reviewed, refined to preserve the durable RPC cache without a global cache-version bump, and merged into main on November 4).

The moment I re-parsed my local cache, all 244 sessions snapped into focus with zero token drift:

• Tuesday.sh workspace: $41.86 across 172.52M tokens (1,111 calls)
• Packablock workspace: $18.71 across 123.63M tokens (2,237 calls)
• Blog & Postmill studios: $30.16 across 200.26M tokens (1,122 calls)

(Quick reality check on those dollar figures: my daily Antigravity sessions run on a flat-rate Google AI Ultra subscription, not metered API billing. Because codeburn multiplies token counts against public pay-as-you-go list prices, those numbers actually measure API-Equivalent Value Generated—helped massively by a 93% prompt cache hit ratio that keeps my subscription quota stretching all month).

2. Unit Economics: $0.04 vs. $2.99 per AI Commit

Knowing how many tokens you burned in a folder is a vanity metric. Knowing what it cost to ship working code is engineering telemetry.

I paired codeburn with @prism-d1/cli to benchmark my workspaces across PRISM’s 8 maturity dimensions. Out of the box, PRISM’s D1 (Velocity & Economics) dimension scored 0 because it looks for commit trailers (AI-Origin, AI-Agent, AI-Model) in your git history.

Interestingly, @prism-d1/cli recently deprecated its own .git/hooks installer because developers constantly bypass or clobber local git hooks across multi-repo checkouts.

In my workspaces, however, agents never run raw git with my personal credentials. Every agent role (agy, contributor-1, tester, planner) is required to commit through a central wrapper (./scripts/git-agy) that injects its scoped GitHub PAT and SSH signing key.

Adding three lines to that central wrapper gave me 100% deterministic commit attribution across every sub-repository—with zero brittle .git/hooks:

git "${git_configs[@]}" "$@" \
    --trailer "AI-Origin: antigravity" \
    --trailer "AI-Agent: $GITHUB_NAME ($profile)" \
    --trailer "AI-Model: ${AI_MODEL:-gemini-4-argon}"

When I joined my 30-day codeburn session spend with my multi-repo git history, a fascinating contrast jumped off the screen:

Look at that bottom line: $0.04 per commit on Packablock versus $2.99 per commit on Tuesday.sh.

Why the 75x difference? Packablock is in hardened execution mode—tight issue scopes, mature .agents/GEMINI.md guardrails, and surgical commits. Tuesday.sh was in early architectural R&D, where I spent multi-hour sessions prototyping Android and iOS hardware discovery against live simulators before cutting granular commits.

Without combining token telemetry and git trailers, that architectural signal is completely invisible.

3. Two Paths to AWS: The Full Workshop Suite vs. Lean Single-Dev Mode

I wanted this telemetry in AWS CloudWatch so I could query both ventures in one place using Amazon CloudWatch Omni.

At the AWS workshop in Santa Monica during LA Tech Week, I got to see the full PRISM D1 architecture in action. To understand how both approaches behave in production, I deployed and tested both setups side-by-side in us-west-2:

Path A: The Full PRISM D1 Workshop Suite (prism-cli workshop deploy-infra)

For most engineering teams, prism-cli workshop deploy-infra is the gold standard and the exact path I recommend. In one command, it deploys three well-architected AWS CDK stacks (~85 CloudFormation resources): KMS-encrypted DynamoDB tables, a Cognito User Pool with OIDC PKCE so every developer logs in cleanly via codeburn sync setup, EventBridge rules, Bedrock Guardrails, 10 Lambdas, and four turnkey CloudWatch Dashboards (Team-Velocity, Developer-Productivity, Executive-Readout, and CISO-Compliance).

Two practical notes if you are deploying the workshop suite on a brand-new startup AWS account:
1. VPC Interface Endpoint Sizing (-c skipVpc=true): By default, the stack provisions 5 PrivateLink VPC Interface Endpoints across 2 AZs (~$72/month for the shared team stack). For an established engineering org, PrivateLink isolation is a no-brainer; if you’re testing on startup credits, passing --context skipVpc=true drops the fixed idle cost to $0/month.
2. New-Account Lambda Concurrency Quotas: The API stack configures reservedConcurrentExecutions: 100 on its handler. Brand-new AWS accounts start with a default regional concurrency limit of 10 until you request a quota bump, so dial that parameter down on fresh accounts.

Path B: My Lean Single-Dev Collector (aws-otel-collector + CloudWatch Omni)

Right now, I’m operating in lean single-dev mode. While the full PRISM D1 workshop stack is firmly on my upgrade path as I grow the team and need multi-developer OIDC identity and CISO compliance dashboards, I didn’t need 85 CloudFormation resources just for myself today.

To save runway while still getting the full power of AWS CloudWatch and CloudWatch Omni, I wired up a lightweight local collector using the official aws-otel-collector (ADOT) binary, a 40-line config.yaml, and a nightly cron job.

Deployment time: 30 seconds. Fixed idle cost: $0.00/month—and my data is already sitting in CloudWatch ready for when I graduate to the full team suite.

4. The OTLP + DataFusion Quirk in CloudWatch Omni

Getting my custom collector logs into CloudWatch Omni (AWS’s natural-language and SQL observability workspace) uncovered an interesting interaction between OpenTelemetry formatting and Omni’s SQL engine.

Initially, I configured aws-otel-collector to ship my JSONL logs via the standard otlp_http exporter (logs.us-west-2.amazonaws.com/v1/logs).

When otlp_http ingests a JSON log, it wraps your fields inside an OTLP struct: attributes.event, attributes.model, attributes.costUSD.

Then I opened CloudWatch Omni and asked its AI assistant a simple question: “Show me model spend by venture.”

Omni’s AI query planner generated this SQL:

SELECT ... FROM `default` WHERE `attributes.event` = 'codeburn_model'

And it returned zero rows.

Why? Because CloudWatch Omni’s SQL engine runs on Apache DataFusion. When the AI query planner wraps a dotted field name in backticks ( attributes.event ), DataFusion treats it as a literal column name containing a period rather than traversing the attributes struct. (In the full PRISM workshop CDK stack, the custom otel-receiver Lambda unpacks those OTLP spans into flat columns for you automatically).

I also noticed that running codeburn export --format json -o file.json outputs human-readable table headers ("Cost (USD)", "API Calls") instead of camelCase keys, and nests models[] and daily[] arrays inside a single row.

How I Fixed It on My Lean Collector:
1. Unnest with jq -c: I piped codeburn export through jq -c to emit one flat JSONL row per model (event: "codeburn_model") and one per day (event: "codeburn_daily") with clean camelCase keys (venture, model, calls, costUSD).
2. Switch ADOT to awscloudwatchlogs with raw_log: true: Switching from otlp_http to the native awscloudwatchlogs exporter (raw_log: true) stripped the OTLP wrapper entirely.

Every field immediately indexed as a true top-level column in Omni’s default dataset. Both manual SQL and Omni’s natural-language AI chat worked on the first try.

5. Dev VMs vs. Production Servers: Why You Shouldn’t Run codeburn on Your Backend

Once my developer VM telemetry was humming on a nightly 00:10 cron, I faced one last question: how should I capture AI spend from my live production backends?

When you fall in love with a developer tool like codeburn, it is tempting to try to run it everywhere—maybe install the CLI inside your production containers or attach a heavy log-scraping sidecar to your web servers.

Don’t do it.

codeburn exists on developer machines because coding agents are closed binaries. You don’t own the HTTP client inside Claude Code, Cursor, or Antigravity CLI. Because you can’t hook into their network calls directly, those tools write local session transcripts (.db and .jsonl files), and you need an external parser like codeburn to scrape those files after the fact.

On your own production server, you own the exact line of code calling the LLM.

Installing a file scraper or spinning up a collector sidecar alongside a stateless Cloud Run container wastes RAM, slows down cold starts, and misses application-level context. Worse, you’d be writing logs to disk just so another process can parse them back out.

Instead, on tuesday-server and in my Python datalake harvesters, I wrote a 50-line inline logger (Telemetry::HostedAiLogger). Right after the LLM API responds, the server reads the exact usage token ledger directly from the HTTP response (prompt_tokens, completion_tokens, cached_tokens), calculates costUSD, and ships a single flat JSON event (stream: "hosted-ai-v1") straight to the same /tuesday/codeburn log group in AWS CloudWatch.

Because the inline logger uses the exact same column names as my codeburn export (venture, model, calls, costUSD, cacheReadTokens), one SQL query in CloudWatch Omni shows my Dev Coding Agent Spend (adot-v2) and my Production Server Inference Spend (hosted-ai-v1) side by side.

Pro Tip: Match your telemetry pattern to who owns the HTTP client. Use file scrapers (codeburn) on developer workstations where the agent is a black box. Use a 50-line inline logger on production servers where you own the API call. And if your CloudWatch Omni queries return zero rows on custom OpenTelemetry logs, check the backticks—raw_log: true will save your sanity.