Guide · October 16, 2026 · Updated October 18, 2026 · 6 min read

Choose your parts

AI work runs on more than a model. It runs on tools, skills, approvals and helper models too. When you can swap each part on its own, your setup gets better as you learn, and no single provider decides what you can use.

An AI setup is a set of parts

When people talk about “the AI”, they usually mean the model: the program that reads text and writes a reply. Useful work needs more than that. A working setup has several parts around the model:

The model. It runs on your own computer or on a provider’s servers, and it does the reasoning.
Instructions. Standing text that tells the model what job it is doing and how.
Tools. Actions the model can ask for, such as reading a file, running a command or searching the web.
Skills. Written procedures, like a deploy checklist or your house style, that the model loads when a task needs them.
Approvals. Rules for which actions run on their own and which wait for you.
Helper models. Second models that take a share of the work: a first draft, the summary of a long chat, the description of an image.
The record. What was sent, what ran and what it cost.

Each part answers its own question. The model decides how well the work is reasoned. Tools decide what it can reach. Approvals decide what it may do without you. When all of these come welded into one product, you cannot swap one answer without accepting all the others.

One runtime, parts you choose. Swapping a dashed part leaves the others, and the shared folder, gate and record, as they were.

Why the parts should be separate

Each part moves on its own schedule. New models arrive every few months, and prices move with them. The best model for code review this spring may be the expensive choice by autumn. Your work shifts too. A project that began as quick questions can grow into nightly jobs that nobody watches.

If the parts are fixed together, every one of those updates means starting again: a new app, a new tool setup, new permissions and a lost history. If the parts are separate, the fix stays small. You swap the model for one job and keep everything else.

The point is not to swap parts all the time. It is to make each swap cheap, so the good ones actually get made.

Model-agnostic means you are not locked in

A system is model-agnostic when the rest of it does not depend on which model is answering. Kaptain reaches models four ways and treats them alike:

Local models through Ollama, a local model runner that downloads and serves open models on your machine.
GGUF model files, the file format of models run by llama.cpp, served by its llama-server.
Cloud APIs with your own key: OpenAI, Google Gemini, DeepSeek, Groq, Mistral, Together AI, OpenRouter, or any endpoint that speaks the OpenAI chat-completions format.
The Claude Code and Codex command-line assistants you already sign in to. Kaptain drives them as models, on your own subscription.

A fifth source is another of your computers. Once two Kaptains are paired, the other machine’s models appear in your picker under its name.

Every route works in chat, in kapsules (Kaptain’s agents), as the delegation worker and as the summarizer. They all share one set of tools, one approval gate, one record of what ran and one project folder that you choose.

That is what keeps you free. If a provider raises its prices, changes its terms or falls behind, you move the jobs it was doing to another model. Your tools, skills, agents and history stay where they were: on your machine.

No model is chosen for you. In a fresh browser the chat picker reads Choose a model, and delegation has no worker until you pick one under Settings › Model Handling › Delegation.

Tune one part, leave the rest alone

Choosing a model is the first decision. Deciding how it runs is the second. In Kaptain each part has its own control:

Per model. The ⚙ next to the model picker opens Model settings for the selected model: Thinking, Context window, Max output, Tool approval, Tool calls, and Reasoning effort where the model declares effort levels. Settings are saved per model and used from the next message.
Per job. Settings › Model Handling names the models for supporting work: the Worker model for delegated briefs, the Summarizer that folds the older messages of a long chat into a summary, and the Vision tool model that describes images for models that cannot see them.
Per tool. Krew › Native Tools gives every built-in tool its own switch.
Per agent. Each kapsule has its own model, tools, permissions and skills.

You can even switch the model in the middle of a conversation. When a chat moves off Claude Code or Codex to another model, Kaptain hands over a digest of it. Handoff written by, under Settings › Model Handling › Context & Compaction, sets who writes that digest.

Here is one set of choices these controls allow. You chat with Claude Code for design work. A small local model is the delegation worker, so summaries and log digests use output tokens with no per-token bill. The summarizer is a small model on another of your computers. A nightly kapsule that watches logs runs on a local model too. None of these choices depends on the others, and each can be revisited tomorrow.

Parts that get better with use

Some parts improve because you improve them, and the improvement is kept.

Skills. A skill is a Markdown document with a name, a one-line description and instructions. Models load the full text only when they need it. When you find a better way to do a recurring task, you edit the skill once, and every model that loads it gets the better way. Kaptain finds skills in your project, in its own data folder, in kapsules, and in Claude Code’s and Codex’s own skill folders when that CLI is the model. Type / in a chat to apply one skill to one message.
Lessons. A kapsule can keep short lessons with the remember tool: one-sentence rules, kept only when a run finishes cleanly.
The record. BlackBox shows every turn: the context sent, each tool call and its result, the reply and the tokens. It is how you find which part to improve next.

What does not improve by itself is replayed history. Run memory for scheduled agents is off by default, for a reason Kaptain Docs put plainly: “one bad run steers the next, old evidence reads as current, and the window fills with yesterday.” In Kaptain, getting better is deliberate. It is a skill you edited, a lesson kept after a clean run, or a setting you adjusted after reading a trace.

Parts kept in plain places

A system built this way passes a simple test. When something better arrives, how much do you have to rebuild? The answer should be one setting, one file or one switch.

Kaptain keeps its parts in plain places so that this holds. Settings live in kaptain.json, and per-model settings and API keys in models.db. Each agent is one kapsule.json file you can diff, copy and keep in git. Skills are Markdown files. Your MCP servers are listed in mcp_servers.json, in the same shape as the blocks in server READMEs.

Where to start

The Kaptain Docs chapter Customise before your first run lists ten settings worth choosing on purpose. Each is a trade-off, and each can be undone later without losing anything. From there, read Models and runtimes, Per-model settings, Delegation and token use and Skills.

The next two guides in this series cover the tools, in Krew and MCP, and the agents, in What is a kapsule?