letify 2.8.6__tar.gz → 2.8.7__tar.gz

letify-2.8.7/.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.8.7/.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.8.7}/.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.8.7}/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.8.7}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: letify
-Version: 2.8.6
+Version: 2.8.7
 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.8.7}/PROJECT.md

@@ -238,7 +238,6 @@ 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 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 +297,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.8.7}/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.8.7}/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.8.7}/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

{letify-2.8.6 → letify-2.8.7}/docs/SPEC.md

@@ -278,7 +278,7 @@ Not opening a link is a decision of this project, not a rule of Kaggle's. Two so
 - `TPU_V3_8` is a TPU instance, carried by `Instance.tpu` rather than `Instance.gpu`, and requests `TPU_V3_8` as the accelerator in `CommitAndRun`. With `host="remote"`, letify ships the whole function to the runtime. Using the TPU is the user's code's responsibility, with `torch-xla` or JAX in the user's own lock file; letify neither installs nor checks those TPU libraries. letify requests and reports the TPU, without making the user's code TPU-capable. Kaggle refuses `host="local"` for TPU instances as it does for every other Kaggle instance.
 - When no account inventory is configured, the default inventory takes each discovered instance's device count, so the two-card `T4` shape can be reserved. An explicit account inventory keeps its configured counts and indices.
 - **Two credentials, both required.** The cookie starts and ends the interactive session and mints its Jupyter proxy URL. The API token authenticates every official Kaggle CLI invocation through `KAGGLE_API_TOKEN` in the child environment, never process arguments, for notebook deletion and weekly quota. There is no cookie fallback. Login stores the cookie in `~/.letify/accounts/<alias>/cookie` and the verbatim token, including `KGAT_`, in `access_token` beside it, using owner-only files (0600) and an owner-only directory (0700). The CLI accepts no working file-based token form, so keeping the token out of the environment cannot be honoured. Its child process environment is the narrowest available scope and exposes less than the argument list. An account without `access_token` is refused with `ConfigError` naming the login command when it reaches a CLI-only path.
