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.

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
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

Start from where the work already is

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.
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

One YAML file

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.

$ 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

Or start it yourself

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 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 →

Check the work

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.

More ways teams use agents

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