14 views
-/https://github.com/berriai/litellm/issues/30421
GitHub · issue

#30421 [Feature]: lite cli: add launch agent cli ability just like `ollama launch` do

  • State: open
  • Author: @evan0greenup
  • Labels: enhancement, proxy, llm translation

### Check for existing issues

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

### The Feature

# What this feature is?

a subcommand like `lite launch <agent-tool>` , where `<agent-tool>` can be `claude`, `codex`, `opencode`, `openclaw`, `hermes` , it can use single litellm virtual key to launch the agent-tool with remote litellm enabled. It should also be able to obtain the list of all available models in the remote litellm instance. And let user to choose which one to use for the agent.

The behavior just simliar to `ollama launch`, but this is for using remote litellm.

# Why user need this?

Beside managing the remote litellm instance via `lite` command, user really has the following problem when using local agent with remote litellm instance:

1. It is difficult for user to configure different agent-tools for remote litellm. Each tools has their unique way to configure the remote litellm instance, even if there is documentation on litellm website, but it is still take user a lot of time to read and debug. `lite launch` would be a life-saver.

2. some of agent tools like `claude` may not be able to list all the models on litellm instan…

GitHub resolver

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

Refresh page
vote history (21 events)
#0 of 0 · 31d19h13m49s ago — entered · #import:https:::github.com:berriai:litellm post #1659
The left issue spans a new CLI workflow, multiple external agent integrations, credential handling, model discovery, subprocess/environment configuration, and cross-platform UX, creating substantially broader integration and maintenance risk. The right issue is a focused dependency and callback-adapter migration with a bounded compatibility surface and test updates.
The launch-agent feature is substantially harder: it requires a new CLI workflow, remote authentication and model discovery, subprocess/environment integration, and compatibility across multiple external agent tools and platforms. The cancellation bug is narrower, though it still needs careful async exception, fallback, cooldown, and regression-test handling.
The right-side work spans a new CLI workflow, integrations with multiple external tools, remote authentication and model discovery, configuration generation, and cross-platform testing. The left-side work is comparatively localized to proxy model-registration and blocked-state handling, with narrower regression risk.
The right issue is harder because it spans a new CLI workflow, multiple external agent integrations, remote discovery, authentication, configuration generation, and cross-platform testing, while the left issue is comparatively localized routing and regression-test work.
The right-hand feature spans a new CLI workflow, multiple external agent integrations, model discovery, authentication, configuration, and cross-platform testing. The left-hand bug is narrower, centered on diagnosing and correcting concurrency-limit enforcement and adding regression coverage.
The agent-launch feature is substantially harder: it requires new CLI behavior, integration-specific environment/configuration handling across multiple external tools, remote model discovery and selection, authentication, and cross-platform process execution. The Windows database failure is narrower in scope, primarily involving diagnosis and correction of platform-specific connection or path handling.
The right issue is substantially harder: it spans a new CLI workflow, multiple external agent integrations, authentication/configuration handling, remote capability discovery, interactive model selection, and compatibility testing. The left issue is narrower, involving diagnosis and correction of parameter propagation or Azure URL construction across an existing integration path, with focused regression coverage.
34241 requires cross-cutting repository restructuring, licensing analysis, and careful preservation of enterprise gating and compatibility, creating substantial legal and regression risk. 30421 is a sizeable but comparatively contained CLI integration involving subprocess configuration, discovery, and provider-specific adapters.
The right issue is harder because it spans CLI design, subprocess orchestration, authentication, remote capability discovery, interactive selection, and compatibility across several external agent ecosystems. The left issue is substantial but more contained within LiteLLM’s existing quota, persistence, API, and UI layers.
Issue 21347 has substantially broader cross-provider compatibility scope, schema integration, test coverage, and maintenance risk; issue 30421 is primarily a bounded CLI orchestration and configuration feature.
Issue 30421 is harder because it spans a new CLI workflow, interactive model discovery and selection, authentication, subprocess/environment configuration, and compatibility with several independently evolving agent tools. Issue 27883 is narrower, primarily requiring server-side configuration storage, validation, and delivery for two integrations.
Implementing this requires a new CLI workflow spanning multiple external agent integrations, authentication/configuration translation, model discovery, interactive selection, subprocess behavior, and broad compatibility testing. The other issue is a narrower proxy accounting defect, though diagnosing distributed Redis timeout and atomicity behavior still carries meaningful risk.
The right issue is harder because it spans request-path integration across SDK and proxy flows, configuration and authorization layers, third-party model/runtime behavior, failure isolation, and comprehensive observability. The left issue is primarily a CLI orchestration and per-tool configuration task, with integration breadth but less impact on core request processing.
30421 is harder because it spans a new CLI workflow, multiple third-party agent integrations, remote model discovery, authentication, configuration translation, and cross-platform process behavior. 31824 is substantial but more bounded around authenticated API design, usage aggregation, and dashboard presentation.
Cross-provider protocol compatibility requires coordinated changes across request translation, streaming state, token accounting, regression coverage, and production validation, while the other item is primarily a CLI orchestration and configuration feature with bounded integration work.
30421 is harder because it spans a new user-facing CLI workflow, authentication, model discovery, and compatibility with several independently evolving external agent tools. 31835 requires substantial billing-data correctness, versioning, idempotency, and audit safeguards, but remains more contained within LiteLLM's existing proxy and spend systems.
The left issue is harder because it spans a new user-facing CLI workflow, credential handling, remote capability discovery, interactive selection, and integrations with several external agent tools across environments. The right issue is a substantial routing and configuration change, but it is more contained within LiteLLM's existing model-group and deployment-selection architecture.
Issue 28168 is harder because it spans a broad cross-resource export design, serialization and reapplication semantics, dependency ordering, sensitive data handling, compatibility, and likely extensive API/CLI and testing work. Issue 30421 is comparatively bounded to CLI orchestration, model discovery, and provider-specific agent configuration integrations.
The proxy-side change is harder because it requires a stable extensibility architecture within the request-routing lifecycle, careful compatibility with existing strategies, and robust behavior under concurrency, retries, fallbacks, and distributed deployments. The CLI work is broader across integrations but can largely be isolated behind provider-specific launch adapters and configuration flows.
30421 spans a new CLI workflow, multiple third-party agent integrations, remote model discovery, credential handling, and cross-platform process/configuration behavior. 31296 is comparatively bounded to protocol-compliant metadata and authentication response handling within existing MCP middleware, with focused tests.
#0 of 0 · 31d17h22m35s ago — current · #import:https:::github.com:berriai:litellm post #3511
The right issue is harder because it requires a cross-cutting credential and authentication abstraction, secure secret handling, provider and OAuth integration, compatibility considerations, and extensive security-focused testing. The left issue is substantial but more bounded to CLI orchestration, model discovery, and configuration adapters for external tools.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search