feat: modular AI model routing system for flexible provider support

[alok-108]

Problem

The current system used tightly coupled model inference logic, making it difficult to switch between different AI models or providers without significant code changes.

Solution

Introduced a modular Model Routing Architecture. This decuples the application logic from the underlying model provider, allowing for "plug-and-play" support for multiple AI engines.

Features

• Centralized Model Router: Dynamically switches between providers.
• • OpenAI Support: Ready-to-use integration for GPT models.
• • HuggingFace Support: Flexible usage of open-source models via the transformers library.
• • Local Model Support: Extensible path for offline inference.
• • Improved Resource Management: Skips local model loading if a cloud provider is selected.
• • Clean Configuration: Centralized settings for default providers and models.

Impact

• Flexibility: Activities can now use different models (e.g., local for privacy, OpenAI for performance).
• • GSoC Alignment: Directly addresses the "AI Optimization" project goals by improving system extensibility.
• • Maintainability: Clean project structure separating core logic from provider-specific code.

[alok-108]

Hi, I am exploring contributions aligned with the AI Optimization GSoC project. This PR introduces a modular routing system for flexible AI model usage, enabling users to easily plug in their own models or switch between providers (OpenAI, HuggingFace, etc.). I would appreciate your feedback on this architectural improvement.

[alok-108]

Nice catch on issue #102. The 401 errors were definitely happening because the settings.API_KEYS dictionary was only being populated from the .env file at startup, essentially "forgetting" any dynamically generated OAuth keys already stored in the database.

I've addressed this in my PR by introducing a sync_and_load_keys() helper in auth.py and hooking it into the application's startup sequence in main.py. This ensures we have a proper two-way sync: it still migrates new keys from the environment into the DB, but now it also hydrates the in-memory validation layer with every approved and active key found in the persistent store.

OAuth users should now maintain their API access consistently across server restarts and redeployments.

[alok-108]

Nice catch on issue #102. The 401 errors were definitely happening because the settings.API_KEYS dictionary was only being populated from the .env file at startup, essentially "forgetting" any dynamically generated OAuth keys already stored in the database.

I've addressed this in my PR by introducing a sync_and_load_keys() helper in auth.py and hooking it into the application's startup sequence in main.py. This ensures we have a proper two-way sync: it still migrates new keys from the environment into the DB, but now it also hydrates the in-memory validation layer with every approved and active key found in the persistent store.

OAuth users should now maintain their API access consistently across server restarts and redeployments.