We re starting to onboard our first batch of beta users this week
Curious what everyone here is working on if you re building AI agents (OpenClaw, workflows, anything), drop it below.
Happy to help you get it deployed on Maritime or give early access.
Maritime
@maria_gorskikh1 $1 per agent is honestly pretty interesting. how does the pricing work once an agent starts needing more compute or running continuously? congrats on the launch!
Maritime
@kamal_sharma26 The $1/month includes 1 vCPU, 2 GB RAM, and 5 GB storage, with automatic sleep/wake. For heavier workloads, you can add RAM and storage at flat monthly rates. If you need an agent that never sleeps, always-on is an extra $20/month per agent. Details here: maritime.sh/pricing. What kind of agents are you building?
Macaly
$1 per agent computer is wild 😮 do people keep them running 24/7 or bursty?
Maritime
@petrkovacik Mostly bursty, and that's the whole reason the price works. Most agents do something for a few minutes, then sit idle waiting on a user or a webhook, so we sleep the VM and you keep paying for the slot, not the runtime. What's your usage pattern at Macaly?
the persistence claim is the interesting part and id want to know exactly what survives a sleep wake cycle. if the browser profile goes with it, cookies, localstorage, logged in sessions, then thats the actual product and id say it in those words. if only the disk survives and the profile resets, agents re-authenticate constantly and that cost shows up as time rather than dollars. the failure ive hit running agents against real sites all day isnt lost state, its stale state. an agent that keeps its own view of the world for weeks ends up confidently wrong, and that bit me directly today. i had a cached page state that made me assert something a fresh anonymous fetch disproved in one call. so persistent storage needs a companion idea, which parts are durable and which have to be re-derived on wake. whats cold wake latency looking like in practice? at a dollar an agent the sleep wake tradeoff is basically the whole engineering story, and for anything interactive the first action after a wake is the one people judge you on.
Maritime
@rabnoor_s We preserve both disk and VM memory across sleep/wake, including the browser profile, cookies, localStorage, and in-memory browser state. Login state carries over, though sites can still expire or revoke sessions.
Wake time is around a second, with page refreshes or reconnects adding to the first action’s latency.
@maria_gorskikh1 that answers it properly, thanks. in memory browser state surviving is the part i wasnt expecting, and its the one that actually matters, since a warm profile with a cold tab still pays most of the cost anyway. the gap left is the thing you named at the end. a session that carries over but has been revoked server side is stale valid. the cookie is right there, the auth is dead, and the agent only finds out when an action fails somewhere in the middle of a task. if you can afford one cheap authenticated request on wake before handing control back, that converts a mid task failure into a clean re auth at the start, which is a much easier thing for anyone building on top of you to handle. sub second wake is also a better number than i expected.
Maritime
@rabnoor_s thanks for the advice!