Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 04 · LESSON 4.3

Configure models for different jobs

Assign models to jobs through stable configuration aliases.

Lesson 18 of 86 · FabrCore 2.0

Overview

The answering model, extraction model and embedding model have different requirements. Named configurations make those choices visible without scattering provider details through plugins. Provider capabilities, token limits and deployment names must match the actual service you use.

A named model is a dependency

An assistant may generate prose, a classifier may need a compact structured result, and an embedding service produces vectors rather than answers. Name these roles in the model catalog and select them at the consuming component. This keeps provider credentials and deployment names out of business plugins and makes environment changes reviewable.

Changing an alias does not change every cached client

The catalog tells a factory how to construct a client. An existing agent can retain a previously initialized client until its supported reload/reconfiguration path runs. Model capabilities and limits also belong to the provider deployment you actually selected. Copying another model's context window or embedding dimensions into the catalog does not grant those capabilities.

Assign models by job

  1. Add distinct default, embeddings and optional specialist configurations. Set ApiKeyAlias and the correct provider endpoint/deployment.
  2. Configure timeout, supported reasoning effort, ContextWindowTokens and MaxOutputTokens from the deployed model's metadata. Do not copy another model's context limit blindly.
  3. Use an explicit extraction alias for GraphRAG when needed; its resolution falls back through graphrag to default. Keep the integrated embedding dimension requirement in view.
Multiple Models · reference snippet 
{
  "ModelConfigurations": [
    {
      "Name": "default",
      "Provider": "OpenAI",
      "Model": "gpt-4o",
      "ApiKeyAlias": "openai"
    },
    {
      "Name": "fast",
      "Provider": "OpenAI",
      "Model": "gpt-4o-mini",
      "ApiKeyAlias": "openai",
      "ContextWindowTokens": 128000,
      "MaxOutputTokens": 16384,
      "CompactionKeepLastN": 10,
      "CompactionThreshold": 0.8
    },
    {
      "Name": "reasoning",
      "Provider": "OpenAI",
      "Model": "o1",
      "ApiKeyAlias": "openai",
      "TimeoutSeconds": 300,
      "CompactionEnabled": false
    }
  ]
}

Confirm which model handled each job

  1. Configure two generation aliases supported by your available provider and assign one to a disposable assistant. Ask a simple fixed question and inspect model attribution in the resulting call record.
  2. Change the instance to the other alias through an explicit reconfiguration, then repeat. Verify the recorded model/deployment changed; different answer wording alone is not reliable evidence.
  3. Keep embedding configuration separate and verify the vector service's required dimensions before using it with a knowledge index. Do not send an embedding alias to the chat-agent factory.

The check is about resolving and applying named dependencies. Quality and cost comparisons need a repeatable evaluation set, introduced in module 12.

If the result is different

Some providers do not offer all capabilities. A chat-capable endpoint is not evidence that its embedding or audio API is compatible.

Go deeper

Explore the related documentation.