Versely
    AI Models

    Picking the chat model behind the agent

    The chat model plans; the generate model renders. Change chat_model to pick the brain, and pin generate models separately when the clip has to match.

    Versely Team••7 min read

    The model that decides what to generate is not the model that renders the frame. Chat models live on GET /api/v1/agentic/chat-models. Generation models live on GET /api/v1/agentic/models and on the public catalog. Swap the first and the agent plans, talks, and picks tools differently. The MP4 still comes from whichever video model the generate tool was told to use. Mix those two knobs up and you will think a new chat model "changed the look" when a router quietly picked a different renderer.

    If the clip has to match last month's ad, pin the generate model in the brief. If the planning is sloppy or slow, change chat_model.

    Two catalogs, two jobs

    The chat list is the agent's brain. Each entry has id, name, description, provider. The payload also has default, which is currently runpod/kimi-k2.7-code (Kimi K2.7 Code). The app seeds its picker from that default and only falls back when chat_model is omitted or unknown. Treat GET /chat-models as the live list; do not hard-code a roster from a blog post.

    The generate list is the renderer. Image, video, image-to-video, audio, the whole production catalog. The agent fills a required models argument on generate tools either with a name you gave it or with a routed pick. That is a separate decision, covered properly in agent routing versus pinning the model yourself.

    Custom brains are allowed. If chat_model is not in the built-in map but looks like org/model, it is treated as a custom OpenRouter model. Those also show up on /chat-models when you have saved them, tagged provider: "openrouter". Duplicate ids (a custom row that repeats a built-in) are dropped so clients that key on id never see the same model twice.

    A lasting preference is the right place to store "always plan with this brain" if you are working in the app rather than passing the field every call. It still does not pin the renderer.

    How the pick is sent

    Both POST /api/v1/agentic/chat and POST /api/v1/agentic/chat/stream accept chat_model. Send the id from /chat-models, not the marketing name.

    Also send chat_model_explicit: true when the value is a choice, not a leftover default. Several domain sub-agents are allowed to run on a faster stand-in (on the OpenRouter path that stand-in is Claude Haiku 4.5 unless you override the env). Mechanical domains (generation, slideshow, social, the web editor) are eligible. Workflow scene-directing and movie planning are not: they keep the chat model you picked, because the quality of the plan is the job.

    That stand-in is OpenRouter-only. The default RunPod Kimi is not swapped for Haiku. If you picked an OpenRouter brain and omitted the flag, a fast-eligible sub-agent may run on Haiku while the picker still shows the OpenRouter id. The generate model is untouched either way. The web chat sets chat_model_explicit when the user actually selected a model. A raw API client has to set it itself.

    Chat tokens and generations bill on two meters. The done event (and the blocking JSON) return credits_used for the reasoner and generation_credits_used for the renders. Changing brains changes the first number. It does not change what a text-to-video call costs once a renderer is named. Both cost credits; there is no free chat allowance. Pricing is the live tariff.

    Vision, attachments, and text-only brains

    Not every chat model accepts image parts. Several built-ins are text-only: the GLM 5 family, MiniMax M2.7, Qwen3 Max Thinking, the MiMo line, DeepSeek V4 Pro, and the RunPod-hosted Kimi ids (including the default, Kimi K2.7 Code). Send an image to those and the provider 404s on the image part.

    The practical rule:

    • You are attaching stills, frames, or a screenshot of the thing to edit. Pick a vision-capable brain. The live /chat-models list does not return a vision field; from the built-in registry, Gemini 3.1 Pro, the Claude ids, Grok 4.3, OpenRouter Kimi K2.5 / K2.6 / K3, and Qwen3.5 397B accept image parts. The text-only ids listed above do not.
    • You are attaching video or audio and the selected brain is not Gemini. The server pre-processes that attachment through Gemini and injects an understanding into the prompt so a text-only (or non-Gemini) brain can still act. You do not have to pick Gemini just to describe a clip. You do have to pick a vision model if the image is the brief.
    • No attachments, lots of tool use. The default is a reasonable start. Switch if the planner is dropping arguments or over-calling tools, not because you dislike the stills. The stills are the renderer.

    Gemini 3.1 Pro is the native Google entry. Claude ids are served via OpenRouter. RunPod Kimi and OpenRouter Kimi K3 are different ids on purpose: different endpoints, and the RunPod pair is text-only. Do not copy the name from one and send the other.

    Change the brain without changing the look

    A prompt that keeps the two knobs apart:

    Use this chat model for planning. Do not change the video model. Generate with Kling 3 Turbo, 5s, 9:16, locked-off bottle on wet stone. If you need to look up allowed durations, call the schema tool, then generate. Do not substitute a different renderer.

    That message does two jobs. chat_model on the request selects the planner. The named renderer in the body selects the pixels. If you omit the second sentence, a newly clever brain may "help" by routing to a different family, and you will blame the chat model for a look shift it did not render.

    When you are exploring looks, let generate routing work and keep the brain stable, so the variable is the renderer. When you are exploring planners (did this model actually pass aspect_ratio? did it spawn instead of blocking?), keep the renderer named and swap chat_model.

    The agent still loads the same extras regardless of brain: brand kit, memories, conversation media library, workflow summary, in-flight tasks. A "dumber" model with a precise brief often beats a flagship model with "make me an ad." The agent is the surface; the brain is a parameter on it.

    FAQ

    Will changing the chat model change my next clip's look?

    Only if the new brain picks a different generate model than the last one did. Pin the renderer in the brief (or in a saved workflow) if matching matters. The chat model changes planning, tool use, and the text reply.

    Where is the live list?

    GET /api/v1/agentic/chat-models. Use those id values in chat_model. The default field is what the server uses when you send nothing. Custom OpenRouter rows you saved are appended, minus id collisions with built-ins.

    Why did a sub-agent ignore the model I picked?

    The request likely omitted chat_model_explicit: true on an OpenRouter brain, so a fast-eligible domain (generation, slideshow, social, web editor) was allowed to run on Haiku. Set the flag when the picker value is a real choice. The default RunPod Kimi is not swapped. Workflow and movie planning do not take that stand-in.

    Can I use a text-only model if I attach a photo?

    Not for the image itself. Text-only ids 404 on image parts. Pick a vision-capable chat model, or put the visual brief in text and skip the attachment. Video and audio attachments are pre-processed for non-Gemini brains, which is a different path.