# 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
- Any single docs page as markdown: append `.md` to its URL, e.g. https://www.ellipsis.dev/docs/agent-yaml.md
- 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

Infrastructure for your Software Factory

Run Claude Code and Codex in the cloud without thinking about infrastructure. Govern with scoped credentials, budget caps, and full observability. Start with $100 credit, then pay for tokens + 10%.

Start agents from anywhere

Start, steer, and review sessions from the terminal, the web app, the API, Slack, or GitHub. Same agents, same logs, same budgets everywhere.

- Terminal — One command starts an agent on its own cloud machine. Attach, steer, and hand off from your shell. Every harness and model through the same interface.
- Web — Start sessions, watch them run, and search every log from app.ellipsis.dev.
- API — Spawn, manage, and govern cloud agents like any other cloud infrastructure — over REST, or the Python and TypeScript SDKs.
- Slack — Mention an agent in a channel and get the diff back in the thread.
- GitHub — Agents pick up issues, review pull requests, and open PRs of their own.

Governance built in Every session logged, scoped, and capped

- Agents are defined in YAML — One file declares the agent and the environment it runs in: repositories, dependencies, permissions, and budgets. Check it in, review it, and audit changes like any other code. (/platform/sandbox, /platform/sandbox, /platform/agents)
- Credentials set before the session starts — Every session runs on credentials minted just for it: the repositories it may touch, the tools it may call, nothing else. Revoked when the session ends. (/platform/security, /platform/agents, /platform/sandbox)
- Budgets that stop the session — Cap spend per session, per developer, or over time, in the same YAML. A session that hits its cap stops, and the ledger shows where every token went. (/platform/budgets, /platform/budgets, /use-cases/analytics)
- Every step is recorded — Every thinking token, tool call, and diff is recorded and attributed. Logs are searchable by the whole team, if you want. (/platform/observability, /platform/observability, /platform/cloud)

How it works

1. Define an agent in YAML — Prompt, trigger, model, repositories, credentials, budget. Commit it to your repo and it is live.
2. Start it from anywhere — A GitHub event, a Slack mention, a schedule, the terminal, or the API. Each session runs on its own cloud machine, hundreds at a time.
3. Watch and audit — Every session streams live and is kept afterward: every tool call, diff, and dollar, attributed to a person or a trigger.

Secure, Managed Infrastructure that is very easy to use

Ellipsis is built with governance at scale in mind. Permissions are defined before a session starts. Every agent action is logged. You have full control over your data longevity. SOC 2 Type I: Certified. SOC 2 Type II: In progress.

- Scoped credentials — Minted per session, scoped to the repos you allowed, revoked with the sandbox.
- Zero source retention — Your code lives only in the session sandbox and is deleted with it.
- Full audit trail — Every command, file change, and tool call an agent made, kept after the sandbox is gone.

## /platform — Platform

Managed Cloud Agent Platform

Agents become YAML files. Each session gets scoped credentials, budget caps, and a searchable log.

## /platform/agents — Platform: Agents as code

Agents are YAML files

Deploy with git push

- 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 route tokens through your own Anthropic key or your AWS Bedrock account.

- 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 Anthropic key or Bedrock account — Connect an Anthropic key or your AWS Bedrock account and tokens bill you directly against credits and commitments you already hold. 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.
- Search everything your agents have ever done — Transcripts, recaps, and PR references are all indexed, with semantic search alongside full text, 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 the coding agent your team already uses, on any model, 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.
- 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 /v1/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.

## /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 /v1/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

Any harness, any model: Ellipsis is the infrastructure under whichever agent 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
- Cursor (/agents/cursor) — not available yet
- Grok Code (/agents/grok) — not available yet
- Antigravity (/agents/antigravity) — not available yet
- OpenCode (/agents/opencode) — not available yet
- Pi (/agents/pi) — 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 agent run, 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

