Limonata Linux provider 0.8.0 — shared resident AI model
https://limonata.xyz/ai

Start connects your saved provider identity to a shared Qwen3-32B model. The
coordinator assigns one pinned, contiguous stage to this GPU. The client
fetches only that stage, verifies it, loads it inside the existing process
sandbox and performs actual GPU inference before announcing readiness.
Several compatible providers execute successive stages of the same answer.
Weights stay resident across requests and ordinary network reconnections.

REQUIREMENTS

- Linux x86-64, Ubuntu 22.04+ (glibc 2.35+), libstdc++6 and libgomp1.
- NVIDIA Ampere or newer with a CUDA 12.8-compatible driver. No CUDA toolkit
  installation is needed. Initial device detection needs at least 4 GiB VRAM;
  a shared assignment additionally needs at least 18623 MiB free for stage 1
  or 8379 MiB free for stage 2, under the current conservative admission plan.
  The real GPU load/probe must still pass. Memory is reserved for stage weights,
  KV cache and runtime. Reported memory alone does not prove a successful fit.
- Landlock enabled by the host/container (kernel 5.13+). There is no unprotected
  fallback, driver installer or change to host security settings.
- Disk space for the assigned stage plus a 2 GiB reserve and installed runtime.
  Stage 1 (layers 1-48) is 14.99 GB; stage 2 (layers 49-64) is 5.86 GB. Shared
  embedding/output tensors are duplicated, so these are not equal-size pieces.
- Stable outbound HTTPS/WSS and a public LIMO payout address. No wallet private
  key, inbound public GPU port or cloud API credential is required.

The current two-stage split supports particular GPU sizes; it cannot divide
itself into arbitrary smaller fragments to fit every newly connected device.
An incompatible GPU waits for a compatible assignment. The client does not
pretend that waiting or downloading is inference, nor substitute a smaller
model for the shared 32B model. Other contribution modes remain explicit.

INSTALL AND START

Runpod is one option; a compatible Linux computer uses the same client. On a
root Pod, use /opt/limonata and /var/lib/limonata-provider. Some /workspace
volumes cannot enforce ownership, permissions or hard links; do not use those
volumes for extraction or private identity storage. No systemd, privileged Pod
or Docker-in-Docker is required.

(
  set -eu
  install -d -m 755 /opt/limonata
  cd /opt/limonata
  curl -fL https://limonata.xyz/ai/downloads/linux -o limonata-provider-linux-x64-0.8.0.tar.gz
  curl -fL https://limonata.xyz/ai/downloads/linux-checksums -o SHA256SUMS-linux.txt
  sha256sum --check --ignore-missing SHA256SUMS-linux.txt
  tar --no-same-owner -xzf limonata-provider-linux-x64-0.8.0.tar.gz
  ./limonata-provider-linux/limonata-provider doctor --data-dir /var/lib/limonata-provider
)

Do not continue after a checksum or diagnostic failure. Checksums detect
corruption; this preview has no independent release-signing key. A regular
user may extract into a local directory they own and omit --data-dir.

  /opt/limonata/limonata-provider-linux/limonata-provider start --data-dir /var/lib/limonata-provider --payout 0xYOUR_PUBLIC_LIMO_ADDRESS

First start saves a private random provider credential and the public payout.
Subsequent starts reuse them. Registration itself earns nothing and does not
make a model ready. Shared mode checks the runtime and detects the GPU before
requesting an assignment; it does not download a small whole model as a probe.
The assigned stage performs the real startup probe. A rejected GPU placement,
wrong artifact, incomplete download or failed probe cannot qualify as ready.

A cache hit still verifies exact size and SHA256. Interrupted transfers retain
a private .part file and resume with an exact byte range and immutable artifact
tag on restart. Incomplete bytes are never loaded; final size and SHA256 must
pass before promotion. Invalid complete files are discarded. Public artifacts
are fetched without identity headers;
coordinator requests and the WSS connection authenticate separately. Only
release-pinned model/runtime files can run. No remote shell, executable path
or arbitrary download URL is accepted.

