Any open model on Hugging Face. Your card, your choice, no bill.
Ivy plans, edits, runs your tests and asks before it touches anything. Pull a model from Hugging Face, serve it with Ollama or vLLM on your own card, and point Ivy at it. There is no account and no API bill. Your code and your prompts go to your own endpoint and nowhere else, unless you ask the agent to fetch something from the web.
Want a frontier model for the hard part? Drop the flag and the same agent uses hosted ones instead.
Ivy is the plant that runs on whatever structure is already standing. It does not need a building of its own; it climbs the wall you have. Once it has taken hold it covers a little more every season, with nobody tending it. The agent works the same way. It grows on the GPU you already own and on the open models already published, and every month it takes over a little more of the work that used to go to a metered API. And it is green. That was not an accident.
ivy "add rate limiting to the login endpoint"Frontier models through the platform, with the worker fleet, memory sync and skills that come with a Knockout account. This is Knockout, under a name that also fits the other mode.
ivy --local --model qwen2.5-coder:32b
ivy --endpoint http://gpu.internal:8000/v1 --model qwen2.5-coder-32b--local talks to Ollama on this machine. --ollama is the same switch. --endpoint points it at vLLM on a LAN box, or at anything that speaks the OpenAI chat API. Nothing else changes: same tools, same terminal, same permission prompts.
curl -fsSL https://ivy.fightclub.pro/install.sh | shmacOS, Linux and Windows, with the model setup for Ollama and vLLM, the checksum step and the air-gapped route, on the install page.
A 32B model on one card is not a frontier model, and an agent written for frontier models falls over the first time a local one fumbles a tool call. Ivy was built knowing that.
--model qwen2.5-coder:32b,deepseek-coder-v2The first is the one Ivy trusts. The others give a second opinion on the plan in the full pipeline, and the first judges between them.
No per-step model tiering. Hosted mode picks a model size per step from a catalogue. Local mode has no catalogue, so a step runs the model you named. A list of models is the tiering you get: the first runs everything and the rest join the plan step.
No memory sync, RAG stores, Brain, worker fleet or MCP serving. Those are platform services. Local sessions, memory files and edit snapshots live under .ivy in your project, in plain text, on your machine.
Web tools still reach the internet. WebFetch and WebSearch work in local mode when the agent decides to use them. On an air-gapped box they fail, nothing more. Nothing else in local mode makes an outbound connection except your endpoint.
Tool calling is required. A model served without a tool-calling template cannot drive Ivy, however good it is at prose. Run doctor.
Ollama's default context is 4k. That truncates the agent's prompt and the model starts improvising. Raise it to 32k. The manual shows how.
Ollama for a laptop. vLLM for a GPU box, with --enable-auto-tool-choice and the right tool parser. llama.cpp server, LM Studio, TGI, SGLang and NIM containers all expose the same endpoint. If curl $ENDPOINT/models answers and the model does tool calling, Ivy runs on it.