Rippling Burned 40% of Its Engineering Budget on AI Tokens.

Rippling Burned 40% of Its Engineering Budget on AI Tokens. So I Built a Cheap Version of the Tool They Made to Fix It

A look at Rippling’s new AI Spend Console, and a working, self-hosted alternative you can set up in an afternoon.

The number that should scare every engineering leader

On August 7, 2026, TechCrunch ran a story with a line that made me put my coffee down: Rippling, the HR/payroll platform, had been on track to spend 40% of its entire R&D headcount budget on AI tokens. Not 40% of a tools budget. Forty percent of what it pays its engineers, going instead to Anthropic, OpenAI, and Cursor invoices.

The details, as reported by Julie Bort, are almost cartoonish. Spend was growing 80% month-over-month. One engineer was personally burning $50,000 a month in tokens. Roughly 10–15% of employees were driving 60% of total AI spend. When CFO Adam Swiecicki put the number in front of the executive team in March, Chief Product Officer Matt MacInnis said the reaction was simple disbelief.

So Rippling built a product to fix its own problem, then decided to sell it: AI Spend Console. It tracks who’s spending what, on which models, and (this is the interesting part) whether that spend is actually producing anything. The blog post gives a genuinely uncomfortable example of what the dashboard can surface: “which engineers have high AI spend whose peers frequently ask them to redo work in code reviews.”

That’s not a cost dashboard. That’s a productivity lie detector.

Why this landed for me

I don’t run a team burning six figures a month on tokens. But I use Claude Code, Cursor, and a rotating cast of API keys every single day, and I recognized the underlying pattern immediately: I default to the newest, most expensive model for everything, including tasks that don’t need it. Renaming a variable, writing a commit message, checking grammar on a draft: same frontier model as the task that actually needs deep reasoning.

MacInnis said something in the TechCrunch piece that stuck with me: “The truth is that the inference providers… have absolutely no incentives to help you control your spend.” That’s not a knock on Anthropic or OpenAI, it’s just structurally true. Nobody upstream is going to tell you that a cheaper model would’ve done the job. You have to build that discipline yourself, or buy a product that does it for you.

Rippling’s fix had two parts, and only one of them requires HR software:

1. A gateway that routes requests to the cheapest model that can do the job , instead of defaulting to the frontier model every time.
2. Visibility : spend broken down by person, team, and role, tied back to actual output (pull requests, code review rework, tickets closed).

Part one, it turns out, you can build yourself in an afternoon with open-source tools. Part two takes more work, but a rough version is doable too. I put together a small stack to prove it out.

Building the poor man’s AI Spend Console

The core idea: put a proxy in front of every model call. Route cheap, low-stakes tasks to a local model running on your own hardware. Route everything else through a router that picks the least expensive model that meets a quality bar. Log every call so you actually know where the money goes.

I used LiteLLM as the gateway (open source, does exactly what Rippling’s internal gateway does: routes and logs requests to 100+ providers behind one OpenAI-compatible API) and Ollama as the free, local fallback for anything that doesn’t need a frontier model.

docker-compose.yml

version: "3.9"
services:
  ollama:
    image: ollama/ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_data:/root/.ollama
    litellm:
    image: ghcr.io/berriai/litellm:main-latest
    ports:
      - "4000:4000"
    volumes:
      - ./litellm-config.yaml:/app/config.yaml
    command: ["--config", "/app/config.yaml", "--port", "4000"]
    environment:
      - ANTHROPIC_API_KEY=${ANTHROPIC_API_KEY}
      - OPENAI_API_KEY=${OPENAI_API_KEY}
    depends_on:
      - ollama
volumes:
  ollama_data:

litellm-config.yaml (this is where the actual routing policy lives):

model_list:
  # cheap/local: grammar, commit messages, formatting, low-stakes drafting
  - model_name: cheap-local
    litellm_params:
      model: ollama/qwen2.5:14b
      api_base: http://ollama:11434
