Build an llm interface for openai

[gowthamkishore3799]

Build an llm interface for openai

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Possible Duplicates

• Build an openai interface for llm calls #1020

Related Issues

• Build an openai interface for llm calls #1019
• Build an openai interface for llm calls #1021
• Build an openai interface for llm calls #1022
• Build an openai interface for llm calls #1023

👤 Suggested Assignees

• gowthamkishore3799

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitaidev]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

🔗 Similar Issues

Possible Duplicates

• Build an openai interface for llm calls #1023

Related Issues

• Build an openai interface for llm calls #1019
• Build an openai interface for llm calls #1020
• Build an openai interface for llm calls #1021
• Build an openai interface for llm calls #1022

👤 Suggested Assignees

• gowthamkishore3799

🔍 Additional Context

Summary: Context for Building an LLM Interface for OpenAI

Based on the gathered documentation, here are the key findings for implementing an LLM interface for OpenAI:

1. Available OpenAI Libraries

The most relevant libraries for building an OpenAI LLM interface are:

• OpenAI Python (/openai/openai-python) - High reputation, 459 code snippets, Benchmark: 89.9
• OpenAI Go (/openai/openai-go) - High reputation, 330 code snippets, Benchmark: 76.6
• OpenAI Node/TypeScript (/openai/openai-node) - High reputation, 356 code snippets, Benchmark: 85.2

2. Client Initialization Patterns

Python SDK:

• Supports both synchronous (OpenAI) and asynchronous (AsyncOpenAI) clients
• Configuration includes API keys, organization, project, timeout, and retry parameters
• Supports Azure OpenAI integration with custom endpoints
• Custom HTTP client configuration available for proxy and transport settings

Go SDK:

• Initializes with API key using openai.NewClient(option.WithAPIKey(...))
• Uses context-aware patterns with context.Background()
• Simple, type-safe method signatures for API calls

3. Core LLM Interface Design

LLM interface patterns should implement:

• Unified Provider Trait: A core interface for all LLM providers that unifies chat, completion, and embedding capabilities
• Builder Pattern: Flexible configuration of providers with settings for model, API keys, base URLs, generation parameters (max_tokens, temperature), system prompts, and timeouts
• Chain Support: Ability to chain multiple LLM providers together for complex workflows

4. Primary API Operations

Core operations for OpenAI chat completions:

• POST /chat/completions - Create chat completions with messages, tools, and response format options
• GET /chat/completions/{id} - Retrieve specific completion details
• POST /chat/completions/{id} - Update existing completions
• DELETE /chat/completions/{id} - Delete completions
• GET /chat/completions/{id}/messages - List messages within a completion

5. Multi-Provider Abstraction Patterns

For broader LLM integration, reference libraries like:

• LiteLLM - Unified OpenAI-compatible interface for 100+ LLMs with retry/fallback logic
• Unified Rust LLM Interface - Provides standardized chat, completion, embedding capabilities across providers
• Any-LLM - Simplified unified interface leveraging official SDKs

Key Implementation Considerations:

• Support both sync and async operations
• Implement configuration management for API credentials and model parameters
• Enable streaming and non-streaming response modes
• Support tool calling and structured outputs
• Include timeout and retry mechanisms
• Design for provider extensibility

Context gathered from: Context7

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitaidev]

Coding Plan

Approach

Build a typed, validated interface for interacting with OpenAI's LLM API, enabling chat completions and other LLM operations within the codebase. The implementation will follow established patterns from the Zod v4 demonstration project, using environment variables for credentials, Zod schemas for validation, and discriminated unions for responses.

Observations

This is a Zod v4 and Tailwind v4 demonstration project with an Express backend template (fools/newLib.ts) and comprehensive Zod validation patterns. The project uses environment variables for API credentials, axios for HTTP calls, and established patterns for request/response validation with discriminated unions. Currently lacks OpenAI integration and TypeScript configuration.

Assumptions

Assumption 1: Which OpenAI API methods to support initially

Options Considered:

