Agentic Simulation Workflows: Token Cost Is an Engineering Parameter

By Aydar Akchurin

I recently compared two agentic simulation workflows running the same TriboSolver simulation case: through the web interface and through the API route. The numerical result was the same, while the effort required to get that result in terms of time and tokens was different. The question of the time required to get the results is straightforward, we need to get the results as soon as possible. When it comes to tokens, the situation is similar: less tokens means less money and energy spent on the execution. The number of tokens used becomes especially important with latest news that LLM providers such as Anthropic reduce the number of available tokens for the users in a given plan.

For the tested case, the API route completed setup, execution tracking and result retrieval in about 6.0 minutes. The web UI route took roughly 10-11 minutes. The larger difference was in the amount of machine-readable context needed for automation. The API route needed about 270 payload tokens. The UI callback route needed about 2,940 payload tokens to start the job, load the result and extract the five scalar values used in the comparison. As an example, if we take ChatGPT (costs shown below, I took the output tokens for the max prices), with a budget of 100 US dollars, we can run approximately 1100 simulations via UI and over 12000 simulations via API. Right now the costs seem bearable relative to the license costs. however, we need to keep in mind that the tokens are subsidized and due to the shortage of the compute in the coming years, the token prices are expected to rise. It should be mentioned though, that although I have used ChatGPT behind the OpenClaw agent, it is not necessary to do so. Its possible to set this simulations using cheaper models and I will explore this in future and compare the results.

Comparison tells us that the efficient agentic simulation workflows need to be going via APIs and as such, engineering tools need to be developed as API first.

Automation payload difference between agentic simulation via web UI and API.

What was compared

The comparison used one dry-contact input payload and two execution routes.

Web UI route: operate the deployed TriboSolver Dash interface, start the dry-contact calculation through the UI callback, load the saved result file and request the scalar result variables.
API route: submit the same dry-contact JSON payload via API, retrieve the results via the result file

Result check

The first requirement was simple: the API must not change the engineering result. It must reach the same solver path and return the same values as the web workflow. For this dry-contact case, it did.

Metric	Web UI result	API result
`FC`, calculated contact load	1.000000000000001 N	1.000000000000001 N
`PA`, average contact pressure	27777.777777777806 Pa	27777.777777777806 Pa
`Pnom`, nominal contact pressure	27777.777777777806 Pa	27777.777777777806 Pa
`Indent`, rigid body motion	1.5031768476615807e-09 m	1.5031768476615807e-09 m
`AREA`, real contact area	3.6e-05 m²	3.6e-05 m²

This is the important part. The checked scalar values matched exactly.

Time and token overhead

The time comparison comes from the measured API runner time and the observed web UI workflow during the same verification session. The token estimate uses compact payload length and the standard rough approximation of about four characters per token. This is not exact tokenizer accounting. It is good enough for comparing the interface overhead.

The API route reduced both elapsed workflow time and payload size for automated verification.

Metric	API route	Web UI route	Comment
Total setup, run tracking and result retrieval time	About 6.0 minutes	Roughly 10-11 minutes	The API avoided browser-state and callback overhead.
Setup/result payload estimate	About 270 tokens	About 2,940 tokens	The UI route used roughly 10-11 times more payload for the same scalar check.
Checked scalar outputs	Exact match	Reference route	The lighter route did not change the tested result.

What the token difference costs with current LLM prices

The token numbers above are small for one run, but they become real money when an agent repeats the same verification workflow thousands of times. The API route used about 270 setup/result tokens. The web UI route used about 2,940 setup/result tokens. That is an avoidable overhead of about 2,670 input tokens per run when the task is repeated automation rather than human inspection.

The table below uses public provider prices checked on 3 June 2026. It focuses on text input and text output token prices, because that is the part most directly affected by converting UI state into model context. Pricing changes often, so production cost estimates should always be rechecked against the provider pages.

