Every AI spend tracker vendor will tell you they offer visibility, attribution, and cost optimization. These claims are not false. They are also not differentiating. Asking a vendor whether their product provides visibility is like asking a car manufacturer whether their vehicle has seats. The interesting question is not whether the feature exists. It is how it was built and what breaks when the organization scales.

The enterprise computing market of the 1960s had the exact same dynamic, and IBM's dominance came from answering the architectural questions its competitors were not being asked. Choosing an AI spend tracker vendor today requires asking the same kinds of questions that separated IBM from the field in 1965.

The Mainframe Vendor Problem

In the early 1960s, Burroughs, UNIVAC, Honeywell, GE, RCA, and NCR all competed with IBM for enterprise data processing contracts. Every vendor claimed their systems handled the same core functions: payroll processing, inventory management, order tracking, financial reporting. The feature lists looked similar. The marketing language was nearly identical.

IBM's eventual dominance, achieving roughly 70% market share by the late 1960s, did not come from having the most impressive individual components. It came from having thought harder about what large organizations actually needed when their data processing operations scaled. Consistent data formats across different departments. Reliable integration between systems that had not been designed to talk to each other. Enterprise-scale reliability that held up when the entire organization depended on it simultaneously.

IBM's competitors had optimized for specific use cases and impressive demos. IBM had optimized for the architecture that would still work five years after the purchase decision, when the use cases had multiplied and the scale had grown by an order of magnitude. The architectural decisions IBM made when no one was watching were the ones that mattered.

The AI spend tracker market is in the same position today. Every vendor can produce a demo that shows attribution. The question is what architectural decisions they made that determine whether that attribution holds up at production scale, when your team is running millions of calls per month across four vendors with a taxonomy that has evolved three times since you went live.

5 Questions to Ask Any AI Spend Tracker Vendor Before Signing

  1. How is attribution attached at the call level? The critical question is not whether the vendor tracks calls. It is how. Some AI spend trackers intercept at the SDK level, wrapping your AI client library to capture every call before it goes out. Some intercept at the network level, acting as a proxy between your application and the AI provider. Some rely on you to instrument your code manually and send events to their API. Each approach has different failure modes. SDK-level interception breaks when you upgrade the underlying library. Proxy-based approaches add latency and create a new dependency in your critical path. Manual instrumentation requires engineering discipline to maintain as the codebase evolves. Ask the vendor which approach they use, why they chose it, and what happens to your attribution data when their component has an outage.
  2. Does the system normalize across vendors? If you use more than one AI provider today, or plan to, this question is not optional. Ask the vendor to show you a specific example: one organization using both Anthropic and OpenAI, with usage data from both providers displayed in a single view with normalized cost-per-output metrics. Not a diagram of how this would work in theory. A live example or a recorded demo of actual multi-vendor normalization. Vendors who have not actually built multi-vendor normalization will give you a diagram. Vendors who have built it will show you data.
  3. What happens when a workflow spans multiple models? Most production AI features are not single model calls. They are pipelines: an embedding model for retrieval, a small model for classification or routing, a large model for generation, sometimes a reranking step. The cost of the user-facing action is the sum of all of these. Ask the vendor how they aggregate cost across a multi-step workflow and what the developer has to do to enable that aggregation. If the answer requires significant manual instrumentation, the attribution will degrade as the codebase grows and engineers forget to tag new calls. A good AI spend tracker automates as much of this aggregation as possible.
  4. How does the system handle cost data that is not available at call time? Some AI providers return token counts in the API response synchronously. Others return them asynchronously, or only in the billing API with a delay. Some vendor pricing changes retroactively for batch processing jobs. An AI spend tracker that assumes all cost data is available at call time will have gaps for providers that do not work that way. Ask the vendor explicitly: what happens when cost data is delayed or not available at the time of the API call? The answer tells you how carefully they have thought about the edge cases that will eventually affect your organization.
  5. What does the data model look like when your AI usage is 10x what it is today? This is the IBM question. IBM's competitors built systems that worked well at the scale their customers were currently operating. IBM built systems designed for the scale their customers would reach. Ask the vendor: at what volume does their system require architectural changes? How does pricing scale with usage? What changes about the data model when you go from 1 million calls per month to 10 million? A vendor who has not thought about this will give you a vague answer about their infrastructure being scalable. A vendor who has thought about it will give you a specific answer about where the architectural limits are and what they have done to address them.

