Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Add Provider Abstraction Layer for AI Module

Open
  • Is something wrong?
#24 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
nodejs, typescript
Domain
ai, cli

Research direction

Start by locating the existing AI module and its OpenAI-compatible chat and tool-calling logic; the issue does not name files or tests. Compare that flow with the proposed AIProvider interface and identify the smallest agreed first step, since provider priorities and fallback behavior are still open questions. Done would require a tested provider abstraction and configuration-based selection, but the scope needs maintainer clarification.

Written by the indexing model from the issue text.

Description

AI core enhancement priority: high refactor

Summary

  • Add abstraction layer for AI providers to support multiple backends (OpenAI-compatible, Anthropic, local models)
  • Enable easier provider switching without rewriting tool-calling logic
  • Standardize provider capabilities detection (structured output, streaming, etc.)

Motivation

The current AI module design assumes OpenAI-compatible API format. Adding support for other providers (Anthropic, Ollama, LM Studio) would require duplicating tool-calling logic and handling provider-specific differences.

An abstraction layer would:

  • Reduce code duplication when adding new providers
  • Make provider switching configuration-based
  • Allow graceful degradation based on provider capabilities
  • Simplify testing with mock providers

Proposed Design

interface AIProvider {
  // Core chat completion
  chatCompletion(params: ChatParams): Promise<ChatResponse>;
  
  // Capability detection
  supportsStructuredOutput(): boolean;
  supportsStreaming(): boolean;
  supportsToolCalling(): boolean;
  
  // Provider-specific formatting
  formatTools(tools: Tool[]): any;
  formatMessages(messages: Message[]): any;
}

interface ChatParams {
  messages: Message[];
  tools?: Tool[];
  responseFormat?: 'text' | 'json';
  stream?: boolean;
}

class OpenAICompatibleProvider implements AIProvider {
  constructor(config: { baseUrl: string; apiKey: string; model: string }) {}
  // OpenAI-specific implementation
}

class AnthropicProvider implements AIProvider {
  constructor(config: { apiKey: string; model: string }) {}
  // Anthropic-specific implementation  
}

class LocalProvider implements AIProvider {
  constructor(config: { baseUrl: string; model: string }) {}
  // Local model server implementation
}

Implementation Plan

  1. Define AIProvider interface and related types
  2. Implement OpenAICompatibleProvider (refactor existing code)
  3. Add provider factory based on configuration
  4. Update config to support provider type selection
  5. Add Anthropic provider (Phase 2B)
  6. Add local model provider support (Phase 2C)

Benefits

  • Single place to handle provider-specific differences
  • Easier to add new providers in the future
  • Better testability with mock providers
  • Cleaner separation of concerns

Drawbacks

  • Additional abstraction layer
  • May need to handle lowest-common-denominator capabilities
  • Slightly more complex initial implementation

Open Questions

  • Should we support multiple providers simultaneously (fallback chain)?
  • How to handle provider-specific features that don't fit the abstraction?
  • What's the priority order for provider implementation?

Generated with Devin

Dominant language
TypeScript
Stars
1
Forks
0
Avg merge
23h 35m
Merged PRs (30d)
159

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Kuldeep2822k/cli

All issues in Kuldeep2822k/cli

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.