Changelog

• Sandboxes: any vCPU and memory combination can be created, not only the named tiers - a 4 vCPU, 4096 MiB, 30720 MiB shape is admitted instead of refused with shape_mismatch.
• Billing: per-plan resource ceilings replace a fixed allowed-size list, so a create is admitted against your plan's maximum vCPU, memory and disk, and every exceeded field is named.
• Billing: paid plans auto-recharge before a pause when credits run out; free plans pause instead.
• Billing: plans can be paid for directly - the approval gate is gone, so Subscribe activates the plan and grants the credits with no admin step.

• Billing: leaked or previously unbilled resources now accrue a charge - GPU, managed service, computer backup and Forge automation compute were billed at zero.

• Sandboxes: a new sandbox's resolver file could come back as the literal bytes of another file, leaving the sandbox with no DNS or egress.
• Sandboxes: exec and file access fail fast when the workload behind the row is dead, instead of paying a full round trip to the host.
• Sandboxes: legacy checkpoints written before the architecture cutover can be trusted and restored again.
• Sandboxes: a cold boot of a certified image no longer fails readiness with an identity mismatch.
• Runs: a run that wrote its required output but not an optional file no longer loses the whole run - mark a file optional.
• Runs: output collection no longer stops silently part way through the file list, and a failure names every remaining missing file.

• Python miosa 2.1.0.

• Computers: computer backups no longer silently lose their bytes when retention or an owner purge runs over the snapshot they share.

• A custom disk selector on sandbox create, plus custom CPU and memory on the create form.
• Custom templates can be created and their builds watched.
• Template identifiers are copyable with paste-ready integration code.
• @miosa/sdk 3.0.1 and 3.0.2, and @miosa/cli 1.1.19 through 1.1.22.
• Sandboxes: pick the disk yourself in the console - Sandboxes > New has a custom disk input that accepts anything at or above the selected size's floor, with inline validation.
• Sandboxes: set vCPU and memory per sandbox - Sandboxes > New > Advanced takes optional vCPU and memory, where blank means the size default.
• Sandboxes: template create takes vCPU, memory and disk alongside a named size.
• Sandboxes: the template page shows a copyable template identifier and copy-ready create snippets for the Python SDK, the TypeScript SDK and the CLI.
• Sandboxes: the sandbox page is a full module - Services, Connectors, Database, Usage and Policies tabs, a working terminal, and reworked Files, SSH and Terminal tabs.
• Settings: Workspace has a default sandbox template card.
• Sandboxes: build errors in the template list, the template page and the runtime catalog read as human text instead of raw error tuples.

• Console: the page no longer shifts when you click a tab or nav item - the scrollbar gutter is reserved.
• Sign-in and accounts: logging out and back in no longer pushes you through naming an organization again when you already own a named one, and the switcher stops listing unnamed duplicates.
• Sandboxes: list and detail tables use tabular numbers with tighter padding, and the runtime catalog summary is four cards.

• Sandboxes: creating with an explicit null disk, CPU or memory resolves to the shape default instead of crashing.
• Sandboxes: a published shape with no baked network slot cold boots from the base rootfs instead of failing with a slot rejection.

• Services, Connectors, Database, Policies, Usage and a PTY terminal as sandbox tabs.
• A new tiny machine shape at 1 vCPU and 1024 MiB.
• Atomic creation, idempotency keys and immutable versions for sandboxes.
• Sandboxes: the templates API became a real workflow - every error body carries a request id, a template and its first build are created atomically, an idempotency key makes retries safe, template versions are numbered and immutable, and a sandbox can be moved to another template with a preview-first migrate that lists what is lost as loudly as what is preserved.
• Sandboxes: you can set the disk size you want - a requested disk at or above the shape's floor is honoured instead of requiring an exact match, and a custom-disk sandbox always cold boots.
• Sandboxes: a template build that starts from a template you ship inherits that template's declared shape instead of falling back to the platform default.
• Builds: a Kali base image is accepted and builds a real image at the medium shape.

• Builds: the builder honours the shape declared in the build spec instead of always building on the small shape and running out of disk.

• Builds: template builds failed for every tenant with a capacity rejection because the build machine floor had been raised to a shape the fleet does not keep slots for; the floor is back to the small shape.
• Builds: a comment inside a Dockerfile line continuation no longer ends the instruction and silently drops the rest of the step from the build.

• A workspace's own templates show in the UI with honest build state.
• Sandboxes: bulk create over the API - POST /api/v1/sandboxes/batch, with batch status, items, cancel and a live stream, up to 10,000 sandboxes at a concurrency you set.
• Agents: POST /api/v1/runs accepts a run group, and a failed run always reports a non-empty error code and message plus a plain agent message instead of making you parse a metadata blob.
• Databases: GET /api/v1/databases/{id}/metrics returns real data - memory and CPU series carry points and the current block reports memory used and CPU percent, where the endpoint previously always answered an empty series.

• Sandboxes: deletion returns faster - DELETE /api/v1/sandboxes/{id} answers as soon as the destroy is durably queued and may report destroying rather than destroyed.

• Dead state styling was fixed across nine components.
• Snapshots purge their stored objects before the record is removed.
• Runs report a terminal failure reason and whether they are blocked or retryable.
• Sandboxes: a large sandbox create on a busy host no longer fails with a cross-device link error - the warm slot is cloned with a topology-aware sparse copy.
• Sandboxes: the tenant's always-on setting now applies to sandboxes created through the public API.
• Builds: an unknown Dockerfile base image fails with a clear named error instead of silently substituting Debian.
• Sandboxes: the bookworm and debian-12 aliases resolve to a template that boots, and the retired alias no longer appears in the list.
• Sign-in and accounts: an email MFA challenge reports distinct states - malformed, expired, already used, too many attempts, wrong code - so the screen can tell you to request a fresh code.
• Sign-in and accounts: sign-in has its own rate limit, a non-string email or password returns a normal 400 instead of a 500, and registering an existing address no longer reveals that it is taken.
• Agents: optional connector runs no longer die mid-run with a 401 because connector recognition differed between dispatch paths.

• @miosa/sdk 3.0.0, @miosa/cli 1.1.18, and Python miosa 2.0.0.
• Sandboxes: create and manage your own sandbox templates and watch them build - Sandboxes > Templates lists your templates separately from platform ones, validates the build spec with a dry run before submit, and streams build progress with cancel and retry.
• Sandboxes: a template that has never built reads "Not built yet" and cannot be launched, and failed, cancelled and never-run builds are distinguished in words instead of a raw code.
• Billing: the pricing page actions work - "Choose Business" and "Request Enterprise" take you to billing with that plan preselected.

• Billing calls to action are wired, and provider labels are cleaned up.
• Billing: the plan named in the URL is honoured, so arriving at /billing?plan=business preselects it and opens the change-plan dialog.
• Billing: after a top-up the credit balance refreshes itself instead of leaving the success notice over a stale balance.

• Onboarding always reuses an auto-created organization to stop double tenants.
• Email verification delivery failures and server errors are handled in the auth flow.
• Billing: the payment provider shown on the plan and credits views is the real one.
• Billing: top-up, subscription and cancellation notices no longer reappear on every page refresh.
• Organizations: choosing a company organization at signup no longer creates a second empty organization that kept the welcome credits.
• Sign-in and accounts: registration says the address could not receive a verification email instead of a generic failure, and verification and MFA screens show a plain message instead of a raw server error or a wrong "that code is incorrect".
• Sign-in and accounts: after OAuth sign-in the token is removed from the address bar so it no longer lingers in the URL and browser history.
• Console: tabs, switches, checkboxes and radios show their state again in light and dark themes, and the chosen storage survives a page reload.
• Console: a failed backend response can no longer paste raw HTML into a customer-facing error message.

• The full Forge frontend shipped: all repository screens, collaboration, provenance and lifecycle, with bounded pull request diffs.
• Bring your own cloud: a placement switcher, spend caps and batch create.
• Forge: the full repository workspace - browse code and commits, list branches and tags, open, approve and merge change requests with review timelines and comment threads, read checks with their evidence, see releases with source artifacts and checksums, read a provenance timeline with signed attestations, edit merge rules, fork a repository, change visibility and delete a repository.
• Forge: a change request renders the actual diff - a changed-files section with totals, ahead and behind counts, and one collapsible patch per file with line numbers, status and renames; files withheld at the safety boundary are labelled rather than shown blank.
• BYOC: choose where your work runs - Cloud sets an organization default of platform-managed or your own certified cloud with a precedence explainer, Settings > Workspace sets per-workload defaults, and a placement badge names which tier won on the sandbox inventory, sandbox header, computer cards and deployments.
• Sandboxes: batch create from the Sandboxes page - a count and a concurrency, live counters, a fill graph, a failure sample and a cancel.
• BYOC: pool create, the pool policy editor and the pools table show the hourly cost ceiling and the pool's time to live.

• Computers: every desktop card always shows its real screen - cards without a full-motion slot show the real desktop as a poster, and the number of full-motion desktops per host was raised from four to six.
• Computers: a card can no longer show the remote-desktop vendor's own session-disconnected panel.

• Every desktop card always shows its real screen, and a vendor's Session Disconnected panel never reaches a card.

• Forge: public Forge repository pages show organization profiles, fork counts and stars, and a repository can be starred.

• Forge: large repositories with many branches or tags are readable again - ref discovery is bounded per kind and reports when it stopped, instead of failing the repository and leaving the code view unavailable.

• Sandboxes: an exhausted network slot surfaces a retriable named error instead of silently leasing a legacy default slot, so a create can no longer land on a foreign network's snapshot.

• Returning OAuth users no longer loop through first-run setup.
• Sign-in: returning Google OAuth users with a completed setup reach the platform even when no workspace is visible; members, viewers and guest roles are no longer forced through owner-only onboarding; and the callback strips the token from the URL.

• A readiness stream endpoint for sandboxes.
• Instant create from pre-provisioned capacity for faster sandbox startup.

• New accounts no longer see low-credit warnings, and a computer that cannot be paid for is refused before it boots.
• Sandboxes: destroying a sandbox under a burst of traffic reports success instead of 503 - a destroy racing its own stop is treated as success.

• @miosa/sdk 2.0.7 and Python miosa 1.3.8.
• Sandboxes: GET /api/v1/sandboxes/{id}/readiness/stream - a readiness stream that emits ready immediately or when the sandbox becomes ready, emits a timeout past the server deadline, and sends keepalives.
• Billing: computers refuse up front with 402 insufficient_credits from both create and start when the balance cannot cover a single billing tick, instead of booting a machine that is hibernated seconds later.

• API keys are reachable, findable and named consistently, with a usable inventory and permission display.
• Console: API keys has its own sidebar row and one name everywhere, at /developer/api-keys.
• Console: the key inventory defaults to active keys with a count and a show-revoked toggle, revoked rows carry no dead controls, scopes render as badges with an overflow count, rows are selectable with bulk revoke behind a count-based confirmation, and the creation wizard groups permissions by category.
• Console: onboarding offers "Create an API key" weighted like the primary action.

• Every new account gets its first workspace, and brand-new accounts are no longer told they are running low.
• Accounts: every new signup receives its default workspace and owner membership in the same transaction, so a brand-new account can create API keys and use the platform.
• Onboarding: an account that owns no workspace resumes at the step that creates it, ending the loop where customers were stuck on "Your workspace is ready" and could not reach anything.
• Billing: brand-new accounts no longer receive a "your credits are running low" email about the welcome bonus before spending anything.
• API: every event stream was sending headers and closing before delivering a single event; sandbox events, notifications, all log streams, deployments, run groups, snapshots and open computers now deliver.
• Sandboxes: warm-slot adoption is bounded, so a defective slot falls back to a cold boot instead of hanging the create for a minute.

• Durable Forge mirror operations, public profiles with stars, and evidence-backed pull request detail.
• @miosa/sdk 2.0.6, Python miosa 1.3.7, Go v2.0.3, and @miosa/cli 1.1.16.
• Forge: two revisions can be compared - a bounded comparison that resolves refs to commits and reports when it stopped rather than overclaiming.
• Forge: pull request detail is evidence-backed with retained collaboration evidence and permission-gated actions.
• Forge: bounded pull request diffs render with added and removed files and per-file sections.

• Sandboxes: placement orders sandbox and desktop candidates by exact measured round-trip time instead of a broad latency class, so creates land on the closest host first.

• Forge: the first push to a new repository is accepted - every Forge-enabled organization now has a baseline push ruleset before repository creation.
• SDKs: a sandbox create that asks for a compact body no longer returns the full sandbox view after waiting for readiness.

• Forge: mirror operations are visible inside a repository - source authority, mirror mode, commit and ref totals, local and observed source heads with convergence, deliveries against completed reconciliation, and append-only operation receipts.
• Forge: the full console surface - repository tabs for code, commits, branches, tags, change requests, checks, releases, provenance, policy, lifecycle and settings, plus public organization and user profiles, repository creation and a diff viewer.

• Sandboxes: creation no longer fails fleet-wide - certified template snapshots are accepted again through their own path.
• Sandboxes: a paused sandbox restores against the artifact template and generation recorded with its network slot.
• Computers: a restored desktop snapshot starts inside its deadline.

• Forge repository workflows, README rendering and share cards.
• Forge: public repository pages show organization profiles, fork counts and stars, and a repository can be starred.
• Forge: repository workflows - create public, internal or private repositories with an optional README, gitignore and MIT license, and browse files, the README, commit history, refs and pull requests; file creation, visibility changes, branch protections and deletion are wired to real endpoints.
• Forge: README files render as sanitized Markdown with repository-relative images and links.
• Forge: repository pages generate their own social share cards.

• Forge: the public landing was restored with repository discovery, and anonymous public repository reads no longer probe protected endpoints.

• The Forge GitHub installation callback, and replay of existing GitHub mirrors.
• Forge: an existing mirror can be replayed instead of failing on an already-mirrored repository.

• Three-plan pricing and billing flows, with the Business monthly credit allowance explained.
• The Forge public landing, plus a governed Forge backend with verified backup and restore and Git traffic routing.
• Billing: three plans published - Developer at $0 with 1,000 credits at activation, Business at $500 a month with 100,000 credits at activation and 50,000 after each paid monthly renewal, and Enterprise as custom - visible without signing in at /pricing and in the console billing page.
• Billing: plan selection with request, approval, checkout, cancellation and limit requests.
• Billing: pricing is readable without authentication, and GET /api/v1/compute/pricing returns the plan catalogue to unauthenticated callers.
• Billing: the billing page shows included, purchased, reserved, refunded, adjusted, expiring, gross and spendable credit balances, and the pricing page lists every billable surface with its unit and charging behaviour.
• Forge: a public landing at miosa.ai/forge with a working waitlist.
• Forge: installing the code host app returns you to your Forge organization instead of being misrouted as a repository.