During download, load and contribution, the client refreshes presence and its
assignment. Terminal output shows download progress, stage coverage, readiness,
active requests and reconnects. Model weights stay loaded during a temporary
WSS outage; obsolete KV sessions are cleared before reconnecting. Authentication
rejection stops work. Ctrl+C stops owned processes and releases GPU memory.
An existing tmux session may keep the terminal running after SSH disconnects;
the client installs no automatic startup service.

IDENTITY, RESTART AND UPDATE

  ./limonata-provider start --data-dir /var/lib/limonata-provider
  ./limonata-provider status --data-dir /var/lib/limonata-provider

Status is the last private local snapshot with its timestamp, not a live
connection check. Keep the same --data-dir for start, status and upgrades. Never
delete private/identity.json to retry or run two copies of one identity. Back
it up privately before replacing a Pod or losing its local disk.

New root installs default to /var/lib/limonata-provider; regular users use
~/.local/share/limonata-provider. Existing identities in the older /workspace
location retain that default. Private directories are 0700, identity files
0600. The data filesystem must enforce permissions, ownership and locking.

Version 0.8.0 requires the FULL archive, including shared/runtime. Replacing
only the old client executable is insufficient. Stop the existing client,
extract the verified complete archive above, then restart with the existing
data directory and without repeating --payout. Old model/RPC caches are retained.
Outstanding work or paid quotes may temporarily block an execution-mode change;
wait for those requests to finish and retain the same identity.

Select another GPU with --device CUDA1. Device IDs are logical CUDA IDs and
may be renumbered by CUDA_VISIBLE_DEVICES. Shared mode preserves that visibility
mapping and limits the stage to the selected GPU. Use distinct data directories
for distinct GPUs; do not create multiple identities for one physical device.

OTHER EXPLICIT MODES

  ./limonata-provider start --mode auto
  ./limonata-provider start --mode collective

Auto retains the independent-request pool: one whole model is loaded per GPU,
with a 2048-token context and one request slot. Conservative free-memory
thresholds select Qwen3-32B (22000 MiB; 19.76 GB), Qwen3-8B (7500 MiB; 5.03 GB),
or Qwen2.5-1.5B (2048 MiB; 1.12 GB). A real full-GPU load/inference check follows.
A smaller eligible model may be tried before registration after a load failure;
the final registered model is always explicit. This is separate from shared
mode, where every participating stage belongs to the same pinned 32B model.

Collective retains the older distributed tensor-RPC design. It performs the
small local GPU probe, then joins an RPC group. Its optional verified tensor
cache uses --cache-gib 32 (0 disables; existing files retained). RPC messages
can be latency-sensitive; shared mode instead retains layer weights and KV
on each stage worker. Neither design guarantees Internet response latency.

ACTIVITY AND REWARDS

A stage can be verified and connected while the complete group is still
waiting for another stage. Readiness is not a guarantee of paid demand.
Resource reports and local placement checks are not hardware attestation.
Stage lifecycle output is activity, not blockchain hashrate or earned coins.

Shared-model paid allocation is a separate coordinator/payment integration.
Do not infer earnings from stage calls, replayed tokens, idle time, cached
bytes or downloaded weights. Only explicitly funded, accepted and settled
work can create an earned LIMO amount. Sponsored work earns no provider reward.
Historical credited earnings, pending settlement and a verified on-chain
withdrawable balance are different quantities. Test LIMO has no monetary value.

SECURITY AND VALIDATION

The native stage uses the same _engine isolation path as existing Linux GPU
runtimes: Landlock read access to its verified runtime and assigned model only,
a writable scratch directory, denied outbound connections, restricted syscalls,
no new privileges and root-to-nobody execution where applicable. It cannot
read private identity files or write weights. The Go parent owns networking,
authentication and child cleanup. No sandbox bypass is added for shared mode.