• Start with only chat completions (most common LLM use case)
• Build comprehensive interface for all OpenAI services
• Focus on streaming chat completions for real-time responses

Chosen Option: Start with chat completions

Rationale: This is the primary LLM interface use case and allows for a focused, high-quality implementation following existing patterns. The service can be extended later for embeddings or other features as needed. Developers will appreciate having a working, well-validated chat interface immediately rather than a broader but less polished solution.

Assumption 2: Service location and structure

Options Considered:

• Create new service file in root directory alongside zod files
• Place in fools/ directory with other demo code
• Create dedicated services/ or lib/ directory for better organization

Chosen Option: Create in root directory (openaiService.ts and openaiSchemas.ts)

Rationale: This aligns with how Zod schemas are currently organized at the root level. Since this is a demonstration project without strict architectural boundaries, keeping the OpenAI service at the root makes it easily discoverable and consistent with existing file organization patterns.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Dependencies and Configuration Setup

Set up the required dependencies and TypeScript configuration to support OpenAI integration with proper type safety.

Task 1: Install OpenAI SDK and Configure TypeScript

Add the official OpenAI package and create TypeScript configuration to ensure proper module resolution and type checking.

• Install openai package as a production dependency
• Create tsconfig.json in root directory with module resolution set to "node" or "bundler", target ES2020 or later, and strict mode enabled for type safety
• Configure include paths for all .ts files in root and fools/ directories
• Set up lib options to include ES2020+ features for async/await support

Task 2: Environment Configuration for API Key

Establish environment variable pattern for OpenAI API credentials following the existing pattern used for WEATHER_API_KEY and DATABASE_URL.

• Create .env.example file documenting OPENAI_API_KEY variable
• Add .env to .gitignore if not already present to prevent credential leakage
• Document the environment variable requirement in a comment or README section

🤖 Prompt for AI agents

Set up OpenAI integration dependencies and TypeScript configuration.

Install the openai package as a production dependency.

Create tsconfig.json with:
- Module resolution set to node or bundler
- Target ES2020 or later
- Strict mode enabled
- Include paths for root and fools/ directory .ts files
- Lib options for ES2020+ async/await support

Create .env.example documenting OPENAI_API_KEY variable.

Ensure .env is in .gitignore to prevent credential leakage.

Phase 2: OpenAI Service Implementation

Build the core service layer with Zod schemas for validation, following established patterns from zodv4-examples.ts and zodv4-features.ts.

Task 1: Define Zod Schemas for OpenAI Requests and Responses

Create validation schemas following the CreateUserRequest/CreateUserResponse pattern established in zodv4-examples.ts.

• Create openaiSchemas.ts in root directory
• Define ChatCompletionRequest schema with fields: model (string enum for gpt-4, gpt-3.5-turbo, etc.), messages (array of message objects with role and content), temperature (optional number with range validation), max_tokens (optional number), and other common OpenAI parameters
• Define Message schema with role (enum: "system", "user", "assistant") and content (string)
• Define ChatCompletionResponse schema as discriminated union (following ApiResponse pattern from zodv4-features.ts) with success variant containing message content and metadata, and error variant with error details
• Export TypeScript types using z.infer pattern
• Include custom error messages for better validation feedback

Task 2: Implement OpenAI Service Layer

Create the service module that wraps the OpenAI SDK with Zod validation and follows the existing external API pattern from newLib.ts.

• Create openaiService.ts in root directory
• Import OpenAI SDK and initialize client using process.env.OPENAI_API_KEY (following the environment variable pattern from newLib.ts)
• Implement createChatCompletion function that:
  • Accepts validated ChatCompletionRequest
  • Calls OpenAI SDK's chat.completions.create method
  • Validates responses using ChatCompletionResponse schema with safeParse()
  • Returns discriminated union response (success/error) matching the established pattern
• Add error handling for API failures, network issues, and validation errors
• Export service functions with proper TypeScript types
• Include JSDoc comments documenting parameters and return types for better developer experience