-- **Token input and notebook owner.** `letify login kaggle <alias>` accepts `--key` or hidden input asking for the API token exactly as kaggle.com shows it, including `KGAT_`. It requires that prefix and a nonempty body with no whitespace; it does not strip or reformat the token. Length is not fixed because the measured 32-character body establishes a working token, not a universal length contract. A malformed token is refused with a message naming what to paste, before any cookie verification or file write. The token is not verified online at login. A login never silently reuses a token already on disk: `letify login kaggle <alias> --replace` asks for the token again, because the reason to renew an account is usually that the stored credential stopped working, and reusing it would make the renewal a no-op with no way to replace it. An account declared before the token was stored under this name still has to be renewed once. Login retains `--username` or a username prompt and stores it in `username` beside the credentials with mode 0600. This is only the owner for `kernels delete -y <owner>/<slug>`, not an authentication credential. Explicit input avoids another authenticated lookup and does not mistake a cookie display name for an owner. The owner is not read from an authenticated call. Reading an existing `access_token` file strips leading and trailing whitespace, including a trailing newline, before CLI calls or reuse by login when `--key` is omitted. Explicit `--key` and prompted token input still reject whitespace rather than reformatting it, so adding an owner with `--username` does not require pasting the token again. The owner is a public Kaggle username, not a secret, and its file uses the same owner-only permissions as the account directory. Login refuses a missing or blank owner before cookie verification or any file write. Nothing is written until both credentials, the owner and cookie verification pass. Before any session starts or notebook is created, `open_channel` requires a readable, nonempty `username` file. An incomplete account is refused with `ConfigError` naming the login command, so a run cannot reach teardown without a notebook owner.
+- **Token input and notebook owner.** `letify login kaggle <alias>` accepts `--key` or hidden input asking for the API token exactly as kaggle.com shows it, including `KGAT_`. It requires that prefix and a nonempty body with no whitespace; it does not strip or reformat the token. Length is not fixed because the measured 32-character body establishes a working token, not a universal length contract. A malformed token is refused with a message naming what to paste, before any cookie verification or file write. The token is not verified online at login. A renewal asks for each credential rather than reusing what is on disk, and a blank answer keeps the stored one. The two credentials expire on different clocks: the cookie is a thirty day web session and the token lasts until it is rotated, so renewing one must not demand the other. `letify login kaggle <alias> --replace` therefore prompts for the token and then the cookie, each saying that blank keeps what is stored, and writes only what was answered. A blank answer with nothing stored is refused, naming what to paste. Silently reusing a stored credential would make a renewal a no-op with no way to replace a credential that stopped working. Login retains `--username` or a username prompt and stores it in `username` beside the credentials with mode 0600. This is only the owner for `kernels delete -y <owner>/<slug>`, not an authentication credential. Explicit input avoids another authenticated lookup and does not mistake a cookie display name for an owner. The owner is not read from an authenticated call. Reading an existing `access_token` file strips leading and trailing whitespace, including a trailing newline, before CLI calls or reuse by login when `--key` is omitted. Explicit `--key` and prompted token input still reject whitespace rather than reformatting it, so adding an owner with `--username` does not require pasting the token again. The owner is a public Kaggle username, not a secret, and its file uses the same owner-only permissions as the account directory. Login refuses a missing or blank owner before cookie verification or any file write. Nothing is written until both credentials, the owner and cookie verification pass. Before any session starts or notebook is created, `open_channel` requires a readable, nonempty `username` file. An incomplete account is refused with `ConfigError` naming the login command, so a run cannot reach teardown without a notebook owner.
 - **The cookie carries an ``exp`` claim, but that claim is not proof the cookie still works.** The `CLIENT-TOKEN` cookie is an `alg:none` JWT whose `exp` claim was thirty days after the login that minted it, in every case observed. But a live account has been seen with over nine days left on that claim while every internal call, including the plain `users.UsersService/GetCurrentUser` read, answered as a refused, anonymous session: Kaggle invalidates a cookie server side, for reasons this project has not pinned down, without the claim changing to say so. So `exp` is useful for exactly one direction: a cookie past its `exp` is certainly dead. It says nothing about a cookie before its `exp`, which may be live or may already be refused.
   - **Two checks, for two costs.** An offline check reads only the claim, costs no network call, and is what `letify providers` shows as the account's `exp claim says N days left (not checked live; see letify usage)`, or `EXPIRED` once `exp` has passed. An online check additionally calls `GetCurrentUser`, the same call the login proved the cookie with, and is made once per session start (`open_channel`) and once per `letify usage` read, each result trusted for sixty seconds so starting several runtimes together costs one round trip rather than one per runtime. A run whose cookie fails either check is refused with `ConfigError`: missing or past `exp` says exactly that; refused online says "the Kaggle cookie has not expired, but Kaggle no longer accepts it", which is the one fact that check establishes, never a guess at why. A run is also refused when fewer than one hour is left on the `exp` claim, since starting a session the claim says the cookie cannot outlive risks it dying mid run with no way to tell that apart from any other lost runtime; this offline guard and the online check both have to pass.
   - The online check is not made on every call into a running session, only at the two points above, so it is not the cost of every request a declared function makes.
@@ -1895,7 +1895,7 @@ A UDP pinhole opens where a TCP simultaneous open is refused, which is why Tailc
 
 QUIC is the one UDP payload such a device is unlikely to shape, because HTTP/3 is QUIC and shaping it breaks the web. So letify can carry the session over a real QUIC v1 connection: version 1 on the wire, a TLS 1.3 handshake, a certificate, and the ALPN `letify/1`.
 