A separate shared/runtime directory holds the patched llama library, avoiding
replacement of the independent-model/RPC runtime. The stage executable and
all bundled libraries are pinned in the client. Linux CUDA source/build
provenance and third-party licenses accompany the complete release.

Local CPU numerical parity, transport/session recovery and isolated payment
fixtures do not establish physical GPU or WAN speed. Actual GPU fit/inference
must pass on each contributor; hardware benchmarks must name the model,
precision, stage layout, GPU, context and network conditions.

BUILD FROM SOURCE

The source archive includes ai/linux, ai/residentclient, ai/inference and
ai/weightcache. From ai/linux, use Go 1.25+ to run:

  go test -race ./...
  CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath -buildvcs=false -ldflags='-s -w' -o limonata-provider .

Run the portable transport tests separately from ai/residentclient. Existing
CUDA runtime reproduction uses ai/linux/build-runtime.sh. The pinned stage
build recipe/source is under ai/swarm; build-cuda-pilot.sh reuses verified
b10107 CUDA objects from that runtime build and rebuilds the modified Qwen3
architecture and stage frontend. A fresh native toolchain may use
ai/swarm/build-native.sh cuda. The packaging script accepts only the pinned
shared runtime hashes; a differently rebuilt artifact needs its own reviewed
pins and validation, not a sidecar override.

HISTORICAL COMPATIBILITY NOTES

The entries below record earlier releases and diagnostics; current behavior is
described above. Old failure reports do not describe the status of this release.

RECOVERING A FAILED 0.5.0 EXTRACTION ON /workspace

If SHA256 said OK but tar reported Cannot utime / Cannot hard link, the archive
is intact but that filesystem cannot extract it. No registration took place
if extraction stopped the command block. Reuse the existing verified archive:

(
  set -eu
  install -d -m 755 /opt/limonata
  tar --no-same-owner -xzf /workspace/limonata-provider-linux-x64-0.5.0.tar.gz -C /opt/limonata
  /opt/limonata/limonata-provider-linux/limonata-provider doctor --data-dir /var/lib/limonata-provider
)

Use --data-dir /var/lib/limonata-provider for subsequent start/status commands
with 0.5.0 as well. This workaround retains all isolation checks. Version 0.5.1
ships regular files only and no longer selects /workspace for new identities.

LINUX 0.5.2 CUDA INITIALIZATION COMPATIBILITY

CUDA names worker threads by writing /proc/<pid>/task/<tid>/comm. The runtime
now receives only WriteFile beneath its own /proc/self/task subtree. Other
processes, unrelated procfs writes, private data and outbound connections
remain restricted. The helper execs the runtime in the same PID; arbitrary
CUDA descendant processes do not receive this additional permission.
This change addresses a locally reproduced blocked operation required by CUDA.
The reported Runpod Blackwell GPU still failed on 0.5.2; see the 0.5.3
follow-up below.
Reference: https://github.com/NVIDIA/OpenShell/pull/1522

Existing 0.5.0/0.5.1 installations can replace just the small client executable;
the CUDA runtime is unchanged and its embedded hashes are rechecked by doctor.
Stop any running provider before updating. From your Runpod root terminal:

(
  set -eu
  cd /opt/limonata/limonata-provider-linux
  base=https://limonata.xyz/ai/downloads
  file=limonata-provider-client-0.6.1
  curl -fL "$base/linux-client" -o "$file"
  curl -fL "$base/linux-checksums" -o SHA256SUMS-linux.txt
  sha256sum --check --ignore-missing SHA256SUMS-linux.txt
  chmod 755 "$file"
  mv "$file" limonata-provider
  ./limonata-provider doctor --data-dir /var/lib/limonata-provider
)

CUDA initialization errors now include the driver's diagnostic when available.
No debug bypass is introduced and no provider identity is changed by this update.

