20 KiB
Lingma Proxy
Lingma Proxy exposes Tongyi Lingma as standard OpenAI-compatible and Anthropic-compatible HTTP APIs. It can use either the local IDE plugin IPC channel or an experimental remote API backend, and ships as both a CLI proxy service and a cross-platform desktop app for macOS and Windows.
The project is designed for tools such as Claude Code, Cline, Continue, OpenCode, custom agents, and any client that can talk to OpenAI or Anthropic style APIs.
The proxy now supports two backend modes:
- Remote API mode (default, experimental): imports the local Lingma login cache or an explicit credential file and calls Lingma remote APIs directly. This feels more like an official API, does not depend on an IDE IPC session, and is currently the recommended mode for Claude Code / Hermes style agents.
- IPC plugin mode: connects to the local Lingma IDE plugin over WebSocket / Named Pipe. This keeps behavior closest to the IDE plugin and is useful as a compatibility fallback.
Current Version
The current desktop line is v1.4.6.
See CHANGELOG.md for release history.
Release builds are produced by GitHub Actions for:
| Asset | Platform | Purpose |
|---|---|---|
lingma-ipc-proxy_<tag>_darwin_arm64.tar.gz |
macOS | CLI proxy |
lingma-ipc-proxy_<tag>_windows_amd64.zip |
Windows | CLI proxy |
lingma-ipc-proxy-desktop_<tag>_darwin_arm64.dmg |
macOS Apple Silicon | Drag-to-install desktop app |
lingma-ipc-proxy-desktop_<tag>_darwin_arm64.zip |
macOS Apple Silicon | Raw .app archive |
lingma-ipc-proxy-desktop_<tag>_windows_amd64.zip |
Windows | Desktop app |
lingma-ipc-proxy_<tag>_sha256.txt |
all | Checksums |
Which Package Should I Download?
| Your system | Recommended asset | Notes |
|---|---|---|
| macOS on Apple Silicon (M1/M2/M3/M4) | lingma-ipc-proxy-desktop_<tag>_darwin_arm64.dmg |
Open the DMG and drag Lingma IPC Proxy.app to Applications. |
| macOS on Apple Silicon, portable archive | lingma-ipc-proxy-desktop_<tag>_darwin_arm64.zip |
Same app, but packaged as a zip instead of a drag-to-install DMG. |
| Windows x64 / x86_64 / AMD64 | lingma-ipc-proxy-desktop_<tag>_windows_amd64.zip |
This is the correct package for normal 64-bit Windows PCs, including Intel and AMD CPUs. |
| macOS CLI only | lingma-ipc-proxy_<tag>_darwin_arm64.tar.gz |
Terminal-only proxy binary. |
| Windows CLI only | lingma-ipc-proxy_<tag>_windows_amd64.zip |
Terminal-only proxy binary for 64-bit Windows. |
There is currently no separate windows_arm64 package. On a normal x64 Windows machine, choose windows_amd64.
Desktop App
The desktop app wraps the proxy with a native-feeling control panel:
- Start, stop, and restart the proxy.
- Inspect health, latency, recent requests, models, settings, and logs.
- View full request and response bodies with internal scrolling and hidden scrollbars.
- Copy endpoint URLs, model IDs, request logs, and response logs with visible feedback.
- Detect Lingma IPC paths automatically on macOS and Windows, with manual fallback settings.
- Follow system theme automatically, or switch light/dark mode manually.
- Keep the proxy running when the window is closed; quit explicitly from the app/menu.
Screenshots
Light mode:
Dark mode:
Narrow window layout:
Supported APIs
| API | Endpoint | Support |
|---|---|---|
| Health | GET /, HEAD /, GET /health, HEAD /health |
supported |
| Models | GET /v1/models |
supported |
| Capability Discovery | GET /capabilities, GET /v1/capabilities |
supported |
| Debug Requests | GET /debug/requests, GET /debug/logs |
recent HTTP request history |
| Debug Aliases | GET /api/requests, GET /api/logs |
aliases for request/log inspection |
| LM Studio / Ollama Discovery | GET /api/v1/models, GET /api/tags, GET /props |
supported |
| OpenAI Chat Completions | POST /v1/chat/completions |
streaming and non-streaming |
| OpenAI Chat Alias | POST /api/v1/chat/completions |
supported |
| Anthropic Messages | POST /v1/messages |
streaming and non-streaming |
What This Fork Adds
Compared with the original protocol proof of concept, this repository focuses on making the proxy usable as a complete local product:
- Function Calling / Tools for both OpenAI and Anthropic clients.
- Tool result continuation for multi-step agent loops.
- Tool stability hardening with proxy-side routing hints, core tool examples, missed-tool retry, and common alias mapping such as
BashtoterminalandReadtoread_file. - Anthropic streaming tool-call hardening so streaming clients such as Claude Code receive final
tool_useevents instead of premature refusal text when tools are present. - Image input for OpenAI
image_urland Anthropic image blocks. - Local and remote image normalization for data URLs, HTTP URLs,
file://URLs, and absolute local paths, with automatic JPEG downscaling for large images. - Request log image redaction so large base64 payloads are visible as image markers instead of breaking the desktop log view.
- More request parameter compatibility so stricter clients can connect without custom patches.
- Full request and response recording in the desktop app for debugging 400/500 errors.
- macOS and Windows desktop app with start/stop/restart, settings, logs, model discovery, themes, and window lifecycle handling.
- Cross-platform release packaging for CLI and desktop builds.
OpenAI Compatibility
The proxy accepts common OpenAI request fields:
model,messages,streamtemperature,top_p,stopmax_tokens,max_completion_tokenspresence_penalty,frequency_penaltytools,tool_choice,parallel_tool_callsresponse_format,seed,user,reasoning_effort- image input through
image_urldata URLs, HTTP URLs,file://URLs, and absolute local paths
Anthropic Compatibility
The proxy accepts common Anthropic request fields:
model,system,messages,streamtemperature,top_p,top_k,stop_sequencesmax_tokens,metadatatools,tool_choice- image blocks through base64 sources
- tool result continuation blocks
Architecture
flowchart LR
Client["OpenAI / Anthropic Client"] --> HTTP["HTTP API Layer"]
Desktop["Desktop App"] --> AppBridge["Wails Go Bridge"]
AppBridge --> Service["Proxy Service"]
HTTP --> Service
Service --> Session["Session Manager"]
Service --> Tools["Tool Emulation"]
Service --> Models["Model Discovery"]
Service --> Backend{"Backend Mode"}
Backend --> Transport["IPC Plugin Transport"]
Backend --> Remote["Remote API Client"]
Transport --> Pipe["Windows Named Pipe"]
Transport --> WS["macOS / Windows WebSocket"]
Pipe --> Lingma["Tongyi Lingma IDE Plugin"]
WS --> Lingma
Remote --> Cloud["Lingma Remote API"]
Module Layout
| Path | Responsibility |
|---|---|
cmd/lingma-ipc-proxy |
CLI entrypoint, config loading, signal handling |
internal/httpapi |
OpenAI/Anthropic HTTP routes, streaming SSE responses, request recording |
internal/service |
request orchestration, sessions, model discovery, proxy lifecycle |
internal/lingmaipc |
Lingma JSON-RPC transport over Named Pipe and WebSocket |
internal/remote |
remote Lingma login-cache import, signing, model list, and SSE parsing |
internal/toolemulation |
tool definition injection, action block parsing, tool result projection |
desktop |
Wails desktop shell, native window commands, proxy control bridge |
desktop/frontend |
Vue UI for dashboard, requests, models, settings, and logs |
.github/workflows/release.yml |
CI release pipeline for macOS and Windows CLI/Desktop packages |
Transport Detection
| Platform | Default transport | Detection |
|---|---|---|
| macOS | WebSocket | reads Lingma SharedClientCache files under user application support paths and ~/.lingma fallbacks |
| Windows | Named Pipe / WebSocket | scans Lingma named pipes plus %APPDATA%, %LOCALAPPDATA%, %ProgramData%, and %USERPROFILE%\.lingma shared cache hints |
| Linux | WebSocket | reads ~/.lingma / XDG hints when present; manual --ws-url is still recommended |
If auto detection fails, set the path manually in the desktop Settings page or pass CLI flags:
lingma-ipc-proxy --transport websocket --ws-url ws://127.0.0.1:36510 --port 8095
lingma-ipc-proxy --transport pipe --pipe '\\.\pipe\lingma-ipc'
Backend Modes
Remote API Mode (Default, Experimental)
Remote mode calls Lingma's remote API directly:
lingma-ipc-proxy --backend remote --port 8095
By default it reads the local Lingma login cache in read-only mode:
~/.lingma/cache/user
~/.lingma/cache/id
~/.lingma/logs/lingma.log
%APPDATA%\Lingma\cache\user
%LOCALAPPDATA%\Lingma\cache\user
XDG config/state Lingma cache paths when present
You can also pass an explicit credential file:
lingma-ipc-proxy \
--backend remote \
--remote-base-url https://lingma.alibabacloud.com \
--remote-auth-file ~/.config/lingma-ipc-proxy/credentials.json
Credential file format:
{
"source": "manual",
"token_expire_time": "1777520000000",
"auth": {
"cosy_key": "xxx",
"encrypt_user_info": "xxx",
"user_id": "123",
"machine_id": "xxxxxxxxxxxxxxxx"
}
}
Notes:
- Remote mode does not write or migrate login state. It only reads the local Lingma cache or the credential file you provide.
- If your Lingma plugin uses a dedicated domain, remote mode first uses
--remote-base-url,LINGMA_REMOTE_BASE_URL, or the JSON config field. If those are empty, it scans Lingma's local logs on macOS, Windows, and Linux for endpoint hints such asendpoint config:and marketplace service URLs. - The desktop Settings page shows the resolved remote domain and detection source without exposing tokens.
/v1/modelsin remote mode returns remote API model keys, which may not match the IPC plugin display IDs such asMiniMax-M2.7orKimi-K2.6.- Local validation passed
/health,/v1/models, OpenAI streaming/non-streaming chat, and Claude Code Anthropic + Bash tool use. Claude Code full tool runs are much slower than simple OpenAI requests because the client sends a large context and performs a second tool-result turn. - This mode is inspired by the remote API and credential-signing research in ZipperCode/lingma2api, integrated here as a switchable backend under the existing OpenAI / Anthropic / desktop app architecture.
IPC Plugin Mode
IPC mode talks to the local Lingma IDE plugin:
lingma-ipc-proxy --backend ipc --transport auto --port 8095
Use this when VS Code / the Lingma plugin is already running, when you want plugin session behavior, or when you want the model list exposed by the local plugin.
Quick Start
Desktop App
- Install VS Code and the Tongyi Lingma extension.
- Log in to Tongyi Lingma and verify the Lingma panel can chat normally.
- Download the desktop asset from Releases.
- Start
Lingma IPC Proxy. - Click
探测模型after the proxy is running. - Configure clients to use
http://127.0.0.1:8095.
CLI
git clone https://github.com/Lutiancheng1/lingma-ipc-proxy.git
cd lingma-ipc-proxy
go build -o ./dist/lingma-ipc-proxy ./cmd/lingma-ipc-proxy
./dist/lingma-ipc-proxy --host 127.0.0.1 --port 8095 --session-mode auto
Windows:
.\scripts\build.ps1
.\dist\lingma-ipc-proxy.exe --host 127.0.0.1 --port 8095 --session-mode auto
Client Configuration
Claude Code
export ANTHROPIC_BASE_URL="http://127.0.0.1:8095"
export ANTHROPIC_API_KEY="any"
Then select a model in Claude Code:
/model kmodel
Cline
- Provider:
OpenAI Compatible - Base URL:
http://127.0.0.1:8095/v1 - API Key:
any - Model ID:
kmodel
Continue
{
"models": [
{
"title": "Lingma Proxy",
"provider": "openai",
"model": "kmodel",
"apiKey": "any",
"apiBase": "http://127.0.0.1:8095/v1"
}
]
}
Models
The proxy reports the models exposed by the Lingma plugin. The desktop app does not force a global model switch; the calling client should specify the model field. Clicking a model in the desktop app copies its model ID.
Observed model IDs include:
AutoKimi-K2.6MiniMax-M2.7Qwen3-CoderQwen3-MaxQwen3-ThinkingQwen3.6-Plus
Model Metadata and Recommendation
The proxy only reports models actually exposed by your Lingma plugin. The table below combines official model information where available with local proxy testing. If Lingma exposes a model name without public model-card metadata, the README marks it as observed rather than inventing a context length.
| Model | Best use | Context / capability basis |
|---|---|---|
Kimi-K2.6 (kmodel in remote mode) |
Default recommendation for remote API mode and third-party agents | Kimi's official API docs describe native text/image/video input, a 256K context window, and multi-step tool invocation support. Local Claude Code testing showed cleaner native tool execution in remote mode. |
MiniMax-M2.7 (mmodel in remote mode) |
Fast fallback | NVIDIA's MiniMax M2.7 model card describes a language MoE model with 200K input context and agentic use cases; local proxy testing passed read/search/terminal/web/patch/vision smoke tests and was fast in previous runs. |
Qwen3-Coder |
Code-specialized fallback | Qwen's official blog describes 256K native context, up to 1M with extrapolation, and agentic coding/tool protocols. |
Qwen3.6-Plus |
General/vision fallback | Exposed by Lingma and passed local smoke tests, but this repository does not have an official Lingma-specific context-length source for it. |
Qwen3-Max |
Fast general/vision model | Exposed by Lingma and strong in simple tests, but less stable on forced edit/read tool calls in this proxy. |
Default model when the client omits model: kmodel (Kimi-K2.6 in the remote model list).
Remote mode enables timeout fallback by default. On timeout, upstream 5xx/429, or network interruption, the proxy only switches models if no streaming bytes have been sent to the client yet. Fallback candidates are filtered against the actual /v1/models response, so unavailable models are skipped. Default order:
Kimi-K2.6 -> MiniMax-M2.7 -> Qwen3-Coder -> Qwen3.6-Plus -> Qwen3-Max -> Qwen3-Thinking
Configuration
Default config file:
./lingma-ipc-proxy.json
Example:
{
"host": "127.0.0.1",
"port": 8095,
"backend": "ipc",
"transport": "auto",
"remote_base_url": "",
"remote_auth_file": "",
"remote_version": "",
"mode": "agent",
"shell_type": "zsh",
"session_mode": "auto",
"timeout": 300,
"remote_fallback_enabled": true,
"remote_fallback_models": [
"kmodel",
"mmodel",
"dashscope_qwen3_coder",
"dashscope_qmodel",
"dashscope_qwen_max_latest",
"dashscope_qwen_plus_20250428_thinking"
],
"cwd": "/Users/you/project",
"current_file_path": ""
}
Priority order:
- built-in defaults
- JSON config file
- environment variables
- command-line flags
- desktop Settings page updates
Concurrency
Older builds rejected concurrent chat requests with a rate_limit_error saying the proxy handled one request at a time. Current builds use a small execution pool instead:
- default max concurrent chat requests:
4 - override with
LINGMA_PROXY_MAX_CONCURRENT - allowed range:
1to16 session_mode=autouses fresh Lingma sessions so parallel editor requests do not share one sticky session
Example:
LINGMA_PROXY_MAX_CONCURRENT=8 lingma-ipc-proxy --port 8095
Function Calling / Tool Calling
Lingma does not expose a native public OpenAI/Anthropic tool-call protocol, so this proxy emulates tool calling:
- Normalize OpenAI or Anthropic tool definitions.
- Inject tool contracts into the Lingma prompt.
- Parse model action blocks from the response.
- Convert parsed actions back into OpenAI
tool_callsor Anthropictool_use. - Feed tool results back into Lingma for continuation.
Current proxy hardening includes:
- a generated tool routing table based on the client's actual tool names
- dedicated examples for
read_file,search_files,terminal, andweb_search - automatic retry when the model says it cannot access files, terminal, or web despite tools being present
- common tool alias normalization such as
Bash->terminal,Read->read_file,Grep->search_files, andEdit->patch - Anthropic
stream=truerequests with tools are resolved internally before streaming the finaltool_useblocks, which avoids sending premature "please run this command yourself" text to clients such as Claude Code.
In local smoke tests after this hardening, MiniMax-M2.7, Kimi-K2.6, Qwen3.6-Plus, and Qwen3-Coder all completed read/search/terminal/web/patch/vision checks. Remote API mode with kmodel is now the default because it avoids Lingma IDE IPC session limits and behaved better with Claude Code and Hermes-style local tools.
Request And Log Inspection
The desktop app keeps a visual request stream, and the HTTP server also exposes a small read-only debug history for CLI troubleshooting.
Useful endpoints:
curl http://127.0.0.1:8095/health
curl -I http://127.0.0.1:8095/
curl 'http://127.0.0.1:8095/debug/requests?limit=20'
curl 'http://127.0.0.1:8095/debug/logs?limit=20'
/debug/requests and /debug/logs return the newest records first. Each record includes:
- request time
- HTTP method and path
- status code
- duration in milliseconds
- sanitized request body
- sanitized response body
The server keeps the most recent 200 HTTP records in memory. Image payloads and large base64 strings are redacted before recording, and very large bodies are truncated to keep the desktop UI responsive.
These debug endpoints are intended for local development and client-adapter troubleshooting. They should only be exposed on trusted localhost networks.
Local Desktop Build
Install Wails:
go install github.com/wailsapp/wails/v2/cmd/wails@v2.12.0
Build macOS:
npm ci --prefix desktop/frontend
cd desktop
wails build -platform darwin/arm64 -clean
Build Windows on Windows:
npm ci --prefix desktop/frontend
cd desktop
wails build -platform windows/amd64 -clean
The desktop bundle name is always Lingma IPC Proxy.
Release Plan
The release workflow is triggered by:
- pushing a tag such as
v1.4.0 - manually running the
Releaseworkflow with a tag input
Planned improvements:
- macOS signing and notarization
- Windows installer packaging
- configurable log retention
- request export/import
- richer model metadata display
- optional Linux desktop packaging after the Lingma transport story is stable
Acknowledgements
This project is based on the protocol insight and initial discovery work from coolxll/lingma-ipc-proxy. The core idea of connecting to Lingma's private local IPC protocol and exposing standard API endpoints came from that project. This fork extends the implementation with broader OpenAI/Anthropic compatibility, tool emulation, image handling, desktop app support, request/log inspection, cross-platform packaging, and release automation.