-`letify-quic` is a binary in letify-core, built for each wheel and installed beside the CUDA shim in `letify/remoting/lib/`. It takes the punched endpoints rather than discovering anything, because the rendezvous already exchanges them:
+`letify-quic` is a binary in letify-core, built for each wheel and installed in `letify/remoting/lib/`. It takes the punched endpoints rather than discovering anything, because the rendezvous already exchanges them:
 
 ```
 letify-quic serve   --bind <port> --peer <ip:port> --token <hex> --forward <ssh port>
@@ -2585,11 +2585,13 @@ A lost worker process or link raises `RuntimeLost`, and the session is discarded
 
 `_make_wrapper_subclass`, `TorchFunctionMode` and `torch.utils._pytree` are each present in 2.1. An older PyTorch raises `UnsupportedMode` naming the version found and the version needed.
 
-### The driver stand-in is retired <!-- id: letify-core -->
+### The driver stand-in is removed <!-- id: letify-core -->
 
-> `host="local"` does not load letify-core. Standing in for the CUDA driver was replaced by operator forwarding.
+> `host="local"` does not load letify-core. Standing in for the CUDA driver was replaced by operator forwarding, and the driver stand-in was removed from the tree.
 
-Measured on 2026-09-14 against a Tesla P100 server with torch 2.5.1 cu121: libcudart 12.1 resolves 425 driver symbols by name and the stand-in `libcuda.so.1` exports 20, so CUDA initialization fails with `cudaErrorInsufficientDriver`. The private `cuGetExportTable` blocks adding symbols one by one, and PyTorch kernels arrive through fatbinary registration that `cuModuleLoadData` does not see. Operator forwarding depends on PyTorch's public extension points instead of the driver's private ones. The Rust crates in `letify-core/` and `letify.remoting.probe` remain in the tree and the wheels, and nothing on the `host="local"` path calls them.
+Measured on 2026-09-14 against a Tesla P100 server with torch 2.5.1 cu121: libcudart 12.1 resolves 425 driver symbols by name and the stand-in `libcuda.so.1` exports 20, so CUDA initialization fails with `cudaErrorInsufficientDriver`. The private `cuGetExportTable` blocks adding symbols one by one, and PyTorch kernels arrive through fatbinary registration that `cuModuleLoadData` does not see. Operator forwarding depends on PyTorch's public extension points instead of the driver's private ones.
+
+The crates `letify-wire`, `letify-driver` and `letify-agent` and the module `letify.remoting.probe` are not in the tree. The code is at the git tag `archive/cuda-driver-forwarding`. A stand-in at the CUDA runtime API layer, which libcudart does not need driver symbols for, is proposed in [pull request 74](https://github.com/DarkPyonix/letify/pull/74). `letify-core/` holds the crates `letify` and `letify-quic`.
 
 ## Command line
 
@@ -2615,7 +2617,7 @@ A heading, an alias at the top of a block and a table's column names are bold. S
 
 A `LetifyError` that reaches the command line prints `✗ <message>` on standard error and exits with 1. An argument error is argparse's own and exits with 2.
 
-`--json` prints the records with no styling on `providers`, `devices`, `status`, `usage`, `utilization`, `probe` and `efficiency`.
+`--json` prints the records with no styling on `providers`, `devices`, `status`, `usage`, `utilization` and `efficiency`.
 
 Connection decision lines stay on standard error as `letify: <message>`, with the content set by Transport. When standard error is a terminal with colour, the `letify:` prefix is dim and nothing else changes.
 
@@ -2627,7 +2629,6 @@ Connection decision lines stay on standard error as `letify: <message>`, with th
 | `devices` | A table `PROVIDER  ACCELERATORS`, the accelerators joined by `, `. `--json` is the mapping from alias to accelerator names |
 | `status` | The header `<name>  <live> live, <busy> busy`, one block per live runtime, then a table `PROVIDER  ACCELERATOR  RESERVED  INDICES` with reserved as `<reserved>/<count>`. With no runtime the blocks are replaced by `no live session in this process`. `--json` is `Launcher.status()` |
 | `usage`, `utilization` | As Remaining usage and GPU utilization describe |
-| `probe` | A mark and `forwarding usable`, `forwarding usable but costly` or `forwarding not usable`, then aligned `platform`, `core`, `agent` and `round trip` fields and the reason, dim. `--json` is the capability record |
 | `efficiency` | `<p>% of a direct run`. `--json` is `{"efficiency": <fraction>}` |
 | `check` | `✓ <alias> answers`, then the machine's output indented by 2 spaces |
 | `login` | `✓ <alias> declared in <home>`, or `! <alias> was already declared in <home>, so nothing was asked for`, then `✓ <alias> referenced in <project>, which is safe to commit` |
@@ -2754,7 +2755,7 @@ Provider tools run out of process and never in the user's `.venv`. Colab runs th
 
 uv must be installed. letify finds it from the `UV` environment variable, then from `PATH`. If neither has it, letify raises an error that says uv is required.
 
-The Python code is pure and links no Python extension. letify-core binaries are built in CI and placed in `letify/remoting/lib/`, so each release has one wheel per desktop platform, tagged `py3-none-<platform>`:
+The Python code is pure and links no Python extension. The `letify-quic` binary of letify-core is built in CI and placed in `letify/remoting/lib/`, so each release has one wheel per desktop platform, tagged `py3-none-<platform>`:
 
 | Platform | Wheel platform tag |
 |---|---|
@@ -2765,7 +2766,7 @@ The Python code is pure and links no Python extension. letify-core binaries are
 | macOS arm64 | `macosx_11_0_arm64` |
 | macOS x86_64 | `macosx_10_12_x86_64` |
 
-Linux wheels are built inside the `manylinux_2_28` containers, so the binaries need glibc 2.28 or newer. That covers RHEL 8, Debian 10 and Ubuntu 18.10 onward. The sdist carries no binaries, and an install from it has no letify-core.
+Linux wheels are built inside the `manylinux_2_28` containers, so the binaries need glibc 2.28 or newer. That covers RHEL 8, Debian 10 and Ubuntu 18.10 onward. The sdist carries no binaries, and an install from it has no `letify-quic`, so the QUIC strategy is skipped.
 
 ### Versioning and releases <!-- id: versioning -->
 
@@ -2776,7 +2777,7 @@ Linux wheels are built inside the `manylinux_2_28` containers, so the binaries n
 | File | Field |
 |---|---|
 | `letify/__init__.py` | `__version__` |
-| `letify-core/Cargo.toml` | `[workspace.package].version`, and the `letify-wire`, `letify-driver` and `letify-agent` entries in `Cargo.lock` |
+| `letify-core/Cargo.toml` | `[workspace.package].version`, and the `letify` and `letify-quic` entries in `Cargo.lock` |
 | `letify-ext/package.json` | `version`, and `version` and `packages[""].version` in `package-lock.json`, when `letify-ext/` exists |
 | Git tag | `v<version>` |
 
@@ -2784,6 +2785,10 @@ Linux wheels are built inside the `manylinux_2_28` containers, so the binaries n
 
 Pushing a tag `v*` runs `.github/workflows/publish.yml`. It builds the sdist, the six platform wheels above and, when `letify-ext/` exists, the extension's `letify-ext-<version>.vsix` after its unit tests pass. It then creates the GitHub Release for the tag with every one of those files attached, and uploads the sdist and wheels to PyPI. The extension is not published to the VS Code Marketplace.
 
+The same tag also runs `.github/workflows/publish-crates.yml`, which publishes the crate `letify` to crates.io at the same version. `letify` is the Rust face of the project: a library crate in `letify-core/letify` that re-exports the letify components meant for use outside letify, the first being the connection library `letify-link` once it exists. Every other crate in `letify-core/` sets `publish = false`, because each is a binary shipped inside the wheels and tied to the Python package of the same version. The workflow checks before it uploads anything: the tag agrees with every version file, the tagged commit is on `develop`, the workspace builds and its tests pass, and `cargo publish -p letify --dry-run` packages and builds the crate on its own. The upload comes last, because crates.io never replaces a version: a published number can be yanked but is taken forever. It runs in the GitHub environment `crates-io` with the repository secret `CARGO_REGISTRY_TOKEN`, a crates.io API token scoped to publishing `letify` and the future `letify-*` crates. A tag pushed before that secret exists fails at the upload and publishes nothing.
+
+A `letify-*` crate name is reserved before its first release by pushing the tag `reserve/<crate>`, which runs `.github/workflows/reserve-crates.yml` and publishes version 0.0.0 of that name with no code and a README naming the letify release that ships it. A name crates.io already has is skipped, and a name not of the form `letify-<word>` is refused. The real crate then publishes at letify's version like every other, so 0.0.0 stays below every real release. `letify-link` and `letify-proto` are reserved this way, for letify 3.0.
+
 ## Known gaps
 
 > Implemented and unimplemented, stated plainly so nobody builds on a promise.

{letify-2.8.6 → letify-2.8.7}/docs/guide/03-execution-modes.md

@@ -86,7 +86,7 @@ torch.cuda.set_sync_debug_mode("warn")
 This does not depend on where the GPU is, so it can be measured on any CUDA device, including a Colab runtime. Under `host="local"`, `letify.remoting.device.current_client().stats` counts it for you: `round_trips` is `k` and `ops` is `n`. With `k` measured and the round trip measured, the formula gives you a real answer instead of an estimate.
 
 ```bash
