litellm - 💡(How to fix) Fix [Feature]: Support Command Code API provider (api.commandcode.ai) [1 participants]

Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

Add support for the Command Code API (https://api.commandcode.ai) as a LiteLLM provider.

Command Code currently exposes a custom streaming API at:

POST https://api.commandcode.ai/alpha/generate

The API is not OpenAI-compatible today, but it appears stable and externally callable with:

• bearer authentication
• versioned headers
• streaming event responses
• tool call events
• reasoning deltas

A provider adapter in LiteLLM would allow Command Code models to be exposed through the standard OpenAI-compatible LiteLLM proxy surface (/v1/chat/completions).

This would make Command Code usable with:

• Hermes
• OpenCode
• Cline
• OpenAI-compatible coding agents/tools
• existing LiteLLM routing/load-balancing infrastructure

Known integration details discovered during testing:

Required endpoint

https://api.commandcode.ai/alpha/generate

Required headers

Authorization: Bearer <API_KEY>
Content-Type: application/json
x-command-code-version: 0.24.1

Required payload structure

{
  "config": {
    "workingDir": "/tmp",
    "date": "2026-05-10",
    "environment": "terminal",
    "structure": [],
    "isGitRepo": false,
    "currentBranch": "",
    "mainBranch": "",
    "gitStatus": "",
    "recentCommits": []
  },
  "memory": "",
  "taste": "",
  "skills": null,
  "permissionMode": "standard",
  "params": {
    "model": "deepseek/deepseek-v4-flash",
    "messages": [
      {
        "role": "user",
        "content": "hello"
      }
    ],
    "tools": [],
    "system": "",
    "max_tokens": 100,
    "stream": true
  }
}

Observed stream event types

text-delta
reasoning-delta
tool-call
finish
error

There is already an existing unofficial provider implementation for the Pi agent ecosystem:

• https://github.com/patlux/pi-commandcode-provider

The implementation there may help accelerate provider support and stream translation logic.

Motivation, pitch

LiteLLM is already the de-facto interoperability layer for LLM tooling.

Command Code is gaining visibility in coding-agent communities because it aggregates several open-source coding models behind a single API with aggressive pricing/subscription packaging.

However, because the API is not OpenAI-compatible, it currently cannot be used directly with most OpenAI-compatible coding agents and developer tooling.

A native LiteLLM provider would:

• make Command Code immediately usable across existing OpenAI-compatible ecosystems
• reduce the need for ad-hoc proxy wrappers
• improve compatibility with coding agents that already integrate with LiteLLM
• provide another routing option for users optimizing for cost-sensitive coding workloads

What part of LiteLLM is this about?

Proxy

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

Yes

Twitter / LinkedIn details

https://x.com/JoyBoy_Ash https://www.linkedin.com/in/arsh-tulshyan/