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 their working set of tools, 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 catalogue— but not all of it at once. An employee is shown a small working set every turn and looks the rest up on demand; see How tools reach the model. The catalogue is:

• 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, Notes, Resources, charts, mail, finance and attachments, and reach any registered Integration tool. Always available; the frequently-used ones are loaded up-front and the rest are a find_tools call away.
• find_tools and call_tool — how the employee searches the catalogue and runs anything in it. 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.

In practice this no longer binds. Only the working set goes on the request — around 20 tools — so the catalogue behind it can grow without approaching any provider's ceiling. An employee with a dozen Connections is fine.

The old trimming behaviour is still there as a backstop: if the working set somehow did exceed a cap, Genosyn drops the lowest-value tools until it fits, preferring ones the employee holds no Grant for, and writes a [tools] line into the run log naming exactly what it dropped. Every run also logs how the catalogue was split, so you can always see what the employee was shown.

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.

When a chat or Run reports a model error

The error names the active model, shows the safe host-only endpoint, preserves the provider's detail and request ID when available, and lists checks for that failure type. In chat, use Review AI Model settings on the error to jump straight to the active employee's model roster. A separate chat connection interrupted message means the browser lost its stream to the Genosyn server; confirm the server is running and inspect its logs before retrying. A Genosyn couldn't complete this chat turn message includes the conversation ID to search for in those logs and usually points to server-side setup such as a Browser or company MCP connection.

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.