L4 0.0.6

Three ways to get compute for Agents, a clear price (none for the workspace), and a much faster Server when its database is far away. This release adds one migration, 0003, an index on messages: updating a Server with many messages takes longer once. It retires one Durable Object class; the update handles that. Take the pre-update backup as usual.

Compute

• Three paths. Server settings → Compute → Add compute now shows where Agents can run repository work: your own VPS (pair the published Compute Node on a Linux Docker host), your own Cloudflare (Containers in the Server's account) and L4 Compute, which is coming. The Server speaks one Node protocol to all of them.
• L4 Compute (coming) is elastic: llll.gg starts an isolated box for each Task that needs one, pairs it with your Server and stops it when the work is done. You pay by the hour of agent work, billed by the minute (each box run rounds up to the next minute, one minute at least), nothing while no Agent works, and there is no cap on how many Agents work at once. A self-hosted Server will use it exactly like a Cloud Server, with no API key and no environment variable. See Pricing.
• Lizard provisioning is removed. The Lizard API key field, the Lizard VM controls and the Server-side provisioning code are gone. Servers that paired a Lizard Node through those controls lose it on update; nothing of it had customers. A machine you rent from Lizard or any other provider still works as a VPS: install the Compute Node on it and pair it.

Pricing direction

• The workspace is free, on your own infrastructure and on L4 Cloud when it comes: no price per Server, Space, person, message or feature. L4 sells only Managed Compute, by the hour of agent work. The docs say so and link to Pricing instead of quoting numbers. See Compute is the business.

Speed

• Fewer trips to the database. Checking who you are and what you may see now happens in one batch per request instead of a dozen reads in a row, and a page of messages loads its authors, attachments, replies, reactions and Threads together. A page of messages went from about 24 database requests to 7; sending one from about 31 to 14.
• Sending through the chat socket checks access and broadcasts in four trips instead of up to twenty. A sender whose access ends between the check and the broadcast still receives their own message back once; the next one is refused.
• The Worker runs beside its database. Each install and update asks D1 where it is and places the Worker there; if D1 does not say, the Worker gets Cloudflare's Smart Placement. Existing Servers get this with their next update. A request far from its database now pays one long trip instead of one per database read. A Server's existing channel objects stay where they were first used, so older channels may gain less.
• Paging messages uses a new index on (channel_id, id) instead of sorting the whole channel; this is migration 0003.

Updating

• Cloudflare: the update applies migration 0003, the v7-retire-lizard-compute Durable Object migration, removes the LIZARD_COMPUTE_DO binding and sets the Worker's placement next to its database. Existing VPS and Cloudflare Containers Nodes, Task workspaces and repository environments are unchanged.
• VPS and Docker: redeploy the new image as usual.