--- name: inference description: Discover, deploy, modify and run open-weight models on Cagoule as Modelpack apps. Use when the user wants a model, LoRA, generated media, or a variant of an existing deployment. --- Use the bundled Cagoule MCP tools. The same binary is the `cagoule` command line (`brew install anorak-games/cagoule/cagoule`); when the user wants to work outside the agent, `cagoule deploy DIR`, `cagoule run APP --input JSON` and `cagoule logs` do what the tools below do, sharing the same login. On first use call connection_status; if authentication_required, call connect once and poll connection_status while the employee signs in with their Anorak Google account. Do not request tokens or credentials. An access_denied result needs administrator attention; do not repeatedly reopen sign-in. An app is a directory containing `modelpack.yml`. That one file declares everything: name, short description, inline Markdown long_description and usage, tags, base_model family, source_url for the implementation repository, the platform stack family, the build command, the command that serves requests, machine types and memory, the Hugging Face volumes it reads, and JSON Schemas for inputs and outputs. The platform derives every deployment setting from it; there is no separate recipe, and the platform does not keep or export app source. Provide concise listing text, factual model capabilities, and practical usage guidance in the manifest. Use a stable family such as h3 or ltx for base_model; source_url links to the implementation repository or subdirectory. Weight repositories and pinned revisions belong in volumes. Treat the directory like any application: it belongs in a repository the user controls. 1. Read platform_capabilities and list_apps. Follow next_cursor even when a filtered page is empty. describe_app returns the current revision including its generated definition and input/output schemas; there is one generate tool for all models. 2. For a new model, search_huggingface and inspect_huggingface to choose files. Prefer weights the platform has already replicated: inspect_huggingface returns a `replicated` list for the repository and list_volumes shows every replicated selection with the apps using it; pinning one of those revisions with the same or a subset of its files publishes in minutes and adds no storage, so only pin a new revision when the model needs it. Then create_app_project with an absolute new directory, an explicit stack family from platform_capabilities (for example python312-pytorch290-cu130), a machine type and runtime memory. It scaffolds `modelpack.yml`, `app.py`, the vendored `modelpack_protocol.py`, `pyproject.toml` and `.inferignore`. For a variant of an existing app, work from that app's source repository: copy the directory, change `name` in `modelpack.yml`, and edit from there. 3. Edit `modelpack.yml`. Under `volumes`, declare each Hugging Face repository with its full commit SHA and the exact `files` the model opens, as paths or `**` patterns; nothing else exists at `/volumes/` on the worker, and a pattern matching no file fails publication. Put structural validation in the `inputs` and `outputs` schemas; `default` is a hint for user interfaces and is never applied, so model code owns fallbacks. Keep `machine_types` in preference order and set `runtime_memory_gib` to peak host memory beyond weights, package and stack. Declare Python dependencies in `pyproject.toml`; torch and CUDA come from the stack, and the built package must stay under 2 GiB. 4. Implement `app.py` against the protocol helper: `setup(context)` loads the model from `context["volumes"]` onto `context["device"]` and returns state; `run(state, input, output_dir)` returns the output object and writes files under `output_dir`, naming them in the output by relative path; `teardown(state)` releases the model. Input arrives exactly as submitted after schema validation. Printing to stdout or stderr is fine; both are request logs. Base weights and LoRAs are ordinary separate volumes, such as `base` and `lora`; loading them is model-specific code. 5. validate_manifest on the directory, then package_app with execution="remote" and a unique operation name. Poll get_package_job until ready or failed; read_package_logs provides diagnostics. Publish the resulting artifact_url with publish_package, then poll describe_app until the revision is ready or failed. Publication replicates the package and synchronizes every declared volume to all regions before the revision becomes ready; list_volumes and describe_volume show that progress and any sync error. A failed publication preserves the previous ready revision. Preflight checks configuration against the hourly hardware catalog, not live GPU capacity or successful inference; if a zone catalog is temporarily unavailable, allow it to populate rather than launching inference to bypass it. 6. Run a small generation against the exact ready revision using its input schema. Give generate a unique operation name. Reuse that operation after an interrupted call; choose a new one for an intentional repeat. Upload local inputs with upload_input. It returns a renewable URL the API refreshes on submission. 7. Poll get_request. Use read_package_logs for packaging failures and read_logs for runtime failures, following its cursor; logs flush periodically. Fix, rebuild and republish as necessary; any manifest change is a new build. Do not automatically retry inference. cancel_request stops cloud work; disconnect only clears device login. Client restarts do not cancel work: recover using app/revision, request history and the same generation operation. 8. Return app name, reproducible revision, request ID, renewable result links and local paths from download_output. Never put binary contents in text context. Omit `tmp_memory_gib` for the default 4 GiB memory-backed `/tmp`. Increase it for large temporary intermediates such as decoded frames; it must stay within `runtime_memory_gib`, alongside CPU tensors and other working memory. Capacity does not preallocate RAM. Stack names identify fixed runtime families; revisions provide compatible maintenance within a family, and apps always run on the family's current revision. Select another stack explicitly to change core runtime versions. Use remote packaging; employees need no local Python, Go, Docker or Google CLI. Keep existing Terraform-managed models unchanged. No Terraform execution, fleet administration, private/gated repositories, training, multi-node execution, streaming generation or promotion workflow.