FR : LMArenaBridge incorporation

[sudosign]

Adding https://github.com/CloudWaddie/LMArenaBridge

More diverse set + more apis?

[mirrobot-agent]

@sudosign Thank you for submitting this feature request. I am now beginning my analysis and will report back shortly.

[mirrobot-agent]

Initial Analysis Report

Summary: This is a feature request to integrate LMArenaBridge, a third-party project that provides an OpenAI-compatible API endpoint to interact with models on LM Arena (lmarena.ai).

Issue Validation: Needs More Info

Reproducibility Assessment: N/A (Feature Request)

Root Cause Analysis:
This is not a bug but a feature request to add a new provider integration. LMArenaBridge is an external project that:

1. Purpose: Provides an OpenAI-compatible API that bridges to LM Arena, enabling access to various LLM models including "stealth models" not officially listed
2. Authentication: Uses browser cookies (arena-auth-prod-v1 token) scraped from the LM Arena website for authentication
3. Architecture: Runs its own server on port 8000 with a /api/v1/ endpoint

Integration Feasibility Assessment:

Aspect	Current LLM-API-Key-Proxy	LMArenaBridge
Auth Type	OAuth/API Keys	Browser Cookies
API Format	OpenAI-compatible	OpenAI-compatible ✅
Key Rotation	Full support	Not applicable (single session)
Credential Management	Automated discovery	Manual cookie extraction

Key Technical Considerations:

1. Cookie-based Auth Complexity: LMArenaBridge uses arena-auth-prod-v1 and cf_clearance cookies which are session-bound and can expire frequently, making them unsuitable for the current credential rotation architecture in src/rotator_library/client.py

2. Integration Paths:

   • Option A (Direct): Add a new provider plugin in src/rotator_library/providers/ following the ProviderInterface pattern — would require adapting cookie-based auth
   • Option B (Upstream Proxy): Use LMArenaBridge as an upstream OpenAI-compatible API via the existing DynamicOpenAICompatibleProvider system using environment variables like LMARENA_API_BASE

3. Terms of Service Concerns: LM Arena is a research project and using automated access may violate their ToS

Suggested Labels: enhancement, feature-request, needs-discussion

Proposed Next Steps:

1. Clarify the integration approach preferred by the maintainers (direct vs upstream proxy)
2. Evaluate ToS implications of automated access to LM Arena
3. If proceeding, start with Option B (upstream proxy) as it requires minimal code changes:

   # Run LMArenaBridge separately, then configure:
   LMARENA_API_BASE="http://localhost:8000/api/v1"
   LMARENA_API_KEY_1="dummy-key"
   LMARENA_MODELS='["gpt-4o", "claude-3-opus", "gemini-pro"]'

Missing Information (if any):

• What specific "more diverse set + more apis" models are you hoping to access via LM Arena?
• Are you looking for direct integration into this proxy, or would using LMArenaBridge as an upstream API suffice?
• Have you verified the models you need are available on LM Arena and accessible via LMArenaBridge?

---

This analysis was generated by an AI assistant.