ISOLATED CUDA FAILURE DIAGNOSTIC

A reported Runpod Blackwell Pod still fails isolated enumeration on 0.5.2 while
bare enumeration succeeds. The procfs correction alone has not resolved that
Pod's error. Do not disable isolation or treat the Pod as inference-ready.
To collect the actual failed system calls, run the separately checksummed
diagnostic below. It installs strace from the OS repositories if needed,
traces only isolated device enumeration for at most 45 seconds, and prints
refused operations. The full failed-syscall log stays in private/ with mode
600. No provider identity is read, no registration is sent and no GPU service
is opened. A successful script exit is not a successful GPU test.

(
  set -eu
  cd /opt/limonata
  base=https://limonata.xyz/ai/downloads
  file=limonata-cuda-diagnostic-1.sh
  curl -fL "$base/linux-diagnostic" -o "$file"
  curl -fL "$base/linux-diagnostic-checksums" -o diagnostic.sha256
  sha256sum --check diagnostic.sha256
  bash "$file"
)

Share the printed section between Refused or unsupported operations and
End of diagnostic. Some failed syscalls are normal fallbacks, so the trace
needs interpretation; it is not itself evidence of which operation is fatal.

LINUX 0.5.3 EXACT CUDA OPEN FLAGS

The Runpod trace identifies O_WRONLY|O_CREAT|O_TRUNC when NVIDIA opens an
existing /proc/self/task/<tid>/comm file. Version 0.5.2 granted WRITE_FILE but
omitted the separate Landlock TRUNCATE right required by O_TRUNC on ABI 3+.
Version 0.5.3 grants both rights only beneath the runtime's own task subtree.
It also permits read-only access to /proc/sys/vm/mmap_min_addr and
/etc/localtime, both queried in the trace. No parent-directory read grant,
procfs file-creation grant, network bypass or privileged-runtime fallback
is added. The CUDA runtime and its integrity hashes remain unchanged.

The regression now uses the driver's exact flags and fails before the fix,
then passes after it, including root-to-nobody execution in Ubuntu.
Actual GPU enumeration and inference on the reported Pod remain unverified
until doctor and the subsequent start-time inference check succeed there.
Reference: https://www.kernel.org/doc/html/v6.13/userspace-api/landlock.html

LINUX 0.5.4 CUDA INITIALIZATION FOLLOW-UP

The user's 0.5.3 trace no longer reports the thread-name denial. CUDA reaches
later initialization, which requests /proc/devices, the NVIDIA application
profile directory, and AF_UNIX SOCK_SEQPACKET|SOCK_CLOEXEC sockets.
Version 0.5.4 grants reads of /proc/devices and files/directories below
/etc/nvidia/nvidia-application-profiles-rc.d (when present), plus creation of
AF_UNIX SOCK_SEQPACKET sockets for the local NVIDIA UVM listener.
All connect calls, including Unix socket connections, remain blocked. Unix
stream/datagram sockets and Internet datagram/raw sockets remain blocked.
The local UVM socket is an IPC endpoint inside the host/container; it does
not open an Internet port. No host/container capability changes are required.

Tests exercise the local socket's creation/bind/listen, denied outgoing
connect, denied other socket types, metadata reads and the existing isolation
checks. Actual Runpod GPU enumeration and inference still need confirmation.
The host/container also denied get_mempolicy in the trace; this syscall is
not denied by the provider and this update does not alter host policies.
CUDA local socket trace reference:
https://forums.developer.nvidia.com/t/failure-when-using-openacc-after-mpi-init/176124

LINUX 0.5.5 INFERENCE DIAGNOSTICS

The reported Blackwell Pod passes doctor on 0.5.4 and reaches the generation
request after model readiness and full GPU offload checks. That request fails;
0.5.4 discarded the transport error and runtime log, so the cause is unknown.
Version 0.5.5 allows up to two minutes for the first generation (previously
20 seconds), still within the overall three-minute local probe budget.
First-use PTX compilation can be slow; it is a hypothesis, not a confirmed
cause of the reported failure. Runtime libraries and isolation are unchanged.