• Billing: the Business credit allowance is explained the same way on the home page, the public pricing page and both billing views.
• Forge: "Join beta" scrolls to the form instead of remounting the page.
• Docs: pricing documentation regenerated to the three current plans.

• Docs: all public sandbox benchmark results, scores, rankings and provider comparisons were removed.

• @miosa/sdk 2.0.5 and Python miosa 1.3.6.
• Sandboxes: POST /api/v1/sandboxes accepts wait=true to block until the sandbox is running before responding, and a compact response format for a trimmed create body, with named errors for a readiness timeout and a boot failure.
• Sandboxes: the create-and-run response reports server wait and server exec time separately instead of one combined field.
• Sign-in and accounts: sign-in MFA can mark the browser trusted for 24 hours, or 15 minutes otherwise, for both email codes and authenticator codes - "Remember this browser" on /login.
• Onboarding: the finish action navigates straight to the chosen module instead of stalling behind an auth refresh.

• Sandboxes: the snapshot boot path batches admission, billing and quota work and replaces restore-time shell orchestration with one native guest bootstrap.
• Sandboxes: same-tenant bursts no longer serialise credit and admission checks.
• Sandboxes: placement prefers the lowest measured latency, so creates land on the nearest healthy host.
• Sandboxes: boot concurrency is configurable live, removing second-wave waits in large bursts.
• Sandboxes: warm-slot refill is deferred behind customer claims so restore work does not compete with a new sandbox's first command.

• The final onboarding step navigation was unblocked.
• Sandboxes: the first command after a warm adoption no longer fails with a transport-closed error, and a first command rejected during identity handoff is retried once.
• Sandboxes: creates under a concurrent burst fall back to a snapshot restore instead of racing the warm-pool refill.
• Sandboxes: snapshot boot no longer fails during overlapping configuration, and can reclaim a network slot from a dead owner.
• Sandboxes: creating a sandbox or computer whose name or parameters contain an identifier is no longer falsely rejected by the card-data scan.

• The public home, auth and pricing experience was rebuilt.
• A social preview and enterprise contact page.
• Console: the public home, sign-in and invite layouts were rebuilt, and the interactive desktop demo moved to /desktop-demo.
• Console: the home page unfurls with a purpose-built social preview image, and the AI consultation chat became an enterprise contact page with a prefilled mailto.
• Onboarding: the flow was cut from seven screens to three, the final screen shows the live credit balance, and there is one finish action.
• Sandboxes: POST /api/v1/sandboxes/run defaults to a non-persistent sandbox on host-local storage, so the one-shot run lane starts without a durable rootfs.

• Onboarding was simplified, with the live credit balance shown after onboarding.
• Desktop stream retries stop before provisioning completes.
• Sandboxes: small ephemeral sandboxes report interactive after proving the final block device and baseline filesystem, finishing disk growth in the background.
• Sandboxes: readiness on distant hosts no longer pays extra cross-region calls, and the guest readiness checks were collapsed into one authenticated command.
• Sandboxes: ephemeral readiness no longer forces durable-media flushes, and per-tenant spend admission no longer serialises one tenant's burst.
• Public site: mobile home layout and header repaired, and the home page renders during session restore instead of a black page.
• Public site: the OSA entry in the footers is a real external link.

• Onboarding: welcome credits are provisioned and verified before the flow reports success, and a failure returns 503 instead of promising credits it did not record.
• Onboarding: a failing legacy settings mirror can no longer trap a user on the final step.
• Computers: the desktop preview no longer retries the stream endpoint in a tight loop while the computer is provisioning.
• Computers: deleting a computer while it is still provisioning cancels the provisioning and tears down the host.

• Agents: a run created with required connectors now has those connectors staged into the run, so connector tools are actually available to the agent.
• Sign-in and accounts: a fresh sign-in code can be requested from the MFA prompt without restarting sign-in.
• Console: the Command Center was rebuilt as an evidence-backed surface - broken resources are prioritised, a selected resource expands inline with its facts, supported actions, confirmation and recovery receipts, and status counts act as filters.
• Console: a system pulse panel shows workspace viability, lifecycle, releases, capacity and telemetry freshness, separating desired from observed state.

• Authentication code emails use a clearer design.
• Computers: creating a computer no longer falls back to a slow cold boot when warm adoption runs outside enforce mode.
• Sign-in and accounts: sign-in, sign-up and verification were rebuilt around six-digit code entry with a resend cooldown and distinct invalid, expired, rate-limited and unreachable messages.
• Sign-in and accounts: authentication code emails carry purpose-specific subjects and headings on a redesigned layout.

• Sign-in and accounts: account emails were crashing and not being delivered; password reset, email verification, computer ready, sandbox ready and deployment succeeded messages send again.
• API: failed API calls return the real status from the service instead of being masked as 503.
• Databases: stopping or restarting a managed database flushes the engine's durable state first, so recent writes survive a stop and start.
• Storage: object uploads of any content type are accepted instead of failing with 415.

Clearer documentation navigation

• The sidebar now groups guides by customer goal instead of mixing product workflows, internal architecture, and infrastructure ownership.
• White-label architecture, customer identity, branding, domains, events, metering, and examples now live together under Build Your Product.
• Infrastructure choices, external providers, and provider comparisons now share one Infrastructure section.
• Sandboxes, deployment, data, computer, security, and recipe labels use consistent customer-facing language.
• Existing documentation URLs remain unchanged, so saved links and integrations continue working.

A clearer path from idea to production

• The documentation homepage now leads with the outcomes teams can achieve instead of presenting Sandboxes as the primary product promise.
• A three-stage journey explains how agents create software safely, prove the result, and deploy one verified release.
• Goal-based starting paths connect application development, Agent Runs, computer automation, and customer-controlled infrastructure to the relevant guides.
• Production release proof remains visible without requiring new users to understand every command before they begin.
• The refreshed homepage supports keyboard navigation, reduced motion, mobile layouts, and accessible contrast in light and dark themes.

Operational documentation and safer discovery

• Projects now have a dedicated conceptual guide that separates ownership from Sandboxes, Computers, and Deployments.
• Domain guidance now translates DNS-provider fields and shows the complete ownership, certificate, and routing sequence.
• Recovery playbooks provide symptom-first checks for deployments, domains, TLS, App Engine hosts, and Sandbox previews.
• Documentation search recognizes common customer language while returning canonical MIOSA concepts.
• Public changelog checks reject common private identifiers before publication.
• Documentation feedback sends only the page path, rating, and feedback source, with no query string or customer-entered content.

No customer action is required.

Documentation search

• Search now ranks direct title and phrase matches ahead of weaker body and terminology matches.
• Results can open a matching section directly instead of stopping at the top of its page.
• Common product aliases remain discoverable without diluting exact matches.
• The selected result now uses one quiet neutral surface with a clear destination arrow instead of a stacked accent treatment.
• Search supports mouse, keyboard, screen-reader, light-theme, dark-theme, and mobile navigation.

Guided learning paths and clearer terminology

The documentation now provides a guided education layer across the existing technical references, cookbook workflows, and API guides.

Learning paths

• A new Learning Paths hub organizes existing documentation around four outcomes: deploying a first production app, building an agent product, automating a desktop, and building a white-label platform.
• Every path defines an ordered reading sequence, expected result, proof requirement, recovery expectation, and finish line.
• A compute chooser explains when to begin with a Sandbox, Computer, App Engine Host, Bring Your Own Cloud region, or OpenComputer.

Complete Next.js example

• A new Next.js tutorial takes an application from an empty Sandbox through Preview, App Engine publishing, Deployment proof, custom-domain verification, safe updates, and rollback.
• Expected results appear after each major step instead of leaving readers to infer whether an operation succeeded.
• A symptom-first recovery table covers pending capacity, broken previews, unavailable App Engine Hosts, incomplete promotion, DNS verification, incorrect domain ownership, and application regressions.
• The tutorial ends with an explicit completion checklist and production-hardening links for databases, secrets, publishing, and domains.

MIOSA glossary

• A visual flow shows how work moves from Organization and Workspace through Sandbox, Release, Version, Deployment, and Domain.
• “Do not confuse” guidance separates User and Organization, Release and Version, Deployment and Runtime Instance, and Bring Your Own Cloud and OpenComputers.
• Definitions cover customer-visible ownership, development, deployment, domain, agent, data, security, infrastructure, and billing concepts.
• Private infrastructure details and security-sensitive implementation notes remain excluded.

Sidebar navigation

• The selected page now uses a quiet neutral surface and subtle border instead of a colored gradient and glow.
• Parent groups stay visually calm while the exact current page remains clear.
• Hover and keyboard-focus states remain distinct in both light and dark themes.

• Docs: an infrastructure section covering the platform's own fleet, bringing your own cloud, and shared responsibility.
• Docs: a glossary, a learning-path hub and an end-to-end tutorial that takes an app from an empty sandbox to production.
• Docs: a projects guide and symptom-first recovery playbooks for deployments, DNS, TLS, hosts and sandbox previews.
• Docs: the sandbox recovery lifecycle documented end to end, with public sandbox states separated from snapshot and fork operations.

• Docs: search rebuilt with title-first ranking, section-level results with deep links, result counts and a clearer empty state.
• Docs: the landing page now leads with building and deploying software, with goal-based entry cards.
• Docs: the sidebar reorganised into Build Your Product and Infrastructure groups, with every existing URL preserved.

• Console: the Command Center no longer declares the Agents module unavailable when the agent registry is empty.

A clearer documentation experience

The documentation now uses one navigation system and a more focused reading layout.

• Search, appearance controls, page navigation, and Ask OSA are easier to find.
• Ask OSA opens beside the article without replacing or shrinking the documentation landing experience.
• The assistant panel can be resized to fit different screens and reading preferences.
• Generated search and AI indexes were refreshed to match the public documentation.

Domain setup and deployment URLs

Domain configuration now explains the difference between platform-provided deployment URLs and customer-owned domains more clearly.

• Organization domain setup presents the required DNS record and verification state in one flow.
• Deployment screens show which hostname is currently serving the application.
• Custom deployment domains remain scoped to the owning organization and deployment.
• DNS, certificate, and routing states use clearer status language and recovery guidance.

Onboarding improvements

New organizations can configure team access and domain setup during onboarding.

The final onboarding step now provides clearer next actions for using the platform, CLI, and agent workflows.

• Sign-in and accounts: a privacy rights request can be filed without an account, confirmed by an emailed link, then checked or cancelled.
• Deployments: the domains page was rebuilt around one explicitly selected deployment with a searchable picker and a shared add-domain dialog, and domain states are filtered as verified, pending and invalid.
• Docs: the documentation site has one unified navigation and header, old build pages redirect to canonical ones, and Ask OSA is back as a header action.

• Docs: Ask OSA opens as an overlay and no longer displaces the "On this page" rail, and its panel is resizable.
• Docs: the appearance control shows an explicit system, light or dark label and offers glass modes.
• Onboarding: the final step recommends only Deploy, Sandbox and Computer, and its deployment action goes straight to creating one.

• Deployments: custom-domain routing recovers after a runtime restart, with the network device recreated before the runtime resumes.
• API: deleting a deployment that is still building or running returns 409 RUNTIME_ACTIVE with an instruction to stop it first, instead of deleting it.
• API: the JSON API rejects payloads containing card-number-shaped values while excluding identifier-shaped strings, so normal ids are not mistaken for card numbers.

• Computers: a small desktop restored from a snapshot no longer takes nearly a minute to become usable - the restored session gets a bounded resume grace period and the fallback restart no longer blocks readiness polling.

• Sign-in and accounts: durable browser sessions - the account security page lists your active browser sessions and sign-in activity, can revoke one or all others, and shows authenticator status. A password reset or an organization switch revokes existing sessions.
• Sign-in and accounts: a new-sign-in security email after a successful password or OAuth sign-in, and the user payload exposes the OAuth provider, avatar source, whether a password is set, and last login.
• Computers: viewer access controls in computer settings - the viewer password status is shown, with rotate and reveal where the replacement is displayed once and copyable.

• Computers: the desktop viewer keeps its intended quality - a preset had been silently overwriting the full resolution with a quarter of it.
• Computers: fast live desktop handoff transfers viewer ownership from the gallery to the workspace, with gallery previews capped.
• Computers: the interactive workspace was stabilised - viewer ownership, stream continuity, embedded permissions, terminal duplication and stale scrollback, dock controls and action menu hierarchy.
• Computers: gallery cards render edge to edge as one desktop surface with no dead strip above the live preview.
• Computers: plan capacity limits are visible - every size is listed with locked options disabled, the required upgrade explained, and remaining aggregate running memory shown.
• Computers: restored desktops come up much faster - the desktop snapshot is certified once instead of being re-hashed on every launch, removing about fifteen seconds per restore.

• Computers: medium, large and extra-large desktops no longer fail to launch - snapshot disk contracts are recorded per size and snapshots are paired with their exact rootfs.
• Computers: a stale warm slot is reaped and provisioning continues instead of failing with an adopt error.
• Computers: an extra-large computer is no longer silently created as medium, because every advertised size resolves correctly.
• Computers: transient routing errors show the branded retry page instead of raw JSON inside a desktop card.

• Sign-in and accounts: signup requires a six-digit email verification step before onboarding, with a resend option and a client cooldown, and unverified returning users are routed through the same flow.
• Sign-in and accounts: organizations can define custom member types carrying their own titles, module scopes and permission allowlists, assign them to members, and use them in invitations.
• Sign-in and accounts: an invitation inbox lists pending organization and workspace invitations with the destination, role and expiry, and lets the recipient decline - Account > Invitations.
• Sign-in and accounts: authenticator-app two-factor authentication is complete - password-confirmed setup with a QR secret, ten single-use recovery codes, verification enforced before login tokens are issued, and a disable path.
• Computers: every advertised desktop size can be launched from a certified warm snapshot instead of only the small tier, cutting the wait for medium, large and extra-large.
• Agents: a redesigned contextual operator panel in the embedded computer chat - it shows the signed-in actor, workspace, resource and computer context, renders replies as Markdown with collapsed activity, and replaces the composer with Attach, Ask, Investigate, Plan and Act.