# mid-tier: everyday coding tasks
  - model_name: mid-tier
    litellm_params:
      model: anthropic/claude-haiku-4-5-20251001
      api_key: os.environ/ANTHROPIC_API_KEY
  # frontier: reserved for tasks that actually need it
  - model_name: frontier
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY
router_settings:
  routing_strategy: cost-based-routing
litellm_settings:
  # every request gets logged with cost, latency, and caller
  success_callback: ["langfuse"]

Then, in your editor or agent config, you point at http://localhost:4000 instead of calling Anthropic or OpenAI directly, and pick cheap-local, mid-tier, or frontier per task. Ollama pulls a model with one command:

docker compose up -d
docker exec -it <ollama-container> ollama pull qwen2.5:14b

For the visibility half, I paired this with Langfuse (also self-hostable via its own docker-compose) to get a running log of every call: model, tokens, cost, latency, who made it. It’s not “map spend to pull request rework” sophisticated, but it answers the first and most important question, which is simply: where is the money going, and could a cheaper model have done that?

This is roughly the shape of what Rippling built internally before they packaged it into a product. MacInnis mentioned their own benchmarking found that Z.ai’s GLM 5.2 was “85% cheaper” than frontier models “with nearly identical performance” on a lot of coding tasks. Whether you use GLM 5.2, a local Qwen or DeepSeek model, or Claude Haiku as your cheap tier is a matter of taste. The point is having a cheap tier and a router that actually uses it by default.

What you get, and what you don’t

+----------------------------+----------------------------+--------------------------------+
| Capability | Rippling AI Spend Console | LiteLLM + Ollama + Langfuse |
+----------------------------+----------------------------+--------------------------------+
| Cost-based model routing | Yes, built in | Yes, config-driven |
| Per-employee spend view | Yes, native to HR data | Possible, needs custom tagging |
| Spend vs. output | Yes, integrates with | Manual, you wire it to |
| (PRs, tickets, revenue) | GitHub/Salesforce etc. | GitHub/Linear yourself |
| Policy enforcement | Yes, by employee/role | Yes, via router config |
| Natural-language querying | Yes | No, build your own on top |
| Setup time | Minutes (SaaS) | An afternoon |
| Cost | Included w/ Rippling HR, | Free (self-hosted) or cheap |
| | or standalone pricing | (managed Langfuse Cloud) |
| Data stays in-house | No, vendor-hosted | Yes, fully self-hosted |
+----------------------------+----------------------------+--------------------------------+

The honest gap is the last row of Rippling’s feature set: tying spend to actual business output (pull request rework rates, revenue per rep, performance ratings) requires deep integration with your HR and engineering systems that a two-person DIY stack won’t casually replicate. That’s the part Rippling is actually selling, and for a company with hundreds of engineers and a real governance problem, it’s probably worth paying for.

The part I’m less sure about

Here’s where I’ll admit some doubt, because the TechCrunch piece raises it too: mapping individual AI spend to code-review rework rates is a productivity metric wearing a cost-control costume. It’s one click away from “your AI usage score is part of your performance review,” and Rippling, being an HR company, is exactly positioned to make that click. MacInnis said it outright: if they can’t tie token spend to output, “all bets are off on any of this stuff being available to the broader employee base.” Read plainly, that means non-engineering employees’ AI access could eventually depend on proving productivity, not just having a login.

For a small team or solo developer, none of that risk exists. You’re just trying not to blow your API budget on a model you didn’t need. For that use case, the LiteLLM/Ollama/Langfuse stack above gets you 80% of the value for free. For an org of Rippling’s size, with the accountability and privacy trade-offs that come with it, a purpose-built tool starts making more sense. You just want to go in with eyes open about what “visibility” actually means once it’s tied to HR data.

Either way, the underlying lesson doesn’t need a $50,000-a-month cautionary tale to be true: if you don’t know where your token spend is going, it’s already higher than it needs to be.

Tags: AI, LLMOps, FinOps, DeveloperTools, SoftwareEngineering, OpenSource, Rippling