Choose a model for your project

CLIO Coder lets you choose the model connection around your project. Start with the place your code is allowed to go, then choose a model and runtime that can do the task. A local GPU, a model server, an institutional gateway, and a cloud API are different deployment choices.

If you already connected a model, skip to Separate conversation from worker models below.

Decide where inference may run

On first setup, Guided setup asks what you have. Choose by where the model input may go, then by what you already run.

When setup finds a route first, such as a provider key in your environment or a model server on a default local port, it lists that route before asking. A subscription-backed route has its own authentication and usage conditions; it is not interchangeable with an API account. The connection guide covers each route.

Connect one model

1. 01

   Install CLIO Coder

   Shell

   curl -fsSL https://coder.iowarp.ai/install.sh | sh
   cd /path/to/your/project

2. 02

   Start guided setup

   Shell

   clio-coder configure

   Choose Guided setup. The desktop alpha offers the same wizard after clio-coder gui --open. In a terminal session, /config opens your connections, where Add a target runs the wizard without leaving the session.

3. 03

   Pick the route and the model

   Answer what you have, then provide the key, sign-in, or server address it asks for. Setup takes the provider's recommended model, or the only model a server lists; otherwise you pick from the list. For a local server with no models, load one and choose Check again.

4. 04

   Test the connection, then save

   Setup sends the model one short test request and saves when it answers. After a failure you can try again, change the key or address, or choose Save anyway. The first connection supplies the chat and worker defaults, and /model changes the model later.

Ask one question you can check

Read the tool activity and compare the answer with the project. If it fails, check the endpoint, the loaded model, the credentials, and the selected runtime before giving it a larger assignment. clio-coder doctor provides diagnostics; it does not certify model quality.

Separate conversation from worker models

The model answering you need not handle every delegated task. The terminal /settings groups its rows into seven areas below Recent & Pinned, with the conversation model under Models and worker defaults under Workers.

clio-coder configure --settings opens the shell menu, which uses eight sections instead: the conversation model is under Chat and worker defaults under Fleet. On the desktop, Settings has a Models page and a Fleet routes tab. Select a connection and model for conversation, then use worker defaults or profiles for delegated work.

This helps when exploring a repository and changing code have different requirements, or when you want to keep a workflow while evaluating another model. The benefit depends on the task and environment; this guide makes no claim that a particular combination is cheaper or faster.

A worker running on your machine against a remote model server is still a local worker: inference and tool execution are separate choices. To run the worker process on another machine, use the fleet configuration.

Choose capabilities deliberately

CLIO Coder supports more than one kind of model interaction. Its Inception runtime serves Mercury diffusion language models as chat models with tool calling. Optional, experimental System One routes answer typed questions an agent asks through consult. Neither replaces a chat model or is required to get started.

Vision support depends on the model and the route. A model advertised as multimodal is not enough if the bridge does not carry images: the managed Codex, Pi, OpenCode, Claude Code, and Antigravity CLI bridges are text-only. Check what the route accepts before attaching a screenshot.