• Agents: the embedded computer chat is bound to the signed-in identity, routes through the hosted API rather than localhost, and no longer restores stale conversation state from local storage.
• Computers: instant launch stays responsive - the launch action is not disabled while plan metadata loads, and the provisioning overlay clears as soon as the live viewer connects.
• Computers: desktop rendering is faster - the VNC client is bundled and preloaded instead of downloaded per computer, and the viewer transport is warmed during create.
• Computers: gallery previews renew their viewer session before it expires, so a healthy running computer is no longer shown on a disconnected page while labelled live.
• Computers: interactive desktops keep the connected session across viewer credential rotation and unexpected disconnects, retaining the last frame.
• Computers: quick create exposes only the fastest placement, and size, idle behaviour and template defaults are clamped into the effective plan.
• Computers: stop, resume and restart work for remotely placed warm computers.
• Sign-in and accounts: a personal organization is preserved when a user goes through company onboarding.
• Console: the organization member surface was redesigned as a compact directory with denser rows and explicit role and status labels on mobile.

• Computers: the warm handoff retries transient and stale connection failures and restores the direct handoff path, so a warm launch no longer stalls.
• Computers: live branding works on the warm path, and a cosmetic check failure can no longer destroy a usable desktop.
• Computers: restored desktops reopen correctly - restored sessions are owned and repaired, and a restored snapshot no longer re-enters build mode.
• Computers: a desktop stopped and started repeatedly no longer lands in a stale paused state.
• Sign-in and accounts: the organization name and slug are immutable after onboarding.
• Computers: a host-session failure no longer permanently refuses a reconnect.

• Docs: a Computers fast start and readiness page, plus refreshed benchmark and overview pages describing the warm launch path and the readiness contract.

• Computers: the embedded desktop workspace is more stable - the native viewer is revealed when the navigation completes and authenticated stream URLs are preferred.
• Computers: gallery previews preconnect to the warm viewer while the handoff is still provisioning, so a warm launch shows the desktop sooner.
• Computers: creation is plan-aware - the size list is filtered by the active plan, the plan's idle-stop policy is enforced, and the warm small tier is labelled fast start.
• Computers: warm handoff is more reliable - the viewer route is published before handoff and the viewer overlaps the handoff.
• Computers: interactive desktops use latency-ranked host selection across certified warm pools.
• Computers: placement and plan choices are honoured, including an explicitly automatic placement and an explicitly selected region.

• Computers: the desktop viewer URL no longer returns 503.
• Computers: warm desktop routing resolves an adopted desktop to its real backing host, and adopted machines survive a service restart.
• Computers: the desktop wallpaper is normalised to the platform default.
• Computers: a desktop preview that loads a proxy error page is no longer shown as live.
• Computers: stuck and failed computers can be deleted, and unavailable lifecycle actions are disabled.

• Databases: a managed database is no longer rescheduled onto another host and reformatted onto a blank volume - an existing database is refused rather than moved when its storage host is unavailable.
• Sandboxes and computers: a guest can no longer grow host memory without bound by writing to its own console.

• Sandboxes: the instant-code template is publicly creatable - previously hidden from the create list.

• Sandboxes: pause and resume on a customer-cloud host perform a real live pause and resume instead of being aliased to stop and start, so running processes and memory survive.
• Deployments: deployments that vanished when their appliance machine was lost are recovered - liveness and automatic reprovisioning default on, active releases are replayed after host recovery, and linked database variables are restored.
• Sign-in and accounts: closed an authorization bypass where a caller without the egress scopes could reach the same OAuth provider listing and start behaviour through a duplicate route.

• Sandboxes: create many sandboxes in one job from a batch page with live dispatch and runtime counters, and cancel a running batch - Sandboxes > Batch, POST /api/v1/sandboxes/batch.
• BYOC: a placement switcher for platform-managed versus your own cloud across sandboxes, computers and deployments, a placement badge showing where a machine ran, workspace placement defaults, and spend caps with a time to live on cloud pools - Cloud.
• Console: an integration access panel on computers, sandboxes, deployments, databases, projects, agents and workflows showing which connections are inherited from the organization, workspace or project and which are set on the resource, with integrations settings moved to /integrations.

• Databases: the database detail view shows desired against observed lifecycle state and immutable lifecycle receipts, and the capability copy matches what resize, backup, restore and metrics actually do.

• Sign-in and accounts: closed a high-severity advisory where a forged token could revoke another user's session.

• Databases: plan-aware backup retention is returned by the API - 7 days on Free and Starter, 14 on Pro, 30 on Scale and Platform, 35 on Enterprise - with the retention window and each backup's expiry exposed on the database endpoints.
• Cloud: host certification now covers computers and deployments as well as sandboxes, so desktop and deployment capacity on your own cloud can be certified and made selectable.

• Sign-in and accounts: accounts with no organization or no workspace are treated as incomplete even when the stored onboarding state says ready, and are routed back into onboarding to repair scope.
• Integrations: governed assignment is complete with organization, workspace, project and resource targeting, capability and delivery-mode choices, and corrected tool server configuration.
• Databases: the telemetry panel shows current CPU load and memory utilisation plus sample freshness and count, instead of treating any successful response as healthy.
• Databases: plan-specific backup retention and storage readiness are exposed, and restore checksum verification receipts and failure codes are displayed.

• Databases: restores verify the checksum of every artifact before restoring and fail closed with stable codes when a checksum is missing or mismatched.
• Databases: branch and replica allowances are enforced under locks, and quota reservations are released when provisioning fails.
• Databases: the plan API reports which managed features are actually available, so high availability, point-in-time recovery, cross-region recovery and backup encryption read as unavailable until they are implemented.
• API: sandbox create and deployment list no longer return a 500 when the tenant context is blank or malformed; they return the expected 422.
• BYOC: every cloud account must use role assumption - the dormant direct access-key mode and its public preview field are removed.
• BYOC: the onboarding templates now require the exact provisioning role plus your organization's external id instead of trusting a whole account root.
• BYOC: account verification works with keyless credentials again, and host installs no longer fail on systems whose resolver is a local stub.
• BYOC: image builds no longer fail at the copy-on-write mapping step, and a build that cannot leave the certified free-space floor is rejected before any cloud resources are created.
• Deployments: an interrupted control-plane cutover no longer leaves the API stopped - a recovery guard restores the prior release when rollback is still safe.

• Databases: run one SQL statement against a managed PostgreSQL database from the tables browser and SQL editor - POST /api/v1/databases/{id}/query, with a 15-second timeout and responses capped at 1000 rows.
• Deployments: publish from an uploaded build with no repository - POST /api/v1/deployments/drop/sessions creates an upload-backed deployment, and uploads are candidate-first so they never change production automatically.
• Deployments: drop a built static site by file or folder to create an immutable preview candidate - /deploy/new.
• Deployments: a native App Engine surface with grouped navigation, a domains screen with add, DNS instructions, verify and remove, and the deployed app's preview in place of the old portal screen.
• Deployments: the new-deployment flow is source-first around a repository URL, with App Engine as a runtime target rather than a source.
• Networks: /network rebuilt as a contained module consolidating routes and tunnels into endpoints with tenant-wide posture and capability inventory, and publishing a public endpoint now requires explicit confirmation.
• Cloud: cloud and BYOC presented as organization capacity rather than workspace configuration, with node certification controls that queue and poll durable operations.
• Cloud: a shared compute-origin selector in sandbox and computer creation sends strict placement requests.
• Cloud: read which workloads and providers are actually available - GET /api/v1/cloud/capabilities, covering sandboxes, computers, deployments, databases, storage, volumes, functions and agents across platform, open-computer, AWS and GCP capacity.
• Cloud: workload placement is gated on exact, unexpired certification receipts, and customer-cloud placement needs an explicit region and pool.
• Computers: create a computer by purpose with safe defaults, and the genuinely supported options moved under advanced settings - /computers/new.
• Computers: workspace-scoped saved setups are real create, read, update and delete - /computers/templates.
• Computers: one workspace hosting the live desktop stream, resizable terminal tabs and the agent chat panel in a single surface.
• Sandboxes: a terminal section and a connect section with a generated SSH key, a copyable connection command, and the private key revealed only on request.
• Sandboxes: inventory uses workspace and project scoped queries with pagination, sorting, filtering and tracked bulk lifecycle jobs.
• Sandboxes: creation is plan-aware with project attribution, allowed-size enforcement, total and concurrent limits and the backend lifetime cap.
• Integrations: connect a provider once and assign it at organization, workspace, project or resource scope, with assigned integrations resolved into sandbox and deployment runtime environments.
• Integrations: marketplace made operational with a working discovery view, provider detail and persisted provider requests.
• Integrations: a first-class hosted tool server configuration surface at /integrations/mcp.
• Databases: resize is limited to the five billable shapes with a current-to-target comparison and a confirmation dialog explaining the restart.
• Storage: bucket creation, file upload and signed application access explained in plain language, with unsupported capability screens removed from customer navigation.

• Sandboxes: list sandboxes with server-side paging, filtering and sorting - page, limit, state, template_id, search and sort, returning totals, page counts and per-state counts.
• Sandboxes: create to first command is about a second faster on warm hosts.
• Storage: the bucket list reports allocated, used and available capacity and the per-bucket maximum, so the console can show remaining allocation.
• Computers: warm desktop slots wait up to 90 seconds for readiness instead of 30, so healthy desktops stop being discarded into a cold boot.
• Computers: gallery cards open the workspace directly and hand the authenticated session in, and viewer recovery retries through the boot window.
• Computers: delete uses one confirmation instead of two, and a stopped computer's workspace can be reopened.
• Deployments: the deployment inventory is responsive rows with clear manage and open actions instead of a dense table.
• Deployments: domain actions open the canonical organization domain settings, and section navigation is URL-backed so refresh, back and shared links work.
• Databases: the tables browser and SQL editor use the full module canvas, structured values render as readable JSON, and resize shows hourly and approximate monthly runtime pricing.
• Databases: attachments, usage and cost, and policies are backend-backed, and revealing a secret is an explicit action that clears on leaving the panel.
• Databases: the plan's storage allowance and the managed database ceiling are enforced, and price is shown before creation.
• Optimal: tasks, investigations, artifacts, approvals, history, usage and preferences are wired to workspace-scoped contracts, with governed approvals.

• Databases: activity and logs work for a managed database on any compute host, because log requests route through the node that owns the guest.
• Databases: decrypted credential responses are marked private and non-cacheable so connection credentials are not stored by intermediaries.
• Computers: unsupported create options are rejected instead of silently ignored - GPU options, a maximum runtime and a linked database return a named 422, and malformed fields are named.
• Computers: a hibernated computer can no longer be deleted while it is waking during a rolling release.
• Storage: creating or resizing a bucket above the plan allowance returns a named 422 with a per-account lock so concurrent creates cannot over-allocate.
• Databases: resize accepts only the five supported shapes, checks credits first, and returns 402 or a 422 listing the supported shapes.
• Agents: run groups are workspace-scoped, and cross-workspace access returns 404.
• Billing: GET /api/v1/usage applies the requested resource-family filter to both grouped rows and timeline points and echoes it back, returning 422 for an invalid value.
• Sandboxes: sandbox memory is scrubbed and the shared default TLS key removed before a snapshot is captured, and unique SSH host keys are generated when a key is installed after restore.
• Deployments: clicking App Engine no longer renders a 500, and the redundant advanced console entry point is removed.
• Optimal: tasks, sections and chat stay bound to the selected workspace and resource, and every chat session for a selected machine is restored with its tab.
• Sign-in and accounts: sign-in no longer wedges when a session cookie cannot be validated, and the redirect accepts the apex domain.

• Command Center: /command-center is the canonical operational route, with /dashboard redirecting there and query strings preserved.
• Command Center: an interactive resource graph with node controls, selection and expansion, workspace-scoped inventory, capability receipts, and resource snapshot and fork actions.
• Agents: the workspace agent control plane wired to persisted agent definitions, with real execution configuration and capability editing that preserves what you configured.
• Optimal: chat conversations persist across reloads.
• Databases: the managed database data browser is back on the database page, with tables and a SQL editor.

• Optimal: conversation state survives moving between platform pages, the resolved workspace is preserved so a chat does not silently switch, and sessions are hardened across organization and workspace switches.
• Computers: creation waits for the selected workspace before provisioning, regions without live capacity are disabled, and the visibility you chose is preserved.

• Optimal: answers are recovered when the live stream is unavailable, so chat still replies.
• Workspaces: a remembered workspace that returns a forbidden error now recovers by trying another workspace in the active organization, with no refresh and no retry loop.
• Command Center: the topology canvas keeps pan, zoom, expansion, selection and fit controls on narrow viewports.

• Agents: an agents console with sections for authority, definitions, evaluations, memory, runs, skills, tasks, templates, tools, triggers and usage.
• Workflows: a workflows console with builder, connections, runs, schedules, templates and usage.
• Cloud: a cloud console with accounts, connect, hosts, open computers, permissions, placement, pools and regions.
• Network: a network console with domains, meshes, policies, routes and tunnels.
• Developer: a developer surface with API keys, webhooks and code samples.
• Intelligence: an intelligence section with per-provider pages.
• Projects: projects and products consoles, with project sections for activity, compute, environments, health and network.
• Observability: an observability console with per-section pages, plus reworked analytics and logs.
• Security: agent authority, approvals, authentication, people, roles and sessions pages.
• Storage: buckets, volumes, activity and protection pages.
• Integrations: a catalog, provider detail, connections, installed and requests pages.
• Sandboxes: deepened detail, creation and control surfaces.
• Computers: inventory, templates, settings and usage pages, plus an immersive desktop wall.
• Databases: rebuilt database list and detail with a create flow, inventory and detail views.
• Dashboard: rebuilt as an operational command center.
• Onboarding: first-run setup rebuilt as a guided flow covering profile, organization and workspace, team invites, domain routing, goals and activation, with a product tour.
• Sign-in and accounts: authenticator-app second factor shows a scannable QR code plus a manual setup key, and recovery codes can be downloaded.
• Deployments: egress policy controls exposed on the deploy surface.

• Platform: the redesigned consoles, onboarding and navigation shipped in one release.
• Platform: one shared application shell and module sidebars across consoles, with duplicate navigation destinations removed.
• Platform: legacy workspace URLs retired and permanently redirected to their canonical modules.
• Optimal: chat sessions and workspace records bound to the active organization and workspace.
• Deployments: customer-facing "Docker" wording replaced with "App Engine".
• Sign-in and accounts: the theme default follows your operating system's light or dark setting while explicit choices are kept.
• Workflows: workflow runs moved to durable run groups.
• Sandboxes: the control plane was completed with batch, environment and template surfaces.

• Databases: provisioning contracts and layout corrected, and the database resource inventory scoped and aligned.
• Deployments: the deployment creation flow was fixed.
• Computers: the archived computers fleet experience corrected.
• Projects: project filters stabilised.

