[HN Gopher] Launch HN: Twill.ai (YC S25) - Delegate to cloud age...
___________________________________________________________________
Launch HN: Twill.ai (YC S25) - Delegate to cloud agents, get back
PRs
Hey HN, we're Willy and Dan, co-founders of Twill.ai
(https://twill.ai/). Twill runs coding CLIs like Claude Code and
Codex in isolated cloud sandboxes. You hand it work through Slack,
GitHub, Linear, our web app or CLI, and it comes back with a PR, a
review, a diagnosis, or a follow-up question. It loops you in when
it needs your input, so you stay in control. Demo:
https://www.youtube.com/watch?v=oyfTMXVECbs Before Twill, building
with Claude Code locally, we kept hitting three walls 1.
Parallelization: two tasks that both touch your Docker config or
the same infra files are painful to run locally at once, and manual
port rebinding and separate build contexts don't scale past a
couple of tasks. 2. Persistence: close your laptop and the agent
stops. We wanted to kick off a batch of tasks before bed and wake
up to PRs. 3. Trust: giving an autonomous agent full access to
your local filesystem and processes is a leap, and a sandbox per
task felt safer to run unattended. All three pointed to the same
answer: move the agents to the cloud, give each task its own
isolated environment. So we built what we wanted. The first
version was pure delegation: describe a task, get back a PR. Then
multiplayer, so the whole team can talk to the same agent, each in
their own thread. Then memory, so "use the existing logger in
lib/log.ts, never console.log" becomes a standing instruction on
every future task. Then automation: crons for recurring work, event
triggers for things like broken CI. This space is crowded. AI labs
ship their own coding products (Claude Code, Codex), local IDEs
wrap models in your editor, and a wave of startups build custom
cloud agents on bespoke harnesses. We take the following path:
reuse the lab-native CLIs in cloud sandboxes. Labs will keep
pouring RL into their own harnesses, so they only get better over
time. That way, no vendor lock-in, and you can pick a different CLI
per task or combine them. When you give Twill a task, it spins up
a dedicated sandbox, clones your repo, installs dependencies, and
invokes the CLI you chose. Each task gets its own filesystem,
ports, and process isolation. Secrets are injected at runtime
through environment variables. After a task finishes, Twill
snapshots the sandbox filesystem so the next run on the same repo
starts warm with dependencies already installed. We chose this
architecture because every time the labs ship an improvement to
their coding harness, Twill picks up the improvement automatically.
We're also open-sourcing agentbox-sdk,
https://github.com/TwillAI/agentbox-sdk, an SDK for running and
interacting with agent CLIs across sandbox providers. Here's an
example: a three-person team assigned Twill to a Linear backlog
ticket about adding a CSV import feature to their Rails app. Twill
cloned the repo, set up the dev environment, implemented the
feature, ran the test suite, took screenshots and attached them to
the PR. The PR needed one round of revision, which they requested
through Github. For more complex tasks, Twill asks clarifying
questions before writing code and records a browser session video
(using Vercel's Webreel) as proof of work. Free tier: 10 credits
per month (1 credit = $1 of AI compute at cost, no markup), no
credit card. Paid plans start at $50/month for 50 credits, with
BYOK support on higher tiers. Free pro tier for open-source
projects. We'd love to hear how cloud coding agents fit into your
workflow today, and if you try Twill, what worked, what broke, and
what's still missing.
Author : danoandco
Score : 40 points
Date : 2026-04-10 16:22 UTC (6 hours ago)
(HTM) web link (twill.ai)
(TXT) w3m dump (twill.ai)
| Mr_P wrote:
| How does this compare to Claude Managed Agents?
| danoandco wrote:
| Claude managed agents is a general-purpose hosted runtime for
| Claude. While Twill focuses on SWE tasks.
|
| And so the SWE workflow is pre-built (research, planning,
| verification, PR, proof of work). Twill is also agnostic to the
| agent, so you can use codex for instance. Additionally you have
| more flexibility on sandbox sizing on Twill
| hmokiguess wrote:
| > Run the same agent n times to increase success rate.
|
| Are there benchmarks out there that back this claim?
| danoandco wrote:
| Yes, this is the pass@k metric from code generation research.
| Found the relevant paper Evaluating Large Language Models
| Trained on Code (Chen et al., 2021) which introduced the
| metric.
| hmokiguess wrote:
| Interesting, and how does Twill uses it in that feature?
| danoandco wrote:
| On the Twill web app, you can run the same task across
| different agents and multiple attempts (each in its own
| sandbox). Then you pick the best result. This is super
| handy for UI work where you can open the live preview for
| each attempt and compare. Next step for us is adding a
| final pass where an agent evaluates the results and
| combines the best parts into one PR.
| hardsnow wrote:
| I've been developing an open-source version of something
| similar[1] and used it quite extensively (well over 1k PRs)[2].
| I'm definitely believer of the "prompt to PR model". Very
| liberating to not have to think about managing the agent
| sessions. Seems that you have built a lot of useful tooling
| (e.g., session videos) around this core idea.
|
| Couple of learnings to share that I hope could be of use:
|
| 1) Execution sandboxing is just the start. For any enterprise
| usage you want fairly tight network egress control as well to
| limit chances of accidental leaks or malicious exfiltration if
| theres any risk of untrusted material getting into model context.
| Speaking as a decision maker at a tech company we do actually
| review stuff like this when evaluating tools.
|
| 2) Once you have proper network sandboxing, you could secure
| credentials much better: give agent only dummy surrogates and
| swap them to real creds on the way out.
|
| 3) Sandboxed agents with automatic provisioning of workspace from
| git can be used for more than just development tasks. In fact, it
| might be easier to find initial traction with a more constrained
| and thus predictable tasks. E.g., "ask my codebase" or "debug CI
| failures".
|
| [1] https://airut.org [2] https://haulos.com/blog/building-
| agents-over-email/
| willydouhard wrote:
| Willy from Twill here.
|
| I love the idea of emailing agents like we email humans! Thank
| you for sharing your learnings:
|
| 1. Network constraints vary quite a bit from one enterprise
| customer to another, so right now this is something we handle
| on a case-by-case basis with them.
|
| 2. We came to the same conclusion. For sensitive credentials
| like LLM API keys, we generate ephemeral keys so the real keys
| never touch the sandbox.
|
| 3. Totally right, we support constrained tasks too (ask mode,
| automated CI fixes). We've gone back and forth on whether to go
| vertical-first or stay generic. We're still figuring out where
| the sweet spot is. The constrained tasks are more reliable
| today, but the open-ended ones are where teams get the most
| leverage.
| 2001zhaozhao wrote:
| 24/7 running coding agents are pretty clearly the direction the
| industry is going now. I think we'll need either on-premises or
| cloud solutions, since obviously if you need an agent to run 24/7
| then it can't live on your laptop.
|
| Obviously cloud is better for making money, and some kind of VPC
| or local cloud solution is best for enterprise, but perhaps for
| individual devs, a self-hosted system on a home desktop computer
| running 24/7 (hybrid desktop / server) would be the best
| solution?
| danoandco wrote:
| For a solo dev running one task at a time, a beefy desktop
| overnight is totally viable. We see a lot of this with the Mac
| Mini hype
|
| Cloud starts to matter when you want to (a) run a swarm of
| agents on multiple independent tasks in parallel, (b) share
| agents across a team, or (c) not worry about keeping a machine
| online
| 2001zhaozhao wrote:
| I would point out that a beefy desktop is probably faster at
| compiling code than a typical cloud instance simply due to
| more CPU performance. So maybe up to 10-ish concurrent agents
| it's faster to use a local desktop than a cloud instance, and
| then you start to get into the territory where multiple
| agents are compiling code at the same time, and the cloud
| setup starts to win. (That's assuming the codebase takes a
| while to compile and pegs your CPU at 100% while doing so. If
| the codebase is faster to compile or uses fewer threads, then
| the breakeven agent count is even higher.)
|
| Other than that, I agree with what you said. I don't know
| what the tradeoffs for local on-premises and cloud agents are
| in terms of other areas like convenience, but I do think that
| scalability in the cloud is a big advantage.
| danoandco wrote:
| Totally right on the compile time. CIs have the same
| bottleneck, and the ecosystem is working on fixing this
| (faster cpus, better caching) in both coding agents and CI
| to improve overall velocity
| piker wrote:
| > 24/7 running coding agents are pretty clearly the direction
| the industry is going now.
|
| This assertion needs some support for those of us that don't
| have a macro insight into the industry. Are you seeing this
| from within FAANG shops? As a solo developer? What? Honest
| question.
| 2001zhaozhao wrote:
| I'm speaking from my daily experience. Sometimes i don't want
| to close my laptop before going to bed because there are
| still 1-2 tasks ongoing in my AI kanban board, so I just
| leave my laptop open (lock but not suspend it) so that the
| agents keep working for a while. I don't even have things all
| that automated.
|
| I anticipate that once I have some more complex agentic
| scaffolds set up to do things like automatically explore
| promising directions for the project, then leaving the AI
| system on overnight becomes a necessity.
| ragelink wrote:
| The core issue for me is, I don't want to trust someone else
| with my code, or run my stuff on their computers. I don't see
| serious enterprise organizations offloading something as
| critical to security outside their own network perimeter.
| gbnwl wrote:
| So instead of using my Claude Code subscription, I can pay the
| vastly higher API rates to you so you can run Claude Code for me?
| willydouhard wrote:
| Anthropic recently killed the ability for third parties to use
| the Claude Code subscription, and it's assumed they're
| subsidising that price heavily. Which is fine, but it's a good
| reminder of the vendor lock-in risk. One policy change and your
| workflow breaks. Twill is agent-agnostic (Claude Code, Codex
| CLI, OpenCode), so you're not betting on any single vendor's
| pricing decisions.
|
| On the cost for solo devs, yeah, if you're one person running
| one agent at a time on your laptop, the sub is probably the
| better deal today. No argument there. The cloud agent model
| starts to make sense when you want to fire off multiple tasks
| in parallel.
| gbnwl wrote:
| Not sure if you've seen it yourself but Claude code can kick
| off parallel agents working in their own worktrees natively
| now. I do it all the time.
| willydouhard wrote:
| Yes, the difference is that Twill launches dedicated infra
| on each sandbox for each task. This means you can work on
| multiple tasks requiring a DB migration for instance.
|
| Also you can fire and forget tasks (my favorite) and don't
| have to keep your laptop running at night.
| verdverm wrote:
| See also Cowork and other upcoming Anthropic features.
|
| See also Show HN, this exact product is frequently shown
| as a github link.
|
| The paradigm shift in Ai means what you are making is (1)
| filling a gap until the primaries implement it, most have
| it in their pipeline if not already (2) how easy it is to
| replicate with said Ai using my preferred tech stack
| willydouhard wrote:
| Cowork does not seem to be focused on engineering, but we
| are fully expecting Anthropic to catch up in this
| category.
|
| What Anthropic can't offer is to let you use Codex or
| combine it with Claude Code. That is why we think non ai-
| labs players have a say in this market.
|
| To your last point, as always there is a buy vs build
| tradeoff which ultimately comes down to focusing on your
| core business which we think still remains important in
| the ai era
| verdverm wrote:
| > as always there is a buy vs build tradeoff
|
| it's a _nonbinary_ decision now
|
| Google has a free, open source take on what you are
| building, looks more mature as well
|
| https://googlecloudplatform.github.io/scion/overview/
|
| My comment about Cowork is more about pointing out a
| different feature set that will crossover with Code. In
| example they have the Task related things as an
| affordance, Code has this coming.
| willydouhard wrote:
| I believe there is a difference between an open source
| framework and a product. You would still have to manage
| and scale your infra, build the integration layer around
| it to make it accessible where your teams are, fix bugs
| etc...
|
| I am not saying that build is always the bad choice, but
| the tradeoff did not disappear imo
| verdverm wrote:
| I'm surprised how much you push back instead of dig in to
| understand more. I have heard mentor time is way down at
| YC since they stopped doing things that don't scale. You
| could be asking questions to better understand where
| you'd fit in with users and how to better position
| yourself. We are your market, how do we see the world
| now, post-ai?
| dennisy wrote:
| Congrats on the launch, the agentbox-sdk looks interesting, but
| seeing as the first commit was 3 days ago - I feel a little wary
| to use it just yet!
|
| One question, do you have plans for any other forms of sandboxing
| that are a little more "lightweight"?
|
| Also how do you add more agent types, do you support just ACP?
| willydouhard wrote:
| Thank you! agentbox-sdk is very recent so it is not stable just
| yet indeed!
|
| For the lightweight sandbox, can you give an example?
|
| Currently we support main coding CLIs, ACP support is not
| shipped yet.
| a_t48 wrote:
| Does it support running Docker images inside the sandbox?
| willydouhard wrote:
| Yes, for instance Twill is running a local postgres and redis
| directly in the sandbox using docker compose when running on
| our codebase.
|
| This is what enables Twill to self verify its work before
| opening a PR
| senordevnyc wrote:
| How does this compare to something like Cursor Cloud Agents with
| a solid set of skills and tools?
| danoandco wrote:
| Similar but reusing lab-native CLIs like Claude Code or Codex,
| which they perform RL on. And so in the long-run, we believe
| this approach wins over custom harnesses.
| auszeph wrote:
| I built an internal version of this for my workplace.
|
| Something very useful that will be harder for you most likely is
| code search. Having a proper index over hundreds of code repos so
| the agent can find where code is called from or work out what the
| user means when they use an acronym or slightly incorrect name.
|
| It's quite nice to use and I'm sure someone will make a strong
| commercial offering. Good luck
| willydouhard wrote:
| I agree and that is why I think monorepos are making a
| comeback.
|
| That said, there are workarounds, like cloning all repos and
| enabling LSP (coding CLIs added that feature) or using a
| dedicated solution for codebase indexing and add a skill/mcp.
|
| Super fast models spamming grep commands are also fun to watch!
|
| Curious to know how you implemented it in house.
| auszeph wrote:
| https://github.com/sourcegraph/zoekt
|
| Run a copy of this in the same VPC. Monorepos would
| definitely help, but that's not the structure we have. I
| didn't want to rely on API limits (or stability) at GitHub
| for such a core feature.
|
| Using this we've had agents find dead APIs across multiple
| repos that can be cleaned up and the like. Very useful.
| wordpad wrote:
| How does this compare to Jules from Google?
| danoandco wrote:
| Jules is similar to Twill with the following differences:
|
| - Twill is CLI-agnostic, meaning you can use Claude Code, Codex
| or Gemini. Jules only works with Gemini.
|
| - We focus on the delegation experience: Twill has native
| integrations with your typical stack like Slack or Linear. The
| PRs comes back with proofs of work, such as screenshots or
| videos.
| eranation wrote:
| Edit: just noticed this is a semi duplicate question to
| https://news.ycombinator.com/item?id=47723506 so rephrasing my
| question - will you have computer use and will you have self-
| hosted runners option? (you being just the controlplane / task
| orchestrator, which is the hardest problem apparently...)
|
| Additional question - what types of sandboxes you use? (just
| docker or also firecracker etc...)
|
| Original comment:
|
| Congrats on the launch!
|
| What's the benefit over cursor cloud agents with computer use?
| (other than preventing vendor lock in?)
|
| https://cursor.com/blog/agent-computer-use
|
| Or the existing Claude Code Web?
| willydouhard wrote:
| We already support computer use out of the box (linux
| sandboxes). Self hosted runners are not available yet, but
| Twill is built on a runtime agnostic layer (see
| https://github.com/TwillAI/agentbox-sdk) so it is feasible!
| eranation wrote:
| HN hug of death probably, but your scorecard returns an error :(
|
| The analysis request failed.
|
| Hosted shell completed without parseable score_repo.py JSON
| output. 11 command(s), 11 output(s). (rest redacted)
___________________________________________________________________
(page generated 2026-04-10 23:00 UTC)