Model	Input price	Output price	Extra cost from UI overhead, 10,000 runs	Why it matters
Gemini 2.5 Flash-Lite	$0.10 / 1M tokens	$0.40 / 1M tokens	About $2.67	One of the cheapest hosted choices for high-volume simple agent checks.
DeepSeek V4 Flash	$0.14 / 1M cache-miss input tokens	$0.28 / 1M tokens	About $3.74	Very low input and output cost; cache hits can be cheaper.
Gemini 3.1 Flash-Lite	$0.25 / 1M tokens	$1.50 / 1M tokens	About $6.68	Cheap newer Google option when stronger simple-agent behavior is useful.
Gemini 2.5 Flash	$0.30 / 1M tokens	$2.50 / 1M tokens	About $8.01	Still low cost, but waste grows quickly in repeated UI-driven workflows.
DeepSeek V4 Pro	$0.435 / 1M cache-miss input tokens	$0.87 / 1M tokens	About $11.61	More capable than the Flash tier while staying inexpensive per token.
OpenAI GPT-5.4 mini	$0.75 / 1M tokens	$4.50 / 1M tokens	About $20.03	A compact higher-quality model; context waste costs more than with budget models.
Claude Haiku 4.5	$1.00 / 1M tokens	$5.00 / 1M tokens	About $26.70	Useful low-end Claude tier, but still 10 times the input cost of Gemini 2.5 Flash-Lite.
OpenAI GPT-5.4	$2.50 / 1M tokens	$15.00 / 1M tokens	About $66.75	Wasted UI context becomes expensive when a stronger model is used for review.
Claude Sonnet 4.6	$3.00 / 1M tokens	$15.00 / 1M tokens	About $80.10	A common agent/coding model tier where repeated browser overhead is not free.
OpenAI GPT-5.5	$5.00 / 1M tokens	$30.00 / 1M tokens	About $133.50	Frontier-model context should be spent on engineering judgement, not avoidable UI state.

The numbers in the fourth column only count the extra input tokens created by using the UI route instead of the API route. Output tokens, tool calls, search grounding, image input, cached-input rules and batch discounts can change the final invoice. The direction does not change: when the workflow is repeated, a cleaner API lets the agent spend context on assumptions, validation and interpretation instead of describing a browser.

Sources checked for the rates above: Google Gemini Developer API pricing, DeepSeek API pricing, OpenAI API pricing and Anthropic Claude API pricing.

For repeated automated verification, this is enough evidence to prefer the API. The web interface is still useful for inspection, manual setup and visual review. It is a poor interface for running the same verification loop many times from an agent.

Why the interface matters

A human can use a graphical interface efficiently because the human sees the screen, recognizes the form and decides what matters. An agent has to convert that same interface into text, state snapshots, callback payloads and tool calls. Every extra selector, hidden field, result-loading step and page state becomes context.

That context has a price. Sometimes the price is money. Sometimes it is latency. Sometimes it is the loss of useful working memory inside the model. In engineering work, all three matter.

In this TriboSolver case, the API gave the agent three things that the UI route did not give cleanly:

a structured input payload,
a simple completion rule based on job status and the result route,
a compact result object that can be checked without reconstructing the UI state.

This is the kind of difference that looks small in a demo and becomes large in production. One dry-contact case is manageable either way. Hundreds of cases, parameter sweeps, regression checks and report-generation runs are a different problem.

Token cost as an engineering parameter

Token use is often treated as an accounting detail. I think that is becoming the wrong way to look at it. For agentic engineering workflows, tokens are closer to CPU time, memory and network bandwidth. They define how much work can be done before the workflow becomes too expensive, too slow or too fragile.

The recent direction of the AI market supports this view. Public API pricing now separates input, cached input, output, tool use and processing modes. Providers also keep changing usage limits and service tiers because model capacity is tied to real compute supply. Anthropic’s 2026 announcement about higher Claude usage limits and additional SpaceX compute capacity is a good example: the product limit changed because more compute was made available. Deloitte’s 2026 technology outlook makes the same point from the infrastructure side, estimating very large AI data center capital expenditure as inference and test-time scaling continue to grow.

I would not describe this as a future where tokens simply run out. That is too dramatic. The practical problem is narrower and more useful: high-quality tokens will be rationed by price, latency, rate limits and availability. Engineering tools that waste fewer tokens per verified result will be easier to automate.

What this means for simulation software

Simulation software still needs a good user interface. Engineers need to inspect the model, review plots, change assumptions and catch mistakes. But the UI should not be the only programmable route.

A better architecture is straightforward:

UI for engineers: model setup, visualization and review.
API for automation: structured input, execution, polling and result retrieval.
Shared solver backend: both routes must reach the same calculation engine.
Periodic comparison: API results should be checked against the UI route to detect drift.

The last point is important. An API becomes dangerous if it quietly diverges from the trusted engineering workflow. The comparison above is therefore part of the API development process, not a marketing exercise.

Conclusion

For this dry-contact case, the TriboSolver API route produced the same checked scalar result as the web UI and reduced the automation payload by roughly an order of magnitude. It also shortened the end-to-end workflow.

That is the practical conclusion. If the task is manual inspection, use the UI. If the task is repeated verification, regression testing, parameter scanning or report generation, use the API and keep comparing it against the UI route.

As AI tools become more expensive and capacity limits become more visible, simulation software should treat token use as an engineering parameter. Measure it. Reduce avoidable overhead. Spend the model context on assumptions, validation and interpretation, not on operating a browser interface that was designed for a human.