For the last three months, I have been warning the Claris ecosystem about a hidden mathematical reality in the transition to AI-assisted coding: The Token Tax.
Yesterday, a report from Fortune and Yahoo Finance proved exactly why this matters at an enterprise scale.
According to the report, Microsoft has begun actively canceling internal Claude Code licenses for its own engineers. Uber’s CTO admitted that they burned through their entire 2026 AI coding budget in just four months. Bryan Catanzaro, VP of applied deep learning at Nvidia, bluntly stated: “For my team, the cost of compute is far beyond the costs of the employees.”
If the richest technology companies on earth are hitting a financial wall trying to deploy Agentic AI, the FileMaker community needs to pay very close attention to why it is happening—and how it affects our platform.
The Agentic Token Paradox
We are transitioning from “Autocompletion” to “Agentic Workflows.” Instead of an AI just writing one line of code, an AI Agent reads your entire codebase, reasons about a problem, attempts a fix, reads the error log, and loops back to try again.
This creates the Agentic Token Paradox: Even as the cost of individual AI tokens drops exponentially, the consumption of tokens in an agentic loop rises at a staggering 24x multiplier.
When you run an autonomous agent on a standard text repository (like Python or Node.js), the LLM is reading thousands of tokens per second to maintain context. That is expensive.
Now, apply that exact same workflow to FileMaker.
The FileMaker Multiplier
FileMaker is not a text language; it is a binary state machine that expresses its code via the clipboard as highly verbose XML (fmxmlsnippet).
Through extensive benchmarking during the development of ai2fm, we proved that FileMaker XML carries a 5.6x token bloat compared to standard scripting languages.
If Microsoft and Uber are blowing their annual budgets trying to run agents on clean, concise Python code, imagine the absolute financial disaster of trying to run an autonomous reasoning loop on raw FileMaker XML.
The community’s current approach to this problem is to use “prompt hacking.” Just this week, a prominent FileMaker developer released an open-source Claude dictionary containing 2,900 lines of instructions just to teach an LLM how to format FileMaker XML tags. In his own release notes, he admitted he had to delete his validation suite just to get the prompt to fit inside the LLM’s context window without maxing it out.
If you have to feed an LLM a 2,900-line dictionary plus 5.6x bloated XML code every single time an autonomous agent runs a reasoning loop, you are not writing software.
You are setting your API billing account on fire.
Compilers are the Only Scalable Path
Optimization cannot outrun understanding. If we want to bring true Agentic AI to the Claris ecosystem, we cannot pass raw XML through MCP servers and hope for the best.
The token tax will quite literally bankrupt the workflow.
This is exactly why we built the .fmscript deterministic compiler and the https://ai2fm.com/ VS Code extension.
We don’t try to teach the AI how to read XML. We use a centralized Node.js XSLT engine to completely strip the 5.6x XML bloat away before it ever reaches the LLM. The AI receives a clean, dense, native text syntax (.fmscript). It reasons, it refactors, and it writes code at a fraction of the token cost. When the AI is done, the compiler deterministically transforms the text back into the exact XML payload the FileMaker clipboard requires.
You achieve 100% bidirectional reliability at a fraction of the API cost.
The era of fragmented XML clipboard hacks is over. The cost of compute demands a unified text standard.
The standard is here https://fmscript.org/. It is time to start building with it.
