AI Models

Provider kinds

A model talks straight to a model API from inside Genosyn — there's no CLI to install, no subscription sign-in, and nothing written to disk. Three provider kinds cover every setup:

The Custom kind is the path for any self-hosted or gatewayed LLM that speaks the OpenAI API — see Open-source LLMs for that flow.

Credentials

Everything a model needs is entered in the app. There's no OAuth sign-in and no per-provider config file to manage — just the fields the kind requires:

• Anthropic and OpenAI. Paste an API key. That's the whole setup — the runner picks the default model for the kind, or you can name a specific model string.
• Custom. Paste a base URL and a model id, plus an optional API key if your endpoint requires one. The loop then points every request at that endpoint.

Context window

Every turn sends the employee's Soul, their Skills, and the whole tool catalog, and each tool call adds its result on top. A long routine therefore grows until it reaches whatever the model will accept — so Genosyn needs to know how much room there is. When a model connects, it asks the provider and shows the answer on the model card.

Once it knows, a run budgets against it: when the next prompt wouldn't fit, the oldest tool results are dropped to a stub so recent work and the routine's instruction survive. The run log says [compact] whenever that happens, so a forgetful-looking employee is always explained by its transcript.

Not every server reports a window. vLLM, LM Studio, and llama.cpp publish one; plain Ollama and OpenAI's own API don't. When the card reads Unknown, use Ask the provider to retry, or Set manually and type the number in — whatever the server was launched with, such as vLLM's --max-model-len or llama.cpp's -c. A number you set by hand always wins over the probe, and Clear hands the field back to it.

Built-in agent tools

The runner and chat both run an in-process agent loop that hands the model tools directly — no matter which provider kind you pick, every model gets the same toolset:

• Coding tools. bash, read_file, write_file, edit_file, glob, and grep — run inside the employee's sandboxed directory.
• genosyn — the tools the employee calls to run Routines and Todos, write journal notes, save Memory, work with Bases and attachments, and reach any registered Integration tool. Always on.
• browser — browser tools backed by a headless Chromium when browserEnabled is true on the employee. Skipped when off.
• Company MCP servers. Any MCP servers your company has configured are added to the loop alongside the built-ins.

How many tools an employee can hold

OpenAI accepts at most 128 tools on a request and rejects the whole turn if you send more. Anthropic publishes no such limit, and a custom endpoint sets its own — so this only constrains employees whose active model is an OpenAI one.

The built-ins take up roughly 49 of those slots (coding, the genosyn tools, and the browser tools when enabled), which leaves about 79 for Integration tools and company MCP servers. That is a lot — but a single Integration can register a dozen or more tools, so an employee granted many Connections at once can reach the ceiling.

If it happens, the run doesn't fail. Genosyn drops the lowest-value tools until the list fits, preferring to cut ones the employee holds no Grant for and therefore couldn't have used anyway, and writes a [tools] line into the run log naming exactly what it dropped. If you see that line, remove a Connection or an MCP server from the employee — or move it to an Anthropic or custom model, which have no cap.

Multiple models & the active one

An employee can hold several models side by side — say an Anthropic key for everyday work and an OpenAI key for a second opinion. Exactly one is active at a time; the active model is the brain the loop runs for routines and the chat seam answers with. The most recently added model becomes active automatically — hit Make active on any other to switch, instantly and as often as you like.

Open an employee, then Settings → Model to see the roster: each card shows the provider kind, model string, connection status, and an Active badge on the current brain. Use Add model to register another.

Removing a model

Remove on a model card deletes that AIModel row along with its encrypted credentials. If you remove the active model, the most recently added survivor is promoted to active. No data on Soul, Skills, Routines, or past Runs is affected.