7 views
-/https://github.com/berriai/litellm/issues/24109
GitHub · issue

#24109 [Feature]: Provide either `/info` or `/version` API endpoint to expose LiteLLM version

  • State: open
  • Author: @dan2k3k4
  • Labels: enhancement

### Check for existing issues

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

### The Feature

I see that the info is in the `openapi.json` file via `info.version` like so:

``` { openapi: "3.1.0", info: { title: "LiteLLM API", version: "1.82.0" } } ```

A `/info` endpoint to expose the info (including title, description) or a `/version` endpoint to only expose the version, might be useful to some people.

### Motivation, pitch

I have various LiteLLMs in different regions, but rollout version changes to only some of them for test purposes.

I want to be able to easily query for the version, although I could look into grepping the `openapi.json` document instead, which I only realised had it while writing this issue out, figured I'd post as an issue in case others find it useful.

### What part of LiteLLM is this about?

Other

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

No

### Twitter / LinkedIn details

_No response_

GitHub resolver

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

Refresh page
vote history (1 events)
#0 of 0 · 31d17h52m58s ago — entered · #import:https:::github.com:berriai:litellm post #2988
The right issue is harder because it requires tracing and correcting provider metadata propagation across multiple request paths and the budget-limiter callback, with regression coverage for integrations that currently succeed but emit failures. The left issue is a narrowly scoped API addition with limited implementation and testing risk.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search