# tensorlake's fastest claim rests on one SQLite run

> A compute platform whose sandbox product is a stateful Firecracker microVM, installed from PyPI with a separate standalone CLI binary. The benchmark behind the speed claim is one configuration with no sample size, a timed-out sandbox create no longer deletes the machine, tightening a pool's network policy does not reach sandboxes that were already claimed, and three crates carrying the filesystem engine are excluded from a default build.

**tensorlakeai/tensorlake** — Tensorlake is a serverless runtime for sandboxes and deploying background agentic applications

- Repository: https://github.com/tensorlakeai/tensorlake
- Website: https://tensorlake.ai
- Stars: 1,017 · Forks: 147
- Language: Python
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/tensorlakeai-tensorlake

## The headline is filesystem speed and the measurement is a whole SQLite run

The first capability bullet is titled fastest filesystem I/O, and the evidence under it is a SQLite benchmark.

The configuration is stated: 2 vCPUs and 4 GB of RAM. The five numbers are 2.45 seconds for Tensorlake, 3.00 for Vercel, 3.92 for E2B, 4.66 for Modal and 5.51 for Daytona. The ratios given are 1.2, 1.6, 1.9 and 2.2 times.

The arithmetic checks out, since 5.51 divided by 2.45 is about 2.25. The interesting number is the first ratio. The nearest competitor is 18 percent slower, not 20 percent faster in the sense the multipliers suggest, and a run that opens a database, applies a schema and executes queries is measuring a great deal that is not filesystem throughput.

What is missing is the part that would make the figure mean anything: no repetition count, no spread, no variance, no statement of which SQLite version or dataset, and one machine size. The remaining capabilities are stated without numbers at all, including creation in under a second through a scheduler called Lattice, resume in under a second, a pause of a few seconds during live migration, and support for up to 5 million sandboxes in a single project.

## A create that times out no longer deletes the sandbox

This is the most consequential line on the page, and it is a behaviour change rather than a new feature.

The convenience methods send the create with `wait=False`, so the server acknowledges the sandbox immediately and the client polls until it is running. If that wait runs out, the sandbox is not deleted. A pending exception carrying the sandbox id is raised, and the sandbox keeps its place in the queue until capacity arrives.

The documented escape hatches are three. Collect it later with a connect call on the id. Request sandboxes ahead of capacity, which returns a pending handle whose readiness can be polled. And pass a cancellation flag to get the previous behaviour, or a pending bound to let the server give up after a limit.

So a timeout stopped meaning cancellation. Any code written against the older behaviour, where a failed create cleaned up after itself, now leaks a queued sandbox that will eventually start and run until something stops it.

The CLI says the same thing in a comment next to its own blocking command, that a timeout leaves the sandbox queued and never cancels it, and pairs it with a queue flag and an explicit wait command carrying a thirty minute timeout.

## A pool network change misses the sandboxes already claimed

Pool network policy has three ways to be set and one important limit, and the limit is stated in the same paragraph.

You can set the policy when you create the pool, replace it later with a pool update, or remove it entirely by passing a clear sentinel in Python or null in the TypeScript SDK.

The limit is what happens to running sandboxes. When the policy changes, the service recycles the pool's unclaimed warm containers onto the new configuration. Containers that a sandbox has already claimed keep the policy they booted with.

So tightening a pool from internet access allowed to blocked leaves every already-running sandbox with its original access until it is recycled. For a product whose selling point is running agent-generated code in isolation, that ordering is the detail to plan around: apply the restrictive policy at pool creation, treat a later policy change as applying to future claims only, and assume a running sandbox keeps whatever it started with.

The pool API makes the same ordering visible elsewhere. Claiming attaches file systems before the sandbox is reported as running, and pool root disks default to the registered image's size with an explicit size argument to grow a filesystem-only image, never to shrink below the image.

## You cannot bring your own Docker image

The custom environment story is one sentence long, and it rules out the obvious approach.

Omit the image flag to get the platform's default managed environment. To get something else, pass the name of a registered Sandbox Image. Arbitrary Docker image references are not supported.

That is a real constraint for agents. A model that needs a specific interpreter, a specific library version or a system package cannot construct one at runtime from a public base image; the environment has to be registered on the platform first. The registered image names in the examples follow a namespaced pattern, one of which is a minimal Ubuntu variant.

