Weave & OpenRouter MCP 2026: Markdown Drafting Routing

Two launches in the same week - OpenRouter's MCP server on June 25 and Weave's smart model router as a Show HN on the same day - put multi-model routing on the desk of every creator who writes Markdown for social platforms. Routing means sending different prompts to different LLMs: Claude for tone, DeepSeek for code, Kimi for Chinese phrasing, GPT-5 for fact-checking, all from a single CLI or editor session. This article explains what each tool actually does, why 2026 is the year routing becomes a creator concern rather than a developer concern, and where the deterministic, non-routed step in the pipeline - converting the final Markdown draft to rich text - fits when the rest of the stack is configurable.

What Multi-Model Routing Means in 2026

Multi-model routing is the practice of choosing a different LLM per task inside one workflow. The previous best practice was "pick one strong model and use it for everything." That still works for occasional writing, but it leaves money on the table for high-volume creators: Claude Sonnet 4.7 writes the best LinkedIn openers, but it is overkill for a routine code-snippet expansion; DeepSeek V4 writes the cleanest API snippets, but its prose is not as strong as Claude's on a long-form essay; Kimi K2 is the strongest Simplified Chinese model, but it is irrelevant for an English-only post.

The 2026 generation of routing tools does not just pick a model per session - it picks a model per paragraph, per code block, per fact-check pass, sometimes per sentence. The routing layer sits between the editor (Claude Code, Codex, Cursor, Pi) and the upstream LLM APIs, inspects each outgoing prompt, and rewrites the destination based on a policy file or a tool call from the agent. The creator does not see the routing; the editor does not see the routing; only the routing layer and the API logs know which model produced which sentences.

Weave Router: Local-First Model Proxy

Weave is a local HTTP proxy. You install it once, point Claude Code or Codex at it with one environment variable, and Weave intercepts every API call before it leaves your machine. A small YAML policy file declares which provider should answer which kind of prompt:

# weave.yaml
routes:
  - match: { type: prose, word_count_gt: 200 }
    upstream: anthropic/claude-sonnet-4.7
  - match: { type: code, language: python }
    upstream: deepseek/deepseek-chat
  - match: { type: fact_check }
    upstream: openai/gpt-5-mini
  - match: { type: bulk_draft, tone: casual }
    upstream: zhipu/glm-4.6
default: anthropic/claude-sonnet-4.7

The June 2026 release ships with that policy as the default - long prose to Claude, code to DeepSeek, fact-check to GPT-5 mini, and casual bulk drafting to GLM-4.6 - so a creator who installs Weave and never edits the YAML gets reasonable routing out of the box. Because Weave runs locally, no request log leaves the machine unless the creator opts into a cloud dashboard; the providers see traffic from the creator's IP, not from a shared proxy pool.

The proxy model has one obvious limitation: the routing decision is static. The YAML file says "long prose goes to Claude" once at startup, and every long prose prompt for the rest of the session goes to Claude, even if the model briefly returns 429s or the policy would benefit from a one-off exception. Weave's workaround is to expose the proxy on a localhost port that the editor polls for health; if the primary upstream fails, Weave fails over to a configured fallback (GPT-5 mini in the default policy) without the editor noticing.

OpenRouter MCP Server: Routing as an Agent Tool

The OpenRouter MCP server, released June 25, 2026, exposes the same routing capability through the Model Context Protocol. Where Weave is a proxy the editor does not know about, OpenRouter MCP is a tool the agent invokes from inside the conversation. The creator writes a prompt like "draft the next paragraph in Claude's voice and have GPT-5 fact-check the code sample," and the agent calls openrouter.route with the model selector as an argument.

The MCP path has a different set of tradeoffs. On the plus side, the routing decision is visible in the agent's transcript - the writer can scroll back through the conversation and see "this paragraph was generated by claude-sonnet-4.7, this code block was generated by deepseek-chat" - which makes auditing which model produced which sentence a normal part of the workflow. The per-paragraph granularity is also native to the MCP path: the agent can decide to switch models mid-conversation based on the evolving prompt, without a static policy file getting in the way.

On the minus side, the MCP path requires an MCP-aware editor. Claude Code, Codex, Cursor, Pi, Continue, Cline, and Roo Code all speak MCP as of mid-2026; older editors and plain CLI invocations of claude or codex do not. The OpenRouter MCP server is also one more tool to register in the agent's settings.json or .mcp/config.json, and a misconfigured server is silent - the agent falls back to its default model and the writer never learns that routing is off.

Why Creators Are Routing Their Markdown Drafts

The reason routing matters for creators, not just developers, is that the destination platform rewards different things. LinkedIn rewards an opener that names a tension the reader recognizes in the first sentence; X Articles (the long-form feature inside X) rewards a hook that fits in 280 characters but pulls the reader past the fold; Medium rewards prose density and a slower build; Substack newsletter rewards a personal voice and a clear call-to-action at the bottom; Bluesky long-form rewards brevity and direct claims without the LinkedIn-style rhetorical scaffolding.

One model cannot write the LinkedIn opener, the X Articles hook, the Medium body, and the Substack close at the same strength. Claude Sonnet 4.7 is best at the LinkedIn opener and the Medium body. GPT-5 mini is best at the X Articles hook because it is ruthlessly concise. Kimi K2 is irrelevant for the English-only destinations but unmatched for a bilingual post. The routing layer is what makes it practical to give each paragraph the model it actually needs, without manually switching editors or copy-pasting between Claude and GPT windows.

