Proteina-Complexa binder-design remote tool#
TOU validation and deployment status (2026-08-16)#
Proteina-Complexa 1.1.0 (NVIDIA’s flow-matching binder generator – it DESIGNS proteins against a target structure, it does not fold one) ran on the NVIDIA GB10 (aarch64, cc 12.1) with the optimization kit in
fastmode, all six levers engaged. Verified on FOUR CONSECUTIVE IDENTICAL REQUESTS, a mixed-shape sequence (100, 100, 200, 100 residues) and an ascending ladder (100/200/400), plus a sequence that changed the ENGINE KEY (num_steps, batch size, binder length, the target, the seed) and returned to the first request, which reproduced byte for byte. The held worker’s design for the smoke target is byte-identical to the kit’s ownrun.sh designin a fresh process, and to a worker built from the lock in an empty venv. Per-request peak reserved runs from 1.70 GiB (100 residues) to 20.25 GiB at the ceiling corner, which is the declared budget. One thing to know before deploying: torch 2.7.0+cu128’s NVRTC does not know this card, and without the pinned 12.9 NVRTC every request dies intorch.prod(see the environment section). Public publication, cross-user isolation, concurrency, recovery and design quality (binding, designability) are unvalidated; keep this deployment private.
Operation:
complexa_design_binderStart:
python -m tooluniverse.remote.complexa.complexa_toolEndpoint:
http://127.0.0.1:8056/mcpProvider configuration: this provider is on the remote-tool standard, so the model runs in its own environment built from a pinned lock, and the weights are declared with a size and a sha256 and verified before the worker starts. Keep provider data, weights, caches and credentials outside Git. Use one worker: the resident worker serves one request at a time by design, and a second in-flight request queues on its lock rather than doubling peak VRAM. The measured VRAM budget is 20.25 GiB; read the envelope it was measured at in the manifest before co-tenanting anything else on the card, because a larger request exceeds it.
TOU check:
tu doctor --forward http://127.0.0.1:8056/mcp --jsonPrivate relay:
tu serve --share --forward http://127.0.0.1:8056/mcp --name validation-complexa --workers 1
Non-loopback binding requires TOOLUNIVERSE_API_TOKEN; otherwise keep the
server on loopback. The relay requires TOOLUNIVERSE_SERVICE_KEY. Public
publication and independent-caller testing were not run.
New-user check: python scripts/remote_validation/setup_skill_preflight.py --implementation complexa. Add --check-provider-env before launch, --live
after launch, and --check-connect-prereqs before sharing. Live preflight
checks exact MCP discovery only; it does not run or validate a model.
The authenticated 2026-08-16 Platform matrix found all 30 private owner relays
online and all 41 operations discoverable. It imported each implementation as
unpublished owner draft(s), configured a 120-second timeout, and invoked it
through /expert-sessions/{id}/test. This implementation was added after
that matrix and was not part of it, so none of that evidence covers it: it has
not been exercised through the Platform at all, and everything above was
measured locally, on one card, through the loopback endpoint. Public
publication, independent-caller authorization/isolation, broad saturation and
persistent supervision are unvalidated here.
Overview#
Proteina-Complexa de novo binder design: generate binder backbones and sequences against a target structure and hotspot residues
Weights and kit are pinned: src/tooluniverse/remote/complexa/provider.toml
declares the upstream kit by commit, the environment by lock file, and every
weight file with its byte count and digest. Nothing is fetched at request time.
The measured peak VRAM for this host is written to
~/.cache/tooluniverse/measured/complexa.json, and that per-host file – not the
number in the manifest – is what a scheduler should read.