Surely the days of being able to “bring your own subscription” to a third party platform are also numbered?

On one hand, yes, it doesn't make sense to give out subsidized tokens forever.

On the other hand, subscriptions create lock-in in a way that API pricing doesn't.

I think a more likely end is that subscription value decreases over time because API pricing gets more reasonable, but subscriptions stay because they are a good way of getting money out of people consistently.

Right, subscriptions are not only cheaper because they "create lock-in". They also let you do things like forecast demand and plan your capacity for it, borrow against it sometimes if you need to, and keep somewhat less around because your cashflows are predictable. It is also valuable because it keeps customers around but that's by no means the only reason recurring revenue gets a higher multiple.

This is why "subsidized tokens" is possibly a misnomer. Money at lower variance is worth more than the same money at higher variance. Not "subsidy" so much as reducing risk and passing some of that to a consumer.

You just described the benefits of customers being locked in?

I’m not so sure… Claude backtracked on this when they tried it

> Edit: great answer.

What do you mean by that? If you're being sassy about a downvote then I'll remind you that when you reply to a comment, that person can't downvote your reply. Also this is an account with barely any comments or points, I'm pretty sure they can't downvote at all.

I’ll remind the reader if they downvote without mentioning why, there’s no opinion really being conveyed.

Just a stub of a conversation.

I don’t care about the points. Just the chat, which seems finished.

Sure, no opinion really being conveyed.

But it didn't come from the person you were talking to, so editing on a sarcastic "great answer" doesn't really work.

The person you were talking to just hadn't responded within the first hour. They still might.

If “community outreach” or “marketing” happens to reappear on their agent’s to-do list, then maybe!

As a quick update, the app should be available in the EU now! Sorry about that.

Nice, love the idea of having containers that can work on either local or remote. We may end up reaching out once we start thinking about that.

And thanks re: pricing model. It's a start, and we still have a lot of optimizations to go there to make this as cheap as possible, but we think it's a good base to build upon to make agents as efficient as possible compute-wise.

Please do, interested to add Boxes as a runtime for awman, then workflows could execute in the cloud transparently.

Hey, I'm working on a project that does a similar thing, and I'd be interested in working together, if your up for it? You can learn more about it at https://www.threadedstack.com The project is not live yet, but will be in the next month. Check it out, and if you're interested let me know. Thank

I would certainly be interested. Please reach out to connorjhicks at gmail to discuss!

We're currently running Firecracker VMs in E2B, which separate kernel level isolation. Over the long term, we're open to making it cloud/provider agnostic if you don't like that and want to run in your own cloud.

Right now, since these are just linux machines, agents only have access to what you give them. For most development workflows, this means you're putting development environment variables and keys there.

We're also considering having some sort of key storage construct that allows you to require human confirmation for access to certain other keys, but curious if you have any thoughts on what the ideal UX is.

You can of course just build your ideal solution on the template box (perhaps 2 factor authentication via AWS secrets manager to get access to certain keys that require human confirmation), and update your skills. Then all future threads/forks will have access to that setup.

Oof, I don't think we paid super close attention to the country list when shipping our app. We'll fix this for you, but it might be a few days for things to make it out of review. Really appreciate you trying it out. It's still pretty early so things are still rough around the edges, but we'll be keeping an eye out on our logs for bugs, and feel free to reach out to feedback at boxes.dev if you notice any issues.

Nice -- yeah I definitely think it's possible to get configuration figured out for worktrees, but does require a some setup. Glad you all are in a good place on that front.

RE: setup required to make a project ready for VM deployment, not sure how complex your app is, but we've found that coding agents do a pretty good job at finding your dependencies locally, installing them on the remote, and ensuring your app runs on the remote end. If you have a few minutes, try out our auto-setup. Most people haven't had to lift a finger to get their apps running in VMs.

Hahaha, it was a cheap shot :P

The fun thing is that in some way it's a bit inaccurate. We auto port-forward ports from the remote machines to your localhost, so you can still just go to localhost:3000 or whatever, and it goes to whatever machine you have selected in the desktop app. We'll give you a browser in the mobile app too soon to hit "localhost" on mobile.

Yeah, no. I don't give a fuck about port forwarding to make a remote machine look like it's running on my localhost. I don't want to cede any more of my computing needs to the cloud than I absolutely have to. I like to own my hardware, not rent it.

It's definitely possible to build something like this yourself, but there are a lot of little things we've done that we think add up to a much better UX:

- A dedicated app where you can scroll through your thread/chat history and start a new thread/fork/VM just by typing a new message, along with access to persistent terminals organized by thread/machine. Push notifications as well when your threads are done. Sort of doable via termux/tmux/ssh/etc.

- It takes a little while to get git worktrees set up well to have multiple threads running in parallel. You have to make sure each worktree starts your app on a different port, for example. But some folks are able to get it in a good place through some manual setup work.

- We started hitting resource limits running 5 full copies of our app on 1 laptop (so each agent can test its work separately), but again, if you have a beefy enough machine this might not be a problem.

- We auto-handle port forwarding for you on desktop (and on mobile soon too). Again, you can finagle something like this with tailscale, but it's a pain in the butt to manually track which thread maps to which port on the same machine. We have some magic where if you select a thread in the desktop app, we automatically remap localhost:3000 (or any other port running there) to that thread's machine, so you can just reload your browser locally to test.

These are a few examples. From building this ourselves, we're pretty convinced that you need some sort of UI to do remote development in a super clean way that feels like localhost. But if you're willing to put in the work, you can probably get relatively close yourself!

I'm both Windows and Linux, so either would work for me.

Thanks a ton for the feedback. Yeah, this is something we'll try to solve in the long term. One of the things that makes this work really smoothly for setup and speed is the ability to have a template box that you can instantly snapshot and fork (disk and RAM) to spin up new machines. There aren't many sandbox providers that do that well for running a full app and development environment, but I'm sure there will be more over time. And the per-second pricing means that you only pay when your agent is running.

You could use VPS, but spinning up and down boxes on inactivity takes a long time, and making changes to the template for new machines is less trivial there. If you're only paying for 1 VPS box, then you lose the "multiple independent machines" benefit, and I imagine things start to get more expensive even in the VPS world when you have 10 of them running at the same time (one per thread).

Don’t bother listening to people who give you feedback that your product should be free. They aren’t going to buy your product no matter what you do.

Pretty sure you could accomplish this in a large physical server or even a huge resource VM (that has KVM passthrough) with some sort of microvm technology? Then that would obviate the need for "multiple cloud instance per coding thread", it would just be a microvm on the large server.

Then again, I'm just the guy running his mouth, and you guys are the ones actually doing the work :)

BTW, looks very polished and thought-through, I may have to still give it a try!

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!