letify 2.8.6__tar.gz → 2.9.0__tar.gz

letify-2.9.0/.github/workflows/publish-crates.yml

@@ -0,0 +1,89 @@
+# Publish the crate letify to crates.io when a version tag is pushed.
+#
+# This runs beside publish.yml on the same tag v<version>. Order inside this file:
+#   1. verify: the tag agrees with every version file, the tagged commit is on develop, the
+#      workspace builds and its tests pass, and `cargo publish --dry-run` packages and builds
+#      the crate alone.
+#   2. publish-crate: the upload, only after verify succeeds.
+# The upload is last because crates.io never replaces a version. A published number can be
+# yanked but is taken forever, so every check that can fail runs before it.
+#
+# GitHub Release creation stays in publish.yml. Other crates in letify-core set publish = false.
+#
+# One-time setup: add the crates.io API token as the secret CARGO_REGISTRY_TOKEN in the GitHub
+# environment crates-io. See docs/guide/08-releasing.md.
+name: publish-crates
+
+on:
+  push:
+    tags: ["v*"]
+
+permissions:
+  contents: read
+
+concurrency:
+  group: publish-crates-${{ github.ref }}
+  cancel-in-progress: false
+
+jobs:
+  verify:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+        with:
+          fetch-depth: 0
+      - uses: astral-sh/setup-uv@v6
+      - name: Install Rust
+        # rustup reads letify-core/rust-toolchain.toml when cargo runs there.
+        run: |
+          rustup toolchain install stable --profile minimal
+          rustup default stable
+      - name: Check the tag and every file carry one version
+        run: uv run --no-project python scripts/version.py check --tag "$GITHUB_REF_NAME"
+      - name: Check the tagged commit is on develop
+        # letify tags develop, not main, so develop is the branch a release must come from.
+        run: |
+          git fetch origin develop
+          if ! git merge-base --is-ancestor "$GITHUB_SHA" origin/develop; then
+            echo "Tagged commit $GITHUB_SHA is not an ancestor of origin/develop."
+            echo "Merge the release commit into develop before tagging."
+            exit 1
+          fi
+      - name: Build the workspace
+        # All five crates are pure Rust with no system packages needed on ubuntu-latest.
+        working-directory: letify-core
+        run: cargo build --workspace --locked
+      - name: Test the workspace
+        working-directory: letify-core
+        run: cargo test --workspace --locked
+      - name: Package and build the crate without uploading
+        working-directory: letify-core
+        run: cargo publish -p letify --dry-run --locked
+
+  publish-crate:
+    needs: verify
+    runs-on: ubuntu-latest
+    environment: crates-io
+    steps:
+      - uses: actions/checkout@v4
+      - name: Install Rust
+        run: |
+          rustup toolchain install stable --profile minimal
+          rustup default stable
+      - name: Publish letify to crates.io
+        working-directory: letify-core
+        env:
+          CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}
+        run: |
+          version="${GITHUB_REF_NAME#v}"
+          status=$(curl -s -o /dev/null -w '%{http_code}' -A "letify-release (https://github.com/DarkPyonix/letify)" "https://crates.io/api/v1/crates/letify/${version}")
+          if [ "$status" = "200" ]; then
+            echo "letify ${version} is already on crates.io, nothing to publish."
+            exit 0
+          fi
+          if [ -z "$CARGO_REGISTRY_TOKEN" ]; then
+            echo "CARGO_REGISTRY_TOKEN is empty."
+            echo "Add a crates.io API token as the secret CARGO_REGISTRY_TOKEN in the crates-io environment."
+            exit 1
+          fi
+          cargo publish -p letify --locked

letify-2.9.0/.github/workflows/reserve-crates.yml

