[outofcoffee]

Run a model too big for your laptop on a cloud GPU that only exists while you are using it, driven by the same Outfit file you would use locally.

Summary

• Adds an outfit remote command group — start, stop, status and deploy — targeting the scale-to-zero endpoint the companion cloud-vm-llm project deploys. It drives that endpoint; it does not create it.
• Adds a REMOTE Outfit instruction naming the file holding the endpoint's control URLs, resolved relative to the Outfit like PRESET, so a project can carry its own endpoint. Without one, a per-user config is used, so the commands still work outside a project.
• outfit remote deploy derives what to serve from the Outfit and its preset: PROVIDER picks the engine, MODEL or the preset's hf names the weights, CONTEXT the window, ALIAS the served name, and the preset's remaining flags the engine's arguments.
• Adds a vllm provider to the catalogue, so both self-hostable engines can be named by PROVIDER and switching between them is a one-line edit.
• Adds an apiKeyOptional catalogue flag for a provider that works both unauthenticated and authenticated, and marks llamacpp with it — without which applying a remote llama.cpp Outfit produced a keyless config that 401s.
• Teaches tab completion about nested commands, so outfit remote <TAB> offers its subcommands.
• Documents the command in the user manual, and records the specification delta as the OpenSpec change add-remote-endpoint-control.

Additive throughout: an Outfit without REMOTE behaves exactly as before, and no existing command changes behaviour.

Implementation details

PROVIDER names the engine; there is deliberately no RUNNER keyword. An Outfit already says llamacpp, and outfit serve already runs llama.cpp from it — the remote case is the same statement pointed at another machine. A separate keyword would allow PROVIDER llamacpp alongside RUNNER vllm, a contradiction worth making unrepresentable. The cost is that a hosted provider cannot be deployed, which is reported as an error rather than left as a gap.

The deploy payload describes intent, not storage. It carries the engine, model, quantisation, context, served name and flags — and deliberately no storage location. The endpoint derives its own layout and fetches missing weights itself, so a change to that layout never becomes an outfit release.

One preset serves locally and deploys unchanged. Rather than a second list of remote flags, the existing preset is reused with the settings the endpoint owns (host, port, model location, API key, context, alias, metrics) removed. Two subtleties this forced: flags must be matched after alias resolution, since ngl and n-gpu-layers are the same setting, and a preset's [*] defaults are a separate layer that must be merged — missing it silently dropped ngl and jinja, which would have served the model on CPU with no tool calling.

internal/remote is the only package that reaches the network or touches AWS. It brings the first non-stdlib runtime dependency outside YAML parsing, and is reached only by this command group; every other command still runs offline with no credentials. Requests are signed with the caller's own AWS chain and need only lambda:InvokeFunctionUrl. deploy is the first request with a body, so the signature covers the payload hash and Content-Length computed from the exact bytes sent.

deploy_url is optional. A config written before deploy existed still works for the other three subcommands; only deploy complains, and it says what to add.

apiKeyOptional exists because adding the key variable alone regressed local use. The Pi harness writes a $VAR reference it resolves at run time, so a keyless local server would have received a reference to an unset variable — which makes Pi hide the provider's models. Falling back to the placeholder globally was not an option either, since for other providers that reference is deliberately resolved later. The flag marks the one case where an unset variable genuinely means "no key".

Also in this PR

• The deployment itself, under remote/: the CDK application that outfit remote drives — an endpoint holding no instance until asked for one, launching into whichever zone has GPU capacity, and terminating itself once unused. Weights live in object storage at a location derived from engine, model and quantisation, fetched automatically when absent.
• start reports progress. The endpoint blocks until the model is serving, so a cold start used to sit silent for minutes. Progress goes to stderr and only the exports to stdout, so eval "$(outfit remote start)" needs no filtering.
• Keys are never written to disk. opencode's config carries an {env:VAR} reference rather than the secret, matching how Pi has always worked, and outfit harness passes the keys it can resolve to the agent it launches. A .env is read beside the Outfit being applied — it previously resolved through a build-machine path an installed binary could never find.
• Applying a config that cannot authenticate now says so, instead of succeeding and failing later as a rejected request.
• This repository is public, so no identifier of a deployment may be committed: scripts/check-no-cloud-identifiers.sh fails the build on account ids, ARNs, endpoint hostnames, public addresses, bucket names and resource ids, and runs first in CI.
• CI: a separate Remote deployment workflow typechecks, tests and synthesizes remote/ when it changes.
• Specification: the OpenSpec change is applied to the main specs and archived — four new capabilities (remote-endpoint, endpoint-lifecycle, inference-runners, model-weights) plus the requirements this work altered across seven existing ones.