What the Vendor Claims Cannot Tell You

The three claims you will hear from every AI spend tracker vendor, visibility, attribution, and cost optimization, are table stakes. They tell you what the product does in a demo environment with clean data and a single AI provider. They do not tell you what happens when your taxonomy has exceptions, when a provider's API changes, when a workflow gets refactored, or when the engineering team that originally instrumented the system turns over.

The architectural questions above are designed to surface how the vendor thought about these scenarios before they happened to you. IBM won the mainframe market not by being loudest or cheapest but by being the only vendor whose architecture had already accounted for the problems their customers had not encountered yet. You want an AI spend tracker built by a team that has thought about your future problems, not just your current ones.

Reference calls are valuable but limited. Ask specifically about the moment something broke: a vendor API changed, a new model was added, the taxonomy had to be restructured. How the AI spend tracker handled those transitions tells you more about its durability than any demo of steady-state operation.

Frequently Asked Questions

What should I look for in an AI spend tracker vendor?

Look for four things: multi-vendor normalization that is demonstrated with real data, not diagrams; call-level attribution that does not require extensive manual instrumentation to maintain; a data model designed for 10x your current scale; and a clear answer about how they handle cost data that arrives after the fact. Beyond these, look at how the vendor talks about failure modes. A vendor who can clearly articulate what breaks in their system and how they have mitigated it has thought more carefully about production reality than one who claims everything works perfectly.

Is Oberhahn an AI spend tracker?

Yes. Oberhahn is an AI spend tracker built specifically for engineering organizations running AI features in production across multiple vendors. It handles call-level attribution, multi-vendor normalization, workflow cost aggregation, and dual-audience reporting for both engineering and finance. The architecture is designed for organizations that are scaling AI usage significantly and need attribution data that remains accurate as the model mix, vendor set, and team structure evolve. The five questions in this post are the questions Oberhahn was built to answer correctly.

What is the difference between a free and paid AI spend tracker?

Free AI spend trackers typically cover a single vendor, provide limited attribution depth, and do not support multi-audience reporting. They work well for small teams with simple usage patterns and a single AI provider. Paid AI spend trackers add multi-vendor normalization, workflow-level cost aggregation, shared attribution taxonomies, finance-facing reporting, and the architectural durability required for production scale. The right choice depends on how many vendors you use, how complex your AI feature set is, and how much organizational trust the data needs to carry. When the AI spend tracker data influences budget decisions, the accuracy and reliability of a paid solution becomes worth the cost quickly.

How does an AI spend tracker handle attribution for autonomous agents?

Autonomous agents generate variable, often unpredictable numbers of model calls per task. A well-designed AI spend tracker handles agent attribution by tagging each model call with both the agent identifier and the initiating user action or trigger, then aggregating all calls within an agent run into a single workflow cost. This requires the agent framework to propagate a run identifier through each model call it makes. Most modern agent frameworks support this through context propagation mechanisms. Ask any vendor how their AI spend tracker integrates with your specific agent framework and what happens when an agent spawns sub-agents or hands off to other agents.

Can an AI spend tracker work across OpenAI, Anthropic, and Cursor simultaneously?

Yes, a production-grade AI spend tracker should handle all three simultaneously and normalize their costs into a single view. OpenAI and Anthropic are standard inference API providers with well-documented token pricing. Cursor is a development tool that uses AI under the hood, and tracking its costs requires integrating with Cursor's usage reporting rather than intercepting API calls directly, since your application does not make Cursor's model calls. Any AI spend tracker claiming to cover Cursor should be asked specifically how that integration works, because the data path is different from standard inference API attribution.

The Architecture That Works at Scale

Oberhahn was built around the same principle as IBM's enterprise systems: attribution architecture that holds up at production scale, multi-vendor normalization that does not require a diagram to explain, and a data model designed for organizations that will use significantly more AI next year than they do today. The five questions in this post are the ones Oberhahn would ask if evaluating a competitor. They are worth asking of any vendor, including us.

The AI spend tracker market will consolidate the way the mainframe market did. The vendors that built for scale and thought carefully about the problems their customers had not encountered yet will be the ones that survive that consolidation. Choose accordingly.