TL;DR: Agentic development is accelerating software delivery, yet evolving models and pricing make AI spend difficult to understand, attribute, and forecast. MojoTech is addressing that challenge by treating AI cost intelligence as a data engineering problem: standardizing attribution across users, workspaces, and clients; ingesting disparate usage metrics from providers and transforming them into a unified dataset; and surfacing dashboards and daily alerts that helps our team achieve model rightsizing for the task at hand without turning token counts into leaderboards. Built on Databricks, our approach is also the foundation for a forthcoming Databricks Brickbuilder Partner Solutions offering for organizations looking to manage similar multi-provider AI utilization and cost analytics.
How we are balancing faster software delivery with responsible AI spending
AI-assisted development at MojoTech has evolved from experimental to standard practice. For more than a year, it has been an integral part of how we design, build, test, and maintain software. Like many experienced engineers, we initially approached generated code with caution. The skepticism was useful. AI can produce convincing but incorrect answers, miss important context, and introduce subtle design flaws. In late 2025 and early 2026, however, the tools became more generally applicable and expensive enough that spending could no longer be left to chance. Today, we use AI to accelerate research, reach a shared understanding, explore different implementations, and rapidly iterate through test-driven development. Work that once required writing every line of code from scratch or starting from an existing point now increasingly involves directing agents, refining their output, and reviewing the results. This change shortens delivery cycles and shifts the deployment bottleneck to quality control.
Experience matters more than ever. The value of more than a decade of technical expertise is the ability to recognize when an AI-generated solution is fundamentally wrong, unnecessarily complex, or unsatisfactory to requirements. The shift has created a second challenge: when unconstrained, AI usage can also make software delivery unexpectedly expensive.
Capability and cost are rising together
Agentic software development increased sharply as more capable models arrived. Notably, Claude Opus 4.5 in November 2025 and GPT-5.3-Codex in February 2026 helped move coding agents from occasional assistants to a regular part of the development workflow.The economics of these tools go beyond a simple price per token. Total cost depends on the model, input and output pricing, the size of the working context window, whether input is cached or uncached, the amount of reasoning or test-time compute, repeated tool calls and agent loops, and the number and duration of concurrent tasks.
An efficient model may be sufficient for simple tasks, while a frontier model is justified for architectural work. Using the most expensive model for every task, however, can increase cost without necessarily producing a corresponding improvement in quality.
Agentic workflows amplify this effect as a developer is no longer sending a single prompt and receiving a single response. An agent may inspect a repository, search files, run commands, test and revise its approach, and then repeat the process. Each step consumes additional context and tokens. A single developer’s daily usage can therefore increase from a modest amount to hundreds of dollars when the task at hand, the model, and the context do not play well together.
e.g., An agent ran up a $100 bill in an hour trying to brute-force a failing test suite before we implemented boundaries.
At scale, that variability makes AI spending difficult to forecast. Adoption is not the metric. Additionally, upcoming models are increasingly expensive, with Fable 5 costing 10 times more per input and output token than Haiku 4.5.
e.g., Using Fable to write documentation is unnecessary and costly.
Instead, the practical goal is to find the middle ground. Within model providers, we want to optimize model rightsizing for the task at hand. For instance, using Claude Sonnet 4.6 for unit tests and Opus 4.8 for system tests. This practice maximizes the value delivered by AI while keeping its cost observable, explainable, and within an intentional budget.
Attribution requires deliberate boundaries
Before we could manage AI costs, we needed to understand where they originated.
We assign API credentials at useful accounting boundaries. Depending on the work, that means a key associated with an individual is always tied to a workspace: internal or client engagement. To effectively understand and evolve how we use LLMs in our development process and product offerings, we realized we needed to be more organized in how we generate keys, namespaces, and name keys.
These boundaries are part of responsible data governance. Client work must use approved providers, models, credentials, and retention settings that satisfy the client’s requirements. Model selection and approval involves answering several key questions:
- Provider: What data will be sent and what retention and training policies apply?
- Access Control: Is this credential approved for this specific client and purpose?
- Attribution: Can the resulting usage be tracked and attributed correctly?
We therefore made workspace and credential setup part of project onboarding. Workspaces are what you would expect: a way to sequester certain related key usage. Meanwhile, API key aliases follow a consistent naming standard:-
- Development: {org}_{project}_{username}_dev
- Product: {org}_{project}_{username}_{purpose}_product
This convention lets us reliably connect usage to an organization, project, person, and environment. For example, MojoTech allocates 5 focused hours per week to skill development and continuous learning. All internal Mojotime-related usage is tied to a mojo_mojotime_{username}_dev key to ensure internal costs are tracked separately.
The risk we want to avoid is accidentally using an unrelated API key for the wrong project. That creates critical billing, security, IP, and data-governance problems.
One remediation is to use the command-line tool direnv to manage environmental variables at the per-project level, where each project includes a .envrc.sample file with a directive to unset each LLM API key.
e.g. unset OPENAI_API_KEY
From there, an individual must set the key in the project .envrc file; it will override any default keys when they enter the directory and require them to approve the variable settings.
Project keys are for use in deployed or shared environments (staging, production). Instead, we store these in a secret manager and rotate them on a defined schedule. If these are for a client, it is best if they provide them directly.
Building a unified view in Databricks
The major AI platforms expose usage and billing data differently. The available dimensions, reporting delays, model names, pricing structures, and data schemas vary across Anthropic, OpenAI, OpenRouter, and other providers. Permissions vary for engineers across platforms and workspaces, with multi-page dashboards specific to each provider. These provider disparities meant that reconciliation was manual, arduous, and error-prone.
We parameterized the disparity, using Databricks to build automated daily fetch jobs from repeatable abstractions and base classes. This approach facilitates robust, independent, and exhaustive data accumulation. Our implementation guardrails ensure idempotency, deduplication, and historical data retention and loss prevention.
Data was curated intentionally by following the medallion architecture data model, which allows us to incrementally improve data quality and structure, creating consistent and comparable data. This structure lets us maintain source fidelity while presenting a normalized view across providers ready for refined business intelligence and machine learning analytics.
The result supports two primary reporting experiences, each attached to an AI intelligence layer for custom queries.
The management dashboard presents cumulative usage for each provider and model, allocation by workspace and project, cost trends, and ML-powered forecast spending. Its purpose is to help leadership understand the current run rate and plan for future demand.
The developer dashboard provides a more granular view of individual usage across platforms. Engineers can inspect trends over time, understand which models account for their spending, and identify unusual changes in their own workflows.
We also connected the reporting layer to Slack. Each day, a summary of recent usage and an appropriate team-level comparison is sent to provide a short feedback loop, making the information actionable. Weekly, tech leads receive a team spend breakdown, giving each hierarchy level in the organization appropriate visibility to reconcile AI usage with deliverables and productivity
Usage reporting creates legitimate concerns. Individual metrics can easily be misread, stripped of context, or turned into performance rankings. This is not the purpose of this system. We are not building an AI leaderboard. The purpose is to give everyone visibility into the resources they use so they can make informed decisions. The same principle applies to management reporting. A large increase may represent a difficult production incident, a valuable research effort, or a complex delivery milestone.
What we have learned
Several conclusions are already clear.
- Agentic development is becoming a durable part of software engineering.
- More capable agents can consume far more tokens, and the most powerful model is not automatically the right model.
- Per-user, per-workspace, and per-client attribution must be designed into the system.
- Transparency is more effective than simplistic rankings or arbitrary limits.
- Forecasting requires normalized data across providers, models, and pricing periods.
The central question is how we can preserve momentum while making usage governable and spending predictable.
Our answer is to measure AI usage, make it visible, and give our team the context to act.
Databricks was a practical solution for us because this is fundamentally a data engineering problem. In 2025, MojoTech became a Databricks solutions partner, now powered by our certified Data Engineering Associates and Professionals. With our growing expertise, we’ve leveraged the Databricks platform to ingest records from multiple providers, apply repeatable transformations, and serve both detailed analysis and executive reporting. The medallion architecture makes the pipeline easier to validate and extend as providers, pricing models, and requirements change. The resulting dashboards are only as valuable as the data is clean, so establishing trust in our data integrity was a top priority.
MojoTech is preparing a Databricks Brickbuilder Partner Solutions offering for organizations that need similar multi-provider AI usage, cost monitoring, and analytics. As these tools change, how we use them does too, so it is key to understand the impacts day-to-day and over longer time periods. For readers interested in the underlying architecture, connectors, transformations, forecasting, and governance model, we will also publish a detailed technical implementation guide.