Task 3: Create Usage Example Documentation

Provide clear documentation on how to use the OpenAI interface within the codebase.

• Add usage examples in comments at the top of openaiService.ts showing:
  • How to import and call createChatCompletion
  • Example request object structure
  • How to handle success/error response variants
  • Environment setup requirements
• Optionally add a simple example to fools/newLib.ts Express routes demonstrating integration with an API endpoint (creates /api/chat route that accepts POST requests, validates input with Zod schema, calls openaiService, returns JSON response)

🤖 Prompt for AI agents

Implement the OpenAI service layer with Zod validation following established
patterns.

Create openaiSchemas.ts:
- Define Message schema with role enum (system, user, assistant) and content
string
- Define ChatCompletionRequest schema with model enum (gpt-4, gpt-3.5-turbo,
etc.), messages array, optional temperature with range validation, optional
max_tokens, and other common parameters
- Define ChatCompletionResponse as discriminated union with success variant
(message content and metadata) and error variant (error details)
- Export TypeScript types using z.infer pattern
- Add custom error messages for validation feedback

Create openaiService.ts:
- Import and initialize OpenAI client using process.env.OPENAI_API_KEY
- Implement createChatCompletion function that accepts ChatCompletionRequest,
calls OpenAI SDK's chat.completions.create, validates response with safeParse(),
and returns discriminated union (success/error)
- Add error handling for API failures, network issues, and validation errors
- Include JSDoc comments for parameters and return types
- Add usage examples in top comments showing imports, example requests, response
handling, and environment setup

Optionally add /api/chat POST route example to fools/newLib.ts demonstrating
integration with Express endpoint.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Set up OpenAI integration dependencies and TypeScript configuration.

Install the openai package as a production dependency.

Create tsconfig.json with:
- Module resolution set to node or bundler
- Target ES2020 or later
- Strict mode enabled
- Include paths for root and fools/ directory .ts files
- Lib options for ES2020+ async/await support

Create .env.example documenting OPENAI_API_KEY variable.

Ensure .env is in .gitignore to prevent credential leakage.
===============================================================================

Task: 2

Implement the OpenAI service layer with Zod validation following established
patterns.

Create openaiSchemas.ts:
- Define Message schema with role enum (system, user, assistant) and content
string
- Define ChatCompletionRequest schema with model enum (gpt-4, gpt-3.5-turbo,
etc.), messages array, optional temperature with range validation, optional
max_tokens, and other common parameters
- Define ChatCompletionResponse as discriminated union with success variant
(message content and metadata) and error variant (error details)
- Export TypeScript types using z.infer pattern
- Add custom error messages for validation feedback

Create openaiService.ts:
- Import and initialize OpenAI client using process.env.OPENAI_API_KEY
- Implement createChatCompletion function that accepts ChatCompletionRequest,
calls OpenAI SDK's chat.completions.create, validates response with safeParse(),
and returns discriminated union (success/error)
- Add error handling for API failures, network issues, and validation errors
- Include JSDoc comments for parameters and return types
- Add usage examples in top comments showing imports, example requests, response
handling, and environment setup

Optionally add /api/chat POST route example to fools/newLib.ts demonstrating
integration with Express endpoint.

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitai]

Coding Plan

Approach

Build a typed, validated LLM interface with OpenAI as the first provider, using a factory pattern that enables future support for additional providers like Anthropic.

Observations

This is a Zod v4 and Tailwind v4 demonstration project with an Express backend template (fools/newLib.ts) and comprehensive Zod validation patterns. The project uses environment variables for API credentials, axios for HTTP calls, and established patterns for request/response validation with discriminated unions. Currently lacks OpenAI integration and TypeScript configuration.

Assumptions

Assumption 1: Which OpenAI API methods to support initially

Options Considered:

• Start with only chat completions (most common LLM use case)
• Build comprehensive interface for all OpenAI services
• Focus on streaming chat completions for real-time responses

Chosen Option: Start with chat completions

