surface

Install and run recipes.

Find recipes, inspect requirements, install and run them with declared inputs, and connect their outputs to Studio while keeping local and cloud files distinct.

Written for
Users running packaged tools on their own machine.
You need
Any plan to connect Runtime to Studio; Studio or Enterprise for Kaitoi Code node authoring; Kaitoi Runtime installed and hardware suitable for the chosen recipe

For setup and updates, see Install and update. Check kaitoi --version and use kaitoi code --help to confirm available commands. Older builds may interpret unsupported code acp or code serve commands as model prompts.

A Runtime recipe packages a tool's installation, inputs, execution, and output collection. Local Runtime commands do not universally require platform login; account, tunnel, and managed generation features have separate authentication requirements.

Find and inspect a recipe

kaitoi runtime list --search text
kaitoi runtime hardware
kaitoi runtime info ./recipe.yaml
kaitoi runtime validate ./recipe.yaml

list searches available registry recipes. packages lists packages already installed on this machine. A recipe can resolve from a registry name or a local path. Inspect its inputs, outputs, source, backend, dependencies, and hardware requirements before installing it.

Schema validation does not prove that dependencies can be downloaded, the machine has enough memory, or execution will succeed. Installation and running can download code, dependencies, and model weights. Authored recipe code can also call external paid services.

Install and run with the declared inputs

For the message input in the example recipe:

kaitoi runtime install ./recipe.yaml
kaitoi runtime packages
kaitoi runtime run ./recipe.yaml --message "Hello"

Use the input names defined by that recipe; there is no universal --prompt or JSON-stdin input contract. Hyphens normalize to underscores, and declared numeric or boolean inputs coerce compatible strings. A bare input flag becomes the string true before coercion. Avoid collisions with Runtime's own options.

Available recipes, installed packages, and a run's outputs are three different things.

The registry is a catalog. Installing a recipe prepares a local package and its dependencies. A run supplies the package's declared inputs and produces output files. Listing a recipe does not mean it is installed, and installation does not mean an execution has passed. Studio can use a connected Runtime and a reviewed user node to call it.

The authored hello-text package declares a message input. The example “Bring a book. Share a story.” appears unchanged in its local result.txt output; this does not claim that a catalog item was installed or run.

run installs the recipe first when needed. It supports backend selection, force-reinstall, timeout, verbose output, and an output directory. install supports --backend NAME and --force. Use the command's --help for the exact options in your installed version, and choose force reinstall only when intended.

Inspect and keep the outputs

Review the result, stderr, and actual output files. Runtime file output values are machine paths, not hosted Kaitoi file IDs. The output-directory option copies results for convenience; it does not upload them to the cloud library. A schema or installation success is a different milestone from a successful run with the expected content.

Kaitoi Code's local.save_runtime_file saves a reported Runtime output into the workspace through the authenticated local Runtime server. Inspect the saved file with local.view_image or the appropriate text/file tool. Runtime's output-directory option is also available for direct CLI runs.

Ask Kaitoi Code to create a recipe

Ask the model selected in Kaitoi Code to find a model, write a local recipe, test it and create a node. It uses normal workspace file tools and deterministic Runtime commands; no second authoring model is called.

The flow searches Hugging Face or reads your GitHub/Hugging Face URL, writes local-name.yaml and its declared companion local-name.py, checks them, then asks before installing. The approval shows both files' hashes and sizes, source and ref, dependencies, weights and known sizes, hardware and remote inputs. Replacing an existing local recipe requires replace=true. The local- prefix is reserved for authored recipes.

kaitoi runtime analyze https://github.com/openai/whisper --json
kaitoi runtime validate ./local-name.yaml --json
kaitoi runtime install ./local-name.yaml --check --json

These local authoring commands add no network routes. Static checks return coded diagnostics; installation reports ok, phase, installKind, failureKind and the real errorTail. A script-only repair reuses its venv and weights. Failed builds/swaps preserve the working installation; unchanged weights are reused during full rebuilds too. Stop or timeout terminates the local install process tree.

After a small test run, the agent saves and inspects the output. It stops on environment limits and reports repeated fixable failures. Review licences and gated-model access first; URL inputs, remote model choices and remote code need explicit consent. HTTP job/install requests accept plain recipe names only.

Node authoring keeps its existing Studio/Enterprise gate. On other plans the flow ends with a working local recipe. On eligible accounts, the agent validates and installs a node, checks the account's Runtime connection with runtime_inspect, then requests a node run through the real tunnel. Installation, local execution and a successful Studio tunnel run are separate verification steps.

Use kaitoi runtime uninstall NAME to remove an installed package when it is no longer needed. Inspect the name in packages first.

Use a recipe from Studio

Connect Runtime, then open Settings → Integrations → Runtime in an account with access to local integrations. Inspect Installed Recipes.

Create Node asks Penny to inspect the recipe and its input/output schema, then build a user node. It is an assisted authoring request, not an immediate, deterministic wrapper. Review and test the proposed node. When a node already exists, its Add to graph action is a separate path.

A generated node may upload input files, call runtime.run_recipe, and download outputs. Those transfers bridge local Runtime files and Studio's own data; the file identities are not interchangeable. Keep the Runtime and tunnel available while the graph needs them.

For a node you author yourself, this body calls the installed hello-text example and reads its text output. It assumes the node declares a message input and text output and receives the injected runtime helper; it is not a complete node definition.

result = runtime.run_recipe("hello-text", {"message": message})
text_files = result.get("outputs", {}).get("text", [])
if not text_files:
    return {"@error": "The recipe did not produce text."}
return {"text": runtime.download_text(text_files[0]).strip()}

Use the recipe's actual input and output names. download_text reads a Runtime file into the node; Code's local.save_runtime_file saves it into your workspace.

Direct Runtime CLI commands execute what you request. Code's model tool calls instead follow its permission settings and saved approvals; there is no blanket rule that every recipe action always shows a permission card.

Turning a repository into a node

Start with Create a recipe, validate and test its outputs locally, then use the Studio Runtime integration to create a node. Connecting Runtime to Studio works on every plan. Kaitoi Code's node-authoring tools require Studio or Enterprise. A direct local recipe run requires no plan.

Connecting local services

Follow Connect local services for Runtime, ComfyUI, Blender or Ollama. Inspect connection status before generating a node.

Last reviewed against Kaitoi on 31 October 2026. View this page as Markdown

Type at least two characters.