🐍 Python Functions are now in Public Preview

[andreea.oprita]

UiPath Python Functions are now in Public Preview. Write deterministic logic in plain Python — in your own IDE — publish it with one CLI, and call it from anywhere on the platform. No enrollment required.

Code is now a first-class citizen of the platform

Your agents reason. Your robots click. Your people approve. But some steps just need code — a precise calculation, an API call with custom auth, a data transformation, a business-rule check.

That’s exactly what UiPath Functions are: the developer-native compute unit of the agentic platform. No LLM, no reasoning loop, no model — just typed input in, typed output out. And we’re starting with the language developers reach for first: Python.

Developer-native, end to end

• Author anywhere. Write plain Python in the IDE you already use — VS Code, PyCharm, whatever — with your preferred coding agent riding shotgun (Claude Code, Cursor, Codex…). Define Input/Output as dataclasses or pydantic models; the SDK turns them into JSON Schema for binding.

• Access the whole platform. The UiPath SDK gives your code the entire platform at runtime — IXP, Data Fabric, Integration Service — plus Orchestrator resources: queues, assets, credentials, and storage buckets. Credentials stay in Orchestrator; no secrets in your code.

• Ship without ceremony. The uip CLI packs and publishes for you — it handles the UiPath platform contracts (entry points, schemas, packaging), so you only ever write business logic.

• Run where you want. On UiPath Serverless today; on your local unattended robot soon. Same code, you pick the target.

And it’s observable and governed by default: drop @traced on a helper to light up the trace tree, and every run inherits Orchestrator RBAC, identity, and audit logs.

It looks like this

from pydantic.dataclasses import dataclass

@dataclass
class Input:
    message: str = ""

@dataclass
class Output:
    reply: str = ""

def main(input: Input) -> Output:
    return Output(reply=f"Hello, {input.message}!")

From zero to running locally with the uip CLI:

# Prereqs: Node 20+ and Python 3.10+
npm i -g @uipath/cli      # the uip CLI
pip install uipath        # the Python SDK

uip functions new my-function --language py
uip functions init                              # generate the I/O schema + bindings
uip functions run main '{"message": "world"}'   # run it locally

See it in action

1 · Author in your IDE, with your coding agent

The function open in your editor of choice: @traced on a helper, sdk().buckets.download(…) pulling a file from Orchestrator, and uip functions run main streaming live logs in the terminal.

2 · Debug logs, right in Orchestrator

Every run lands as a Function (python) job with full install and execution logs — no extra tooling to stand up.

3 · Every @traced step, visualized

The Trace tab turns your decorated steps into a timed execution tree — bucket_download, ixp_digitize, netsuite_get_vendor — with the typed output right beside it.

4 · A new project type — that ships in your solution

Create, run, and debug a Python Function project directly in Studio Web — and onboard it into a UiPath solution to pack and deploy it alongside your other projects.

5 · Drop a function into Maestro

The new Start and wait for Function Service Task binds your function into a Maestro process, with typed inputs and outputs mapped automatically.

Call it from anywhere

Package your function, publish it to Orchestrator, and deploy it as a process — then invoke it from:

• a Maestro “Start and wait for Function” Service Task

• a Run Job activity in Studio

• the Orchestrator API

• any trigger — scheduled, queue, or event / webhook

? Where it runs & what it costs

Runs on UiPath Serverless today. Pricing: 0.01 PU per 15 seconds of execution.

By mid-July, you’ll also be able to run functions — alongside coded and low-code agents — on your own local unattended robot. Same code; you choose where it runs.

What’s next

• JavaScript / TypeScript functions, with full HTTP semantics — coming next.

• Local unattended execution for functions and agents — mid-July.

Dig in

• SDK + samples: github.com/UiPath/uipath-python

• SDK reference: uipath.github.io/uipath-python

• Docs:

It’s a preview — and we want your scars and your wins. Build something with it, then tell us what worked and what you’d change. Reply right here, or share feedback on the Insider Portal so we can squash the critical issues before GA.

[edevries (Peter Griffin)]

Looks well-done. I would love to see more support for C#/.NET as well. Coded Workflows/Code Source files were a great start.

Specifically, a .NET-first project type that allows us to build pieces of an automation in any environment and then deploy to UiPath infrastructure. Rather than being reliant on Studio to run/test.

Edit: This does not look good. It requires us to pay per-execution to run these on our servers (from my understanding).

[edevries (Peter Griffin)]

Local unattended deployments for functions and agents? Now this is promising. If we can run these on our own servers, my organization would be more likely to explore these options.

