Summary
The recommendations feature currently uses Claude (Anthropic) exclusively. Adding OpenAI as an alternative provider would let users bring their own OpenAI API key instead of — or in addition to — an Anthropic one.
Motivation
Not everyone has an Anthropic API key. OpenAI's models (GPT-4o, o1, o3) are widely used and a natural alternative for this kind of taste-matching recommendation task.
Proposed approach
- Introduce a
RECOMMENDATION_PROVIDER env var (anthropic | openai, defaulting to anthropic)
- Add
OPENAI_API_KEY env var alongside the existing ANTHROPIC_API_KEY
- Abstract the recommendation call behind a provider interface in
src/lib/recommendations.ts so the prompt logic is shared and only the API call differs
- Update
.env.example and the README configuration table
- Graceful degradation: if neither key is set, the recommendations page returns 503 as it does today
Open questions
- Should both providers be supported simultaneously (let the user pick in the UI), or is env-var selection enough?
- Which OpenAI model is the right default? GPT-4o is the obvious choice but o1/o3 may give better reasoning for taste-matching.
Summary
The recommendations feature currently uses Claude (Anthropic) exclusively. Adding OpenAI as an alternative provider would let users bring their own OpenAI API key instead of — or in addition to — an Anthropic one.
Motivation
Not everyone has an Anthropic API key. OpenAI's models (GPT-4o, o1, o3) are widely used and a natural alternative for this kind of taste-matching recommendation task.
Proposed approach
RECOMMENDATION_PROVIDERenv var (anthropic|openai, defaulting toanthropic)OPENAI_API_KEYenv var alongside the existingANTHROPIC_API_KEYsrc/lib/recommendations.tsso the prompt logic is shared and only the API call differs.env.exampleand the README configuration tableOpen questions