Ditto SN118 v0.133.0 stages node-scoped memory screening capacity

Ditto SN118 released v0.133.0 on August 29 with a tighter way to assign screening capacity before miner submissions reach evaluation.

The release adds node-scoped channel leases and a staged design for running normal screening load on a dedicated host, with Google Compute Engine available as overflow. The code and operating instructions are merged. The dedicated host is installed, but it remains deliberately unenrolled.

That boundary defines the update. Ditto has added controls for where screening jobs may run and how much work each enrolled node may claim. It has also documented a rollout sequence. The release does not establish that the dedicated fleet is serving production jobs today.

Capacity now belongs to a node identity

Pull request 1270 builds the control layer.

It introduces append-only, audited concurrency settings for each screening node. Build jobs, runtime smoke tests and source reviews can be bound to enrolled node identities. Shared sandbox limits and separate admission limits for each lane are enforced by the platform.

New nodes start with zero effective capacity. Settings, status changes and job claims require authentication and leases. The Backroom controls use exact compare-and-swap confirmation for reads and writes, which gives operators a stricter way to change capacity without silently overwriting a newer state.

The practical object here is a lease. A node does not receive work simply because a provider exists in configuration. It needs an enrolled identity, channel capacity and a valid claim for that job.

PR 1270 also admits Hetzner as a capacity provider while retaining GCE in each safety route. Its safety note explicitly says the pull request does not deploy, enroll or activate a host.

The dedicated-fleet path is staged

Pull request 1271 supplies the host execution design around those leases.

Under the proposed normal-load setup, subnet-screener-1 would run eight worker processes. The 64 GB server would be capped at four concurrent disposable guests for build and smoke work, plus four concurrent source reviews.

Each submission follows an ordered sequence of static safety preflight, build, runtime smoke, general source review and verdict. Different submissions may move through the sequence at the same time. A failed build or smoke test stops the later source-review step, avoiding that work after an earlier terminal result.

GCE is the overflow route in this design. It is meant to claim new work when the primary node heartbeat is unavailable or when unclaimed backlog rises above the configured threshold, defined as the greater of 12 jobs or three times screening concurrency. The proposed overflow limit is six. GCE is not assigned to retry a lane that already ended on the dedicated path.

These are routing and capacity rules. They do not demonstrate higher throughput or improved reliability. Those outcomes would require operating evidence after enrollment and controlled rollout.

Installed is still outside production policy

The rollout sequence in PR 1271 starts with a development rehearsal. It then calls for enrolling the dedicated server with every channel set to zero while existing routes remain unchanged. A one-lane canary would follow. Steady-state limits come only after proof of the ordered pipeline and its failure paths.

The server preparation has progressed further than a paper plan. According to the pull request, the host has Debian 13 on RAID1 storage, restricted SSH, firewall and update controls, plus validated Docker, KVM and libvirt setup. A digest-verified Debian 12 guest image was booted as a temporary copy-on-write VM and destroyed after the check.

The same source says the host remains deliberately unenrolled. No node credential, source-review key, screener systemd unit or live guest remained after preparation. It also states that merging the repository changes does not enroll the host or alter Backroom production policy.

For readers tracking rollout status, this is the decisive line. The hardware has been prepared and tested at the host level. Production screening on that dedicated fleet still depends on later enrollment, shadow configuration, canary routing and explicit policy changes.

Where screening sits in Ditto SN118

Ditto’s README describes SN118 as a Bittensor subnet for agent memory harnesses. Miners submit a Docker build context that serves the public harness contract. Validators run screened images in isolated sandboxes and score them through DittoBench on tool calling and memory recall.

The v0.133.0 work sits before and around that scoring path. It governs how submissions are admitted to build, smoke and source-review jobs, and which node may perform each step.

Tao Outsider has not independently validated DittoBench, the memory-recall claims or the fleet behavior described in these pull requests. Screening controls can make an evaluation process more bounded and auditable. They do not prove better agent memory quality or benchmark validity.

TaoSwap status snapshot

At 10:45 BRT on August 29, 2026, the TaoSwap snapshot for SN118 showed five active miners and an emission_value of 0.00436394.

That is status only. It records a point-in-time miner count and emission value. It does not measure screening capacity, memory quality, reliability, throughput or traction.

The next meaningful evidence is operational. It would include enrollment at zero capacity, unchanged routes during shadow mode, a documented one-lane canary and proof that GCE overflow follows the published triggers. Until then, v0.133.0 should be read as a merged infrastructure design with a prepared host, not a live dedicated-fleet deployment.