[Feature request]: Set default models per Pattern

[PyrokineticDarkElf]

What do you need?

I believe it would enhance the results of Fabric if users could assign different default models (LLMs) to specific Patterns. Each LLM excels in different scenarios—some are proficient in coding, others in understanding intent, or in utilizing up-to-date data. Therefore, it's logical to align specific patterns with models that suit them best.

Proposal:

• Configurable Default Models: Introduce a configuration file where patterns can be mapped to their preferred default LLM. If a specific model isn't designated, the system defaults to the Fabric default set by the user.
• Creator Presets: Allow the Pattern authors to provide a model option. This could be the model they tested their Pattern on, or the best model they have found for their pattern.
• Import Creator Presets: Allow the user, through a CLI command, to import the presets providing the user has an API key for those models.
• CLI Command: Implement a CLI command to manage this configuration file. Users can add, remove, or update mappings between patterns and default models directly from the command line. This should be retained after updates.
• Opt-in: To prevent unexpected charges, this feature should be disabled by default. Users can enable it through a clearly defined setting during setup.

This enhancement would not only optimize the system's performance by leveraging specialized models but also empower users to tailor AI interactions to their specific needs effectively.

[AO12612]

this is interesting

I would add that it could be useful to also have the option of different prompts tailored to specific models for each pattern. This way for models with significantly different characteristics the degrading output can be handled graciously.

[snafu4]

Was this (or related) functionality ever implemented?

[ksylvan]

No it was not @snafu4 - how do you imagine it working?

[snafu4]

I think it is an individual preference so any implementation would be local. The creator of the pattern could put their model suggestion(s) in the README.md (or user.md) but no (initial) automation to use/implement that suggestion.

fabric pattern-model set <pattern> <model> fabric pattern-model unset <pattern> fabric pattern-model list

stored in: ~/.config/fabric/pattern_models.yaml with entries mapping pattern names to models:

summarize: openai/gpt-4o-mini
suggest_pattern: ollama/qwen3:4b

[PyrokineticDarkElf]

What about using markdown frontmatter to store the recommended model in the pattern file itself?

That way, no additional file would be needed. It would also open up more possibility for other config options in the future.

[snafu4]

I think it is an individual preference so any implementation would be local. The creator of the pattern could put their model suggestion(s) in the README.md (or user.md) but no (initial) automation to use/implement that suggestion.

fabric pattern-model set <pattern> <model> fabric pattern-model unset <pattern> fabric pattern-model list

stored in: ~/.config/fabric/pattern_models.yaml with entries mapping pattern names to models:

summarize: openai/gpt-4o-mini
suggest_pattern: ollama/qwen3:4b

Code created with PR: https://github.com/danielmiessler/Fabric/pull/1712

[ksylvan]

Hi @snafu4 - I think the approach in the vibe-coded PR works, but I think it's a bit outside the scope creep for Fabric.

Let me think about a simpler approach—perhaps closer to the @PyrokineticDarkElf idea—or some additional configuration that can be put in ~/.config/fabric/config.yaml.

[snafu4]

Np @ksylvan. I’ve been a Fabric user since (almost) the beginning, and it has been great to see the project explode in popularity (👍). With that growth has also come more complexity (👎), which for me has made the tool harder to use day-to-day. That is really the challenge you are managing: balancing future growth with keeping things simple and intuitive. You and the team have done an amazing job overall. This is not a complaint, and I know I could not have done anywhere near as well as you and the others.

I think @PyrokineticDarkElf’s idea fits with what you are calling "scope," but it also adds to the complexity of a tool that shines most when it feels simple and delivers a big bang for little effort. That drift is what motivated my PR.

I am looking forward to seeing where you and the team take Fabric (not sarcasm). Thanks again for all the hard work you have put in.

[ksylvan]

Thanks, Neil, for the kind words. I'll come up with a smaller patch for the same functionality soon. @snafu4

[ksylvan]

@snafu4 Neil, I have a much simpler way to do this without the complexity of adding more CLI flags, config files, and config management commands to Fabric.

See #1714 - You'd simply need to specify the environment variables in your shell startup files that map the patterns to models (optionally you can specify VENDIR|MODEL to disambiguate where we have multiple vendors providing the same model name).

For example:

$ FABRIC_MODEL_AI='Groq|deepseek-r1-distill-llama-70b' fabric -p ai 'Why is 
the sky blue?'
<think>
Okay, so I need to figure out why the sky is blue. Hmm, I remember learning something about light in school, but I'm not exactly sure how it all ties together. Let me start by recalling what I know.

First, the sky appears blue during the day, right? But during sunrise or sunset, it can turn red or orange. That must have something to do with the light from the sun and how it interacts with the Earth's atmosphere. So, maybe the color of the sky has to do with the atmosphere scattering sunlight.
[...]

And using a different model,

$ FABRIC_MODEL_AI='OpenAI|o3-mini' fabric -p ai 'Why is the sky blue?'
- Sunlight interacts with Earth's atmosphere producing scattered short blue wavelengths.
- Short wavelengths scatter more efficiently generating blue appearance overhead sky.
- Human eyes perceive scattered blue due to visible spectrum sensitivity.

You would set up your model mappings in some shell startup file.

[snafu4]

An elegant solution @ksylvan. It is much better than my suggestion and it keeps things simple. Thanks!