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.

Install on GitHub
Documentation
ellipsis.dev@priya-shah in splitshift-hq

What are we shipping today?

JavaScript was built in 10 days. It now runs most of the visible internet. Sleep well.

Repository: splitshift-hq/splitshift-web
Agent: Default
Model: claude-opus-5
Start a cloud session…
+ New session
Reviewing the schedule-conflict rules in splitshift-api2 turns · 3.2k · $0.21 · 2m ago
Backfill the tip-pool report totals for June6 turns · 12.4k · $0.86 · 18m ago
Fix the flaky shift-trade webhook retries11 turns · 4.8k · $1.15 · 41m ago
Draft the unfilled-shift digest cron1 turn · 2.2k · $0.30 · 3h ago
Bump pnpm to 10 across the monorepo4 turns · 9.1k · $0.62 · 1d ago
↓/esc: sessions
01

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.

Issue #208 · splitshift-apiClosed
Add rate limiting to API endpoints

@ellipsis 100 req/min per key, 429 + Retry-After, Redis-backed

Ellipsis
feat: rate limiting on API endpoints
PR #314 · 3 files · +187 −4
✓ checks passed

A labeled issue becomes a pull request

02

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.

agents/feature-builder.yamllive on merge
ellipsis:  version: v1  name: Feature builder  description: Implement the change described on the issueclaude:  model: claude-opus-4-8  system: |    Implement the change the issue describes. Read the surrounding    code first, follow the conventions you find, and run the test    suite before you open the pull request.trigger:  type: react  issue:    on: [opened]    labels: [agent]sandbox:  repositories:    - name: splitshift-apibudget:  session: 2.00  day: 20.00

Prompt, trigger, repos, and caps in one committed file

03

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.

$ agent session start "add rest-period warnings to the schedule editor" --watch

using config "Feature builder" (repo default)

session_7Hq2mX4p · sandbox ready in 8s · splitshift-web cloned

Read src/schedule/editor.tsx · Edit · Bash npm test

✓ opened PR #514 · 6 files · +212 −18

One command from the repo you are standing in

04

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.

$ agent session ide session_9fKq…org-gated

splitshift-web

  • src/lib/trades.tsM
  • src/pages/schedule.tsxM
  • tests/trade_retry.test.ts

@@ acquireTradeLock @@

- if (shift.isOpen(now)) {

+ if (shift.isOpen(now, { lock: true })) {

+ await releaseOnConflict(trade);

$ pnpm test trades

12 passed · in the sandbox

same working tree, same environmentpreview :3000 →

A real editor into the live sandbox

You can use Ellipsis for...

Every use case runs on the same platform. See how it works