Where the money goes when a model drives a screen
April 2026's release notes on the subject are largely about unit consumption and metering. That is the cost question approached from the accounting end, and the version we get asked is the engineering one: does having a model drive the screen work out cheaper than paying for the integration build. In the abstract there is no answer to it, and the answer for any given process depends on figures most teams have never counted. So we start with where the money actually goes in each shape.
An agent that operates an interface runs a loop. It captures the screen as a screenshot, sends that to a vision-capable model with the goal and the history so far, gets back an action such as a click at a coordinate or a string to type, executes it, then captures the screen again. Every pass through that loop is a model call carrying a large image, and that is the thing you are paying for.
Cost per run is step count multiplied by the price of one call. Step count is where estimates go wrong, because it is not fixed. It varies with what the interface does while the run is in progress: the agent re-reads the screen to confirm what happened, handles validation errors it triggered, and waits for panels to render, and each of those is another pass through the loop. Two runs of the same process against different records can take different numbers of steps.
You also pay for the infrastructure the run sits on, which is a Windows VM or container holding a browser profile open for the length of the task. Recovery is the cost we see left out of estimates most often. A model that misreads a screen can carry on regardless, and getting back to a known state means resetting the application and paying for a second full pass.
Where the money goes when you call an API
Almost all of the cost of an API integration falls at the front of the work: the auth flow (OAuth client credentials or an API key in a header), field mapping, pagination and rate limits, and idempotency logic so a repeated call cannot create a duplicate record. That is engineering time paid once, plus a smaller amount when the vendor versions the endpoint.
After the build, a run costs the compute time of the code that makes the call plus whatever the vendor charges for it, and providers set their own prices and rate limits. The same input produces the same request, so the integration can be unit tested. Failures come back typed as a 401, a 429 with a retry-after header, or a 422 with a field-level error body. We put more weight on typed failures than most cost comparisons do, because a typed failure tells you what to change and a screenshot of a stuck screen does not.
We still use a language model inside these workflows, on the steps that need reading, classifying or interpreting: pulling a delivery date out of a supplier email, or deciding which of nine service categories an enquiry belongs to. Those are bounded calls on text, one or two per run, and they do not scale with the number of screens involved.
Why volume decides it
It comes down to two numbers per process. The build cost, which for an API integration is most of the total, amortises across every run the process ever does. The cost per run, which for screen operation is most of the total, does not amortise.
The crossover point is the build cost divided by the difference in cost per run. Below that volume the build cost dominates the total and screen operation can be the cheaper option overall. Above it the cost per run dominates and the integration is cheaper overall. We work the number out for each process before committing to a shape, and we would argue with anyone who quotes you a general answer to this. A pilot runs at a volume well below the crossover, so pilot cost figures do not carry over to production without recalculating.
Why we ask for your own per-process figures
All of that arithmetic assumes you know your current cost per run for each process, which is not a figure most teams have to hand. UiPath's release note for the Consumables Center, a public preview shipped on 23 April 2026, describes the prior state plainly: there was no way to see where units were consumed across the full organisational hierarchy, from bundle down to tenant, folder and process.
UiPath also shipped tenant consumption enforcement on 27 April 2026, letting an administrator decide whether a service stops consuming units once a tenant hits its allocation. With enforcement on, consumption halts at 100% of the allocation. With it off, consumption continues from the organisation pool, and notifications go out at 50%, 75% and 90% either way. A cap of that kind limits what a runaway process can spend. It does not tell you which process is expensive per unit of work delivered, which is the question the cost comparison needs answered.
For the work we run, every execution records the process, trigger, step count, tokens in and out, duration and outcome, so cost per run and cost per successful run are both queries against that table rather than estimates.
Coupling, prompt injection and bot detection
A screen driver is coupled to a rendered interface, so when a vendor moves a button or adds a consent dialog on first login, the run either fails or acts on the wrong control. A model-driven agent handles some of that variation without a code change, and it also makes failures harder to diagnose, because the evidence of what went wrong is a sequence of screenshots. Microsoft's Power Automate 2026 release wave 1 plan records video logs for unattended desktop flow runs as reaching public preview on 30 April 2026, with general availability not yet set. We are not sizing any estimate around it while it sits in preview.
An agent reading a supplier portal or a shared inbox is reading text controlled by people outside your business, and that text goes to the model as input. Help Net Security reported on 24 April 2026 on Google and Forcepoint research into indirect prompt injection, with Google observing a 32% relative increase in the malicious category between November 2025 and February 2026. Forcepoint found no evidence of highly coordinated campaigns, and noted that shared injection templates across multiple domains suggest organised tooling more than isolated experimentation. Forcepoint also found a fully specified PayPal transaction with step-by-step instructions aimed at agents with payment capabilities. Those findings sit at odd angles to each other, so how organised this activity is remains unsettled. We are not waiting for that to settle: outbound actions in our builds are held for a person to approve before they execute.
Help Net Security's 30 April 2026 write-up of the Thales 2026 Bad Bot Report puts automated traffic at 53% of all observed internet traffic in 2025, with AI-driven bot activity up more than tenfold (12.5x) across the year. We read figures out of a vendor report as an indication of direction and nothing stronger, since the method behind them is not published in enough detail to put them in a calculation. Public-facing sites run bot detection against traffic of that kind, a browser session driven by an agent can be challenged or blocked by it, and runs stopped that way have to be retried or picked up by a person.
When we would still drive the interface
Screen operation is the correct engineering choice in several situations. The system has no API, or the API covers reads and omits the write you need. API access is sold as an upgrade tier priced above the cost of the screen runs. Volume is low and stable, so an integration build would not pay back. The process is temporary, such as a migration, a backfill, or a cutover with parallel running.
If you do it, keep the exit path open by holding the decision logic, field mappings and validation rules in code you own. UiPath released a public preview on 30 April 2026 allowing a low-code agent to be cloned as a coded agent, and the release note states that cloning generates a Python project including source code representing the agent's prompts, tools and schemas. Take features like that up while the estate is still small enough to move.
Two rules apply to our builds whatever the cost comparison says. An interface-driving agent does not get a step that moves money or sends external communication without a person approving it first. Any process that runs often enough to matter gets a scheduled review of its cost per successful run, because both model pricing and the interfaces it drives change over time.
There is no crossover figure that holds across processes generally, because step count varies with the interface being driven and a figure from one system does not carry to another. The question we carry forward is whether the video logs make a failed unattended run diagnosable, and that is untested while the feature sits in preview.