Network control is a first class part of the same API rather than an image concern. The CLI has a flag that blocks all outbound internet access on a running sandbox, and the Python pool API takes a network configuration object with the access switch. So isolation is expressed through the platform's own knobs, which is consistent with the constraint above: the platform controls what is in the machine and what it can reach.

Both paths into a sandbox are also documented for both transports. The CLI offers an interactive terminal subcommand and a command execution subcommand that takes a shell and a command string, and the Python SDK offers a run method taking a program and an argument list, plus file read and write helpers and a long running process starter.

## Three crates holding the filesystem engine are excluded from a default build

The workspace manifest has five members and three exclusions, and the comments around the exclusions explain more than the member list does.

The included members are a cloud SDK, a CLI, a function agent core, and two bindings, one for Node and one for Python. The excluded ones are named with a common prefix and described as private crates that are resolution-only placeholders, with the stated purpose of keeping default workspace builds public-only while official full builds inject their sources before enabling client features.

One of the three is the filesystem client engine, and its comment says it owns all filesystem behaviour, that the public CLI calls it through a thin host adapter, and that the public SDK exposes no native filesystem module in default builds.

Another is a packfile codec, described as backing a git clone subcommand, with a note that the real source is no longer vendored in the repository and that official builds swap it in ephemerally, pointing at a vendored-from file, a build recipe in the justfile and a CI action.

The readme describes a Cloud Volumes product, a client that manages durable versioned file trees without mounting them, hashing files locally and uploading missing 64 MiB parts directly to a checksum-bound object store URL. That is the feature the excluded filesystem crate implements, and the workspace pins a content-defined chunking library at version 3, which is the technique such a part upload needs.

So the documentation covers a subsystem you cannot read or build from this checkout. The workspace licence is Apache 2.0 and the edition is 2024, but three of the eight crates are placeholders.

## Three websocket libraries in one SDK and two ways to hold one credential

The Python SDK has six runtime dependencies, and a third of them are ways of speaking to a socket.

The install is one line, from the package index:

```bash
pip install tensorlake
```

There is an HTTP client with HTTP 2 support, a synchronous websocket client, an asynchronous websocket library, a validation library, a gRPC runtime and protobuf. The manifest caps them: HTTP below 1.0, the sync websocket below 2.0, the async websocket between 14 and 18, the validation library below 3.0, gRPC below 2.0.0 and protobuf below 7.0.0.

Two of those are websockets with different concurrency models, and the Rust side adds a third in its tungstenite dependency pinned at 0.28 with webpki roots for TLS. A sandbox client that also opens an interactive terminal and streams process output has reason to need more than one, but it means three implementations of the same protocol in a stack that is otherwise six packages wide.

The credential story has the same doubling. Setup documents both an environment variable holding the API key and a login command, and the repository's example environment file carries both an API URL and an API key. So there are three routes to the same credential: the variable, the login, and whatever the login writes.

The CLI itself is not on either index. The page states it is distributed as a standalone binary, not through PyPI or npm, and installed with a shell script fetched over the network.

## A makefile, a justfile, Poetry, maturin and cargo in one repository

The build tooling runs on four systems at once, and the Python side is configured by three.

There is a makefile and a justfile. The Python environment is Poetry, with a lock file and a configuration file. The extension is built by maturin against a Rust manifest that points at a specific crate, binds through pyo3, and names the resulting extension module. That extension is what gives the package its Rust code.

The makefile's install targets wrap almost every step in a helper script that injects the function agent core, which is also the mechanism the Cargo comments describe for the private crates. Its release path removes a build directory, installs with the dev group, builds the extension, builds a wheel, and then copies helper scripts from a top level directory into the environment's bin. Its global install target builds a release wheel and installs it with pip into the user site, with a flag that overrides the platform's protection against a system-wide install.

There are three console scripts declared: one for deploying, one for running a function, and one for the function executor entry point. Linting is configured three ways for Python, with a pylintrc file, black targeting Python 3.10, and isort on the black profile, and both of the latter skip the vendored and Rust directories. Rust has its own lint configuration file.

The file naming at the root is inconsistent while you are looking at it, with lowercase contribution and conduct files beside uppercase ones for everything else.