Rationale: This is the primary LLM interface use case and allows for a focused, high-quality implementation following existing patterns. The service can be extended later for embeddings or other features as needed. Developers will appreciate having a working, well-validated chat interface immediately rather than a broader but less polished solution.

Assumption 2: Service location and structure

Options Considered:

• Create new service files in root directory alongside zod files
• Place in fools/ directory with other demo code
• Create dedicated services/ or lib/ directory for better organization

Chosen Option: Create in root directory

Rationale: This aligns with how Zod schemas are currently organized at the root level. Since this is a demonstration project without strict architectural boundaries, keeping the LLM service files at the root makes them easily discoverable and consistent with existing file organization patterns. Use separate files for common interface (llmProvider.ts), schemas (llmSchemas.ts), provider implementations (openaiProvider.ts), and factory (llmFactory.ts).

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Dependencies and Configuration Setup

Set up the required dependencies and TypeScript configuration to support multi-provider LLM integration with proper type safety.

Task 1: Install OpenAI SDK and Configure TypeScript

Add the official OpenAI package and create TypeScript configuration to ensure proper module resolution and type checking.

• Install openai package as a production dependency
• Create tsconfig.json in root directory with module resolution set to "node" or "bundler", target ES2020 or later, and strict mode enabled for type safety
• Configure include paths for all .ts files in root and fools/ directories
• Set up lib options to include ES2020+ features for async/await support

Task 2: Environment Configuration for API Keys

Establish environment variable pattern for LLM provider credentials following the existing pattern used for WEATHER_API_KEY and DATABASE_URL.

• Create .env.example file documenting OPENAI_API_KEY variable (and LLM_PROVIDER for factory selection)
• Add .env to .gitignore if not already present to prevent credential leakage
• Document the environment variable requirements in comments noting that ANTHROPIC_API_KEY can be added later

🤖 Prompt for AI agents

Set up dependencies and TypeScript configuration for multi-provider LLM
integration.

Install the OpenAI SDK:
- Add `openai` package as production dependency

Create tsconfig.json:
- Set module resolution to "node" or "bundler"
- Target ES2020 or later
- Enable strict mode
- Include all .ts files in root and fools/ directories
- Add ES2020+ lib options for async/await

Configure environment variables:
- Create .env.example with OPENAI_API_KEY and LLM_PROVIDER
- Add .env to .gitignore
- Document environment variable requirements with comments for future
ANTHROPIC_API_KEY

Phase 2: Core LLM Interface and Schema Design

Define the common interface and standardized schemas that all LLM providers must implement, enabling provider interchangeability.

Task 1: Define Common LLM Provider Interface

Create the abstract interface/type definitions that all providers (OpenAI, Anthropic) will implement.

• Create llmProvider.ts in root directory
• Define LLMProvider interface with methods:
  • chatCompletion() for sending messages and receiving responses
  • Optional future methods as comments (embeddings, streaming) as extension points
• Define provider-agnostic types for provider configuration and initialization
• Export interface with clear JSDoc comments explaining the contract

Task 2: Create Standardized Zod Schemas

Build provider-agnostic validation schemas following the CreateUserRequest/CreateUserResponse pattern from zodv4-examples.ts.

• Create llmSchemas.ts in root directory
• Define ChatMessage schema with role (enum: "system", "user", "assistant") and content (string)
• Define ChatRequest schema with messages array, temperature (optional number 0-2), max_tokens (optional number), and model (string for provider-specific model names)
• Define ChatResponse schema as discriminated union (following ApiResponse pattern from zodv4-features.ts) with:
  • Success variant containing response message, model used, and usage metadata
  • Error variant with error message and optional error code
• Export TypeScript types using z.infer pattern
• Include custom error messages for validation feedback

🤖 Prompt for AI agents

Define provider-agnostic LLM interface and validation schemas.

Create llmProvider.ts:
- Define LLMProvider interface with chatCompletion() method
- Add comments for future methods (embeddings, streaming)
- Include provider configuration types
- Add JSDoc documentation

