Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Feature: Translate between chat completions and Responses API (maybe even Anthropic API?) across providers

Aperta
  • Qualcosa non va?
#723 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
backend-api-design

Direzione di ricerca

Start with the existing adapter in internal/providers/responses_adapter.go, the stream converter in internal/providers/responses_converter.go, and the chatgpt provider methods in internal/providers/chatgpt/chatgpt.go; read ADR-0002 and ADR-0007 for the boundary design. Issue #1084 specifies the first implementation slice, while #1055 flags a known translation-loss concern. Done means chat requests can reach Responses-only providers with responses converted back, including streaming, usage, and the stated ID and chaining semantics.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Is your feature request related to a problem? Please describe.

The new chatgpt provider (#718) serves only the Responses API. The Codex
backend behind a ChatGPT subscription has no chat completions endpoint.
ChatGPT and Codex subscription tokens now work through the Responses API only.

A client that calls /v1/chat/completions on a chatgpt model gets
501 unsupported_provider_operation. The provider returns this from
ChatCompletion and StreamChatCompletion
(internal/providers/chatgpt/chatgpt.go).

This blocks real setups:

  • A harness that speaks only chat completions, for example Kimi Code CLI,
    cannot use ChatGPT subscription models.
  • An Anthropic harness on /v1/messages cannot use them either. GoModel
    translates the Anthropic dialect to the canonical chat request at ingress
    (ADR-0007). The request then hits the same 501.
  • A virtual model that mixes chatgpt with chat-native providers is
    unreliable. Failover treats the 501 as eligible and skips the provider
    (internal/gateway/failover.go). A mixed pool loses capacity instead of
    using it.
Image
  • The reverse direction works today. ResponsesViaChat
    (internal/providers/responses_adapter.go) lets chat-only providers serve
    /v1/responses. Providers like kilo, groq, gemini, bedrock, ollama, cohere,
    and vertex use it through openai.ChatCompatible. The Anthropic ingress
    (ADR-0007) proves dialect translation at the boundary for a third API shape.
    Only one direction is missing: chat completions in, Responses out.

Describe the solution you'd like

Goal: the client dialect and the provider dialect should be independent.
GoModel translates between them on the fly.

This issue uses "dialect" for one API format: chat completions, Responses,
or Anthropic Messages. This table shows the desired state:

Client calls Provider serves Today
/v1/chat/completions chat completions works
/v1/responses chat completions works (ResponsesViaChat)
/v1/messages chat completions works (ADR-0007)
/v1/responses Responses works (native)
/v1/chat/completions Responses only (chatgpt) 501
/v1/messages Responses only (chatgpt) 501

The two 501 rows share one gap: no conversion from a chat request to a
Responses request.

Expected logic:

  1. A client request arrives in any supported dialect.
  2. GoModel resolves the model to a provider, as today.
  3. GoModel checks which dialect the provider serves.
  4. If the dialects differ, GoModel converts the request to the provider
    dialect.
  5. GoModel converts the response back to the client dialect. Streaming
    responses convert event by event.
  6. Usage, budgets, cache, failover, and audit keep working on the canonical
    request, as today.

Virtual models then work across API types. Load balancing can mix a chat-only
provider and a Responses-only provider in one pool.

Conversion must follow the existing Postel's Law rule: translate what is
portable, drop or reject what is not, and document the loss. Known hard
points:

  • Some chat fields have no Responses equivalent, for example n > 1 and
    logit_bias. Decide per field: convert, drop, or reject.
  • Usage shapes differ (prompt_tokens against input_tokens). Cost tracking
    and budgets must see correct numbers.
  • The Codex backend accepts a strict parameter allowlist and streams only.
    The chatgpt provider already adapts this for direct Responses calls. The
    translated path must reuse that adaptation.
  • Chat completions is stateless. Responses features that need server state
    (previous_response_id, conversations) stay Responses-only.

I do not propose a specific implementation. Two directions look consistent
with the current design, for orientation:

  • Mirror the existing adapter: add the reverse of ResponsesViaChat, and
    let Responses-only providers delegate their chat methods to it.
  • Make dispatch capability-aware: providers declare the dialects they serve,
    and the gateway inserts conversion where dialects differ. This also lets
    failover and virtual-model balancing prefer native targets.

Describe alternatives you've considered

  • Keep the 501 and document it. Works for Codex itself. Does not work for
    chat-only or Anthropic harnesses.
  • Put a shim in front of GoModel per client. Duplicates gateway work outside
    the gateway.
  • Extend passthrough. Passthrough forwards bytes unchanged and cannot convert
    dialects. chatgpt is not in the passthrough allowlist.
  • Rely on failover. Failover skips the incompatible provider. Capacity stays
    unused, and a pool with only chatgpt targets still fails.

Additional context

  • @SantiagoDePolonia asked for this to be moved to an issue from Discord DMs for broader evaluation.
  • Implementation issue: #1084 specifies the first slice (chat to Responses
    adapter plus chatgpt provider wiring, ID and chaining semantics).
  • Known translation-loss point: #1055 (tool strict dropped on the Anthropic
    and Gemini output paths).
  • Related material:
    • ADR-0002: dialect translation belongs at the ingress boundary.
    • ADR-0007: Anthropic Messages ingress, the same pattern for a third
      dialect.
    • docs/advanced/responses-compatibility.mdx: the existing compatibility
      matrix. This feature adds the reverse direction.
    • internal/providers/responses_adapter.go: the existing one-way adapter.
    • internal/providers/responses_converter.go: the existing stream
      converter for the Responses direction.
    • PR #718: the chatgpt provider.

This issue was drafted with AI assistance (Kimi Code CLI). The AI analyzed
the codebase at commit 0a174082.

Lingua principale
Go
Stelle
1.2k
Fork
111
Merge medio
14h 43m
PR unite (30g)
142

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ENTERPILOT/GoModel

Tutte le issue di ENTERPILOT/GoModel

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.