Right now the application has an llm package, but inside it we only have an openai implementation that is exported and called directly by the business logic that requires the functionality. Additionally, even the templated commands have a field for model name, which is directly tied to a model provider.
A more robust and flexible solution would be for the model providers to be completely abstracted away from the business logic. All the exported code should be at the llm package, and based on user configuration, the code then decides whether to delegate the calls to OpenAi, or any of the other--to be supported--model providers.
Instead of calling out the model name directly in the commands and templates, we could refer to them as model families (GPT and reasoning), and model size (Large,Small). And let the provider-specific code map these concepts to its own domain.
The configuration should come from .vyb/config.yaml. This file should be created during vyb init execution, and default the LLM-provider to OpenAI.
Right now the application has an
llmpackage, but inside it we only have anopenaiimplementation that is exported and called directly by the business logic that requires the functionality. Additionally, even the templated commands have a field for model name, which is directly tied to a model provider.A more robust and flexible solution would be for the model providers to be completely abstracted away from the business logic. All the exported code should be at the
llmpackage, and based on user configuration, the code then decides whether to delegate the calls to OpenAi, or any of the other--to be supported--model providers.Instead of calling out the model name directly in the commands and templates, we could refer to them as model families (
GPTandreasoning), and model size (Large,Small). And let the provider-specific code map these concepts to its own domain.The configuration should come from
.vyb/config.yaml. This file should be created duringvyb initexecution, and default the LLM-provider to OpenAI.