Feature Request: OpenAI-compatible base_url support (Cerebras, Groq, Ollama, LMStudio)

[tailorgunjan93]

Feature Request: OpenAI-compatible base_url config

Problem

Currently git-lrc only supports 5 hardcoded AI providers (Gemini, OpenAI, Claude, DeepSeek, OpenRouter).
Many popular providers — Cerebras, Groq, Ollama, LMStudio, Together AI — all expose an
OpenAI-compatible API but cannot be used today.

Proposed Solution

Add an openai_compat connector type with a configurable base_url and model field:

# ~/.lrc.toml
[[connector]]
type     = "openai_compat"
base_url = "https://api.cerebras.ai/v1"
api_key  = "your-key"
model    = "llama-3.3-70b"

Since the existing OpenAI connector already handles auth + chat completions,
this would reuse that code with just the base URL swapped out.

Why This Matters

• Cerebras — free tier, ultra-fast inference
• Groq — free tier, very fast
• Ollama / LMStudio — 100% local, no data leaves the machine
• One change unlocks dozens of providers for free-tier users

Implementation Hint

In the OpenAI connector, replace the hardcoded base URL:

// Before
baseURL := "https://api.openai.com/v1"

// After
baseURL := cfg.GetString("connector.base_url", "https://api.openai.com/v1")

This is a low-effort, high-impact change.

[richardchen874-sys]

This would be a high-impact addition.

I agree that an openai_compat connector is probably the cleanest design, but I’d avoid treating it as only a base URL swap. Once users start adding Cerebras, Groq, Ollama, LMStudio, Together, or private gateways, a few provider-specific differences can show up quickly:

• model ID format
• streaming behavior
• max token / context limits
• error mapping for 429 / 5xx responses
• local endpoint vs remote endpoint security
• whether tool/function calling is supported or ignored
• whether the provider follows /v1/chat/completions strictly

A config like type, base_url, api_key, and model would solve the first step, but it may also be useful to support an optional provider_name or profile field for logging/debugging.

For independent developers using AI inside Git workflows, this would make git-lrc much more flexible: local models for privacy, free-tier providers for experiments, and lower-cost API providers for daily usage.

The main thing I’d test is not just whether the first request succeeds, but whether streaming, retries, and long-context requests behave consistently across providers.