• Databases: the database list and detail page show platform recovery as its own state with polling and a data-preservation message, instead of collapsing it into provisioning or error.
• Agents: one server-owned action decision for every surface - an actions catalog, authorize, approvals with approve and deny, grants and receipts.
• Builds: durable reviewed app documents - create, version, review, publish and run generated apps over the API, with declared data collections, resumable automations and callbacks bound to action authority.
• Usage: /usage rebuilt as a usage control console with spend, ledger, plan rates, reports and controls views and a per-resource cost explorer.
• Account: /account rebuilt as a console with profile, security and access sections.
• Docs: an agent operating guide, a platform BYOC page and a databases API reference.
• Sign-in and accounts: an email change page at /email-change.

• Sign-in and accounts: credential locations consolidated - /api-keys owns platform access keys, /integrations owns provider credentials, and CLI sessions move to /account, with the old paths redirecting.
• Billing: plan detail moved into the billing console, and the old plans and email settings paths redirect.
• Status: unsupported latency and 90-day uptime claims were removed from the public status page, which now reads as monitored checks with the latest verified timestamp.
• Docs: the changelog consolidated into a single release history, and the known-limitations page removed.
• Platform: light theme fixed across the shell.

• Databases: a managed database that was running when the service or a compute host was interrupted now comes back up automatically from its persistent volume, while deliberately stopped, paused, suspended, destroyed and retired databases are left alone.
• Deployments: permanent deployment appliances recover on their own after a host or service interruption, with bounded retries.
• Computers: a failed hibernation resume no longer destroys the computer's persistent disk, hibernation snapshot or address reservation, so the resume can be retried.
• Integrations: channel configuration and notification preferences save to the server instead of simulating it.
• Computers: one computer state model now drives the computer page and the sign-in callback.

Public contracts and deployment guidance

The CLI, API, SDK, data, domain, release, and deployment guides were aligned with the shipped platform contracts.

• API examples use the current production base URL and credential families.
• Sandbox snapshots, restore, fork, and lifecycle operations are documented.
• Release creation, exact promotion, production proof, and rollback are documented as separate steps.
• Managed database lifecycle, credentials, backups, restores, logs, metrics, and placement are covered.
• Documentation checks reject known stale commands, paths, and hostname patterns.

Usage and platform controls

Usage and billing surfaces now use consistent USD and credit meanings.

The Action Authority experience supports constrained approvals for sensitive operations.

• Security: the Action Authority console at /settings/action-authority - review and resolve pending agent action approvals, inspect immutable action receipts, browse the versioned capability catalog, and revoke standing grants, failing closed when the authority API is unavailable.
• Security: create exact action grants, each with a version, fingerprint, scope, constraints and expiry, with malformed or unconstrained grants refused before they save.

• Billing: credit balances and dollar balances agree across the dashboard, usage, billing and settings, with the ambiguous balance wording removed.

• Sign-in and accounts: the unsubscribe link in low-credit emails works - every opt-out had been returning 404, so the alerts kept re-sending.
• Billing: balance alerts are much quieter - one email per severity level, a further email only on escalation, no daily re-send, and no running-low notice at all when auto-recharge is on.
• Databases and deployments: the deployment page shows a managed database panel with readiness, database id, environment, engine and version, lifecycle state, and a note that preview environments use isolated database branches.
• Computers: computer deletion goes through one fail-closed path - owner-host resources are destroyed and verified before durable ownership is removed - so a deleted computer can no longer be reported deleted while its resources survive.
• Deployments: redeploying a sandbox-published App Engine deployment rolls out its active release instead of attempting a rebuild from source, with environment variables rematerialised.

• Computers: desktop branding is the platform's or the tenant's own end to end - the viewer title, favicon, loading, reconnecting and error states are replaced, and the tenant's product name, colours and logo are applied at provisioning and repair.
• Computers: the desktop viewer controls are restored - clipboard, fullscreen, display, scaling, keyboard, pointer and quality were hidden by a branding override.
• Computers: the desktop image installs the latest OSA release and exposes osa, osagent and miosa in the desktop terminal, with the retired launcher replaced by a terminal running the agent.
• Computers: white-label desktop wallpapers actually apply, so a tenant with a custom wallpaper no longer gets the default background on newly provisioned machines.
• Sandboxes: sandbox attributes returned to SDK callers no longer flip between two shapes, which fixes clients that failed to read them depending on the code path.
• Sandboxes: snapshotting or forking a paused sandbox clones its live rootfs instead of using a computer-style path, fixing fork and restore.
• Agents: managed runs are labelled from the agent's own terminal output, so a mid-run error or an abnormal stream close is recorded as a failure instead of "succeeded".
• Sandboxes: guest DNS works again - the resolver file is written world-readable so unprivileged workloads can resolve names.
• Billing: sandbox usage reports provisioned memory and creation count alongside vCPU, CPU and network.
• Billing: snapshot storage is billed from the observed physical object size, so charges match what is stored.

• Security: a sandbox token injected into a machine can no longer mint delegation tokens for arbitrary users.
• Security: oversized and compressed payloads are rejected before decoding on the open-computer codec and the local persistence journal.
• Computers: fixed cold desktop provisioning failing to start by colocating the image cache and persistent disks on the same device.

• Webhooks: run lifecycle events are durable and subscribable - created, running, succeeded, failed, canceled and file ready - and deliveries survive a control-plane restart.
• Webhooks: secrets must be 16 to 255 characters, and failed deliveries reset on reactivation instead of staying failed.
• Agents: managed Claude Code runs wait for the egress proxy before launching, removing intermittent connection-refused run failures.
• Agents: Claude Code and Codex are installed world-readable and executable inside the sandbox, so managed runs can start the CLI.
• Agents: the Claude instruction workspace is staged readable before the run starts, so a staged-access failure no longer aborts the run.

• Billing: sandbox spend limits - organization owners and admins can set a monthly cap or unlimited, choose ascending alert thresholds, and see spent, reserved and remaining for the period at Settings > Billing.
• Billing: sandbox admissions are refused with 402 SANDBOX_SPEND_LIMIT_EXCEEDED naming the scope, limit, spent, reserved and requested credits once the cap is reached.
• Webhooks: sandbox.spend_threshold_reached is a subscribable event alongside the existing billing events.
• Sandboxes: the create flow shows catalog-backed sizes with each contract id, vCPU, memory and disk, and a fast start, cold start or unavailable readiness badge, hiding sizes the template does not advertise.
• Sandbox snapshots: snapshot create accepts a retention or expiry, and snapshot responses expose retention, last used and expiry. A snapshot past retention returns 410 SNAPSHOT_EXPIRED.
• Sandboxes: a typed 429 with class, limit, requested, window and Retry-After when an organization allocates vCPUs faster than allowed.
• Docs: the sandbox, snapshot and cookbook pages and the published API specification were rewritten to match the shipped contract.

• Docs: the bring-your-own-cloud pages carry an explicit notice that customer-host provisioning and sandbox placement are disabled until the acceptance suite is complete.

• Sandboxes: POST /api/v1/sandboxes returns a dedicated 503 with Retry-After when the requested size is not currently available on the fleet, instead of an unhelpful error.
• Sandboxes: the published specification documents the size selector, the default small contract, persistent-by-default lifecycles and the default session timeout.
• Docs: the bring-your-own-cloud sandbox pool flow, covering account attach, preflight, region, pool and placement scope.

• Sandboxes: plan-gated sizes are enforced at admission, so an over-plan size is refused up front with a plan error instead of failing later.

• Catalog: GET /api/v1/compute/catalog returns the shape contracts, so a client or SDK can map each advertised size to its exact vCPU, memory and disk contract.

• Sandboxes: a typed 429 SANDBOX_CREATE_RATE_LIMIT with Retry-After and the plan class, limit and window when an organization creates sandboxes faster than its plan allows.
• Billing: sandbox metering is attributed to the sandbox's resource contract rather than raw request fields.

• Console: settings has one domain story - a Branding & Domains group, a dedicated branding page, domain and DNS management only on the domains page, and a live three-step setup guide that reflects real state.

• Console: the top navigation no longer paints over the search box - labels collapse to icons based on the nav's own width.
• Status: GET /api/v1/status/overview reports real per-service checks across API, auth, compute, open computers, AI and billing, instead of a permanently empty list.

• Computers: adopting a computer is re-identified in place instead of restarting - about 17 seconds down to about 1 second.

• Computers: the desktop stream no longer comes up dead - start waits for the desktop to bind before the session is handed over.
• Computers: storage clone durability fixed across every copy path, ending corrupt disks and the build and container failures that came with them.
• Sandboxes: restoring a sandbox rebases its rootfs off the shared golden disk, so restored sandboxes no longer corrupt the shared image.
• Console: fixed three 500s reachable from normal page loads - the integrations catalog, the egress audit and the workspace computers list.
• Console: the security audit and network pages were rewritten against the real contracts and return the expected shapes.
• Organizations: sessions minted before organizations existed heal from durable membership instead of locking the user out.
• Landing page: the homepage has a real main landmark again, restoring screen-reader navigation.

• Organizations: switch organization from the account page.

• Sandboxes: restore no longer forces memory pages in eagerly - pages are read lazily through the fault handler, so restoring a sandbox is cheaper.

• Organizations: legacy memberships are preserved and stale sessions recover their organization from durable membership, so users whose organization exists no longer see a create-an-organization screen.
• Organizations: access and membership authorization are enforced consistently across API keys, OAuth credentials and sessions.
• Sandboxes: placement retries on another eligible host when a reserved node is unreachable and releases the failed reservation.
• Sandboxes: a cloned rootfs is flushed before it is attached, fixing corrupt filesystems that dropped sandboxes to error.
• Databases: managed database readiness and reattachment were hardened, so a database attached to a deployment is ready before attachment.
• Deployments: attaching a database returns 409 DATABASE_NOT_READY with a clear message instead of partially attaching.
• Deployments: a host in draining state keeps serving its existing routes instead of returning 503 to live traffic.
• Console: API contracts were aligned for tenant, membership, grant, checkout and token flows.

• Organizations: multi-organization sessions through the API - list, current and switch endpoints, with the selected organization validated against membership and preserved across token refresh and page reloads.
• Computers: live memory resize. A computer boots at its family maximum and a balloon deflates it to the paid tier, so changing size now changes memory without restarting the machine, and the row and billing both use the paid amount. vCPU and disk changes still apply on the next full boot.

• Computers: customer-ready desktop time after a restore drops from about 9 seconds to about 3, because a healthy resumed session is kept instead of restarted.
• Computers: snapshots record the resume capability, so a fresh desktop restores from its snapshot instead of falling back to a cold boot.
• Billing: credit exhaustion rechecks the canonical wallet before suspending a running resource, so a concurrent top-up cannot leave a resource suspended.

• Organizations: invites recover the session for an accepted invitation instead of leaving the user stranded on the invite page.
• Organizations: switching surfaces retryable errors for invalid or revoked memberships.
• Docs: availability, known limitations, custom domain, invite, sandbox and SDK version pages were corrected against current behaviour.

• Organizations: an organization switcher in the header and mobile navigation lets a user in more than one organization change the active one.
• Computers: resize a computer with PATCH /api/v1/computers/{id} and a size. The response reports that a restart is required, the new size applies on the next boot, and the disk only ever grows.

• Computers: a resize boot waits for in-guest filesystem growth before reporting active, and an enlarged disk is re-expanded on every cold boot.

• Computers: restart runs on the computer's owning host instead of failing on the wrong node.
• Deployments: white-label App Engine apps route correctly across hosts.

• Databases: managed database runtimes are no longer treated as orphans and killed by the reaper, so instances stay up across sweeps.

• Computers: the desktop viewer URL for a computer is now <computer>.<your-computer-domain>/viewer, for embedding a desktop in your own app.

• Computers: desktop streaming is back on the direct low-latency path, and a healthy resumed session is no longer torn down on boot.
• Computers: desktops boot reliably - guest session startup is serialised and the startup deadlock is removed.

• Deployments: environment variables are passed through to App Engine apps, so database-backed apps boot with their connection string and secrets.
• Deployments: custom domains stay active - DNS verification accepts the canonical proxy target and verified domains attach instead of being marked failed.
• Deployments: App Engine apps are routed through their owning node, fixing 502s on custom-domain traffic.
• Computers: desktop provisioning no longer deletes the baked desktop layout, and white-label branding is applied to the real monitor after the desktop is live.

• Deployments: a deployment proof endpoint and a live proof panel on the deployment page, checking the deployment row, running state, public URL, host readiness, the app row, the container route and an optional HTTP probe - GET /api/v1/deployments/{id}/proof.
• Agents: expected outputs can declare an output root, so relative expected files are collected from a declared directory and absolute paths are preserved.
• Computers: an explicit restart reprovisions the machine rather than reusing a broken runtime.
• Docs: App Engine documented as the workspace container runtime for apps that need Docker, background processes or durable hosting, publishing to a public URL under deploy.miosa.ai, a workspace or tenant domain, or an exact custom domain.

• Docs: custom domain, known limitations, availability, share token, preview URL and SDK version pages refreshed, plus a reworked computers guide and docs navigation.

• Computers: the embedded desktop is resized to its frame, embed mode is restored, viewer parameters survive a reload, and the stream is tuned for low latency.
• Computers: desktop branding is restored after a repair, and the branded desktop stays active rather than dropping to the default shell.
• Console and docs: customer-facing surfaces can no longer ship legacy naming - App Engine is enforced by a naming check in the production deploy.

• Agents: active Claude Code and Codex runs no longer fail after three transient sandbox process-state misses; sustained failures still fail with full diagnostics.
• App Engine: the embedded console is back inside the workspace, its tabs route to the real console paths, and the sidebar entry is renamed to App Engine.
• App Engine: custom domains and app hostnames for published apps route to the appliance app, and duplicate workspace app hosts are resolved.
• App Engine: both the build command and the start command are sent to the appliance contract.

• Sandboxes: creating while scheduled capacity is still starting returns a distinct retryable 503 with a Retry-After hint, and real failures return a create-failed code instead of a misleading validation error.
• Sandboxes: sandboxes that enter an error state persist the failure reason and last error, so a failed sandbox says why.
• Status page: a status reading older than three minutes is shown as unknown and stale instead of being presented as current.
• Deployments: a release that crash-loops slowly is failed and dropped from retries instead of looping for days behind a running badge, and an abandoned release behind a healthy version is aborted within minutes.
• App Engine: publishing fails fast with a clear 503 when the appliance control token is missing, instead of surfacing a confusing upload 401.

• App Engine: builds install the release into the workspace appliance and call the endpoint it actually exposes, so App Engine deploys reach a running container instead of failing.