-letify probe gpu.lab.example.edu     # round trip, and whether forwarding is possible
+ping -c 5 gpu.lab.example.edu        # round trip
 ```
 
 ## Tuning `k` down

{letify-2.8.6 → letify-2.8.7}/docs/guide/06-cost.md

@@ -148,7 +148,7 @@ Colab figures assume the 600 credit pack at 49.99 USD, which is about 0.083 USD
 ## Checking before you spend
 
 ```bash
-letify probe gpu.lab.example.edu     # round trip, and whether forwarding is viable
+ping -c 5 gpu.lab.example.edu        # round trip, which sets what forwarding costs
 letify check lab_a100                # does the machine answer at all?
 letify login shell lab_a100          # declare the machine before spending on it
 letify usage                         # what is left on each account

{letify-2.8.6 → letify-2.8.7}/docs/guide/07-troubleshooting.md

@@ -242,7 +242,7 @@ Pulling 20 GB from a bucket next to the runtime is 40 to 60 seconds against 27 m
 If `host="local"`, you are forwarding PyTorch operators and paying a round trip per host synchronization. Measure both terms:
 
 ```bash
-letify probe gpu.lab.example.edu
+ping -c 5 gpu.lab.example.edu
 ```
 
 ```python

{letify-2.8.6 → letify-2.8.7}/docs/guide/08-releasing.md

@@ -1,6 +1,6 @@
 # Releasing
 
-A release is one version number pushed as the tag `v<version>`. GitHub Actions builds everything and attaches it to a GitHub Release.
+A release is one version number pushed as the tag `v<version>`. GitHub Actions builds everything, attaches it to a GitHub Release and publishes the crate `letify` to crates.io.
 
 ## The version rule
 
@@ -24,7 +24,7 @@ The `ci` workflow runs `check` on every push and pull request.
    git commit -am "Chore: Set the version to 1.2.0"
    ```
 