There is also a cost story. A 2,000-word post routed with the Weave default policy costs roughly 30 percent less than the same post drafted entirely with Claude Sonnet 4.7, because the bulk-drafting and fact-check legs go to cheaper models. A 10,000-word monthly output sees the savings add up to several hundred dollars, which pays back the time spent configuring Weave or the OpenRouter MCP tool within a quarter.

What Routing Actually Saves (Cost and Latency)

The honest numbers, drawn from the Weave Show HN thread and the OpenRouter MCP launch post, look like this for a 2,000-word post with three code samples:

Leg of pipeline             Model used         Cost     Latency
-------------------------------------------------------------------
LinkedIn opener (80 words)  Claude Sonnet 4.7   $0.04    1.2s
Body paragraph (700 words)  Claude Sonnet 4.7   $0.18    4.8s
Code sample #1 (40 lines)   DeepSeek V4         $0.01    1.4s
Code sample #2 (30 lines)   DeepSeek V4         $0.01    1.0s
Code sample #3 (25 lines)   DeepSeek V4         $0.01    0.9s
Fact-check pass             GPT-5 mini          $0.02    3.1s
Closing paragraph           GLM-4.6             $0.01    0.7s
-------------------------------------------------------------------
Total routed                                  ~$0.28    ~13s
Total single-model (Claude)                   ~$0.40    ~14s

The savings are modest in absolute dollars (twelve cents on a draft) but the latency story matters more. Parallel routing - the body paragraph drafting on Claude while the code samples draft on DeepSeek at the same time - cuts wall-clock time by 40-50 percent compared to a single-model serial draft, because the cheap models are not bottlenecked behind the expensive model's queue. For a creator publishing three posts a day, that latency drop is the difference between finishing the day's drafts in three hours and finishing them in five.

The savings do not appear if the routing is set up wrong. A policy that sends long prose to DeepSeek because DeepSeek is cheaper will save money on the API bill and produce a LinkedIn post that reads like it was written by DeepSeek. The cheap model is not the right model for every leg of the pipeline; routing only works when each leg goes to the model that is actually strongest at that leg.

The Limits of Routing: Conversion Is Not Routing

Routing is a powerful primitive, but it stops at the upstream LLM. Once the agent has produced a Markdown draft - regardless of which model wrote which sentence - the next step is converting that Markdown to the rich-text payload that LinkedIn, X Articles, Medium, Substack, Notion, or Bluesky expects when the creator presses paste.

That conversion is not a routing problem. There is no model to choose, no trade-off between quality and cost, no upstream API to call. The conversion is a deterministic function: Markdown -> HTML -> clipboard text/html -> paste. The same input Markdown always produces the same output HTML. The clipboard payload is always text/html. The destination platform always accepts the paste.

This is the part of the pipeline where adding an LLM makes things worse, not better. If the conversion step routes the Markdown through Claude or GPT-5 to "polish" the rich text, the polished output is no longer deterministic: the same Markdown can produce three slightly different rich-text payloads on three runs, and small formatting differences (a bold that should have been italic, a code block that should have been a list) start showing up in published posts. The reliability story Caliper introduced last week for the drafting step applies in reverse to the conversion step: the conversion should be the part of the pipeline that is already reliable.

How md2rich Fits in a Multi-Model Pipeline

md2rich is the deterministic, non-routed step. It runs entirely in the browser as a static HTML page - no backend, no model, no rate limit, no upload. The creator pastes the Markdown draft (which may have been routed through Claude, DeepSeek, GPT-5, and Kimi on the way out of the agent) into the editor, picks the destination platform from a dropdown if md2rich needs to know (LinkedIn, Medium, Notion, Substack each have small quirks in how they render lists and code blocks), and presses convert. md2rich produces the text/html clipboard payload and the creator pastes it into the destination editor.

The interesting property of this setup is that the routing layer (Weave or OpenRouter MCP) can change every week - the creator can swap Claude Sonnet 4.7 for Claude Sonnet 5 when Anthropic ships it, add a new model to the policy, or switch from Weave to the OpenRouter MCP server without touching the conversion step. The conversion step is invariant. The Markdown draft from any model goes through the same deterministic converter, produces the same rich text, and pastes cleanly into the destination platform. Routing varies the upstream; the conversion is invariant.

This is also where the privacy-first design of md2rich matters. Weave runs locally, so the routed prompts do not leave the creator's machine. md2rich runs locally, so the Markdown draft never leaves the browser. The whole pipeline - from the editor to the routing layer to the conversion step - can run without any third party seeing the content of the post. This is the only configuration in which a creator writing about a sensitive topic (a personal essay, an internal postmortem, a regulated industry disclosure) can use multi-model routing without worrying that the model provider is logging the draft.

Closing: Pick the Routing Layer, Lock the Conversion Layer

The 2026 lesson is that AI drafting is a moving target, and the only way to keep up is to make the routing layer configurable. Weave and the OpenRouter MCP server are the first two tools that put routing in reach of creators, not just developers, and the cost-quality trade-off they enable is real for any creator publishing more than 10,000 words a month.

The conversion step is the part of the pipeline where the routing question does not apply. Once the AI agent has produced a Markdown draft the writer is willing to publish, the conversion does not need an LLM. It needs a deterministic function. This is exactly what md2rich is: a single static HTML page that takes Markdown, produces rich text, and copies it to the clipboard as text/html. No backend, no model, no rate limit, no upload. The same input Markdown always produces the same output HTML. The clipboard payload is always text/html. The destination platform always accepts the paste. The conversion reliability is 100 percent by construction, which means the only variable part of the pipeline is the AI agent that produced the draft - and that is the part the routing layer is responsible for.

Pick the routing layer that fits the editor. Lock the conversion layer with md2rich. The pipeline is configurable where it should be and deterministic where it must be.