[Alexandru_Bizon]

Yes, you will be able to run functions and agents on local unattended robot. We are getting ready to ship this very soon.

[ashokkarale]

@Alexandru_Bizon

This is great!
What’s plan on pricing local unattended robot runs?

[Alexandru_Bizon]

The unattended robot will be enhanced with new execution engines for python (for executing python functions, low code agents and coded agents) and js/ts (for executing low code API workflows and coded js/ts functions).

The machine template will have options to define which runtimes you want your robot to execute.

• RPA - same as today will require the unattended license
• Low code agents and coded agents - you will configure how many parallel agents can be executed at once and they will consume Platform Units or Agent Units if you are on flex licensing
• Python or JS/TS functions - you will configure how many parallel functions can be executed at once and they will consume Platform Units or Robot Units if you are on flex licensing.

[edevries (Peter Griffin)]

So, we pay to run an agent or function even if we are running it locally on one of our servers? I am not on flex licensing.

[Alexandru_Bizon]

hi @edevries sorry for the slow reply, this one deserved a proper answer rather than a quick one.

Short version: yes. Execution is consumption-priced regardless of where it physically runs: local robot or cloud, flex or not. The location of the compute doesn’t change the fact that you’re using the new execution engine plus the orchestration, audit, and governance around it.

The longer “why” is that pricing here is a balancing act between forces that genuinely pull against each other:

• Covering the cost to build it (a lot of engineering went into bringing these new execution engines to the local robot; that work has to be paid for somehow)
• Keeping the entry barrier low (we want Functions priced cheaply enough that adoption isn’t walled off by cost)
• Not undercutting existing licensing (running RPA on local servers already requires an Unattended license. You can have a local robot with no unattended license and making Functions free would mean no revenue for the orchestration, audit, governance, and execution around them)
• Preventing abuse (Functions are pure code. We can’t dictate what a developer writes and flags as a Function, and it doesn’t take much to reverse-engineer the metadata the CLI adds to mark a package as one. Consumption-based pricing is the neutral, fair way to handle that.)
• Where the market is going (consumption-bahat customers expect and ask for)

There’s rarely a clean answer in pricing. The honest goal is to make everyone a little unhappy rather than leave one group delighted and another deeply frustrated.

[edevries (Peter Griffin)]

In that case, I don’t foresee having any plans of using this new feature. We already pay for Orchestration, I cannot justify to my organization paying more every time we run these, especially when it is on our own servers.

Rather than UiPath’s agent projects, I’ll just call an LLM over their web API directly. If I want to use Python badly, I’ll just use an invoke Python script activity. That way, it is easier for me to get a ROI on projects.

[ForsakenFiji (Nick Sudh)]

