dregitsky

Thanks! We aggressively spin down idle boxes. We'll put any box to sleep where the agent has finished its turn and you're not connected, and then we'll wake it again if you connect (firecracker VMs can sleep/wake very quickly). We don't charge for sleeping boxes (neither does our infra provider) so this keeps costs down for everyone.

Thanks! Longer term it's hard to say if everything 100% moves to the cloud. I'd guess that some things stay local (e.g. if you need your local hardware or are very are hands-on iterating with the code). But at the moment the average developer coding with AI seems way too local-bound, so we're focused on making remote development more convenient. At some point down the road we may add local as an option too.

Yes it definitely sped up development! The main wins were around parallelization and autonomy:

1) full isolation (filesystem + compute per thread) 2) agents having a working dev environment that runs our app 3) being able to close our laptops and check in from mobile

The combo of these meant we could fire and forget lot of parallel threads like "root cause and fix this bug: add logging, run app, get a repro, write fix, validate live" or "build this feature, test new workflows live, send screenshots" -- and then come back later to review & iterate.

You can get to a reasonable level of this with locally with git worktrees and the right project setup, but in the cloud you can really fly.

Nice! We love hearing about personal setups to solve these same problems. One difference between boxes.dev and your setup is that we spawn an exact copy of the main box for each agent thread, so it's totally isolated. But doing parallel agents on one box can definitely work too, it's just more work to configure a project for it.

Our bet is that a lot of people will want something prebuilt, and that the last-mile UX for making a good coding workspace (including code review, etc) is actually nontrivial, especially at companies.

Thanks! We were also excited about Sprites when it launched but it didn't quite work for us either. And Cursor Cloud Agents is definitely pretty similar -- one area where we differ is that Cursor only uses their custom harness, and we liked using the actual Codex/CC harnesses directly (and wanted to benefit from any improvements big LLM cos are making to their models+harnesses)

What kind of cpu/memory do the vms get?

Default is 4 vCPU / 8 GB memory but it's configurable at the team/project level (can go higher).

Is there a way to define the template that's used, so I can say to a new team member, log in to boxes.dev and all the repos and tools are already there for you?

Yes we're moving in this direction! For the current public version each person sets up their box and then agent threads start on a snapshot of that box. But for companies, what you laid out is 100% the vision and coming soon. No more eng onboarding, and maybe even give non-technical folks a default dev environment where they can spawn agents and prototype.

And where do you get the machines, can we bring our own?

Right now we're using MicroVMs with E2B as our infra provider, but for companies we're exploring how to support bringing your own. Happy to chat if interested!

Nope you're exactly right - we're using microVMs today (Firecracker VMs via E2B) and running that same shape but on customer-owned machines is definitely one approach we're looking into.

And thank you!

To add to what @nab said, the longest ("overnight") runs are usually after going back and forth to build out a big multi-phase plan doc -- especially when each phase has an extensive manual test plan (agent runs the app in a browser, clicks through the workflow, watches logs, confirms behavior, etc).

These can go for many hours from all the manual testing and debugging. Quality really depends on how much you spec things out beforehand, and how you define the test plan / "success" gates. If the agent can't even run the app to test it then things can definitely go off the rails!

It's just one hour of runtime. But we put the machines to sleep very quickly once the agent finishes its work, and then wake when you interact in the UI (e.g. terminal, filesystem, send the agent a followup). We're running on firecracker microVMs so can sleep/wake very quickly, which keeps things nice and responsive.

Re: web searches -- we're running a full linux kernel and the agent runs on the machine itself, so we can't sleep mid run. But conceptually, moving the agent off-box and sleeping during web searches etc would be interesting, but in our experience coding agents are running enough stuff on the machine itself (rg, bash, playwright, etc) that there wouldn't be much savings.

http://www.plottingtool.com/app.html

It's a fully client-side, Tableau-inspired data visualization & exploration tool for CSV / tabular data. I built it around 7 years ago with just ES6 and d3.js (no React etc) but never really finished or "launched" it - perfectionism led to a neverending todo list, and with a target market of only myself I didn't have a strong pull toward solving a real-world use case. I even took some time between jobs thinking I'd build it into a real product, but only managed to burn myself out instead (quite a surprise to learn that could happen on a passion project!)

But it does work - drag in a CSV file (ideally <100MB) and you can make some cool charts and quickly explore a dataset, all without the data leaving your machine. The features aren't very discoverable, but it has stuff like adding derived columns, various fancy charts, row/column sorting, custom colors, etc. I'm sure there are far better tools around these days, but I've still come back to this thing a surprising amount in my day job when I want to whip up a quick histogram or investigate some trend in a medium-size dataset.

Actually a single water molecule is held together by covalent bonds between the O and two H's, and hydrogen bonds (not Van der Waals) are the intermolecular forces responsible for the properties like surface tension and high boiling point.

We might not need the government to fully subsidize healthcare to improve things though. Prices are set so high that hospitals - even nonprofit ones - have huge profit margins (this is better stated in the original [now-paywalled] TIME cover story: http://www.time.com/time/magazine/article/0,9171,2136864,00....). So even without the government paying for everything, there could be regulation to control prices set by healthcare providers.

With restaurant bills, things get rather complicated when everyone orders different items, someone bought a Groupon, etc. Unless people are OK with over/under paying, a bill splitting app can be pretty useful to figure out what everyone actually owes.

Cash works well when everyone has it, but from what I've seen that doesn't happen all that often. Also, you get a lot of restaurants that refuse to itemize the bill (maybe their point of sale system doesn't support it), and sometimes they'll only take 1 credit card. Integration with payment apps is great for that. It goes beyond saving time...an app can help make sure people pay up and the IOUs don't become permanent.

Disclosure: I recently released Grouptuity (https://play.google.com/store/apps/details?id=com.grouptuity), which tries to solve these problems and integrates with Venmo.

Not that it'd help you specifically, but I've found that working with someone else can be really beneficial for getting things finished. For me it was great for keeping stuff on track and staying accountable when it comes to finishing parts of it up. That said, only certain kinds of projects are good for this.