AI Agent Platform Comparison: Pricing and Lock-In

How did we run this AI agent platform comparison?

The short answer: every platform type bills differently, exports less than its marketing implies, and stops working at a predictable point. We compared platforms on the three things that decide cost over two years: how they bill, what you can export, and where they stop working. Feature checklists age within a quarter, so we left them out.

What we included and what we left out

We grouped options into four types rather than ranking brands. Each type behaves differently on cost and exit.

• Hosted low-code builders, such as Microsoft Copilot Studio, where flows are built in a visual editor.
• Cloud-provider agent services, such as Amazon Bedrock Agents.
• Model-vendor agent APIs, such as the OpenAI agents guide.
• Open-source orchestration frameworks, such as LangGraph.

We did not run benchmark latency tests, and we do not publish vendor list prices. Those change monthly, so read them from the vendor's own page on the day you buy. We also have no published per-platform cost-to-match figures yet, so the build-versus-buy section below gives you a method to run with your own numbers instead of ours.

Agent platform pricing models side by side

Platforms bill in four ways. The right one depends on whether your usage is spiky, steady or growing fast.

• Per seat: you pay for each builder or user, whether or not they publish an agent.
• Per message or credit: you buy bundles of conversations or runs and draw them down.
• Per token: you pay for model calls and context length, which makes the bill follow usage closely.
• Free code plus hosting: the framework costs nothing, but you pay for infrastructure and engineering time.

Why list price misleads, and what to ask a vendor

Agent loops multiply calls. One user request can trigger a planner call, three tool calls and a verification pass, so a flat "per message" price hides a variable underneath. Model your cost per completed task, not per request. Then pick the pricing model whose cost curve matches your expected usage: per-seat suits a small, stable group of builders, credits suit predictable volume, and token billing suits workloads you expect to grow or shrink sharply.

A worked example shows the gap. Suppose a support agent handles 1,000 requests a month. If each request triggers five model calls, you are billed for 5,000 calls, not 1,000. If 10% of runs fail and retry once, add roughly 500 more. A forecast built on the per-request count would be off by more than five times before you account for longer contexts. The numbers are illustrative, not vendor prices, but the multiplier is the part to measure in your own pilot.

Ask what counts as one billable unit, whether failed runs are billed, and whether connectors carry separate fees. Get the answers in writing before you build on the platform. Because we do not quote vendor prices here, treat the table as a checklist of where each model tends to surprise buyers, and fill in real numbers from the vendor's current pricing page.

AI agent platform comparison: what do you own when you leave?

You usually own your prompts, data and evaluation sets. You rarely own the orchestration logic, connectors or memory format unless the platform exports them as code or a documented schema.

What is portable and what is trapped

Portable items:

• Prompts and system instructions, as plain text.
• Source documents and the embeddings you can regenerate.
• Your evaluation cases, if you wrote them outside the platform.
• Model choice, where the platform allows bring-your-own-model.

Visual flows, proprietary connector configurations and stored conversation memory are the common traps. A flow built from drag-and-drop blocks has no meaningful translation into Python or TypeScript, so leaving means a rebuild. Stored conversation memory is the subtler trap: even when you can download transcripts, the platform's summarisation and retrieval layer is not included, so a new system starts with raw history and no learned context about each customer.

The exit test we use

Before committing, export a small agent and try to run it elsewhere. If that takes more than a day, price the rebuild into your decision. Open standards such as the Model Context Protocol reduce the tool-integration part of this problem, because the same tool server can be reused across clients.

Where is each platform's ceiling?

Every platform stops being useful at a predictable point:

• Hosted low-code builders stop at custom logic. They are fast for approvals, FAQs and simple ticket routing, but they struggle with branching logic that needs unit tests, with strict data residency, and with evaluation that runs in your CI pipeline.
• Cloud-provider services and model-vendor APIs stop at cross-vendor flexibility. Both integrate cleanly with their own ecosystem, identity and logging. The ceiling appears when you want to swap models, run one agent across two clouds, or inspect intermediate reasoning steps beyond what the console exposes.
• Open-source frameworks stop at your own team's capacity. You get full control of state, retries and tool design, but you also own tracing, secrets, rate limits and upgrades when the framework changes its API. An honest agent framework comparison must count that maintenance, because it recurs every quarter.

What does build-your-own cost to match a platform?

Matching a platform means rebuilding orchestration, tool connectors, evaluation, observability and access control. We have not published cost-to-match figures per platform, and we would rather say so than invent them. What we can give you is the structure for working them out yourself.

Build versus buy: the cost lines

A fair build vs buy AI agent comparison needs the same lines on both sides:

• Initial build: engineering time to reproduce orchestration, connectors, evaluation and access control.
• Monthly run cost: hosting, tracing and monitoring for the custom build, or the platform bill for the bought option.
• Model usage: tokens consumed per completed task, which is usually similar on both sides.
• Maintenance time: engineering hours each month for upgrades, secrets, rate limits and breakages.

In our experience, skipping maintenance is a frequent reason a build looks cheaper than it is, so give it its own line rather than folding it into the build estimate.

Break-even logic

The break-even depends on volume. Below a certain monthly run count, usage billing stays cheaper than an engineer's time. Above it, a custom build tends to win. To find your own point, take the one-off build cost and divide it by the monthly saving, which is the platform bill minus the custom run cost and maintenance cost. That gives the number of months to recover the build.

For example, if a platform costs more per month than a custom build's hosting and upkeep combined, the gap is your monthly saving. If the gap is small, the payback period stretches past the point where requirements change, and buying is the safer choice. If the gap grows with run volume, the payback shortens and a custom build starts to make sense. Rerun the calculation whenever your run volume changes by a large factor, because the answer moves with it.

To make the arithmetic concrete, take invented round numbers: a build that costs 60,000 up front, a platform bill of 5,000 a month, and custom hosting plus maintenance of 3,000 a month. The saving is 2,000 a month, so payback takes 30 months. That is longer than most teams can trust their requirements to stay stable, so buying wins. If volume triples the platform bill to 15,000 while custom costs rise only to 4,000, the saving becomes 11,000 and payback drops to about five and a half months. The same build flips from a poor bet to an obvious one.

Which platform fits which company size?

Small teams should buy and prototype fast, mid-size companies should mix a platform with custom tools, and larger enterprises usually need code they control. The deciding factor is engineering capacity, not budget.

Startups and small teams

Use a hosted builder or model-vendor API to prove the workflow. Keep prompts and evaluation cases in your own repository so a later rebuild starts from something real. If the agent must work against a fixed scope quickly, you can also look at our Moonship MVP option for getting a working version without committing to a platform.

Mid-size companies

Run one cloud-provider service where your data already lives, and write custom tools behind a standard interface. The hard part is usually connecting agents to internal systems, which is where AI integration work can help.

Large enterprises

Expect compliance reviews, audit logging and multi-team ownership. Code-first frameworks tend to fit better. Some enterprises also bring in senior oversight through fractional CTO leadership while the internal team matures.

We default to code-first agents on core systems

We pick the platform per project, after a discovery call, and we default to code-first orchestration when the agent touches a client's core systems. That choice follows from what happens after launch: systems tend to outlive the tools chosen on day one, so we favour setups that are easy to move.

If a hosted builder covers the workflow and exit cost is low, we say so. Not every agent needs a custom build, and recommending one when a licence would do is poor advice.

Start with the broken workflow assessment

Our AI development services cover platform selection, custom builds and agent development. If you are unsure which workflow is worth automating first, take the broken workflow assessment. It is a way to narrow down a candidate workflow before you spend on any platform, and you can bring the result to a conversation with a senior engineer.