• Invites: organization and workspace invite emails are branded HTML with the logo, including older records whose template override was blank.
• Invites: invite landing pages show context before accepting, and legacy invite links redirect to the canonical page.
• Settings: webhooks point at the live contract, the unsupported manual retry control is gone, and email delivery shows an honest read-only status.
• Settings: organization and workspace member pages show real counts, hierarchy and wired invite actions.
• App Engine: the embedded portal signs in automatically with a platform-minted single-sign-on URL, tabs use the real portal paths, and links use the tenant deploy domain instead of exposing runtime URLs.
• App Engine: the clients page counts and labels appliances by portal readiness, showing stale hosts as needing repair, and portal readiness requires the backing runtime to be live with a fresh heartbeat.
• Console: the compute sidebar no longer shows fake expandable chevrons, deeper modules no longer double-highlight an unrelated item, and unclear labels were renamed.

• Deployments: releases larger than about 128 KB install instead of failing every retry with an argument-list-too-long error.
• App Engine: destroyed, failed and pending historical rows no longer appear as live apps in the deploy table.
• Users: deploying a new frontend version no longer strands open tabs on an error page - the app reloads once on a stale chunk and the error page offers a reload action.

• Billing: published plans are Free, Starter, Pro, Team and Enterprise with their credit and sandbox allowances, and accounts missing their welcome credit were backfilled.
• Computers: open-computer host, container and custom-domain limits cover Team and Enterprise, and the removed legacy plan is rejected.

• Settings: plan usage counts only resources that still exist, and members render with their real name, email and avatar.
• Billing: compute is metered only while the machine is actually running, so stopped machines stop accruing charges.
• Computers: always-on computers and app runtimes revive from their existing disks when their node reboots, instead of staying dead after a restart.

• Computers: computers left showing active with no machine running are flipped to stopped within minutes instead of showing live and billing.
• Sandboxes: running sandboxes are excluded from the orphan reaper, so in-use sandboxes are no longer destroyed by cleanup.
• Deployments: embedded app previews are no longer rate limited on request bursts.
• Data retention: destroyed resources older than 30 days and retired appliances idle for 14 days are permanently deleted by a daily job.
• Pricing: the console lists the current plan set and the free-plan copy says the right credit amount.
• Settings: compute and GPU pricing fallbacks match the backend rates, so the prices shown are the prices charged.
• App Engine: the embedded portal no longer shows implementation-provider branding in its frame chrome.

• Agents: a background run whose sandbox became unreachable is marked failed with diagnostics instead of sitting pending forever.

• Agents: agent runs no longer force-load a default tool server into every Claude Code and Codex run; it is loaded on demand.

• BYOC: bring your own cloud account through a documented API - attach a cloud account, choose regions, create pools, provision a pool, list nodes and run preflights.
• BYOC: connect with an access key and secret instead of a role trust, with the keys encrypted at rest and only a preview returned.
• BYOC: an onboarding kit - infrastructure templates, a least-privilege policy and a step-by-step guide.
• Deployments: white-label sandbox preview hosts can obtain TLS certificates on demand.

• BYOC: computers provision into your own cloud pool instead of the shared fleet, and scale on your own pool rather than the platform plan.
• BYOC: sandboxes in your own cloud are metered as orchestration and no longer deduct platform compute credits.
• Computers: desktop computers are persistent by default, while sandboxes keep their suspend timer.
• Computers: tenant branding is applied to provisioned desktops.
• Agents: the default run timeout for Claude Code and Codex runners is extended to 24 hours.

• Agents: runs no longer use an output mode that produced no final message.
• Deployments: the appliance portal route is registered when the appliance is marked healthy, and the appliance routes through the platform proxy rather than the machine address.

• Agents: run inputs can be injected as files into the runtime alongside materialised environment.
• Computers: provisioning failures are visible on the computer object and in the API, instead of a silent stuck state.
• Accounts: API keys can carry agent runtime profile scopes.
• Agents: a default tool server is wired into Claude runs.

• Agents: Claude Code is pinned to a specific version with an isolated package cache, its tool server configuration is loaded, and the runner is isolated from the home bin directory.
• Agents: sandbox agent runs execute as tracked background processes, and the agent binaries are exposed to the sandbox user.
• Agents: runs fail fast when a required connector is unavailable.
• Agents: run workspace lifecycle and long-run file transfers were hardened.
• Computers: active computer machines are protected from the orphan reaper.
• Sandboxes: sandbox resume restoration is explicit, and a snapshot resume routes to the host that recorded it.

• Agents: one run contract behind POST /api/v1/runs with command, custom, Claude Code and Codex runners, and a single run read surface for outputs, messages, command output, files, previews, activity, events and diagnostics.
• Docs and API: the developer API reference is generated from the live routes, and a check fails when a live route is undocumented.
• Databases: managed databases accept external workspace, user and project ids for attribution, matching sandboxes, computers and agent runs.

• Sandboxes: in-sandbox provisioning became opt-in - new sandboxes get read and interact only unless created with provisioning allowed, and provisioning calls otherwise return 403.
• Deployments: appliance DNS labels are capped so they resolve, and invalid hostnames are rejected at registration.
• Agents: Codex runs in explicit non-interactive mode with its working directory set, and Claude and Codex output is bridged into run messages when no structured final message is returned.

• Deployments: the janitor no longer kills deployment runtime machines - they were missing from the supervised set and were being killed every ten minutes.

• Agents: agent runtime provider commands were fixed, Codex runs non-interactively inside the isolated runtime, and Codex uses the workspace home.
• Computers: desktop agent tool readiness and computer agent command execution were fixed.
• Docs: the benchmark page was published with per-lane detail, and the Python and TypeScript SDK pages were updated.

• Deployments: the appliance liveness probe routes to the node that owns the appliance rather than the control plane.
• Sandboxes: template readiness probes are cached instead of re-probed per request.

• Sign-in: GitHub sign-in works - the routes had been returning 500 because only the Google handlers existed. GitHub users are deduplicated by email, with a fallback when GitHub hides the address.
• Computers: passwordless desktop embedding - GET /api/v1/computers/{id}/embed returns a viewer URL carrying a short-lived token for iframes.
• Computers: GET /api/v1/computers/{id}/urls, GET /api/v1/templates and GET /api/v1/webhooks/events with signing metadata.
• Databases: managed databases take a scheduled daily backup, with per-day idempotency, per-database failure isolation and retention pruning - previously they had no automated backups.
• Billing: a tenant whose resources were paused for exhausted credit resumes automatically on top-up.

• Computers: desktop developer tools are repaired on boot and validated by running them, with a fallback that replaces a crashing shim; a slow repair no longer marks a healthy desktop as errored.
• Agents: Claude Code runs work on desktop computers, inheriting the machine's or sandbox's environment variables.
• Billing: balance alerts fire on the real spendable balance.

• Deployments: deployments orphaned between a ready release and the deploy are finished by a reconciler instead of hanging forever.
• Deployments: appliance hostnames stay inside the DNS label limit and prefer the human workspace name over a UUID slug.
• Sandboxes: a doubled prefix in sandbox preview URLs was removed.
• Sandboxes: legacy platform-owned preview domains are treated as stale and cleared, while a real tenant-owned base domain still works.
• URLs: the platform enforces one URL contract - miosa.ai for the platform and sandbox previews, miosa.app for durable published deployments.

• Sandboxes and computers: GET /api/v1/compute/catalog exposes the canonical product, template and size metadata with per-entry artifact readiness.
• BYOC: authenticated cloud routes for accounts, role attach, regions, pools and preflights, with new cloud read and write scopes.
• Console: the platform console separates the authenticated desktop session from the desktop viewer password, so opening a computer no longer needs the viewer password.

• Sandboxes: pricing and catalog readiness are aggregated across the live fleet instead of reporting one node's local state.
• Sandboxes: warm-pool refill enforces the exact requested size and clears stale health state after a refill.
• MCP: the create tools advertise the canonical sizes.

• Sandboxes: slot validation no longer requires a per-slot image to already exist, which had collapsed the fleet onto a single base snapshot and capped concurrency.
• Sandboxes: an exec touching shared state can no longer crash the sandbox process.
• Databases and sandboxes: managed database credentials can be rekeyed with zero downtime, and a control-plane restart or deploy no longer destroys running sandboxes or mislabels a clean shutdown as an error.

• Deployments: appliances provision at a new starter tier and are resizable up through larger tiers.
• Deployments: appliance scale to zero - hibernating frees the appliance's memory in about a second and waking restores it in place with the database and portal intact.
• Console: an all-clients dashboard showing every workspace as a client with all of its appliances and deployments in one view.

• Deployments: resizing an appliance up a tier now takes effect - the resize allowlist had been hardcoded to the base sizes.
• Deployments: appliance sizes pass schema validation on both the computer and deploy host schemas.

• Billing: the credit ledger is the single source of truth for balance reads, including the balance reported to MCP clients, which previously read a stale mirror.
• Billing: the tenant top-up mirror is kept in sync with the ledger, so top-ups are reflected immediately.

• Agents: connector attach, sync, preflight and detach for sandboxes, computers and deployments, plus provider triggers with one-time webhook tokens and signed inbound webhook verification.
• Docs: about fifteen missing product pages restored and re-linked, covering the deploy API reference and the agent product, runtime, device and workflow guides.
• Accounts: the workspace invite acceptance page was rebuilt with preview, expired, already-accepted and error states.
• Console: an Ask AI drawer on the docs site.

• Sign-in: token refresh retries with backoff on transient failure instead of dropping the session.
• Billing: the console credit balance shows the correct dollar value.

• Billing: balance alert emails gained a visible unsubscribe link and one-click unsubscribe headers, and no longer leak a placeholder organization name.

• Agents: sandboxes can run platform-managed Claude Code agent runs, and a run can be dispatched asynchronously into a sandbox rather than blocking the request.
• Sandboxes: command records accept arbitrarily long commands, so long exec commands no longer fail.

• Accounts: the current-tenant endpoint resolves for API-key callers such as the SDK and CLI instead of always returning 404.
• Computers and sandboxes: preview and deployment domains are separated from computer domains.

• Billing: the public pricing page works again - four read-only pricing routes had been behind authentication and returned 401 with no token, so the page showed a loading state forever.
• Billing: usage rollups no longer fail when compute or runtime attribution fields are missing from a record.

• Agents: agent runtime profiles standardise which runtime, tools, connectors and environment apply to agent runs, and machines inherit a profile by default with the option to pin or skip one.
• Agents: orchestration groups - create a group of runs, dispatch it, cancel it and stream grouped run events.
• Agents: signed, short-lived download links for agent run artifacts and sandbox exports, and run artifact bytes are persisted so artifacts survive after the run finishes.
• Agents: cancel a running agent run, and cancel sandbox process runs.
• Agents: runtime environment variables inherited per organization, workspace and project, with a deployment target.
• Sandboxes: export and download sandbox contents.
• Docs: inherited runtime environment, MySQL and Qdrant data pages, and pages for the enterprise data partner pattern and transactional email.

• Sandboxes and computers: stored environment is injected into exec, so variables set on a machine now apply to its commands.
• Agents: runtime environment is injected into agent runs, and profile environment into machine exec.
• App Engine: the portal single-sign-on handshake survives a cross-host proxy hop, so the embedded portal logs in instead of returning 401.
• App Engine: the host watchdog no longer re-provisions a healthy appliance and the revive loop is bounded, so appliances stop flapping between healthy and unavailable.
• Billing: the AI inference rate sheet is realigned to market pricing.
• Billing: outbound egress is metered per tenant at 5 cents per GB, and the unified credit wallet is enabled.
• Billing: persistent volume storage is billed per provisioned GiB-hour, attached or not, and database backup storage per GiB-hour.
• Billing: deployment builds, functions and buckets deduct from the credit wallet.
• Billing: every ledger line is itemized with its resource type and id, and spend can be grouped by resource or product.
• Billing: balance alert emails read the real credit balance, so a tenant holding credits no longer gets a false budget-exhausted email.

• Sign-in and accounts: real password reset for apps built on platform app authentication - POST /api/v1/app-auth/{resource_type}/{resource_id}/password-reset always returns 202, stores a hashed one-hour token and emails a confirmation link, and the confirm route sets a new password and invalidates the token.
• Sign-in and accounts: real email confirmation for app authentication - when a project requires it, signup creates a 24-hour token, emails a confirmation link, and login for an unconfirmed user is refused.
• Databases: MySQL and Qdrant are creatable, and the supported-engine list in error bodies now names them.
• Databases: PostgreSQL images ship the vector extension, so it can be enabled without a runtime install step.
• Databases: persistent volume attach and detach on computers - hot-plug a disk into a running machine and unmount and unplug it, both of which previously returned 501.
• Agents: target-agnostic agent runs - dispatch a natural-language prompt to an agent runtime inside a sandbox or computer, list runs and inspect one.
• Agents: agent run outputs are recorded as durable run events and declared artifacts, with a runtime capabilities listing and artifact download.
• Agents: a managed connector works end to end - the vendor token never leaves the platform and an egress allowlist rule is seeded on first use.
• MCP: sandbox operations route through the sandbox engine, with new stop, extend, snapshot delete and fork tools.
• Builds: Bun and Hono app templates for a JSON API and for HTMX.
• SDKs: agent device facades added to the Go, Python and TypeScript SDKs.
• Docs: backend agent orchestration guides, agent product workflow guides, and an agent runs API reference.

• Agents: creating a secret with a connector binding works in one request.
• Billing: the console dollar value of the credit balance uses the canonical credit-to-cent ratio, matching whoami and invoices.
• MCP: the storage object tools were corrected against the live contract - upload uses a raw body, list parses the keys, and download decodes raw bytes.
• Docs: Mermaid diagrams render and the mobile docs shell is fixed.

• Sandboxes: sandboxes are persistent by default - stopping a sandbox preserves its filesystem and returns a resumable paused sandbox, create accepts opting out, and delete destroys it.
• Sandboxes: attach provider connectors to a sandbox, with sync, preflight and detach, and a connector catalog.
• Agents: managed connector presets can be configured per tenant without storing a vendor token.
• Deployments: the deployment page gains a versions tab with a chronological table, per-row promote and rollback, and an active-version highlight.
• Docs: snapshots documented as preserving filesystem state across sessions, checkpoints and forks, and an agent platform documentation set published.

• Sign-in and accounts: the current-tenant endpoint reports the real plan name and returns the balance from the ledger, so CLI auth and API-key callers see the correct plan and balance.
• API keys: newly minted keys can carry the egress read and write scopes.
• Computers: white-label desktop URLs stay on the tenant's own computer domain and are never built on the reserved deploy portal domain.
• Deployments: sleeping and waking status badges on the deployment page.

