We Tried to Cut Our AI Bills. We Accidentally Built a Product.

An AI cost optimization story from the CTO of Binadox.

The future is AI-powered. The invoices are, too.

Let's be honest: these days, if your company isn't using AI, you're probably losing time to someone who is.
At Binadox, we're no exception.
We process huge amounts of data every day. Our engineers write code, analyze information, investigate problems, and automate workflows. AI has become part of how we work, not some shiny experiment we run on Fridays.
We use Codex, ChatGPT, Claude Code, and Claude chat. Different tools, different tasks, different models — all helping us move faster.
And for a while, everything was great.
Until our accountant came to us with a question no CTO wants to hear:

"Do you know how much we're actually spending on AI?"
Well... we knew we were spending money.
We just didn't know how much, where it was going, or whether we were getting enough value out of it.
Our AI adoption was growing. Our productivity was growing. And apparently, our bills had decided they didn't want to be left behind.

Phase 1: Let's just be more careful

Our first reaction was classic engineering optimism.
"We'll monitor usage more carefully. We'll pick cheaper models when possible. We'll stop wasting tokens. How hard can it be?"
Famous last words.
We asked the team to pay more attention to usage, check costs, review model choices, and optimize their workflows.
Soon, our engineers were doing two jobs:

1. Building products and processing data.
2. Playing financial detectives every time they used AI.

Should I use this model or that one? Is this prompt too long? How much did yesterday's experiments cost? Which tool is eating the budget?
Every optimization decision required time, attention, and context switching.
After about a month, we had an interesting result:

• Productivity: down.
• AI bills: stubbornly unchanged.
• Engineers' enthusiasm for manual cost tracking: approaching zero. We had managed to create a new problem while trying to solve the original one. We needed a different approach.

Phase 2: Surely, someone has already built this

We decided to stop reinventing the wheel. We asked one of our team members to investigate existing LLM monitoring and cost-management tools.
The mission sounded simple: find a solution that would give us cost visibility without turning every engineer into a part-time FinOps analyst.
We explored three options.

1. Langfuse

Langfuse offers LLM observability, tracing, token and cost tracking, and analytics. It's a strong option for teams that want to understand what's happening inside their LLM applications.
But our immediate problem wasn't just debugging individual model calls. We wanted a straightforward way to understand our AI spending across providers and make cost management part of our normal operations.
We didn't want cost optimization to become another engineering project that required more engineering projects.

2. Helicone

Helicone provides LLM observability, request-level insights, usage tracking, and cost analytics.
It was another promising option. But we were looking for a solution that fit our broader cost-management workflow, rather than introducing another specialized layer that our team would need to configure and maintain.
Our goal wasn't to collect more dashboards. It was to spend less time figuring out where the money went.

3. OpenLIT

OpenLIT caught our attention because of its open-source approach and self-hosting option.
That was appealing. However, running and maintaining another observability stack would still mean operational effort for our team.
We were trying to reduce the overhead of managing AI costs, not add another system to our maintenance backlog.
To be clear, these are not bad tools. Each solves real problems, and the right choice depends on your architecture and requirements.
They simply didn't give us the exact combination of simplicity, cost visibility, and integration into our existing workflow that we wanted.

Then another month passed.
The result?
Our bills hadn't meaningfully changed. Our colleague had spent weeks researching and evaluating tools. And we were still discussing AI costs instead of automatically managing them.
At this point, we had two options: keep searching or do what engineers sometimes do when they get sufficiently frustrated.
Build the thing ourselves.

Phase 3: Fine. We'll build our own.