I honestly fail to see the value of deterministic coded functions as platform-level callable units. Can’t I just invoke code (Python/C #) directly in my Studio and ship it with my automation project? Or if I need a logic reused by many automations, I’ll just build a library…

And if I truly need a Python project exposed to my Automations, organization-wide, I’ll just spin up a FastAPI locally, expose the endpoints, and have an Integration service and/or an HTTP activity call them?

[edevries (Peter Griffin)]

AND you pay per execution on Functions apparently. Unless I am missing something you’d have to be a nimrod to pay to execute some Python with it.

[ForsakenFiji (Nick Sudh)]

The only value I can see is if I need to execute GPU heavy python code where the cost of compute and administrative overhead of renting GPU VMs may break even with python functions. But UiPath needs to explain the full mechanics of how they will price compute heavy functions…

[Alexandru_Bizon]

@ForsakenFiji here are several real advantages to Functions, and they’re complementary to RPA, not a replacement.

You author them in any IDE. Python Functions run natively on the Python engine, which makes them a far better fit for large data manipulation than Python Activities in RPA - those run on .NET with a Python translation layer on top. You get 100% predictability: the code you debug and test locally is exactly what runs in production, no surprises. JS Functions return in under a second, and when you’re building apps for customers, that speed matters.

You also get full observability and tracing out of the box, plus governance and audit. Compare that to the RPA path: to surface your Python business-logic logs in RPA, and then surface the RPA logs up into Maestro, you’d be writing a lot of boilerplate - and it’s not even an easy thing to get right in the first place. Functions give you that for free.

Then there’s the whole class of use cases where you don’t touch a legacy desktop system at all (no UiAutomation needed), every system has APIs, and the customer wants a long-running business process automated. That’s where this setup is genuinely better. You model the process in Maestro so the customer sees it in a business language they understand, then implement each task as pure code in your own IDE (VS Code, Cursor, whatever) with the coding agent of your choice (Claude, Codex, etc.). The SDK and CLI give that code access to the entire UiPath ecosystem.

That’s speed and productivity - a coding agent generates the Python fast, and the whole thing slots straight into CI/CD and proper testing practices. You deliver in days instead of months. And six months later, anyone can open the repo and fix a task without you in the room. That last part is what earns customer trust: the process is legible in Maestro, and the tasks are just code.

@edevries on the pricing - I answered this a few posts up, so I won’t rerun the whole thing, but short version: execution is consumption-priced regardless of where it physically runs, local robot or cloud. You’re not paying to “run some Python.” You’re paying for the new execution engine plus the orchestration, audit and governance wrapped around it. A local robot can exist without an unattended license, so making Functions free would mean charging nothing for that whole layer - that’s the part that has value, not the Python itself. And the “just host a FastAPI box” alternative isn’t free either: that VM bills whether it’s hit once a day or never, and you own all the scaling, patching, auth and monitoring that a Function hands you for nothing.

The honest part is that pricing here is a balancing act - covering the engineering that went into bringing these engines to the local robot, keeping the entry barrier low enough that adoption isn’t walled off, not undercutting existing unattended licensing, and not leaving the package metadata trivially game-able (Functions are pure code; you can’t dictate what someone flags as one). Consumption is the neutral way to handle all of that. There’s rarely a clean answer in pricing - the goal is to make everyone a little unhappy rather than leave one group delighted and another furious.

And @edevries - I DM’d you to get into exactly this, how you’d price it, because a forum thread is a poor place to design a pricing model. That offer’s still open. I’d genuinely rather hear your model than keep trading posts about mine.

[edevries (Peter Griffin)]

I chose not to respond because you have heard my answer. Plus, I think it’s better for the discussion to be open here where other community members can give input.

You argued you have to charge per-execution because it cost money to make these features. I’d argue you should just make these new features, so customers continue to pay for your services at all. I understand paying to use functions in a serverless environment (like Azure, whom I assume you borrow the nomenclature from), but I think it is bizarre for us to pay per-execution to run these locally.

I’m not trying to be instigative, and I appreciate the work the UiPath developers put into their product. I’d be curious what some of the other UiPath users have said about their experience with Maestro and the suite of features coming out to support it as well. It just seems awful expensive.

[Mark.Edgeller]

To echo some of the points people are making, ROI is the main driver that organisations care about, and If you’re only talking to development teams you’re missing the bigger picture. Once you start adding up all the individual costs for all these shiny new consumption-priced capabilities, ROI goes out of the window head-first.

Take Maestro, for example. It is a great example of a brilliant idea that has a barrier to entry that is prohibitively high (5 AU per run is insane). Functions now appear no different. At least Maestro’s benefit is much easier to demonstrate to a non-developer (i.e. our management!). I fully understand that there’s a cost to everything, particularly on the LLM side. I don’t think teams begrudge you charging what you are for LLM use given what the upstream providers make you pay. But for what amounts to a bit of CPU time, a lot of your pricing doesn’t add up. Charging for both the unattended runtime use-case and cloud-executed separately just means you pay for it twice.

Someone really ought to sit down and look at a couple of whole business cases where you’d want to use a few of these capabilities at the same time, then look at what it actually costs to run a single transaction. I think you’ll get the same shock we’ve been having, honestly.

[Alexandru_Bizon]

@Mark.Edgeller @edevries @ForsakenFiji honestly, thank you for this. Brutal, but the good kind. It’s rare to get people who care enough to sit down, do the maths, and tell me straight that it doesn’t add up. That’s worth ten polite replies. Putting the pricing out in the open here was exactly the right call, because this is the conversation I actually needed to have.

So let me be real with you.

On Maestro: yeah, I hear you on the AU thing. Can’t say much yet, but it’s not landing on deaf ears. I’ll share what I can when I can.

On Functions though, I think the fear is actually pointing the wrong way, and I’d rather just show you than ask you to take my word for it. An unattended license is a big fixed cost every year. Consumption is pay-as-you-go. Run the numbers and the only time the license wins is if you’re keeping that robot busy more than half the year. Below that, paying per use is the cheaper option, usually by a mile. So for the way people actually run, consumption is protecting your ROI, not killing it. You’re not overpaying against a license, you’d be overpaying if I made you buy one.

Where you’re 100% right is the bit that stings: if you already own an unattended license and it’s just sitting there idle, being told to pay units on top to run on your own box does feel like paying twice. I don’t have a clean answer for that today. That’s the honest gap, and I’m not going to hand-wave it.

So here’s what I’m actually doing with this, not just nodding along: I’m taking it to leadership and pricing to let the local robot do both: pay-per-use with units, or just run it on the capacity you’ve already paid for; and you pick whichever’s cheaper for you. Bursty, occasional stuff, units win. Busy robot with room to spare, use the license. Best of both worlds, and that’s the version I’m fighting for.

And none of that happens without threads like this. So, genuinely thanks for the honest version. Keep it coming.

[David_Hernandez2 (David Hernandez)]

pay-per-use with units, or just run it on the capacity you’ve already paid for; and you pick whichever’s cheaper for you.

This would be huge! I don’t think we could convince leadership to take on additional pay-per-use costs right now, especially in the current economy/market. But if we could start using some of these tools with the licenses and capacity we already have, it could prove the value and pave the way for those conversations in the future.

[Mark.Edgeller]

Thanks for taking the time to reply. I’ll overlook the fact that this response was clearly written by AI (you can’t hide the cadence and “I’m not going to hand-wave it” is a Claude trademark at this point), despite how irritating it is.

I understand the point about paying per use is often cheaper up to a threshold, but the simple point this overlooks is that the pre-paid licenses are just sitting there. Its sunk cost. You’re not making us overpay by buying a license because we already have them.

The conversation about utilisation is one we’ve been having internally, so I know where you’re coming from. I’d wager almost every organisation that buys unattended licenses overspends through an abundance of caution, or precisely because of the bursty throughput scenario you described. In our case, we have way too many Unattended runtimes, but we need what we have for a couple of hours each morning to get through all the urgent work. We cannot run these processes in a PAYG manner because they’re all heavy, UI-based automations pointing at our ERP (an old Oracle EBS instance, for reference). The unfortunate consequence is that for ~20 hours in a day a lot of our VM’s sit idle.

If you can achieve what you describe then it’ll go a long way towards tearing down the picture of greed that is slowly forming in our minds about UiPath in general.

[Alexandru_Bizon]

True about the written by AI part - I had Claude fix my English and structure my thoughts…and obviously enough it added his own style on top of it.

I got the idea, and the solution described above will be what I will push in having in 26.10 LTS Robot.

It will take some work both on alignment and also engineering and product wise - as you probably imagine it becomes quite complex to handle both unattended licensing and PAYG consumption models, machine template with slots and runtimes, doing orchestration for all these job types on the right robot with the right consumption model and the right runtime, surfacing all of this in the UI…and providing a sane UX for you to make sense of it and be able to predict what is going to happen.

We still have some time until we freeze the 26.10 LTS release, so I just ended up with having some extra work on my plate. But it’s the kind of work that I like and that it brings real value for our customers.

Now, on your statement about greed. For functions I can 100% tell you that this is not the case.

Serverless pricing model for Functions is modeled to as affordable as possible within certain boundaries and constrains.

JS Functions with HTTP semantics will be free execution on Serverless (up to a certain amount to prevent abuse)! You will get a super fast super scalable BackEnd (talking ms response times here) for UiPath Apps for free - that was the initial plan, before this conversation even took place. Working on this as we speak and it will light up in 2-3 weeks.

As for the local execution pricing, there were some baggage that I had to carry over (mainly due to coded agents, revenue stream canibalisation, and preventing abuse…don’t want to go in a lot of details…I already shared more than enough in this thread about the complex nature of pricing and the decisioning process that backs it)

For Maestro, I want to let you know that there is a market fit for the pricing at is today - very long business processes that take weeks, months.

That 1$ price per instance was designed for this market.

Indeed it is totally wrong to charge 1$ for business processes that takes less than 15 minutes - and like I said, we are working on having a solution for this also.

Next, you mentioned the transaction costs and how costs cand creep up. We know about this.

We working on a feature to surface this at design time for the developer to be able to easily predict and make the right design choices while he builds that automation.

Lastly, UiPath is delivering vertical solutions per industry through our FDE engineers that work directly with our customers. These vertical solutions are mainly pure code (agents, functions) modeled in Maestro. And when we sell these, we sell at per Maestro instance cost - does not matter the time it takes to execute nor what consumables are being used (LLM calls, IS calls etc.)

I would argue that the image you painted is not accurate…

We struggled during the last 3-4 years to spin up a new revenue growth engine for the company and at the same time move to a PAYG model…and sometimes I also get the feeling that due to this we might come across as too aggressive on monetization. Maybe sometimes the baggage shows. But we see it, and we are correcting where it doesn’t make sense.