Create llmSchemas.ts:
- Define ChatMessage schema with role enum ("system", "user", "assistant") and
content string
- Define ChatRequest schema with messages array, optional temperature (0-2),
optional max_tokens, and model string
- Define ChatResponse as discriminated union with success variant (response
message, model, usage metadata) and error variant (error message, optional error
code)
- Export TypeScript types using z.infer
- Add custom validation error messages

Phase 3: OpenAI Provider Implementation

Implement OpenAI as the first concrete provider, demonstrating the pattern for future Anthropic integration.

Task 1: Create OpenAI-Specific Schemas and Adapters

Build OpenAI-specific validation and transformation logic.

• Create openaiSchemas.ts in root directory
• Define OpenAI-specific request schema extending/mapping from common ChatRequest
• Add OpenAI model enum (gpt-4, gpt-3.5-turbo, gpt-4-turbo-preview, etc.)
• Create adapter functions to transform between common schemas and OpenAI SDK types
• Export transformation utilities for mapping OpenAI responses to common ChatResponse format

Task 2: Implement OpenAI Provider Class

Create the concrete OpenAI implementation of the LLMProvider interface.

• Create openaiProvider.ts in root directory
• Import OpenAI SDK and implement class/object that satisfies LLMProvider interface
• Initialize OpenAI client using process.env.OPENAI_API_KEY (following newLib.ts pattern)
• Implement chatCompletion method that:
  • Validates input using common ChatRequest schema with safeParse()
  • Transforms to OpenAI-specific format using adapters
  • Calls OpenAI SDK's chat.completions.create method
  • Transforms response back to common ChatResponse format
  • Returns discriminated union response (success/error)
• Add error handling for API failures, network issues, and validation errors
• Include JSDoc comments documenting the implementation

🤖 Prompt for AI agents

Implement OpenAI as the first concrete LLM provider.

Create openaiSchemas.ts:
- Define OpenAI-specific request schema extending common ChatRequest
- Add OpenAI model enum (gpt-4, gpt-3.5-turbo, gpt-4-turbo-preview)
- Create adapter functions to transform between common schemas and OpenAI SDK
types
- Export utilities for mapping OpenAI responses to common ChatResponse

Create openaiProvider.ts:
- Import OpenAI SDK and implement LLMProvider interface
- Initialize client with process.env.OPENAI_API_KEY
- Implement chatCompletion method:
  - Validate input with safeParse()
  - Transform to OpenAI format using adapters
  - Call chat.completions.create
  - Transform response to common ChatResponse
  - Return discriminated union (success/error)
- Handle API failures, network issues, and validation errors
- Add JSDoc documentation

Phase 4: Factory Pattern and Usage Integration

Create the factory method to instantiate providers and demonstrate usage within the codebase.

Task 1: Implement LLM Factory Method

Build the factory function that creates the appropriate provider instance based on configuration.

• Create llmFactory.ts in root directory
• Implement createLLMProvider factory function that:
  • Accepts provider name parameter (default from process.env.LLM_PROVIDER or "openai")
  • Uses switch/case or object mapping to instantiate correct provider
  • Returns LLMProvider interface instance
  • Throws descriptive error for unsupported providers
• Add placeholder case for "anthropic" with clear TODO comment explaining extension point
• Export factory function with TypeScript types and JSDoc documentation
• Document in comments how to add new providers (implement interface, add to factory)

Task 2: Create Usage Example Documentation

Provide clear documentation demonstrating how to use the LLM interface and factory pattern.

• Add comprehensive usage examples in comments at the top of llmFactory.ts showing:
  • How to import and call createLLMProvider factory
  • Example of creating provider and calling chatCompletion
  • How to handle success/error response variants
  • Environment setup requirements
• Optionally add example integration to fools/newLib.ts Express routes:
  • Create /api/chat route accepting POST requests
  • Use factory to get provider instance
  • Validate input with Zod schema
  • Call provider's chatCompletion method
  • Return JSON response with appropriate status codes
  • Demonstrate proper error handling