-2. Bring the commit to `main` as usual, then tag that commit and push the tag:
+2. Tag that commit on `develop` and push the tag. The crates.io workflow refuses a tag whose commit is not in `develop`'s history:
 
    ```
    git tag v1.2.0
@@ -38,6 +38,17 @@ The `ci` workflow runs `check` on every push and pull request.
 
 4. It creates the GitHub Release `v1.2.0` with all of those files attached, and uploads the sdist and wheels to PyPI through trusted publishing.
 
+5. The `publish-crates` workflow runs on the same tag. Its `verify` job checks the version files, that the tagged commit is on `develop`, the workspace build and tests, and `cargo publish -p letify --dry-run`. Its `publish-crate` job then uploads the crate `letify` 1.2.0 to crates.io. If that version is already there, the job says so and succeeds without uploading. crates.io never replaces a version, so a wrong upload can only be yanked.
+
+## One-time setup for crates.io
+
+1. On crates.io, create an API token with the scopes `publish-new` and `publish-update`, limited to the crate patterns `letify` and `letify-*`.
+2. In the GitHub repository settings, create an environment named `crates-io`.
+3. Add the token to that environment as the secret `CARGO_REGISTRY_TOKEN`.
+4. Optionally add a required reviewer to the environment, so each crates.io upload waits for an approval.
+
+A tag pushed before step 3 passes `verify` and fails at the upload with a message naming the missing secret. Nothing is published.
+
 A failed run publishes nothing to the Release. Fix the cause, delete the tag with `git push origin :v1.2.0`, and tag again.
 
 ## Installing the extension from a release

{letify-2.8.6 → letify-2.8.7}/docs/guide/ko/03-/354/213/244/355/226/211-/353/260/251/354/213/235.md

@@ -86,7 +86,7 @@ torch.cuda.set_sync_debug_mode("warn")
 GPU가 어디 있는지와 무관하므로 Colab 런타임을 포함해 어떤 CUDA 장치에서도 잴 수 있습니다. `host="local"`에서는 `letify.remoting.device.current_client().stats`가 대신 셉니다. `round_trips`가 `k`이고 `ops`가 `n`입니다. `k`와 왕복을 둘 다 재면 계산식이 추정이 아니라 실제 답을 줍니다.
 
 ```bash
-letify probe gpu.lab.example.edu     # 왕복과 중계 가능 여부
+ping -c 5 gpu.lab.example.edu        # 왕복
 ```
 
 ## `k`를 줄이기

{letify-2.8.6 → letify-2.8.7}/docs/guide/ko/06-/353/271/204/354/232/251.md

@@ -142,7 +142,7 @@ Colab 수치는 49.99달러 600 크레딧 팩 기준으로 크레딧당 약 0.08
 ## 쓰기 전에 확인하기
 
 ```bash
-letify probe gpu.lab.example.edu     # 왕복, 그리고 중계가 쓸 만한지
+ping -c 5 gpu.lab.example.edu        # 왕복, 중계 비용을 정합니다
 letify login shell lab_a100          # 돈을 쓰기 전에 머신을 먼저 등록
 letify usage                         # 계정마다 남은 사용량
 letify utilization                   # 선언된 GPU가 지금 얼마나 바쁜가

{letify-2.8.6 → letify-2.8.7}/docs/guide/ko/07-/353/254/270/354/240/234-/355/225/264/352/262/260.md

@@ -242,7 +242,7 @@ def train(lr): ...
 `host="local"`이면 PyTorch 연산을 중계하고 있고 동기화마다 왕복을 내고 있습니다. 두 항을 모두 재세요.
 
 ```bash
-letify probe gpu.lab.example.edu
+ping -c 5 gpu.lab.example.edu
 ```
 
 ```python