# Vercel's coding agent template is a hosted UI around six CLI agents and one sandbox > A Next.js template where a signed-in user describes a task, Vercel Sandbox checks out their repository, one of six coding CLIs runs inside it, and the result lands on an AI-named branch. **vercel-labs/coding-agent-template** — Multi-agent AI coding platform powered by Vercel Sandbox and AI Gateway - Repository: https://github.com/vercel-labs/coding-agent-template - Stars: 1,792 · Forks: 298 - Language: TypeScript - License: NOASSERTION - Published: 2026-10-07 · Updated: 2026-10-07 · Language: en - Canonical page: https://hysenlabs.com/projects/vercel-labs-coding-agent-template ## Six CLI agents behind one interface The list of supported agents is the first thing worth noting because it is longer than the marketing framing suggests: Claude Code, OpenAI's Codex CLI, GitHub Copilot CLI, Cursor CLI, Google Gemini CLI, and opencode. Each is executed inside a Vercel Sandbox that has your repository checked out. The choice is per task, not global, and it matters because these are not interchangeable behind a common interface. They have different authentication models, different permission prompts, and different ideas of what a tool call looks like. The template's contribution is to normalize the surrounding workflow rather than the agent behaviour, which is also why one feature is explicitly Claude-only: MCP server support, used to extend Claude Code with extra capabilities. The user-facing loop is five steps and deliberately boring: sign in with GitHub or Vercel OAuth, create a task from a repository URL plus a description of what you want, watch real-time logs while the agent works, review the diff and the branch it created, then manage everything from a sidebar with status updates. Multi-tenancy is handled rather than assumed. The README states that each user has their own tasks, their own API keys, and their own GitHub connection, which is the minimum needed to run this as a shared service instead of a single-operator tool. ## Maximum duration and Keep Alive are two different controls The README spends more space on sandbox lifetime than on anything else, and reading it carefully answers the questions a reader actually has about cost and iteration. Maximum duration controls how long the sandbox stays alive measured from the moment it is created, with selectable timeouts from 5 minutes to 5 hours. Everything happens inside that window: agent execution, dependency installation, and any verification you add. When the timeout arrives, the sandbox expires on its own. Keep Alive decides what happens after the task completes, and it defaults to off. With it off, the sequence is: sandbox created with a timeout, agent runs, task completes, changes are committed and pushed to the branch, then the sandbox immediately shuts down and destroys all processes. The README suggests this setting for one-time changes, tasks likely to work on the first attempt, and cost minimization. With Keep Alive on, step five changes: the sandbox stays alive with all processes running, you can send follow-up messages until the timeout expires, and if the project has a dev server such as `npm run dev` it starts automatically in the background. The README's own worked example makes the arithmetic concrete: a one-hour timeout with a task that finishes in ten minutes leaves fifty minutes of follow-up window. The interaction between them is stated explicitly. The maximum duration timeout always takes precedence, so a one-hour sandbox expires after one hour whatever Keep Alive says. Keep Alive only controls whether the sandbox shuts down early. That is the whole rule, and the README is refreshingly unambiguous about it. ## What the task pipeline does before the agent starts The How It Works section in the README describes the pipeline in five steps, and the second one is the most interesting because it happens without blocking anything. The order is: the task is stored in the database, a descriptive branch name is generated with AI SDK 5 and AI Gateway, a Vercel sandbox is created with the repository, the chosen agent analyzes the prompt and makes changes, and git operations commit and push the result to the generated branch. Step two is marked non-blocking, and the README attributes that to `after()` in Next.js 15. The branch name is a nicety rather than a requirement, so waiting for a model call to return before creating the sandbox would add latency for no benefit. Scheduling it after the response is the cheap fix. Everything after that depends on two credentials, and the deployment flow makes this explicit rather than leaving it to discovery. The one-click deploy asks for `SANDBOX_VERCEL_TEAM_ID`, `SANDBOX_VERCEL_PROJECT_ID`, `SANDBOX_VERCEL_TOKEN`, `JWE_SECRET`, and `ENCRYPTION_KEY`, with a note that at least one OAuth provider must be configured afterwards. The database is created for you. The README says a Neon Postgres database is automatically created and connected, which is why the local path needs an explicit `pnpm db:push` while the hosted path does not. ## Running it locally, and the two build flags that differ The local setup path is short and uses pnpm throughout. ```bash git clone https://github.com/vercel-labs/coding-agent-template.git cd coding-agent-template pnpm install # Set up .env.local with required variables pnpm db:push pnpm dev ``` The database layer is Drizzle ORM on Neon serverless Postgres, with `drizzle-kit` behind four scripts. `db:generate` writes migrations, `db:migrate` applies them, `db:push` pushes the schema directly without generating a migration file, and `db:studio` opens the Drizzle Studio browser. For a template where the schema is small and starts from nothing, `db:push` is the sensible first command. The one detail that will look like a mistake is in the package scripts: `dev` runs `next dev --webpack` while `build` runs `next build --turbopack`. Development on Webpack and production builds on Turbopack is an unusual combination, and it means a bug that only appears in the production bundler will not show up under `pnpm dev`. The repository also carries `AGENTS.md`, a `.husky/` directory wired up by a `prepare` script, and both `eslint.config.mjs` and Prettier with a `format:check` script. It also ships `vercel-template.json` and `vercel.json`, which is the metadata the one-click deploy reads. ## License field and LICENSE file do not agree The repository's license field reads NOASSERTION, which is what GitHub shows when it cannot classify the license from the file contents. At the same time the tree contains a `LICENSE` file at the root, and `package.json` is marked private and does not carry a license field of its own. Those two facts sit together without resolution, and the reason to care is specific: this is a template meant to be cloned and deployed, so the license determines whether you can fork it into a product. A NOASSERTION badge tells you nothing either way, and the file contents are the only place the answer lives. The version tells a similar story. `package.json` reads 2.0.0, and the repository has no releases at all, so there is no changelog to say what changed in 2.0.0 or whether 1.x and 2.x differ in a way that affects you. For a project meant to be deployed from a template rather than consumed as a library, the absence of releases is a smaller problem than it would be for a package, but it does mean you are tracking main rather than tracking versions. The dependency list is more informative about where the effort went. Alongside the expected `@vercel/sandbox`, `ai`, `drizzle-orm`, and `@octokit/rest`, there are `@git-diff-view/react` and `@monaco-editor/react` for rendering diffs, `arctic` and `jose` for OAuth and token handling, `jotai` for state, and a full Radix UI component set with `components.json` at the root, which is the shadcn/ui configuration file. The UI is a genuine part of the deliverable, not a placeholder. ## Conclusion The template's real job is not running an agent, it is running someone else's agent against a repository the signed-in user already has access to, which is why almost all of the design decisions are about sandbox lifetime and git credentials rather than about prompting. Two settings carry most of the behaviour. Maximum duration, from 5 minutes to 5 hours, starts counting the moment the sandbox is created and always wins over Keep Alive, so it is the real upper bound on a task. Keep Alive, off by default, decides whether the sandbox dies on completion or stays warm for follow-up messages and a background dev server. If you are adapting this, those two are the first knobs. A third thing worth checking before you deploy: the license field reads NOASSERTION while a `LICENSE` file sits at the repository root, so read the file rather than the badge before shipping a fork. ## FAQ ### Can I build my own coding agent? This repository is a starting point for exactly that. It runs Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Cursor CLI, Google Gemini CLI, or opencode inside a Vercel Sandbox against a repository you supply, then commits the result to a generated branch, so the agent logic comes from the CLI you pick rather than from this template. ### Are coding agents safe? The template's answer is isolation rather than permission prompts. Each task runs in its own Vercel Sandbox with the repository checked out, the sandbox is destroyed when the timeout expires or when a task finishes with Keep Alive off, and the agent's changes are committed to a branch rather than pushed to your default branch. ### What does the Keep Alive setting do in the Vercel coding agent template? It decides whether the sandbox shuts down as soon as the task completes or stays alive for the rest of its timeout. With it on you can send follow-up messages and a dev server starts in the background, and it defaults to off. The maximum duration timeout always takes precedence over it. ### Do I need a database to run the coding agent template locally? You need a Neon Postgres connection in `.env.local`, and `pnpm db:push` creates the schema. The hosted path is simpler because the one-click deploy provisions a Neon Postgres database for you. Persistence for tasks, API keys, and GitHub connections all lives in that database. ## Sources - [Issues](https://github.com/vercel-labs/coding-agent-template/issues) - [README](https://github.com/vercel-labs/coding-agent-template/blob/main/README.md) - [vercel-labs/coding-agent-template on GitHub](https://github.com/vercel-labs/coding-agent-template) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vercel-labs-coding-agent-template