A prototype that shows knowledge workers what their AI workflows would cost if unlimited usage became a real monthly budget, and whether those workflows fit inside it.
Most knowledge workers using AI tools today are not paying for them directly. The cost is absorbed by an employer, a flat-rate subscription, or a pricing tier generous enough that it rarely registers. That situation is starting to change, though not uniformly.
Ramp's June 2026 AI Index puts median corporate AI spend at $11.38 per employee per month. The top ten percent of companies spend $611. The top one percent spend $7,500. For most people, there is no budget cliff. But for engineering organizations running agentic coding workflows (e.g. Claude Code, Codex, Cursor) the numbers are already in a different tier, and as agentic usage spreads beyond early adopters, that will become a much broader problem.
The deeper problem is that most of this spend is invisible. Flat-rate subscriptions absorb the cost. When enterprises eventually move to API pricing, usage that felt free becomes a line item, and most teams will have no concept of what they're spending or how it breaks down.
Product Approach
AI Expense Report is a fictional demo: a seeded report for a named persona (Alex, in seven different roles) showing what a realistic AI workweek would cost at current market pricing. The app makes no real integrations with Claude, Cursor, or any AI tool. What it does is give someone a place to look at their workflows as a budget, not a convenience.
The budget cliff simulator is the signature feature. It lets someone drag a slider to a hypothetical monthly budget and see, by category, which workflows fit and which don't. The developer persona at a $50 budget is the most dramatic example: agentic coding alone runs $173 against a $50 budget, before the other categories have even entered the frame.
Screenshots
Setup: choose your role and the app seeds a realistic AI workweek for that persona.Report: the Developer persona at $50/month — Agentic / deep work alone runs $173, more than three times the budget.Budget cliff simulator: drag the slider to a hypothetical budget and watch categories drop in or out, in priority order.
Where It Could Go
This fictional demo is a validation step. The real version of this app would read actual usage data.
The natural starting point is a Claude Code plugin. Claude Code already has the session context: which prompts ran, how many tokens each consumed, what kind of task it was. A plugin could capture that data locally and feed it into a report like this one (automatically categorized, accurately priced, updated in real time). The equivalent integrations exist for Codex and Cursor, which expose similar usage metadata through their APIs.
With real prompt context, the app could do something the fictional demo can't: categorize usage automatically rather than relying on self-reported workflow tags. A session that involved reading files, running tests, and iterating on a component is different from one that involved a single code generation request, and the context behind each prompt tells you more than the token count alone can.
That's also where the hard problems begin. Prompt content is sensitive — it contains code, business logic, and potentially confidential context. Any real integration would need to process that data locally, never transmit it, and give the user clear control over what gets logged. The architecture is closer to a local dashboard than a cloud sync, which is probably the safer approach anyway.
The goal is something like Mint.com for AI spend: a clear, categorized view of where your token budget goes, built from the data that already exists in the tools you're already using.
The bug that taught me the most
Late in the build, one interaction froze the whole browser tab: opening the budget slider and dragging it would pin the CPU and lock up, sometimes taking every other tab down with it. It only happened on a real machine with a real mouse, never in automated testing, which made it maddening to chase.
I was building and debugging with an AI agent, and it spent a long time guessing: it swapped out a UI library, removed animations, theorized about the graphics card. Every fix was plausible and none of them worked, because the agent could not reproduce what I was seeing. I kept letting it try one more idea.
What finally solved it was stepping in myself. I opened the browser's debugger, paused the page mid-freeze, and handed the agent the one thing it could not get on its own: a snapshot of exactly where the code was stuck. From there the root cause was obvious and the fix was quick.
The lesson stuck with me more than the bug did. When a tool cannot reproduce a problem you can, more clever guesses are not the answer. The fastest path is to step in and give it real evidence from the environment where the problem actually lives. I waited too long to do that. A few minutes of hands-on debugging would have saved hours.
