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

#29961 How should an independent OpenAI-compatible gateway be represented in model_prices_and_context_window.json?

  • State: open
  • Author: @Lwoxs
  • Labels: llm translation

Hi LiteLLM maintainers,

I would like to add pricing metadata for Starveri API, an independent OpenAI-compatible GPT/Codex API gateway with public model metadata and a direct prepaid-credit buyer path.

Before opening a PR, I wanted to ask which provider representation you prefer for independent OpenAI-compatible gateways. I checked model_prices_and_context_window.json and did not find current entries using litellm_provider: custom_openai, so I do not want to submit a shape that does not fit your conventions.

Public source links: - Pricing / buyer page: https://api.starveri.net/credits - Public model metadata: https://api.starveri.net/models - Docs: https://api.starveri.net/docs - OpenAPI: https://api.starveri.net/openapi.yaml - LLM discovery: https://api.starveri.net/llms.txt

Canonical public models: - gpt-5.1-codex - gpt-5.3-codex-spark - gpt-5.3-codex - gpt-5.4 - gpt-5.4-mini - gpt-5.5

The public /models endpoint exposes USD per 1M token prices for cached input, input, and output. It also exposes non-billable global model-spec metadata.

Would you prefer: 1. Dedicated model keys such as starveri/gpt-5.5 with a Starveri-specific provider name, 2. A custom OpenAI-compatible pro…

GitHub resolver

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

Refresh page
vote history (2 events)
#0 of 0 · 31d19h1m49s ago — entered · #import:https:::github.com:berriai:litellm post #1850
The right issue is harder because it requires debugging provider-specific request translation, validating AWS API semantics, preserving existing caching behavior, and adding regression coverage. The left issue is primarily a convention and metadata/configuration decision with comparatively limited implementation scope.
#0 of 0 · 31d18h16m57s ago — current · #import:https:::github.com:berriai:litellm post #2580
The right issue is harder because it requires determining and validating a provider-representation convention, assessing compatibility with existing pricing metadata and routing behavior, and potentially covering several models and integration edge cases. The left issue is a localized catalog and backup-data update with minimal implementation risk.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search