DEV Community: 韩

n8n Workflow Automation: 5 Hidden Uses of the 192K-Star Self-Hosted AI Stack

Sat, 13 Jun 2026 03:07:51 +0000

In 2025 a workflow tool raised a $180M Series C while one of its CVEs got weaponized into RCE the same year. The project is older than GPT-3, has 192,000+ GitHub stars, and almost no one is using it the way it was designed to be used. n8n is the 800-pound workflow platform that 95% of its users only know as a Zapier clone — and that framing misses every interesting thing it can actually do.

n8n-io/n8n sits at 192,242 stars and 58,496 forks as of 2026-06-13, written in TypeScript, self-hostable with a single Docker command, and shipping native LangChain, native MCP, and a fair-code license. The Hacker News thread about its $180M raise pulled 235 points and 184 comments; its main Show HN hit 728 points. But the "Sim – Apache-2.0 n8n alternative" story that hit 240 points last December is the tell: people are still looking for something n8n already does.

This article covers five hidden uses I have not seen written up anywhere, pulled from n8n's own docs, the LangChain integration, and the MCP Client/Server Trigger that landed in core. Most readers will only need the first two; the last three are the ones that make n8n worth self-hosting in 2026.

Context: n8n in the 2026 AI Stack

Two shifts made n8n suddenly matter. First, the LangChain integration became first-class — AI Agent, Tools Agent, Conversational Agent, ReAct Agent, SQL Agent, and Plan-and-Execute Agent all live as root nodes now, with 20+ vector stores and 15+ chat models wired in as sub-nodes. Second, n8n shipped native MCP support in both directions: an MCP Client node that consumes any MCP server, and an MCP Server Trigger that exposes n8n workflows themselves as MCP tools to Claude Desktop, Cursor, or any other MCP client. Combined, that turns n8n into a backend builder for AI agents — you design the integration, expose it once, and every MCP-aware tool can call it.

The third shift is the most underrated: the Code node runs in a sandboxed VM, not a browser, and supports both JavaScript and Python with npm packages. Most "no-code" tools treat code as a fallback; n8n treats it as a first-class branch, which is why its data-transformation stories outlast every pure-visual competitor.

Hidden Use #1: Expose n8n Workflows as MCP Tools to Claude/Cursor

What most people do: Wire n8n to a SaaS via Webhook, copy the URL, and poll. Fine for backends, useless for AI clients.

The hidden trick: Drop an MCP Server Trigger node on any workflow, and that workflow becomes a discoverable tool. Claude Desktop, Cursor, Cline, and any MCP-aware client can list it, call it, and stream the result back — no webhook boilerplate, no auth header juggling.

// Inside an n8n Code node that runs as the body of the MCP tool:
const items = $input.all();
const enriched = items.map(item => {
  const j = item.json;
  return {
    json: {
      ticket_id: j.id,
      priority: j.priority > 7 ? 'P0' : j.priority > 4 ? 'P1' : 'P2',
      owner: j.assignee || 'unassigned',
      sla_hours: Math.round((Date.now() - new Date(j.created_at)) / 3.6e6),
    }
  };
});
return enriched;

Wire that into a workflow starting with MCP Server Trigger, set the operation to expose, and the same logic now appears in Claude's tool list as lookup_ticket. No SDK glue, no separate auth flow.

The result: Five minutes of work turns an internal API into a tool every AI client in your org can call. Teams that previously had to write one integration per client (Claude SDK, Cursor config, Cline config) write it once.

Data sources: n8n MCP Server Trigger shipped as a core node; HN "N8n raises $180M" thread 235 pts; HN "Sim – Apache-2.0 n8n alternative" 240 pts (the demand for MCP-native workflow tools is real and growing).

Hidden Use #2: Multi-Agent Supervisor via Sub-Workflow Conversion

What most people do: Build a single massive workflow with a long agent loop, then debug it for hours when the agent misbehaves.

The hidden trick: Convert any node sequence into a reusable sub-workflow, then have an AI Agent call it as a tool. You end up with a clean supervisor/worker pattern: one parent agent that decides which sub-agent to invoke, and each sub-agent is a small, testable n8n workflow with its own prompt, memory, and tool set.

// Parent AI Agent's system prompt (set in the AI Agent node's "System Message")
// dynamically decides which sub-workflow to call by tool name.

const lastUserMsg = $('Chat Trigger').first().json.chatInput;
const intent = await this.helpers.httpRequest({
  method: 'POST',
  url: 'https://api.openai.com/v1/chat/completions',
  headers: { Authorization: `Bearer ${$env.OPENAI_API_KEY}` },
  body: {
    model: 'gpt-4o-mini',
    messages: [
      { role: 'system', content: 'Classify the user request as one of: research, code, triage. Reply with one word.' },
      { role: 'user', content: lastUserMsg },
    ],
  },
  json: true,
});
return [{ json: { route: intent.choices[0].message.content.trim().toLowerCase() } }];

Plug that into a Switch node, branch to three sub-workflows (research / code / triage), each itself an AI Agent with its own tools. The sub-workflow's "Execute Workflow" trigger means the parent gets a clean tool-call interface and a single response object back.

The result: A multi-agent system you can pause, inspect, and unit-test one branch at a time. Beats the "one workflow to rule them all" pattern that breaks the moment your agent makes a bad tool call.

Data sources: n8n "Execute Sub-workflow" + "Execute Workflow Trigger" + AI Agent with tool-calling (docs.n8n.io/advanced-ai/); HN "N8n added native persistent storage with DataTables" 174 pts (the platform is being re-architected around agent workloads).

Hidden Use #3: Native RAG with 20+ Vector Stores — No Code Glue

What most people do: Stand up a separate vector DB, write a FastAPI server, wire it to LangChain manually, and then fight version mismatches.

The hidden trick: n8n ships vector-store nodes for Pinecone, Qdrant, Weaviate, Milvus, MongoDB Atlas, Supabase, PGVector, Chroma, Redis, Oracle, Azure AI Search, and a Simple Vector Store. Each is a sub-node you drop under a Default Data Loader, set the embedding model, and feed documents into. The retrieval is wired into the AI Agent's "Vector Store" tool slot — no glue code.

// Inside the Default Data Loader's "Split Into Chunks" Code node
const text = $input.first().json.content || '';
const chunkSize = 800;
const overlap = 100;
const chunks = [];
for (let i = 0; i < text.length; i += chunkSize - overlap) {
  chunks.push(text.slice(i, i + chunkSize));
}
return chunks.map(c => ({ json: { text: c, source: $input.first().json.url } }));

Hook that into a Qdrant Vector Store sub-node configured with OpenAI embeddings, then attach the parent to an AI Agent. The agent can now search_documents(query) and get back the top-k chunks inlined into its context window.

The result: A working RAG pipeline in ten minutes, swap Qdrant for Pinecone by changing one sub-node, and keep the entire data flow visible in the canvas.

Data sources: n8n vector store node list (docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.vectorstoreqdrant/ and 11 siblings); n8n embeddings node list with 15+ providers.

Hidden Use #4: Streaming Chat Responses via Server-Sent Events

What most people do: Build a chatbot that returns the full response after the LLM finishes — three to ten seconds of silence for the user.

The hidden trick: n8n's "Streaming responses" feature (in the workflow settings) lets a Chat Trigger stream tokens to the front-end as they're generated, using SSE under the hood. The "AI Agent" node outputs each token as a separate item, and the SSE node pushes them down the wire without buffering.

// In the AI Agent's "Post-process" Code node, tag every partial token
const items = $input.all();
return items.map((it, idx) => ({
  json: {
    chunk: it.json.output,
    done: idx === items.length - 1,
    trace_id: it.json.metadata?.run_id || null,
  }
}));

Pair that with a front-end EventSource client and the user sees a true token-by-token stream. Crucially, the AI Agent's intermediate tool calls are still visible in the execution log — you can replay the whole run later.

The result: Real ChatGPT-class UX on top of self-hosted infrastructure, with full traceability of which tool the agent called and when.

Data sources: n8n "Streaming responses" (docs.n8n.io/workflows/streaming/); n8n Chat Trigger with SSE output option; HN "N8n AI Workflows – 3,400 Workflows and an LLM Prototype" 12 pts (the community already pushes this hard).

Hidden Use #5: OpenTelemetry Observability Inside the Execution Graph

What most people do: Run n8n blind — execution logs are visible in the UI but you cannot correlate them with the rest of the system.

The hidden trick: The n8n-otel OpenTelemetry integration (shipped as a community plugin and a first-class config in 1.50+) exports every node execution, every retry, every AI Agent tool call as OTel spans. Set the OTLP endpoint in your docker-compose.yml, and the same Trace ID that appears in your application logs surfaces in n8n's execution view.

# docker-compose.yml — drop this on your existing n8n service
services:
  n8n:
    image: n8nio/n8n
    environment:
      - N8N_METRICS=true
      - QUEUE_HEALTH_CHECK_ACTIVE=true
      - OTEL_ENABLED=true
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318
      - OTEL_SERVICE_NAME=n8n-prod
    ports:
      - "5678:5678"

Then in your OTel collector, route n8n.* spans into a dedicated dashboard. The most useful signal is the "node duration" histogram per node type — your Slack and HTTP nodes will dominate; your AI Agent nodes will tell you exactly which tool calls cost the most time.

The result: A 2026-grade observability story for free, and the same Trace ID you already use in your app code links straight to the n8n execution that triggered it. Beats clicking through the n8n UI every time something misfires.

Data sources: n8n observability config (docs.n8n.io/hosting/configuration/observability/); HN "Bringing Observability to Your N8n Workflows: OpenTelemetry in Action" 17 pts (2026-04-12 — recent and credible).

Closing

Five things n8n can do that almost nobody uses:

MCP Server Trigger — expose any workflow as a tool to Claude/Cursor/Cline
Sub-workflow as agent tool — multi-agent supervisor with clean per-branch testing
Native vector store sub-nodes — RAG in 10 minutes, swap providers by swapping one node
SSE streaming chat — token-by-token output with full execution replay
OpenTelemetry export — correlate n8n runs with the rest of your stack via Trace ID

The one that surprised me most was #4. SSE streaming in n8n is barely documented, but it's there, it works with the AI Agent node out of the box, and it makes self-hosted chatbots feel native.

If you want to dig deeper into the agent ecosystem, check out these three articles:

Crush Terminal AI Coding Agent: 5 Hidden Uses — another terminal-first agent with surprisingly clean config hygiene
KTransformers: 5 Hidden Uses of the 17K-Star MoE Inference Stack — how Tsinghua's MoE engine gets 347 tok/s on consumer GPUs
Serena's 5 Hidden Uses — IDE-level intelligence for AI coding agents via LSP

What is the most useful MCP server you have exposed via n8n? I am collecting real-world examples for a follow-up — drop yours in the comments.

n8n 的 5 个隐藏用法，19.2 万 Star 的自部署 AI 工作流栈里没人讲的能力

Sat, 13 Jun 2026 03:07:45 +0000

在 2025 年，一个工作流自动化平台拿到了 1.8 亿美元 C 轮融资，同年它的一个 CVE 被武器化成远程代码执行。这个项目比 GPT-3 还老，GitHub 上有超过 19.2 万颗星，但几乎没人真正按它设计的方式在用它。n8n 是那个 800 磅重的工作流平台，95% 的用户只把它当成 Zapier 的开源替代品——而这个定位让你错过了它真正能做的所有有意思的事情。

n8n-io/n8n 截至 2026-06-13 拥有 192,242 颗星、58,496 个 Fork，TypeScript 编写，单条 Docker 命令就能自部署，原生集成 LangChain、原生支持 MCP，使用 fair-code 协议。它 1.8 亿美元融资那条 HN 主帖拿到 235 票 184 条评论，主 Show HN 帖拿到 728 票。但去年 12 月那条《Sim – Apache-2.0 n8n alternative》拿到 240 票才是真正的信号：大家还在找 n8n 已经有的东西。

这篇文章讲五个我在任何地方都没见人写过的隐藏用法，材料全部来自 n8n 官方文档、LangChain 集成和落地到 core 里的 MCP Client/Server Trigger。大部分读者前两个就够用了，最后三个才是 n8n 在 2026 年值得自部署的真正理由。

背景：n8n 在 2026 年 AI 栈里的位置

两个变化让 n8n 突然变得关键。第一，LangChain 集成变成了一等公民——AI Agent、Tools Agent、Conversational Agent、ReAct Agent、SQL Agent、Plan-and-Execute Agent 全部作为根节点存在，20+ 种向量库和 15+ 种聊天模型作为子节点直接接进来。第二，n8n 在两个方向上同时支持了 MCP：MCP Client 节点可以消费任何 MCP Server，MCP Server Trigger 可以把 n8n 工作流自身作为 MCP 工具暴露给 Claude Desktop、Cursor 或任何 MCP 客户端。两者合起来，让 n8n 成了 AI Agent 的后端构建器——你设计好集成、暴露一次，所有支持 MCP 的工具都能调用。

第三个变化是最被低估的：Code 节点跑在沙箱化 VM 里，不是浏览器，原生支持 JavaScript 和 Python，还能加载 npm 包。大部分"零代码"工具把代码当成兜底选项，n8n 把代码当成一等分支，这就是它的数据转换能力比所有纯可视化竞品更耐用的原因。

隐藏用法 #1：把 n8n 工作流暴露成 MCP 工具给 Claude/Cursor 用

大多数人的做法： 用 Webhook 把 n8n 接到一个 SaaS，复制 URL，然后开始轮询。对后端够用，对 AI 客户端完全没用。

隐藏技巧： 任何一个工作流加上 MCP Server Trigger 节点，整个工作流就变成了一个可被发现的工具。Claude Desktop、Cursor、Cline 以及任何支持 MCP 的客户端都能列出它、调用它、实时回传结果——不用写 Webhook 模板，不用管理鉴权头。

// 跑在 MCP 工具主体里的 n8n Code 节点：
const items = $input.all();
const enriched = items.map(item => {
  const j = item.json;
  return {
    json: {
      ticket_id: j.id,
      priority: j.priority > 7 ? 'P0' : j.priority > 4 ? 'P1' : 'P2',
      owner: j.assignee || 'unassigned',
      sla_hours: Math.round((Date.now() - new Date(j.created_at)) / 3.6e6),
    }
  };
});
return enriched;

把它接进一个以 MCP Server Trigger 开头的 workflow，操作设为 expose，同一段逻辑就会以 lookup_ticket 的名字出现在 Claude 的工具列表里。不用 SDK 胶水代码，不用单独的鉴权流。

效果： 五分钟工作把内部 API 变成组织里每个 AI 客户端都能调的工具。以前要给每个客户端（Claude SDK、Cursor 配置、Cline 配置）各写一遍集成，现在只写一次。

数据来源： n8n MCP Server Trigger 作为核心节点发布；HN《N8n raises $180M》帖 235 票；HN《Sim – Apache-2.0 n8n alternative》240 票（市场对 MCP 原生工作流工具的需求真实且在增长）。

隐藏用法 #2：用子工作流转换搭多 Agent 监督者架构

大多数人的做法： 写一个又长又大的工作流，里面塞一个超长 agent 循环，agent 一抽风就调半天。

隐藏技巧： 把任意一段节点序列转成可复用的子工作流，再让一个 AI Agent 把它当工具调用。最后你会得到一个干净的 supervisor/worker 模式：一个父 agent 决定调用哪个子 agent，每个子 agent 都是一个小的、可测试的 n8n workflow，自带自己的 prompt、记忆和工具集。

// 父 AI Agent 的系统提示（在 AI Agent 节点的 "System Message" 里设置）
// 通过工具名动态决定调用哪个子工作流。

const lastUserMsg = $('Chat Trigger').first().json.chatInput;
const intent = await this.helpers.httpRequest({
  method: 'POST',
  url: 'https://api.openai.com/v1/chat/completions',
  headers: { Authorization: `Bearer ${$env.OPENAI_API_KEY}` },
  body: {
    model: 'gpt-4o-mini',
    messages: [
      { role: 'system', content: '把用户请求分类为以下之一：research, code, triage。只回一个词。' },
      { role: 'user', content: lastUserMsg },
    ],
  },
  json: true,
});
return [{ json: { route: intent.choices[0].message.content.trim().toLowerCase() } }];

把它接进 Switch 节点，分支到三个子工作流（research / code / triage），每个子工作流自己又是一个带工具的 AI Agent。子工作流的 "Execute Workflow" trigger 让父 agent 拿到一个干净的工具调用接口和一个统一的响应对象。

效果： 多 agent 系统可以暂停、逐分支审查、单独单测。比"一个 workflow 管所有"模式强太多——后者一旦 agent 调错工具就全盘崩溃。

数据来源： n8n "Execute Sub-workflow" + "Execute Workflow Trigger" + AI Agent 工具调用（docs.n8n.io/advanced-ai/）；HN《N8n added native persistent storage with DataTables》174 票（平台正在围绕 agent 工作负载重新架构）。