There is a particular moment in every engineering project when someone says:
"This should be a small internal tool."
Everyone experienced knows what happens next.
The scope grows. Edge cases appear. Integrations need attention. Data needs to be normalized. Dashboards need to make sense. Suddenly, the small tool has a roadmap.
Our project was no exception.
But this time, we had a clear goal: make AI spending visible and manageable without requiring engineers to babysit it.
We built LLM Cost Tracker as part of Binadox.
The idea was straightforward: collect usage and cost information from supported LLM providers, bring it into one place, and make it easier to understand where the budget goes.
Instead of manually comparing separate provider dashboards, we wanted a unified view.
Instead of discovering a spending spike when the invoice arrived, we wanted alerts.
Instead of guessing which models or workloads were driving costs, we wanted data that could guide optimization decisions.
The result evolved into a tool for monitoring and optimizing LLM spending across supported providers, including OpenAI, Google Vertex AI, Azure OpenAI, and AWS Bedrock.
It brings together usage and cost analytics, provider and model comparisons, anomaly detection, budget alerts, and cost-optimization capabilities.
The most important part wasn't the dashboard itself.
It was getting our engineers out of the business of manually monitoring every AI dollar.
We wanted people to focus on solving customer problems, not constantly switching between code editors, AI chats, and billing pages.

Phase 4: Wait, this could help our customers, too

This was the unexpected part.
We had started with a very internal question:
"How do we stop our AI costs from growing without slowing down our team?"
But as we worked on the solution, it became clear that this wasn't a problem unique to Binadox.
Any company adopting AI at scale can run into the same challenge:

• Developers adopt new AI tools faster than finance teams can track them.
• Different providers report usage and costs in different places.
• Teams experiment with models without always understanding the financial impact.
• Manual reviews consume time that could be spent building products.
• Spending surprises arrive at exactly the wrong moment. Our internal headache had become a potential source of value for our customers. That's one of the best things about building software: sometimes the most useful product ideas come from the problems you experience yourself. We already had experience with cloud and SaaS cost management at Binadox. Applying that mindset to LLM spending was a natural extension of what we were doing. And we didn't need to introduce another standalone subscription just to solve our own problem. LLM Cost Tracker became part of our existing Binadox platform. One problem solved internally. A new capability for customers. And one less reason to spend Friday afternoon investigating an unexpected bill. I'll call that a reasonable return on frustration.

What we learned

Looking back, there are a few lessons I'd share with other CTOs and engineering leaders.

1. AI productivity doesn't automatically mean AI efficiency

AI can make your team faster while making your technology spending harder to predict.
The question isn't whether AI is worth using. It's whether you understand the relationship between its cost and the value it creates.

2. Manual cost optimization doesn't scale very well

As usage grows, asking engineers to monitor every token, model choice, and invoice becomes increasingly expensive in terms of human attention.
The people using AI shouldn't have to become full-time analysts of their own AI usage.

3. Visibility comes before optimization

You can't reliably optimize spending you don't understand.
Before changing models or restricting usage, you need to know which providers, models, teams, and workloads are driving the cost.

4. Don't build everything — but don't ignore your own requirements

Existing tools deserve serious consideration. Building your own solution has costs, too: development time, maintenance, and ongoing responsibility.
But if you repeatedly find yourself working around the same limitations, it's worth asking whether the missing capability is actually important to your business.

5. Your internal tools can become customer value

We didn't set out to launch a new product. We wanted to stop wasting time and money.
The fact that the solution could help our customers facing similar challenges was a welcome bonus.

The punchline

We started using AI to save time.
Our AI bills grew.
We tried to optimize manually and lost time.
We spent another month evaluating tools and lost more time.
Then we built a tool to stop losing time.
Engineers are a funny species. Sometimes we spend weeks automating something that would take five minutes to do manually. Sometimes we build an entire product because we don't want to open one more billing dashboard.
But sometimes that stubbornness creates something genuinely useful.
For us, that became Binadox LLM Cost Tracker.
The lesson isn't that every company should build its own cost-management platform. Quite the opposite.
Use AI to move faster. Use cost visibility to make sure moving faster doesn't mean spending blindly.
And if your accountant asks how much you're spending on AI, try to have an answer before the next invoice arrives.
Trust me on this one.