On failure, the client reports the transport/HTTP/decode error and the final
40 lines / 8000 characters from the fixed local probe log. The temporary API
key and terminal controls are removed. This does not log private provider
identity or user chats. Successful generation and full GPU offload remain
mandatory before registration; a longer timeout does not waive either check.
Use start without --payout to reuse the saved identity and verified test model.
Reference: https://docs.nvidia.com/cuda/blackwell-compatibility-guide/

LINUX 0.5.6 — VERIFIED PUBLIC WEIGHTS CACHE

Collective mode now keeps eligible public weights on this provider's disk. The
first transfer fills the cache; later loads reuse SHA256-verified local bytes.
Default limit: 32 GiB, with 2 GiB filesystem space reserved. Change the limit
with --cache-gib 16 or disable use with --cache-gib 0. Disabling does not delete
existing cache files. Oversized tensors and unknown models transfer normally.

Only tensors listed in the embedded, pinned public model catalog can persist.
Every hit is SHA256-verified. Unverified incoming bytes stay in bounded RAM
(up to 256 MiB additional live buffer); conversations/activations are not saved.
Disk errors fall back to normal transfers. The native runtime cache is disabled
and the GPU subprocess cannot access the private cache directory.

Cache: DATA_DIR/private/weights. Stop the provider before deleting only this
weights directory to free disk space. Keep private/identity.json: it is your
provider identity. The CLI and status snapshot report cache size, hit count and
bytes not retransferred during the current session. These are not AI speed or
coin earnings. The cache survives app restarts but not loss of the Pod disk.

Qwen3-32B Q4_K_M: about 92% of file bytes are cache eligible; actual savings
depend on assigned layers and available disk. The largest tensors still travel
over the network. GPU upload, warm-up, and generation still take time. This
release does not guarantee a response latency or avoid a reload on API restart.
The cache protocol is pinned to llama.cpp b10107 RPC 4.0.3. No CUDA libraries
changed; existing 0.5.5 installations need only the new client executable.

LINUX 0.6.0 — AUTOMATIC AI CONTRIBUTION

The same isolated RPC client now joins coordinator-managed small-model GPU pools
and larger groups. Terminal activity and historical group speed come from
accepted requests; connected time and local checks never mint rewards. Earned
totals, pending settlements and the current verified payout-wallet withdrawal
balance are distinct. Existing identity, CUDA runtime, isolation and weights
cache are retained. Upgrade by stopping the old client and replacing only the
executable using the current linux-client and linux-checksums download endpoints.

LINUX 0.6.1 — KEEP THE CACHED TUNNEL ALIVE DURING GPU WORK

The verified weights cache now keeps reading WebSocket control frames while the
local GPU is computing. The previous serial relay could miss a server heartbeat
while waiting for a GPU reply, disconnecting an otherwise healthy provider.
Read-ahead uses four fixed 64 KiB buffers; RPC order and normal backpressure are
preserved. Remote closure also releases a pending local GPU socket read. The
128 KiB WebSocket message limit is applied after the NetConn adapter is created.

Replace only the client executable using the verified update command above.
Keep the same --data-dir: your saved identity, payout and disk cache are reused.
The CUDA runtime, GPU checks and process isolation are unchanged. Existing
weights can still need a GPU upload or additional model bytes; disk cache is
not GPU memory. Standby means connected and waiting for an assignment or model
readiness; it does not earn LIMO. Ordinary stream rotation is now logged as a
stream ending instead of always labelling it a connection interruption.

Validation includes real loopback WebSocket pings during a delayed GPU response,
bounded-buffer ordering and teardown, and complete model loads and generations
through two CPU RPC backends. Updated-client physical GPU/WAN validation remains
pending provider reconnection; the local integration is not a speed guarantee.