@@ -0,0 +1,77 @@
+# Reserve a letify-* crate name on crates.io before its first real release.
+#
+# Pushing the tag reserve/<crate>, for example reserve/letify-link, publishes version 0.0.0 of
+# that crate: a library with no code whose README says which letify release ships it. The real
+# crate later publishes at letify's own version, as every crate in letify-core does, so 0.0.0
+# stays below every real release.
+#
+# Only names starting with letify- are accepted, and a name crates.io already has is skipped,
+# so pushing the tag again changes nothing. The crate letify itself is not reserved here: it
+# publishes at the release version from publish-crates.yml.
+#
+# The upload runs in the GitHub environment crates-io with the secret CARGO_REGISTRY_TOKEN, as
+# publish-crates.yml does.
+name: reserve-crates
+
+on:
+  push:
+    tags: ["reserve/*"]
+
+permissions:
+  contents: read
+
+concurrency:
+  group: reserve-crates-${{ github.ref }}
+  cancel-in-progress: false
+
+jobs:
+  reserve:
+    runs-on: ubuntu-latest
+    environment: crates-io
+    steps:
+      - name: Install Rust
+        run: |
+          rustup toolchain install stable --profile minimal
+          rustup default stable
+      - name: Publish 0.0.0 unless the name is taken
+        env:
+          CARGO_REGISTRY_TOKEN: ${{ secrets.CARGO_REGISTRY_TOKEN }}
+          CRATE: ${{ github.ref_name }}
+        run: |
+          set -euo pipefail
+          name="${CRATE#reserve/}"
+          if [[ ! "$name" =~ ^letify-[a-z0-9]+(-[a-z0-9]+)*$ ]]; then
+            echo "reserve/$name: only names of the form letify-<word> are reserved here" >&2
+            exit 1
+          fi
+          code="$(curl -s -o /dev/null -w '%{http_code}' -A 'letify-reserve (github.com/DarkPyonix/letify)' "https://crates.io/api/v1/crates/$name")"
+          if [[ "$code" == "200" ]]; then
+            echo "$name is already on crates.io; nothing to reserve"
+            exit 0
+          fi
+          if [[ -z "$CARGO_REGISTRY_TOKEN" ]]; then
+            echo "CARGO_REGISTRY_TOKEN is empty. Add it to the crates-io environment." >&2
+            exit 1
+          fi
+          dir="$RUNNER_TEMP/$name"
+          mkdir -p "$dir/src"
+          cat > "$dir/Cargo.toml" <<TOML
+          [package]
+          name = "$name"
+          version = "0.0.0"
+          edition = "2024"
+          license = "MIT"
+          description = "Reserved for the letify project. The first release ships with letify 3.0."
+          repository = "https://github.com/DarkPyonix/letify"
+          readme = "README.md"
+          TOML
+          cat > "$dir/README.md" <<MD
+          # $name
+
+          This name is reserved for the letify project, https://github.com/DarkPyonix/letify.
+          Version 0.0.0 holds no code. The first release ships with letify 3.0 and carries
+          letify's version, as every letify crate does.
+          MD
+          echo '#![doc = include_str!("../README.md")]' > "$dir/src/lib.rs"
+          cd "$dir"
+          cargo publish --allow-dirty

{letify-2.8.6 → letify-2.9.0}/.gitignore

@@ -253,10 +253,11 @@ __marimo__/
 .claude
 
 # letify
+.letify-home/
 .letify/
 typings/
 
-# letify-core binaries, copied here by letify-core/build.py
+# The letify-quic binary, copied here by letify-core/build.py
 letify/remoting/lib/
 
 # Artifacts the examples write where they run

{letify-2.8.6 → letify-2.9.0}/CLAUDE.md