- [Authentication](https://www.ellipsis.dev/docs/api/authentication): Create an API key in the dashboard and send it as a bearer token on every request to https://api.ellipsis.dev.
- [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.
- [Python SDK](https://www.ellipsis.dev/docs/api/python-sdk): Drive Ellipsis agent sessions from Python. Install ellipsis-dev, import ellipsis; every /v1 operation, sync and async.
- [TypeScript SDK](https://www.ellipsis.dev/docs/api/typescript-sdk): Drive Ellipsis agent sessions from TypeScript. Install @ellipsis-dev/sdk; every /v1 operation typed from the API spec, no runtime dependencies.
- [Automations](https://www.ellipsis.dev/docs/cli/automations): List, run, create, and move automations from the terminal. agent automation run invokes a saved agent exactly as defined.
- [Agent CLI](https://www.ellipsis.dev/docs/cli): Install the agent CLI with Homebrew, log in, and type agent "prompt" to run a cloud agent from your terminal. Subcommands cover scripts and CI.
- [Platform](https://www.ellipsis.dev/docs/cli/platform): Manage environments, sandbox secrets, and files, rebuild the sandbox image, and check integrations, analytics, budget, and usage from the terminal.
- [Sessions](https://www.ellipsis.dev/docs/cli/sessions): Start a cloud agent session with agent "prompt", steer it live, and drive sessions from scripts with agent session get, list, search, connect, stop, diff, and export.
- [code_review.yaml](https://www.ellipsis.dev/docs/code-review/configuration-yaml): The optional review pipeline file. Every field, type, and default, plus custom reviewers, the description stage, the gatekeeper, budgets, and permissions.
- [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.
- [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.
- [agent.yaml](https://www.ellipsis.dev/docs/agent-yaml): Every field of an automation's YAML file, with types, defaults, and allowed values. The schema is strict, so an unknown key fails validation.
- [Automations](https://www.ellipsis.dev/docs/automations): An automation is a saved agent that runs on a trigger or when invoked. Define it as YAML under agents/ in your repository, or through the API.
- [Environments](https://www.ellipsis.dev/docs/environments): An environment is the machine a session runs in, defined once as YAML and referenced by name from sessions, automations, and the organization's defaults.
- [Introduction](https://www.ellipsis.dev/docs): Ellipsis runs coding agents in the cloud. Start a session with one command, define automations as YAML, and govern all of it with budgets and scoped permissions.
- [Organization](https://www.ellipsis.dev/docs/organization): The defaults and ceilings every session resolves against, spend limits, credits and billing, and the security boundary. What an administrator sets once so every developer's bare `agent` is safe.
- [Pricing](https://www.ellipsis.dev/docs/pricing): TODO
- [Quick start](https://www.ellipsis.dev/docs/quick-start): Install the GitHub app and the CLI, run your first cloud session with one command, then turn the same prompt into a scheduled automation.
- [Sessions](https://www.ellipsis.dev/docs/sessions): A session is one agent working in the cloud. Start one with `agent`, steer it live, stop it, and read what it did and cost afterward.
- [Support](https://www.ellipsis.dev/docs/support): TODO
- [Automations](https://www.ellipsis.dev/docs/api/automations): Automations endpoints of the Ellipsis REST API.
- [Environments](https://www.ellipsis.dev/docs/api/environments): Environments 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.
- [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.
- [Secrets](https://www.ellipsis.dev/docs/api/secrets): Secrets endpoints of the Ellipsis REST API.
- [Sessions](https://www.ellipsis.dev/docs/api/sessions): Sessions endpoints of the Ellipsis REST API.
- [How to automate your daily standup](https://www.ellipsis.dev/docs/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/guides/how-to-build-a-custom-slackbot-with-access-to-your-code): Add one slack.yaml to your .ellipsis repository to run a team Slackbot that answers from your codebase, routes per channel and per person, opens pull requests, and keeps every conversation searchable.
- [How to give agents the tools and credentials your build needs](https://www.ellipsis.dev/docs/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 route GitHub mentions by repository](https://www.ellipsis.dev/docs/guides/how-to-route-github-mentions-by-repository): Add one github.yaml to your .ellipsis repository to pick which agent answers @ellipsis in each repository, with its own prompt, token scope, sandbox, and budget.
- [How to route Linear mentions by team and project](https://www.ellipsis.dev/docs/guides/how-to-route-linear-mentions-by-team): Add one linear.yaml to your .ellipsis repository to pick which agent answers @ellipsis on each Linear team's or project's issues, with its own prompt, repositories, and budget.
- [How to turn Sentry alerts into root-cause diagnoses](https://www.ellipsis.dev/docs/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.
- [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.
- [DELETE /automations/{automation_id}](https://www.ellipsis.dev/docs/api/automations/delete-automations-automation_id): Delete an automation, by id or by name.
- [GET /automations/{automation_id}/metrics](https://www.ellipsis.dev/docs/api/automations/get-automations-automation_id-metrics): Return an automation's session distribution and trailing spend, by id or by name.
- [GET /automations/{automation_id}](https://www.ellipsis.dev/docs/api/automations/get-automations-automation_id): Return one automation, by id or by name.
- [GET /automations](https://www.ellipsis.dev/docs/api/automations/get-automations): List automations.
- [POST /automations/{automation_id}/link](https://www.ellipsis.dev/docs/api/automations/post-automations-automation_id-link): Move an automation into a repository, by id or by name.
- [POST /automations/{automation_id}/sessions](https://www.ellipsis.dev/docs/api/automations/post-automations-automation_id-sessions): Invoke an automation.
- [POST /automations/{automation_id}/unlink](https://www.ellipsis.dev/docs/api/automations/post-automations-automation_id-unlink): Take over an automation from its file, by id or by name.
- [POST /automations](https://www.ellipsis.dev/docs/api/automations/post-automations): Create an automation, managed through the API: no file, live immediately.
- [PUT /automations/{automation_id}](https://www.ellipsis.dev/docs/api/automations/put-automations-automation_id): Replace an automation's definition, by id or by name.
- [DELETE /environments/{environment_id}](https://www.ellipsis.dev/docs/api/environments/delete-environments-environment_id): Delete an environment, by id or by name.
- [GET /environments/{environment_id}](https://www.ellipsis.dev/docs/api/environments/get-environments-environment_id): Return one saved environment, by id or by name.
- [GET /environments](https://www.ellipsis.dev/docs/api/environments/get-environments): List saved environments.
- [POST /environments](https://www.ellipsis.dev/docs/api/environments/post-environments): Create an environment, managed through the API: no file, live immediately.
- [PUT /environments/{environment_id}](https://www.ellipsis.dev/docs/api/environments/put-environments-environment_id): Replace an environment's definition, by id or by name.
- [DELETE /files/{file_id}](https://www.ellipsis.dev/docs/api/files/delete-files-file_id): Delete a file.
- [GET /files/{file_id}](https://www.ellipsis.dev/docs/api/files/get-files-file_id): Return one file's metadata and download link.
- [GET /files](https://www.ellipsis.dev/docs/api/files/get-files): List uploaded files, newest first.
- [POST /files](https://www.ellipsis.dev/docs/api/files/post-files): Upload a file that outlives the sandbox.
- [GET /integrations/github/members](https://www.ellipsis.dev/docs/api/integrations/get-integrations-github-members): List the GitHub organization roster.
- [GET /integrations/github/repos](https://www.ellipsis.dev/docs/api/integrations/get-integrations-github-repos): List GitHub repositories connected to the installation.
- [GET /integrations/linear/teams](https://www.ellipsis.dev/docs/api/integrations/get-integrations-linear-teams): List the teams of the connected Linear workspace.
- [GET /integrations/sentry/organizations](https://www.ellipsis.dev/docs/api/integrations/get-integrations-sentry-organizations): List the connected Sentry organizations.
- [GET /integrations/slack/channels](https://www.ellipsis.dev/docs/api/integrations/get-integrations-slack-channels): List the channels of the connected Slack workspace, fetched live from the Slack API.
- [GET /integrations/slack/members](https://www.ellipsis.dev/docs/api/integrations/get-integrations-slack-members): List the members of the connected Slack workspace, fetched live from the Slack API.
- [GET /integrations](https://www.ellipsis.dev/docs/api/integrations/get-integrations): List connected integrations.
- [GET /budget](https://www.ellipsis.dev/docs/api/platform/get-budget): Return the caller's current budget summary.
- [GET /me](https://www.ellipsis.dev/docs/api/platform/get-me): Return the identity behind the caller's credential.
- [GET /models](https://www.ellipsis.dev/docs/api/platform/get-models): List selectable agent models.
- [GET /settings/organization](https://www.ellipsis.dev/docs/api/platform/get-settings-organization): Get the organization settings.
- [GET /usage](https://www.ellipsis.dev/docs/api/platform/get-usage): Return the caller's usage dashboard data.
- [PUT /settings/organization](https://www.ellipsis.dev/docs/api/platform/put-settings-organization): Set the organization settings.
- [GET /reviews/{review_id}](https://www.ellipsis.dev/docs/api/reviews/get-reviews-review_id): Return one review with findings and outcome.
- [GET /reviews](https://www.ellipsis.dev/docs/api/reviews/get-reviews): List code reviews, newest first.
- [POST /reviews](https://www.ellipsis.dev/docs/api/reviews/post-reviews): Run a code review on demand.
- [GET /sessions/{session_id}/diff](https://www.ellipsis.dev/docs/api/sessions/get-sessions-session_id-diff): Return the session's uncommitted changes as a patch.
- [GET /sessions/{session_id}/export](https://www.ellipsis.dev/docs/api/sessions/get-sessions-session_id-export): Export the complete session history.
- [GET /sessions/{session_id}/output](https://www.ellipsis.dev/docs/api/sessions/get-sessions-session_id-output): Return the session's typed output.
- [GET /sessions/{session_id}/records](https://www.ellipsis.dev/docs/api/sessions/get-sessions-session_id-records): Return the session's stored transcript records, oldest first.
- [GET /sessions/{session_id}](https://www.ellipsis.dev/docs/api/sessions/get-sessions-session_id): Return one session.
- [GET /sessions](https://www.ellipsis.dev/docs/api/sessions/get-sessions): List cloud agent sessions, newest first.
- [POST /sessions/{session_id}/messages](https://www.ellipsis.dev/docs/api/sessions/post-sessions-session_id-messages): Send a message to a session.
- [POST /sessions/{session_id}/stop](https://www.ellipsis.dev/docs/api/sessions/post-sessions-session_id-stop): Stop an in-flight session and return it.
- [POST /sessions](https://www.ellipsis.dev/docs/api/sessions/post-sessions): Start a cloud agent session.