隐藏用法 #3：原生 RAG 接入 20+ 种向量库——零胶水代码

大多数人的做法： 起一个独立的向量数据库，写一个 FastAPI 服务，手动接 LangChain，然后跟版本不匹配死磕。

隐藏技巧： n8n 为 Pinecone、Qdrant、Weaviate、Milvus、MongoDB Atlas、Supabase、PGVector、Chroma、Redis、Oracle、Azure AI Search、Simple Vector Store 都内置了向量库节点。每个都是个子节点，你拖到 Default Data Loader 下面、配上 embedding 模型、把文档喂进去就行。检索动作直接接到 AI Agent 的"Vector Store"工具槽位——零胶水代码。

// 在 Default Data Loader 的 "Split Into Chunks" Code 节点里
const text = $input.first().json.content || '';
const chunkSize = 800;
const overlap = 100;
const chunks = [];
for (let i = 0; i < text.length; i += chunkSize - overlap) {
  chunks.push(text.slice(i, i + chunkSize));
}
return chunks.map(c => ({ json: { text: c, source: $input.first().json.url } }));

接上配了 OpenAI embedding 的 Qdrant Vector Store 子节点，再把父节点挂到 AI Agent 上。Agent 就能 search_documents(query) 拿到 top-k 个 chunk 直接塞进上下文窗口。

效果： 十分钟搭一条能跑 RAG 流水线，要换 Qdrant 到 Pinecone 就替换一个子节点，整条数据流在画布上一目了然。

数据来源： n8n 向量库节点列表（docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.vectorstoreqdrant/ 等 11 个兄弟节点）；n8n embeddings 节点列表，15+ 提供商。

隐藏用法 #4：SSE 推送 Chat 流式响应

大多数人的做法： 做一个聊天机器人，LLM 跑完之后才返回完整响应——用户等三到十秒什么也看不见。

隐藏技巧： n8n 的"Streaming responses"功能（在 workflow 设置里）让 Chat Trigger 把 token 实时推到前端，底层走 SSE。AI Agent 节点把每个 token 当成独立 item 输出，SSE 节点不缓冲直接推下去。

// 在 AI Agent 的 "Post-process" Code 节点里，给每个部分 token 打标
const items = $input.all();
return items.map((it, idx) => ({
  json: {
    chunk: it.json.output,
    done: idx === items.length - 1,
    trace_id: it.json.metadata?.run_id || null,
  }
}));

前端接一个 EventSource 客户端，用户就能看到真正的逐 token 流。关键是，AI Agent 中间的工具调用在执行日志里照样能看到——之后能整段回放。

效果： 自部署基础设施也能提供 ChatGPT 级别的体验，agent 调了哪个工具、什么时候调的，全链路可追溯。

数据来源： n8n "Streaming responses"（docs.n8n.io/workflows/streaming/）；n8n Chat Trigger 支持 SSE 输出；HN《N8n AI Workflows – 3,400 Workflows and an LLM Prototype》12 票（社区已经在重度推进）。

隐藏用法 #5：执行图谱里的 OpenTelemetry 可观测性

大多数人的做法： n8n 跑在黑盒里——执行日志 UI 能看，但跟系统其他部分没法关联。

隐藏技巧： n8n-otel OpenTelemetry 集成（社区插件 + 1.50+ 里的一等配置项）把每次节点执行、每次重试、每次 AI Agent 工具调用全部导出成 OTel span。在 docker-compose.yml 里设好 OTLP endpoint，你应用日志里出现的同一个 Trace ID 就能在 n8n 执行视图里直接看到。

# docker-compose.yml — 贴到现有的 n8n service 上
services:
  n8n:
    image: n8nio/n8n
    environment:
      - N8N_METRICS=true
      - QUEUE_HEALTH_CHECK_ACTIVE=true
      - OTEL_ENABLED=true
      - OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4318
      - OTEL_SERVICE_NAME=n8n-prod
    ports:
      - "5678:5678"

然后在你的 OTel collector 里，把 n8n.* span 路由到专用 dashboard。最有用的信号是按节点类型分桶的"节点耗时"直方图——Slack 和 HTTP 节点会占大头，AI Agent 节点会精确告诉你哪些工具调用最耗时。

效果： 免费拿到 2026 级别可观测性，已经在用的 Trace ID 能直接链回触发它的 n8n 执行。比每次出问题都去点 n8n UI 强太多。

数据来源： n8n 可观测性配置（docs.n8n.io/hosting/configuration/observability/）；HN《Bringing Observability to Your N8n Workflows: OpenTelemetry in Action》17 票（2026-04-12 发布，新鲜可信）。

收尾

五个 n8n 能做但几乎没人用的功能：

MCP Server Trigger — 把任意工作流暴露成 Claude/Cursor/Cline 的工具
子工作流当 agent 工具 — 多 agent 监督者架构，逐分支干净单测
原生向量库子节点 — 十分钟搭 RAG，换服务商就换子节点
SSE 流式聊天 — 逐 token 输出，全执行可回放
OpenTelemetry 导出 — Trace ID 关联 n8n 运行和你系统其他部分

最让我意外的是第 4 个。n8n 的 SSE 流式几乎没文档，但它就在那里，开箱即用对接 AI Agent 节点，让自部署聊天机器人体验原生。

如果你想深入 agent 生态，可以看这三篇：

Crush Terminal AI Coding Agent：5 个隐藏用法 — 另一个终端优先的 agent，配置卫生出乎意料地干净
KTransformers：清华 17K Star MoE 推理栈的 5 个隐藏用法 — 清华的 MoE 引擎怎么在消费级 GPU 上跑到 347 tok/s
Serena 的 5 个隐藏用法 — 通过 LSP 给 AI 编程助手带来 IDE 级别智能

你在 n8n 里暴露过的最有用的 MCP Server 是哪个？我在收集真实案例准备后续文章，在评论区留下你的例子。

Crush 的 5 个隐藏用法：25K Star 的 Charm 终端 AI Agent 在配置卫生上完胜 Claude Code

Fri, 12 Jun 2026 05:45:50 +0000

你知道吗？Charm 团队在 Hacker News 上首发"终端里最迷人的 AI 编码代理"时，那条帖子一天就冲到 367 分、235 条评论。将近一年后，这个仓库已经积累到 25,233 个 GitHub Stars 和 1,805 个 Forks，最近一次提交是 2026 年 6 月 12 日。可是当大多数工程师第一次打开 Crush 的时候，用法跟 Claude Code 没什么两样——聊一聊、改一改、再聊一聊。README 又长又全，但真正好用的生产功能，全藏在配置文件、LSP 接线、MCP 配置和那一小撮不起眼的 flag 里。

charmbracelet/crush 是 Charm 生态（bubbletea、lipgloss、glow 都出自这个团队，他们的基础库支撑了大约 25,000 个下游 Go 应用）出品的代理化终端工具。它原生支持 OpenAI 和 Anthropic，自带三种 MCP 传输协议，同一份二进制在 macOS、Linux、Windows（PowerShell + WSL）、Android、FreeBSD、OpenBSD、NetBSD 都能跑。大多数用户看到的就是"又一个终端 AI"。其实它更像是一个可编程的代理运行时，有自己的小配置语言。

下面这五个隐藏用法，把 Crush 从"我的第二个编码 Agent"变成了我留在顶层的那个。

隐藏用法 #1：`crush.json` 里的 Shell 风格密钥展开

大多数人的用法： 直接把 API Key 粘贴到 crush.json 里（然后第一次提交进 git 就后悔了）。

隐藏技巧： Crush 自带一个兼容 bash 的展开引擎，会在 MCP、provider、LSP 配置的 command、args、env、headers、url 字段上跑一遍。这意味着你可以用 $VAR、${VAR:-default}、$(command)，甚至 ${VAR:?message}——最后一个是大多数人没注意到的杀手锏。必需的凭据一旦缺失就在加载时大声报错，绝不会悄悄变成空字符串。

{
  "$schema": "https://charm.land/crush.json",
  "mcp": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GH_PAT:?请先在 shell 里设置 GH_PAT}"
      },
      "timeout": 120
    },
    "filesystem": {
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/mcp-server.js"],
      "env": {
        "NODE_ENV": "production",
        "TOKEN_FILE": "$(cat /run/secrets/mcp-token)"
      }
    }
  }
}

效果： 解析后值为空字符串的 header 会被 Crush 从请求里整个删掉，而不是发出 Authorization: Bearer 这种空值。这意味着类似 OpenAI-Organization 这种可选的、依赖环境变量的 header 在未设置时不会污染请求；必需的凭据则在 TUI 还没渲染之前就给出明确的报错。

数据来源： Crush 25,233 Stars / 1,805 Forks（GitHub REST API 验证，最近一次 push 2026-06-12）。HN 发布主帖 367 pts / 235 comments（objectID 44736176，2025-07-30）。

隐藏用法 #2：跨多个 TUI 客户端的共享工作区

大多数人的用法： 开一个 Crush 窗口，任务结束，关掉，会话也没了。

隐藏技巧： 运行 crush serve 暴露 HTTP 后端，再用 --cwd 把多个 TUI 客户端附加到同一个工作区。指向相同工作目录的两个客户端会加入同一个底层工作区——共享会话列表、消息历史、权限队列、LSP 服务池和 MCP 连接。会话选择器暴露两个信号：IsBusy（代理正在跑一轮）和 AttachedClients（当前有多少个终端在看着同一个会话）。

# 终端 A：启动一次长时间重构，然后挂后台
crush serve --cwd ~/code/monolith --yolo

# 终端 B：实时围观同一个工作区
crush --cwd ~/code/monolith

# 终端 C，笔记本 SSH 进来：还是同一个工作区
crush --cwd ~/code/monolith

效果： AttachedClients 不为零就是"这个会话在另一个客户端上正在跑"的提示。最先创建工作区的那个客户端固定了进程级 flag——尤其是 --yolo 和 --debug 遵循先到先得原则：后续客户端想用更宽松的设置是不被接受的。工作区的生命周期与任何一个客户端保持 SSE 流连接的时间一致；最后一个流断开时，工作区被销毁，但有一个短暂的宽限窗口，避免"刚创建还没来得及接入"的客户端被立刻回收。

数据来源： Crush README "Sharing a workspace across clients" 章节，宽限窗口与 first-wins flag 规则与官方文档一致。

隐藏用法 #3：带 `user-invocable` 和 `disable-model-invocation` 的 Agent Skills

大多数人的用法： 觉得 skill 文档读起来像插件市场，直接跳过。

隐藏技巧： Crush 支持开放的 Agent Skills 标准（agentskills.io），默认从七个全局路径和三个项目相对路径自动发现 skill——这还没算上你自定义的 options.skills_paths。真正的好戏是两个 frontmatter 标记：

---
name: crush-config
description: "一个可以通过命令面板手动触发的 skill"
user-invocable: true
disable-model-invocation: true
---

# 引导用户完成 crush.json 的编辑流程

设置 user-invocable: true 之后，skill 会在命令面板（Ctrl+P）里以 user:skill-name 或 project:skill-name 的形式出现。再设上 disable-model-invocation: true，这个 skill 对模型完全隐身，但人可以随时手动调起来。Crush 自带的 crush-config skill 用的就是这个套路——模型永远不会自动触发它，但用户按 Ctrl+P 输入 "config" 就能让 Agent 引导自己完成配置。

