Handyst reads your repository, plans the work, edits the code, runs your tests in an isolated sandbox and opens a pull request for your team to review. Every command is sandboxed and logged, and it works with the model you choose.
Reading the code before changing it.
This session is live. Click a changed file to read its diff, type in the chat to steer the agent, or pause the run.
Plugs into where your code and conversations already live, and works in any language in the repo
The problem
Everyone knows how to fix them. They're just never urgent enough to beat the roadmap. So they age, and the codebase pays interest.
Pick a task
Choose a task and watch a replay of how the agent handles it: it reproduces, reads, edits, runs and checks its own work before it hands anything back.
Scripted replays of real-shaped runs. Timings and diffs are illustrative.
test/invoice.test.ts fails on CI a few times a week. Find out why and fix it.
The agent loop
The agent never guesses a whole change in one shot. Each step it picks one tool, runs it, reads the result and decides what's next. Nudge it toward a tool and see the loop adapt.
What it can do
Handyst works the way you would: read first, change what's needed, run it, and hand it over in a form your team already knows how to judge.
Works from the code as it actually is, not from a description of it. It searches, follows imports and reads the tests before it writes a line.
src/
app.ts
routes/
upload.ts
middleware/
auth.ts
lib/
redis.ts
test/
upload.test.ts
helpers.ts
Makes the change across the files it touches, not one snippet at a time.
Executes builds, tests, and tooling in a sandbox, then reacts to the output.
npm ci
added 214 packages in 8s
npm test
✕ resets the window after 60s
npm test
✓ 148 passed
Hands work back the way your team already reviews it.
Every session runs in its own container, so an agent cannot reach past its task.
Nothing merges on its own. Every change waits for an engineer to approve it. The agent can respond to comments, but merge rights stay with people.
Use a frontier model for hard, multi-file changes and a fast, low-cost one for chores. Switch per team or per task.
From sentence to pull request
The same shape every time, whether the task is a one-line fix or a thirty-file upgrade.
Write the change the way you'd brief a colleague: what, where, and how you'll know it works. From an issue, a Slack thread, the CLI or the web app.
New sessionacme/api-gateway
The agent searches the repository, opens the files that matter and reads the tests. It builds its plan from the code as it is, not from a guess.
Explorerg · read_file
src/routes/upload.ts:7 uploadRouter.post("/api/upload", auth, …)
src/middleware/auth.ts:22 req.apiKey = await lookupKey(token)
src/lib/redis.ts:4 export const redis = new Redis(env.REDIS_URL)
test/upload.test.ts:9 upload("key_a").expect(200)
It edits across every file the change touches, in your conventions, on its own branch. Formatting and imports come along.
Changehandyst/rate-limit-upload
src/routes/upload.ts
import { auth } from "../middleware/auth";import { rateLimit } from "../middleware/rateLimit";uploadRouter.post("/api/upload", auth, handleUpload);uploadRouter.post("/api/upload", auth, rateLimit, handleUpload);It runs your builds, linters and tests inside the sandbox. When something fails it reads the output, fixes the cause and runs them again.
Verifysandbox ws-7f3a
✓ Fixed its own failing test before anyone saw it
You get a pull request with a summary, how it was verified and what deserves a second look. Comment on it and the agent pushes a follow-up.
Reviewgithub.com
Summary · How I verified it · Worth a look
3f9c2e1.✓ Approved by a person. Merged by a person.
Sandbox isolation
Every session gets its own container with a copy of the repo, hard resource limits and an egress allowlist you control. Try to break out. Then change the policy.
Try to break out
* everything else deny
curl 169.254.169.254/latest/meta-data/iam/169.254.169.254blocked by egress policynpm ciregistry.npmjs.orgallowed · 214 packagesReview the PR
A clear summary, a real diff, your CI checks and a thread you can reply to. Request a change and watch the agent push a follow-up commit.
Openhandyst-bot wants to merge 1 commit into main from handyst/rate-limit-upload
Summary
POST /api/upload.429 with Retry-After: 60. Other routes are untouched.How I verified it
Worth a look
performance.now(), which the test clock doesn't move. It now uses Date.now().const WINDOW_MS = 60_000;const LIMIT = 10;handyst-bot agent
It can. Request changes with the variable name you want and I'll push a commit.
export async function rateLimit(req: Request, res: Response, next: NextFunction) {Start a session anywhere
Handyst meets your team where the work is described, then reports back in the same place.
acme/api-gateway · Issue #1204
sam-l commented
Repro: curl -F file=@/dev/null …/api/upload gives a 500 instead of a 400.
priya-k commented
@handyst fix this and add a test.
handyst-bot commented
On it in session 9c1e. Reproduced the 500 in the sandbox.
Opened #1207 Return 400 for empty uploads · +18 −2
platform/orders-svc · Merge request !311
jonah.t commented
@handyst the test job fails on the Go 1.23 image. Can you sort it?
handyst commented
TestReserve depends on map iteration order. Sorted the keys and pushed a41be02. Pipeline is green.
#eng-web · Acme
Nadia P. 10:42
@Handyst bump axios to 1.7 in acme/web and open a PR
Handyst APP 10:42
Started session b27d on acme/web.
Handyst APP 10:49
Updated 2 call sites for the new error type. 318 tests pass.
acme/web#2291 Bump axios to 1.7
zsh · ~/src/orders-svc
$ handyst run "Add a /health endpoint with a DB check" --repo acme/orders-svc
▸ sandbox ready ws-3b91 · golang:1.23 · 2 vCPU
▸ plan 4 steps
▸ edit internal/health/handler.go +34
▸ run go test ./...
✓ ok 9 packages
✓ PR https://git.acme.dev/acme/orders-svc/pull/214
$ handyst sessions --watch
3b91 orders-svc done 6m12s PR #214
9c1e api-gateway running 1m40s testing.github/workflows/handyst.yml
on:
issues: { types: [labeled] }
jobs:
handyst:
if: github.event.label.name == 'handyst'
runs-on: ubuntu-latest
steps:
- run: handyst run --headless --json \
--issue ${{ github.event.issue.number }}
env:
HANDYST_URL: https://handyst.techyst.net
HANDYST_TOKEN: ${{ secrets.HANDYST_TOKEN }}Choose your model
Hard refactors deserve the strongest model. Docs and chores don't. Pick a model and a job to see the trade-off between quality, speed and cost.
# Default model for this team
[llm]
model = "anthropic/claude-sonnet-4"
temperature = 0.0
# Optional: send small jobs to a cheaper, faster model
[llm.routing]
bug = "openai/gpt-4.1-mini"
max_cost_per_task = 8.00The strongest planner for multi-file changes and upgrades. Fewer review rounds on hard tasks.
The difference
Inline suggestions save keystrokes. The backlog still needs someone to reproduce, change, test and open the pull request.
Control and security
Security teams ask the same questions every time. Here are the answers, and the log that proves them.
session.startapi-gatewaya41f09run git checkout -b handyst/rate-limit-uploadexit 0c02b7eedit src/middleware/rateLimit.ts+199d11a3net curl 169.254.169.254/latest/meta-datadeniede7a0c4run npm test148 passed51fe2dgit push origin handyst/rate-limit-uploadscoped token7bc3e0pr open #482review req.0d9e6bA fresh container with a copy of the repo, a read-only root filesystem and no host mounts. Thrown away when the session ends.
Short-lived git tokens scoped to one repository. Other secrets are encrypted at rest, injected only where needed and masked in every log.
Each command, edit, network attempt and git operation is recorded with the session and the person who started it, then kept append-only and exportable to your SIEM.
The agent pushes branches and opens pull requests. Your branch protection and reviewers decide what reaches main.
Allowlist your registries and git host. Everything else, including cloud metadata endpoints, is denied and logged.
Sign in with OIDC or SAML. Roles decide who can start sessions, on which repositories, with which models and budgets.
FAQ
If it isn't here, write to us and an engineer who runs Handyst will answer.
Most teams open their first pull request on day one. Connect your git host, pick a repository and a model, and describe a task. We help you tune sandbox policies and review settings during onboarding, and an engineer from Techyst stays on hand while your team finds its rhythm.
No. It pushes to its own branch and opens a pull request. Your branch protection decides what merges, and that means a person approving it. The agent can respond to review comments with follow-up commits, but it never gets merge rights.
Any leading coding model, including Claude, GPT, Gemini and Devstral, plus any OpenAI-compatible endpoint. Stronger models do better on larger, multi-file changes; faster, cheaper ones are ideal for docs and chores. Set a default per team and route small jobs to a lighter model to keep costs down. We'll help you pick for the work you actually do.
Only what your policy allows. By default that means package registries and your git host. Cloud metadata endpoints, host credentials and the open internet are blocked, and every attempt is logged. CPU, memory, process count and session time are capped per session.
Git access uses a short-lived token scoped to the repository in the task. Other secrets come from your secret store, are injected only into sessions that need them and are masked in transcripts and logs. Nothing is baked into prompts.
Well-described changes with a way to check them: bug fixes with a repro, tests, small features, dependency upgrades, migrations, docs and CI fixes. It's less suited to open-ended design decisions, which is why every change arrives as a pull request for review.
Yes. Everything in the web app is available over a REST API and the handyst CLI: start sessions, stream progress, fetch transcripts and read the audit log. Headless mode returns JSON and exit codes, so it slots into scripts and CI.
Pricing isn't per seat, so it doesn't grow every time another engineer starts using it. Model usage is billed at your provider's rates, with per-task cost caps you control. Ask us for a quote.
Point Handyst at a repository, describe a change you've been putting off, and read the pull request over coffee.
$handyst run "the change you keep postponing"
Marco R. reviewer
Staging runs load tests at about 50 uploads a minute. Can this be configurable?