Cursor cloud agents are autonomous coding agents that run on Cursor's hosted virtual machines instead of your laptop, so an engineer can dispatch many agents in parallel and let each one open PRs, run tests, and record video demos without keeping a local IDE attached. On May 13, 2026 Cursor shipped its biggest cloud agents update since launch, "Development environments for cloud agents", which adds multi-repo support, Dockerfile-based environment configuration with cached layers, audit logs, scoped secrets, and governance controls. This guide compares Cursor cloud agents to Totalum for one specific question: once an agent finishes the work, what ships to production?
Quick Answer
- Cursor cloud agents are best at parallel, autonomous coding work inside an existing codebase: branch, plan, code, test, open PR, record video.
- Totalum is best at producing and deploying a real Next.js application with auth, payments, database, storage, custom domains, and an MCP control surface.
- The May 13, 2026 Cursor release adds Dockerfile-based environments, multi-repo support, governance, and audit logs. That closes the "agent needs context" gap, not the "agent ships to prod" gap.
- The natural pairing for teams running fleets of agents: trigger Cursor cloud agents to do the code work, then route the result through Totalum's API or MCP to deploy a live, owned app.
- Agencies running many client projects in parallel can register on totalum.app for the embedded build and deploy layer. For an embedding or partnership conversation, book a 30 minute call below.
What Cursor cloud agents are (and what changed on May 13, 2026)
Cursor cloud agents are agents that execute on Cursor's hosted infrastructure instead of your local machine. The cloud agents product launched on October 30, 2025 and was framed as Cursor's "third era" by the team and by external commentary (see Latent.Space's March 5, 2026 essay). Each agent gets its own VM, can install dependencies, run tools, hit APIs, run tests, and iterate in the background while the engineer does other work.
The May 13, 2026 release, branded "Development environments for cloud agents", changed how those VMs are configured and operated. The release notes and the LinkedIn post from Cursor on that date describe four concrete additions:
- Multi-repo environments. A single cloud agent can now clone and operate against multiple repositories in one session. This matters for monorepos that were split into multiple Git repos, or for cross-service refactors that touch a backend and a frontend repo at the same time.
- Environment configuration as code (Dockerfile-based). Instead of describing setup steps in a YAML file that re-runs every time, environments are now defined as Dockerfiles with cached layers. Cursor reports roughly 70% faster startup on warm caches.
- Agent-led environment setup with validation. The agent can propose, build, and validate the environment itself, then save the working Dockerfile for the team. The agent essentially becomes the one who writes the dev container.
- Environment governance and audit logs. Scoped secrets, role-based controls over which agents can run where, and a per-environment audit log of what each agent did. This is the feature set that makes cloud agents safe to roll out across a larger engineering organization.
A separate but related release shipped on May 11, 2026: Cursor in Microsoft Teams. Engineers can mention @Cursor inside a Teams channel and kick off an agent from a chat message. The combination of Teams triggers, cloud execution, and audit logs is the seed of an enterprise pattern: ops or PMs file a request in chat, the agent does the work, governance keeps it auditable.
What did not change on May 13, 2026: cloud agents still produce code, branches, and pull requests against an existing repository. They do not produce a deployed, hostable application with users, auth, payments, and a database wired in. That is the gap we want to talk about next.
Where Cursor cloud agents end and Totalum begins
It helps to separate the AI coding agent stack into three jobs:
- The thinking job. Read the codebase, plan the change, write code, run tests, fix mistakes. Cursor's core IDE and now its cloud agents specialize here. So do Claude Code, Codex, and Cline at the local layer.
- The shipping job. Take an idea, generate a complete app (frontend, backend, database schema, auth flows, payment integration), put it on a custom domain, and let real users register and use it. This is what AI app builders like Lovable, Bolt.new, V0, Replit, and Totalum specialize in. The output is an application, not a PR.
- The orchestration job. Drive many of the agents above from one place: a backend service, a Slack or Teams bot, a script, or another agent. This is what Totalum's API and MCP server are built for.
Cursor cloud agents are at the top of the thinking job. They are excellent at running many parallel coding sessions, especially after the May 13, 2026 environment release. They do not, on their own, take an idea and ship it as a deployed product with a user table, a Stripe checkout, an upload bucket, and a domain pointed at it.
Totalum is built for the shipping job. The output is a real Next.js codebase with TotalumSDK wired in, deployed on Cloudflare, with built-in auth, payments, storage, AI integrations, and a database. It is also driveable from another agent through an API or MCP server, which is the orchestration job.
That is why these two tools are not really competitors. They are layers. The interesting question is when to use each, and when to chain them.
Cursor cloud agents vs Totalum: comparison table
| Capability | Cursor cloud agents (after May 13, 2026) | Totalum |
|---|---|---|
| Where the agent runs | Cursor-managed cloud VMs | Cloud, or driven from any client (CLI, agent, API consumer) |
| What it produces | Code changes, branches, PRs, video demos in an existing repo | A complete deployed Next.js + TotalumSDK application |
| Multi-repo workflow | Native multi-repo cloud environments | Each project is its own repo, multiple projects can be driven in parallel via API |
| Environment configuration | Dockerfile-based with layer caching | Built-in app primitives (auth, payments, DB, storage) preconfigured |
| Governance and audit logs | Scoped secrets, role-based controls, per-environment audit logs | Per-project access, per-deployment history, secret storage |
| MCP support | Cursor supports MCP servers as clients; Cursor SDK is in public beta as of early May 2026 | Totalum exposes itself as an MCP server other agents drive |
| Deploys to production | Through your existing CI or PR merge, deploy is outside Cursor | Yes, custom domain, hosting, HTTPS, scaling are built in |
| Owned code | Yes, code lives in your repo | Yes, code is in your repo or under your account, deployable elsewhere |
| Pricing pattern (as of mid-May 2026) | Per-seat plans with usage on cloud agent runs; pricing has shifted multiple times in 2025 to 2026 | Credit-based plans tied to build, deploy, and agent operations |
The honest summary: if you already have a codebase and you want agents to do the coding inside it, Cursor cloud agents are the strongest current option. If you are trying to go from idea to deployed product, you need something that owns the shipping job, and Cursor is not built for that.
When to use Cursor cloud agents, when to use Totalum, and when to use both
Pick by the job you are doing today.
Use Cursor cloud agents when
- You have an established codebase and want autonomous coding work on existing repos.
- You need many agents working in parallel against the same project without melting your laptop.
- You need multi-repo workflows, like a refactor that touches a backend repo and a frontend repo together.
- You need environment governance and audit logs because the org cares about who ran what and where.
- The deliverable is a pull request, not a launched product.
Use Totalum when
- You are starting from an idea and you need a deployed app, not a PR.
- The application needs auth, payments, a database, file uploads, AI features, and a custom domain.
- You are an agency or SaaS shipping repeatable client projects, and you want a builder that produces production-grade Next.js code your clients can take with them.
- You want to drive the builder from another system: a CLI, another agent, a Teams bot, or a Slack workflow. Totalum's API and MCP server are built for that.
- You want to embed an AI app builder inside your own SaaS for your users.
Use both when
- A team is running cloud agents on existing repos AND shipping new products in parallel.
- An agency uses Cursor cloud agents for client maintenance work and uses Totalum for greenfield client builds.
- An enterprise wires Cursor cloud agents into Microsoft Teams as the "make a change to our app" entry point, and uses Totalum as the "spin up a new internal tool" entry point.
The interesting pattern is the third one. A cloud agent and a deploy platform compose. The pattern looks like: a chat message triggers a Cursor cloud agent to write code, the merged PR triggers a Totalum-managed app to redeploy, and an audit log on each side records exactly what happened.
Tutorial, connecting Cursor cloud agents to Totalum
Cursor supports MCP servers as clients. Totalum exposes itself as an MCP server. That means a cloud agent can use Totalum to create or modify a Totalum project as part of its work. Here is the cleanest setup.
Step 1, install Cursor and enable cloud agents
Make sure you are on a Cursor version that supports cloud agents and development environments. As of May 2026 this requires a paid Cursor plan. On the Cursor settings page, open the Cloud Agents section and confirm it is enabled for your workspace.
Step 2, get a Totalum API key
Register on totalum.app and create a project. Under Account, generate a personal API key. The same credential is what an MCP client will use to authenticate.
Step 3, configure Totalum as an MCP server in Cursor
In your Cursor settings, find the MCP servers section. Add an entry with the Totalum MCP endpoint and the API key as a header. The exact config block looks like this:
{
"mcpServers": {
"totalum": {
"type": "http",
"url": "https://www.totalum.app/api/mcp",
"headers": {
"x-api-key": "tlm_your_personal_api_key_here"
}
}
}
}Save the config. The cloud agent now has Totalum as a tool source. For a full tour of the surface a cloud agent gets when MCP is enabled, see the Claude Code MCP tutorial, which uses the same MCP entrypoint.
Step 4, give the agent a deploy task
Open a cloud agent session in Cursor. Prompt it with a task that ends in "deploy to a Totalum project on the production custom domain". The agent will use the Totalum MCP tools to create or update a project, write the relevant frontend or backend code into it, run a build, and trigger a deploy. Because Totalum owns the auth, payments, DB, storage, and domain layers, the agent does not have to reinvent them.
Step 5, audit and reuse
Both sides log the action. Cursor records what the cloud agent did inside the environment. Totalum records the project change, deploy, and any database edits. If something looks wrong, the audit logs give a complete trail. If something looks right, you can reuse the same Dockerfile (Cursor side) and the same Totalum project template the next time.
This is the cleanest "cloud agents that ship to production" pattern available as of May 2026 in our testing. It works because each tool stays in its lane: Cursor does the thinking, Totalum does the shipping, MCP is the contract between them.
Microsoft Teams plus Cursor plus Totalum, an enterprise agent stack
Cursor in Microsoft Teams shipped on May 11, 2026. The pattern it enables, when combined with the May 13, 2026 cloud agents environment release and a Totalum MCP integration, is the cleanest enterprise agent stack we have seen this year.
Concretely:
- A product manager writes "@Cursor please add a 'cancel subscription' button to our admin app" in a Teams channel.
- Cursor spins up a cloud agent inside a Dockerfile-defined environment.
- The agent reads the current Totalum project via MCP, edits the right files, runs tests, opens a PR.
- A reviewer merges the PR. Totalum redeploys the Next.js app to the production custom domain automatically.
- The Cursor audit log records the agent's actions. The Totalum deploy history records the change.
- The PM gets a Teams message back when the change is live.
This is what "agentic engineering inside a regulated org" looks like in practice. There are still humans in the loop (the reviewer, the PM), and there is auditability on both sides. The novel thing is that none of the work happened on a laptop, and yet the artifact at the end is a real deployed app, not a sandbox.
For agencies running fleets of client projects, the same pattern collapses elegantly: one Teams channel per client, one Cursor cloud agent per request, one Totalum project per client app, one audit log per side. That is roughly the configuration we hear about from agency owners using Totalum's API for client work. If your agency is interested in that setup, the booking link at the bottom of this post is the right next step.
Pricing notes (as of mid May 2026)
Cursor's pricing has shifted multiple times in 2025 to 2026. As of mid May 2026, cloud agent usage is metered separately from local IDE usage, and customers on the Business plan have shared in a public discussion (see Reddit r/cursor, 10+ comment thread from March 2026) that they treat cloud agents as the more expensive option to use, reserved for "fire and forget" tasks where keeping the local IDE attached is not feasible.
Totalum is credit-based. The same credits power local CLI driven builds, MCP-driven builds (from a cloud agent or another tool), and the Totalum web UI. There is no separate "cloud agent surcharge" because the entire builder is hosted; the agent driving the build is the cost center, not the location of the IDE.
For teams pricing a "Cursor plus Totalum" setup against a "Claude Code plus Totalum" or "Codex CLI on Windows plus Totalum" setup, the variable is mostly which coding agent you prefer. The Totalum layer is the same cost in all three.
How Cursor cloud agents compare to the other big coding agents
For full head to head pieces on the coding agent side, see:
The very short version: Cursor cloud agents are the strongest current option specifically for the "many parallel agents on existing repos" pattern. Claude Code is strongest at deep reasoning in a single local session with humans in the loop. Codex is strongest at command line scripting on Windows or Linux with the May 13, 2026 sandbox. Cline is strongest as a free local fallback. All four can drive Totalum via MCP, so the choice of coding agent is mostly a workflow preference, not a deploy decision.
Ready to build with Totalum
If you are evaluating Cursor cloud agents and you also need to ship the resulting apps to production with auth, payments, a database, and a custom domain, the fastest way to see how the pairing feels is to register and try it. Start free at totalum.app.
If you are an agency running multiple client projects in parallel, or a SaaS evaluating Totalum as an embedded AI build and deploy layer for your own users, we would rather have a call than have you read more comparison posts. Book a 30 minute call here: https://calendly.com/cuentas-speedparadigm/30min. Bring a real project. We will walk through the Cursor cloud agent plus Totalum MCP setup live.
Anthropic's parallel to a Cursor preset is Claude Code Skills, and the Claude Code Skills + Totalum guide walks through the Skill plus MCP chain that ends in a deployed app.
FAQ
How much do Cursor cloud agents cost?
As of mid May 2026, Cursor cloud agents are metered usage on top of paid Cursor plans. The exact rate has changed several times during 2025 to 2026, and Cursor publishes the current pricing on its pricing page. Teams in the r/cursor community discussion report treating cloud agent runs as a more expensive alternative to local agents, reserved for fire and forget work or for parallelism beyond what a single laptop can handle.
What did the May 13, 2026 Cursor 3.4 release actually change?
The May 13, 2026 release added four things to cloud agents: native multi-repo support inside a single cloud agent session, Dockerfile-based environment configuration with cached layers (roughly 70% faster warm startup per Cursor's release notes), agent-led environment setup with validation, and governance plus audit log features (scoped secrets, role-based controls, per-environment audit trails). It did not introduce production deployment.
Do Cursor cloud agents support MCP servers?
Yes. Cursor supports MCP servers as clients, and the Cursor SDK was opened in public beta around May 4, 2026, which makes the surface easier to script. Cloud agents inherit the same MCP configuration the user sets, which is how a cloud agent can drive Totalum to deploy an app at the end of its work. See Claude Code MCP tutorial for the equivalent setup pattern on the Claude Code side.
Does Cursor cloud agents support multi-repo workflows?
Yes, after the May 13, 2026 release. A single cloud agent can clone and operate against multiple repos in one session. This is a real change from earlier cloud agent sessions, which were single-repo.
What are the security boundaries on Cursor cloud agents?
Each cloud agent runs in its own VM with a Dockerfile-configured environment. Scoped secrets are exposed to the environment, not stored in the codebase, and the May 13, 2026 release added role-based controls and a per-environment audit log. The combination is intended to make cloud agents auditable for orgs that need to track who ran what against which environment.
Can a Cursor cloud agent deploy my project to a custom production domain?
Not on its own. Cursor's job is to write code and open a PR. To deploy a real, hostable application with a custom domain, auth, payments, database, and storage, the cloud agent needs to drive a deploy platform. Totalum is built to be that target. With Totalum configured as an MCP server in Cursor, a cloud agent can create, modify, and redeploy a Totalum project as part of its task. The result is a production app on a custom domain, not a merged PR.