# 用 anthropics/skills 当起点，把示例 skill 装到本地
mkdir -p ~/.config/crush/skills
cd ~/.config/crush/skills
git clone https://github.com/anthropics/skills.git _temp
mv _temp/skills/* . && rm -rf _temp

效果： 干净地分离了人主动调用的工作流（部署、改配置、清理）和模型主动触发的 skill（调研、重构、代码检索）。模型不可能误触发危险 skill，但人随时可以召唤。

数据来源： Crush README "Agent Skills" 章节，七个全局路径 + 三个项目相对路径与源码一致。agentskills.io 开放标准在 README 中明确引用。

隐藏用法 #4：自定义 Anthropic 兼容 Provider 与每模型成本元数据

大多数人的用法： 用内置预设 Provider，从不动 providers 字段。

隐藏技巧： Crush 支持两种自定义 Provider 写法——openai-compat 给那些走 OpenAI 接口形态但不是 OpenAI 的服务（Deepseek、Groq、Together、Fireworks），anthropic 给 Anthropic 兼容端点（代理、内部集群、自定义 base URL）。真正没写在文档里的彩蛋是每模型的元数据字段——cost_per_1m_in、cost_per_1m_out、cost_per_1m_in_cached、cost_per_1m_out_cached、context_window、default_max_tokens、can_reason、supports_attachments。这些不只是装饰：TUI 用它们在每次请求时显示真实成本估算。

{
  "$schema": "https://charm.land/crush.json",
  "providers": {
    "deepseek": {
      "type": "openai-compat",
      "base_url": "https://api.deepseek.com/v1",
      "api_key": "$DEEPSEEK_API_KEY",
      "models": [
        {
          "id": "deepseek-chat",
          "name": "Deepseek V3",
          "cost_per_1m_in": 0.27,
          "cost_per_1m_out": 1.1,
          "cost_per_1m_in_cached": 0.07,
          "context_window": 64000,
          "default_max_tokens": 5000
        }
      ]
    },
    "custom-anthropic": {
      "type": "anthropic",
      "base_url": "https://api.your-proxy.internal/v1",
      "api_key": "$INTERNAL_ANTHROPIC_KEY",
      "extra_headers": {
        "anthropic-version": "2023-06-01",
        "X-Tenant-Id": "$TENANT_ID"
      },
      "models": [
        {
          "id": "claude-sonnet-4-20250514",
          "name": "Claude Sonnet 4",
          "cost_per_1m_in": 3,
          "cost_per_1m_out": 15,
          "context_window": 200000,
          "default_max_tokens": 50000,
          "can_reason": true,
          "supports_attachments": true
        }
      ]
    }
  }
}

效果： extra_body 是不展开的 JSON 透传（用来塞静态字段），但 extra_headers、api_key、base_url 都会走 shell 展开引擎。这意味着你可以在团队里只分发一份 crush.json，每位工程师通过环境变量覆盖自己的凭据；TUI 能显示真实成本，因为元数据写在配置里、不是硬编码。

数据来源： Crush README "Custom Providers" 章节，Deepseek 示例配置与官方 README 一致。Provider 总数（25+，包括 OpenAI、Anthropic、Google、Groq、OpenRouter、Vercel、MiniMax、Z.ai、Cerebras、Hugging Face、AWS Bedrock、Azure OpenAI 等）通过 README 的环境变量表交叉验证。

隐藏用法 #5：分层工具与 Skill 隔离（`.crushignore` + `disabled_tools` + `disabled_skills`）

大多数人的用法： 启动时加 --yolo 听天由命，或者每次权限弹窗都手动点。

隐藏技巧： Crush 给了你三层独立的隔离机制，可以叠加使用：

.crushignore——gitignore 语法的文件，文件根本进不到 Crush 的上下文（不只是禁止编辑，连读都不读）。
options.disabled_tools——对代理完全隐藏内置工具（比如 "bash"、"sourcegraph"）。模型看不到的工具就没法选。
options.disabled_skills——对代理隐藏 skill（内置和发现的都算）。再叠加 skill 自己的 frontmatter 里的 disable-model-invocation 可以做到单个 skill 级别的隐身。
permissions.allowed_tools——反方向的白名单。只有列出来的工具能跑，其他都需要弹窗。

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "disabled_tools": ["bash"],
    "disabled_skills": ["crush-config"],
    "skills_paths": [
      "~/.config/crush/skills",
      "./project-skills"
    ]
  },
  "permissions": {
    "allowed_tools": [
      "view",
      "ls",
      "grep",
      "edit",
      "mcp_context7_get-library-doc"
    ]
  }
}

# .crushignore —— 凭据、构建产物、大数据文件
.env
.env.*
secrets/
*.pem
node_modules/
dist/
*.parquet
data/raw/

效果： 你可以给团队部署一份"禁用 bash（所有 shell 操作强制走 MCP 工具）、隐藏某些 skill（模型重构时不会自作主张触发 crush-config）、只读工具白名单"的 Crush。.crushignore 跟 .gitignore 用一样的语法并叠加生效——已经提交进仓库但不想让代理碰的文件，git 留底、Crush 看不见。这是把 Crush 跑在面向客户的内部工具里时，团队实际在用的配置模式。

数据来源： Crush README 的 "Ignoring Files"、"Allowing Tools"、"Disabling Built-In Tools"、"Disabling Skills" 四个章节，四种机制均与官方文档行为一致。

总结：五个隐藏用法

Shell 风格密钥展开：${VAR:?msg} 与 $(command)，必需凭据零容忍。
共享工作区：crush serve + --cwd 键值，多 TUI 客户端同步会话。
Agent Skills：user-invocable 与 disable-model-invocation 配合，分离"人触发"和"模型触发"两种工作流。
自定义 Anthropic/OpenAI Provider：每模型成本元数据 + extra_body 透传。
分层隔离：.crushignore + disabled_tools + disabled_skills + allowed_tools 四重保险。

Crush Terminal AI Coding Agent: 5 Hidden Uses of the 25K-Star Charm Stack That Beat Claude Code at Config Hygiene

Fri, 12 Jun 2026 05:45:47 +0000

Here's the thing — on Hacker News, the Charm team's "Glamourous AI coding agent for your favourite terminal" launch hit 367 points and 235 comments the day it shipped. Almost a year later, the repo has climbed to 25,233 GitHub stars and 1,805 forks, with the latest push on June 12, 2026. Yet when most engineers open Crush for the first time, they end up running it the way they run Claude Code — chat, edit, repeat. The README is long, but the most useful production features are hidden in the configuration file, the LSP wiring, the MCP section, and a tiny set of flags.

charmbracelet/crush is the agentic terminal tool from the Charm ecosystem (the same team behind bubbletea, lipgloss, and glow — the foundation powering roughly 25,000 downstream Go applications). It speaks OpenAI and Anthropic natively, ships three MCP transports, and runs the same binary on macOS, Linux, Windows (PowerShell + WSL), Android, FreeBSD, OpenBSD, and NetBSD. Most users see "yet another terminal AI." What's actually under the hood is closer to a programmable agent runtime with a real config language.

Let's walk through the five hidden uses that turned Crush from "my second coding agent" into the one I keep on top.

Hidden Use #1: Shell-Style Secret Expansion in `crush.json`

What most people do: Paste API keys directly into crush.json (and then regret it the first time the file lands in a git commit).

The hidden trick: Crush ships a bash-compatible expansion engine that runs over command, args, env, headers, and url fields in MCP, provider, and LSP config. That means you can use $VAR, ${VAR:-default}, $(command), and even ${VAR:?message} — the last one is the trick most engineers miss. Required-credential syntax fails loudly at load time instead of silently resolving to an empty string.

{
  "$schema": "https://charm.land/crush.json",
  "mcp": {
    "github": {
      "type": "http",
      "url": "https://api.githubcopilot.com/mcp/",
      "headers": {
        "Authorization": "Bearer ${GH_PAT:?set GH_PAT in your shell env first}"
      },
      "timeout": 120
    },
    "filesystem": {
      "type": "stdio",
      "command": "node",
      "args": ["/path/to/mcp-server.js"],
      "env": {
        "NODE_ENV": "production",
        "TOKEN_FILE": "$(cat /run/secrets/mcp-token)"
      }
    }
  }
}

The result: Headers whose value resolves to the empty string are dropped from the outgoing request entirely — Crush does not send Authorization: Bearer with a blank value. That means optional env-gated headers like OpenAI-Organization stay clean when unset, and required credentials fail fast with a meaningful error before the TUI ever renders.

Data sources: Crush 25,233 Stars / 1,805 Forks on GitHub (last push 2026-06-12), verified via the GitHub REST API. HN launch discussion 367 pts / 235 comments (objectID 44736176, 2025-07-30).

Hidden Use #2: Shared Workspaces Across Multiple TUI Clients

What most people do: Open one Crush window, finish, close it, lose the session.

The hidden trick: Run crush serve to expose an HTTP backend, then attach multiple TUI clients to the same workspace, keyed by --cwd. Two clients pointing at the same working directory join the same underlying workspace — they share the session list, message history, permission queue, LSP server pool, and MCP connections. The session picker exposes two signals: IsBusy (an agent turn is in flight) and AttachedClients (how many terminals are currently viewing the same session).

# Terminal A — start a long refactor and detach
crush serve --cwd ~/code/monolith --yolo

# Terminal B — watch the same workspace live
crush --cwd ~/code/monolith

# Terminal C on a laptop, SSH'd in — same workspace
crush --cwd ~/code/monolith

The result: A non-zero AttachedClients is the cue that a session is "in progress" on another client. The first client to create a workspace fixes process-wide flags (notably --yolo and --debug follow a first-wins rule — later clients cannot loosen security). The workspace lives as long as any client holds an SSE stream open against it; the moment the last stream disconnects, the workspace is torn down with a short grace window so a client that just created the workspace has time to attach.

Data sources: Crush README "Sharing a workspace across clients" section. Workspace lifecycle semantics verified against the README's documented grace-window and first-wins flag rules.

Hidden Use #3: Agent Skills with `user-invocable` and `disable-model-invocation`

What most people do: Skip skills because the docs read like a plugin marketplace.

The hidden trick: Crush supports the open Agent Skills standard (agentskills.io) and discovers them from seven default global paths plus three project-relative paths — and that's before you customize options.skills_paths. The killer feature is two specific frontmatter flags:

---
name: crush-config
description: "A skill that can be invoked as a command."
user-invocable: true
disable-model-invocation: true
---

# Walk the user through editing crush.json

Set user-invocable: true to surface the skill in the commands palette (Ctrl+P) as user:skill-name or project:skill-name. Set disable-model-invocation: true to hide the skill from the model entirely while still letting the human invoke it manually. This is how Crush ships its built-in crush-config skill — the model never auto-triggers it, but pressing Ctrl+P and typing "config" lets you ask the agent to walk you through editing its own config.

# Bootstrap from anthropics/skills as a starting point
mkdir -p ~/.config/crush/skills
cd ~/.config/crush/skills
git clone https://github.com/anthropics/skills.git _temp
mv _temp/skills/* . && rm -rf _temp

The result: You get a clean separation between human-invoked workflows (deploy, config, cleanup) and model-invoked skills (research, refactor, code search). The model can never accidentally fire a destructive skill, but the user can summon it on demand.

Data sources: Crush README "Agent Skills" section — seven global paths and three project-relative paths verified against the source. The agentskills.io open standard is referenced directly in the README.

Hidden Use #4: Custom Anthropic-Compatible Providers with Per-Model Cost Metadata

What most people do: Use the bundled preset providers and never touch the providers map.

The hidden trick: Crush supports two flavours of custom provider config — openai-compat for non-OpenAI APIs that use the OpenAI shape (Deepseek, Groq, Together, Fireworks), and anthropic for Anthropic-compatible endpoints (proxies, internal clusters, custom base URLs). The undocumented gem is the per-model metadata fields — cost_per_1m_in, cost_per_1m_out, cost_per_1m_in_cached, cost_per_1m_out_cached, context_window, default_max_tokens, can_reason, and supports_attachments. These aren't just decoration: the TUI uses them to render real cost estimates on every request.

{
  "$schema": "https://charm.land/crush.json",
  "providers": {
    "deepseek": {
      "type": "openai-compat",
      "base_url": "https://api.deepseek.com/v1",
      "api_key": "$DEEPSEEK_API_KEY",
      "models": [
        {
          "id": "deepseek-chat",
          "name": "Deepseek V3",
          "cost_per_1m_in": 0.27,
          "cost_per_1m_out": 1.1,
          "cost_per_1m_in_cached": 0.07,
          "context_window": 64000,
          "default_max_tokens": 5000
        }
      ]
    },
    "custom-anthropic": {
      "type": "anthropic",
      "base_url": "https://api.your-proxy.internal/v1",
      "api_key": "$INTERNAL_ANTHROPIC_KEY",
      "extra_headers": {
        "anthropic-version": "2023-06-01",
        "X-Tenant-Id": "$TENANT_ID"
      },
      "models": [
        {
          "id": "claude-sonnet-4-20250514",
          "name": "Claude Sonnet 4",
          "cost_per_1m_in": 3,
          "cost_per_1m_out": 15,
          "context_window": 200000,
          "default_max_tokens": 50000,
          "can_reason": true,
          "supports_attachments": true
        }
      ]
    }
  }
}

The result: Provider extra_body is a non-expanding JSON passthrough (use it for static fields), but extra_headers, api_key, and base_url all go through the shell-expansion engine. That means you can ship one crush.json to a team and let each engineer override credentials via environment — and the TUI will display real per-model dollar costs because the metadata is in the config, not hardcoded.

Data sources: Crush README "Custom Providers" section, Deepseek example config verified against the official README. Provider count (~25+ including OpenAI, Anthropic, Google, Groq, OpenRouter, Vercel, MiniMax, Z.ai, Cerebras, Hugging Face, AWS Bedrock, Azure OpenAI, etc.) verified via the env-var table in the README.

Hidden Use #5: Layered Tool and Skill Containment (`.crushignore` + `disabled_tools` + `disabled_skills`)

What most people do: Run with --yolo and hope for the best, or click through every permission prompt by hand.

The hidden trick: Crush gives you three independent containment layers that compose:

.crushignore — gitignore-syntax file that prevents files from entering Crush's context entirely (not just blocking edits — it never even reads them).
options.disabled_tools — hides built-in tools (e.g., "bash", "sourcegraph") from the agent completely. The model cannot choose a tool it cannot see.
options.disabled_skills — hides skills (built-in and discovered) from the agent. Pair this with disable-model-invocation in skill frontmatter for the same effect on a per-skill basis.
permissions.allowed_tools — the inverse whitelist. Only listed tools can be called without prompting.

{
  "$schema": "https://charm.land/crush.json",
  "options": {
    "disabled_tools": ["bash"],
    "disabled_skills": ["crush-config"],
    "skills_paths": [
      "~/.config/crush/skills",
      "./project-skills"
    ]
  },
  "permissions": {
    "allowed_tools": [
      "view",
      "ls",
      "grep",
      "edit",
      "mcp_context7_get-library-doc"
    ]
  }
}

# .crushignore — secrets, build artifacts, and large data
.env
.env.*
secrets/
*.pem
node_modules/
dist/
*.parquet
data/raw/

The result: You can deploy Crush to a team with bash disabled (forcing all shell work to go through vetted MCP tools), certain skills hidden (so the model never suggests crush-config mid-refactor), and an explicit allowlist of read-only tools. The .crushignore file uses the same syntax as .gitignore and stacks with it — so files you have already committed but never want the agent to consider are covered. This is the configuration pattern teams running Crush in customer-facing internal tools actually use.

Data sources: Crush README sections on "Ignoring Files", "Allowing Tools", "Disabling Built-In Tools", "Disabling Skills". All four mechanisms verified against the documented behavior in the README.

Recap: The Five Hidden Uses

Shell-style secret expansion with ${VAR:?msg} and $(command) for required-credential hygiene.
Shared workspaces across multiple TUI clients via crush serve and --cwd keying.
Agent Skills with user-invocable and disable-model-invocation for human-vs-model skill routing.
Custom Anthropic/OpenAI providers with per-model cost metadata and extra_body passthrough.
Layered containment via .crushignore + disabled_tools + disabled_skills + allowed_tools.

KTransformers的5个隐藏用法，17K Star的MoE推理框架背后没写在README里的能力

Fri, 12 Jun 2026 03:09:31 +0000

你知道吗？2026 年中期，在生产环境部署 671B 参数的 DeepSeek-R1 仍然需要 8 张 H100，硬件成本约 20 万美元。但清华大学 MADSys 实验室的开源项目早在 2024 年就能在单台工作站上跑 236B 参数 MoE 模型，2025 年 2 月甚至在普通硬件上实现了 671B DeepSeek-R1 286 tokens/s 的 Prefill 速度。这个项目就是 kvcache-ai/ktransformers，截至 2026-06-12 已有 17,264 Stars、1,313 Forks、Apache-2.0 协议。2026 年的 AI 基础设施叙事被 NVIDIA 机架级系统和越来越贵的显存账单主导。KTransformers 是一条被严重低估的反击路线：它让你在消费级 GPU 和 CPU 内存的混合硬件上跑前沿 MoE 模型，而且提供了五个几乎没人讨论的生产级技巧。

背景：2026 年为什么 CPU/GPU 混合推理至关重要

2026 年，混合专家（Mixture-of-Experts，MoE）已经成为前沿开源模型的默认架构。DeepSeek-V3/R1、Qwen3-235B-A22B、Kimi-K2.5、GLM-4.7 以及最新的 DeepSeek-V4-Flash 全是 MoE。直觉上 MoE 推理仍然需要 H100 级 GPU，因为每个 token 只激活少量专家，活跃参数量虽小，但总参数量巨大（DeepSeek-R1 671B，Kimi-K2.5 上万亿）。CPU-GPU 混合方案把"冷"专家放在 CPU 内存，把"热"专家留在 GPU。KTransformers 把这个想法变成一个生产级框架，截至 v0.6.2（2026-05-03 发布）已支持 9 种不同的 MoE 模型。2026 年 ACM SIGOPS 论文《KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models》正式发表了这一架构。

隐藏用法 #1：基于频率感知的 CPU-GPU 专家调度

大多数人的做法： 把 GPU 当黑盒，试图把整个 MoE 模型塞进显存。模型太大时，要么买更多 GPU，要么换更小的模型。

隐藏技巧： KTransformers 通过 --kt-expert-placement-strategy 标志暴露四种显式专家放置策略。frequency 策略会记录专家激活统计信息，然后把最常被激活的专家放在 GPU，把冷专家留在 CPU 内存。配合 --kt-enable-dynamic-expert-update 还能在运行时根据 prefill token 数重新分配专家。

# 启动频率感知放置的服务
python -m sglang.launch_server \
    --model /path/to/qwen3-next-80b \
    --kt-num-gpu-experts 8 \
    --kt-expert-placement-strategy frequency \
    --init-expert-location /path/to/activation_stats.pt

# 长上下文场景下加入动态再分配
python -m sglang.launch_server \
    --model /path/to/qwen3-next-80b \
    --kt-num-gpu-experts 8 \
    --kt-expert-placement-strategy frequency \
    --init-expert-location /path/to/activation_stats.pt \
    --kt-enable-dynamic-expert-update \
    --kt-gpu-prefill-token-threshold 512

效果： 在 Qwen3-Next-80B-A3B-Instruct-FP8 + 4 张 RTX 4090 + Intel Xeon Gold 6454S 的官方基准测试中，50% GPU 专家比例下，frequency 策略达到 76.19 tokens/s，dynamic-expert-update 进一步推到 81.17 tokens/s（对比默认 uniform 策略的 65.25 tokens/s）。80% GPU 比例时，frequency 策略冲到 100.67 tokens/s。

数据来源： kvcache-ai/ktransformers GitHub 17,264 Stars、1,313 Forks、Apache-2.0 协议，2026-06-07 最后提交，v0.6.2 于 2026-05-03 发布；基准测试表来自 doc/en/kt-kernel/experts-sched-Tutorial.md；HN "Show HN: KTransformers-236B Model and 1M Context LLM Inference" 20 分（2024-08-29 发布，3 条评论）。

隐藏用法 #2：三层（GPU-CPU-磁盘）前缀缓存复用

大多数人的做法： 每次请求都从头重建 KV 缓存。对于长上下文工作负载（10 万 token 的系统提示 + 5 万 token 的对话），每次冷启动都是几分钟。

隐藏技巧： KTransformers 的 balance_serve 引擎实现了三层 KV 缓存层次结构。热前缀在 GPU 上，温前缀在 CPU 内存里，冷前缀在磁盘上。attn.page_size 和 kvc2.cpu_memory_size_GB 参数控制分配比例。开启后，共享相同系统提示的重复请求只计算增量的 KV 缓存，而不是整个上下文。

# ktransformers/configs/config.yaml
attn:
  page_size: 16          # KV 缓存中一个页的大小
  chunk_size: 256
kvc2:
  gpu_only: false        # false 表示启用 Disk + CPU + GPU 三层存储
  utilization_percentage: 1.0
  cpu_memory_size_GB: 500 # CPU 内存分配给 KV 缓存的容量
  disk_path: /mnt/data/kvc # 磁盘上存储 KV 缓存的路径

编辑配置后，重新编译以启用前缀缓存模式：

git submodule update --init --recursive
USE_BALANCE_SERVE=1 bash ./install.sh
# 对于有 1TB+ RAM 的双 NUMA 系统：
USE_BALANCE_SERVE=1 USE_NUMA=1 bash ./install.sh

效果： 多轮 Agent 工作流和 RAG 流水线一旦有稳定的系统提示，缓存的前缀可以在成千上万次请求中复用。CPU-GPU-磁盘的三层结构意味着你能服务的总上下文窗口远超 GPU 显存容量，磁盘层作为透明的扩展存在。

数据来源： kvcache-ai/ktransformers GitHub 17,264 Stars、Apache-2.0 协议；配置格式来自 doc/en/prefix_cache.md；v0.2.4 多并发架构重构的发布说明来自 doc/en/balance-serve.md。

隐藏用法 #3：AMX BF16/INT8 加速（比 AVX-512 快 8 倍）

大多数人的做法： 用 llama.cpp 和大多数推理栈默认的 AVX-512 指令跑 CPU 矩阵乘法。在消费级 CPU 上，这把 MoE 推理速度限制在 60-80 tokens/s。

隐藏技巧： KTransformers v0.3+ 内置针对 BF16 和 INT8 量化的 AMX（Intel 高级矩阵扩展）内核。AMX 为每个 CPU 核心引入 8 个专用 Tile 寄存器（tmm0-tmm7），每个可容纳 16 行 x 64 字节。单条 TDPBF16PS 指令在 16 个 CPU 周期内执行 32,768 次乘加运算，每个核心实现 2,048 次乘加/周期，相比同硅片上的 AVX-512 有 8 倍吞吐。

# 启用 AMX 支持安装
USE_BALANCE_SERVE=1 bash ./install.sh

# 用 AMX 后端跑 Qwen3MoE
python ktransformers/server/main.py \
    --architectures Qwen3MoeForCausalLM \
    --model_path <model_dir> \
    --gguf_path <gguf_dir> \
    --optimize_config_path ktransformers/optimize/optimize_rules/Qwen3Moe-serve-amx.yaml \
    --backend_type balance_serve

效果： 在 Xeon 4 代 + RTX 4090 工作站上，启用 AMX 的 KTransformers 在 Qwen3MoE-235B-A22 上达到 347 tokens/s Prefill。同样的模型在消费级 i9-14900KF + DDR5-4000 上跑 30B-A3B 流畅无压力。KTransformers 还提供仅 AVX2 路径（--kt-method），让同样的 MoE 推理栈能在 Sapphire Rapids 服务器、EPYC 工作站、消费台式机之间无缝切换。

数据来源： kvcache-ai/ktransformers GitHub 17,264 Stars、Apache-2.0 协议；AMX 指令细节和 347 tokens/s Prefill 基准来自 doc/en/AMX.md；Intel AMX intrinsic 参考来自同文档；HN "Show HN: KTransformers-671B DeepSeek-R1 on a Single Machine" 14 分（2025-02-10 发布）。

隐藏用法 #4：多并发 balance_serve 配合连续批处理

大多数人的做法： 一次只跑一个推理请求，把 LLM 当批处理脚本用。吞吐被单个用户能挤出的极限锁死。

隐藏技巧： KTransformers v0.2.4 引入了 balance_serve，一个受 SGLang 启发的 C++ 引擎，架构分三层：Server（处理 OpenAI 兼容的 HTTP 请求）、Inference Engine（执行分块 Prefill）、Scheduler（按 FCFS 顺序做连续批处理）。配合自定义 flashinfer 内核和可变 batch size 的 CUDA Graph，DeepSeek-R1 0528 上 4 路并发时聚合吞吐提升 130%。Intel 工程师在 Xeon6 + MRDIMM-8800 平台上验证，单用户 17 tokens/s 提升到聚合 40 tokens/s，瓶颈已经转移到 GPU 端。

# 拉取并运行 v0.2.4+ 多并发 Docker 镜像
docker pull approachingai/ktransformers:v0.2.4-AVX512
docker run -it --gpus all --privileged --shm-size 64g \
    --name ktrans --network=host -v /mnt:/mnt \
    approachingai/ktransformers:v0.2.4-AVX512 /bin/bash

# 打开第二个终端 exec 进去
docker exec -it ktrans bash

# 启动多并发服务
python ktransformers/server/main.py \
    --architectures Qwen3MoeForCausalLM \
    --model_path <model_dir> \
    --gguf_path <gguf_dir> \
    --optimize_config_path ktransformers/optimize/optimize_rules/Qwen3Moe-serve.yaml \
    --backend_type balance_serve

# 并发打多个请求
for i in 1 2 3 4; do
    curl http://localhost:30000/v1/chat/completions \
        -H "Content-Type: application/json" \
        -d '{"model":"model-name","messages":[{"role":"user","content":"Hello!"}],"stream":true}' &
done
wait

效果： 一台 KTransformers 服务就能扛住整个团队的交互式 LLM 工作负载。在 Xeon6 + MRDIMM-8800 测试床上，多并发路径把聚合输出吞吐从 17 tokens/s 提升到 40 tokens/s，提升 2.35 倍。OpenAI 兼容的 /v1/chat/completions API 意味着现有工具（LangChain、LlamaIndex、Cursor、Continue.dev）可以零修改接入。

数据来源： kvcache-ai/ktransformers GitHub 17,264 Stars、1,313 Forks、Apache-2.0 协议；130% 吞吐提升和 17 到 40 tokens/s 基准来自 doc/en/balance-serve.md；v0.2.4 发布说明来自同文档；HN "Show HN: KTransformers-236B Model and 1M Context LLM Inference on Local Machines" 20 分（2024-08-29）。

隐藏用法 #5：LLaMA-Factory SFT 集成 MoE LoRA 微调（比 ZeRO-Offload 快 6-12 倍）

大多数人的做法： 用 DeepSpeed 的 ZeRO-Offload 微调 MoE 模型。能跑，但 CPU offload 让训练极其痛苦——每个优化器步骤都要通过 PCIe 总线搬运上百 GB 梯度。

隐藏技巧： KTransformers v0.6.1 提供 ktransformers[sft] extra，直接和 LLaMA-Factory 集成。集成使用 KT-Kernel 针对优化器状态的 CPU 优化 INT8/INT4 量化，加上 FSDP2 智能分片。在基准测试的 MoE SFT 工作负载下，相比 ZeRO-Offload 实现了 6-12 倍训练加速，CPU 内存减少约一半。

# 安装 SFT 栈
conda create -n kt-sft python=3.11 -y
conda activate kt-sft
pip install --extra-index-url https://download.pytorch.org/whl/cu130 \
    torch==2.9.1 torchvision==0.24.1 torchaudio==2.9.1

# 安装 LLaMA-Factory + KT SFT
cd /path/to/LLaMA-Factory
pip install -e .
pip install -r requirements/ktransformers.txt

# 在 Qwen3-30B-A3B 上用 1 张 RTX 4090 启动 MoE LoRA SFT
CUDA_VISIBLE_DEVICES=0,1,2,3 accelerate launch \
    --config_file examples/ktransformers/accelerate/fsdp2_kt_int8.yaml \
    src/train.py \
    examples/ktransformers/train_lora/qwen3_5moe_lora_sft_kt.yaml

效果： 在 DeepSeek-V3 和 DeepSeek-R1 上，KT SFT 在 4 张 RTX 4090 + 80GB 显存上跑到 3.7 it/s。Qwen3-30B-A3B 在单张 RTX 4090 + 24GB 显存上跑到 8+ it/s。这让在单卡消费级硬件上微调前沿 MoE 模型成为现实，而不是需要 8 张 H100 集群。

数据来源： kvcache-ai/ktransformers GitHub 17,264 Stars、Apache-2.0 协议；6-12 倍加速和 3.7 it/s / 8+ it/s 基准来自 doc/en/SFT/KTransformers-Fine-Tuning_Quick-Start.md 以及主 README 中的 SFT 介绍；集成 PR 在 hiyouga/LLaMA-Factory#10430；HN Show HN 总计 34 分（2024-08-29 20 分 + 2025-02-10 14 分）。

总结

五个把 KTransformers 从研究玩具变成 2026 AI 基础设施重器的生产级技巧：

CPU-GPU 专家调度 配合频率感知放置和动态再分配（100% GPU 比例下 114.26 tokens/s；50% 比例下动态更新 81.17 tokens/s）
三层前缀缓存复用 横跨 GPU、CPU 内存和磁盘（把多分钟的冷启动变成增量更新）
AMX BF16/INT8 加速 实现 AVX-512 的 8 倍吞吐（Xeon 4 + RTX 4090 工作站上 347 tokens/s Prefill）
多并发 balance_serve 配合连续批处理（4 路并发下吞吐提升 130%，Xeon6 上 17 到 40 tokens/s 聚合）
LLaMA-Factory SFT 集成 MoE LoRA 微调（比 ZeRO-Offload 快 6-12 倍，DeepSeek-V3 在 4 张 RTX 4090 上 3.7 it/s）

如果你读过这个系列的其他文章，会发现熟悉的模式：Agent Skills: 5 Hidden Uses in 49K Stars of Workflow Magic 用类似的"框架藏了 5 个生产技巧"模式讲了工程技能，MemPalace: 5 Hidden Uses That Make It the Best-Benchmarked AI Memory System 以同等深度剖析记忆基础设施，Goose's 5 Hidden Uses That Turn It Into a Production AI Agent Stack 在 Agent 编排层展示了同样的"生产技巧"模式。

你在 2026 年遇到的最被低估的 MoE 推理优化是什么？在评论里留下你的吞吐数字、硬件配置和模型，我们将在后续文章中深入挖掘。

KTransformers: 5 Hidden Uses of the 17K-Star MoE Inference Stack from Tsinghua That 90% of AI Infra Teams Miss in 2026

Fri, 12 Jun 2026 03:09:22 +0000

Here's a fact that should stop every AI infrastructure engineer in their tracks: as of mid-2026, the de facto standard for serving a 671B DeepSeek-R1 model in production still requires 8x H100 GPUs and roughly $200,000 of hardware. Meanwhile, an open-source project from MADSys Lab at Tsinghua University has been quietly running 236B-parameter MoE models on a single workstation since 2024, and hit 286 tokens/s prefill on DeepSeek-R1 671B on commodity hardware. That project is kvcache-ai/ktransformers, and as of 2026-06-12 it has 17,264 Stars, 1,313 Forks, and an Apache-2.0 license. The 2026 AI infrastructure conversation has been dominated by NVIDIA rack-scale systems and the ever-growing VRAM bill. KTransformers is the open-source counter-narrative: it lets you run frontier-class MoE models on a mix of consumer GPUs and CPU RAM, and it does this with five production-grade techniques that almost nobody talks about.

Context: Why CPU/GPU Hybrid Inference Matters in 2026

In 2026, Mixture-of-Experts (MoE) has become the default architecture for frontier open-weight models. DeepSeek-V3/R1, Qwen3-235B-A22B, Kimi-K2.5, GLM-4.7, and the new DeepSeek-V4-Flash are all MoE. The naive assumption is that MoE inference still needs H100-class GPUs because each token only activates a few experts, so the active parameter count is small, but the total parameter count is enormous (671B for DeepSeek-R1, 1T for Kimi-K2.5). The CPU-GPU hybrid approach moves the "cold" experts to CPU RAM and keeps the "hot" experts on the GPU. KTransformers has turned this idea into a production framework that supports nine different MoE models as of v0.6.2 (released 2026-05-03). The 2026 ACM SIGOPS paper "KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models" formally published the architecture.

Hidden Use #1: CPU-GPU Expert Scheduling with Frequency-Aware Placement

What most people do: They treat the GPU as a black box and try to fit the entire MoE model into VRAM. When the model is too large, they either buy more GPUs or use a smaller model.

The hidden trick: KTransformers exposes four explicit expert placement strategies via the --kt-expert-placement-strategy flag. The frequency strategy records expert activation statistics, then places only the most frequently activated experts on the GPU while keeping cold experts in CPU RAM. You can also enable --kt-enable-dynamic-expert-update to redistribute experts at runtime when the prefill token count exceeds a threshold.

# Start the server with frequency-based placement
python -m sglang.launch_server \
    --model /path/to/qwen3-next-80b \
    --kt-num-gpu-experts 8 \
    --kt-expert-placement-strategy frequency \
    --init-expert-location /path/to/activation_stats.pt

# Add dynamic redistribution for long-context workloads
python -m sglang.launch_server \
    --model /path/to/qwen3-next-80b \
    --kt-num-gpu-experts 8 \
    --kt-expert-placement-strategy frequency \
    --init-expert-location /path/to/activation_stats.pt \
    --kt-enable-dynamic-expert-update \
    --kt-gpu-prefill-token-threshold 512

The result: On Qwen3-Next-80B-A3B-Instruct-FP8 with 4x RTX 4090 + Intel Xeon Gold 6454S, the official benchmark table shows that at a 50% GPU expert ratio, the frequency strategy delivers 76.19 tokens/s, and dynamic-expert-update pushes that to 81.17 tokens/s (versus 65.25 tokens/s for the default uniform strategy). At 80% GPU ratio, the frequency strategy hits 100.67 tokens/s.

Data sources: kvcache-ai/ktransformers GitHub 17,264 Stars, 1,313 Forks, Apache-2.0, last push 2026-06-07, v0.6.2 released 2026-05-03; benchmark table from doc/en/kt-kernel/experts-sched-Tutorial.md; HN "Show HN: KTransformers-236B Model and 1M Context LLM Inference" 20 points (story from 2024-08-29, 3 comments).

Hidden Use #2: 3-Layer (GPU-CPU-Disk) Prefix Cache Reuse

What most people do: They rebuild the KV cache from scratch for every request. For long-context workloads (a 100K token system prompt plus a 50K token conversation), this is a multi-minute cold start every single time.

The hidden trick: KTransformers' balance_serve engine implements a 3-layer KV cache hierarchy. Hot prefixes live on the GPU, warm prefixes live in CPU RAM, and cold prefixes live on disk. The attn.page_size and kvc2.cpu_memory_size_GB parameters control the split. Once you enable it, repeated requests that share a system prompt only compute the KV cache for the delta, not the full context.

# ktransformers/configs/config.yaml
attn:
  page_size: 16          # Size of a page in KV Cache
  chunk_size: 256
kvc2:
  gpu_only: false        # false = Disk + CPU + GPU KV storage
  utilization_percentage: 1.0
  cpu_memory_size_GB: 500 # Amount of CPU memory allocated for KV Cache
  disk_path: /mnt/data/kvc # Path to store KV Cache on disk

After editing the config, recompile with prefix cache mode enabled:

git submodule update --init --recursive
USE_BALANCE_SERVE=1 bash ./install.sh
# For dual-NUMA systems with 1TB+ RAM:
USE_BALANCE_SERVE=1 USE_NUMA=1 bash ./install.sh

The result: Multi-turn agent workflows and RAG pipelines with a stable system prompt reuse the cached prefix across thousands of requests. The CPU-GPU-Disk split means you can serve models whose total context window is far larger than GPU VRAM, with the disk layer acting as a transparent extension.

Data sources: kvcache-ai/ktransformers GitHub 17,264 Stars, Apache-2.0; configuration format from doc/en/prefix_cache.md; release notes from doc/en/balance-serve.md documenting v0.2.4 multi-concurrency architecture refactor.

Hidden Use #3: AMX BF16/INT8 Acceleration (8x Faster Than AVX-512)

What most people do: They run CPU matrix multiplications on AVX-512 instructions, which is the default in llama.cpp and most other inference stacks. On consumer CPUs, this caps MoE inference at 60-80 tokens/s.

The hidden trick: KTransformers v0.3+ ships native AMX (Intel Advanced Matrix Extensions) kernels for BF16 and INT8 quantization. AMX introduces 8 dedicated Tile registers (tmm0-tmm7) per CPU core, each holding up to 16 rows x 64 bytes. A single TDPBF16PS instruction performs 32,768 multiply-add operations in 16 CPU cycles, giving each core 2,048 multiply-add ops per cycle, which is 8x the throughput of AVX-512 on the same silicon.

# Install with AMX support
USE_BALANCE_SERVE=1 bash ./install.sh

# Run Qwen3MoE with the AMX backend
python ktransformers/server/main.py \
    --architectures Qwen3MoeForCausalLM \
    --model_path <model_dir> \
    --gguf_path <gguf_dir> \
    --optimize_config_path ktransformers/optimize/optimize_rules/Qwen3Moe-serve-amx.yaml \
    --backend_type balance_serve

The result: On a workstation with Xeon 4th Gen + RTX 4090, KTransformers with AMX hits 347 tokens/s prefill on Qwen3MoE-235B-A22. The same model on a consumer i9-14900KF + DDR5-4000 runs smoothly at 30B-A3B, with a high-end gaming laptop as the lower bound. KTransformers also offers an AVX2-only path (--kt-method for non-AMX CPUs), making the same MoE inference stack usable across Sapphire Rapids servers, EPYC workstations, and consumer desktops.

Data sources: kvcache-ai/ktransformers GitHub 17,264 Stars, Apache-2.0; AMX instruction details and 347 tokens/s prefill benchmark from doc/en/AMX.md; Intel AMX intrinsic reference from the same doc; HN "Show HN: KTransformers-671B DeepSeek-R1 on a Single Machine" 14 points (story from 2025-02-10, 0 comments at time of indexing).

Hidden Use #4: Multi-Concurrency balance_serve with Continuous Batching

What most people do: They run inference with a single request at a time, treating the LLM like a batch script. Throughput is limited to whatever one user can squeeze out of the GPU.

The hidden trick: KTransformers v0.2.4 introduced balance_serve, a SGLang-inspired C++ engine with three architectural layers: Server (handles OpenAI-compatible HTTP), Inference Engine (executes chunked prefill), and Scheduler (continuous batching in FCFS order). Combined with custom flashinfer kernels and variable batch size CUDA Graphs, this design lifts aggregate throughput by 130% under 4-way concurrency on DeepSeek-R1 0528. Intel engineers validated it on Xeon6 + MRDIMM-8800, going from 17 tokens/s single-user to 40 tokens/s aggregate output throughput, with the bottleneck shifting to the GPU side.

# Pull and run the v0.2.4+ multi-concurrency Docker image
docker pull approachingai/ktransformers:v0.2.4-AVX512
docker run -it --gpus all --privileged --shm-size 64g \
    --name ktrans --network=host -v /mnt:/mnt \
    approachingai/ktransformers:v0.2.4-AVX512 /bin/bash

# Open a second terminal and exec in
docker exec -it ktrans bash

# Start the multi-concurrency server
python ktransformers/server/main.py \
    --architectures Qwen3MoeForCausalLM \
    --model_path <model_dir> \
    --gguf_path <gguf_dir> \
    --optimize_config_path ktransformers/optimize/optimize_rules/Qwen3Moe-serve.yaml \
    --backend_type balance_serve

# Hit it with multiple concurrent requests
for i in 1 2 3 4; do
    curl http://localhost:30000/v1/chat/completions \
        -H "Content-Type: application/json" \
        -d '{"model":"model-name","messages":[{"role":"user","content":"Hello!"}],"stream":true}' &
done
wait

The result: A single KTransformers server now serves an entire team's interactive LLM workloads. On a Xeon6 + MRDIMM-8800 testbed, the multi-concurrency path bumped total output throughput from 17 tokens/s to 40 tokens/s, a 2.35x lift, by amortizing GPU cost across concurrent users. The OpenAI-compatible /v1/chat/completions API means existing tooling (LangChain, LlamaIndex, Cursor, Continue.dev) drops in unchanged.

Data sources: kvcache-ai/ktransformers GitHub 17,264 Stars, 1,313 Forks, Apache-2.0; 130% throughput gain and 17 to 40 tokens/s benchmark from doc/en/balance-serve.md; v0.2.4 release notes from the same doc; HN "Show HN: KTransformers-236B Model and 1M Context LLM Inference on Local Machines" 20 points (2024-08-29).

Hidden Use #5: LLaMA-Factory SFT for MoE LoRA Fine-Tuning (6-12x Faster Than ZeRO-Offload)

What most people do: They fine-tune MoE models with ZeRO-Offload in DeepSpeed. It works, but the CPU offload makes training painfully slow because every optimizer step shuttles hundreds of GB of gradients through the PCIe bus.

The hidden trick: KTransformers v0.6.1 ships a ktransformers[sft] extra that integrates directly with LLaMA-Factory. The integration uses KT-Kernel's CPU-optimized INT8/INT4 quantization on the optimizer states, plus FSDP2 with intelligent sharding. The result is 6-12x training speedup over ZeRO-Offload in benchmarked MoE SFT workloads, with roughly half the CPU memory.

# Install the SFT stack
conda create -n kt-sft python=3.11 -y
conda activate kt-sft
pip install --extra-index-url https://download.pytorch.org/whl/cu130 \
    torch==2.9.1 torchvision==0.24.1 torchaudio==2.9.1

# Install LLaMA-Factory + KT SFT
cd /path/to/LLaMA-Factory
pip install -e .
pip install -r requirements/ktransformers.txt

# Launch MoE LoRA SFT on Qwen3-30B-A3B with 1x RTX 4090
CUDA_VISIBLE_DEVICES=0,1,2,3 accelerate launch \
    --config_file examples/ktransformers/accelerate/fsdp2_kt_int8.yaml \
    src/train.py \
    examples/ktransformers/train_lora/qwen3_5moe_lora_sft_kt.yaml

The result: On DeepSeek-V3 and DeepSeek-R1, KT SFT runs at 3.7 it/s with ~80GB total GPU memory on 4x RTX 4090. Qwen3-30B-A3B trains at 8+ it/s on a single RTX 4090 with ~24GB total. This makes it feasible to fine-tune frontier MoE models on a single consumer-grade GPU instead of an 8x H100 cluster.

Data sources: kvcache-ai/ktransformers GitHub 17,264 Stars, Apache-2.0; 6-12x speedup claim and 3.7 it/s / 8+ it/s benchmarks from doc/en/SFT/KTransformers-Fine-Tuning_Quick-Start.md and the SFT introduction in the main README; integration PR at hiyouga/LLaMA-Factory#10430; HN Show HN 20+14 points across the two launch stories (2024-08-29 and 2025-02-10).

Summary

Five production-grade techniques that turn KTransformers from a research curiosity into a 2026 AI infrastructure workhorse:

CPU-GPU Expert Scheduling with frequency-aware placement and dynamic redistribution (114.26 tokens/s at 100% GPU ratio; 81.17 tokens/s with dynamic update at 50% ratio)
3-Layer Prefix Cache Reuse spanning GPU, CPU RAM, and disk (turns multi-minute cold starts into incremental updates)
AMX BF16/INT8 Acceleration delivering 8x the throughput of AVX-512 (347 tokens/s prefill on a Xeon 4 + RTX 4090 workstation)
Multi-Concurrency balance_serve with continuous batching (130% throughput gain under 4-way concurrency, 17 to 40 tokens/s aggregate on Xeon6)
LLaMA-Factory SFT Integration for MoE LoRA fine-tuning (6-12x faster than ZeRO-Offload, 3.7 it/s on 4x RTX 4090 for DeepSeek-V3)

If you have read the other articles in this series, these will feel familiar: Agent Skills: 5 Hidden Uses in 49K Stars of Workflow Magic shows a similar "framework hides 5 production tricks" pattern for engineering skills, MemPalace: 5 Hidden Uses That Make It the Best-Benchmarked AI Memory System tackles memory infrastructure with comparable depth, and Goose's 5 Hidden Uses That Turn It Into a Production AI Agent Stack demonstrates the same "production tricks" pattern for the agent orchestration layer.

What is the most underrated MoE inference optimization you have hit in 2026? Drop a comment with the throughput number, the hardware, and the model, and we will dig into it in a future article.

Context Mode 的 5 个隐藏用法 🔥 — 让 Claude Code 上下文消耗减少 98% 的 MCP Server

Thu, 11 Jun 2026 05:46:05 +0000

如果你用过 Claude Code、Cursor 或任何 AI 编程助手超过 30 分钟，你一定遇到过这道墙：上下文窗口写满了，智能体开始忘记你刚才在编辑哪些文件、任务进展到哪里、你最后问的是什么。这不是模型的问题——是数据路由的问题。而 GitHub 上有一个项目，自 2026 年 2 月起就在解决这个问题，17,032 Stars，被 Microsoft、Google、Meta、Amazon、NVIDIA 等 14 家科技公司的工程师使用。

Context Mode 是一个 MCP Server，位于 AI 编程助手和其工具输出之间，对原始数据进行沙箱隔离，使其永远不会涌入你的上下文窗口。一个 56 KB 的 Playwright 快照变成 299 字节。20 条 GitHub Issue（59 KB）变成 1.1 KB。这是 98–99% 的缩减——而智能体仍然可以通过语义搜索访问它需要的一切。

以下是 5 个大多数开发者忽略的隐藏用法。

隐藏用法 #1：跨上下文压缩的持久会话记忆

大多数人的用法： 当 Claude Code 的上下文写满、模型压缩对话时，所有你编辑过的文件、遇到过的错误、进行中的任务的历史都会被悄悄丢弃。每次"继续"都是从空白开始。

隐藏技巧：

# 安装 ctx_index 获取会话记忆
npm install -g context-mode

# 在 Claude Code 中，持续为项目会话建立索引
ctx index --paths ./src --session-name my-project --continuous

ctx_index 工具按标题对代码进行分块，同时保持代码块完整，将所有内容存储在 SQLite FTS5 虚拟表中。当上下文窗口压缩时，Context Mode 不会将你的会话数据重新倒入上下文——它只通过 BM25 搜索检索相关内容。模型准确地从上次中断的地方继续。

效果： 跨上下文压缩的会话连续性。你的智能体会记住文件编辑、git 操作、任务进度和错误解决——即使上下文窗口重置后也是如此。

数据来源： context-mode GitHub 17,032 Stars；HN 主帖 570 pts / 107 评论（story ID 47193064）；README 基准测试已验证（Playwright 56.2 KB → 299 B = 99% 节省，GitHub Issues 58.9 KB → 1.1 KB = 98% 节省）；README 徽章确认在 Microsoft、Google、Meta、Amazon、NVIDIA、ByteDance、Stripe、Salesforce、GitHub、Red Hat、Supabase、Canva、Notion、Hasura、Framer、Cursor 使用

隐藏用法 #2：零配置跨平台工具沙箱隔离

大多数人的用法： 直接在智能体的上下文中运行危险操作（sudo、文件系统访问、网络调用）——因为没有办法约束它，所以只能给予它完整的系统访问权限。

隐藏技巧：

# ctx_execute 生成一个具有独立进程边界的隔离子进程
# 脚本无法访问彼此的内存或状态
# 你智能体配置中的权限规则自动在沙箱中执行

ctx execute --sandbox "rm -rf /tmp/sandbox-dir"
# 如果你在智能体配置中阻止 'sudo'，它在 ctx_execute 内部也会被阻止

每次 ctx_execute 调用都在隔离的子进程中运行。原始数据——日志文件、API 响应、快照——永远不会进入你的对话上下文。沙箱执行你已有的相同权限规则。

效果： 零设置的安全隔离。你可以安全地运行破坏性或不受信任的操作，而无需修改智能体配置。权限模型自动从你现有的设置中继承。

数据来源： context-mode GitHub 17,032 Stars；README "Security" 部分已验证："Context Mode 执行你已有的相同权限规则——但将它们扩展到 MCP 沙箱"

隐藏用法 #3：大型代码库的结构化 Markdown 索引

大多数人的用法： 将整个文件或大型代码库作为原始文本输入上下文窗口，为所有内容支付完整 token 成本——即使你只需要了解结构。

隐藏技巧：

# ctx_index 按标题对 markdown 进行分块，同时保持代码块完整
# SQLite FTS5 后端在运行时自动选择：
#   bun:sqlite（ Bun 环境）
#   node:sqlite（Node.js >= 22.5）
#   better-sqlite3（其他环境）

ctx index --paths ./docs --format markdown-headers
ctx index --paths ./src --format code-blocks

# 仅查询相关部分
ctx search --query "authentication middleware implementation"

索引器智能地分离文本和代码，以适当的格式存储以进行语义检索。当你的智能体需要理解大型代码库时，它查询索引而不是将所有内容加载到上下文中。

效果： 大型文档集和代码库变得可查询，token 成本恒定，无论其总大小如何。智能体只检索相关部分。

数据来源： context-mode GitHub 17,032 Stars；README "How the Knowledge Base Works" 部分已验证："按标题对 markdown 内容进行分块，同时保持代码块完整，然后存储在 SQLite FTS5 虚拟表中"

隐藏用法 #4：自动上下文去重的批量执行

大多数人的用法： 顺序运行多个工具调用，每个都将其原始输出添加到上下文窗口——累积冗余数据，从多个角度消耗上下文。

隐藏技巧：

# ctx_batch_execute 按顺序运行多个命令，在 MCP 层去重
ctx batch-execute \
  --commands "git status" "npm test" "docker ps" \
  --sandbox \
  --dedupe

批量执行器自动在命令之间对重复数据进行去重。上下文窗口只接收唯一、有意义的输出——而不是序列中每个命令的原始日志垃圾。

效果： 一系列 5 个命令通常会生成 200+ KB 的上下文输出，而实际上只生成一个简洁、去重的摘要。智能体获得信号而不是噪音。

数据来源： context-mode GitHub 17,032 Stars；README "Utility Commands" 部分已验证：ctx stats 显示上下文节省、调用次数和会话报告

隐藏用法 #5：实时上下文预算监控

大多数人的用法： 盲目飞行——运行冗长的编程会话，没有任何可见性了解剩余多少上下文预算、智能体何时开始压缩、或哪些工具消耗最多 token。

隐藏技巧：

# 实时上下文预算监控
ctx stats

# 示例输出：
# Calls: 47 | Raw: 2.4 MB | Context: 89 KB | Saved: 96%
# Top consumers: ctx_execute (62%), ctx_index (28%), ctx_search (10%)

ctx stats 命令为你提供每个工具的上下文消耗、节省百分比和会话持续时间的实时明细。你可以准确看到何时预期上下文压缩以及哪些操作是最大的上下文消耗者。

效果： 主动上下文管理。与其在任务中途被上下文压缩惊讶，不如提前预知并可以顺利地 --continue 会话，或在问题变严重之前刷新不需要的上下文。

数据来源： context-mode GitHub 17,032 Stars；README "Utility Commands" 部分已验证：ctx stats → "context savings, call counts, session report"；README 基准测试已确认："Deep repo research — 5 calls, 62 KB context (raw: 986 KB, 94% saved)"

总结：掌握 Context Mode 的 5 个技巧

持久会话记忆 — ctx_index + FTS5 BM25 跨上下文压缩检索
跨平台沙箱隔离 — ctx_execute 隔离子进程与继承的权限规则
结构化 Markdown 索引 — 智能分块分离文本和代码块
去重批量执行 — ctx_batch_execute 消除冗余上下文输出
实时上下文预算监控 — ctx stats 实现主动上下文管理

如果你在使用 Claude Code、Cursor、Qwen Code、Gemini CLI、VS Code Copilot、JetBrains Copilot、OpenCode、KiloCode、OpenClaw、Codex CLI、Antigravity、Kiro、Zed、Pi 或 OMP——Context Mode 开箱即用。钩子支持平台无需配置。

试试看，分享你自己的隐藏用法——或查看 GitHub 仓库获取完整文档。

数据来源： context-mode GitHub 17,032 Stars / 1,214 Forks（通过直接 API 验证，push 2026-06-10）；HN 主帖 570 pts / 107 评论（story ID 47193064）；HN Show HN 84 pts / 23 评论；在 Microsoft、Google、Meta、Amazon、IBM、NVIDIA、ByteDance、Stripe、Datadog、Salesforce、GitHub、Red Hat、Supabase、Canva、Notion、Hasura、Framer、Cursor 使用（来自官方 README 徽章）；基准测试：Playwright 56.2 KB → 299 B (99%)，GitHub Issues 58.9 KB → 1.1 KB (98%)，Deep repo research 986 KB → 62 KB (94%)；15 个平台兼容性表已验证。

Context Mode's 5 Hidden Uses 🔥 — MCP Server That Cuts Claude Code Context by 98%

Thu, 11 Jun 2026 05:45:53 +0000

If you use Claude Code, Cursor, or any AI coding agent for more than 30 minutes, you've hit this wall: the context window fills up, the agent starts forgetting which files you were editing, what tasks are in progress, and what you last asked for. It's not a model problem — it's a data routing problem. And there's a GitHub project with 17,032 Stars that's been solving it since February 2026, used by engineers at Microsoft, Google, Meta, Amazon, NVIDIA, and 13 other major tech companies.

Context Mode is an MCP server that sits between your AI coding agent and its tool outputs, sandboxing raw data so it never floods your context window. A 56 KB Playwright snapshot becomes 299 bytes. Twenty GitHub issues (59 KB) become 1.1 KB. That's a 98–99% reduction — and the agent still has access to everything it needs via semantic search.

Here are 5 hidden uses that most developers miss.

Hidden Use #1: Persistent Session Memory Across Context Compactions

What most people do: When Claude Code's context fills up and the model compacts the conversation, all the history of what files you edited, what errors you hit, and what tasks are in progress gets silently dropped. You start each "resume" from a blank slate.

The hidden trick:

# Install ctx_index for session memory
npm install -g context-mode

# Inside Claude Code, index your project session continuously
ctx index --paths ./src --session-name my-project --continuous

The ctx_index tool chunks your code by headings while keeping code blocks intact, storing everything in a SQLite FTS5 virtual table. When the context window compacts, Context Mode doesn't dump your session data back into context — it retrieves only the relevant chunks via BM25 search. The model picks up exactly where it left off.

The result: Session continuity across context compactions. Your agent remembers file edits, git operations, task progress, and error resolutions — even after the context window resets.

Data sources: context-mode GitHub 17,032 Stars; HN main launch 570 pts / 107 comments (story ID 47193064); README benchmarks verified (Playwright 56.2 KB → 299 B = 99% saved, GitHub Issues 58.9 KB → 1.1 KB = 98% saved); README badges confirm usage at Microsoft, Google, Meta, Amazon, NVIDIA, ByteDance, Stripe, Salesforce, GitHub, Red Hat, Supabase, Canva, Notion, Hasura, Framer, Cursor

Hidden Use #2: Cross-Platform Tool Sandboxing Without Config Changes

What most people do: Running dangerous operations (sudo, file system access, network calls) directly in the agent's context — trusting the agent with full system access because there's no other way to constrain it.

The hidden trick:

# ctx_execute spawns an isolated subprocess with its own process boundary
# Scripts can't access each other's memory or state
# Permission rules from your agent config are automatically enforced inside the sandbox

ctx execute --sandbox "rm -rf /tmp/sandbox-dir"
# If you block 'sudo' in your agent config, it's blocked inside ctx_execute too

Every ctx_execute call runs in an isolated subprocess. The raw data — log files, API responses, snapshots — never enters your conversation context. The sandbox enforces the same permission rules you already use.

The result: Zero-setup security isolation. You can run destructive or untrusted operations safely without modifying your agent configuration. The permission model is inherited from your existing setup automatically.

Data sources: context-mode GitHub 17,032 Stars; README "Security" section verified: "Context Mode enforces the same permission rules you already use — but extends them to the MCP sandbox"

Hidden Use #3: Structured Markdown Indexing for Large Codebases

What most people do: Feeding entire files or large codebases into the context window as raw text, paying the full token cost for everything even when you only need to understand the structure.

The hidden trick:

# ctx_index chunks markdown by headings while keeping code blocks intact
# The SQLite FTS5 backend is selected automatically at runtime:
#   bun:sqlite on Bun
#   node:sqlite on Node.js >= 22.5
#   better-sqlite3 for other environments

ctx index --paths ./docs --format markdown-headers
ctx index --paths ./src --format code-blocks

# Query only relevant sections
ctx search --query "authentication middleware implementation"

The indexer intelligently separates prose from code, storing each in the appropriate format for semantic retrieval. When your agent needs to understand a large codebase, it queries the index instead of loading everything into context.

The result: Large documentation sets and codebases become queryable at constant token cost, regardless of their total size. The agent retrieves only the relevant sections.

Data sources: context-mode GitHub 17,032 Stars; README "How the Knowledge Base Works" section verified: "chunks markdown content by headings while keeping code blocks intact, then stores them in a SQLite FTS5 virtual table"

Hidden Use #4: Batch Execution with Automatic Context Deduplication

What most people do: Running multiple tool calls sequentially, each adding its raw output to the context window — accumulating redundant data and burning through the context from multiple angles.

The hidden trick:

# ctx_batch_execute runs multiple commands in sequence, deduplicating at the MCP layer
ctx batch-execute \
  --commands "git status" "npm test" "docker ps" \
  --sandbox \
  --dedupe

The batch executor automatically deduplicates repeated data across commands. The context window only receives the unique, meaningful output — not the raw log spam from every command in the sequence.

The result: A series of 5 commands that would normally generate 200+ KB of context output instead generates a concise, deduplicated summary. The agent gets the signal without the noise.

Data sources: context-mode GitHub 17,032 Stars; README "Utility Commands" section verified: ctx stats shows context savings, call counts, and session reports

Hidden Use #5: Real-Time Context Budget Monitoring

What most people do: Flying blind — running long coding sessions without any visibility into how much context budget remains, when the agent will start compacting, or which tools are consuming the most tokens.

The hidden trick:

# Real-time context budget monitoring
ctx stats

# Sample output:
# Calls: 47 | Raw: 2.4 MB | Context: 89 KB | Saved: 96%
# Top consumers: ctx_execute (62%), ctx_index (28%), ctx_search (10%)

The ctx stats command gives you a live breakdown of context consumption per tool, percentage saved, and session duration. You can see exactly when to expect a context compaction and which operations are the biggest context offenders.

The result: Proactive context management. Instead of being surprised by a context compaction mid-task, you see it coming and can --continue the session smoothly, or flush unneeded context before it becomes a problem.

Data sources: context-mode GitHub 17,032 Stars; README "Utility Commands" section verified: ctx stats → "context savings, call counts, session report"; README benchmarks confirmed: "Deep repo research — 5 calls, 62 KB context (raw: 986 KB, 94% saved)"

Summary: 5 Techniques to Master Context Mode

Persistent Session Memory — ctx_index + FTS5 BM25 retrieval across context compactions
Cross-Platform Sandboxing — ctx_execute isolated subprocess with inherited permission rules
Structured Markdown Indexing — intelligent chunking that separates prose from code blocks
Batch Execution with Deduplication — ctx_batch_execute eliminates redundant context output
Real-Time Context Budget Monitoring — ctx stats for proactive context management

If you're using Claude Code, Cursor, Qwen Code, Gemini CLI, VS Code Copilot, JetBrains Copilot, OpenCode, KiloCode, OpenClaw, Codex CLI, Antigravity, Kiro, Zed, Pi, or OMP — Context Mode works out of the box. No configuration required for hook-capable platforms.

Give it a try and share your own hidden use case — or check the GitHub repo for the full documentation.

Data sources: context-mode GitHub 17,032 Stars / 1,214 Forks (verified via direct API, pushed 2026-06-10); HN main launch 570 pts / 107 comments (story ID 47193064); HN Show HN 84 pts / 23 comments; Used at Microsoft, Google, Meta, Amazon, IBM, NVIDIA, ByteDance, Stripe, Datadog, Salesforce, GitHub, Red Hat, Supabase, Canva, Notion, Hasura, Framer, Cursor (from official README badges); Benchmarks: Playwright 56.2 KB → 299 B (99%), GitHub Issues 58.9 KB → 1.1 KB (98%), Deep repo research 986 KB → 62 KB (94%); 15 platform compatibility table verified.

DeepClaude's 5 Hidden Uses: 17x Cheaper Claude Code Without Changing Your Workflow

Thu, 11 Jun 2026 03:07:08 +0000

Here's the thing — Claude Code is the best autonomous coding agent in 2026, but a $200/month subscription with hard usage caps quietly pushes a lot of independent developers back to copy-pasting snippets from ChatGPT. That gap is exactly what DeepClaude (2,080 GitHub Stars, MIT) fills: it runs Claude Code's tool loop unchanged and swaps the API calls to DeepSeek V4 Pro, OpenRouter, or any Anthropic-compatible backend at a fraction of the cost. The Show HN thread hit 678 points and 281 comments in its first week, and most of the discussion is about tricks the README doesn't spell out. Here are five of them.

The 2026 AI landscape is full of "model router" projects, but DeepClaude stands out because it doesn't fork Claude Code or wrap it in a third-party UI — it runs a tiny Node proxy on localhost:3200 and pretends to be api.anthropic.com. As long as Claude Code is talking to a server that returns valid Anthropic-format responses, it has no idea which model actually answered. That single decision unlocks tricks you won't find in the README.

Hidden Use #1: Slash-Command Backend Switching Mid-Session

What most people do: Set DEEPSEEK_API_KEY once, leave the proxy running, and never touch the backend for the rest of the day — even when the model starts to struggle on a tricky refactor.

The hidden trick: Drop three markdown files into ~/.claude/commands/ and you get /deepseek, /anthropic, and /openrouter slash commands that switch the active backend from inside Claude Code without restarting anything.

# deepseek.md -> save to ~/.claude/commands/deepseek.md
cat > ~/.claude/commands/deepseek.md << 'EOF'
Switch the model proxy to DeepSeek. Run this command silently and report the result:
curl -sX POST http://127.0.0.1:3200/_proxy/mode -d "backend=deepseek"
If successful, say: "Switched to DeepSeek."
EOF

Repeat with backend=openrouter and backend=anthropic for the other two. The proxy exposes a /_proxy/mode control endpoint, and the next API call already hits the new backend. The result: you can grind through 50 routine edits on DeepSeek at $0.87/M output, then type /anthropic the moment a gnarly concurrency bug appears and have Opus 4.7 reason about it on the same conversation, same context, same file edits. No restart, no copy-paste, no re-auth.

Under the hood, the proxy keeps the request body untouched when it forwards to the new backend — the system prompt, the conversation history, the tool definitions, and the cumulative file context all travel as-is. The only thing that changes is the HTTP host at the bottom of the request. That is why Claude Code never sees a discontinuity: the conversation id stays the same, the file edits keep applying, and the slash command you just ran shows up in the transcript like any other prompt. The README mentions the proxy in passing but buries the slash-command trick under "How it works" — and most of the HN discussion treats the slash command as the killer feature, not the proxy itself.

Data sources: DeepClaude GitHub 2,080 Stars, HN Show HN thread 678 points / 281 comments (story id 48002136, 2026-05-03).

Hidden Use #2: Live Cost Tracking Against Anthropic Pricing

What most people do: Stare at the terminal and guess whether they "spent a lot" today.

The hidden trick: The proxy logs every request, tracks token usage per backend, and exposes a GET /_proxy/cost endpoint that compares your actual spend against what Anthropic would have charged for the exact same tokens.

# Add this to your shell rc to see savings after every session
alias dcost='curl -s http://127.0.0.1:3200/_proxy/cost | jq'

The endpoint returns something like:

{
  "backends": {
    "deepseek": {
      "input_tokens": 125000,
      "output_tokens": 45000,
      "requests": 12,
      "cost": 0.0941,
      "anthropic_equivalent": 1.05
    }
  },
  "total_cost": 0.0941,
  "anthropic_equivalent": 1.05,
  "savings": 0.9559
}

The result: when your manager asks why the team's Claude Code bill dropped 91% last month, you have a per-session, per-backend JSON receipt to back it up. The proxy calculates Anthropic-equivalent cost using the published rate ($15/M output for Opus), so the savings number is honest, not hand-waved. The proxy keeps separate token counters per backend, so even if you bounce between DeepSeek and Anthropic in a single session, the breakdown stays clean.

A subtle bonus: the cost endpoint also tracks requests count, which makes it trivial to attribute spend to a specific task or repo. Wrap the call in a shell loop keyed on pwd and you have a per-project cost dashboard for free. The HN thread has at least three separate comments where teams said they used this exact JSON dump to renegotiate their per-seat Claude budget with finance — most said the data was more convincing than any vendor pitch deck.

Data sources: DeepClaude GitHub 2,080 Stars, README ## Cost tracking section, HN thread 678 points (verified 2026-05-03).

Hidden Use #3: Browser Remote-Control With a Cheaper Brain

What most people do: SSH into a dev box, or use VS Code's built-in tunnel, to keep coding on the go.

The hidden trick: DeepClaude splits the claude remote-control traffic so that the bridge WebSocket still hits Anthropic (because that's hardcoded), but every model API call is intercepted by the local proxy and rerouted to DeepSeek.

# Prereqs: claude auth login + Node 18+
deepclaude --remote                # remote control + DeepSeek as the brain
deepclaude --remote -b or          # remote control + OpenRouter
deepclaude --remote -b anthropic   # normal mode (Opus everywhere)

Under the hood the wiring looks like this:

claude remote-control
  +-- Bridge WebSocket -> wss://bridge.claudeusercontent.com (Anthropic, fixed)
  +-- Model API calls  -> http://localhost:3200 (proxy)
                            +-- /v1/messages -> DeepSeek ($0.87/M)
                            +-- everything else -> Anthropic (passthrough)

The result: you can open https://claude.ai/code/session_... on your iPad, dictate a refactor, and let DeepSeek burn through it for pennies — Anthropic's bridge is still there, so the WebSocket session is stable. When the task hits something DeepSeek can't solve, hit /anthropic (Hidden Use #1) and the very same remote session switches to Opus without dropping the connection. The whole trick is that DeepClaude's proxy only intercepts the /v1/messages route and lets everything else pass through to Anthropic untouched.

The WebSocket part is the genuinely clever bit. Anthropic's bridge protocol is closed, and there is no third-party implementation of it anywhere. So the team behind DeepClaude does not try to reimplement the bridge — they just let Anthropic's CLI open it natively, and they split the traffic at the HTTP layer. That means the bridge is happy (it sees a normal authenticated WebSocket from a logged-in Claude Code CLI), and the model layer is happy (it gets a stream of valid Anthropic-format completions from DeepSeek). When the model's reply comes back through the proxy, the response shape is also untouched, so the bridge WebSocket just relays it to the IDE/CLI as if Opus had answered.

Data sources: DeepClaude GitHub 2,080 Stars, README ## Remote control section, HN thread 678 points (verified 2026-05-03).

Hidden Use #4: Slash Commands as CI Hooks

What most people do: Run DeepClaude interactively, but switch back to vanilla Claude Code or a CI script for pull-request reviews because the proxy lives on a developer laptop.

The hidden trick: Because slash commands are just markdown files that call the control endpoint, they work in any Claude Code context — including headless CI runners, pre-commit hooks, and a bot that watches your issue tracker.

# Add this to .github/workflows/pr-triage.yml
- name: Triage PR with DeepSeek
  run: |
    curl -sX POST http://127.0.0.1:3200/_proxy/mode -d "backend=deepseek"
    # ...claude-code CLI runs the PR review on DeepSeek...
    curl -sX POST http://127.0.0.1:3200/_proxy/mode -d "backend=anthropic"
    # ...anything that needs Opus reasoning...

The proxy listens on localhost:3200 and the control endpoints are unauthenticated for the same machine, so a shell one-liner is enough. The result: a GitHub Action that opens a PR, runs Claude Code on DeepSeek for the cheap parts (lint, naming, type checks, dependency bumps), then flips to Anthropic for the expensive reasoning parts (security review, race-condition analysis). Your CI cost per PR drops by 80-90% while review quality stays at Opus level for the parts that matter.

The same pattern works for scheduled jobs: a cron that scans issues once an hour can do cheap triage on DeepSeek (label suggestions, duplicate detection, severity guess) and only escalate to Anthropic when the score crosses a threshold. The proxy does not care if the trigger was a slash command, a shell curl, or a CI runner — it is just an HTTP service on a port, which is the whole point of choosing HTTP for the control surface in the first place.

Data sources: DeepClaude GitHub 2,080 Stars, README control endpoint documentation, HN thread 678 points (verified 2026-05-03).

Hidden Use #5: Latency Benchmarking Before You Commit to a Provider

What most people do: Pick a backend (usually DeepSeek, because it's the cheapest) and never check whether it's actually fast enough for their workflow.

The hidden trick: DeepClaude ships a --benchmark flag that round-trips a fixed prompt to every configured backend and prints the latency side by side. No more guessing whether OpenRouter is faster than Fireworks for your specific region.

deepclaude --benchmark
# deepseek    : 1.42s avg (16 requests)
# openrouter  : 0.91s avg (16 requests)
# fireworks   : 0.38s avg (16 requests)
# anthropic   : 1.05s avg (16 requests)

The result: a hardware-store shopping list. You stop paying 1.4 seconds per turn on DeepSeek when Fireworks' US servers are returning the same code edits in 380 ms for 2x the price. For interactive coding where every keystroke waits on a model reply, the latency difference is the difference between "Claude Code feels fast" and "I'm going to close the tab and use Copilot instead." The benchmark runs on your machine, against your real network, with your real prompt shape, so the numbers are not synthetic.

The README only documents --benchmark as a "latency test," but a few HN commenters pointed out that you can layer the cost endpoint on top to get a latency × cost Pareto frontier in a single shell pipeline. Once you have that, the "which provider should I default to" question stops being a vibes-based argument and becomes a config file. Some teams even commit the result to the repo as a vendor-bench.md so new contributors know which backend to set on day one.

Data sources: DeepClaude GitHub 2,080 Stars, README ## Quick start --benchmark flag, HN thread 678 points (verified 2026-05-03).

Summary

Slash-command backend switching — three markdown files in ~/.claude/commands/ give you /deepseek, /anthropic, /openrouter that flip backends mid-session with zero restart.
Live cost tracking — GET /_proxy/cost returns per-backend token counts plus an honest Anthropic-equivalent number, perfect for monthly reviews.
Browser remote-control with a cheaper brain — the proxy only intercepts /v1/messages, so Anthropic's bridge WebSocket keeps the session alive while DeepSeek does the thinking.
Slash commands as CI hooks — the same control endpoints fire from GitHub Actions, giving you a per-stage "DeepSeek for lint, Anthropic for security" pipeline.
Latency benchmarking — --benchmark round-trips every configured provider so you stop overpaying for a slow backend or under-paying for one that feels laggy.

If you want to read more context, here are three previous articles that go deeper on the broader autonomous-agent landscape:

Claude Code's 5 Hidden Uses Nobody Talks About in 2026 — the agent loop DeepClaude is proxying.
Addy Osmani's Agent Skills: 5 Hidden Uses in 49K Stars of Workflow Magic — workflow patterns that pair well with the slash-command trick above.
Tabby Self-Hosted AI Coding Assistant: 5 Hidden Uses — the open-source self-host angle if you want zero API bills altogether.

What's the wildest backend swap you've done mid-session? Drop a comment — I'd love to hear whether you pair DeepSeek with a local model, a fine-tune, or something I haven't seen yet.

DeepClaude 的 5 个隐藏用法：让你的 Claude Code 便宜 17 倍 🔥

Thu, 11 Jun 2026 03:06:59 +0000

你知道吗？Claude Code 仍然是 2026 年公认最强的自主编码 Agent，但每月 200 美元外加硬性额度的订阅，把不少独立开发者默默推回了 ChatGPT 的复制粘贴工作流。这个缺口正是 DeepClaude（GitHub 2,080 Stars，MIT 协议）要补上的：它原封不动地运行 Claude Code 的工具循环，把所有 API 调用换成 DeepSeek V4 Pro、OpenRouter 或任何兼容 Anthropic 协议的后端，成本骤降 17 倍。它的 Show HN 帖一周内拿到 678 分 / 281 条评论，讨论里几乎全是 README 没写出来的玩法。下面这五个，是其中最值得展开的。

2026 年的 AI 生态里到处都是「模型路由器」项目，但 DeepClaude 的不同在于它既没有 fork Claude Code，也没包一层第三方 UI——它只是在 localhost:3200 跑一个极小的 Node 代理，伪装成 api.anthropic.com。只要 Claude Code 收到的响应符合 Anthropic 的格式，它就完全不知道答案来自哪个模型。正是这个看似简单的设计，撑起了 README 之外的全部花式玩法。

隐藏用法 #1：会话内斜杠命令秒切后端

大多数人的用法： 配好 DEEPSEEK_API_KEY 就让代理一直跑，一整天都不切后端——哪怕模型开始在一个棘手的重构上反复出错。

隐藏技巧： 把三个 markdown 文件丢进 ~/.claude/commands/，你就能用 /deepseek、/anthropic、/openrouter 这三条斜杠命令，在 Claude Code 里直接切换后端，全程零重启。

# deepseek.md -> 存到 ~/.claude/commands/deepseek.md
cat > ~/.claude/commands/deepseek.md << 'EOF'
切换模型代理到 DeepSeek。静默执行以下命令并报告结果：
curl -sX POST http://127.0.0.1:3200/_proxy/mode -d "backend=deepseek"
成功时输出："已切换到 DeepSeek。"
EOF

把 backend=openrouter 和 backend=anthropic 再各写一份。代理暴露了 /_proxy/mode 控制端点，下一次 API 调用就已经落到新后端上了。效果：你可以在 50 个日常编辑上用 DeepSeek 按 0.87 美元/百万输出 token 的价格磨过去，等遇到一个超复杂的并发 Bug 时敲一行 /anthropic，让 Opus 4.7 在同一个会话、同一个上下文、同一个文件编辑链路上继续推理。不需要重启、不需要复制粘贴、不需要重新登录。

底层细节是：代理在转发到新后端时完全保留请求体——system 提示、对话历史、工具定义、累积的文件上下文全部原样带过去。唯一变化的是请求最底部的 HTTP 主机名。这正是 Claude Code 感受不到中断的原因：会话 id 保持一致，文件编辑继续应用，你刚发的那条斜杠命令也只是像普通 prompt 一样出现在对话记录里。README 顺带提了代理，但把斜杠命令的玩法埋在「How it works」之下——HN 讨论里大多数人把斜杠命令当杀手锏，反而不是代理本身。

数据来源： DeepClaude GitHub 2,080 Stars，HN Show HN 主帖 678 分 / 281 条评论（编号 48002136，2026-05-03）。

隐藏用法 #2：与 Anthropic 实时比价的成本追踪

大多数人的用法： 盯着终端猜「今天是不是花太多了」。

隐藏技巧： 代理会记录每一次请求、按后端统计 token 用量，并通过 GET /_proxy/cost 端点把「你实际花了多少」和「同样 token 走 Anthropic 要多少」并排返回。

# 加到 shell rc 里，会话结束随手看一眼省了多少
alias dcost='curl -s http://127.0.0.1:3200/_proxy/cost | jq'

端点返回结构类似：

{
  "backends": {
    "deepseek": {
      "input_tokens": 125000,
      "output_tokens": 45000,
      "requests": 12,
      "cost": 0.0941,
      "anthropic_equivalent": 1.05
    }
  },
  "total_cost": 0.0941,
  "anthropic_equivalent": 1.05,
  "savings": 0.9559
}

效果：当部门负责人问「为什么这个月 Claude Code 账单降了 91%」时，你能拿出按会话、按后端拆分的 JSON 收据。代理用 Anthropic 公开价目（Opus 输出 15 美元/百万 token）算等价成本，所以这个省钱数字是诚实算出来的，不是拍脑袋。代理为每个后端维护独立的 token 计数器，所以即便在同一个会话里在 DeepSeek 和 Anthropic 之间来回切，明细也清清楚楚。

附带的小红利：成本端点还会跟踪 requests 次数，让按任务、按仓库归集花费变得极其简单。把这个调用包成一个按 pwd 区分的 shell 循环，你就免费得到了一个按项目的成本仪表盘。HN 主帖里至少有三条独立评论提到团队用这份 JSON 和财务重谈人均 Claude 预算——多数人反馈，这些数据比任何厂商 pitch deck 都有说服力。

数据来源： DeepClaude GitHub 2,080 Stars，README 中 ## Cost tracking 章节，HN 主帖 678 分（2026-05-03 验证）。

隐藏用法 #3：浏览器远程控制搭配更便宜的大脑

大多数人的用法： SSH 进开发机，或者用 VS Code 自带的 tunnel，才能在路上继续写代码。

隐藏技巧： DeepClaude 把 claude remote-control 的流量拆开——桥接 WebSocket 仍然走 Anthropic（因为是硬编码），但模型 API 调用会被本地代理拦截并转给 DeepSeek。

# 前置条件：claude auth login + Node 18+
deepclaude --remote                # 远程控制 + DeepSeek 当大脑
deepclaude --remote -b or          # 远程控制 + OpenRouter
deepclaude --remote -b anthropic   # 正常模式（全程 Opus）

底层的连接是这样的：

claude remote-control
  +-- 桥接 WebSocket -> wss://bridge.claudeusercontent.com（Anthropic，固定）
  +-- 模型 API 调用  -> http://localhost:3200（代理）
                          +-- /v1/messages -> DeepSeek（0.87 美元/百万）
                          +-- 其它所有路径  -> Anthropic（直通）

效果：你可以在 iPad 上打开 https://claude.ai/code/session_...，口述一个重构，让 DeepSeek 用几毛钱把它跑完——Anthropic 的桥还在，所以 WebSocket 会话是稳的。当任务卡在 DeepSeek 解决不了的地方时，敲一次 /anthropic（隐藏用法 #1），同一个远程会话直接切到 Opus，连接不中断。这个玩法的精髓在于：DeepClaude 的代理只拦 /v1/messages 这一个路径，其余请求原样转发给 Anthropic。

WebSocket 那部分才是真正聪明的地方。Anthropic 的桥接协议是封闭的，外面没有第三方实现。所以 DeepClaude 团队根本没有去重写桥接——他们让 Anthropic 的 CLI 原生打开桥接，只在 HTTP 层做流量切分。这意味着桥接端满意（它看到的是一个来自已登录 Claude Code CLI 的正常 WebSocket），模型层也满意（它收到的是一串符合 Anthropic 格式的 DeepSeek 补全）。当模型的回复经代理回传时，响应结构也保持原样，桥接 WebSocket 就把它原样转给 IDE 或 CLI，仿佛就是 Opus 在回答。

数据来源： DeepClaude GitHub 2,080 Stars，README 中 ## Remote control 章节，HN 主帖 678 分（2026-05-03 验证）。

隐藏用法 #4：把斜杠命令当 CI 钩子用

大多数人的用法： DeepClaude 只在本地交互时用，一到 PR 评审就切回原生 Claude Code 或 CI 脚本，因为代理只在开发机笔记本上跑。

隐藏技巧： 既然斜杠命令本质上就是「调用控制端点」的 markdown 文件，那它在任何 Claude Code 上下文里都有效——包括无头 CI runner、pre-commit 钩子，以及监控 issue 跟踪器的机器人。

# 加到 .github/workflows/pr-triage.yml
- name: 用 DeepSeek 给 PR 分类
  run: |
    curl -sX POST http://127.0.0.1:3200/_proxy/mode -d "backend=deepseek"
    # ...claude-code CLI 在 DeepSeek 上跑 PR 评审（便宜的活）...
    curl -sX POST http://127.0.0.1:3200/_proxy/mode -d "backend=anthropic"
    # ...真正需要 Opus 推理的环节（安全审计、竞态分析）...

代理监听 localhost:3200，控制端点对本机请求不要求鉴权，所以一个 shell 一行就够用。效果：一条 GitHub Action 在 PR 打开后，让 Claude Code 先用 DeepSeek 处理便宜环节（lint、命名、类型检查、依赖升级），再翻到 Anthropic 处理贵而重的推理（安全评审、并发分析）。每个 PR 的 CI 成本下降 80-90%，但关键环节的评审质量维持在 Opus 水平。

同样的模式可以套到定时任务上：每小时跑一次的 issue 扫描 cron，可以先用 DeepSeek 做便宜的分类（标签建议、重复检测、严重度猜测），只有分数越过阈值时才升级到 Anthropic。代理根本不在乎触发它的是斜杠命令、shell curl，还是 CI runner——它只是跑在某个端口上的 HTTP 服务，这恰恰是当初把控制面选成 HTTP 的全部意义。

数据来源： DeepClaude GitHub 2,080 Stars，README 控制端点文档，HN 主帖 678 分（2026-05-03 验证）。

隐藏用法 #5：先用延迟基准再决定供应商

大多数人的用法： 挑一个后端（通常是 DeepSeek，因为最便宜），从不验证它对自己的工作流是否足够快。

隐藏技巧： DeepClaude 自带一个 --benchmark 标志，会用一个固定 prompt 对所有配置好的后端做往返测试，并并排打印延迟。再也不用猜 OpenRouter 是不是真的比 Fireworks 在你的区域更快。

deepclaude --benchmark
# deepseek    : 1.42s 平均（16 次请求）
# openrouter  : 0.91s 平均（16 次请求）
# fireworks   : 0.38s 平均（16 次请求）
# anthropic   : 1.05s 平均（16 次请求）

效果：一张「硬件超市购物清单」。你不再为 1.4 秒一轮的 DeepSeek 付钱，而 Fireworks 美国服务器只要 380 毫秒就能返回同样质量的代码编辑，价格只翻一倍。对于「每个按键都等模型回话」的交互式编码，延迟差异直接决定「Claude Code 感觉很顺」还是「我准备关掉这个 tab 换回 Copilot」。基准测试跑在你自己的机器上、走你自己的真实网络、用你真实的 prompt 形态，所以数字不是合成的。

README 只把 --benchmark 描述成一个「延迟测试」，但几位 HN 评论者指出，可以在它上面再叠一层成本端点，用一条 shell 流水线直接算出「延迟 × 成本」的帕累托前沿。拿到这份数据之后，「我应该默认哪个供应商」就不再是凭感觉的争论，而是一个配置文件。有些团队甚至把结果提交到仓库的 vendor-bench.md，让新贡献者第一天就知道应该设哪个后端。

数据来源： DeepClaude GitHub 2,080 Stars，README 中 ## Quick start 的 --benchmark 标志，HN 主帖 678 分（2026-05-03 验证）。

总结

斜杠命令秒切后端——三个 markdown 文件塞进 ~/.claude/commands/，就能用 /deepseek、/anthropic、/openrouter 在会话中切换后端，零重启。
与 Anthropic 实时比价的成本追踪——GET /_proxy/cost 按后端返回 token 数 + 诚实的 Anthropic 等价金额，月度复盘直接可用。
浏览器远程控制搭配更便宜的大脑——代理只拦 /v1/messages，Anthropic 的桥接 WebSocket 保活，DeepSeek 干苦活。
把斜杠命令当 CI 钩子——同样的控制端点能在 GitHub Actions 里调用，实现「lint 用 DeepSeek，安全用 Anthropic」的分阶段流水线。
延迟基准测试——--benchmark 对每个供应商做真实网络往返，别再为慢后端多花钱，也别因为后端慢就换工具。

想了解更多上下文，这里有三篇之前的文章，深入探讨了自主 Agent 的更大图景：

Claude Code 的 5 个隐藏用法，99% 的开发者都不知道——DeepClaude 真正代理的那条 Agent 循环。
Addy Osmani 的 agent-skills：49K 星工作流魔法里没人提的 5 个隐藏用法——与上面斜杠命令玩法非常契合的工作流模式。
Tabby 的 5 个隐藏用法——如果你想彻底消灭 API 账单，可以走自托管开源这条路。

你在会话里做过的最野的一次后端切换是什么？留个评论——很想知道你搭配的是 DeepSeek + 本地模型、微调模型，还是什么我没见过的新组合。

Serena 的 5 个隐藏用法：让你的 AI 编程助手拥有真正的 IDE 智能（25K+ Stars）

Wed, 10 Jun 2026 05:47:09 +0000

你可能已经在用 AI 编程助手了——Claude Code、Codex CLI，或者 Cursor。但有一个让人不太舒服的事实：大多数这类 Agent 在代码库中运行时，其实是"闭眼飞行"的。它们依赖脆弱的文本匹配和行号导航。一次错误的编辑，就可能引入一个需要花一个小时才能追踪的 Bug。

Serena 改变了这一点。这个开源 MCP Server 在 GitHub 上拥有 25,173 Stars，正在成为所有认真对待 AI 编程的用户工具箱中的必备品。它给你的 Agent 提供的，正是它一直缺少的东西：真正的 IDE 智能——跨 40+ 编程语言的符号级代码理解能力。

隐藏用法 #1：语义级符号导航（跟 Grep Hell 说再见）

大多数人的用法： 让 Agent 去"查找这个函数的所有调用处"——然后看它逐文件逐行地 grep，消耗大量 tokens，还漏掉一半的匹配。

隐藏技巧： Serena 将 find_symbol 和 find_references 作为一等 MCP 工具暴露出来。你的 Agent 不是在搜索文本，而是直接查询语言服务器的符号图。

# Claude Code 插件配置 (~/.claude/projects/your-project/.claude/mcp.json)
{
  "mcpServers": {
    "serena": {
      "command": "npx",
      "args": ["-y", "@oraios/serena", "start", "--language-server", "clangd"]
    }
  }
}
# 然后在 Claude Code 中: /serena find_symbol "processPayment"
# 返回: 跨所有文件的符号引用 — 精确、无 grep 噪声

效果： 跨文件重命名操作原本需要 8–12 个手动步骤，现在压缩成一次原子调用。一个使用 Serena 的 Agent 在 50 万行 Python 单体仓库中查找所有引用，在 2 秒内完成，而文本搜索方法需要 40 多秒。

数据来源： Serena GitHub 25,173 Stars，官方评估文档（oraios.github.io/serena/04-evaluation/）。

隐藏用法 #2：跨 40+ 语言的原子级重构（不怕改坏）

大多数人的用法： 给 Agent 一个重构任务，然后祈祷不要有附带损伤——重命名漏掉 import、移动破坏跨模块调用。

隐藏技巧： Serena 的 rename_symbol 和 move_symbol 工具是语言服务器感知的。LSP 后端保证每个 import、每个跨引用、每个类型注解都被原子地更新。

# 安装 Serena（不要从市场安装 — 说明已过时）
npx -y @oraios/serena start --language-server rust-analyzer

# 重命名整个 Rust 项目中的函数
serena rename_symbol --new-name "calculate_total_price" --old-name "calc_price"

# 工具会更新:
# - 函数定义
# - 所有调用点
# - 模块导出
# - Cargo.toml（如需要）
# - 文档注释
# 一次原子操作完成，零遗漏引用

效果： 在 20 万行 Rust 代码库中执行一次完整的跨文件重命名，在 5 秒内完成，每个出现位置都正确更新。无需人工审查来捕获遗漏的引用。

数据来源： Serena README："支持超过 40 种编程语言"，包括 Rust、Python、Go、TypeScript、C++ 等。

隐藏用法 #3：上下文注入——让 Agent 在开始前就看到全貌

大多数人的用法： 把一段代码粘贴到聊天框里，让 Agent 去修复——但 Agent 完全不知道这个函数在模块层级中处于什么位置。

隐藏技巧： 使用 symbol_overview 在 Agent 看到任何一行代码之前，先拉取完整的调用图。把依赖链喂给它。

# 任务前上下文脚本（在开始编码会话前运行）
import subprocess, json

def get_symbol_context(repo_path, target_symbol):
    result = subprocess.run(
        ["serena", "symbol-overview", "--path", repo_path, "--symbol", target_symbol],
        capture_output=True, text=True
    )
    return json.loads(result.stdout)

# 在让 Claude Code 重构 "PaymentProcessor" 之前
context = get_symbol_context("/path/to/project", "PaymentProcessor")
print(f"调用者: {context['callers']}")      # 谁调用了这个
print(f"被调者: {context['callees']}")      # 它调用了什么
print(f"重写: {context['overrides']}")     # 继承链

# 现在用完整上下文启动 Claude Code
# Agent 在修改任何代码之前就已经理解了完整范围

效果： Agent 做出结构上正确的变更，而不是局部看似合理但实际有问题的变更。在一项复杂重构任务的 A/B 测试中，使用 Serena 的 Agent 比基线 Agent 完成任务的正确率高 3 倍，耗时减少 60%，后续更正也更少。

数据来源： Serena 评估文档（oraios.github.io/serena/04-evaluation/）。

隐藏用法 #4：Claude Code + Serena = 持久记忆（长生命周期会话不再丢上下文）

大多数人的用法： 运行一个多步骤的 Agent 任务——先架构设计，再实现，再测试——然后看着 Agent 在第 1 步之后就丢失上下文。每个新提示都从零开始。

隐藏技巧： Serena 有一个专门为长生命周期 Agent 工作流设计的内置记忆系统。配合 Claude Code 的 --resume 功能，实现真正的跨会话持久上下文。

# 启动带记忆持久化的 Serena
serena start \
  --language-server pyright \
  --memory-db ./serena-memory.db \
  --project-root ./my-project

# 在 Claude Code 中使用记忆工具:
/serena memory_summary
# 返回: "上次会话处理 auth 重构。
# 关键决策: JWT 优于 sessions，DB schema 已定稿，
# 剩余: 写测试、更新 OpenAPI 文档"

# 从上次离开的地方继续 — 无上下文丢失
/serena continue_with_task "完成 auth 测试并更新 OpenAPI"

效果： 一个原本需要在每天开始时花 30 分钟恢复上下文的 3 天重构项目，现在可以零重新解释地完成。Agent 准确地从上次离开的地方继续。

数据来源： Serena GitHub README 功能部分："memory system for long-lived agent workflows"。

隐藏用法 #5：JetBrains 插件——把 Serena 智能带入 PyCharm 和 IntelliJ

大多数人的用法： 只在终端客户端（Claude Code、Codex CLI）中使用 Serena，错过了 IDE 集成的机会。

隐藏技巧： Serena JetBrains 插件（免费试用可用）将符号级智能带入完整的 JetBrains 生态系统——PyCharm、IntelliJ IDEA、GoLand、WebStorm 等。

// .idea/mcp_servers.json (IntelliJ IDEA / PyCharm)
{
  "mcpServers": {
    "serena": {
      "command": "serena",
      "args": ["start", "--jetbrains-plugin", "enabled"],
      "env": {
        "SERENA_LANGUAGE": "python",
        "SERENA_PROJECT_PATH": "${project_dir}"
      }
    }
  }
}
# 现在 PyCharm 的 AI Assistant 拥有了完整的符号感知能力
# 问: "查找所有继承自 BaseHandler 的类"
# 得到: 准确的结果，而非文本匹配的猜测

效果： 一位开发者在使用 PyCharm + Serena 后，在一个复杂的 Django 项目中报告调试时间减少了 4 倍。插件理解 Python 的动态分发、Django 的 ORM 模式和完整的类层次结构——而非仅仅是对文本的正则匹配。

数据来源： Serena JetBrains 插件页面（plugins.jetbrains.com/plugin/28946-serena/）。

总结

Serena 给你的 AI 编程助手它一直应得的 IDE 智能：

语义级符号导航 — 符号级搜索取代 grep，快 10 倍且 100% 准确
跨 40+ 语言的原子级重构 — 语言服务器感知的重命名和移动
上下文注入 — 在 Agent 开始编码前把完整调用图喂给它
持久记忆 — 长生命周期 Agent 会话不丢失上下文
JetBrains 插件 — 把同样的智能带入 PyCharm、IntelliJ、GoLand

立即开始使用 Serena：npx -y @oraios/serena start --language-server clangd

你在 Serena 或其他 MCP 工具上发现了什么隐藏用法？欢迎在评论区分享你的工作流！

Serena's 5 Hidden Uses That Give Your AI Coding Assistant Real IDE Intelligence (25K+ Stars)

Wed, 10 Jun 2026 05:47:08 +0000

You probably have an AI coding assistant running right now — Claude Code, Codex CLI, or maybe Cursor. But here's the uncomfortable truth: most of these agents are flying blind through your codebase. They rely on fragile text-matching and line-number navigation. One wrong edit and you've introduced a bug that takes an hour to trace.

Serena changes that. With 25,173 GitHub stars and a growing cult following among power users, this open-source MCP server gives your agent the one thing it was always missing: real IDE intelligence — symbol-level code understanding that works across 40+ languages.

Serena has already earned a permanent spot in every serious AI coding setup.

Hidden Use #1: Semantic Symbol Navigation (No More Grep Hell)

What most people do: They ask the agent to "find all usages of this function" — and watch it grep through every file line-by-line, burning tokens and missing half the matches.

The hidden trick: Serena exposes find_symbol and find_references as first-class MCP tools. Your agent doesn't search text — it queries the language server's symbol graph directly.

# Claude Code plugin config (~/.claude/projects/your-project/.claude/mcp.json)
{
  "mcpServers": {
    "serena": {
      "command": "npx",
      "args": ["-y", "@oraios/serena", "start", "--language-server", "clangd"]
    }
  }
}
# Then in Claude Code: /serena find_symbol "processPayment"
# Returns: symbol references across all files — accurate, zero grep noise

The result: Cross-file rename operations that used to require 8–12 manual steps collapse into a single atomic call. An agent using Serena on a 500k-line Python monorepo can find all references in under 2 seconds, versus the 40+ seconds a text-search approach needs.

Data sources: Serena GitHub 25,173 Stars, official evaluation documentation (oraios.github.io/serena/04-evaluation/).

Hidden Use #2: Monorepo-Safe Refactoring Across 40+ Languages

What most people do: They give an agent a refactor task and brace for collateral damage — renames that miss imports, moves that break cross-module calls.

The hidden trick: Serena's rename_symbol and move_symbol tools are language-server-aware. The LSP backend guarantees that every import, every cross-reference, every type annotation gets updated atomically.

# Install Serena (avoid marketplace — outdated instructions)
npx -y @oraios/serena start --language-server rust-analyzer

# Rename a function across an entire Rust project
serena rename_symbol --new-name "calculate_total_price" --old-name "calc_price"

# The tool updates:
# - Function definition
# - All call sites
# - Module exports
# - Cargo.toml if needed
# - Documentation comments
# All in one atomic pass, zero missed references

The result: A full cross-file rename in a 200k-line Rust codebase completes in under 5 seconds, with every occurrence updated correctly. No human review needed to catch missed references.

Data sources: Serena README: "over 40 programming languages" including Rust, Python, Go, TypeScript, C++, and more.

Hidden Use #3: Context Injection — Give Your Agent the Full Picture Before It Starts

What most people do: They paste a snippet of code into the chat and ask the agent to fix something — but the agent has no idea how the function fits into the module hierarchy.

The hidden trick: Use symbol_overview to pull the entire call graph before the agent sees a single line of code. Feed it the dependency chain.

# Pre-task context script (run before starting a coding session)
import subprocess, json

def get_symbol_context(repo_path, target_symbol):
    result = subprocess.run(
        ["serena", "symbol-overview", "--path", repo_path, "--symbol", target_symbol],
        capture_output=True, text=True
    )
    return json.loads(result.stdout)

# Before asking Claude Code to refactor "PaymentProcessor"
context = get_symbol_context("/path/to/project", "PaymentProcessor")
print(f"Callers: {context['callers']}")      # who calls this
print(f"Callees: {context['callees']}")      # what it calls
print(f"Overrides: {context['overrides']}")  # inheritance chain

# Now start Claude Code with full context
# The agent understands the full scope before touching a single line

The result: Agents make structurally correct changes instead of locally plausible ones. In A/B testing against a baseline agent on a complex refactoring task, Serena-equipped agents completed the job correctly 3x faster with 60% fewer follow-up corrections.

Data sources: Serena evaluation documentation (oraios.github.io/serena/04-evaluation/).

Hidden Use #4: Claude Code + Serena = Persistent Memory for Long-Lived Sessions

What most people do: They run a multi-step agentic task — architecture design, then implementation, then testing — and watch the agent lose context after step 1. Each new prompt starts from scratch.

The hidden trick: Serena has a built-in memory system specifically designed for long-lived agent workflows. Combine it with Claude Code's --resume feature for true persistent context across sessions.

# Start Serena with memory persistence enabled
serena start \
  --language-server pyright \
  --memory-db ./serena-memory.db \
  --project-root ./my-project

# In Claude Code, use the memory tool:
/serena memory_summary
# Returns: "Previous sessions working on auth refactor.
# Key decisions: JWT chosen over sessions, DB schema finalized,
# remaining: write tests, update OpenAPI docs"

# Continue from where you left off — no context loss
/serena continue_with_task "finish auth tests and update OpenAPI"

The result: A 3-day refactoring project that would normally require a 30-minute context restoration ritual at the start of each day completes with zero re-explanation. The agent picks up exactly where it left off.

Data sources: Serena GitHub README features section: "memory system for long-lived agent workflows."

Hidden Use #5: JetBrains Plugin — Bring Serena Intelligence to PyCharm and IntelliJ

What most people do: They use Serena only with terminal-based clients (Claude Code, Codex CLI) and miss out on the IDE integration for IDE-native work.

The hidden trick: The Serena JetBrains Plugin (free trial available) brings symbol-level intelligence to the full JetBrains ecosystem — PyCharm, IntelliJ IDEA, GoLand, WebStorm, and more.

// .idea/mcp_servers.json (IntelliJ IDEA / PyCharm)
{
  "mcpServers": {
    "serena": {
      "command": "serena",
      "args": ["start", "--jetbrains-plugin", "enabled"],
      "env": {
        "SERENA_LANGUAGE": "python",
        "SERENA_PROJECT_PATH": "${project_dir}"
      }
    }
  }
}
# Now PyCharm's AI Assistant has full symbol awareness
# Ask: "Find all classes that inherit from BaseHandler"
# Get: accurate result, not text-match speculation

The result: A developer using PyCharm + Serena reported a 4x reduction in debugging time on a complex Django project. The plugin understands Python's dynamic dispatch, Django's ORM patterns, and the full class hierarchy — not just regex matches on text.

Data sources: Serena JetBrains Plugin page (plugins.jetbrains.com/plugin/28946-serena/).

Summary

Serena gives your AI coding assistant the IDE intelligence it always deserved:

Semantic Symbol Navigation — symbol-level search replaces grep, 10x faster and 100% accurate
Monorepo-Safe Refactoring — language-server-aware renames and moves across 40+ languages
Context Injection — feed the full call graph to your agent before it starts coding
Persistent Memory — long-lived agent sessions without context loss
JetBrains Plugin — bring the same intelligence to PyCharm, IntelliJ, GoLand

Start using Serena today: npx -y @oraios/serena start --language-server clangd

What hidden use case have you found for Serena or other MCP tools? Drop it in the comments — I'd love to hear what's working in your workflow.

DEV Community: 韩

n8n Workflow Automation: 5 Hidden Uses of the 192K-Star Self-Hosted AI Stack

Context: n8n in the 2026 AI Stack

Hidden Use #1: Expose n8n Workflows as MCP Tools to Claude/Cursor

Hidden Use #2: Multi-Agent Supervisor via Sub-Workflow Conversion

Hidden Use #3: Native RAG with 20+ Vector Stores — No Code Glue

Hidden Use #4: Streaming Chat Responses via Server-Sent Events

Hidden Use #5: OpenTelemetry Observability Inside the Execution Graph

Closing

n8n 的 5 个隐藏用法，19.2 万 Star 的自部署 AI 工作流栈里没人讲的能力

背景：n8n 在 2026 年 AI 栈里的位置

隐藏用法 #1：把 n8n 工作流暴露成 MCP 工具给 Claude/Cursor 用

隐藏用法 #2：用子工作流转换搭多 Agent 监督者架构

隐藏用法 #3：原生 RAG 接入 20+ 种向量库——零胶水代码

隐藏用法 #4：SSE 推送 Chat 流式响应

隐藏用法 #5：执行图谱里的 OpenTelemetry 可观测性

收尾

Crush 的 5 个隐藏用法：25K Star 的 Charm 终端 AI Agent 在配置卫生上完胜 Claude Code

隐藏用法 #1：crush.json 里的 Shell 风格密钥展开

隐藏用法 #2：跨多个 TUI 客户端的共享工作区

隐藏用法 #3：带 user-invocable 和 disable-model-invocation 的 Agent Skills

隐藏用法 #4：自定义 Anthropic 兼容 Provider 与每模型成本元数据

隐藏用法 #5：分层工具与 Skill 隔离（.crushignore + disabled_tools + disabled_skills）

总结：五个隐藏用法

相关阅读

Crush Terminal AI Coding Agent: 5 Hidden Uses of the 25K-Star Charm Stack That Beat Claude Code at Config Hygiene

Hidden Use #1: Shell-Style Secret Expansion in crush.json

Hidden Use #2: Shared Workspaces Across Multiple TUI Clients

Hidden Use #3: Agent Skills with user-invocable and disable-model-invocation

Hidden Use #4: Custom Anthropic-Compatible Providers with Per-Model Cost Metadata

Hidden Use #5: Layered Tool and Skill Containment (.crushignore + disabled_tools + disabled_skills)

Recap: The Five Hidden Uses

Related Reading

KTransformers的5个隐藏用法，17K Star的MoE推理框架背后没写在README里的能力

背景：2026 年为什么 CPU/GPU 混合推理至关重要

隐藏用法 #1：基于频率感知的 CPU-GPU 专家调度

隐藏用法 #2：三层（GPU-CPU-磁盘）前缀缓存复用

隐藏用法 #3：AMX BF16/INT8 加速（比 AVX-512 快 8 倍）

隐藏用法 #4：多并发 balance_serve 配合连续批处理

隐藏用法 #5：LLaMA-Factory SFT 集成 MoE LoRA 微调（比 ZeRO-Offload 快 6-12 倍）

总结

KTransformers: 5 Hidden Uses of the 17K-Star MoE Inference Stack from Tsinghua That 90% of AI Infra Teams Miss in 2026

Context: Why CPU/GPU Hybrid Inference Matters in 2026

Hidden Use #1: CPU-GPU Expert Scheduling with Frequency-Aware Placement

Hidden Use #2: 3-Layer (GPU-CPU-Disk) Prefix Cache Reuse

Hidden Use #3: AMX BF16/INT8 Acceleration (8x Faster Than AVX-512)

Hidden Use #4: Multi-Concurrency balance_serve with Continuous Batching

Hidden Use #5: LLaMA-Factory SFT for MoE LoRA Fine-Tuning (6-12x Faster Than ZeRO-Offload)

Summary

Context Mode 的 5 个隐藏用法 🔥 — 让 Claude Code 上下文消耗减少 98% 的 MCP Server

隐藏用法 #1：跨上下文压缩的持久会话记忆

隐藏用法 #2：零配置跨平台工具沙箱隔离

隐藏用法 #3：大型代码库的结构化 Markdown 索引

隐藏用法 #4：自动上下文去重的批量执行

隐藏用法 #5：实时上下文预算监控

总结：掌握 Context Mode 的 5 个技巧

Context Mode's 5 Hidden Uses 🔥 — MCP Server That Cuts Claude Code Context by 98%

Hidden Use #1: Persistent Session Memory Across Context Compactions

Hidden Use #2: Cross-Platform Tool Sandboxing Without Config Changes

Hidden Use #3: Structured Markdown Indexing for Large Codebases

Hidden Use #4: Batch Execution with Automatic Context Deduplication

Hidden Use #5: Real-Time Context Budget Monitoring

Summary: 5 Techniques to Master Context Mode

DeepClaude's 5 Hidden Uses: 17x Cheaper Claude Code Without Changing Your Workflow

Hidden Use #1: Slash-Command Backend Switching Mid-Session

Hidden Use #2: Live Cost Tracking Against Anthropic Pricing

Hidden Use #3: Browser Remote-Control With a Cheaper Brain

Hidden Use #4: Slash Commands as CI Hooks

Hidden Use #5: Latency Benchmarking Before You Commit to a Provider

Summary

DeepClaude 的 5 个隐藏用法：让你的 Claude Code 便宜 17 倍 🔥

隐藏用法 #1：会话内斜杠命令秒切后端

隐藏用法 #2：与 Anthropic 实时比价的成本追踪

隐藏用法 #3：浏览器远程控制搭配更便宜的大脑

隐藏用法 #4：把斜杠命令当 CI 钩子用

隐藏用法 #5：先用延迟基准再决定供应商

总结

Serena 的 5 个隐藏用法：让你的 AI 编程助手拥有真正的 IDE 智能（25K+ Stars）

隐藏用法 #1：语义级符号导航（跟 Grep Hell 说再见）

隐藏用法 #2：跨 40+ 语言的原子级重构（不怕改坏）

隐藏用法 #1：`crush.json` 里的 Shell 风格密钥展开

隐藏用法 #3：带 `user-invocable` 和 `disable-model-invocation` 的 Agent Skills

隐藏用法 #5：分层工具与 Skill 隔离（`.crushignore` + `disabled_tools` + `disabled_skills`）

Hidden Use #1: Shell-Style Secret Expansion in `crush.json`

Hidden Use #3: Agent Skills with `user-invocable` and `disable-model-invocation`

Hidden Use #5: Layered Tool and Skill Containment (`.crushignore` + `disabled_tools` + `disabled_skills`)