Wrap Existing AI Providers Using the New AIProvider Abstraction Layer

[ShashankSaga]

Is your feature request related to a problem? Please describe.

LocalMind now has a foundational AI provider abstraction layer (AIProvider, AIProviderRegistry) that defines a clean contract for interacting with AI providers.
However, existing AI integrations (e.g., Gemini, Ollama, OpenAI) are still accessed directly, which means the new abstraction is not yet exercised in real execution paths.

Without wrapping at least one real provider:

The abstraction remains theoretical

Provider logic stays coupled to implementation details

Capability-based routing cannot be validated end-to-end

This is not a bug, but a missing architectural integration step.

Describe the solution you'd like

Introduce a concrete implementation of AIProvider for one existing provider (recommended: Gemini or Ollama) and register it using AIProviderRegistry.

Scope:

Create a provider adapter that:

Implements AIProvider

Maps existing provider logic to the new interface

Declares supported capabilities using the new capability model

Register the provider during application initialization

Keep all existing API behavior unchanged

This allows the abstraction layer to be exercised in real flows while keeping changes minimal and safe.

Describe alternatives you've considered

Leaving existing providers untouched and waiting for a full router implementation

Refactoring all providers at once

These approaches either delay validation of the abstraction or introduce unnecessary risk. Incrementally wrapping one provider is safer and aligns with clean architecture principles.

Additional context

This issue is a direct continuation of the recently merged foundational abstraction PR.
Completing this step will:

Validate the abstraction in production code

Enable future capability-based routing

Reduce provider coupling incrementally

Serve as a reference implementation for wrapping additional providers

This change is reusable, scalable, and improves developer experience without altering external behavior.

[ShashankSaga]

Hi @abhishek-nexgen-dev 👋

As discussed, I’ve raised this follow-up issue to build on the newly added AI provider abstraction.

I’m happy to take this up and start by wrapping a single existing provider (Gemini or Ollama) in a minimal, non-breaking way to validate the abstraction in real flows.

Please let me know if you’re okay assigning this to me and if you have a preference for which provider to start with. Thanks!

[abhishek-nexgen-dev]

@ShashankSaga

make sure the user choose the provider and model support user choose cloud then show all the model related to cloud once user clicks on specific model then use that model to give the answer

[ShashankSaga]

@abhishek-nexgen-dev
Got it 👍

I’ll implement this in a way where:

• users explicitly choose the provider (cloud / local),
• models are listed dynamically based on the selected provider,
• and only the selected model is used for inference.

I’ll keep the changes isolated and non-breaking so existing flows continue to work as-is.