We built a small internal dashboard with FutureX in three days. The dashboard itself was unremarkable — a status board, a few API integrations, and a Postgres view. What was remarkable was the token bill. Input tokens were roughly 2.4x what the task should have required, and output tokens were almost 3x. This post is a transparent account of where those tokens went, the three mistakes that inflated the cost, and the specific workflow changes that brought subsequent work down to a sane level.
If you are using an AI coding agent for internal tools, the dollar amount per million tokens matters less than the ratio of useful tokens to wasted tokens. FutureX surfaces a per-run breakdown of model calls, tool calls, and context size, which made the waste visible. Here is what the numbers looked like and what they taught us about prompt engineering and cost optimization.
The Project: A Simple Internal Dashboard
The tool was a read-only operational dashboard for our support team. It needed to: pull deploy status from our CI provider, show open incidents from the ticketing API, overlay recent error rates from the metrics store, and render all of it in a single-page React app with a tiny Express backend. The entire thing is about 1,900 lines of code including styles.
We used FutureX with fx-pro for the initial scaffold and architecture, then fx-fast for the bulk of the implementation. Total wall-clock time was about nine hours spread over three days. The token usage was the interesting part.
Source: marketplace.visualstudio.com
Here is the honest accounting:
- Input tokens: ~4.1 million
- Output tokens: ~680,000
- Context cache reads: ~2.9 million (these are cheaper but still not free)
- Total: the equivalent of roughly $38 USD with the standard FIM pricing tiers we were using (your mileage varies with
fx-ecovsfx-pro)
We estimated the same project should have cost $14–$16. So we paid roughly 2.4x what was necessary. The worst part is that none of the waste was malicious or even surprising — it was all structural. Three specific mistakes accounted for almost all of it.
Breaking Down the Token Bill
Before getting to the mistakes, it is worth understanding where tokens actually go when FutureX builds a project. The bill is not just "your prompt in, the code out." There are four major consumptive channels.
1. Context loading and re-reading
Every time FutureX opens a file, reads a directory, or greps for a symbol, those tokens land on the input side. Early on, we let FutureX re-scan the entire project on nearly every task. That meant reading the same package.json, the same schema file, and the same component tree over and over. In our final breakdown, roughly 38% of all input tokens were repeat reads of files that had not changed.
2. Tool call overhead
Each tool call carries structured overhead: the function name, arguments, and results. When the agent runs read_file on a 400-line file, the file content is one thing, but the wrapper around it adds tokens on both input and output. Small tool calls are cheap; thousands of them are not.
3. Output regeneration
When a prompt is ambiguous, FutureX often produces a plausible but wrong implementation, and the fix is a full regeneration. Output tokens are typically 3–4x more expensive per token than input tokens on most pricing tiers. This is where the bill really inflates. Near the end of day one, we had generated roughly 900 lines of code that we later deleted — at output token prices.
4. Context cache costs
FutureX does automatic context caching, which helps a lot. The first time you send a large context that includes your repo map and instructions, that is a full input bill. Subsequent runs that reuse that prefix hit the cache read rate, which is cheaper. But cache reads are not free, and a poor workflow can invalidate the cache constantly by appending huge amounts of irrelevant history.
Source: blog.futureim.org
Mistake 1: Vague Prompts and the Rewrite Loop
Our first and most expensive mistake was treating FutureX like a pair programmer instead of an engineer with a ticket. The first real task was: "Set up the backend with a health endpoint and connect to Postgres."
That prompt is a landmine. It does not specify:
- Which Postgres driver to use
- Whether the health endpoint should check the DB connection or just return 200
- Where configuration should live (env vars, config file, hardcoded)
- How errors should be shaped
FutureX made reasonable choices on all of those points. Then we said "actually, use the connection pool from the pg library" and "the health endpoint should do a SELECT 1" — and every one of those corrections triggered a partial rewrite. This is the classic prompt engineering failure: assuming the agent will infer intent from a one-line summary.
The fix is to write a short spec before the prompt. Not a full design doc, just a paragraph per endpoint with acceptance criteria. After we switched to that pattern, the number of regeneration loops dropped by roughly 70%. The rewritten prompt for the same task looked like:
Build the backend in
server/. Use Express 4 andpgwith a connection pool.GET /healthshould runSELECT 1against the pool and return JSON{status: "ok"}with a 200 only if the query succeeds; otherwise 503. Config viaPG*env vars. Do not add authentication yet.
That prompt produced a nearly correct implementation on the first try. The token cost difference was dramatic: the first version of the task consumed about 180k input and 40k output tokens. The specified version consumed 48k input and 9k output. Same feature, 4x cheaper.
The lesson: an AI coding agent is not a mind reader. Every structural ambiguity you leave unresolved becomes a token spent on guessing, a token spent on the wrong code, and a token spent on the correction.
Mistake 2: Refusing to Split the Work
Our second mistake was asking FutureX to do too much in a single session. We loaded the entire repo into the conversation and said things like, "Now add the incidents panel and the deploy status widget and fix the CSS."
This feels efficient. It is not.
The context window tax
When you give FutureX four tasks at once, it keeps all four in context. That means: the planning pass for task A puts tokens in the conversation history that remain there during task B, C, and D. The token cost is not additive, it is multiplicative. Every later tool call re-sends the full conversation history plus the new task. We saw sessions where the context reached 120k+ tokens and stayed there for dozens of tool calls.
The math is brutal. A single task done in isolation might be 30k input tokens. Done as the fourth task in a shared session, it might cost 90k input tokens because the context prefix is huge and each new tool call ships the whole history.
The fix was to treat each feature as an isolated session. We started a new FutureX session per feature, with a fresh prompt that included only the relevant files via explicit file references. We also learned to use fx-mini or fx-fast for simple, well-scoped edits rather than fx-pro, which is better suited to architecture-level planning.
Let the agent build its own roadmap
Instead of listing five features in one prompt, we gave FutureX the end state and let it produce a task list, then executed each task in its own session. This is not slower — it is faster, because each step starts with a clean context and no irrelevant history polluting the cache.
Splitting the work reduced our average session length from 22 tool calls to 8, and cut total input tokens by about 40% across the whole project.
Source: marketplace.visualstudio.com
Mistake 3: Ignoring the Diff and Re-Running Everything
Our third mistake was about verification. Whenever FutureX finished a change, we automatically said, "run the tests and lint and build." That is three tool calls, each of which loads outputs back into context. But we did not tell the agent to check the diff first.
The failure mode: FutureX would finish a small change, we would tell it to run the full test suite, it would run the full suite, and then it would see a failing test that was failing before its change, and then — because it was already in the agentic loop — it would try to fix that unrelated failure. That is how a 50-line bug fix becomes a 200k-token session that touches files unrelated to the task.
The fix is prompt-level gatekeeping. We added a standing rule at the top of every session:
After making any change, run
git diffand review the output before running tests. Only run tests after the diff is confirmed. If a test failure is unrelated to the change, report it and stop; do not fix it unless asked.
That single instruction eliminated an entire class of scope creep. The final phase of the project, which involved four small bug fixes, cost less than one of our earlier vague sessions. We also stopped saying "run everything" and started saying "run the test file for the module you changed." Targeted verification is a major cost optimization.
What the Optimized Workflow Looked Like
After the first two days, we had a working dashboard but an embarrassing token bill. For the remaining features — the metrics overlay and the deploy status refresh — we used a revised workflow. The receipts for the final day are worth comparing with day one:
- Day 1: 1.8M input tokens, 290k output tokens, 3 features (mostly wrong)
- Day 3: 490k input tokens, 71k output tokens, 2 features (correct on first pass)
The day 3 sessions all followed the same shape:
- Write the spec first. Five to ten lines per task, with acceptance criteria and explicit "do not" statements.
-
Reference files, not concepts. The prompt said "see
server/routes/metrics.jsandsrc/lib/api.ts" rather than "the metrics stuff." Direct file references cut the number of file-discovery tool calls in half. -
Use the right model tier.
fx-profor the initial architecture and any schema design;fx-fastfor everything else. We reservedfx-ecofor throwaway experiments and one-off greps. - Review the diff before testing. This stops the agent from going down rabbit holes.
- End sessions at natural boundaries. Never start a new feature in the middle of an existing conversation. The context cache saves money, but stale context costs more than a fresh cache miss.
Practical Cost Optimization Rules for FutureX
The numbers from this project are not exotic. Anyone building an internal tool with an AI coding agent will hit the same patterns. Here are the rules we now apply to every FutureX session, which you can steal for your own cost optimization effort.
Rule 1: Spend 2 minutes writing the prompt, not 20 minutes fixing the output
Every unstructured element in your request is an inference FutureX has to make. Inferences cost tokens. A good prompt for FutureX is not a paragraph of English; it is a compact list of constraints, file paths, and acceptance criteria. The best prompts we wrote were the least conversational.
Rule 2: Keep the task narrow and the session shorter
One session, one feature. If you find yourself typing "and also" in a prompt, stop and split it. FutureX handles five small sessions far more efficiently than one giant session with five tasks, because context is the dominant cost driver.
Rule 3: Prefer targeted verification
Run the test file for the module that changed, not the whole suite. If a full test run is required by policy, phrase it as a checkpoint, not as an open invitation to fix failures. "Report failures and stop" is a clause that should appear in many prompts.
Rule 4: Use the model tier as a cost lever
The FIM model line exists to give you that lever. fx-pro is for planning, schema design, and anything where architectural reasoning matters. fx-fast is for routine edits and well-specified features. fx-mini and fx-eco are for trivial transformations and exploration. We saved roughly 30% of our bill just by not using fx-pro for mechanical changes.
Rule 5: Watch the tool-call pattern, not just the token count
A session with 40 tool calls almost always costs more than a session with 10, even if the final code is similar. Repeated reads of the same files, redundant greps, and re-testing are the signals of a prompt that was not specific enough. If you see FutureX re-reading a file it already read, stop and inject the relevant information directly into the prompt.
The Final Bill and What We Learned
The dashboard is in production now, used by four teams, and the total bill for building it — including the wasted tokens — came to about $38. The optimized-next-day sessions alone showed the same work could have been done for roughly $15. That $23 delta is the price of learning these lessons, but it is a repeating cost if you keep the same habits. Every vague prompt, every bloated session, and every unexamined diff inflates the bill by a predictable multiplier.
The core takeaway is that an AI coding agent is less like an autocomplete and more like a very fast junior engineer: it is only as cost-effective as its input allows. FutureX made the token usage transparent, which gave us the data to fix our own process. The tool was never the problem; the prompts were.
If you are about to build an internal tool with FutureX, write the spec, split the work, check the diff, and pick the right model for the job. Do that and the token bill will stay where it belongs — in proportion to the work, not to the mistakes.
Originally published at blog.futureim.org/building-internal-tool-futurex-token-costs.
Top comments (0)