6 views
-/https://github.com/berriai/litellm/issues/31568
GitHub · issue

#31568 [Feature]: Add OpenCode Go provider

  • State: open
  • Author: @cogentParadigm
  • Labels: enhancement, proxy, llm translation

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

I would like to have OpenCode Go as a provider. Some things to note from the OpenCode client's implementation of the OpenCode Go provider:

- It loads cost information from https://models.dev/api.json. - It uses an openai style endpoint by default, but some models use anthropic style endpoints. This is indicated in the models.dev endpoint when a model has provider.npm = "@ai-sdk/anthropic".

### Motivation, pitch

Adding a custom provider would allow:

- available models to be loaded automatically - token usage costs to be calculated - The correct provider to be listed in Usage

### What part of LiteLLM is this about?

Proxy

### LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

No

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (20 events)
#0 of 0 · 31d18h40m37s ago — entered · #import:https:::github.com:berriai:litellm post #2396
OpenCode Go requires a new provider integration spanning model discovery, dynamic pricing, protocol selection, request translation, and usage attribution, creating substantially more cross-cutting implementation and compatibility risk. The metrics issue is comparatively localized to configuration validation and metric registration behavior.
The right-hand task is harder because it introduces a provider integration spanning discovery, pricing metadata, endpoint selection, proxy behavior, authentication, and broader compatibility testing. The left-hand task is comparatively bounded to extending existing multimodal request translation and validation paths.
The Rust migration is a sweeping, cross-cutting architectural rewrite involving compatibility, performance, security-sensitive gateway paths, rollout coordination, and extensive regression testing. The provider addition is comparatively contained, primarily requiring API translation, model metadata, pricing, and proxy integration.
The left issue requires diagnosing and correcting distributed state consistency under retries, timeouts, concurrency, and multi-pod failure modes, with safeguards against financial mis-enforcement and regression testing. The right issue is a bounded provider integration involving request translation, model metadata, pricing, and usage reporting, with comparatively clearer implementation boundaries.
The OpenCode Go work spans a new provider integration, model and pricing discovery, multiple protocol translations, proxy registration, and broader compatibility testing. The Azure failure is narrower in surface area, though it requires tracing parameter propagation across the LangChain adapter, router, bridge, and Azure request construction.
The compatibility-matrix work is harder because it spans broad test infrastructure, multiple provider paths, client-behavior coverage, fixtures, and CI integration, creating substantially more coordination and regression risk than adding one provider with metadata, routing, and cost integration.
Monthly call limits require coordinated changes across quota state, persistence, concurrency-safe enforcement, calendar/timezone handling, warning semantics, APIs, and UI. The provider addition is narrower, mainly involving routing, model metadata, cost attribution, and integration tests.
The right issue is harder because it requires coordinated changes across request parsing, multipart/image translation, provider-specific payload construction, compatibility behavior, and regression coverage. The left issue is a more contained provider integration involving routing, model metadata, pricing, and endpoint selection.
The left task requires concurrency-safe distributed state handling, atomicity, race-condition validation, and asynchronous reliability work across shared accounting paths. The right task is a more bounded provider integration with model metadata, routing, and cost translation.
The left issue is harder because it requires a new provider integration spanning model discovery, pricing metadata, request-format routing, proxy behavior, and broad compatibility testing. The right issue is more narrowly scoped to diagnosing and correcting an existing request-path or caching regression.
Adding a new provider spans provider registration, model discovery, pricing integration, endpoint translation, proxy behavior, and broad compatibility testing. The Bedrock issue is narrower, centered on correcting existing model-specific structured-output routing and configuration, though it carries some API-compatibility risk.
The streaming lifecycle bug is harder because it requires tracing asynchronous response termination, exception propagation, callback invocation, and regression coverage across proxy execution paths. The provider addition is broader in integration points but follows established provider and metadata patterns, making its implementation more predictable.
The right issue is harder because it spans authorization boundaries, privacy-safe data scoping, aggregation across usage records, API design, and frontend work while preserving existing administrative behavior. The left issue is a comparatively contained provider adapter with model metadata, pricing, and protocol-selection integration.
OpenCode Go spans provider registration, model discovery, external metadata synchronization, pricing, endpoint-shape detection, request translation, and usage attribution across proxy paths. Stable key IDs are a more contained schema/API and rotation-flow change, though they require migration and backward compatibility.
The cache-consistency fix is harder because it requires diagnosing and safely coordinating cross-process state invalidation, Redis Pub/Sub delivery, worker lifecycle, race conditions, and multi-worker testing. The provider addition is broader than a simple adapter but can mostly follow established provider, metadata, and pricing integration patterns.
A new provider requires broader integration across model discovery, endpoint translation, pricing, usage accounting, configuration, and compatibility testing. The other task is comparatively localized to preserving an existing alias through one streaming observability path, with a narrower regression surface.
OpenCode Go requires a new provider integration spanning routing, model discovery, endpoint compatibility, pricing metadata, usage attribution, proxy behavior, and broad test coverage. The RAGFlow item is more likely a focused compatibility or response-parsing fix within an existing integration, with narrower scope and lower regression risk. Overall effort is estimated at roughly 3:1.
Issue 31835 is substantially harder because it spans persistent data correction, versioned pricing, policy configuration, idempotent execution, auditability, and administrative API design. Issue 31568 is comparatively contained provider integration work, mainly involving routing, model metadata, and pricing translation.
Issue 23841 is harder because it spans multiple translation paths and compatibility behaviors, requiring careful regression testing across request formats and downstream APIs. Issue 31568 is comparatively bounded provider onboarding with endpoint selection, model metadata, and pricing integration.
#0 of 0 · 31d17h35m52s ago — current · #import:https:::github.com:berriai:litellm post #3480
The right issue is harder because it spans authentication middleware, standards-compliant discovery endpoints, external identity-provider configuration, client interoperability, and security-focused testing. The left issue is comparatively contained within provider registration, model metadata, request translation, and pricing integration.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search