## Three releases in three days and the manifests one version ahead

The release history is three CLI tags on three consecutive days: 0.5.136 on the 28th of September, 0.5.137 on the 29th and 0.5.138 on the 30th.

The tags are all prefixed with the component they belong to, so the CLI has its own release line separate from the package and from the Rust workspace.

Both manifests are one version ahead of the newest tag. The Python project version is 0.5.139 and the Rust workspace version is 0.5.139, with the newest published tag at 0.5.138. The default branch was pushed on 2026-10-02, so the number in the manifests describes work that has not been tagged.

Three-part patch versions released daily is a very fast cadence, and the reason is visible in the structure: the CLI, the Python SDK and the Rust workspace share a version number, so a CLI change moves all three, which means publishing often is how the three stay aligned rather than drifting.

The one place the project documents why it pins what it pins is the gRPC version. The dev group comment says gRPC is forward compatible within a major version, that the minimum must match a constant in the committed proto stubs, and that regenerating the stubs has to stay compatible with what users install at runtime. The proto files and a generation step are committed rather than built on install for that reason.

## Conclusion

tensorlake is aimed at agents that need a real machine rather than a container with a timer, and the parts worth reading closely are the queue and the isolation semantics rather than the throughput numbers. The create path is asynchronous by design: the server acknowledges immediately and the client polls, and a request that times out leaves the sandbox in the queue with its position intact so it can be collected later. Snapshots, cloning, suspend and resume, and migration between machines during updates are all described as preserving memory and filesystem state, which is what an agent that resumes work needs.

Two behaviours will bite you if you do not know them. First, a timed-out create used to delete the sandbox; it no longer does, and the old delete-then-raise behaviour is now behind an explicit flag. Existing code that relied on a timeout meaning cancellation has to opt back in. Second, changing a pool's network policy applies to unclaimed warm containers only, and containers already claimed keep the policy they booted with, so tightening a no-internet rule does not affect sandboxes that are already running.

On the claims themselves, the speed comparison is one SQLite configuration at 2 vCPUs and 4 GB with five vendors and no stated sample size, so treat it as a direction rather than a number. And the filesystem engine that backs Cloud Volumes is not in this repository: three crates are excluded from a default workspace build and their sources are injected only for official builds, so that part of the documentation describes code you cannot read or build from the checkout.

## FAQ

### What is tensorlake?

A compute infrastructure platform for building agentic applications. The sandbox API creates stateful Firecracker microVMs to run agents or to isolate tools and generated code, and a serverless function runtime adds long running orchestration with fan-out on top.

### Is tensorlake open source?

The repository is public and the workspace manifest declares Apache-2.0 with edition 2024 and five published crates. Three further crates, holding the mount core, the packfile codec and the filesystem client engine, are excluded from a default build and have their sources injected only for official builds.

### How do I install tensorlake and its CLI?

The Python SDK comes from PyPI with pip install tensorlake. The tl CLI is a standalone binary that is not distributed through PyPI or npm, and is installed with curl -fsSL https://tensorlake.ai/install piped into sh. You then set TENSORLAKE_API_KEY or run tl login.

### What happens when a tensorlake sandbox create times out?

The sandbox is not deleted. A pending exception is raised carrying the sandbox id and the sandbox keeps its place in the queue until capacity arrives. The previous delete-then-raise behaviour is available behind an explicit cancellation flag, and a pending bound can be set so the server gives up.

### Can I use my own Docker image as a tensorlake sandbox?

No. Arbitrary Docker image references are not supported. You either omit the image flag to get the default managed environment, or pass the name of a registered Sandbox Image.

### Does a tensorlake sandbox pool network change affect running sandboxes?

Not the ones already running. On a policy change the service recycles the pool's unclaimed warm containers onto the new policy, while containers already claimed by sandboxes keep the policy they booted with.

## Sources

- [License: Apache-2.0](https://github.com/tensorlakeai/tensorlake/blob/main/LICENSE)
- [Project website](https://tensorlake.ai)
- [README](https://github.com/tensorlakeai/tensorlake/blob/main/README.md)
- [Releases](https://github.com/tensorlakeai/tensorlake/releases)
- [tensorlakeai/tensorlake on GitHub](https://github.com/tensorlakeai/tensorlake)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tensorlakeai-tensorlake