How Vercel's eve Works
What it's good at, and where it ties you to Vercel
On this page
eve is Vercel's open-source framework for building AI agents in TypeScript. You write an agent as a folder of files, and eve turns that folder into a running server with the agent loop, crash recovery, a sandbox for running commands, and approvals already built in. That's plumbing you'd otherwise build yourself, and Vercel pitches eve the way it pitched Next.js: "Next.js ended this for the web, and eve is doing the same for agents."
If everything you run is already on Vercel and you're fine with Vercel's pricing, eve is a quick way to ship an agent there. It's open source, but running it anywhere else takes more work than the license suggests. It launched in June and is still in beta.
The Short Version
What You Get
Building an eve agent feels like building a Next.js app. A small agent looks like this:
Each file becomes something the agent can do: a tool file becomes a tool, a skill file becomes a procedure the model can load when it needs it, and a schedule file runs the agent on a timer. You run the agent locally with a dev server and deploy it like any other Vercel project.
Under the hood, every conversation runs as a durable workflow that saves progress after each model call, so on Vercel a crashed server doesn't lose the turn. Approvals use the same mechanism, so a tool can wait days for a person to approve it without keeping a server running.
Each agent also gets a sandbox for shell commands and files, subagents with their own tools, memory, and built-in connections to Slack, Discord, Teams, GitHub, Linear, and more. There's an eval command for testing agents, and on Vercel you can trace every conversation from the dashboard.
For a team whose apps already run on Vercel and will stay there, that built-in plumbing is the main reason to pick eve.
Where It Ties You to Vercel
The license doesn't tie you to Vercel. eve is Apache 2.0, and Vercel documents how to self-host it as a regular Node server, with Docker as the sandbox. Models aren't locked in either: Vercel's AI Gateway is the default, but OpenAI, Anthropic, or a model running on your own hardware work too.
One self-hosted server is easy. More than one is harder. eve's crash recovery comes from Vercel's Workflow SDK, which on Vercel runs on Vercel's own managed service. Off Vercel, the default setup only works inside a single process.
To spread conversations across servers, you plug in a different backend through a setting marked experimental. Vercel's own option for this is a Postgres backend, which Vercel describes as a reference implementation that isn't built for scale or security and has no authentication on its routes. Off Vercel, crash recovery across servers depends on that backend, and it doesn't reliably resume a turn after a server crashes.
A few features only exist on Vercel, including the conversation traces in the dashboard and Vercel's built-in sign-in connections for tools. On Vercel, eve itself is free, but you pay for every Vercel product it runs on, from functions and workflows to sandbox time, model tokens, and tracing, each metered separately.
Changing an Agent That's Already Running
An eve agent is compiled from its files at build time, so changing its prompt, tools, or model takes a new deploy. What that deploy does to conversations already in progress depends on where eve runs.
On Vercel, a deploy doesn't touch work in progress. A conversation that's in the middle of a turn, waiting on an approval, or running subagents finishes on the version it's running on. An idle conversation moves to the new version when its next message arrives and picks up the new prompt and tools, as long as the new version can read its saved state.
So a deploy can't fix an agent that's misbehaving in the middle of a task. It only fixes the next turn.
To change behavior without deploying, you can write a function that eve runs before each regular model call to pick the model, tools, or prompt, for example by reading a setting from your database. That works, but it's code you have to write and maintain.
Conversations also keep depending on the deployment they started on, and when that deployment is deleted, the conversation stops working. Vercel's free plan can delete old production deployments after 30 days, the same amount of time eve keeps an idle conversation by default, so old deployments have to stay around as long as their conversations do.
Off Vercel, upgrading eve itself is harsher: the upgrade strands every open conversation. Requests to an old conversation get an error, and a new one starts empty unless your code copies the old transcript in. In eve's words, "tools, approvals, files, sandbox contents, authored state, and interrupted work do not carry over." Vercel's advice is to pin the exact eve version and upgrade deliberately.
Things to Know Before You Build on It
eve is in beta and ships breaking changes in minor releases, not just major ones. Pin the version and read the changelog before every upgrade.
Crash recovery can run a tool twice. If a server dies right after a tool runs but before eve saves progress, the tool can run again. Anything that charges a card or sends an email needs its own way to check whether it already happened.
New projects ship with placeholder authentication, and Vercel's deployment protection doesn't replace it. Add real auth before anyone outside your team can reach the agent.
eve is a framework, not a service. Each agent is an app you build, deploy, and operate, so its deploys, upgrades, and outages are yours to manage.
eve vs Omnara
Omnara is the open-source agent platform we build, and for agents you run in production, it's the better choice. With eve, an agent is code you build and deploy. With Omnara, it's a service you configure through an API, on Omnara Cloud or your own servers, and that difference avoids the deploy, upgrade, and scaling problems covered above.
You can change a running agent without a deploy. Omnara updates a running agent's model, tools, permissions, or instructions through the API, and the change applies at its next model call, in the middle of the conversation. With eve, a deploy can't fix an agent that's already mid-task.
Deploys and upgrades don't touch running agents. An agent's config lives in Omnara rather than in code you deploy, so shipping a release can't strand a conversation, and there's no old deployment to keep alive for it.
Self-hosting scales without experimental pieces. Omnara's workers are stateless, with each agent's progress saved in Postgres, so you add servers by running more workers. eve's multi-server setup goes through an experimental backend setting, and Vercel's own backend for it is a reference implementation.
An agent isn't limited to one sandbox. Its commands run on machines you attach: your own computers or cloud sandboxes, several at once.
eve keeps the agent in your repo as code, with chat connections, evals, and Vercel's tracing built in, which makes an agent quicker to build. Omnara makes it easier to run, change, and scale once people depend on it.
FAQ
Is Vercel eve open source?
Yes, under Apache 2.0. The Vercel services it uses by default, like Workflow, Sandbox, and AI Gateway, are paid products.
Can eve run without Vercel?
Yes, as a Node server with Docker as the sandbox and any model provider. Running it across several servers depends on an experimental setup, and upgrading eve off Vercel breaks open conversations.
How much does eve cost?
eve is free. On Vercel, you pay for the functions, workflows, sandbox time, model tokens, and tracing your agents use. Off Vercel, you pay for your own servers and model provider.