# Ellipsis Ellipsis is a cloud platform for coding agents. You define an agent in a YAML file in your repository and deploy it with git push. Each session runs on its own isolated cloud machine with your repositories cloned in and credentials scoped below any developer's, started by GitHub events, Slack and Linear mentions, Sentry alerts, or a schedule, and it opens pull requests with its work. Which harness and model it runs is a config field; the sandboxes, the permissions, the hard per-session and monthly spend caps, and the recorded transcript of every step are the platform underneath. Everything is reachable from the REST API, the `agent` CLI, and the Python and TypeScript SDKs. The Ellipsis skill teaches any coding agent to use this product in depth: npx skills add ellipsis-dev/cli Its source is https://github.com/ellipsis-dev/cli/blob/master/skills/ellipsis/SKILL.md - Full text of all documentation: https://www.ellipsis.dev/llms-full.txt - Complete OpenAPI specification of the REST API: https://www.ellipsis.dev/openapi.v1.json - Python SDK: https://pypi.org/project/ellipsis-dev/ (`pip install ellipsis-dev`, imports as `ellipsis`) - TypeScript SDK: https://www.npmjs.com/package/@ellipsis-dev/sdk # Website Content (https://www.ellipsis.dev) One section per page, headed by its URL path. ## / — Homepage **Enterprise platform for Cloud Coding Agents** The headline cycles through: Cloud Coding Agents, AI Code Review, Background Agents. Run your team's Claude and Codex sessions in the cloud with isolated sandboxes, scoped permissions, hard budget caps, spend attribution, audit logs, and full observability. - **A fleet of cloud agents, managed like infrastructure** — Each agent runs in its own sandbox with scoped credentials and a hard budget. Developers get parallelism, the platform team gets the audit trail. (/use-cases/development) - **You choose the harness, we handle the infrastructure** — Ellipsis is the infrastructure under whichever agent wins: sandboxes, credentials, budgets, and logs stay the same while the harness and model are config fields. (/platform/cloud) - **Agents are defined as code** — An agent is a YAML file in your repo: the prompt, the model, the sandbox, the permissions, the budget. Like infrastructure-as-code, for your agents. (/platform/agents) - **Code review with your prompts and your models** — Choose the models and prompts, add multiple reviewers, and gate what lands with a filter you write. Too noisy? Write a stricter prompt. (/use-cases/code-review) - **Agents spawn in seconds, with your toolchain installed** — Each agent spawns the full stack and runs the tests in its own sandbox, so ten agents on one repo never clobber each other. (/platform/sandbox) - **Scoped credentials, hard budgets, full audit trail** — Agents stop running on developers’ own credentials. Permissions are minted per session, spend is capped and attributed, and the transcript outlives the sandbox. (/platform/security) - **Spawning agents is as simple as POST /v1/sessions** — Put an LLM decision-maker anywhere in your SDLC with no infra to manage. Spawn a session from any workflow and get typed, structured output back. (/platform/api) - **No data ever leaves your VPC** — Self-host in your AWS account and nothing leaves your VPC. Model calls can route through your own gateway for compliance and logging. (/enterprise) ## /platform — Platform **What the platform does with an agent you define** A laptop can run one agent while you watch it. Running a fleet takes isolation, an always-on runtime, and control. Each page below is one part of that. ## /platform/agents — Platform: Agents as code **Define in YAML, deploy with git push** Prompt, model, triggers, sandbox, and spend caps live in one YAML file. Commit it to deploy, open a pull request to change it, revert to roll it back. Every agent is reviewed and versioned like the rest of your code. - **Agents are defined as code** — An agent is a YAML file in your repo: the prompt, the model, the sandbox, the permissions, the budget. Like infrastructure-as-code, for your agents. - **Agents change only by pull request** — Creating an agent from the dashboard opens a pull request, and the agent goes live when it merges. A PR that edits a config gets a preview version for the sessions it triggers, and an edit that fails validation never deploys: the last good config keeps running. - **Expertise as code, not pasted prompts** — A skill is a version controlled, code reviewed document every agent applies consistently. Domain knowledge becomes one maintained asset instead of the same guidance drifting across a dozen prompts. - **Guidance and code move together** — Repo skills load at the session's checkout SHA with no config needed. A PR that changes both the code and the skill runs with the matching skill version, so guidance never lags the code it describes. - **Explore the agent templates** — Start from a working agent instead of a blank file. Copy the YAML into your repo, adjust the triggers and budgets, and deploy it with a git push. ## /platform/cloud — Platform: Cloud sessions **You can close your laptop now** On the Ellipsis cloud, agents run in isolated sandboxes, so your code is secure and the whole team can see what they did. There is nothing to host and nothing to babysit. - **A fleet of cloud agents, managed like infrastructure** — Each agent runs in its own sandbox with scoped credentials and a hard budget. Developers get parallelism, the platform team gets the audit trail. - **Agents that remember the whole thread** — Every PR, issue, Slack thread, and Sentry alert is one durable conversation. Pushed commits get incremental review instead of amnesiac re-reviews, a reply wakes it in seconds with its working tree intact, and merge closes it. Idle time costs near zero. - **Agents start themselves** — Run on a schedule, react to 15 event types across GitHub, Linear, Slack, and Sentry, or start on demand from the dashboard, API, or CLI. Work starts the moment the event fires, while context is fresh. - **Mention it and it answers in the thread** — Tag @ellipsis on GitHub, Slack, or Linear. It picks up the conversation it was mentioned in, takes the action you asked for, and answers in the same thread. It remembers the conversation, so 'now fix it' works. - **The reviewer is just another agent** — A review agent is the same YAML as any other: it reacts on every head advance of a pull request, holds one conversation per PR, and reviews only the commits it has not seen. Any coding agent can write slop; yours is the one that catches it before merge. ## /platform/sandbox — Platform: Sandboxes **An isolated computer for every session** Each agent works on its own cloud machine: your repos cloned in, credentials scoped below any developer, and nothing left behind at teardown. Give it exactly the tools and access the job needs, and no more. - **A fresh machine for every session** — Every session starts in its own Linux container with the repos already cloned and gh authenticated, and the container is destroyed when the session ends. Size it up to 16 vCPU, 64 GiB of memory, and 24 hours when the job needs it. - **Agents can open PRs, not rewrite history** — Agents never hold a developer's identity. They act through the Ellipsis GitHub App with the repos and permissions you granted at install, and repo administration is not one of them. Your branch protections apply with no bypass, and an agent cannot edit protections, settings, or collaborators, no matter what its prompt says. - **Hand agents exactly the access they need** — Sandbox secrets inject credentials you mint, so you choose the blast radius: give a debugging agent read-only AWS keys and it can tail production logs but never touch a resource. Values are stored write-only. Nothing lands in the config file, and nothing can be read back out. - **Agents only get the access you grant** — Each sandbox gets a GitHub token narrowed to the permissions and repositories in the agent's config, enforced by GitHub when the token is minted. Anything not granted, the agent cannot reach, no matter what its prompt says. - **Bake your environment into the image** — A setup script runs once at image build, after your repos are checked out, and the result is snapshotted. Dependency installs happen on the first session; every session after boots the warm image. Per-session lifecycle hooks cover whatever should not be cached. ## /platform/models — Platform: Models **Every model your agents need, on providers that stay up** Frontier and open-weight models are one line of an agent config. Every call routes through Ellipsis, which retries throttled providers and rolls over to another when one has an outage. Or point an agent at your own Anthropic key, your AWS Bedrock account, or a gateway you run. - **Frontier and open-weight models, one config field** — Claude, GPT, and open-weight models from Z.ai, MiniMax, and Moonshot are all selectable per agent. Open weights cost a fraction of a frontier model on the same harness, so the digest agent and the reviewer do not have to run on the same tier. - **Changing model is changing one line** — The model is a field in the agent config, so switching it is a pull request, not a migration. Nothing else moves: the same sandbox, the same scoped credentials, the same budget, the same transcript. Try a cheaper model on one agent and read the cost breakdown before rolling it out. - **A provider outage does not fail your agents** — Every model call goes through the Ellipsis gateway, not straight to a vendor. A throttled or failing provider is retried with backoff, and if it stays down the same request rolls over to the next provider in the chain. The agent finishes its turn without knowing anything happened. - **Bring your own key, Bedrock, or gateway** — Connect an Anthropic key or your AWS Bedrock account and tokens bill you directly against credits and commitments you already hold. Or register a gateway you run, such as LiteLLM, OpenRouter, Portkey, or a Cloudflare AI Gateway, and point individual agents at it. Every route is verified with a live call before it carries traffic, and no provider credential ever enters a sandbox. ## /platform/observability — Platform: Observability **Log every step, including Thinking and Tool calls** Agent session logs are stored and searchable. You can even download the raw logs and push your local Claude Code sessions to the platform. - **Status and outcomes at a glance** — One live view shows every session across your org: what's running now, what shipped, and what failed, with durations and outcomes by agent and repo. - **Know what every session cost** — Each session reports its exact cost, broken down by tokens, CPU, and memory. Chart spend over time and see it by agent and by repo, so you always know where the money goes. - **Watch a session while it works** — Follow any session in real time: steps stream to the CLI or dashboard as they happen, and a live summary says what the agent is doing right now. The same WebSocket feeds your own tools through the API. - **See every step, from Thinking to Diff** — When a session needs a closer look, open it: the agent's thinking, the tools it called, the tests it ran, and the diff it shipped, with per-step token counts. Every raw transcript is kept as a durable record, so Ellipsis is the system of record for your agent work. - **Open an editor into any live session** — Review and edit the agent's changes in its own sandbox: same working tree, same environment. Run the tests where the agent ran them, and open the dev server it started on a preview port, before anything merges. - **Search everything your agents have ever done** — Transcripts, recaps, and PR references are all indexed, with semantic search alongside full text. Laptop Claude Code sessions sync into the same history, so did-anyone-look-into-this is a query, not archaeology. ## /platform/security — Platform: Security **Define agent permissions as code** Credentials scoped below any developer and revoked at teardown, zero source code retention, and an audit trail for every action. Security your team can verify, not take on trust. - **Scoped credentials, revoked at teardown** — Every session gets its own credentials: a GitHub token limited to the permissions and repos you allowed and an API token scoped to that session, all revoked when the sandbox is torn down. GitHub enforces the scopes at the token mint, so nothing in the sandbox can exceed them. - **Every action, logged and visible** — Zero source code retention: your code exists only inside a session’s sandbox and is deleted when the sandbox is torn down. Every agent action is logged and auditable, so security is something your team can verify, not take on trust. - **SOC 2 certified, audited controls** — Ellipsis is SOC 2 Type 1 certified, with Type 2 in progress. Controls cover security, availability, and confidentiality. Request our report at team@ellipsis.dev. ## /platform/budgets — Platform: Budgets **The bill cannot surprise you** Hard caps per session, per agent, per developer, and per account, declared in the same YAML as the prompt and enforced before a sandbox exists. Spend is attributed to a person, an agent, and a step, so you always know who spent what. - **Spend is capped at every level** — Account, agent, session, and developer each get their own limit, so 'the account may spend this much today' and 'the weekly summary agent may spend a fraction of that' are both one line of config. The tightest applicable cap wins. - **The budget lives next to the prompt** — An agent declares its own budget block: a per-session cap plus trailing daily, weekly, and monthly limits. It deploys by merging, previews on a branch, and is reviewed like the rest of the config, because it is the rest of the config. - **Blocked before a sandbox exists** — A session that would breach a trailing limit never starts: it is cancelled pre-flight and recorded with the exact reason. A running session that reaches its cap stops immediately, and the person whose mention was blocked gets a reply naming the limit. - **Every dollar has a name on it** — Sessions break their cost into tokens, sandbox compute, and fee, with per-step spend on the timeline. Each session ties to a person, an API key, or a parent session, so 'who spent what last week' is a filter, not an investigation. ## /platform/api — Platform: API & CLI **Everything the dashboard does, scriptable** The dashboard is a client of the same API you get. Start sessions from CI and scripts, read typed results back, and let agents spawn agents. - **Spawning agents is as simple as POST /v1/sessions** — Put an LLM decision-maker anywhere in your SDLC with no infra to manage. Spawn a session from any workflow and get typed, structured output back. - **Deploy agents over the REST API** — Call the REST API to start sessions from your own services and internal tools. Spawn an agent from a deploy hook or a webhook handler, poll for status, and read the result back programmatically. - **Agents that return typed data, not prose** — Declare a JSON schema in the agent's YAML and every session exits through it. Downstream automation gets guaranteed shapes, and a session that cannot match the schema fails loudly instead of shipping malformed output. - **Agents become pipeline stages** — An agent with a schema is a function with a contract, so agents chain into pipelines: agent to webhook to script to agent, with no defensive glue. The CLI ships inside every sandbox, so agents can spawn and orchestrate agents. ## /use-cases — Use cases **What teams put agents to work on** The same platform, a different job on each page. Ship changes from an issue to a pull request, review every push before it merges, and put the recurring work on a schedule. ## /use-cases/cloud-agents — Use cases: Cloud agents **The same agent your team runs locally, managed in the cloud** Ellipsis runs Claude Code in isolated cloud sandboxes with your repos cloned and your toolchain installed. Sessions survive the closed laptop, credentials are minted per session, spend is capped, and every step is recorded. It is the upgrade path from one agent on one machine to a governed fleet. - **Agents stop running on developers' own credentials** — Every session gets its own GitHub token, scoped to the repos and permissions you grant and expiring in an hour, plus an API token scoped to that session. Spend runs under hard caps per session, per agent, and per developer. No standing credentials, no surprise bills. - **Sessions keep working after you stop watching** — A cloud session is a durable conversation. It idles when it finishes, wakes when you message it, and picks up with the working tree and transcript intact. Hand off uncommitted local work with one command and the agent keeps going in the cloud. - **Ten agents on one repo, none of them colliding** — Each session runs in its own isolated sandbox with repositories pre-cloned and dependency installs baked into a cached image, so repeat sessions start in seconds. Parallel agents spawn the full stack and run the tests without clobbering each other. - **Every session is recorded, searchable, and replayable** — Watch any session live, or answer which agent session produced PR #123 months later. Every turn, tool call, and thinking block lands in one transcript the whole team can search, and the exact instructions each run launched with are auditable next to what it did. - **The dashboard, the API, the CLI, or the thread you are already in** — Start a session from a terminal, POST /sessions from CI, mention @ellipsis on GitHub, Slack, or Linear, or let a Sentry alert or a cron schedule start it for you. Every entry point produces the same governed session. - **The agent itself is a YAML file in your repo** — Prompt, model, sandbox, permissions, and budget live in one version-controlled file, deployed with git push. Your existing review process becomes the change-control process for your fleet. ## /use-cases/development — Use cases: Development **Cloud coding agents unlock parallelization** Your laptop runs one agent at a time. Ellipsis gives each one its own sandbox with the code and dependencies ready, permission limits so it cannot push to prod, and hard budget caps. Every message is logged and searchable, thinking and tool calls included. - **Describe the change on the issue** — Label an issue and the agent picks it up the moment it opens. It reads the surrounding code, follows the conventions it finds, runs the suite, and opens the pull request. Nobody has to copy the ticket into a prompt. - **The agent doing the work is version controlled** — Prompt, trigger, repositories, and spend caps live in one file in your repository. Creating or changing the agent is a pull request, live on merge, so the review process you already have becomes the change-control process for your automation. - **Hand off a task from your terminal** — Run one command from the repository you are standing in and the agent takes it from there. The repo is cloned at its default branch, dependency installs come from a cached image, and the session streams into your terminal or into a CI log. - **Open an editor into the session that wrote it** — Review the diff in the sandbox where it was made, run the tests in the exact environment the agent used, and open the dev server it started. Reviewing agent work does not mean pulling the branch down first. ## /use-cases/code-review — Use cases: Code review **Code review is an agent you define** Deploy a review agent in YAML: it reacts on every head advance of a pull request, reviews only the commits it has not seen, and runs the suite before it comments. Any coding agent can write slop; yours is the one that catches it before merge. - **Write the review standard into the agent** — The prompt, the model, the repositories it watches, and the spend caps are all yours, in one file in your repository. Tune what it flags and what it ignores the way you tune a linter, and ship the change as a pull request. - **Every push is reviewed once** — The agent reviews only the commits it has not seen yet, anchored at the head it reviewed last. Authors get feedback on what they just pushed instead of the same comments on the same lines, so a long-running branch never turns into review noise. - **A reviewer with a sandbox, not just a diff** — The agent gets your repository on disk with the toolchain installed, so it can run the suite, reproduce the failure, and check the behavior it is worried about. A finding it verified is a finding worth reading. - **Reply on the PR and it answers** — The review is a durable conversation that remembers the whole pull request. Push back on a finding, ask it to fix what it found, or tell it to use the staging database, and it picks up with its working tree intact. Merge closes the conversation. - **Feedback that lands** — Ellipsis measures whether review comments changed the merged code, not just how many comments were posted. - **Volume by severity** — See review volume over time, stacked by blocking, high, medium, low, and trivial findings. - **Know which severities actually get fixed** — For each severity, the share of posted comments that were acted on: the flagged issue resolved on the default branch after merge. Blocking and high findings should land far more often than nits, and they do. - **A full breakdown of comment types** — Every comment is classified (logical bugs, security, performance, maintainability, testing, style, and more) so you can see whether Ellipsis is catching substance or just nits. - **Severity by type, at a glance** — The heatmap crosses every comment type with its severity. Darker cells mean more findings, so you can instantly see where the serious problems cluster: logical bugs skew high, style skews trivial. - **Follow comments through the whole funnel** — Track where comments drop off: findings surfaced by the agent, those that pass the quality gate, the ones posted to GitHub, and finally the ones addressed after merge. A tight funnel means high signal and low noise. ## /use-cases/automations — Use cases: Automations **Automate everything with cloud agents** Agent sessions are defined in code, and can be spawned via CLI, API, in response to webhook events, or on a cron. All the benefits of cloud agents included: isolated sandbox, dependencies installed, full logging, permission limits, and budget caps. - **Every session comes from a config in your repository** — The prompt, the trigger, the repositories it clones, and its spend caps live in one file. Creating or changing it is a pull request, live on merge, so the review process you already have becomes the change-control process for your automation. - **An unattended run can build and test your code** — Each session gets its own container with your repositories cloned and gh authenticated. Dependency installs bake into a cached image, so the nightly run boots the snapshot in seconds instead of installing from scratch, and nothing it writes reaches the next session. - **Read what the 3am session actually did** — Every tool call, every turn, and the exact instructions the agent launched with are recorded, with cost and duration per step. An automation nobody watched is still fully auditable, and the whole history downloads as first-party records. - **Find the run that already looked into this** — One query covers transcripts, recaps, and the pull requests your automations produced, by keyword or by meaning. Months of unattended work becomes something the team can ask questions of instead of a folder of logs. - **It cannot touch what you did not grant** — Scope each agent's GitHub token down to read-only, or to a single repository. GitHub enforces the narrowing when the token is minted, so nothing running in the sandbox can exceed it, and every credential is revoked at teardown. - **A runaway automation stops itself** — Cap what one session can spend, and what this agent can spend across a day, a week, or a month. A session that reaches its cap stops cleanly and records budget_hit, which is not an error, and a run blocked by a trailing limit never gets a sandbox at all. ## /use-cases/background-agents — Use cases: Background agents **Put an LLM decision maker in your SDLC** Some steps in shipping software need judgment, not a script: triaging the failure, choosing the owner, deciding whether a change is safe. Spawn a background agent at that point with one API call. It reads the code, makes the call, and returns an answer your pipeline can act on, inside limits the platform enforces. - **Spawn a decision maker from anywhere in your pipeline** — POST /sessions is the whole integration: one HTTP call from a CI step, a deploy script, or your own service starts an agent session. Declare a structured output schema and the session must exit with JSON matching it, so the verdict feeds straight back into the step that asked. - **The decision maker is a file your team reviews** — Its instructions, model, and environment live in one YAML file in your repository, live on merge. That includes the machine it runs on: append Dockerfile layers to install the tools the decision needs, a database client, a profiler, your own CLI, and they bake into a cached image. - **Judgment you can delegate because the limits are not up to the agent** — Every session records its full log: each tool call, each turn, cost per step, downloadable as one file. Hard budget caps stop a runaway session cleanly, and the GitHub token is minted with exactly the scope the config grants, so a decision maker with read-only access cannot push, no matter what it decides. ## /use-cases/analytics — Use cases: Analytics **Engineering metrics for the age of AI** See what your team is actually shipping. Every metric splits humans from bots, agents rank on the same leaderboards as people, and the same numbers ship via the API and CLI so ROI calculations are grounded in reality. - **See what your team actually shipped** — The headline chart tracks real output (lines changed, PRs merged, reviews, active authors) day by day, with humans and agents counted together. - **Humans and agents on one leaderboard** — Rank every contributor to your repos, engineers and AI agents alike, by lines changed and PRs merged. Ellipsis detects work from any tool that commits to your code, not just Ellipsis agents. - **Spot your most effective reviewers** — Each reviewer is plotted by accuracy (approvals vs. changes requested) and how concise they are (comments per 1,000 lines). The shaded corner is the target: concise and accurate. Bubble size is review volume. The Ellipsis review bot is tuned to land right in it. - **Watch time-to-merge drop** — Each day is the spread of how long PRs took to merge. The box is the p25–p75 range, the tick is the median. A downward trend means changes are getting attention and shipping faster. - **Know where the work is happening** — Break every metric down by repo: lines changed, PRs merged, and how many distinct authors touched each one. Correlate volume with review turnaround to find the repos that need attention. ## /integrations — Integrations **Agents that start where the work already is** An agent is only useful where your team already works. Connect the tools you use and an event there starts a session, with the agent reading and writing back in the same place. ## /integrations/github — Integrations: GitHub **Agents that work where your code review happens** Install the GitHub App and agents react to pull requests, pushes, and issues, answer @ellipsis mentions in any thread, and work with a token scoped to the repositories and permissions you named. Nothing in the sandbox can exceed what you granted. - **Repository events start the work** — An agent declares one event surface and the filters that scope it: a pull request opened against your default branch that touches migrations, a push to a release branch, an issue with a given label. Work starts the moment the event fires, while the context is fresh. - **Every event GitHub emits that matters** — Pull requests, pushes, and issues, each with its own action list. The pushed action covers the open and every later commit, so a reviewer agent stays current on a long-running branch without firing twice on the same commit. - **A token per session, scoped in YAML** — No agent runs on a developer's credentials. Each sandbox gets its own installation token that lives an hour and dies at teardown, narrowed to the repositories and permission scopes the config names. GitHub mints it with that scope, so the limit holds even against a prompt injection. - **Ask for a change where the review is happening** — Mention @ellipsis in a comment, a review, or on a specific line and an agent picks the thread up as its prompt. Replies continue the same conversation with no repeat mention, so a review comment becomes a fix without anyone leaving the pull request. ## /integrations/linear — Integrations: Linear **Turn a Linear issue into a pull request** Connect your workspace and a new issue can start an agent that implements it. Inside the session the agent reads and writes Linear directly, so it pulls the issue, comments its progress, and moves the status without a human relaying anything. - **A new issue starts the work** — One trigger block and a filed issue becomes a running agent. The ticket your team already wrote is the prompt, so nobody translates a description into instructions before the work can begin. - **From ticket to pull request without a relay** — The agent reads the issue, works the problem in its own sandbox, opens a pull request linked back to the ticket, and comments what it did. The issue moves because the agent moved it, not because someone remembered to. - **Agents read and write Linear directly** — Linear is not just the trigger. Any session on a connected account can read issues and comments, update fields, move statuses, and file new issues, so a nightly audit lands in your backlog instead of a log nobody opens. ## /integrations/slack — Integrations: Slack **Start an agent from the thread where the work came up** Mention @ellipsis in a channel or DM the bot, and an agent picks the conversation up as its prompt. It reads the thread for context and answers in place, so the request, the work, and the result all stay where your team is already looking. - **Ask in the channel, get the work back there** — A mention starts a durable conversation in that thread, and replies continue it without mentioning again. The question, the answer, and the pull request it turned into all sit in the same place your team was already discussing it. - **Your Slack agent, not ours** — The built-in responder is a default, not a ceiling. Point a mention trigger at Slack and the agent answering your team is one you defined: the repositories it can see, the model it runs, the prompt it follows, and the budget it spends. - **Every agent can reach the room** — Slack is an output, not only an input. Any session can read a channel for context and post its result where the team reads, so the nightly job's findings arrive as a message on Monday morning instead of sitting in a log. Not available yet: Sentry (/integrations/sentry), Jira (/integrations/jira). ## /agents — Agents **Pick the coding agent your team already uses** Ellipsis is the infrastructure under whichever harness wins. The sandboxes, the credentials, the budgets, and the logs stay the same while the agent and the model are config fields. - **Claude** (/agents/claude) - **Codex** (/agents/codex) - **Copilot** (/agents/copilot) — not available yet - **Gemini** (/agents/gemini) — not available yet ## /agents/templates — Agents: Templates **Starter YAML templates for common tasks** Browse starter agents for the work your team repeats, like triaging CI failures, updating dependencies, and writing release notes. Copy the YAML into your repo and deploy it with Ellipsis. - **Agent Config Builder** (/agents/templates/agent-config-builder) — Interviews you about the agent you want, then opens a pull request that adds a schema-valid agent config YAML to your repository so merging it deploys the new agent. - **Daily Standup** (/agents/templates/daily-standup) — Posts a product-level summary of yesterday's merged pull requests across every repository. - **Skill Maintainer** (/agents/templates/skill-maintainer) — Scans each day's merged pull requests and opens a PR updating your team's skills when the code has moved past them. - **Ellipsis Helper** (/agents/templates/ellipsis-helper) — Explains Ellipsis and walks your team through setting it up, working from the official documentation fetched fresh at the start of every run. - **Session Log Search** (/agents/templates/session-log-search) — Answers questions about your team's session history by searching every cloud agent run and synced laptop Claude Code session, reading their recaps and transcripts, and citing the exact session ids and pull requests behind each answer. - **Docstring Drift** (/agents/templates/docstring-drift) — Checks every merged pull request for docstrings its changes made wrong, and opens a follow-up pull request correcting them. - **PR Screenshots** (/agents/templates/pr-screenshots) — Screenshots the screens a pull request changes, uploads them as org-gated files, and keeps one comment on the PR up to date as commits land. - **Schema Migration Reviewer** (/agents/templates/schema-migration-reviewer) — Reviews database migrations before they merge. ## /compare — Compare **How Ellipsis compares to running agents yourself** Both pages below start from an agent you already run: on your laptop, or wired into a workflow file. Each one is the same agent, and the difference is everything around it. - **vs Claude on a laptop** (/compare/ellipsis-vs-claude-on-laptop) — The same agent, running without you at the terminal - **vs Claude on GitHub Actions** (/compare/ellipsis-vs-claude-on-github-actions) — What a workflow file leaves you to build yourself # Docs - [Ellipsis API](https://www.ellipsis.dev/docs/api): The Ellipsis REST API lives at https://api.ellipsis.dev. Create an API key in the dashboard and send it as a bearer token. - [Webhooks](https://www.ellipsis.dev/docs/api/webhooks): Outbound webhooks push agent session events to your systems. Access is by request while the feature is in a gated preview. - [Configs](https://www.ellipsis.dev/docs/cli/configs): List, validate, create, and deploy agent configs from the terminal. Set which agent runs by default, per repository or for the whole account. - [Agent CLI](https://www.ellipsis.dev/docs/cli): Install the agent CLI with Homebrew and authenticate with a device-code login. Drive sessions, configs, and the platform from your terminal. - [Platform](https://www.ellipsis.dev/docs/cli/platform): Upload files, manage sandbox secrets, rebuild the sandbox image, and check integrations, analytics, budget, and usage from the terminal. - [Sessions](https://www.ellipsis.dev/docs/cli/sessions): Start, watch, connect to, and search agent sessions from the terminal. Open the sandbox IDE and sync local Claude Code sessions. - [Agents as code](https://www.ellipsis.dev/docs/agents-as-code): Each agent is one YAML file in your repository. Merging to the default branch deploys it; branches preview it; git gives you review, history, and rollback. - [Analytics](https://www.ellipsis.dev/docs/analytics): Team velocity measured from your GitHub data, humans and AI agents on the same board. Read the dashboard, then pull the same numbers over the API or CLI. - [Billing](https://www.ellipsis.dev/docs/billing): Ellipsis bills for what each session uses, plus a platform fee. Signup credit funds your first sessions, and spend limits at four levels cap everything else. - [Introduction](https://www.ellipsis.dev/docs): Ellipsis runs coding agents in cloud sandboxes and reviews every pull request. Agents are YAML files in your repository. - [Security](https://www.ellipsis.dev/docs/security): Every session runs in an isolated, ephemeral sandbox with one-hour scoped credentials. What Ellipsis stores, the retention setting, and where prompts go under each Models choice. - [Errors](https://www.ellipsis.dev/docs/python-sdk/errors): Every failure raises a typed exception chosen by HTTP status, carrying the API's error code and request id. - [Examples](https://www.ellipsis.dev/docs/python-sdk/examples): Complete scripts for the common jobs: run an agent in CI, fan out across repositories, watch a session live, and audit last week's work. - [Python SDK](https://www.ellipsis.dev/docs/python-sdk): Drive Ellipsis agent sessions from Python. Every /v1 operation, sync and async, generated from the same OpenAPI spec the API is published from. - [Install and authenticate](https://www.ellipsis.dev/docs/python-sdk/install): Install ellipsis-dev from PyPI and pass an API key. Requires Python 3.10 or newer. - [Pagination](https://www.ellipsis.dev/docs/python-sdk/pagination): Iterating a list method walks every page. The page object also exposes one page at a time when you want the cursor yourself. - [Sessions](https://www.ellipsis.dev/docs/python-sdk/sessions): Start a session and get a handle that polls, messages, and stops it. The handle is sugar over the generated session methods. - [Streaming](https://www.ellipsis.dev/docs/python-sdk/streaming): Watch a session live over the WebSocket stream. Async only, needs the stream extra, and reconnects with resume so a dropped socket loses no records. - [Types](https://www.ellipsis.dev/docs/python-sdk/types): Every request and response is a Pydantic model generated from the OpenAPI spec. Models tolerate new server fields instead of rejecting them. - [Errors](https://www.ellipsis.dev/docs/typescript-sdk/errors): Every failure throws a typed error chosen by HTTP status, carrying the API's error code and request id. - [Examples](https://www.ellipsis.dev/docs/typescript-sdk/examples): Complete scripts for the common jobs: run an agent in CI, fan out across repositories, watch a session live, and audit last week's work. - [TypeScript SDK](https://www.ellipsis.dev/docs/typescript-sdk): Drive Ellipsis agent sessions from TypeScript. Every /v1 operation, typed from the same OpenAPI spec the API is published from, with no runtime dependencies. - [Install and authenticate](https://www.ellipsis.dev/docs/typescript-sdk/install): Install @ellipsis-dev/sdk from npm and pass an API key. No runtime dependencies, ESM only. - [Pagination](https://www.ellipsis.dev/docs/typescript-sdk/pagination): A list method returns a Page. Iterate it with for await to walk every page, or read one page at a time and keep the cursor yourself. - [Sessions](https://www.ellipsis.dev/docs/typescript-sdk/sessions): Start a session and get a handle that polls, messages, and stops it. The handle is sugar over the generated session methods. - [Streaming](https://www.ellipsis.dev/docs/typescript-sdk/streaming): Watch a session live over the WebSocket stream. You supply the socket, the SDK owns reconnect, resume, and protocol negotiation. - [Types](https://www.ellipsis.dev/docs/typescript-sdk/types): Every request and response is typed from the OpenAPI spec. Field names are the API's wire names, so a response object matches the JSON exactly. - [How to trigger agents from your own scripts and CI](https://www.ellipsis.dev/docs/api/guides/how-to-trigger-agents-from-your-own-scripts-and-ci): Start, watch, and stop sessions over HTTP so a CI job or your own service can put an agent in its pipeline. - [Guides](https://www.ellipsis.dev/docs/api/guides): Ellipsis API guides for driving agents from your own code, each with complete requests and the responses they return. - [Agents](https://www.ellipsis.dev/docs/api/agents): Agents endpoints of the Ellipsis REST API. - [Alerts](https://www.ellipsis.dev/docs/api/alerts): Alerts endpoints of the Ellipsis REST API. - [Analytics](https://www.ellipsis.dev/docs/api/analytics): Analytics endpoints of the Ellipsis REST API. - [Files](https://www.ellipsis.dev/docs/api/files): Files endpoints of the Ellipsis REST API. - [Integrations](https://www.ellipsis.dev/docs/api/integrations): Integrations endpoints of the Ellipsis REST API. - [Memories](https://www.ellipsis.dev/docs/api/memories): Memories endpoints of the Ellipsis REST API. - [Platform](https://www.ellipsis.dev/docs/api/platform): Platform endpoints of the Ellipsis REST API. - [Reviews](https://www.ellipsis.dev/docs/api/reviews): Reviews endpoints of the Ellipsis REST API. - [Sandbox secrets](https://www.ellipsis.dev/docs/api/secrets): Sandbox secrets endpoints of the Ellipsis REST API. - [Sessions](https://www.ellipsis.dev/docs/api/sessions): Sessions endpoints of the Ellipsis REST API. - [How to search every agent session your team has run](https://www.ellipsis.dev/docs/cli/guides/how-to-search-every-agent-session-your-team-has-run): Pull laptop Claude Code sessions into the same searchable history as your cloud agents, attributed and linked to the pull requests they produced. - [Guides](https://www.ellipsis.dev/docs/cli/guides): Agent CLI guides for working with agents from the terminal, each with the commands to run and the output they produce. - [Configuration YAML](https://www.ellipsis.dev/docs/code-review/configuration-yaml): Every field, type, and default in kind code_review pipeline files. No YAML is required to enable reviews; a file customizes reviewers, budgets, and which pull requests are watched. - [Gatekeeper](https://www.ellipsis.dev/docs/code-review/gatekeeper): An optional filter stage that judges every reviewer finding against your code before it posts. Off by default; declare a filter agent to add one. - [Code review](https://www.ellipsis.dev/docs/code-review): Ellipsis reviews every pull request as commits land, posting findings as inline comments. One organization-wide toggle enables it; no YAML required. - [Permissions](https://www.ellipsis.dev/docs/code-review/permissions): Ellipsis posts each review itself and only ever comments; reviewers never write to GitHub. Custom reviewer sandboxes are scoped like any agent's. - [Pull request descriptions](https://www.ellipsis.dev/docs/code-review/pull-request-descriptions): Ellipsis keeps a summary of the change at the top of every pull request, rewritten on each push. It owns one marked block; your own text is never touched. - [Quick start](https://www.ellipsis.dev/docs/code-review/quick-start): Enable Ellipsis code review with one org-wide setting. No YAML required; every pull request gets reviewed as commits land. - [Reviewers](https://www.ellipsis.dev/docs/code-review/reviewers): One built-in reviewer, bugs, reads every pull request on Claude Opus 5. Add reviewers with their own prompts, models, and filters, or replace it. - [Which PRs get reviewed](https://www.ellipsis.dev/docs/code-review/which-prs-get-reviewed): One filename, and the repository holding it decides what it governs. Each review then covers only the commits since the last one. - [GitHub](https://www.ellipsis.dev/docs/integrations/github): Install the Ellipsis GitHub App at app.ellipsis.dev/install and pick repositories. It powers every trigger, per-session token, review, and PR comment. - [Integrations](https://www.ellipsis.dev/docs/integrations): Connect the tools your team already works in. Events in GitHub, Slack, and Linear start agent sessions, and agents read and write back in the same place. - [Linear](https://www.ellipsis.dev/docs/integrations/linear): Connect your Linear workspace so new issues start implementing agents and @ellipsis answers on any issue. Scope access per Linear team. - [Sentry](https://www.ellipsis.dev/docs/integrations/sentry): Install the Ellipsis app in your Sentry organization so alerts start diagnosis agents. A recurring issue reaches agents at most once every 6 hours. - [Slack](https://www.ellipsis.dev/docs/integrations/slack): Connect the Ellipsis Slack app from the dashboard. Mention @ellipsis in channels, DM it directly, and let agents post results to your workspace. - [Bring your own AWS Bedrock](https://www.ellipsis.dev/docs/models/bedrock): Point Ellipsis at Bedrock in your own AWS account so agent tokens bill your AWS credits. You grant an IAM role; Ellipsis stores no AWS keys. - [Bring your own Anthropic key](https://www.ellipsis.dev/docs/models/byok): Connect your own Anthropic API key so agent tokens bill your Anthropic account. The Ellipsis platform fee is unchanged. - [Custom LLM proxy](https://www.ellipsis.dev/docs/models/custom-llm-proxy): Route an agent's model calls through your own Anthropic-compatible gateway. You provide the URL and credential; agents opt in per config with llm.proxy. - [Ellipsis-managed models](https://www.ellipsis.dev/docs/models/ellipsis): The zero-setup default: agents run on Ellipsis's own model access. Tokens are metered to your Ellipsis subscription at published per-model rates. - [Models](https://www.ellipsis.dev/docs/models): Every agent names the model it runs on. Ellipsis routes each model call to the provider setup you choose, from zero-setup Ellipsis-managed keys to your own gateway. - [Configuration YAML](https://www.ellipsis.dev/docs/cloud-agents/configuration-yaml): Every field in an Ellipsis agent YAML file, with types, defaults, and constraints. Includes the smallest deployable config and where invalid configs fail. - [Conversations](https://www.ellipsis.dev/docs/cloud-agents/conversations): Every mention and every session you start is a durable conversation. Follow-ups land in the same conversation with full context, not a fresh agent. - [Cloud Agents](https://www.ellipsis.dev/docs/cloud-agents): Agents you define as YAML in your repository, triggered by cron schedules, mentions, and repository events. Each session runs in an isolated cloud sandbox and delivers a real artifact. - [Lifecycle](https://www.ellipsis.dev/docs/cloud-agents/lifecycle): Merge to the default branch to deploy an agent; pull requests preview config changes. Disable with enabled false, delete by removing the file, revive by re-adding it. - [Permissions](https://www.ellipsis.dev/docs/cloud-agents/permissions): Each session runs with its own short-lived GitHub token, never a shared credential. Narrow what the token can do per agent in YAML, down to read-only. - [Quick start](https://www.ellipsis.dev/docs/cloud-agents/quick-start): Install the GitHub app, commit one agent YAML to your repository, and watch its first session run. Zero to a deployed agent in one sitting. - [Sandboxes](https://www.ellipsis.dev/docs/cloud-agents/sandboxes): The isolated machine every agent session runs in. Define the environment in YAML, size compute, open the browser IDE, and preview ports. - [Sessions](https://www.ellipsis.dev/docs/cloud-agents/sessions): Every agent execution is a session. Statuses, exit statuses, the step timeline with live spend, session logs, and how to connect and steer. - [Skills](https://www.ellipsis.dev/docs/cloud-agents/skills): Teach every agent your team's conventions once, as Claude Code skills. Repo skills load automatically; the config's skills list attaches more. - [Triggers](https://www.ellipsis.dev/docs/cloud-agents/triggers): When agents run. A config declares one trigger, a cron schedule, a react event, or an @ellipsis mention. Any agent also starts from the API and CLI. - [How to review every pull request as commits land](https://www.ellipsis.dev/docs/code-review/guides/how-to-review-every-pull-request-as-commits-land): Turn on code review for your organization, then shape it with a pipeline file that scopes what gets reviewed and which reviewers read it. - [Guides](https://www.ellipsis.dev/docs/code-review/guides): Code Review guides, each solving one problem end to end with a complete pipeline file and the review it produced. - [How to add screenshots to every pull request](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-add-screenshots-to-every-pull-request): Have agents upload images that outlive the sandbox and paste org-gated links, so a UI change arrives with proof it renders. - [How to answer codebase questions from GitHub, Slack, and Linear](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-answer-codebase-questions-from-github-slack-and-linear): Let anyone ask a question where the work already lives and get an answer from an agent with the code in front of it. - [How to automate your daily standup](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-automate-your-daily-standup): Replace the standup ritual with a cron agent that reads yesterday's merged pull requests and writes the summary itself. - [How to build a custom Slackbot with access to your code](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-build-a-custom-slackbot-with-access-to-your-code): Turn a mention trigger into a team Slackbot that answers from your codebase, opens pull requests, runs your internal tools, and keeps every conversation searchable. - [How to give agents the tools and credentials your build needs](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-give-agents-the-tools-and-credentials-your-build-needs): Bake your toolchain into a cached image, run setup hooks, and inject credentials so agents can actually build and test your code. - [How to keep pull request descriptions up to date](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-keep-pull-request-descriptions-up-to-date): Rewrite the description on every push so reviewers read what the branch actually does now, not what it did on the first commit. - [How to keep your skills from going stale](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-keep-your-skills-from-going-stale): Run a daily agent that reads the day's merges and opens a pull request when the code has moved past what your skills claim. - [How to prevent documentation drift](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-prevent-documentation-drift): Compare documentation against the code every week and open a focused pull request when a concrete claim has drifted. - [How to review database migrations before they merge](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-review-database-migrations-before-they-merge): Put a specialist reviewer on the pull requests that touch migrations, checking locking, backfills, and rollout order. - [How to teach every agent your team's conventions](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-teach-every-agent-your-teams-conventions): Write your conventions once as a skill and have every agent across every repository load it when the task calls for it. - [How to turn Sentry alerts into root-cause diagnoses](https://www.ellipsis.dev/docs/cloud-agents/guides/how-to-turn-sentry-alerts-into-root-cause-diagnoses): React to Sentry alerts with an agent that reads the stack trace, finds the code path, and posts a diagnosis or opens a fix. - [Guides](https://www.ellipsis.dev/docs/cloud-agents/guides): Every Cloud Agents guide, each solving one problem end to end with a complete config and the artifact it produced.