Ivy plans, edits, runs your tests and asks before it touches anything. Point it at a model from Hugging Face served by Ollama or vLLM on your own card. 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 "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 | sh
# Windows: irm https://ivy.fightclub.pro/install.ps1 | iexollama pull qwen2.5-coder:32bivy doctor --model qwen2.5-coder:32bcd your-project
ivy --local --model qwen2.5-coder:32bBinaries for Linux, macOS and Windows on amd64 and arm64, with a SHA-256 manifest next to every release. The installer verifies nothing you do not see: it downloads one file and puts it on your path.
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.
ivy --local --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.
We named it for what it does. Ivy is green, like the silicon it runs on. Ivy grows on whatever it is given, which is what a coding agent does with a catalogue of open models. Ivy grows on your own wall, so it does not need a building it does not already have. It is patient, it is hard to get rid of once it has taken hold, and it quietly covers more every month.
That last part is the plan for your token bill.
Three letters, and it reads like a tool that has existed for years.
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.