TokenSpend Review: The AI Coding Router That Ties Spend to Shipped PRs

Every engineering team that's rolled out Claude Code, Cursor, or Cline in the last twelve months has run into the same finance conversation: 'we're spending $X on AI coding — is that working?' The honest answer, until now, has been 'we're not sure.' Existing AI observability and routing tools (Helicone, Langfuse, OpenRouter, LiteLLM) do a good job of showing spend per model, per API key, per user — but none of them can tell you whether the call that cost you $2.30 in Sonnet tokens ended up in a merged PR or in a dead branch you abandoned two hours later. TokenSpend closes that gap. It's a router that sits in front of every model call your team makes, but the interesting part is what it does with that data downstream: it uses a GitHub App to resolve each session back to a branch, then to a SHA, then to the pull request that shipped (or didn't). The result is a spend view where every dollar has a confidence rating — Shipped (HIGH), In-flight (MED), or Unmatched (LOW) — repo by repo, model by model. For teams that have been guessing at AI coding ROI, that's the first time the number stops being a vibe.

The router itself is the easy part. TokenSpend exposes an OpenAI-compatible `POST /v1/chat/completions` endpoint at `https://api.tokenspend.dev`, and every OpenAI SDK — Python, JavaScript/TypeScript — works with a single base-URL swap. If your team is already on Cline, Kilo, or aider, the same swap applies. For Claude Code, the migration is two environment variables (`ANTHROPIC_BASE_URL` pointing at TokenSpend, `ANTHROPIC_API_KEY` set to your rail key), and streaming, tool use, image inputs, and prompt caching all pass through unchanged. There's no proprietary SDK, no code refactor, and no lock-in beyond flipping the env var back if you want to leave. Under the hood, the router covers 52 models across 14 vendors: Anthropic Claude, OpenAI GPT, Google Gemini, Meta Llama, xAI Grok, DeepSeek, Moonshot, Mistral, MiniMax, Z.ai, Nvidia, Alibaba, and Thinking Machines. Most models support image inputs (the Images column in the router-docs table is the authoritative reference). Context windows span 128K to just over a million tokens; provider pricing runs from $0.02 per million input tokens at the low end to $50 per million output tokens at the high end, and is passed through at list — no markup. Rate limits sit at 100 requests per minute per rail key, keys are hashed and shown once, and revocation is instant.

The observability layer is where TokenSpend stops looking like an OpenRouter competitor and starts looking like something new. The GitHub App is the whole thesis: once installed, TokenSpend links each router session back to the git branch that was active when the call was made, then walks that branch forward to the SHA it merged into (or didn't), and attributes the spend to the resulting pull request. That one mechanic produces the report every engineering leader wants: 'of the $8,400 we spent on Claude this month, $6,200 shipped in 47 merged PRs across 12 repos, $1,100 is in-flight in open PRs, and $1,100 is unmatched — branches abandoned before merge.' You can slice it by model, and the picture usually gets interesting fast: it's common to discover that the model you're spending most on isn't the one that ships most of your code, and the argument for switching to a cheaper model on a specific workload becomes a data question rather than a religious one. Attribution is aggregated at the team and repo level, not the engineer level — a deliberate design choice to keep TokenSpend from becoming a productivity leaderboard that discourages exploratory or throwaway work. For teams that need finance-side reconciliation, audit exports drop out cleanly for month-close.

For any tool that sits in the middle of your model calls, the data-handling posture is the first thing a security-conscious buyer will ask about. TokenSpend's answer is spelled out clearly on the site: 'Token counts, timestamps, and git refs leave the machine. Your prompts, code, and transcripts never do.' Only metadata (usage counters, model IDs, request/response byte counts, git SHAs) is stored server-side; the actual prompt payload and completions stream through and are not persisted. Data retention runs to 30 days by default with a one-click zero-data-retention mode — useful for teams working under strict client contracts. Authentication accepts either `x-api-key: tsr_…` or `Authorization: Bearer tsr_…` headers (both equivalent, no functional difference). SSO ships on the Enterprise tier today; SOC-2 is on the near-term roadmap rather than certified yet. For teams that need SOC-2 in place before rollout, the zero-retention mode plus the audit-export path are a workable bridge until the certification lands.

TokenSpend's current commercial model is unambiguous: routing is free, monitoring is free to try, and there's no markup on BYOK — the token bills go to your Anthropic, OpenAI, or Google account at list price. That makes the first-week evaluation trivial: install the GitHub App, swap the base URL in your engineers' Claude Code or OpenAI client config, and by the end of the week you'll have your first shipped-vs-burned breakdown across the repos you shipped in. The caveat is that paid Enterprise pricing isn't public yet. SSO ships on Enterprise now; custom retention windows and the SOC-2 certificate that will finalize the enterprise story are dated to the near-term roadmap without published pricing. For teams evaluating today, that's actually a low-risk position — the free product is functional today, and the paid features get priced in due course. For teams that need a locked-in enterprise contract with certified compliance before rollout, waiting for the SOC-2 milestone is the honest recommendation.