Ellipsis vs the GitHub Action

Claude Code agents your whole team can run, govern, and observe

The Claude Code GitHub Action runs an agent inside your CI pipeline. Ellipsis runs the same kind of agents as a managed service, with the triggers, permissions, cost controls, and team-wide visibility you would otherwise build and maintain yourself.

Feature by feature

CapabilityEllipsisClaude Code GitHub Action
Infrastructure to run it
Managed cloud sandboxes, nothing to host
You provision and maintain the CI runners and workflows
Startup time
Warm sandboxes in seconds, dependencies baked into a cached image
Every run boots a runner, checks out, and reinstalls dependencies
Triggers
Pull requests, pushes, cron, and @ellipsis in Slack and Linear
GitHub events inside your CI only
Scheduled agents
Native cron schedules
Scheduled workflows you build and maintain
Team-wide observability
Every session, cost, and diff in one dashboard
Scattered across workflow logs, one run at a time
Spend controls
Per session, day, week, and month caps, enforced live
You track API spend yourself
Permissions
Per-agent GitHub token scopes, enforced at the mint
Whatever the workflow and token happen to allow
Audit trail
Every action and every config version recorded
CI run logs, retained per your CI
Code review on every PR
Built in, from any agent or engineer
A separate thing you build and maintain
Agent definition
One versioned YAML per agent, deployed with git push
Workflow YAML focused on CI steps, not the agent
Secrets
Central, write-only sandbox variable store
GitHub Secrets, managed per repo
Isolation and retention
Ephemeral sandbox per session, zero source code retention
Depends on how your runner is set up
Sandbox ready time
Measured on the Ellipsis monorepo: a full poetry install, baked into the image
First run at a commit
56.8s
Every run after
2.9s
boot 16.4sclone 8.4sinstall dependencies 22.9ssnapshot image 9.1s

A CI runner repeats the checkout and dependency install on every run. Ellipsis pays it once per commit, then starts each sandbox from the cached image with the packages already on disk.

Speed

Sandboxes start in seconds, dependencies included

A CI workflow pays the same tax on every run: boot a runner, check out the repo, install dependencies. Ellipsis bakes the install into a cached sandbox image, so the first session at a commit pays it once and every session after starts with your packages already on disk. Measured on our own monorepo: 56.8 seconds once, then 2.9 seconds.
  • Dependency installs run at image build, not in every session
  • A new commit reinstalls only what changed
  • Two YAML fields: image.dockerfile_append and image.setup
Sessionslive
Flagged 1 risk on splitshift-api #1841
Dropped column without backfill
$0.21
12.0K tok
just now1m30s
Posted daily standup to splitshift-hq #engineering
4 merged, 2 awaiting review
$0.05
3.3K tok
just now22s
Opened splitshift-web #314
Implement CSV export
$0.42
31.2K tok
22s ago4m02s
Approved splitshift-api #1839
Add rate limiting to /v1
$0.18
9.1K tok
1m ago48s
Reviewed splitshift-web #1842
Fix connection leak on error path
$0.31
18.4K tok
3m ago1m12s

Observability

Every session in one place

A CI job leaves its output in scattered workflow logs, one run at a time. Ellipsis records every session in one dashboard: how it was triggered, what it changed, what it cost, and the full step-by-step trace, across every repo and every agent your team runs.
Tool callsmerge-referee
Bash
pytest -k auth · passed
Allowed
Edit
tests/test_auth.py
Allowed
gh pr merge
GH_TOKEN is read-only
Blocked
Grep
"flaky" · 3 matches
Allowed
Read
tests/test_auth.py
Allowed

Permissions

Decide what agents can do before they run

The GitHub Action can do whatever its workflow and token allow. With Ellipsis each agent's GitHub token is narrowed to the permissions and repos its YAML grants, enforced by GitHub at the mint, and spend is capped per session, per day, and per month while the agent runs.
Steps · 152Show thinking
152Commit pushed28 tok
151Bashgit commit -m 'Release connection on error path'20 tok
150thinkingWrite a clear commit message
149assistantGreen. Committing the fix.14 tok
148Bashpytest -k pool · 142 passed24 tok
147Editapi/pool.ts · +12 −426 tok
146thinkingPatch the finally block and add a test

Tracing

See every step, from thinking to diff

See the reasoning behind every change, not just the change. Each session records the agent's thinking, the tools it called, the tests it ran, and the diff it shipped, so a failed or surprising session is something you can actually inspect.

Keep the agent, add the cloud layer

Run your agents as a managed service, with the triggers, governance, and visibility a CI workflow leaves to you.