Model catalog
Fabro keeps five related concepts separate:- A provider serves requests, such as
openaioropenrouter. - A model slug is Fabro’s canonical, human-facing model ID, such as
gpt-5.6-sol. - An alias is another user-facing selector, such as
gpt-56-sol. - A family is display and matching metadata. It does not affect routing identity.
- An API ID is the opaque model string sent on the provider wire. Workflows should never reference it.
(provider, model slug). The same slug and alias may appear on several providers. Within one provider, however, every slug or alias must identify exactly one offering.
For an unqualified selector, Fabro checks canonical slugs before aliases, filters the candidates to providers whose adapters are ready, and then chooses the highest provider priority. Equal priorities use canonical provider ID order. An explicit provider restricts selection to that provider and is a pin: if it is unavailable, Fabro reports the error instead of silently switching.
For example, the shared gpt-56-sol alias can be portable across direct OpenAI and OpenRouter offerings:
Fabro performs this selection once when creating a run and persists the chosen provider and canonical slug in the run settings and graph. Resuming that run does not reconsider provider priority when credentials change. Runtime model fallbacks are the separate mechanism for handling a later provider failure.
Each provider requires its own API key. Server-backed workflows read provider credentials from the server vault (for example
ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, or POOLSIDE_API_KEY set with fabro secret set or fabro provider login). Standalone SDK/CLI flows can opt into env-backed credential sources explicitly. See the Quick Start for setup.
Claude Fable 5 is available as an explicit model but is not the default Anthropic model. If Fable refuses a request, Fabro reports the refusal as a content-filter LLM error and applies the configured run.model.fallbacks chain when one is present.
Configuring providers and models
Fabro’s catalog starts with the built-in providers and models, then merges any[llm] entries from settings. Models are nested under their provider, so two providers can expose the same model slug without overwriting each other.
settings.toml
settings.toml
api_id is the opaque model name sent to that provider’s API. It defaults to the exact model slug, so omit it when the two strings match. Fabro does not infer vendor prefixes or rewrite the value.
Historical built-in catalog keys that exposed provider API IDs remain accepted as compatibility selectors. Fabro normalizes a primary or node selector such as
openai/gpt-5.6-sol to the canonical gpt-5.6-sol slug before normal provider-aware selection. With no provider pin, the highest-priority ready offering wins; a separate provider = "openrouter" pin selects the OpenRouter offering. Fabro also normalizes these keys in legacy top-level [llm.models] rows without rewriting the settings file.default = true controls normal model selection for workflow execution, while small_default = true marks the provider’s small/cheap utility model for metadata tasks such as generated run titles. If a provider has no small default, Fabro falls back to that provider’s normal default.
Provider auth is declared in [llm.providers.<id>.auth] with ordered env:<NAME> or vault:<NAME> refs. The primary auth header defaults to bearer; override with header = { custom = "Header-Name" } for providers like Anthropic that use x-api-key. Omit the [llm.providers.<id>.auth] block entirely for providers that need no API key (e.g. Ollama). Custom headers for any provider — including providers that need only interpolation headers and no API-key auth — go in extra_headers as literal text, {{ env.NAME }} tokens, or {{ secrets.NAME }} tokens. Put credentials in secrets and reference them with {{ secrets.NAME }} instead of a bare literal.
Workflow runs also add x-session-id: <run-id> to every LLM request so compatible gateways can group requests from the same run. An explicitly configured x-session-id in provider extra_headers takes precedence.
Provider agent_profile defaults from adapter and controls profile-specific behavior such as which tools the agent registers, project-memory filenames, CLI/ACP command selection, and native session routing. Valid values are anthropic, openai, gemini, kimi, and gpt56; model-level values override provider-level values.
Two profiles are selected per model rather than per provider, because they follow the model wherever it is served: kimi for Kimi models, and gpt56 for the GPT-5.6 models (Sol, Terra, Luna). The gpt56 profile uses Codex’s narrow core surface — shell_command, apply_patch, and update_plan, plus optional Brave-backed web_search — instead of fabro’s dedicated file-read, discovery, and web_fetch tools. On OpenAI-compatible routes that cannot carry the freeform apply_patch grammar, it substitutes the JSON-schema edit_file tool. Session features may add their own question, skill, or subagent tools separately.
Provider billing_policy defaults from adapter and controls usage-cost estimation. Use openai, anthropic, gemini, or none. Model rows may override it for models whose billing family differs from their provider’s — for example, Claude models served through OpenRouter set billing_policy = "anthropic" so cache reads and writes price correctly.
Provider fields in configuration, APIs, and model routing are provider ID strings. Built-in names like
anthropic, openai, and gemini still work, but custom IDs like proxy work anywhere a provider ID is accepted.Poolside
Fabro ships a built-in Poolside provider for Laguna S 2.1 and Laguna XS 2.1 over Poolside’s OpenAI-compatible API. Store a direct API key withfabro provider login --provider poolside. The same model slugs are also available through the opt-in OpenRouter provider; its vendor-namespaced strings remain provider-only api_id values.
OpenRouter
Fabro ships an OpenRouter provider definition with a curated model catalog, disabled by default. Enable it in settings and store an API key withfabro provider login --provider openrouter:
settings.toml
Amazon Bedrock
Fabro ships an Amazon Bedrock provider definition with a curated multi-vendor catalog over Bedrock’s Converse API, disabled by default. Enable it and authenticate with a Bedrock API key or AWS SigV4 credentials:settings.toml
Ollama
Fabro ships an Ollama provider definition that is disabled by default. Enable it in settings when you want Fabro to route through a local Ollama server:settings.toml
[llm.providers.ollama.models."<model-slug>"] blocks for each Ollama model you have pulled locally. Ollama’s OpenAI-compatible endpoint accepts any bearer token, so local users can set OLLAMA_API_KEY=ollama.
Default models
When no model or provider is specified, Fabro chooses the default offering on the highest-priority ready provider. If no provider adapter is ready, run creation reports that no eligible offering is available. Each provider has its own default model:Using models in workflows
Assign models to workflow nodes using model stylesheets, which use a CSS-like syntax:example.fabro
Overriding the default model
Model stylesheets set per-node models inside the workflow graph, but you can also override the default model for an entire run. This is useful for quick experimentation or when you want to swap models without editing the Graphviz file.CLI flags
Pass--model and optionally --provider to fabro run:
--provider, Fabro selects among ready offerings by priority. Add --provider to pin an exact provider, including for an uncatalogued provider model string.
Run config TOML
For repeatable runs, set the model in a run config file:run.toml
fallbacks array is optional. Each entry may be a bare provider token (like "gemini"), a bare model alias (like "gpt-5.4"), or a qualified "provider/model" reference. Fabro tries them in order when the primary provider is unavailable. In this field, qualified references keep their established provider-pin meaning: "openai/gpt-5.6-sol" selects the direct OpenAI offering.
The precedence order is: node-level stylesheet > run config TOML > CLI flags > server defaults. More specific settings always win.