Introducing Verklet Beta: Browser-First Runtimes for Interactive Software

Predefined tools are useful. Static demos are useful too.

But some work needs room to unfold.

An agent may need to write a script, run it, inspect stdout, fix an error, and try again. A customer may need to try a real package example before booking a sales call. A docs reader may need to change code and see what happens. A support engineer may need to reproduce a small bug without cloning a repo. A data workflow may need to transform a file, validate the output, and produce an artifact.

Those are runtime problems.

Verklet gives products a runtime that starts in the browser. JavaScript and supported Python workloads can run close to the user with a filesystem, package installs, process execution, stdout and stderr, persistent snapshots, and isolated previews. When the workload needs Linux, native packages, longer execution, higher ceilings, or server-side persistence, the same workspace can promote to a managed server runtime.

Browser first. Server on demand.

Verklet is still in beta. Compatibility is growing, and some workloads should start on the server. But we think the model is important: give interactive software the ability to do real work immediately, without creating server infrastructure for every small task.

Try the SDK for free.

When a predefined tool is too narrow

Tool calls are the right interface for many agent actions. They are structured, auditable, and easy to put behind product policy: search this index, create this ticket, update this record, fetch this customer, call this API.

But some tasks do not fit neatly into one predefined function. The agent may need to create a file, write a small program, install a package, inspect messy output, transform data, retry after an error, or produce an artifact the host product did not anticipate.

That is where a runtime helps.

Verklet does not replace tool calls. It gives agents another kind of tool: a controlled workspace where they can run JavaScript or Python, use a filesystem, inspect stdout and stderr, and revise their work. The host product still owns the boundary. Verklet just makes the inside of that boundary more capable.

Start in the browser

The browser is already where the user is. For many interactive workloads, it is also the cheapest capable host.

Browser execution is a strong default for early steps:

• Running JavaScript, TypeScript, and supported Node.js-style commands.
• Running supported Python through Pyodide.
• Creating files, generated assets, Markdown, JSON, CSV, and SVG.
• Installing supported packages for examples and demos.
• Calling public APIs from small scripts.
• Rendering isolated previews inside the host product.
• Persisting project snapshots across reloads.

That does not make the browser a complete Linux replacement. It makes it the right first host for work that fits in a tab.

Promote when the workload needs more

Some tasks need server capabilities immediately. Others start simply and only become server-shaped later.

The server path is for workloads like:

• Native Python wheels.
• uv workflows.
• Native Linux tools.
• Long-running processes.
• Larger memory and CPU ceilings.
• Workspaces that should persist beyond browser storage.

With backend: 'auto', Verklet can start in the browser, snapshot the workspace when the task asks for more, create a managed server session, mount the same files there, and continue through the same SDK surface.

The product does not need one integration for browser execution and another for server execution. It keeps calling runtime.fs, runtime.spawn(), and the same event streams.

One runtime surface

An integration can start small:

import { Runtime } from '@verklet/sdk';

const runtime = await Runtime.boot({
  projectId: 'prj_your_project_id',
  backend: 'auto',
  persistenceKey: 'interactive-workspace',
});

await runtime.fs.writeFile(
  '/workdir/report.py',
  [
    'import json',
    'data = [{"name": "Oslo", "value": 42}]',
    'print(json.dumps(data, indent=2))',
  ].join('\n'),
);

const process = await runtime.spawn('python', ['report.py'], {
  cwd: '/workdir',
});

That same shape works when the host is an AI agent, an embedded docs example, a customer demo, a support reproduction tool, or an internal workflow surface. Mount files. Run code. Inspect output. Show the result. Promote only when the workload needs a server.

For agents

Agents are more useful when they can do the work they are reasoning about.

A predefined tool can hide a lot of useful behavior behind a neat schema. That is often good. But an agent also benefits from a scratch space where it can create intermediate files, run small checks, use JavaScript or Python to transform data, inspect failures, and produce evidence before answering.

The agent loop can stay in your AI framework. Verklet gives that loop a runtime to act inside.

For users

The same runtime model is useful even when there is no AI involved.

A customer demo can be live instead of prerecorded. A docs example can be editable instead of static. A tutorial can show a real terminal and a real preview. A support flow can reproduce a bug from a pasted fixture. An internal tool can run a small transform without provisioning a workspace for every visitor.

These experiences should not need a container before the user has done anything that requires one.

What beta means

Verklet is not a claim that every workload belongs in the browser.

Browser-first means the browser is the default host when it is capable. Server on demand means the product still has a path to real server capabilities when the browser is the wrong place.

During beta, we are still expanding compatibility, tightening the server promotion path, and learning where the runtime boundary should be most visible to developers and users. Some projects will run well in the browser. Some will promote. Some should start on the server from the beginning.

The important part is that the host product does not have to make every small interaction pay the cost of a server session upfront.

The short version

When a predefined tool is too narrow, give the agent a runtime. When a static demo is too limited, give the user one too.

Verklet starts JavaScript and Python workloads in the browser, then promotes to a managed server runtime when the work needs more.

Try the SDK for free.