• API keys: tenant owners and admins can self-create tenant-wide platform keys - POST /api/v1/api-keys with a platform key type mints a tenant key, the default stays a personal user key, and a non-owner gets 403.
• API keys: key creation in the console asks for a key type - tenant automation with full tenant access for server-side use, or a scoped personal key.
• Billing: new signups are granted $10 of starting credit instead of $5, and the grant upserts so it cannot be silently dropped.
• Billing: the organization-create signup path grants the starting credit too, so new organizations no longer start at zero.
• Billing: the default tenant usage budget rose from $5 to $100, so new tenants are not paused almost immediately.
• Deployments: app subdomains under a workspace deploy domain resolve to the deployed container, and the appliance portal domain routes to the portal.
• Deployments: a short-lived single-sign-on URL for the appliance portal, so opening the embedded portal does not ask for a second login.
• Console: onboarding completes once - users who finished are sent straight to their projects - and the final step links to CLI setup.

• Billing: a tenant with credits remaining is never paused by the budget gate.
• Billing: the remaining balance shown on the billing screen is the credit balance net of usage.
• Sandboxes: exec and other operations refresh the idle clock, so a sandbox is no longer stopped mid-use.
• Sandboxes: large file uploads work - payloads are sent in chunks instead of failing on one oversized command.
• Sandboxes: the default timeout rose to an hour, the Starter concurrent-sandbox limit rose from 1 to 3, and a failed boot returns the reason in the response.
• Computers: always-on and permanent computers are never reaped, so an always-on computer is no longer destroyed after entering an error state.
• API keys: listing and revocation are role-scoped, and platform keys are tenant-wide with a much higher rate limit than user keys.

• Deployments: an observability endpoint returning invocations, error rate, latency percentiles, CPU, memory and cold-start rate for a selectable window.
• Deployments: per-request access logs with paging, status and time filters.
• Deployments: a per-route breakdown with invocations, error rate and latency percentiles.
• Deployments: runtime application logs with a live stream, and build log streaming per version.
• Builds: build machines default to 4 vCPU and 8 GB, with a smaller tier selectable per deployment.
• Console: the App Engine section was rebuilt as a native workspace with deployments, projects, domains, databases, logs, usage and settings tabs.

• Sandboxes: fast-boot sandboxes honour the memory you request instead of always resuming a default shape.

• App Engine: deployments default to native Docker-capable runtime nodes instead of running Docker inside a workspace computer, with the previous behaviour still reachable.
• Console: the deployment list no longer scrolls horizontally, and API key error states are human-readable with distinct copy for each failure.
• Console: the logs empty state distinguishes "log aggregation not enabled" and points to resource-level logs.

• Docs: the API key page was rewritten around the two key types, and the CLI page and published specification were refreshed.

• Deployments: log snapshots accept server-side filters - line limits and tail, time bounds, text and regular-expression include and exclude - across deployments, computers, sandboxes and databases, with a named error for an invalid expression.
• Sandboxes: list the listening ports inside a sandbox with the owning process.
• Sandboxes, computers, databases and deployments: a resource metrics summary returning state, readiness, CPU, memory, disk, uptime, timeout remaining and boot timings.
• Deployments: curated Dockerfile and Compose starting points for a range of frameworks and workers, selectable when creating a deployment.
• Deployments: workspace host endpoints for the console, SDK, CLI and MCP callers, and MCP tools to create a App Engine.
• Organizations: workspace email invites - create an invite, get a shareable link, preview it publicly and accept it.
• Organizations: project member roles over the API.
• Console: member settings support email invites with a role, list pending invites with expiry and a revoke action, and an acceptance page handling expired, revoked, already-accepted and email-mismatch states.
• Console: a App Engine section in the sidebar embedding the appliance portal, and a deployment wizard that accepts deep links with a template preselected.
• Docs: pages for connecting third-party computer providers, a comparison against other providers, and the component library with design tokens, plus a App Engine guide and API reference.

• Console: sandbox lifecycle actions work from the list - pause, resume and snapshot per row with toasts, and the stats strip shows ready and provisioning counts.
• Console: settings reflow on narrow screens and the login page preserves a safe redirect destination through login and MFA.

• Sandboxes: a fused run endpoint - POST /api/v1/sandboxes/run creates the sandbox, waits for it to be command-ready and runs the first command in one call, returning the sandbox, the output, the exit code and server timings.
• Computers: the desktop sign-in gate renders tenant branding for white-label tenants.
• Docs: the landing page redesigned with getting-started paths, and an Ask AI assistant rail on documentation pages.
• Docs: a benchmarks page publishing a verified production run - 100 sandboxes at concurrency 10, all successful, with command-ready latency percentiles - plus a provider comparison.

• Computers: the desktop opens in a native viewer client instead of loading the viewer from a public CDN, so keyboard and mouse input reach the guest reliably.
• Computers: a desktop URL reports ready only once a real session is up, and the cold-boot window was raised so the first open shows the desktop instead of an error.
• Computers: desktop entry paths always route to the viewer gate, so an unauthenticated visit goes to sign-in rather than a broken page.
• Docs: sandbox documentation gained a documented fast path.

• Computers: a per-computer desktop password gate - the viewer shows a prompt, the owner reads and rotates a one-time password, and a public rate-limited session endpoint issues a token.
• Agents: one-shot composable app lifecycle - an agent can deploy an app, create its resources and attach a domain in one call, through the API or the compose tool.
• Databases: Qdrant added to the engine model, and vector extension support for PostgreSQL.
• Deployments: a deployment records its linked bucket and auto-provisions a database and storage bucket on create.

• Billing: the active payment provider was cut over to the live provider.

• Sandboxes: creating from an app template seeds runnable starter code into an empty workspace and starts it after seeding.

• Billing: the credit balance comes from the credit ledger directly, fixing "credits show 0" from a drifted mirror column.
• Billing: a tenant holding credits is no longer blocked by an exhausted dollar budget - the credit check and the budget check are alternatives.
• MCP: the server reports its version without an API key.

• Deployments: attach a managed database to a deployment without leaving the deploy flow - POST /api/v1/deployments/{id}/database.
• Builds: read build and runtime logs for a single version, optionally filtered by stage.

• Deployments: log snapshots return without streaming and tolerate missing buffers, so logs read immediately after a deploy.
• Deployments: sandbox-published apps stay on runtime routing instead of falling back to static routing, fixing 502s on server-rendered deployments.
• Deployments: publish responses name the real publish model instead of always reporting a static release.
• Deployments: the deprecated XSS-protection header is gone, and the content security policy no longer allows localhost frame ancestors.
• Sandboxes: the default lifetime rose from 300 to 900 seconds when no timeout is passed, so framework and package installs stop timing out.
• Databases: using a database that is not running returns a structured connectivity error instead of a generic failure.

• Console: the dashboard is rebuilt as a command center with a desktop shortcut, compute by status and by region, and a recent-activity feed.
• Console: the observability query page is real - environment and time-window selectors, a query editor, summary tiles, an event timeline and a results table.
• Console: the observability functions page shows live metrics instead of placeholders.

• Console: platform navigation category links are clickable again and the mega menu is keyboard accessible.

• Billing: plan purchases, credit top-ups, saved-card charges, refunds and cancellations work again on a single payment provider instead of returning a server error.
• Billing: choose any top-up amount between $1 and $5,000 instead of four fixed buttons.
• Billing: auto-recharge charges the saved card and grants credits instead of only sending a notification.
• Sign-in and accounts: signup sends an email verification message, and buying credits or subscribing requires a verified email while free credits do not.

• Billing: balance alert emails are throttled to once a day instead of every fifteen minutes.
• Billing: running computers and deployments draw down the same credit balance as sandboxes, so one wallet covers all compute.
• Console: the billing page rechecks the balance after a successful top-up, so new credits appear without a manual refresh.
• Computers: the computer workspace page no longer overflows its header or detail panels.

• Billing: a reworked billing and pricing surface - checkout and auto-recharge go through unified endpoints, credit purchase offers preset and custom amounts from $1 to $5,000, and the plans page loads the real plans instead of hardcoded ones.
• Console: "coming soon" surfaces were replaced with real ones across observability alerts, notebooks, project members and security, with the coming-soon route removed.

• Computers: desktop access restored on mobile, and the mobile sidebar keeps its icon rail.
• Settings: verified preview domains display as verified.
• CLI: sign-in redirects survive onboarding, so finishing onboarding returns you to the CLI authorization flow.

• Billing: removed portal buttons that returned a server error, since the payment provider offers no hosted portal.

• Sandboxes: restoring a snapshot restores the workspace filesystem, so files written before the snapshot come back.
• Sandboxes: POST /sandboxes accepts a size (xs through xl), and the default memory is 4096 MB instead of 1024.
• Sandboxes: when capacity is still initialising after a restart, creation returns 503 with Retry-After and a distinct code, so SDKs back off and retry.
• Sandboxes: boot reliability - the warm pool refills on any deficit, network slot acquisition is shuffled, and a liveness check removes most snapshot failures.

• Security: a sandbox token injected into a machine can no longer mint delegation tokens for arbitrary users, and the caller's node must own the sandbox before a token is signed.
• Security: sandbox tokens go through the same scope checks as API keys, and provision scope is required to create resources.
• Security: sandbox token lifetime is capped at 24 hours when a caller asks for an unbounded value.

• Sandboxes: every sandbox boots with platform identity available inside it - seven environment variables including a signed token that authenticates back to the API, so code inside the sandbox can call the platform without embedding a real key.
• Sign-in and accounts: POST /api/v1/tokens/scoped lets white-label tenants mint short-lived tokens bound to one end user and workspace, capped at 24 hours, with scope escalation refused.
• Sandboxes: a sandboxes:create scope implied by sandboxes:write, so existing keys keep working.
• Sandboxes: a file tree, batch write of up to 100 files, and live file watch over a stream.
• Sandboxes: process control answers on the main API host instead of returning 404.
• Sandboxes: public share URLs backed by short-lived share tokens.
• Quotas: per-end-user quota limits, enforced when a sandbox is created with 429 QUOTA_EXCEEDED.
• Billing: GET /api/v1/usage rollups grouped by end user, end project or workspace over 7 days, 30 days, month to date or a custom range.
• Organizations: a cursor-paginated GET /api/v1/audit-log filterable by type, actor and resource.
• Events: a tenant-wide event stream with glob type filtering.
• Deployments: framework detection extended to Astro, SvelteKit and Dockerfile, with static versus server-rendered chosen automatically and Dockerfile builds succeeding instead of failing closed.
• Databases: a sandbox on one host can reach a managed database on another host.
• API: the preview-domain routes accept API keys, matching the SDKs.
• Sandboxes: starting a project template registers its preview so the proxy can route to the dev server port.
• Sandboxes: snapshot to fork preserves the workspace, so files written before a snapshot survive into the fork.
• Docs: the homepage rewritten with code samples across five SDKs, and a cookbook overhaul adding embed-a-sandbox, per-user quotas and billing, and sandbox events in real time.

• Volumes: attaching a volume no longer reports success without mounting anything - it returns a clear refusal instead of a false success.
• Sandboxes: creation succeeds when the delegated end-user id is not a UUID, by attributing the sandbox to the organization.
• Docs: the sidebar active state was rebuilt so the indicator no longer shifts content.

• Docs: twenty-two new pages for the release - API references for preview tokens, sandbox shares, tenant preview domain, branding, quotas, usage, audit log, tenant events, sandbox environment, processes, files, templates and webhooks, a five-page integrations section including a white-label walkthrough, and four drop-in UI component pages for React, Vue and Svelte.

• Docs: a full audit pass correcting status values, the default working directory, preview URL shapes and the tool count, and removing internal mechanism detail while keeping every user-facing number. The open-source repositories are public.

• Agents: the expose tool returns the named computer's URL, so the returned URL routes for named computers instead of only identifier-prefixed slugs.

• Databases: resize a managed database's disk between 1 GB and 1 TB with PATCH /api/v1/managed-databases/{id}.
• Databases: deleting a project or workspace now cascades to its managed databases.
• Webhooks: lifecycle webhooks for sandbox, managed database and deployment state changes, so consumers can react without polling.
• API: the event-stream ticket endpoint accepts API keys, which previously got 401.
• API keys: keys can be scoped to a single workspace, isolating them per workspace.
• Sandboxes: register a custom domain for a sandbox, not just for a computer or deployment.
• Console: the domains panel gained an inline wizard - list, add with validation, a DNS setup card, per-domain verify and remove.
• Settings: custom domains UI with a unified CNAME target, and the plan card reads concurrent-sandbox limits from the API instead of a hardcoded number.
• Notifications: a bell in the header with an unread badge, a dropdown, and mark-one and mark-all actions.
• Docs: a Claude Code skills guide.

• Security: connected OAuth accounts refresh their tokens automatically, and if the provider's token endpoint is down the request is served with the existing token rather than failing.
• Throughput: API rate limits raised substantially - the public API and authenticated keys from 300 to 30,000 requests a minute, event streams from 300 to 3,000, and sign-in from 20 to 60.
• Webhooks: delivery hardened - latency recorded per attempt, retries extended to eight attempts over about 24 hours, and a terminal dead-letter state instead of silent loss.

• Sandboxes: the sandbox terminal connects again - it had been closing immediately because the wrong protocol was echoed.
• Security: the OAuth callback redirects to a completion page with a success or error status instead of leaving the popup unresolved.

• Security: security is a top-level console module - overview, secrets, network, audit and OAuth providers - with Secrets, Network and Audit Log tabs on the sandbox page too.
• Security: connecting an OAuth account completes in a popup that closes itself and refreshes the secrets list, with a getting-started path on the landing page.
• Workspaces: a three-step create-workspace wizard and a per-workspace settings page with identity, compute defaults (maximum computers, maximum size, auto-suspend, always-on) and a guarded delete.
• Workspaces: a workspace switcher as a command palette with fuzzy search, keyboard navigation and a URL parameter; list pages re-fetch on switch.
• Workspaces: an activity feed with the last ten events on the workspace settings page.
• Organizations: workspace invites - create, list, revoke, preview and accept.
• Resources: move a sandbox, deployment, database or project to another workspace with POST /api/v1/{resource}/{id}/move.
• Projects: DELETE /api/v1/projects/{id}, refusing with 409 PROJECT_HAS_DEPENDENT_RESOURCES when child resources still exist.
• Databases: managed database REST routes, including additional databases per project.
• Databases: every sandbox in a project with a running managed database gets its connection string written to a platform env file at boot, so sourcing that file is enough to connect.
• Onboarding: a two-screen post-signup flow, a welcome email with three calls to action, and a five-step product tour.
• Notifications: a per-user notification centre with unread count and a live stream.
• Status: the public status page reworked, with a header health indicator.
• Docs: a security API reference, a troubleshooting page, a five-SDK security reference, and three cookbook recipes.