🤖 Prompt for AI agents

Create factory pattern for provider instantiation and usage documentation.

Create llmFactory.ts:
- Implement createLLMProvider factory function
- Accept provider name parameter (default from process.env.LLM_PROVIDER or
"openai")
- Use switch/case to instantiate correct provider
- Return LLMProvider interface instance
- Throw error for unsupported providers
- Add "anthropic" placeholder case with TODO comment
- Export with TypeScript types and JSDoc
- Document how to add new providers

Add usage documentation:
- Include comprehensive usage examples in llmFactory.ts comments showing import,
provider creation, chatCompletion call, response handling, and environment setup
- Optionally add /api/chat POST route to fools/newLib.ts demonstrating factory
usage, input validation, chatCompletion call, JSON response with status codes,
and error handling

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Set up dependencies and TypeScript configuration for multi-provider LLM
integration.

Install the OpenAI SDK:
- Add `openai` package as production dependency

Create tsconfig.json:
- Set module resolution to "node" or "bundler"
- Target ES2020 or later
- Enable strict mode
- Include all .ts files in root and fools/ directories
- Add ES2020+ lib options for async/await

Configure environment variables:
- Create .env.example with OPENAI_API_KEY and LLM_PROVIDER
- Add .env to .gitignore
- Document environment variable requirements with comments for future
ANTHROPIC_API_KEY
===============================================================================

Task: 2

Define provider-agnostic LLM interface and validation schemas.

Create llmProvider.ts:
- Define LLMProvider interface with chatCompletion() method
- Add comments for future methods (embeddings, streaming)
- Include provider configuration types
- Add JSDoc documentation

Create llmSchemas.ts:
- Define ChatMessage schema with role enum ("system", "user", "assistant") and
content string
- Define ChatRequest schema with messages array, optional temperature (0-2),
optional max_tokens, and model string
- Define ChatResponse as discriminated union with success variant (response
message, model, usage metadata) and error variant (error message, optional error
code)
- Export TypeScript types using z.infer
- Add custom validation error messages
===============================================================================

Task: 3

Implement OpenAI as the first concrete LLM provider.

Create openaiSchemas.ts:
- Define OpenAI-specific request schema extending common ChatRequest
- Add OpenAI model enum (gpt-4, gpt-3.5-turbo, gpt-4-turbo-preview)
- Create adapter functions to transform between common schemas and OpenAI SDK
types
- Export utilities for mapping OpenAI responses to common ChatResponse

Create openaiProvider.ts:
- Import OpenAI SDK and implement LLMProvider interface
- Initialize client with process.env.OPENAI_API_KEY
- Implement chatCompletion method:
  - Validate input with safeParse()
  - Transform to OpenAI format using adapters
  - Call chat.completions.create
  - Transform response to common ChatResponse
  - Return discriminated union (success/error)
- Handle API failures, network issues, and validation errors
- Add JSDoc documentation
===============================================================================

Task: 4

Create factory pattern for provider instantiation and usage documentation.

Create llmFactory.ts:
- Implement createLLMProvider factory function
- Accept provider name parameter (default from process.env.LLM_PROVIDER or
"openai")
- Use switch/case to instantiate correct provider
- Return LLMProvider interface instance
- Throw error for unsupported providers
- Add "anthropic" placeholder case with TODO comment
- Export with TypeScript types and JSDoc
- Document how to add new providers

Add usage documentation:
- Include comprehensive usage examples in llmFactory.ts comments showing import,
provider creation, chatCompletion call, response handling, and environment setup
- Optionally add /api/chat POST route to fools/newLib.ts demonstrating factory
usage, input validation, chatCompletion call, JSON response with status codes,
and error handling

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord or schedule a call!

[gowthamkishore3799]

@coderabbitai can you add a factory method which can support anthropic in later

[coderabbitai]

I've updated the plan above based on your feedback. Ready to proceed when you are!

[coderabbitaidev]

I've updated the plan above based on your feedback. Ready to proceed when you are!