mirror of
https://github.com/BerriAI/litellm.git
synced 2026-10-07 02:59:05 +00:00
c8635ecc67
* feat(ui): page the public model hub table off /public/v1/model_hub The public Model Hub page loaded every published model group in one call and did all of its searching, sorting and filtering in the browser, so a proxy with a few thousand groups sent megabytes to render one screen. The models table now asks /public/v1/model_hub for one page at a time. Paging, sorting, search and the provider and mode filters are query parameters on that route, and the pagination footer counts from the response envelope's total_count rather than the rows on screen. Column sortability is derived from the fields the route declares sortable, so a header can no longer ask it for a sort it answers with a 400. The feature filter is dropped: supports_* are booleans and the route has no boolean filter, so it could only ever have filtered the page in view. * fix(ui): offer the model modes litellm actually prices in the hub filter The mode filter listed 'moderations', which no model group's mode is ever set to, so picking it could only ever return nothing; 'anthropic_messages' was dead the same way. Four real modes the catalogue does use, search, ocr, guardrail and vector_store, were missing entirely. The list is now the mode vocabulary in model_prices_and_context_window.json, and a test reads that file so an option that matches nothing, or a mode with no option, fails instead of silently filtering to an empty table. A failed page fetch logs the route's error detail again, as it did before the table moved to the paginated route. * test(ui): keep the model hub health rows out of the inline-object budget frontend-lint's local/no-large-inline-object-arg budget went 555 to 556: the health check rows became arguments to the row helper. They are plain literals spreading a shared default again, which is what they were before, and the gate reports 554 against a max of 555. * feat: keep every model hub filter when the table pages Moving the table onto /public/v1/model_hub cost it two controls the route could not serve: the provider filter fell back to one substring because providers only declared contains, and the feature filter went away entirely because supports_* are booleans with no filter at all. Options for the dropdowns went with them, since a page of rows only knows the values on that page. The route now declares providers in, a features field whose value is the capability names a row has, and providers, rpm and tpm as sortable. Features is one repeated field rather than a boolean per flag so selecting two of them matches either, which is what the multi-select has always meant. Three facet routes serve the distinct providers, modes and features across the published groups, carrying the parent's filters, per section 12 of the list design. All of it is additive: the route rejects unknown parameters, so no request that worked before changes, and the design's stability policy calls new filters and parameters safe within a version. Health status stays unsortable. Health is read for the rows on the page, and ordering the match set by it would mean reading it for every published group, which is the cost the paging exists to avoid. * fix(ui): put the model hub facet types where the generator emits them The generated file lists paths in sorted order and operations in path order. Both new blocks were spliced in one entry too late, after /queue/chat/completions rather than before it, so the schema.d.ts sync check regenerated the file and found them misplaced. Same blocks, byte for byte, moved to the position the generator gives them. * fix(proxy): type a facet payload as the sequence the framework hands it The lint job's basedpyright gate flagged one new reportArgumentType: handle_facet passes a tuple, and FacetListResponse declared data as list[str]. A list would have traded that error for an LIT002 mutable construction, and both budgets are already at their ceiling on the base. Sequence[str] is what the framework actually produces and what the model always accepted: pydantic emits the same array schema either way, verified against model_json_schema, so the OpenAPI spec and schema.d.ts are unchanged, and the existing list-passing caller in spend_logs still type checks. * test(proxy): pin the facet route's rejection contract handle_facet answers six ways before it ever reaches the executor, and none of them was covered: a denied scope, a filter operator the spec does not offer, a repeated parameter, a non-positive page or page_size, and the where clause those last two feed. Every one is a 400 or 403 an unauthenticated caller can reach, so each gets a test that fails when the branch stops firing. |
||
|---|---|---|
| .. | ||
| public | ||
| scripts | ||
| src | ||
| tests | ||
| .env.development | ||
| .env.production | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc | ||
| build_release_ui.sh | ||
| build_ui.sh | ||
| build_ui_custom_path.sh | ||
| CLAUDE.md | ||
| components.json | ||
| eslint-budgets.json | ||
| eslint-suppressions.json | ||
| eslint.config.mjs | ||
| knip.json | ||
| next.config.mjs | ||
| package-lock.json | ||
| package.json | ||
| postcss.config.js | ||
| README.md | ||
| tsconfig.json | ||
| tsconfig.tsbuildinfo | ||
| vitest.config.ts | ||
This is a Next.js project bootstrapped with create-next-app.
Getting Started
First, run the development server:
npm run dev
# or
yarn dev
# or
pnpm dev
# or
bun dev
Open http://localhost:3000 with your browser to see the result.
You can start editing the page by modifying app/page.tsx. The page auto-updates as you edit the file.
This project uses next/font to automatically optimize and load Inter, a custom Google Font.
Learn More
To learn more about Next.js, take a look at the following resources:
- Next.js Documentation - learn about Next.js features and API.
- Learn Next.js - an interactive Next.js tutorial.
You can check out the Next.js GitHub repository - your feedback and contributions are welcome!
Deploy on Vercel
The easiest way to deploy your Next.js app is to use the Vercel Platform from the creators of Next.js.
Check out our Next.js deployment documentation for more details.