Local models and services.

Studio can call supported services such as Ollama, ComfyUI, Blender, and Kaitoi Runtime on your hardware. The browser, the local service, and the connection between that service and Studio each have their own status.

#Locate the failing layer

The host running the work needs a service process, model and dependencies, plus an installed Runtime recipe when used. The supported connection process makes that host reachable while it remains active. Studio then needs the corresponding integration and node contract. A local failure points to the service or hardware; an unreachable working service points to the connection; a missing operation points to recipe or interface setup. Code’s local model choice is separate from Studio connectivity.

The machine cutaway keeps hardware, the running service, installed model and optional recipe in their proper places. The selected probe highlights service, connection or operation setup without claiming the other layers passed.

#Prepare the service

Install the service and the models or packages it needs. Run a small job in the service itself before introducing Studio. Check available memory, device support, and the model's own requirements.

For Runtime, an installed recipe defines how code or a model runs, including inputs, outputs, and dependencies. Read Recipes and the local runtime for the complete recipe-to-node workflow.

#Connect it to Studio

Use Kaitoi CLI's supported connection flow for the service. For the combined Runtime path, kaitoi up starts Runtime and its connection; kaitoi status reports their state. Keep the connection process running while Studio needs it.

In Studio, confirm the corresponding integration is configured and its node can find the expected service or installed recipe. A model file on disk alone does not make a usable node appear automatically.

#Work on another machine

The service can be on your own computer or a supported remote GPU machine. Use the documented connection workflow on the machine that actually runs it. The connection and service credentials still need protection; avoid exposing a raw service port publicly as a shortcut.

#Diagnose the correct layer

• If the model fails locally, fix the service, dependencies, or hardware first.
• If the service works locally but Studio cannot reach it, check login and the connection process.
• If Studio reaches Runtime but cannot find a recipe, check that it was installed and that its declared inputs match the node.

Local execution can still have hardware, rental, download, and other service costs. Generating a recipe with an AI provider is separate from running its resulting code locally.

#Check three independent states

Service: verify the process, model, device and dependencies on its own host. Connection: keep the supported connection process active and inspect Studio's service settings. Recipe/node: verify the installed operation and its input/output contract. CLI local model selection is separate from a Studio service connection.

#Checks and next steps

Treat the service process, its connection to Kaitoi, and the selected node or recipe as separate checks. A running process can still lack a model; a connected Runtime can still lack the recipe or dependency the node expects. Use the service-specific settings in Settings → Integrations and the current CLI connection status to locate the failing layer.

CLI model inference and Studio service access are separate workflows. Choosing a local model for Kaitoi Code does not automatically connect Studio to that model server. Likewise, a Runtime recipe is not automatically a general assistant model. See Hosted and local models and Connect local services for the respective setup.

A local-runtime icon is not a promise that every related operation has zero credits or costs: provider calls, community prices, configured platform fees, hardware and rentals are separate. Check the operation's actual requirements.