-/https://github.com/berriai/litellm/issues/33921

9 views

-/https://github.com/berriai/litellm/issues/33921

GitHub · issue

#33921 [Feat]: Add native API support for Kimi K3 (Moonshot AI), Inkling, and Tinker platform

State: open
Author: @Tibo2403
Labels: llm translation

### Feature Request Description We need native, first-class support in LiteLLM for three recently released models and training/inference platforms to use them seamlessly within our pipelines (Python SDK & Proxy server): 1. **Kimi K3** (Moonshot AI) 2. **Inkling** (Thinking Machines Lab) 3. **Tinker Platform** (Thinking Machines Lab)

Currently, these models require raw OpenAI-compatible custom configurations. Adding native mappings will vastly simplify routing, accurate cost tracking, and specialized parameters (like Kimi K3's reasoning token management).

### Requested Mappings & API Specs

#### 1. Kimi K3 (Moonshot AI) - **Model Identifier:** `moonshot/kimi-k3` - **Base URL:** `https://moonshot.ai` - **Key Specs:** 2.8T Mixture-of-Experts, 1M context window, native vision input, and automatic context caching. - **Special Feature:** Support for the new `thinking_effort` parameter (`Standard`, `High`, `Max`) mapping, which dictates the reasoning tokens budget.

#### 2. Inkling (Thinking Machines Lab) - **Model Identifiers:** `together_ai/thinkingmachines/inkling`, `inkling` (for native engines like vLLM / SGLang) - **Key Specs:** 975B MoE frontier model, native multimodal handling …

GitHub resolver

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

vote history (13 events)

#0 of 0 · 31d18h35m4s ago — entered · #import:https:::github.com:berriai:litellm post #2288

-/https://github.com/berriai/litellm/issues/33921⭐5:1-/https://github.com/berriai/litellm/issues/35131

The left issue spans multiple providers, model families, API mappings, parameter translation, multimodal behavior, cost metadata, and both SDK and proxy integration, creating substantially broader implementation and validation risk. The right issue is a focused proxy background-job state and persistence bug with a narrower investigation and fix surface.

#0 of 0 · 31d18h17m29s ago · #import:https:::github.com:berriai:litellm post #2560

-/https://github.com/berriai/litellm/issues/33921⭐3:2-/https://github.com/berriai/litellm/issues/34998

#33921 is harder because it spans multiple provider integrations, model mappings, parameter translation, and cost/routing validation. #34998 is a focused authorization-data-flow defect, though it still requires careful changes across session context, team lookup, and dashboard behavior.

#0 of 0 · 31d17h21m50s ago · #import:https:::github.com:berriai:litellm post #3513

-/https://github.com/berriai/litellm/issues/33921⭐3:2-/https://github.com/berriai/litellm/issues/28032

Supporting several distinct provider integrations across SDK and proxy layers carries greater implementation risk due to differing APIs, request/response translation, streaming, authentication, parameter semantics, and cost metadata. The access-group change is broader in authorization design but is largely one subsystem, with recursion, cycle prevention, persistence, and cache/invalidation concerns.

#0 of 0 · 31d17h21m46s ago · #import:https:::github.com:berriai:litellm post #3514

-/https://github.com/berriai/litellm/issues/304603:1-/https://github.com/berriai/litellm/issues/33921⭐

The left issue is harder because it involves diagnosing and correcting distributed state consistency under Redis failures, transactional buffering, concurrency, and budget-enforcement correctness. The right issue is broader in coverage but primarily consists of provider integrations, model mappings, parameter translation, and validation, making its risk and architectural depth lower.

#0 of 0 · 31d17h21m36s ago · #import:https:::github.com:berriai:litellm post #3516

-/https://github.com/berriai/litellm/issues/347333:2-/https://github.com/berriai/litellm/issues/33921⭐

34733 is harder because it requires designing and validating atomic distributed accounting behavior across concurrent workers, coordinating related state updates, and correcting asynchronous persistence semantics without regressions. 33921 is broader than a single model mapping but is mainly an integration and parameter-support task across established provider abstractions.

#0 of 0 · 31d17h21m19s ago · #import:https:::github.com:berriai:litellm post #3519

-/https://github.com/berriai/litellm/issues/312963:1-/https://github.com/berriai/litellm/issues/33921⭐

Inbound authentication discovery touches security-sensitive proxy behavior, standards-compliant metadata, HTTP challenge semantics, configuration, and client interoperability, creating substantially higher implementation and regression risk. The other issue is primarily a bounded set of provider adapters, model mappings, parameter translation, and cost metadata.

#0 of 0 · 31d17h17m36s ago · #import:https:::github.com:berriai:litellm post #3565

-/https://github.com/berriai/litellm/issues/33921⭐4:1-/https://github.com/berriai/litellm/issues/32140

Supporting multiple new provider integrations across SDK, proxy, model mapping, parameter translation, cost tracking, and compatibility testing has substantially broader scope and higher integration risk than a focused routing/signature-handling bug fix.

#0 of 0 · 31d17h17m31s ago · #import:https:::github.com:berriai:litellm post #3566

-/https://github.com/berriai/litellm/issues/33921⭐3:1-/https://github.com/berriai/litellm/issues/30641

Three independent provider integrations require broader API-translation work, model metadata and pricing coverage, parameter compatibility, authentication, and regression testing. The other task is primarily a focused configuration-to-dashboard exposure change, with some security and deployment-environment complexity but a narrower implementation surface.

#0 of 0 · 31d17h17m21s ago · #import:https:::github.com:berriai:litellm post #3568

-/https://github.com/berriai/litellm/issues/33921⭐5:3-/https://github.com/berriai/litellm/issues/34732

Supporting three distinct provider/platform integrations entails broader adapter work, API compatibility, parameter and cost-mapping validation, and substantially more test coverage than correcting one shared admission-control race with an atomic coordination mechanism.

#0 of 0 · 31d17h17m16s ago · #import:https:::github.com:berriai:litellm post #3569

-/https://github.com/berriai/litellm/issues/33921⭐5:4-/https://github.com/berriai/litellm/issues/33666

Supporting three distinct provider/platform integrations across SDK, proxy routing, parameter translation, multimodal behavior, and cost accounting creates broader compatibility and testing scope than isolating and bounding a single database access path.

#0 of 0 · 31d17h17m9s ago · #import:https:::github.com:berriai:litellm post #3570

-/https://github.com/berriai/litellm/issues/33921⭐4:1-/https://github.com/berriai/litellm/issues/26535

The right issue is harder because it requires multiple native platform integrations with provider-specific routing, parameter handling, metadata, and broad SDK/proxy test coverage. The left issue is primarily structured validation and CI coverage for an existing implementation, with more bounded engineering risk.

#0 of 0 · 31d17h17m3s ago · #import:https:::github.com:berriai:litellm post #3571

-/https://github.com/berriai/litellm/issues/33921⭐3:2-/https://github.com/berriai/litellm/issues/34328

The left issue is harder because it spans three provider integrations, cross-cutting model metadata, parameter translation, cost accounting, and compatibility across both SDK and proxy paths. The right issue has greater algorithmic risk but a narrower implementation surface focused on a shared expansion routine and its callers.

#0 of 0 · 31d17h16m59s ago — current · #import:https:::github.com:berriai:litellm post #3572

-/https://github.com/berriai/litellm/issues/333713:1-/https://github.com/berriai/litellm/issues/33921⭐

Issue 33371 is harder because it requires designing and integrating a durable cross-layer error and routing-health contract, with compatibility, classification semantics, and consumer-facing API implications. Issue 33921 is broader in provider count but is comparatively bounded to conventional provider mappings, parameter handling, and integration tests.

discussed in #import:https:::github.com:berriai:litellm

ranked child groups
scope depth

no voted pairs yet in this scope

cli

spread