@@ -114,7 +114,7 @@ This repository uses [ResearchTree](https://darkpyonix.github.io/researchtree/)
 
 ## Code layout
 
-The Python package is pure Python and links no Python extension. The package lives in `letify/` at the repository root. letify-core, the Rust workspace in `letify-core/`, is built in CI and shipped as plain binaries in `letify/remoting/lib/` inside platform wheels.
+The Python package is pure Python and links no Python extension. The package lives in `letify/` at the repository root. letify-core, the Rust workspace in `letify-core/`, is built in CI, and its `letify-quic` binary is shipped in `letify/remoting/lib/` inside platform wheels.
 
 ```
 letify/
@@ -129,7 +129,7 @@ letify/
   runtime/          Channel, session, pool, lease, bootstrap and telemetry
   store/            Content addressed blob store, volumes and backends
   providers/        Provider base class and one module per provider
-  remoting/         CUDA API forwarding, used only where a low-latency path exists
+  remoting/         PyTorch operator forwarding for host="local" (remoting/device/) and the efficiency arithmetic; also holds the letify-quic binary in lib/
   _vendor/          Vendored third party code
 letify-ext/         VS Code extension (TypeScript) showing quota and GPU activity from the CLI's --json output
 ```

{letify-2.8.6 → letify-2.9.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: letify
-Version: 2.8.6
+Version: 2.9.0
 Summary: Declarations that become infrastructure.
 Project-URL: Homepage, https://github.com/DarkPyonix/letify
 Project-URL: Documentation, https://github.com/DarkPyonix/letify/tree/main/docs
@@ -171,7 +171,7 @@ uv add letify
 
 That is the whole install, for every provider. letify installs only cloudpickle and blake3. It needs [uv](https://docs.astral.sh/uv/) on the machine, because provider tools such as the Colab CLI and the Modal client run through uv in their own environments, not in your `.venv`.
 
-The wheel carries [letify-core](letify-core/), the Rust component behind `host=letify.local` that stands in for the CUDA driver. Wheels are built for Linux x86_64 and aarch64, Windows x86_64 and arm64, and macOS arm64 and x86_64. On another platform, pip falls back to the source distribution, which has no letify-core, and `host=letify.local` is refused.
+The wheel carries the `letify-quic` binary built from [letify-core](letify-core/), the Rust workspace. Wheels are built for Linux x86_64 and aarch64, Windows x86_64 and arm64, and macOS arm64 and x86_64. On another platform, pip falls back to the source distribution, which has no `letify-quic`, so the QUIC connection strategy is skipped.
 
 ---
 
@@ -259,9 +259,9 @@ Two words, and neither of them is a mechanism.
 
 **`device`** carries the provider, the account and the accelerator in one value, because those are one decision. Core count and memory come with the shape the provider registered, so there is nothing to ask for.
 
-**`host`** is the CUDA word for the CPU side. `letify.local` keeps Python and the libraries in this process and forwards only CUDA calls. `letify.remote` ships the function to the machine that holds the device. The strings `"local"` and `"remote"` are the same values.
+**`host`** is the CUDA word for the CPU side. `letify.local` keeps Python and the libraries in this process and forwards only PyTorch operators. `letify.remote` ships the function to the machine that holds the device. The strings `"local"` and `"remote"` are the same values.
 
-Leave `host` out and you get `letify.local`. When the device is far away, forwarding every CUDA call is slow, so the call warns with the expected efficiency and then runs. For a remote GPU, `host=letify.remote` is usually what you want.
+Leave `host` out and you get `letify.local`. When the device is far away, forwarding operators is slow, so the call warns with the expected efficiency and then runs. For a remote GPU, `host=letify.remote` is usually what you want.
 
 How long a session lives is not a declaration argument. A call ends its session. `with let.keep_alive():` keeps sessions for the length of a block, so a run of separate calls does not pay session start each time.
 
@@ -283,7 +283,7 @@ Counter-intuitive consequence: **a faster GPU makes forwarding worse**, because
 
 Decoding is the case that stays bad. Throughput is bounded near `1000 / (k × RTT)` tokens per second, so the card stops mattering. Ship the whole `generate` call instead.
 
-Measure your own `k` with `torch.cuda.set_sync_debug_mode("warn")` and your round trip with `letify probe`. See [docs/NETWORK.md](docs/NETWORK.md).
+Measure your own `k` with `torch.cuda.set_sync_debug_mode("warn")` and your round trip with `ping`. See [docs/NETWORK.md](docs/NETWORK.md).
 
 </details>
 
@@ -495,7 +495,6 @@ letify status                 # what is running right now
 letify usage                  # what is left on each account
 letify utilization            # how busy each instance's GPU is
 letify check lab              # does this machine answer?
-letify probe lab              # is host=letify.local worth using here?
 letify efficiency 0.5 3 150   # the formula, from measured terms
 ```
 
@@ -513,7 +512,7 @@ Add `--json` to `usage`, `utilization` or `status` for output a program can read
 | 📐 [docs/SPEC.md](docs/SPEC.md) | The design as it stands, decision by decision |
 | 🧩 [docs/COMPONENT.md](docs/COMPONENT.md) | Every class, and the vocabulary |
 | 🌐 [docs/NETWORK.md](docs/NETWORK.md) | Transports, latency measurements, tunnel choices |
-| 🦀 [letify-core/](letify-core/) | The Rust workspace behind `host=letify.local` |
+| 🦀 [letify-core/](letify-core/) | The Rust workspace: the `letify` crate and the `letify-quic` binary |
 | 🧭 [docs/guide/](docs/guide/) | Task-oriented guides |
 | 🇰🇷 [docs/locales/README_ko.md](docs/locales/README_ko.md) | 한국어 |
 
@@ -527,11 +526,9 @@ Alpha, and honest about it. What works today:
 ✅ Persistent sessions: a session cache keeps values between calls, large arguments travel once
 ✅ Content addressed storage, configuration and secrets
 ✅ The `Local` and `Colab` providers
-✅ `letify-core`, verified on a real GPU: the agent opens the driver, the local driver forwards an allocation and a copy in both directions, and the bytes match
 
 Not finished yet:
 
-🚧 `letify-driver` covers the entry points a PyTorch process needs to start up and run one kernel. Anything else names itself and returns `CUDA_ERROR_NOT_SUPPORTED`, so a real run prints the list of what to build next
 🚧 `Modal` and `Elice` follow each published interface but have not been run against the live services
 🚧 Unified memory cannot be forwarded at all, so a paged optimizer needs `host=letify.remote`
 

{letify-2.8.6 → letify-2.9.0}/PROJECT.md

@@ -190,6 +190,22 @@ cache.fetch_checkpoint("run-1", target)
 cache.resume(runtime, "run-1", path)   # put the newest one inside a session
 ```
 
+### Exit hooks
+
+```python
+letify.on_exit(fn)                    # inside a body: run fn if the worker ends before the body does
+```
+
+The hook runs on `SIGTERM`, when the lease deadline passes and when the channel closes during the call, newest first, within 120 s in total. Outside a body it raises `UnsupportedMode`. `letify runs`, `interrupt` and `exec` reach a running call from the command line; see [Controlling a running call](docs/SPEC.md#run-control).
+
+### Taking over a running call
+
+```python
+value = letify.takeover(run)         # become the owner of a running call, return its value
+```
+
+`letify.takeover(run)` and `letify takeover <run>` make the calling process the owner of a call another process started: it renews the lease, receives the output and the result, writes the call's outputs back under the project the call was sent from, and ends the session. The previous owner, if it is alive, is asked to let go and its waiting call raises `OwnershipMoved`. A provider whose runtime a second process cannot reach raises `UnsupportedMode` naming it; see [Taking over a running call](docs/SPEC.md#run-takeover).
+
 ### Handoffs
 
 ```python
@@ -225,6 +241,7 @@ Both work in the local process and inside a shipped function, on any provider. T
 | `ProtocolError` | The remote process died before producing a result | yes |
 | `RemoteError` | The shipped function raised; carries the remote traceback | no |
 | `UnsupportedMode` | The requested mode cannot work here | no |
+| `OwnershipMoved` | The call you were waiting on was taken over by another process, which now receives its result | no |
 | `InsufficientDevices` | The devices a call asks for cannot be allocated; names what holds them | no |
 
 ### Command line
@@ -237,8 +254,11 @@ letify devices                # accelerators each provider offers
 letify status                 # live sessions and what they are costing
 letify usage [alias]          # what is left on each account
 letify utilization [alias]    # how busy each instance's accelerator is
+letify runs                   # calls running from this machine, with their run ids
+letify interrupt <run>        # raise KeyboardInterrupt in a running call's body
+letify exec <run> CODE        # run source beside a running call (-f FILE, --timeout S)
+letify takeover <run>         # become the owner of a running call (--result PATH, --json)
 letify check <alias>          # confirm a machine answers
-letify probe <host>           # whether host="local" is worth using
 letify efficiency 0.5 3 150   # expected share of a direct run
 letify stubs                  # write typings/letify_providers.pyi for editor completion
 ```
@@ -298,6 +318,10 @@ That is the only install. `letify` installs cloudpickle and blake3 and nothing e
 
 `host="local"` additionally needs PyTorch 2.1 or newer in the project, locally and in the runtime's environment, with the same major.minor version on both sides. letify never installs it: torch is the project's own dependency.
 
+## Rust crate
+
+The Rust crate `letify` is published on crates.io at the same version as the Python package. It will re-export the components meant for use outside letify, first the connection library `letify-link`.
+
 ## How this project is built
 
 Spec driven and test driven. [docs/SPEC.md](docs/SPEC.md) is the source of truth, a change edits it before the code, and every test traces to a section of it. The rules are in [CLAUDE.md](CLAUDE.md).

{letify-2.8.6 → letify-2.9.0}/README.md

@@ -146,7 +146,7 @@ uv add letify
 
 That is the whole install, for every provider. letify installs only cloudpickle and blake3. It needs [uv](https://docs.astral.sh/uv/) on the machine, because provider tools such as the Colab CLI and the Modal client run through uv in their own environments, not in your `.venv`.
 
-The wheel carries [letify-core](letify-core/), the Rust component behind `host=letify.local` that stands in for the CUDA driver. Wheels are built for Linux x86_64 and aarch64, Windows x86_64 and arm64, and macOS arm64 and x86_64. On another platform, pip falls back to the source distribution, which has no letify-core, and `host=letify.local` is refused.
+The wheel carries the `letify-quic` binary built from [letify-core](letify-core/), the Rust workspace. Wheels are built for Linux x86_64 and aarch64, Windows x86_64 and arm64, and macOS arm64 and x86_64. On another platform, pip falls back to the source distribution, which has no `letify-quic`, so the QUIC connection strategy is skipped.
 
 ---
 
@@ -234,9 +234,9 @@ Two words, and neither of them is a mechanism.
 
 **`device`** carries the provider, the account and the accelerator in one value, because those are one decision. Core count and memory come with the shape the provider registered, so there is nothing to ask for.
 
-**`host`** is the CUDA word for the CPU side. `letify.local` keeps Python and the libraries in this process and forwards only CUDA calls. `letify.remote` ships the function to the machine that holds the device. The strings `"local"` and `"remote"` are the same values.
+**`host`** is the CUDA word for the CPU side. `letify.local` keeps Python and the libraries in this process and forwards only PyTorch operators. `letify.remote` ships the function to the machine that holds the device. The strings `"local"` and `"remote"` are the same values.
 
-Leave `host` out and you get `letify.local`. When the device is far away, forwarding every CUDA call is slow, so the call warns with the expected efficiency and then runs. For a remote GPU, `host=letify.remote` is usually what you want.
+Leave `host` out and you get `letify.local`. When the device is far away, forwarding operators is slow, so the call warns with the expected efficiency and then runs. For a remote GPU, `host=letify.remote` is usually what you want.
 
 How long a session lives is not a declaration argument. A call ends its session. `with let.keep_alive():` keeps sessions for the length of a block, so a run of separate calls does not pay session start each time.
 
@@ -258,7 +258,7 @@ Counter-intuitive consequence: **a faster GPU makes forwarding worse**, because
 
 Decoding is the case that stays bad. Throughput is bounded near `1000 / (k × RTT)` tokens per second, so the card stops mattering. Ship the whole `generate` call instead.
 
-Measure your own `k` with `torch.cuda.set_sync_debug_mode("warn")` and your round trip with `letify probe`. See [docs/NETWORK.md](docs/NETWORK.md).
+Measure your own `k` with `torch.cuda.set_sync_debug_mode("warn")` and your round trip with `ping`. See [docs/NETWORK.md](docs/NETWORK.md).
 
 </details>
 
@@ -470,7 +470,6 @@ letify status                 # what is running right now
 letify usage                  # what is left on each account
 letify utilization            # how busy each instance's GPU is
 letify check lab              # does this machine answer?
-letify probe lab              # is host=letify.local worth using here?
 letify efficiency 0.5 3 150   # the formula, from measured terms
 ```
 
@@ -488,7 +487,7 @@ Add `--json` to `usage`, `utilization` or `status` for output a program can read
 | 📐 [docs/SPEC.md](docs/SPEC.md) | The design as it stands, decision by decision |
 | 🧩 [docs/COMPONENT.md](docs/COMPONENT.md) | Every class, and the vocabulary |
 | 🌐 [docs/NETWORK.md](docs/NETWORK.md) | Transports, latency measurements, tunnel choices |
-| 🦀 [letify-core/](letify-core/) | The Rust workspace behind `host=letify.local` |
+| 🦀 [letify-core/](letify-core/) | The Rust workspace: the `letify` crate and the `letify-quic` binary |
 | 🧭 [docs/guide/](docs/guide/) | Task-oriented guides |
 | 🇰🇷 [docs/locales/README_ko.md](docs/locales/README_ko.md) | 한국어 |
 
@@ -502,11 +501,9 @@ Alpha, and honest about it. What works today:
 ✅ Persistent sessions: a session cache keeps values between calls, large arguments travel once
 ✅ Content addressed storage, configuration and secrets
 ✅ The `Local` and `Colab` providers
-✅ `letify-core`, verified on a real GPU: the agent opens the driver, the local driver forwards an allocation and a copy in both directions, and the bytes match
 
 Not finished yet:
 
-🚧 `letify-driver` covers the entry points a PyTorch process needs to start up and run one kernel. Anything else names itself and returns `CUDA_ERROR_NOT_SUPPORTED`, so a real run prints the list of what to build next
 🚧 `Modal` and `Elice` follow each published interface but have not been run against the live services
 🚧 Unified memory cannot be forwarded at all, so a paged optimizer needs `host=letify.remote`
 

{letify-2.8.6 → letify-2.9.0}/docs/COMPONENT.md

@@ -24,7 +24,7 @@ Read this table first. Most confusion about letify is one of these words meaning
 | **persistence** | Whether a provider's storage outlives a session: `persistent` or `ephemeral`. |
 | **RemoteTensor** | Under `host="local"`, the local stand-in for a tensor on the runtime's GPU: a meta tensor for shape and dtype plus a handle. Reports its device as `cuda:0`. |
 | **device worker** | The process on the runtime that runs PyTorch operators on real tensors keyed by handle, one per session. |
-| **letify-core** | A Rust workspace from an earlier `host="local"` design that stood in for the CUDA driver. Retired from that path; nothing on it calls letify-core. |
+| **letify-core** | The Rust workspace in `letify-core/`: the `letify` crate and the `letify-quic` binary. The CUDA driver stand-in it once held is removed. |
 
 ## The shape of the thing
 
@@ -58,7 +58,7 @@ One directory per concern, so the file you need is the one named after the thing
 | `runtime/` | The channel, the session, the pool, the lease, bootstrap source |
 | `providers/` | The base class, name normalization, and one module per provider |
 | `store/` | The content addressed store, volumes, and `backends/` |
-| `remoting/` | PyTorch forwarding in `remoting/device/`, and the round trip probe and efficiency arithmetic |
+| `remoting/` | PyTorch forwarding in `remoting/device/`, and the efficiency arithmetic |
 | `launcher.py` | `Launcher` itself, which ties the rest together |
 | `errors.py` | The exception hierarchy, which everything imports |
 | `cli.py` | The command line |
@@ -180,7 +180,7 @@ Three protocol rules exist for performance rather than tidiness. Large arguments
 
 ## remoting
 
-PyTorch forwarding, in `remoting/device/`, and the round trip arithmetic beside it.
+PyTorch forwarding, in `remoting/device/`, and the efficiency arithmetic beside it.
 
 | Module | Owns |
 |---|---|
@@ -197,4 +197,4 @@ It refuses rather than degrading when PyTorch is absent or too old. It does not
 
 ## letify-core
 
-A Rust workspace that stood in for the CUDA driver in an earlier design of `host="local"`. It is retired from that path because libcudart needs driver symbols the stand-in cannot provide; the spec's "The driver stand-in is retired" gives the measurement. The crates remain in `letify-core/` and nothing in the Python package calls them on the `host="local"` path.
+The Rust workspace in `letify-core/`. It holds the crate `letify`, published to crates.io, and the binary `letify-quic`, which the wheels carry in `letify/remoting/lib/` and `letify/transport/quic.py` runs. The driver stand-in it once held is removed; the spec's "The driver stand-in is removed" gives the measurement and where the code is.

{letify-2.8.6 → letify-2.9.0}/docs/NETWORK.md

@@ -217,26 +217,6 @@ Both sides bound one TCP port, learned the mapping from `stun.nextcloud.com:443`
 
 `colab console` is not a usable channel: it is a terminal inside tmux, and a single input line of 4000 characters or more arrives truncated or mixed with terminal control sequences. The Colab runtime proxy reaches only port 8080 on the VM; other port prefixes return 404.
 
-### letify-core copy throughput
-
-A copy to the device through letify-core, with the payload streamed from the caller's buffer into the agent's staging buffer, moves about 2000 MiB/s over loopback TCP. The same payload through an encoded frame, the path before streaming, moves about 520 MiB/s. Both carry one 256 MiB `CopyToDevice` request between a `BufWriter` and a `BufReader` with `TCP_NODELAY`, on an AMD EPYC 7763, and report the median of five runs.
-
-| Path | Three invocations |
-|---|---|
-| Encoded frame, before the change | 545, 544, 507 MiB/s |
-| Encoded frame, after the change | 515, 514, 519 MiB/s |
-| Streamed into staging | 2043, 1961, 1873 MiB/s |
-
-A copy to the host, with the payload streamed from the agent's staging buffer into the caller's buffer, moves about 3250 MiB/s over loopback TCP. The same payload through an encoded frame and a copy into the caller's buffer, the path before streaming, moves about 520 MiB/s. Both carry one 256 MiB `Payload` reply over the same socket pair and machine and report the median of five runs. The copy on the device is not included.
-
-| Path | Three invocations |
-|---|---|
-| Encoded frame, before the change | 522, 514, 519 MiB/s |
-| Encoded frame, after the change | 528, 527, 540 MiB/s |
-| Streamed into the destination | 3234, 3261, 3244 MiB/s |
-
-Loopback removes the network, so these numbers bound what the copy path itself costs. On a real link the link rate decides throughput whenever it is below them. To reproduce, run `cargo test --release -p letify-wire --test throughput -- --ignored --nocapture --test-threads=1` in `letify-core/`.
-
 ## PyTorch forwarding on dept_gpu
 
 > Reading the loss once every 50 steps, `host="local"` takes a median 3.45 ms per step against 1.70 ms directly on the server: about twice the direct time, and one round trip per 45 steps. Measured on 2026-09-14.
@@ -315,7 +295,7 @@ Three checks settle most of what is provider specific.
 
 ```bash
 # Round trip to the machine, which sets the efficiency formula.
-letify probe gpu.lab.example.edu
+ping -c 5 gpu.lab.example.edu
 
 # Whether a layer 3 tunnel is possible at all.
 ls -l /dev/net/tun