willydouhard

Got it! Yes this is definitely doable, added in the roadmap. We will embed the roadmap in the readme soon.

We see developers build their own setup over SSH with success, so in that sense I agree with you.

However, once you want to trigger tasks from Slack, Linear, or GitHub issues or onboard teammates who aren't comfortable wiring up LXC + tmux + agent forwarding, a managed layer is needed.

I think we're at a moment where builders with great setups like yours and products like ours are feeding each other good ideas. The patterns you figure out in your zshrc inform what we productize, and the workflows we ship give you new things to try. It's a virtuous circle. Everyone should use the right-sized solution for their situation.

Definitely the same category of product. The main difference with cursor is that we reuse raw harnesses from ai-labs (claude code, codex). Cursor rebuilds its own harness. We believe nothing will beat the "natural" harness of each model because of RL.

You are also free to swap/combine these harnesses as you please, which is something Anthropic can't do. For instance claude code implements and codex reviews.

By default each plan has a limit (https://twill.ai/pricing). Then you can manually set an overage limit if you want to.

The ralph loop mode also has the concept of a budget per task.

The main difference is that you can pick/combine coding agent CLIs (claude code, codex, open code). There is no vendor lock-in.

This definitely feels like the end state. We need to improve models, agent/human UX and make the transition from cloud work to local work seemless to fully get there

Yes or when you get good feedback/idea talking to someone, being able to spawn tasks from your phone makes everything much faster

We still need to get an oauth token to connect to GitHub. We started with the GitHub mcp but migrated to giving the gh cli to the agent directly.

One learning we had is that most of the time CLI > MCP

There is room for plan adaptation but the agent has to justify and highlight it in the PR.

Defining the plan/acceptance criteria for long running task is the hard part.

We recently added a Ralph loop mode in that spirit. The implementation won't start until the human and agent align on verifiable criteria and a different agent judges if criteria are met at the end of each run.

Overall I think this problem is not yet completely solved and improvement on both the UX and model judgement are needed

This is very convenient but has limitations. GitHub actions are not built to resume state (conversations in our case) and handle multi player experiences.

However reusing the GitHub workflows out of the box feels really nice

this is great, thanks for sharing

Let us know how it goes!

Thank you for the feedback, we are working on it!

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!

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

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

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.

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

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.

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.

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.

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.

This looks great! Any plan to support other languages like bicep?