Nobody Can Say Whether the Engineer Burning $50K a Month Is Waste

What do you do about the engineer who burned fifty thousand dollars

One engineer at Rippling spent $50,000 on tokens in a single month. Company-wide, AI token spend was growing 80% month over month, on track to consume 40% of the R&D headcount budget, with 605 billion tokens flowing through in the peak month. Ten to fifteen percent of employees were generating 60% of total spend (TechCrunch).

The hard part is not cutting the spend. It is deciding what to do about that one engineer. If it is waste, block it. If the output justifies it, the right move is the opposite: get everyone else spending like them. A spend leaderboard cannot distinguish the two cases, and a spend leaderboard is all most companies have.

Rippling built an internal tool to answer the question, then shipped it as a product called AI Spend Console (Rippling). It joins spend by employee, team, and role to signals from work systems like GitHub and Salesforce: pull request volume, code velocity, how often peers ask for rework in code review, even revenue contributed (Business Wire). The result is telling. After controls, Rippling’s July usage was 600 billion tokens, close to the peak, at 37% of April’s cost. Usage did not shrink. Only the waste did.

A tool one company built out of its own pain is proof the category exists. But Rippling’s product is tied to its HR suite and weighted toward spend control. The seat for a neutral layer that sells attribution itself is open.

Under flat rates the question could not even be asked

Until last year this measurement was impossible by construction. Under per-seat flat pricing every employee’s AI cost was identical, so there was nothing to attribute. Usage-based pricing opened gaps of 10x to 100x between individuals in the same role, and only then did the question “does this gap show up in output” become askable.

The first response wave has already passed. Budget caps, cheap-model routing, team limits: the tools exist and companies have deployed them. The moment control is in place, the next question arrives. Of the spend that remains, which do you protect and which do you grow? Rippling’s sequence was exactly that: block first, then build the measurement tool.

The output side is finally joinable too. Engineering organizations expose pull requests, cycle time, and review rework through APIs; sales organizations leave pipeline in the CRM. Spend logs exist. Output logs exist. The missing piece is one join between them, and a missing join is a product.

One join between the spend log and the output log

flowchart LR
  A[Gateway and SSO<br/>usage logs] --> C[Attribution engine]
  B[GitHub, Jira, CRM<br/>output signals] --> C
  C --> D[Team and cohort<br/>ROI views]
  D --> E[Where to spend more,<br/>where to cut]
  E --> F[Spread top users'<br/>patterns internally]

The collection layer does not need to be built. Most companies already funnel calls through an LLM gateway or proxy, so identity, model, and tokens come from those logs, and GitHub, Jira, and the CRM attach through existing APIs. The hard part is not plumbing but comparison design: build cohorts of the same role and similar tenure, then show how output differs by AI usage intensity. Lead with individual leaderboards and the product reads as surveillance, at which point the field starts poisoning the data. Team and cohort views are the default; individual drill-down sits behind permissions.

The second layer is the real differentiation. Extract the patterns of users whose output-per-dollar is best, which models they use for which tasks, and turn that into playbooks the rest of the organization can adopt. At that point the buyer changes. Cost reduction is a CFO concern; how people work is a CTO and people-team concern. The position is the empty square between FinOps tools and people analytics, and independence from any single HRIS is the moat against Rippling.

Sell correlation as causation and the first data review kills you

The most dangerous assumption is that correlation between spend and output can be sold as causation. If your best engineers simply also use AI heavily, the tool’s recommendations collapse at the first serious data review. Conservative cohort design, and the discipline to say “this difference is observed in this team over this window” rather than more, is the entire trust budget of the product.

Second is Goodhart’s law. The moment pull request counts feed into evaluation, pull requests get sliced thinner. Mix in metrics that resist gaming, rework rates, cycle time, incident rates, and rotate the composition. Last is expansion order: start in engineering where output is measurable, because rushing into roles where measurement is fuzzy destroys trust in the numbers everywhere. Whether Rippling’s 40% was one company’s accident or next year’s default for everyone is what sets the size of this market.