• Sandboxes: the expose call now returns a URL that actually routes instead of a broken port form.
• Sandboxes: published templates are pushed to every region, so the first sandbox in any region lands on the snapshot boot path.
• Sandboxes: file writes are permitted under the standard workspace, home, temporary and platform directories.
• Databases: managed database provisioning completes in about five seconds instead of hanging and leaving databases failed.
• Organizations: creating a workspace immediately adds the creator as owner, so the next request no longer fails.
• Organizations: creating a project auto-provisions its volume and default database.
• Domains: a tenant that points a wildcard CNAME at the platform proxy has its preview domain bound automatically on first request.

• Docs: corrected preview URL examples and the content security policy example.

• Agents: the hosted tool server grew from 9 to 145 tools, covering computers (lifecycle, desktop methods, files, checkpoints, environment, logs, domains, services), sandboxes (lifecycle, files, snapshots, logs, expose, deploy, templates), deployments, storage, databases, workspaces and billing.
• Agents: new desktop-control tools (screenshot, click, double-click, type, key, move cursor, scroll) and introspection tools for sandboxes and deployments.
• Security: a credential vault with OAuth-connected accounts, a network allowlist with audit-only and enforce modes, and a live audit log.
• Computers: Secrets, Network and Audit Log tabs on the computer page, with the audit log tailing live.
• Organizations: per-workspace membership with owner, admin, member and viewer roles, with non-member requests refused.
• Organizations: invite by email, with preview and accept routes and the invite email sent by the platform.
• Organizations: settings split into organization members and workspace members.
• White-label: a custom-domain setup wizard with a branding preview card.
• White-label: requests to an unknown or unverified host return a named error, and a credential belonging to a different organization on a pinned host is refused.
• CLI: the authorization page shows the code and an explicit sign-in screen, and the login page explains the sign-in is for the CLI.
• Docs: a hosted tool server guide with per-client tabs and the full tool catalogue, an agent development kit guide, a benchmarks page with reproduction commands, and a custom-domains page.

• Sandboxes: a new template builds its snapshot automatically at creation, so its first boot lands on the fast path.
• Console: the code editor is loaded only when an editor opens, and polling pauses while a tab is hidden.

• Console: every settings page rendered as raw unstyled HTML because its stylesheet was missing after a refactor; restored.
• Console: the domains page was stuck loading from an infinite refetch loop, and the deploy page was hammering the deployments API.
• Console: a re-render loop was firing about a thousand requests in ten seconds at the projects API and getting rate limited.
• Billing: the billing page crashed when a non-essential endpoint returned 404; it now degrades instead of failing the whole dashboard.
• Docs: walked back an over-claimed benchmark comparison and moved unshipped claims into a roadmap section.

• Sign-in and accounts: SAML single sign-on settings - upload identity-provider metadata or configure manually, see status, test login, download service-provider metadata and follow a setup checklist.
• Deployments: webhook endpoints at /settings/webhooks with per-endpoint delivery history and a retry action.
• Sandboxes: an SSH tab on the sandbox page with the connection string, key download and agent setup instructions.
• Deployments: a version selector with one-click rollback on the deploy page, plus a runtime instances tab with polling, restart and state badges.
• Console: new settings surfaces for tokens, security, notifications, audit, integrations and usage, plus per-project settings and workspace environment variables, logs and webhooks.

• Billing: billing copy renamed from the previous payment provider to the one actually in use.

• Organizations: organization slug setup is enforced during onboarding and in account settings.
• Docs: scoped preview domains documented and a public API specification added.

• Console: compute workspace polish - consistent sidebar pattern, standardised spacing and fixed shell scrolling.

• Computers: a desktop control API - hotkey, key down and up, clipboard read and write, screen size, environment info, wallpaper, accessibility tree, mouse down and up, cursor move, and seven window operations.
• Deployments: read production runtime instances, one instance, and its logs.
• Projects: a project workspace backend so consoles can create and list compute projects.
• Console: a projects workspace with a per-project shell and nineteen sub-pages.
• Docs: miosa.ai/docs relaunched as a native part of the console with 67 pages, search, a command palette and diagrams.
• Docs: a public machine-readable docs index, llms.txt, llms-full.txt and an OpenAPI document for agents and tooling.
• Status: a public status page.
• Docs: all desktop methods, the CLI command reference, the Python SDK reference, the tool server guide and the white-label guide.

• Docs: usable on phones with tap targets, a full-screen assistant drawer and scrollable tables.

• Files: file download works, streaming through the native read path instead of shell and base64.
• Files: seven file operations pointed at the wrong path and are corrected.
• Computers: right-click and scroll no longer freeze the desktop for ten seconds.
• Agents: hardened the computer tools.

• Computers: a desktop is reported active only once its desktop agent is actually responding, instead of during boot.
• Sandboxes and computers: HTTPS inside a machine no longer stalls - link-local IPv6 is disabled so a browser cannot fall back to a dead route, and TCP segment clamping is applied on the sandbox network path.

• Agents: six tools to control a computer desktop - click, type, key (single keys and combinations), scroll, drag and launch an application.
• Sandboxes: tag sandboxes, deployments, databases and domains with your own external workspace, user and project ids, read them back on responses and filter lists by them.
• Sign-in and accounts: new API key scopes for project authentication and project integrations.

• Computers: file writes are binary-safe and no longer limited by shell argument size, so larger files, quotes and heredocs work.
• Computers: file writes create missing parent directories, and files written under the home directory are owned by the user so applications can read them.
• Computers: agent calls retry transport failures, reducing unavailable errors.
• Computers: scrolling up on the desktop no longer stalls for about ten seconds, double-click is available, application launch resolves common aliases, and typing is faster.
• Sandboxes: pip install works without special flags, since the externally-managed marker is removed from the image.
• Sandboxes: a 1 GB swap file is baked into the image and activated at boot, so large installs and builds are less likely to be killed.

• Sandboxes: create and manage your own sandbox templates alongside the built-in ones.
• Sandboxes: define a template with a build spec - base image, CPU, memory, disk, steps, environment, workdir, user, start and ready commands, preview port and artifact paths - validate it, build it and follow the build to ready or failed.

• Computers: Chrome starts reliably in the desktop, with shared memory sized and the sandbox flags set correctly.
• Computers: Chrome runs with full browser capabilities, with the restrictive process and extension-limiting flags removed.
• Sandboxes: workspace panels are gated on the sandbox being ready, and the preview route offers a retry.
• Sandboxes: the files and git tabs always use the sandbox API, and the ports tab exposes ports through it with the backend-issued preview URL.

• Sandboxes: first-class previews for a sandbox port, each with a name, port, visibility and metadata.
• Sandboxes: set a preview time to live between 60 seconds and 7 days, mark a preview private so it requires authentication, and share it with a time-limited link that can be revoked.
• Sandboxes: request a region for a new sandbox, used for placement and persisted.
• Deployments: publish static output from a running sandbox into an immutable deployment version, optionally promoting it in the same call.
• Deployments: list and read versions, promote a ready version, and roll back to an older ready version.
• Deployments: attach, list, verify and remove custom domains, with several per deployment.
• Deployments: apex domains can be registered, verified and served, not only subdomains, with a redirect policy between the apex and www.
• Deployments: the API returns the exact DNS records to create with verification instructions.
• Sandboxes: an artifacts tab showing the preview URL, lifecycle state and output paths.

• Deployments: a promoted static version is served at the deployment hostname and its verified custom domains from immutable artifacts with long-lived cache headers.
• Deployments: registering a domain is idempotent, so repeating the same registration returns the existing domain.
• Sandboxes: preview traffic has its own per-preview rate limit, and previews are served so they can be embedded, with the preview token stripped before the request reaches the app.
• Computers: restoring from a saved snapshot boots through the snapshot path, and the restored machine comes back running with its network rebound.
• Computers: desktop and terminal stream tokens are replicated to the host running the computer, so streaming works on every host.

• Deployments: a domain that already belongs to another resource is refused instead of creating a duplicate.
• Sandboxes: deploy returns specific errors instead of a generic failure when the sandbox has no runtime address or the port is invalid.

• Sandboxes: list the built-in templates with the default template id, and read one template's defaults.
• Sandboxes: run a template inside a running sandbox, installing dependencies, starting the dev server and returning an artifact manifest.
• Sandboxes: read a sandbox's artifact paths, preview metadata and lifecycle state.
• Sandboxes: opening a terminal returns a short-lived token and its expiry for the terminal socket.

• Sandboxes: create from a template and inherit its CPU, memory, disk, readiness probe, preview port and workdir, with an unknown template refused naming the list endpoint.
• Sandboxes: the terminal socket connects to sandboxes running on any host.
• Sandboxes: preview URLs at the sandbox preview domain now serve.
• Deployments: deploy a running sandbox to a live URL, with port and custom domain accepted and the response carrying the state and URL.
• Deployments: responses include the public URL, and a running deployment's managed hostname is re-registered automatically after an edge restart so the URL recovers without a redeploy.
• Computers: the desktop iframe and terminal socket accept computer hostnames and are proxied across hosts.
• Computers: the terminal opens in the home directory instead of failing, and accepts a starting directory.

• Sandboxes and computers: writing a file creates missing parent directories, and the workspace is prepared and owned by the sandbox user on boot.
• Sandboxes: destroying a sandbox releases its network slot lease, so repeated create and destroy cycles do not exhaust a host's slots.

• Sandboxes: create from the new Debian 12 fast-boot runtime, which becomes the default template.
• Sandboxes: choose a template at creation from the published list.
• Sandboxes: request a disk size, and keep a sandbox running with an always-on flag so it is not auto-destroyed when idle.
• Billing: sandbox runtime is metered while the sandbox is running, checked every few minutes, so long-running and always-on sandboxes are charged for elapsed time instead of only at destroy.
• Agents: builder sessions are stored server-side and survive across browsers and devices instead of living in the browser.
• Sign-in and accounts: continue with GitHub on the login and registration pages.
• Agents: a tabbed integration centre splitting the page into OAuth, AI keys and services, with OAuth provider cards and brand logos.
• Agents: voice mode - a hands-free voice conversation with an audio-reactive orb, a live transcript pane, a voice picker and an editable system prompt.
• Agents: a dictation microphone, a slash-command palette, and image paste and file drag-and-drop in the composer.
• Agents: a unified chat surface, so the builder page uses the same agent chat panel as sandboxes and computers, with a child-agent drawer.
• Agents: three more AI providers, bringing the catalog to twelve.
• Agents: a live connection indicator in the chat header.
• Sandboxes: the terminal supports two display modes, command autocomplete, a quick command menu and one-click installers for common coding agents.

• Sandboxes: set a timeout from one second up to 24 hours.
• Sandboxes: the default size is 1 vCPU, 1 GB RAM and 3 GiB disk, with requests capped at 4 vCPU, 8 GB and 10 GB.
• Computers: terminal, event and desktop streams wait for a booting computer and retry, so a connection opened during boot no longer closes immediately.
• Agents: the chat warns if no event arrives and marks a task failed with an explanation after silence.
• Agents: the builder project tabs are mine, recently viewed, shared with me and templates.

• Computers: the desktop URL points at the computer domain so the desktop opens rather than failing, and stream URLs use the same domain.
• Billing: the billing page shows the real plan name, usage budget, top-up balance and available balance instead of zero in every dollar field.
• Billing: top-up payments credit the balance, period usage resets at renewal, and a cancelled subscription returns the account to the free plan, instead of those events being dropped.
• Sign-in and accounts: a signed-in user with no workspace gets a personal workspace created automatically instead of every API call failing.
• Sign-in and accounts: clearer errors for GitHub sign-in failures, covering no public email, a provider error and a cancelled sign-in.
• Appearance: components using undefined colour tokens no longer render white-on-white buttons or dark-on-dark text.

• Sandboxes: clone a repository into the sandbox at boot by passing a repository URL with an optional branch and clone path, with the checkout status reported in the sandbox metadata.
• Sandboxes: pause a running sandbox to stop paying for CPU while keeping it alive, and resume it, with pause, resume, snapshot and fork on the sandbox page.
• Sandboxes: fork a running sandbox into a new one that inherits its template, size, environment, services, tags and metadata.
• Sandboxes: sandbox responses include boot diagnostics, so you can see whether it came from a warm pool or a cold boot and how long the boot took.
• Billing: size presets are named Agent, Builder and Service with hourly rates.
• Billing: the pricing page was rewritten per credit with Free, Starter, Pro, Scale and Enterprise plans and a monthly and annual toggle.
• Billing: computer and sandbox size rate tables with hourly and monthly prices, a storage and egress rate table including the stopped-computer rate, and inference cluster rates.
• Billing: an inline enterprise contact form and a pricing FAQ.
• Computers: a creation flow with a runtime choice, per-size prices and a review step before launch.

• Computers and sandboxes: new machines come with the common coding agent CLIs and a starter repository already installed, and the cold-boot path no longer spends minutes installing them over the network.
• Sandboxes: an idle sandbox with a timeout set is snapshotted and paused automatically, and any command, file transfer or tunnel activity resets the idle clock.
• Sandboxes: the event stream carries agent, tool-progress and computer-use events on top of lifecycle events.
• Sandboxes: the idle timeout you choose is actually sent on create, previously defaulting to disabled.
• Computers: auto-suspend now defaults to five minutes for sandbox-type workloads and fifteen minutes for interactive desktops when you do not set one.
• Files: the default path is the home directory, and the standard workspace, home and temporary directories are permitted.
• Computers: opening a computer's hostname in a browser redirects to the desktop client instead of returning a JSON status blob.
• Billing: the billing overview classifies sandbox, database and custom-domain runtime as compute and inference tokens as AI, instead of lumping them under other.

• Computers: the in-machine agent token is written to the path the agent actually reads, fixing the 401 that every sandbox and computer auth request returned.
• Computers: the root filesystem clone uses copy-on-write instead of a full sparse copy.
• Sandboxes: a repository import that is not a valid HTTPS URL is refused up front instead of failing the clone silently.
• Sandboxes: requests have a timeout and retry once on 401.

