Two numbers that don't fit in the same sentence. Ramp's AI Index tracks live spend data across its corporate card and bill-pay customers, and its June 2026 release put an exact number on something everyone building for enterprise AI already suspected: adoption isn't a curve clustered around an average, it's a cliff. The top 1% of firms spend $7,450 per employee per month on AI. The top 10% spend $611. The median firm spends $11.38. Source: Ramp AI Index, June 2026. That's a 680x gap between the frontier and the middle of the distribution, and the top 1% grew their per-employee spend another 14.1% in the most recent month alone. This isn't a market maturing toward a common number. It's a K-shaped adoption curve getting more K-shaped. Zoom into a single company and the same shape shows up again, one level down. SemiAnalysis spent 2026 talking to more than 50 enterprises about how they budget AI spend, and cited the same underlying Ramp data at the individual level: a 99th-percentile employee spends roughly $90,000 a year, while the median employee at the same kind of company spends $136. Source: SemiAnalysis, "TokenBudgeting: Our Conversations with Enterprises on Token Spend," 2026. That's a 662x gap, inside one org chart, between the person driving your AI ROI and the person who opened the tool twice last quarter. Two horizontal bar charts on a shared log scale: firm-level monthly AI spend per employee runs from $11.38 at the median firm to $611 at the top 10% to $7,450 at the top 1%, a 680x range; individual employee annual spend runs from $136 at the median to $90,000 at the 99th percentile, a 662x range. Put those two datasets side by side and the coincidence is the point: whether you cut it by firm or by employee, AI spend concentrates in the same narrow, extreme slice, and the rest of the distribution is close to flat. What every "AI budget cap" story is actually responding to. The headlines from earlier this year explain why enterprises reached for a cap in the first place. Meta employees consumed over 60 trillion tokens in a single month before the internal usage dashboard tracking it got shut down, with one individual accounting for roughly 280 billion of that alone. Uber exhausted its entire 2026 Claude Code budget four months into the year and responded with a hard per-engineer limit. Those are tail events, and a flat per-seat cap is the fastest lever an admin panel gives you to put a ceiling on a tail. The caps that actually shipped in response span almost the same 680x range as the spend itself: | Company or sector | Monthly per-employee AI budget cap | |---|---| | Aerospace and pharma manufacturers | $250–$500 | | Uber (per engineer, per tool) | $1,500 | | Cybersecurity firms, senior staff | $1,600–$4,000 | | Stripe, Workday | ~$2,000 | Source: SemiAnalysis, "TokenBudgeting," 2026, based on conversations with 50+ enterprises Read that table next to the percentile data above it and the pattern is hard to miss: the industry already intuits that one number can't govern everyone, which is exactly why cybersecurity firms tier their cap by seniority instead of setting one flat number company-wide. But SemiAnalysis's actual finding, from those 50-plus conversations, is blunter than the table implies: at most organizations, the majority of employees never come close to the cap at all. The ceiling exists for a sliver of the org chart and is invisible to everyone else. Why a flat ceiling can't fit a 680x curve. A dollar cap has exactly one degree of freedom: where you set the line. On a distribution this skewed, both directions fail differently. Set it near the median, and it does nothing, because the median employee is nowhere near it, $136 a year against a $2,000-a-month ceiling isn't a constraint, it's a rounding error. Set it near what the 99th percentile actually needs, and it stops being a company-wide policy and starts being a rubber stamp for whatever the heaviest users were already spending. Set it somewhere in between, which is what most of the caps in the table above actually are, and it throttles your highest-leverage AI usage, the workflows that justified buying the tool in the first place, while remaining completely irrelevant to the 90% of the org it was ostensibly written for. None of that is a governance failure so much as a mismatch between the tool and the shape of the problem. A cap fires after the model already ran, and it can't tell a power user whose heavy usage is producing proportionally heavy output from someone burning tokens on retries and bloated prompts. It governs how many expensive requests get made. It has no opinion on whether any individual one of them needed to be expensive at all. Find out which side of the line you're actually on. You don't need Ramp's dataset to know your own shape, your gateway or provider usage logs already have it. Group cost by user over the trailing 30 days and look at the ratio between your own p99 and median, not the average, which gets pulled toward whichever end has more dollars in it and tells you almost nothing about the shape underneath: -- Per-user spend, last 30 days, from LLM gateway or provider usage logs WITH user_spend AS ( SELECT user_id, SUM(cost_usd) AS spend_30d FROM llm_request_logs WHERE created_at >= NOW() - INTERVAL '30 days' GROUP BY user_id ) SELECT PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY spend_30d) AS p50_spend, PERCENTILE_CONT(0.90) WITHIN GROUP (ORDER BY spend_30d) AS p90_spend, PERCENTILE_CONT(0.99) WITHIN GROUP (ORDER BY spend_30d) AS p99_spend, MAX(spend_30d) / NULLIF(PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY spend_30d), 0) AS max_to_median_ratio FROM user_spend; If max_to_median_ratio lands anywhere near the 600x–700x range Ramp and SemiAnalysis both measured, a single flat cap is structurally the wrong instrument for your organization, whatever number you pick for it. What routing does that a cap can't. The fix isn't a better place to draw the line. It's replacing the question a cap asks with a different one. A cap asks "has this person spent too much yet," which only has an answer once someone is already near a threshold that was set for the wrong point on the curve. Routing asks "does this specific request need the expensive model," a question with the same answer whether it's the median employee's eleventh query this month or a power user's forty-thousandth: import openai client = openai.OpenAI( base_url="https://api.getnadir.com/v1", api_key="ndr_...", ) response = client.chat.completions.create( model="auto", # cheapest model that can handle this specific request messages=[{"role": "user", "content": prompt}], ) Nadir reads each request, routes it to the cheapest model that can handle it, and escalates to a stronger model only when a calibrated verifier flags the cheap model's answer as likely wrong. Because that decision runs per request instead of per person or per period, it doesn't need to identify who's in the tail to save money there. It saves a percentage off every request, which means it automatically saves the most absolute dollars from the accounts making the most requests, exactly where Ramp's and SemiAnalysis's data say the concentration actually lives. A cap has to find and throttle your 99th percentile on purpose. Routing saves money from your 99th percentile as a side effect of saving money from everyone. What to ship this week. Run the percentile query above against your own usage logs, not just the average. If you don't have per-user cost data at all, that gap is worth closing before setting any company-wide number. If your ratio is anywhere near 600x, stop treating one dollar figure as the fix. A tiered cap by role is a step in the right direction, but it's still capping request volume, not the cost of each request. Put a router in front of your heaviest accounts first. The math above says that's where the absolute dollars are, so it's also where a percentage-based saving compounds fastest. Keep spend visibility regardless. Percentile dashboards and threshold alerts are the right complement to routing, not a replacement for it, they tell you where the curve is; routing is what changes its shape. Conclusion. Two datasets, gathered independently, both land on almost exactly the same ratio: a 680x gap between the top 1% of firms and the median firm, a 662x gap between the 99th-percentile employee and the median one. That's strong enough agreement to treat the shape as real rather than an artifact of either sample. A flat per-seat dollar cap is a single point on a line trying to govern a curve that spans three orders of magnitude, and every enterprise that has actually tiered its caps by role has already conceded the point without saying so directly. The alternative isn't a smarter cap. It's a lever that acts on the request instead of the person, so it doesn't need to find your 99th percentile to save money there, it saves money everywhere, proportional to how much is actually being spent. Related reading. Meta capped employee AI spend after costs approached billions. Uber set a $1,500-per-engineer monthly limit. "Tokenminimizing" will not fix the unit economics. A 2,105-upvote HN thread calls it tokenmaxxing. At enterprise scale, it costs $2,700 per developer per month. Spend controls report cost after the fact and only for one vendor. Routing changes the cost of the next request across every vendor. 98% of FinOps teams now manage AI spend. Most still cannot see where the tokens go. Uber burned its 2026 AI budget in four months. Sources: Ramp, "AI Index," June 2026. SemiAnalysis, "TokenBudgeting: Our Conversations with Enterprises on Token Spend," 2026.