I'm so happy to hear this — your experience was what we hoped to enable!

lffgggg excited to see where you take lingo log :)

Seems like an important project to unlock a whole amount of productivity.

Although, Sculptor does not use work trees, but that is an implementation detail.

It's the new TODO app. Anthropic are just going to build one or acquire one of these soon and the rest will be dead.

haha honestly a little bit ya. One key thing we've learned from working on this is that lowering the barrier to working in parallel is key. Making it easy to merge, context switching, etc are all important as you try to parallelize things. I'm pretty excited about "pairing mode" for this reason as it mirrors an agents branch locally so you can make your own edits quickly and test changes.

We've also shipped "suggestions" under beta (think CI pipelines for your parallel agents) which might feel a little different. The idea is to use LLMs and your regular coding tools (pytest, pyre, ...) to verify that the code produced by the agents is actually correct.

Definitely! I'm very excited to get in support both for other coding agents, and for as many language models (and providers) as we can.

Eventually what we want is for the whole thing to be open -- Sculptor, the coding agent, the underlying language model, etc.

Replying to each piece:

> What if my application is not dockerized?

Then claude runs in a container created from our default image, and any code it executes will run in that container as well.

> Can Claude Code execute tests by itself in the context of the container when not paired?

Yup! It can do whatever you tell it. The "pairing" is purely optional -- it's just there in case you want to directly edit the agent's code from your IDE.

> Do they all share the same database?

We support custom docker containers, so you should be able to configure it however you want (eg, to have separate databases, or to share a database, depending on what you want)

> Running full containerized applications with many versions of Postgres at the same time sounds very heavy for a dev laptop

Yeah -- it's not quite as bad if you run a single containerized Postgres and they each connect to a different database within that instance, but it's still a good point.

One of the features on our roadmap (that I'm very excited about) is the ability to use fully remote containers (which definitely gets rid of this "heaviness", though it can get a bit expensive if you're not careful)

> the feature I was most looking forward to is a mobile integration to check the agent status while away from keyboard, from my phone.

That's definitely on the roadmap!

in this context, the container contains the running claude instance, and pairing synchronizes its worktree with your local worktree.

under sculptor, claude code CAN execute tests by itself when not paired. that will also work for non-dockerized applications.

sharing a postgres across containers may require a bit of manual tweaking, but we support the devcontainer spec, so if you can configure e.g. your network appropriately that way, you can use a shared database as you like!

regarding multiplexing: the cognitive overhead is real. we are investigating mechanisms for reducing it. more on that later.

regarding mobile integration: we also want that! more on that later.

You can use git worktree to work in parallel in multiple terminal tabs. It does give a higher cognitive load.

Imbue team member here. The biggest difference between Sculptor and Terragon is the collaboration model. With Terragon, the agent outputs PRs. This works well for simple tasks that agents can one-shot, but is a bit clunky to use for more complex tasks that require closer human-agent collaboration imo. On the other hand, Sculptor is designed for local collaboration. Our agents run in containers too, but we let you (bidirectionally) sync to the containers, which lets you stream in the agent's uncommitted changes, and collaborate in real time. So basically, it feels like you are using Claude Code locally, but you get the safety and parallelism of running Claude in containers. I find this much more usable for real world engineering tasks!

Its not free though. You pay for it by supplying your email address.

Nope, not based on vibekit, but it looks like a cool project!

Our approach is a bit more custom and deeply integrated with the coding agents (ex: we understand when the turn has finished and can snapshot the docker container, allowing rollbacks, etc)

We do also have a terminal though, so if you really wanted, I suppose you could run any text-based agent in there (although I've never tried that). Maybe we'll add better support for that as a feature someday :)

It might be possible to ask claude to write a claude code hook to take a docker snapshot after each finished answer with vibekit to avoid deeply integrating with another third party.

nope but vibekit looks interesting -- will take a look

Hopefully in the next couple of days! You can join the discord and we'll post an announcement when its ready https://discord.gg/GvK8MsCVgk

Yea generally I find GPT 5 does better at reasoning but holy moly even in medium mode the thing can take minutes to come back with a response

sure does :)

See this comment for some differences: https://news.ycombinator.com/item?id=45428185

Yes, but look at Imbue's Investors/Advisors. They obviously have big money behind them.

[dead]

in the works! we want it to be possible to always have the best models and agents available

Thanks!

Please feel free to join discord if you run into any bugs or have any issues at all, we're happy to help: https://discord.gg/sBAVvHPUTE

Suggestions welcome too!

That's super strange — would you mind trying again on a different device? We can't repro. Appreciate your trying!

Just adding that on my iPhone 13 Pro it works fine.

[dead]

Yup -- electron app, typescript / react on the front end, python on the backend

We have some docs here: https://github.com/imbue-ai/sculptor

If you have any specific questions that aren't covered there, please let us know in Discord!

I haven't tried it, but it might work if you set the env var yourself (I think you can create a `.env` file in `~/.sculptor/.env` and it will be injected into the environment for the agent)

I'd give it a good 20% chance of working if you set the right environment variables in there :) Feel free to experiment in the "Terminal" tab as well, you can call claude directly from there to confirm if it works.

ooh this is a great idea -- thanks for sharing!

It's on our roadmap!

Any particular features you'd be looking for when we add support for those models/agents?