• Billing: see your dollar balance and remaining budget - plan, monthly usage budget, top-up balance, spend this period, remaining, period start and auto-reload state - GET /api/v1/billing/balance.
• Billing: start a checkout session for a plan subscription or a one-time top-up and get a URL back, surfaced as top-up buttons on the billing page.
• Billing: read paginated usage history of up to 200 rows - GET /api/v1/billing/transactions.
• Billing: computers and sandboxes are metered per minute by vCPU-hour, GiB-hour of memory and GiB-hour of disk, and storage is metered daily with the first 5 GiB per computer free.
• Billing: top-ups carry a bonus credited by the payment webhook.
• Billing: turn on auto-reload so your card is charged and your balance topped up below a threshold.
• Billing: a usage breakdown with a spend-versus-included bar and a category table showing amount, units and share.
• Billing: a plan card with plan name, status, included budget, period start, next renewal and cancellation date.
• Billing: a usage trend chart with 7, 14, 30 and 90 day windows, a filterable usage table, inline invoices, and payment-issue and free-plan banners.
• Billing: projected monthly spend from your daily average, with a warning when the projection exceeds your budget.
• Billing: usage past the plan budget is posted to your next invoice as a usage overage line at period end.
• Billing: balance alert emails at three levels - budget exhausted, almost depleted and credits running low.
• Agents: bring your own provider API keys for seven providers, returned only as a masked preview.
• Sandboxes: read back the environment variables a sandbox was created with.
• Sandboxes: update an existing sandbox with PATCH /api/v1/sandboxes/{id}.
• Sandboxes: dedicated file routes for read, write and list.
• Agents: an agent tab on the sandbox page with the chat panel bound to that sandbox session, and a recent-chats list in the builder sidebar.
• Cron: a job detail page with execution history, expandable run output, a run-now button and editable schedule, size and timeout options.
• Deployments: a deployment list with status filters and per-status counts, and publishing from a sandbox as a deployment source.
• Deployments: a deployment detail page with overview, build log, builds, environment variables and settings tabs, rollback to the last build, and custom domain connect and remove.
• Functions: a detail page with metrics, a copyable curl example and an editable name.
• Storage: the bucket page rebuilt with files, info, access, settings and danger tabs, including bucket credentials and CORS configuration.

• Billing: a request that would exceed your budget is rejected before any work starts, with 402 naming whether it is the free tier or the budget cap, on sandbox and computer create and start.
• Billing: when a workspace runs out of budget its running computers are paused automatically instead of continuing to accrue usage.
• Sandboxes: the preview pane shows a placeholder with a port selector while the app boots, and boot detection polls faster at first.
• Docs: snapshots renamed to checkpoints across the reference and guides, new errors, rate limits, architecture and recipes pages, and a published specification with 182 paths.
• Landing page: rewritten positioning copy, the badge changed from launching soon to live now, and the call to action is now to build your workspace.
• Refund policy: rewritten for subscriptions, top-ups, metered usage and billing errors.

• Billing: the spend cap's tenant lookup was corrected so the cap is enforced reliably instead of passing requests through.
• Billing: usage records and categories read from corrected metrics, fixing a 400 on the billing page.
• Sandboxes: a request that reaches a listener node without the sandbox cached falls through to a lookup instead of 404ing, so preview URLs resolve from any node.

• Settings: white-label branding - app name, light and dark logos, favicon, three brand colours, email sender name and address, support email and URL, and a "powered by" toggle - gated to the higher plans with an upgrade prompt below that.
• Settings: branding applies across the console, including the header logo, favicon, page title and brand colours, and the workspace response carries the branding object so a branded app can paint before first render.
• Settings: transactional email is sent from your configured sender identity, and preview URLs use your custom preview domain.

• Agents: eight tools offered to the model in standard function-calling format - create a sandbox, exec, write and read files, expose a port, install dependencies, take a screenshot and deploy.
• Agents: the deploy tool promotes a running sandbox into a persistent deployment and can attach a custom domain in the same call.
• Agents: send a code-execution tool and the model runs code in a sandbox for up to ten turns, with the sandbox created on the first call and destroyed when the response finishes.
• Agents: the model listing reports which tools each model supports.
• Sandboxes: give a sandbox a name and look it up by name.

• Integrations: connect thirty third-party services with credentials encrypted at rest, mapped to provider environment variables and injected into the project's machines at boot.
• Integrations: a marketplace with eight providers, filterable and searchable, where connecting a provider shows the environment variables it injects.
• Integrations: an integrations tab on computers, sandboxes and deployments with an add drawer, connected providers, injected variables and removal.
• Sign-in and accounts: a built-in project auth provider that creates user and session tables in the project database and issues tokens, with configurable signup, token expiry and email confirmation.
• Sign-in and accounts: the project machine receives the auth secret and settings so application code can verify tokens.
• Agents: register outgoing webhooks subscribed to twenty-five event types across machines, databases, deployments, previews, health checks, cron and billing, with HMAC signatures and exponential-backoff retries.
• Agents: send a test event and inspect or replay individual webhook deliveries.
• Cron: schedule an agent task instead of a shell command, using a natural-language description optionally bound to a specific computer.
• Agents: an app builder dashboard with a prompt box, project tabs - mine, shared, templates - project search and template cards.
• Agents: a builder project view with a resizable chat panel, prompt chips, and preview, cloud, code and files tabs, plus publish.
• Agents: a cloud sidebar in the builder with eleven sections including overview, AI, emails, database, users, storage, secrets, functions, SQL editor, logs and usage.
• Agents: an orchestrator panel showing multi-agent work in chat, with per-agent chips, wave progress and the synthesis.
• Agents: an agent progress view with a planning step and a running list of tool calls and results.
• Appearance: a light, dark or auto theme switcher in the account menu.

• Sandboxes and computers: an always-on flag keeps a machine running with auto-pause and idle detection disabled, and auto-pause now defaults to off so machines no longer stop five minutes after creation unless configured.
• Emails: sandbox provisioning sends its own ready and failed emails, separate from computer lifecycle emails.
• Agents: the builder runs its AI requests through the platform API instead of a direct provider call.
• Agents: tool call cards were redesigned into one minimal style with a status dot, duration and click-to-expand output.

• Emails: provisioning emails no longer fail with a missing-field error.

• Databases: create and run a managed PostgreSQL database sized on CPU, memory and storage, with start, stop, restart and delete.
• Databases: read the generated connection credentials.
• Databases: a stopped database keeps its persistent volume, so restarting brings the same data back, and it is billed per hour in minute ticks.
• Databases: a management UI with a list showing status, name, engine, size and region, a create form, and a detail page with lifecycle actions and credential reveal.
• Storage: S3-compatible object storage buckets, namespaced per tenant, with quota enforcement and usage counters.
• Storage: put, get, list and delete objects including nested keys, and generate S3-style presigned URLs signed with SigV4.
• Storage: bucket management with a file browser, drag-and-drop upload with progress, per-object download and delete, and presigned URL generation.
• Databases: a table browser with column types, sort, filter, paging, inline cell edit, row insert and bulk delete.
• Databases: a SQL editor with a keyboard shortcut to run, tabular results and the last ten queries kept as history.
• Logs: stream a computer, sandbox or database's logs live, with a real-time viewer, severity colouring, pause and resume, reconnect with backoff and a connection indicator.
• Cron: schedule a recurring task on a five-field cron expression that boots an ephemeral sandbox, runs a command, captures output and cleans up, with a job list, create form and detail page with execution history.
• Deployments: every pull request gets its own preview environment, created on open, rebuilt on push and destroyed on merge or close, with a previews tab listing them.
• Health checks: attach a TCP, HTTP or HTTPS probe to a computer, sandbox or database with configurable interval, timeout, port, path and thresholds, and see the state transition between healthy, degraded and unhealthy.
• Databases: pass a database flag when creating a sandbox or deployment and a managed PostgreSQL is auto-provisioned and linked, with connection variables injected into the machine and the database destroyed with its parent.
• Sandboxes: an attach-database toggle with a size selector at creation, and a database tab showing status, engine, size and credentials.
• Files: a full filesystem API inside sandboxes and databases - list, read, write, upload, download, stat, mkdir, rename, copy, delete and chmod - with uploads up to 10 MB.
• Sandboxes: the file editor is a real code editor with syntax highlighting for the common languages, line numbers, bracket matching, folding, autocomplete and search.
• Functions: create serverless edge functions with node, python, deno or bun runtimes, an entrypoint, environment variables, memory and a timeout, each with a public invoke URL.
• Functions: invoke a function with a JSON payload delivered as an environment value and read the captured output.
• Functions: a management UI with a list, per-runtime starter templates, and a detail page to edit code, deploy, test and view results.
• Sandboxes: a cloud tab with service cards for database, storage, intelligence, secrets, logs and usage.
• Billing: a usage dashboard with credit balance, used this period, daily rate, projection and plan progress, a stacked breakdown by category, a top-consumers ranking and a paginated transaction table.
• Agents: computer-use tool calls render as cards naming the action, with inline screenshots that expand on click.
• Agents: an activity badge over the desktop stream showing what the agent is doing.

• Sandboxes: sandbox URLs now open in the shared computer workspace.
• Navigation: databases, storage and cron jobs added as a data and automation group in the platform header.
• Databases: the deployment create wizard is four steps with an optional managed PostgreSQL.
• Computers: screenshot, click and type calls are routed through the node that owns the machine, so they work for remotely hosted machines.
• Computers: the computer domain serves HTTP/1.1 so socket upgrades work and terminal connections stay open.
• Settings: the actions in the computer settings tab are all wired, and a force restart clears the stale session.

• Emails: computer and sandbox provisioning emails no longer raise a missing-field error.

• Sign-in and accounts: a security page with password change, a send-link action to verify your email, and a revoke action that ends the current browser session.
• Sign-in and accounts: enable or disable email two-factor authentication, confirming with a six-digit code and showing the enabled state.
• Sign-in and accounts: when email two-factor is on, sign-in shows a verification step asking for the emailed code and its expiry.
• Sign-in and accounts: confirm your email address from the link in the verification email, and resend it while signed in.
• Sign-in and accounts: sign-in tells you at the first step whether a second step is needed, then finishes with the emailed code.
• Sign-in and accounts: redesigned password recovery with a reset form, a confirmation and a choose-a-new-password page.
• CLI: an install page walking through Homebrew install, authorization and verification, with one-click copy on each command.
• Computers: a home tab with the machine's info and live system statistics - uptime, memory and disk bars, CPU count and detected services.
• Computers: channels, schedules, services and tutorial tabs, with schedules creatable from templates on a cron expression and runnable on demand.
• Agents: give a computer an inbound email address, read its recent messages, and choose how mail is handled.
• Agents: list the communication channels available and enable or disable one, and read and update notification preferences including quiet hours.
• Billing: read per-GPU credit rates directly in settings, surfaced in the create wizards.
• Accounts: a welcome email on signup or first Google sign-in, and transactional emails moved to a branded layout.
• Deployments: emails when a computer finishes or fails to provision, and when a deployment succeeds or fails, each linking to the resource or the build logs.

• Computers: the terminal supports multiple tabs and remembers open terminals across reloads.
• Computers: the tab bar can be scrolled with arrow buttons when tabs overflow.
• Sign-in and accounts: email codes come from a cryptographic source, expire after ten minutes and stop after five wrong tries.
• Sign-in and accounts: replies to platform emails now land instead of bouncing, with a reply-to address and a plain-text version.
• Billing: GPU prices come from the compute pricing endpoint, so they show in the create wizards.

• Sandboxes: the concurrent limit comes from the plan's concurrent cap rather than its total cap, no capacity returns a retryable 503, and creates are throttled per tenant by plan.
• Computers: start, stop and restart call the user API instead of the admin endpoint, so they work for normal accounts.
• Computers: opening a computer by its slug resolves, and provisioning registers it in the proxy cache so it is reachable as soon as it is created.
• Sandboxes: proxy routing resolves the host's network address rather than its hostname, fixing failed connections to sandboxes on other hosts.
• Sign-in and accounts: failed Google sign-in returns you to the login page with an error code instead of a raw JSON error or a 502.
• Sign-in and accounts: the password reset email link opens the working reset page.
• Sign-in and accounts: the OAuth session is mirrored into a server session cookie at the callback, so the signed-in state is available to server-rendered requests.

• CLI: sign in from the terminal with a browser approval flow instead of pasting a key - miosa auth login opens the authorization page with a one-time code and returns a fresh key once approved.
• CLI: approve or deny a pending terminal login from the console, either from the link the CLI opens or by pasting the code.
• Sign-in and accounts: see and manage terminal access in one place, listing CLI devices and API tokens with fingerprint, scopes and last-used dates, with a per-token revoke.
• Billing: two higher tiers published, Platform at $499 a month with 100 computers, 10,000 sandboxes, 50,000 credits and white-label branding, and Enterprise.
• Billing: plan limits now carry sandbox, deployment, custom-domain and API-key caps, per-plan API rate limits, allowed machine sizes and a preview-domain flag.
• Billing: read your plan, every resource limit and live usage plus the next upgrade tier - GET /api/v1/tenant/plan.
• Billing: a plan and usage tab showing your plan and price, an upgrade link, and usage against limits with progress bars.
• Sandboxes: read per-size compute rates in credits per hour and GPU rates, and that one credit is one cent.
• Sandboxes: the create wizard lets you enable PostgreSQL, Redis or MySQL services, pick a region and set a maximum runtime from five minutes to 24 hours.
• Sandboxes: the list shows each sandbox's preview URL with copy and open, and inline service badges.
• Sandboxes: an interactive terminal over a socket, with a reconnect window that keeps the in-machine terminal alive across disconnects.
• Computers: ports, environment variables, a file manager, snapshots, a create wizard with template, size, GPU and region, and a provisioning screen showing named steps with a live percentage.
• Docs: a changelog page, a CLI page, and API reference pages for filesystem, streaming exec, snapshots, services, custom domains, network policy and events.
• Docs: sandbox SDK documentation for TypeScript, Python and Go, plus templates and status pages, and a rebuilt landing page with tabbed code examples.

• Computers: rename a computer and change its resolution, auto-stop setting and selected apps after creation.
• Deployments: edit the name, branch, build command, run command and auto-deploy setting without deleting and recreating.
• Sandboxes: every sandbox is registered with the proxy on boot and gets a public preview URL immediately.
• Sandboxes: maximum lifetime raised from one hour to 24 hours.
• Settings: a branding tab to serve sandbox previews from your own domain, with a live DNS status badge, a verify action and a setup guide.
• Authentication: the page you were heading to is preserved through an OAuth sign-in instead of dropping you on the sandboxes page.
• Docs: fixed broken internal links, replaced a flat feature table with descriptive cards, and added mobile breakpoints.

• Sandboxes: creating past your plan cap fails cleanly naming the plan and the cap.
• Settings: the branding tab now sends the preview domain under the key the backend expects, so saving a domain takes effect.
• Onboarding: the open-computers welcome modal only appears on its own page instead of interrupting every page.
• Billing: token charges for chat completions were computed per thousand tokens instead of per million, overcharging by a factor of a thousand.