DEV Community: Vishal VeeraReddy

Lynkr vs LiteLLM vs OpenRouter vs PortKey: Choosing an LLM Gateway in 2026

Vishal VeeraReddy — Wed, 27 May 2026 00:58:39 +0000

Lynkr vs LiteLLM vs OpenRouter vs PortKey: Choosing an LLM Gateway in 2026

If you're building anything on top of LLMs in 2026 — a chatbot, an agent, a coding tool, an internal AI app — you've probably hit the same wall I did:

One provider goes down and your product dies with it.
Your OpenAI bill is climbing faster than your MRR.
You want to try a cheaper model, but switching means rewriting code.
Your team is now juggling 4 different SDKs for 4 different providers.

The answer is an LLM gateway — a proxy that sits between your app and every LLM provider, giving you one API, automatic failover, cost routing, and observability.

There are four serious contenders in this space right now: Lynkr, LiteLLM, OpenRouter, and PortKey. I've shipped production code on all four. Here's an honest comparison.

Full disclosure: I built Lynkr. I'll try to be fair about where the others are stronger.

TL;DR

	Lynkr	LiteLLM	OpenRouter	PortKey
Setup	`npm install -g lynkr` (3 lines)	Python + Docker + Postgres	Account signup, no self-host	Docker + YAML config
Self-hosted	✅	✅	❌ (SaaS only)	✅ (paid tier)
Claude Code / Codex / Cursor native	✅	⚠️ (manual config)	❌	⚠️ (manual config)
Local models (Ollama, llama.cpp)	✅ first-class	⚠️ Ollama only	❌	❌
Token optimization (caching/dedup)	✅ Built-in (60-80%)	❌	⚠️ Provider caching only	✅ Caching layer
Auto-failover	✅	✅	✅	✅
Observability dashboard	Basic	✅ Strong	✅ Strong	✅ Strongest
License	Apache 2.0	MIT	Proprietary	Mixed (OSS + paid)
Best for	Devs who want zero-config + coding tools	Python teams w/ existing infra	Quick prototyping	Enterprise observability

1. Lynkr — Zero-config gateway with first-class coding-tool support

What it is: A self-hosted Node.js proxy that exposes both OpenAI and Anthropic wire protocols, routing to 12+ providers underneath.

Where it wins:

Drop-in for Claude Code, Codex CLI, and Cursor. Set one env var (ANTHROPIC_BASE_URL=http://localhost:8081) and your existing tools transparently use any backend — Ollama, Bedrock, OpenRouter, Azure, DeepSeek. No other gateway in this list speaks the Anthropic protocol natively, which means none of them work as drop-ins for Claude Code.
Built-in token optimization (smart tool selection, prompt caching, memory dedup) shaves 60-80% off token counts on top of provider savings.
3-command install:

   npm install -g lynkr
   export ANTHROPIC_BASE_URL=http://localhost:8081
   lynkr start

Local-first. Ollama, llama.cpp, LM Studio, MLX are all first-class providers, not afterthoughts. Run Claude Code on free local models.
Apache 2.0, self-hosted, your data never leaves your infra.

Where it loses:

Observability is basic — log-level only. If you need a polished dashboard with per-team usage charts, PortKey or LiteLLM are ahead.
Newer project, smaller community than LiteLLM (~700 tests passing, growing).
Node.js only — if your team is Python-first, the LiteLLM SDK feels more native.

Pick Lynkr if: You want a coding-tool gateway that works in 60 seconds, or you want to run local models with the tools you already use.

🔗 https://github.com/Fast-Editor/Lynkr

2. LiteLLM — The mature Python-native gateway

What it is: The granddaddy of LLM gateways. A Python library and proxy server that normalizes 100+ providers to the OpenAI API format.

Where it wins:

Massive provider coverage. Hands down the most LLM providers supported — every obscure model you can name.
Strong Python SDK. If your app is Python, from litellm import completion feels native.
Enterprise features: team management, budgets, virtual keys, SSO, audit logs.
Mature dashboard (LiteLLM UI) with per-key spend tracking.
Battle-tested — used by Microsoft, Anthropic internal teams, and tons of YC startups.

Where it loses:

Setup is heavy. Production deployment wants Docker + Postgres + Redis. Not a "3 commands and go" experience.
No Anthropic protocol support. Can't drop into Claude Code as a transparent backend.
No token optimization layer. You pay full token cost.
Local model support is shallow — Ollama works, but llama.cpp/MLX are second-class.

Pick LiteLLM if: You have a Python codebase, need enterprise features (teams, budgets, SSO), and you're comfortable running Postgres.

3. OpenRouter — Quick prototyping, zero self-hosting

What it is: A hosted SaaS that aggregates 100+ models behind one OpenAI-compatible API. You pay them, they pay the providers.

Where it wins:

Literally zero setup. Sign up, get an API key, change your base URL. Done in 60 seconds.
Single bill instead of managing 5 provider accounts.
Built-in fallback — if one model fails, route to another automatically.
Auto-discovery of new models — they add them as providers release them.
Great for prototyping when you want to A/B test models without commitment.

Where it loses:

Not self-hosted. Your prompts and completions transit their infrastructure. For many enterprises, that's a non-starter.
No local model support. Cloud-only by design.
No Anthropic protocol — doesn't work with Claude Code, Cursor, or anything that expects Anthropic's API shape.
Markup on tokens. They take a small margin on every API call (~5%).
No token optimization. You pay full token cost, plus their margin.

Pick OpenRouter if: You're prototyping, you don't care about self-hosting, and you want the simplest possible "try any model" experience.

4. PortKey — Enterprise observability + gateway

What it is: A gateway + observability platform that emphasizes prompt management, evals, and production monitoring.

Where it wins:

Best-in-class observability. Per-request tracing, prompt versioning, eval pipelines, latency/cost dashboards.
Prompt management built in. Treat prompts like code with versions, A/B tests, and rollback.
Caching layer — semantic + exact-match caching out of the box.
Guardrails — built-in PII filtering, content moderation, response validation.
SOC 2, HIPAA options for regulated industries.

Where it loses:

Configuration is heavy. YAML-driven, with a learning curve. Not for weekend hacking.
The good stuff is paid. Self-hosted is free, but team features and advanced observability require their cloud or enterprise tier.
Coding-tool integration is manual — no native drop-in for Claude Code or Codex.
Doesn't shine for local models.

Pick PortKey if: You're an enterprise that needs deep observability, governance, and prompt management more than you need raw provider count.

How to choose — by use case

"I want to run Claude Code on free local models"

→ Lynkr. It's the only one in this list that natively speaks Anthropic's protocol, which is what Claude Code expects. Three commands and you're running Claude Code on Ollama for $0/day.

"I'm prototyping and just want to try every model fast"

→ OpenRouter. Sign up, swap base URL, done. Don't self-host until you have to.

"I have a Python production codebase with team budgets and SSO needs"

→ LiteLLM. Mature, Python-native, every enterprise feature.

"I need deep observability, prompt versioning, and compliance"

→ PortKey. Most polished dashboards and governance features.

"I'm building a multi-provider product and want token costs minimized"

→ Lynkr (for the built-in 60-80% optimization) or LiteLLM (for breadth).

The honest landscape in 2026

LLM gateways used to be a "nice to have." In 2026 they're table stakes — provider outages, pricing changes, and the explosion of capable open models mean no serious app should be hard-wired to one provider.

The right gateway depends on what you're building:

Coding tools and local-model fans: Lynkr.
Python production apps with team management: LiteLLM.
Quick prototyping with zero ops: OpenRouter.
Regulated enterprise with deep observability: PortKey.

The good news: all four are viable. The bad news: most teams pick the wrong one because they didn't realize the others existed.

If you're paying any LLM bill today, the highest-leverage hour you can spend this week is switching to a gateway. Pick one, point your app at it, and never let a provider outage take you down again.

What gateway are you running, and what do you wish it did better? Drop a comment — I'd love to see what's working and what isn't.

Run Hermes Agent on Any Model — Free, Local, and Cost-Routed

Vishal VeeraReddy — Fri, 22 May 2026 05:22:50 +0000

If you've spent any time wrestling with AI coding tools and agents in 2026, you've hit two walls:

Provider lock-in. Claude Code expects Anthropic. Codex expects OpenAI. Your shiny new agent framework wants whatever its README assumes.
Agent amnesia. Every session starts from zero. Your "AI assistant" doesn't actually learn anything about you, your codebase, or the work you did yesterday.

Two open-source projects address those problems head-on — and they pair beautifully together.

Hermes Agent (by Nous Research) — a self-improving AI agent with a built-in learning loop, multi-platform presence, and a serious tool ecosystem.
Lynkr — a self-hosted universal LLM proxy that lets any AI tool talk to any model provider.

This post explains what each one is, why they exist, and shows you the exact steps to run Hermes through Lynkr so you can route Hermes to Databricks, Bedrock, Ollama, llama.cpp, Azure, OpenRouter — or all of them with automatic cost-tier routing.

What Is Hermes Agent?

Hermes is an open-source AI agent (MIT-licensed, built by Nous Research) that you actually live inside, not just call.

What makes it different from "yet another agent":

A closed learning loop. Hermes curates its own memory, autonomously creates skills (procedural memory) after complex tasks succeed, improves them during use, and searches its own past conversations via SQLite FTS5. It's the only agent I've seen that gets meaningfully better the longer you use it.
Lives where you do. A single gateway process plugs into Telegram, Discord, Slack, WhatsApp, Signal, Email, and a real terminal TUI. Send a voice memo from your phone, get a transcribed answer back, continue the same thread from your laptop later.
Runs anywhere. Seven terminal backends — local, Docker, SSH, Singularity, Modal, Daytona, Vercel Sandbox. Run it on a $5 VPS or a GPU cluster. Modal/Daytona give you serverless persistence — hibernates when idle, wakes on demand.
Built-in cron. "Every weekday at 8am, summarize my GitHub notifications and send to Telegram." That's a one-line cron job in natural language.
Delegates and parallelizes. Spawns isolated subagents for parallel workstreams; results come back without flooding your context.
Provider-agnostic by design. OpenRouter, Nous Portal, NovitaAI, NVIDIA NIM, Xiaomi MiMo, z.ai/GLM, Kimi/Moonshot, MiniMax, Hugging Face, OpenAI, or your own endpoint. Switch with hermes model — no code changes.

Architecture in one paragraph

The core is AIAgent in run_agent.py — a synchronous tool-calling loop over OpenAI-format messages. model_tools.py orchestrates ~40 built-in tools auto-discovered from tools/. The CLI (cli.py, ~11k LOC) handles slash commands, prompt_toolkit input, Rich rendering, and a data-driven skin engine. Provider profiles live under plugins/model-providers/<name>/ and contribute base_url, env_vars, api_mode, and fallback_models — the runtime resolver merges those with custom_providers from config.yaml to figure out where to send each request. That last detail is what makes Lynkr integration trivial.

Install Hermes in one line

curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh | bash

Then hermes to start chatting.

What Is Lynkr?

Lynkr is a self-hosted Node.js proxy that sits between any AI coding tool and any LLM provider. One environment variable change, and your tool works with whatever backend you want.

Claude Code / Cursor / Codex / Cline / Continue / Hermes / Vercel AI SDK
                                |
                              Lynkr  (http://localhost:8081)
                                |
   Ollama | Bedrock | Databricks | OpenRouter | Azure | OpenAI | llama.cpp | LM Studio | z.ai | Vertex | Moonshot

What's actually inside

I went through the source. Lynkr is more than a "translate request, forward, translate response" proxy:

Format conversion. Anthropic ↔ OpenAI ↔ Codex Responses API ↔ Databricks ↔ Bedrock — handled in src/clients/ (openai-format.js, responses-format.js, databricks.js, bedrock-utils.js, etc.).
Tier-based routing. src/routing/ analyzes prompt complexity, agentic intent, risk, and latency, then routes to a TIER_SIMPLE / TIER_STANDARD / TIER_COMPLEX model. Cheap stuff goes to Ollama; gnarly stuff goes to a frontier cloud model. This is where the headline "60–80% cost savings" comes from.
Resilience. Circuit breaker (cockatiel), retries, DNS logging, prompt cache injection.
MCP integration + Code Mode. Auto-discovers MCP servers and can collapse 100+ MCP tool definitions into 4 meta-tools (~96% token reduction).
Observability built in. Telemetry, latency tracking, usage reporting (lynkr usage shows AI spend and tier savings), trajectory export as JSONL for training (lynkr trajectory).
699 passing tests. Routing, format conversion, streaming, error resilience, memory store, prompt cache — it's seriously tested for a side-project proxy.

Install Lynkr in one line

curl -fsSL https://raw.githubusercontent.com/Fast-Editor/Lynkr/main/install.sh | bash

Or via npm: npm install -g pino-pretty && npm install -g lynkr.

Why Use Them Together?

Hermes already supports a long list of providers natively. Why bolt Lynkr in front?

Three concrete reasons:

1. Unify your enterprise creds

Your company has a Databricks endpoint serving Claude, an AWS Bedrock account with cross-region inference profiles, an Azure OpenAI deployment, and a private Ollama box. With Lynkr, all of those live behind one OpenAI-compatible URL. Hermes points at that URL and stops caring which backend is serving the request.

2. Automatic cost-tier routing

This is the killer feature. Hermes can switch models with /model, but Lynkr will switch per request based on complexity. Simple tool calls and short prompts go to free local Ollama. Heavy reasoning goes to your premium cloud model. You don't think about it — Lynkr's complexity-analyzer.js and risk-analyzer.js decide.

Run lynkr usage afterward to see the actual savings.

3. Centralized observability for every agent + tool

If you run Hermes + Claude Code + Cursor + Codex all on the same machine — and a lot of us do — Lynkr becomes a single chokepoint for spend, telemetry, prompt caching, and trajectory capture across all of them. You get one usage report instead of four dashboards.

How to Use Lynkr With Hermes

The integration is genuinely 3 minutes of work because both tools speak OpenAI-compatible HTTP.

Step 1: Start Lynkr with a backend

Pick whatever provider you want Lynkr to route to. For a local-first setup:

# .env in your Lynkr directory (or just exports)
export MODEL_PROVIDER=ollama
export OLLAMA_MODEL=qwen2.5-coder:latest
export OLLAMA_ENDPOINT=http://localhost:11434

lynkr start

Or for tier routing across providers:

export TIER_SIMPLE=ollama:qwen2.5-coder:latest
export TIER_STANDARD=openrouter:anthropic/claude-3.5-haiku
export TIER_COMPLEX=bedrock:anthropic.claude-3-5-sonnet-20241022-v2:0
export OPENROUTER_API_KEY=sk-or-...
export AWS_BEDROCK_API_KEY=...
lynkr start

Lynkr now listens on http://localhost:8081 (OpenAI-compatible) and http://localhost:8081/v1/messages (Anthropic-compatible).

Step 2: Register Lynkr as a custom provider in Hermes

Hermes resolves providers through plugins/model-providers/<name>/ profiles plus a custom_providers list in your ~/.hermes/config.yaml. Add an entry:

custom_providers:
  - name: lynkr
    base_url: http://localhost:8081/v1
    api_mode: chat_completions
    env_var: LYNKR_API_KEY      # any string works — Lynkr doesn't validate
    models:
      - auto                    # Lynkr's tier router picks the actual model
      - qwen2.5-coder:latest
      - anthropic/claude-3.5-sonnet

Then set the key (any value):

hermes config set env.LYNKR_API_KEY sk-lynkr

Step 3: Point Hermes at Lynkr

hermes model custom:lynkr/auto

Or interactively: run hermes model, pick custom:lynkr, choose auto.

That's it. Every Hermes turn now flows through Lynkr, which routes to the right backend based on tier and complexity. Run a few turns, then:

lynkr usage

…and you'll see the per-tier spend breakdown and dollars saved versus a single-frontier-model baseline.

Bonus: voice memo → Hermes → Lynkr → cheapest model

Because Hermes already has Telegram and voice memo transcription wired in, this whole stack means:

Record a voice memo on your phone → Hermes transcribes it → routes the request through Lynkr → Lynkr picks Ollama for the "what time is it in Tokyo" parts and Sonnet for the "refactor this function" parts → reply comes back to your phone.

You built that in 5 minutes with two npm/bash installers and a YAML edit.

When NOT to Use Lynkr With Hermes

Being honest:

You only use one provider. Hermes already supports it natively. Adding Lynkr is extra latency and another process to babysit.
You need streaming reasoning tokens from a specific model. Make sure Lynkr's format converter for that provider preserves what you need — it does for most cases, but verify before betting on it.
You're on a constrained environment. Lynkr is Node 20+. Hermes is Python 3.11. That's two runtimes on a Raspberry Pi.

For everything else — multi-provider workflows, enterprise creds, cost optimization, observability — the combination is hard to beat.

TL;DR

Need	Tool
A real AI agent that learns, remembers, and lives across Telegram/Discord/CLI	Hermes
Route any AI tool to any LLM provider with automatic cost tiers	Lynkr
Both	Point Hermes at Lynkr via `custom_providers` in `config.yaml`

What is Google Gemini Spark? A Deep Dive Into Google's 24/7 Personal AI Agent

Vishal VeeraReddy — Fri, 22 May 2026 05:16:13 +0000

What is Google Gemini Spark? A Deep Dive Into Google's 24/7 Personal AI Agent

If you watched Google I/O 2026, one announcement quietly stole the show — not because it was the flashiest, but because it represents a fundamental shift in how we'll interact with computers. That announcement was Gemini Spark.

Spark isn't another chatbot. It isn't a smarter Search. It's Google's first serious attempt at a 24/7 autonomous personal agent — software that keeps working when your phone is in your pocket, when your laptop is closed, and when you're asleep.

Let's break down what it actually is, how it works, and why it matters for developers.

TL;DR

Gemini Spark is a persistent, autonomous AI agent that lives across Gmail, Docs, Calendar, and the rest of Google Workspace.
It runs 24/7 in the background, even when your device is closed.
It's powered by Gemini 3.5 Flash (with Pro coming soon) and built on top of the open Model Context Protocol (MCP) so third-party tools can plug in.
It launched first for Google AI Ultra subscribers ($100/month) in the US, with broader rollout to follow.
For developers, Spark + MCP is the most important integration surface Google has shipped in years.

1. What Exactly Is Gemini Spark?

Gemini Spark is a personal agent that Google describes as a "24/7 collaborator." Unlike previous AI features that respond when you ask, Spark is proactive:

It reads your incoming email and flags what needs action.
It drafts replies, schedules, and follow-ups before you ask.
It tracks ongoing tasks across days and weeks.
It executes multi-step workflows that span multiple apps.
It keeps doing all of the above while your phone is locked.

Think of it as the difference between hiring a contractor (Gemini chat) and hiring a full-time assistant (Spark). One responds to tickets. The other owns outcomes.

2. How It Works Under the Hood

The Model Layer: Gemini 3.5 Flash

Spark runs on Gemini 3.5 Flash, Google's new default model. Key specs Google announced:

~4x faster token output than competing frontier models
Beats the older Gemini 3.1 Pro on coding and agentic benchmarks
Optimized for the kind of long-running, low-latency tool use that agents need

Flash is the right choice here because agents make a lot of small decisions ("should I draft this? wait for more context? ask the user?"). Latency compounds.

The Protocol Layer: MCP (Model Context Protocol)

This is the part most developers missed. Instead of building a proprietary plugin system, Google adopted MCP — the open standard originally pushed by Anthropic — as the way third-party tools connect to Spark.

This is huge. It means:

One MCP server you build can serve Claude, Gemini Spark, and any other MCP-compatible host.
You don't need to maintain a separate "Google plugin" SDK.
Tool definitions, auth, and resource exposure all follow one spec.

A minimal MCP tool looks roughly like this:

from mcp.server import Server
from mcp.types import Tool, TextContent

server = Server("my-tool-server")

@server.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="get_invoice_status",
            description="Look up status of an invoice by ID",
            inputSchema={
                "type": "object",
                "properties": {"invoice_id": {"type": "string"}},
                "required": ["invoice_id"],
            },
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict) -> list[TextContent]:
    if name == "get_invoice_status":
        status = lookup_invoice(arguments["invoice_id"])
        return [TextContent(type="text", text=status)]

Register this with Spark and it can now check invoice status on your behalf — at 3am, while you're asleep, when an email asking about an invoice arrives.

The Runtime Layer: Background Execution

The genuinely new piece is the persistent runtime. Most "AI assistants" stop existing the moment you close the tab. Spark keeps a server-side execution context tied to your account that:

Subscribes to events (new email, calendar change, doc edit).
Wakes the agent loop on relevant triggers.
Executes tool calls (MCP, Workspace APIs, Search).
Surfaces results via the Android Halo — a small communication band at the top of the phone screen showing what background agents are doing.

The Halo is a UX innovation worth noticing: it solves the "what is my agent secretly doing?" trust problem by always making background work visible.

3. What Spark Can Actually Do Today

From the I/O 2026 demos and rollout notes:

Email triage — Reads inbox, drafts replies, surfaces what needs your attention.
Schedule management — Reschedules meetings, finds slots, sends invites.
Daily Brief — Morning digest pulling from Gmail, Calendar, and Tasks, ranked by priority.
Cross-app workflows — "Find the contract Sarah sent last month, summarize the changes, and email her the redline" → executes end-to-end.
Persistent monitoring — "Watch this listing and ping me if the price drops below X" runs indefinitely.

4. Pricing: The Catch

Spark launched on Google's new Ultra tier ($100/month). More importantly, Google scrapped per-day prompt limits and moved to a compute-used billing model. You're charged based on:

Prompt complexity
Features invoked (Spark, Flow, Omni)
Length of the conversation/agent run

The allowance refreshes roughly every 5 hours. A heavy debugging session — or a Spark agent that runs hot for an afternoon — can drain it fast. Build accordingly.

5. Why This Matters for Developers

Three concrete reasons Spark should be on your radar:

1. MCP is now a two-vendor standard

With both Anthropic and Google supporting MCP, it's the closest thing to a universal "tools for agents" spec we have. Build MCP servers, not proprietary integrations.

2. The unit of software is shifting

For ten years we built apps that respond to clicks. The next decade is about building services that agents can drive. That means:

Stable, well-documented APIs
Clear tool descriptions (the LLM has to pick yours over a competitor's)
Idempotent operations (agents will retry)
Streaming/long-running job patterns (agents wait for things)

3. Background-first design

If your product can be useful while the user isn't looking at it, Spark is a distribution channel. "What can my app do for the user at 2pm Tuesday when they're in a meeting?" is now a real product question.

6. How to Start Building for Spark Today

Stand up an MCP server exposing your product's core capabilities. The official Python and TypeScript SDKs are at modelcontextprotocol.io.
Write tool descriptions like marketing copy. The model picks tools based on the description — clarity wins.
Make every operation idempotent and resumable. Background agents crash, retry, and resume.
Test with multiple hosts. Same MCP server should work in Claude Desktop, Gemini Spark, and any other MCP client. If it doesn't, your server is doing something non-standard.
Design for partial autonomy. The best agent UX is "I drafted this — approve?" not "I sent this." At least at first.

Closing Thought

Gemini Spark is the clearest signal yet that the agent era is the product era of the next decade. The companies that win it won't be the ones with the smartest model — they'll be the ones whose software is the easiest for agents to use.

If you ship developer tools, APIs, or SaaS, your roadmap question for 2026 is no longer "how do we add AI features?" It's "how do we become the tool an agent reaches for?"

Spark is Google placing its bet. Time to place yours.

Found this useful? Drop a comment with what you're building for the agent era — I'd love to see it.

Run OpenHands on Any Model You Want

Vishal VeeraReddy — Fri, 22 May 2026 05:09:18 +0000

There's a quiet shift happening in how serious developers are using AI in 2026. The hype cycle has moved past "ask the chatbot" and landed somewhere more interesting: autonomous coding agents that actually open files, run commands, and ship work — paired with self-hosted routing layers that decide which model handles which turn so you don't go broke doing it.

This post is about the two open-source projects I've quietly stitched together into my daily driver — and the setup has all but replaced the closed tools I used to pay a small fortune for. OpenHands is the agent: a sandboxed, autonomous software engineer that opens files, runs commands, writes tests, and ships PRs. Lynkr is the router: a self-hosted proxy that sits in front of every LLM provider on the market and decides, request by request, which one should answer. One runs the work. The other decides what the work is worth. Together, they run locally, leak nothing to a third-party SaaS, and cost a fraction of anything closed you can buy in 2026.

What is OpenHands?

OpenHands is the most credible open-source answer to closed AI coding agents like Devin, Cursor's background agents, and Codex CLI. It grew out of the OpenDevin research project (renamed in early 2025) and is now maintained by All-Hands-AI, a venture-backed company with an $18.8M Series A. The repo lives at All-Hands-AI/OpenHands, ships under the MIT license, and at version 1.7.0 (May 2026) has crossed 74,400+ GitHub stars, 9,400+ forks, 102 releases, and 6,700+ commits — making it by a wide margin the most-adopted open agent framework in the world. The codebase is roughly 63% Python and 36% TypeScript. To understand why it works, it helps to look at the architecture, the agent design, the runtime, and the customization surface in turn.

The architecture: event-sourced, modular, deploy-anywhere

The V1 SDK that landed alongside the November 2025 paper "The OpenHands Software Agent SDK" is a clean reimagining of the original V0 monolith. Where V0 had 140+ configuration fields spread across 15 classes and tightly coupled the agent to the sandbox, V1 splits the system into four independent packages: an SDK for agent definitions, a Tools layer for action handlers, a Workspace layer for execution environments, and a Server for hosting. Everything is stateless and immutable — agents are configuration objects, not living entities — and all mutable context lives in a single event-sourced ConversationState object. The conversation itself is a typed stream of Action and Observation Pydantic events, both immutable, both replayable. This is the single most important design decision in OpenHands: an autonomous agent is modeled as a pure function from event history to next event, run in a loop. Pause, resume, fork, deterministic replay, and full audit trails come for free. The same code runs in a Jupyter notebook locally or against a remote container farm in production — the Conversation factory transparently picks LocalConversation (in-process) or RemoteConversation (HTTP/WebSocket to a containerized server) based on config, with zero code changes.

The agent: CodeActAgent and the "code as universal tool" insight

The flagship agent is CodeActAgent, and its premise comes from the original CodeAct paper: instead of handing the LLM 20 bespoke tools each wrapped in their own JSON schema, give it bash, Python (via Jupyter), and a browser DSL, and let it express any action as code. Want to read a file? cat. Want to refactor across the repo? Python. Want to verify a fix lands? Run the tests. Want to scrape documentation? Drive the browser. Empirically this generalizes far better than tool-per-task designs and dramatically reduces parsing errors, because the model is doing what it's already best at — writing code — instead of filling in arbitrary JSON. Tool use is unified through a single Action → Execution → Observation contract. The SDK also ships MCPToolDefinition extending the standard ToolDefinition interface, so Model Context Protocol tools plug in alongside native ones with no glue code, and a built-in RouterLLM that can switch models mid-conversation (e.g., escalate to a multimodal model only when an image actually appears in context). A LLMSecurityAnalyzer scores every proposed tool call as LOW / MEDIUM / HIGH / UNKNOWN and can pause for confirmation on dangerous operations — a layer most agent frameworks simply don't have.

The runtime: a sandboxed Docker microservice

Agents never touch your host directly. Every action runs inside a sandboxed runtime container that exposes an action execution server over a REST API, which the OpenHands backend talks to in a tight loop: send Action, receive Observation, repeat. The container ships its own bash shell, Jupyter kernel, headless browser, and a pluggable skills system, plus optional VS Code Web access on a tokenized URL so you can drop into the sandbox visually if you want to. Images are managed through a clever three-tier tagging system — source-hash, lock-hash, versioned — so rebuilds are incremental and reproducible across machines. The runtime is pluggable too: Docker is the default, LocalRuntime runs the action server on the host for fastest iteration, and RemoteRuntime targets remote container infrastructure for fleet-scale deployment. Plugin backends include E2B, Modal, and Daytona for teams that already have sandbox infrastructure they trust. Storage supports bind mounts and Docker named volumes with optional copy-on-write overlay mode for isolation.

The customization surface: microagents (V0) / Skills (V1)

OpenHands is opinionated but extensible through what V0 calls microagents and V1 renames to Skills (both terms still work — V1 reads the V0 layout for backward compatibility). You drop a .openhands/microagents/ directory at the root of your repo, add markdown files like repo.md, frontend.md, or migrations.md, and the main agent loads them on demand. A repo.md gives the agent the high-level mental model of your codebase — directory layout, build commands, test conventions, where the gotchas are — so it doesn't have to rediscover them every session. Triggered microagents activate only when their keywords appear in the conversation, so you can teach the agent narrow domain knowledge without bloating every prompt. This is where the project's "agents that ship in production" claim earns its keep: tuning OpenHands for your specific codebase is a markdown commit, not a fork.

The interfaces: four ways in

You can use OpenHands as a CLI (terminal-native, like Aider or Claude Code), a local GUI (React SPA backed by a REST/WebSocket API, the default docker run experience), the hosted cloud at all-hands.dev (free tier on Minimax models, paid tiers on frontier providers, GitHub/GitLab login), or as a headless service driven programmatically via the SDK. The headless mode is what powers the OpenHands Resolver: connect it to a GitHub repo, label an issue, and OpenHands spins up a sandboxed runtime, analyzes the issue, edits the code, runs the tests, and opens a PR — fully autonomous. The same Resolver pattern works for GitLab. For enterprise teams, the deployment story extends to private Kubernetes clusters with RBAC, Slack/Jira/Linear connectors, and source-available enterprise features.

The numbers that matter

OpenHands publishes against the standard benchmark: 77.6% on SWE-Bench Verified with Claude 3.5 Sonnet Thinking on the V0 harness, and 72.8% SWE-Bench Verified + 67.9% GAIA with Claude Sonnet 4.5 on the V1 SDK. Those aren't the highest numbers ever posted, but they are the highest by an open-source, self-hostable system you can actually inspect, fork, and run yourself. In January 2026 the team launched the OpenHands Index — a continuously-updated leaderboard evaluating models across five real engineering categories (Issue Resolution, Greenfield Development, Frontend Development, Software Testing, and Information Gathering) by ability, cost, and execution time. That tells you something about where the project is heading: away from "agent as parlor trick" and toward "agent as measured, reproducible infrastructure."

What ties it together

The throughline is that OpenHands is not trying to be a chatbot or an autocomplete. It's trying to be the runtime layer for autonomous software agents — composable, sandboxed, observable, model-agnostic, and equally happy in a notebook or behind a load balancer. It uses LiteLLM under the hood for LLM dispatch, which means 100+ providers are reachable today (Claude, GPT, Gemini, Bedrock, Vertex, Azure, OpenRouter, Ollama, llama.cpp, anything LiteLLM speaks) with no code changes. That last property is what makes the Lynkr pairing not just possible but obvious.

What is Lynkr?

Lynkr is a self-hosted Node.js proxy that sits between your AI coding tools and the dozen-plus LLM providers worth using, listening on http://localhost:8081 and presenting both Anthropic Messages and OpenAI Chat Completions APIs simultaneously. From the outside it looks like a normal LLM endpoint — point Claude Code, Cursor, Aider, Codex CLI, or OpenHands at it with one environment variable and you're done — but on the inside it does something none of those tools do on their own: it analyzes every request across 15 weighted dimensions (including an AST-based knowledge graph called Graphify that understands code structure across 19 languages, detecting god nodes, community cohesion, and architectural blast radius) and routes it to one of four model tiers — simple, medium, complex, or reasoning — based on what the request actually needs. Supported backends include local-and-free options (Ollama, llama.cpp, LM Studio, MLX Server) and cloud providers (AWS Bedrock with 100+ models, OpenRouter with 100+ more, Azure OpenAI, Azure Anthropic, OpenAI, Google Vertex, Databricks, Moonshot, Z.AI, DeepSeek). On top of routing, Lynkr layers a seven-phase token optimization pipeline — smart tool selection, Code Mode which collapses 100+ MCP tools into 4 meta-tools (≈96% tool-overhead reduction), Distill structural compression, SHA-256-keyed LRU prompt caching, memory deduplication, sliding-window history compression, and an optional ML-based headroom sidecar (Smart Crusher, CCR, LLMLingua) — plus a Titans-inspired long-term memory subsystem that stores observations in a SQLite FTS5 database (lynkr.db) scored on surprise, recency, and relevance, and injects only the relevant slice back into system prompts on future requests. Production deployments get Prometheus metrics at /metrics, Kubernetes-ready health checks, circuit breakers with half-open probe recovery, hot-reloadable config via POST /v1/admin/reload, SQLite-backed routing telemetry with P50/P95/P99 latencies and 0–100 quality scoring on every decision, and load shedding under pressure.

Why You Should Use Lynkr With OpenHands

The honest case for stacking these two has four layers, and each one matters more than the last.

Cost, but not the dumb kind. OpenHands is brilliant precisely because it doesn't ask permission — it just does the work, which means it burns through tokens at a rate that's painful if every turn hits a frontier model. A long session can quietly cost $20+ in Opus tokens because the agent doesn't know — and shouldn't have to know — that a mv foo.py bar.py doesn't deserve a $15-per-million model. Lynkr's complexity analysis is the missing brain: simple file moves and grep calls drop to simple tier (Haiku, GPT-4o-mini, local Qwen), real architectural reasoning gets routed to reasoning tier (Opus, GPT-5, Gemini Ultra). Users typically report 60–80% lower spend without a meaningful drop in output quality, because the expensive models still get called — just for the turns that actually need them. Unlike OpenRouter, Lynkr doesn't take a 5.5% cut of your credits, and unlike LiteLLM's proxy, the token optimization pipeline is built in rather than something you bolt on.

Provider redundancy that doesn't require you to redeploy. When Anthropic has a bad afternoon — and they do — your OpenHands session doesn't stop. Lynkr's circuit breakers detect the failure, route around it to a configured fallback (Bedrock Claude, Azure Anthropic, OpenAI, whatever you've set), and quietly recover via half-open probes when the primary comes back. You change zero code.

Local models when you want them, frontier when you don't. Drop in Ollama or LM Studio as your simple tier and the cheapest turns in your session cost literally nothing — they never leave your machine. The same OpenHands install can be 100% offline-capable for development tasks and seamlessly burst to cloud Opus for the hard problems. No other agent + router combination on the market does this without significant glue code.

One config owns your model strategy. This is the underrated win. As models drop monthly (GPT-5.1, Sonnet 4.7, Gemini 3, the next open-weights surprise from DeepSeek), you stop rewiring your tools — you change one line in Lynkr's config and hot-reload. OpenHands keeps doing what it does. Cursor, Claude Code, Aider, and every other tool pointed at the same Lynkr instance get the new strategy for free.

A note on philosophy: nothing about your code, prompts, or context ever passes through a third-party SaaS on the way to the model. Lynkr is self-hosted, your provider keys live in your environment, and the routing decisions are auditable in a local SQLite database. For anyone working in a regulated environment — or who just doesn't love handing prompt logs to an intermediary — this matters.

How to Use It

The full setup is three steps and roughly five minutes.

1. Install and start Lynkr

Pick whichever feels right:

# One-line install (recommended)
curl -fsSL https://raw.githubusercontent.com/Fast-Editor/Lynkr/main/install.sh | bash

# Or npm
npm install -g lynkr

# Or Homebrew
brew tap vishalveerareddy123/lynkr && brew install lynkr

# Or Docker
docker-compose up -d

2. Configure your providers

Lynkr reads from environment variables (or a .env file). A reasonable starter config that mixes a local model for cheap turns with cloud frontier models for hard ones:

# Tier definitions
SIMPLE_PROVIDER=ollama
SIMPLE_MODEL=qwen2.5-coder:latest

MEDIUM_PROVIDER=openai
MEDIUM_MODEL=gpt-4o-mini

COMPLEX_PROVIDER=anthropic
COMPLEX_MODEL=claude-sonnet-4-6

REASONING_PROVIDER=anthropic
REASONING_MODEL=claude-opus-4-7

# Provider credentials
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...

# Optimizations
SEMANTIC_CACHE_ENABLED=true
CODE_MODE_ENABLED=true
MEMORY_ENABLED=true

Start it and verify:

lynkr start
curl http://localhost:8081/v1/models   # should return a JSON model list

3. Point OpenHands at Lynkr

Three environment variables on the OpenHands container do the entire job. The LLM_BASE_URL tells LiteLLM where to send requests, the LLM_API_KEY is a placeholder (Lynkr accepts anything because the real auth lives upstream), and the openai/ prefix on LLM_MODEL tells LiteLLM to use OpenAI wire format against Lynkr's /v1/chat/completions endpoint — even when the model on the other side is Claude or Gemini.

Full copy-pasteable command:

docker run -it --rm --pull=always \
  -e AGENT_SERVER_IMAGE_REPOSITORY=ghcr.io/openhands/agent-server \
  -e AGENT_SERVER_IMAGE_TAG=1.19.1-python \
  -e LOG_ALL_EVENTS=true \
  -e LLM_BASE_URL="http://host.docker.internal:8081/v1" \
  -e LLM_API_KEY="sk-lynkr" \
  -e LLM_MODEL="openai/claude-sonnet-4-6" \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v ~/.openhands:/.openhands \
  -p 3000:3000 \
  --add-host host.docker.internal:host-gateway \
  --name openhands-app \
  docker.openhands.dev/openhands/openhands:1.7

Open http://localhost:3000, give OpenHands a task, and watch the proxy do its job. If you tail lynkr logs in another terminal you'll see the routing decisions in real time — which tier each request landed on, latency, cached vs cold, and the quality score.

If you prefer config.toml over env vars, OpenHands also accepts:

[llm]
model = "openai/claude-sonnet-4-6"
base_url = "http://localhost:8081/v1"
api_key  = "sk-lynkr"

The same pattern works from OpenHands' GUI under Settings → LLM → Advanced.

What's Actually Happening Under the Hood

When OpenHands fires a request, here's the full lifecycle:

OpenHands → LiteLLM formats the call as OpenAI Chat Completions and ships it to http://host.docker.internal:8081/v1/chat/completions.
Lynkr ingests the request, runs token counting and budget enforcement.
Optimization pipeline applies prompt caching (SHA-256 LRU), memory deduplication, tool truncation (Code Mode collapses MCP tool definitions), and history compression.
Complexity analysis scores the request across 15 dimensions including Graphify AST signals; the router picks a tier.
Format translation converts to whatever wire protocol the destination needs — Bedrock Converse, Vertex Gemini, Anthropic Messages, or stays OpenAI.
Provider invocation via the unified invokeModel() abstraction. If the circuit breaker is open, the request silently fails over.
Response translation converts back to OpenAI Chat Completions for LiteLLM.
Telemetry writes the routing decision, latency percentiles, and quality score to SQLite for later inspection.
Memory subsystem scores the exchange for surprise / recency / relevance and stores any high-signal observations for future injection.

OpenHands sees a perfectly normal OpenAI response. It has no idea any of that happened.

Gotchas Worth Knowing

Don't also set ANTHROPIC_BASE_URL inside the OpenHands container. OpenHands talks via LiteLLM, not the Anthropic SDK directly — the LLM_* env vars are the correct lever.
On Linux, the --add-host host.docker.internal:host-gateway flag is what lets the container resolve back to your host. The command above already includes it; don't drop it.
Keep the openai/ prefix on LLM_MODEL. Without it, LiteLLM tries to use the Anthropic SDK against an OpenAI-shaped endpoint and fails confusingly.
If you're running Lynkr in Docker too, put both containers on the same Docker network and reference Lynkr by container name instead of host.docker.internal.
The LLM_API_KEY value is ignored by Lynkr but must be set to something — LiteLLM refuses to send requests without an API key field present.

The Bigger Picture

The reason this combo works isn't that either project is doing something magical in isolation — it's that they respect the same boundary. OpenHands knows it shouldn't care which model is on the other side of LiteLLM; Lynkr knows it shouldn't care which tool is asking. That clean separation is what makes the stack composable. Tomorrow you can swap OpenHands for Aider or Cline without touching Lynkr's config. Next month you can add Kimi K2 or whatever Mistral ships next without touching OpenHands. The agent layer and the routing layer evolve independently, and your wallet quietly benefits from both.

That's the version of the AI coding stack worth betting on in 2026: open, local-first, model-agnostic, and configurable from one file you actually control.

If you want the source: OpenHands lives at github.com/All-Hands-AI/OpenHands, Lynkr at github.com/Fast-Editor/Lynkr. Both accept contributions, and both maintainers ship fast.

HTML Is the New Markdown

Vishal VeeraReddy — Sun, 17 May 2026 07:47:23 +0000

A response to Thariq Shihipar's "HTML is the new markdown" post — and a practical answer for anyone watching their per-request costs creep up.

The tweet that started it

On May 8, Thariq Shihipar — a member of the Claude Code team at Anthropic — posted what is now one of the most-discussed dev takes of the quarter:

"HTML is the new markdown. I've stopped writing markdown files for almost everything and switched to using Claude Code to generate HTML for me."

The case he made was genuinely compelling. HTML, he argued, lets Claude do things markdown simply can't:

Inline SVG diagrams instead of fenced ASCII art
Interactive widgets — sliders, toggles, collapsible sections — so a PR review or architectural doc becomes a navigable artifact instead of a wall of text
In-page navigation, color-coded severity, real layout
Semantic structure the model can hang richer reasoning on

Thariq's example prompt — "Help me review this PR by creating an HTML artifact… color-code findings by severity" — captures the appeal in one line. The output looks like a small internal tool, not a chat log. Once you see it, going back to plain markdown feels like trading a dashboard for a printout.

Simon Willison agreed enough to write it up the same week. Then the dissents arrived.

The counter-argument: this is expensive

The most-shared rebuttal came from Kurtis Redux's "The Unreasonable Ineffectiveness of HTML". Three points landed:

HTML is 2–4× slower to generate than the markdown equivalent — and roughly 2–4× more output tokens to render the same information.
Verbose markup dilutes model attention. The longer the output, the easier it is for the model to lose the plot, repeat itself, or hallucinate structure halfway down.
Output tokens are the expensive tokens. Across every major API price card, output is 3–5× the cost of input. Recommending 2–4× more output is a real line item.

Then came the uncomfortable subtext from a few corners of the timeline: Anthropic sells by token. Of course a Claude Code engineer wants you generating more of them.

I don't think that's fair to Thariq — he's been shipping thoughtful, often unflattering-to-Anthropic posts about prompt caching and token efficiency for a year. But the structural concern stands: the people best positioned to tell us how to use these tools also have the most to gain when we use them more.

The real question

The argument has been framed as a binary: rich-but-expensive HTML, or cheap-but-flat markdown. Pick a side.

That framing is wrong. The question that actually matters is:

Can I get the HTML output Thariq is excited about — without paying the HTML token bill?

The answer is yes, and most of it has nothing to do with which model you're using. It has to do with everything that happens around the model call. That's the slice I've been working on with Lynkr.

What's actually inflating your token count

Before talking about HTML output, it's worth being honest about where tokens actually go in a Claude Code-style session. In a typical agentic loop, the output HTML is the smallest chunk. The big spenders are:

The system prompt and tool definitions — re-sent every single turn. Claude Code ships with 50+ tools, each with verbose JSON schemas. That's tens of thousands of input tokens per turn before the user has typed anything.
Conversation history — every prior assistant message, every tool call, every tool result, replayed each step.
Tool results — cargo build, pytest -v, eslint ., git diff. A failing test run can dump 40k tokens of stack trace.
MCP tool catalogs — wire up half a dozen MCP servers and your tool schema can balloon past 100k tokens.

The HTML the model writes is real cost, but it's measured in hundreds-to-low-thousands of output tokens. The HTML-vs-markdown debate is fighting over the tip while the iceberg sits unchallenged.

If you want HTML outputs without a wince at the invoice, the lever isn't "stop generating HTML." The lever is "stop sending the model a quarter-million tokens of repeated context to get to that HTML."

How Lynkr attacks the iceberg

Lynkr is a self-hosted proxy that sits between your coding tool (Claude Code, Cursor, Codex CLI, Cline, Continue) and any of 13+ LLM providers. It speaks Anthropic's /v1/messages and OpenAI's /v1/chat/completions, so the client doesn't know it's there. What it does in the middle is the interesting part. A few of the layers most relevant to the HTML-output discussion:

0. Preflight short-circuit (zero tokens)

The most extreme expression of the thesis. Before any model call happens, Lynkr can run a user-supplied shell precondition — pytest path/to/test.py, tsc --noEmit, lint --quiet, whatever proves the work is already done. If every command exits 0, Lynkr returns a synthetic "preflight satisfied" response without calling the LLM at all.

The use case sounds niche until you run a real agent loop: a CI-triggered "fix the failing test" request that arrives 90 seconds after the test was already fixed on another branch. An idempotent agent retry. A scheduled refactor job whose work was finished by a previous run. Today, every one of those wastes a full agentic loop — sometimes hundreds of thousands of tokens — to rediscover that the answer is "nothing to do."

The most expensive HTML output is the one you generate to explain a problem that no longer exists. Preflight is the layer that just doesn't.

Opt-in via preflight_commands in the request payload, gated on LYNKR_PREFLIGHT_ENABLED=true. Inspired by the CodexSaver routing patterns.

1. Smart tool selection (~50–70% token reduction on tool defs)

Claude Code sends every registered tool definition on every turn. Lynkr classifies the incoming request — is this a code edit, a search, a refactor, a "generate an HTML artifact" task? — and ships only the tools that classification actually needs. The model doesn't see the 40 it won't use.

For an "HTML artifact" task specifically, you don't need Bash, Glob, Git, the test runners, or MCP tools. You need read, write, and maybe web search. The savings compound across every turn of the loop.

2. Tool result compression

When the model calls pytest and gets back 40k tokens of output, Lynkr's tool-result compressor detects the pattern (test runner, linter, build, git diff) and compresses it before the model sees it on the next turn — usually keeping the failing assertions and dropping the redundant traceback frames. A tee cache holds the full version if anything downstream needs it.

In an agentic HTML-generation flow ("read the codebase, then produce an HTML report"), tool results are typically the largest single token category. Compressing them shrinks every subsequent turn.

3. History compression (Distill-style structural dedup)

Long sessions accumulate near-duplicate state: the model re-reads the same file four times, re-runs a slightly-different version of the same query, repeats its own reasoning. Lynkr's history compressor deduplicates older turns structurally while preserving the most recent N verbatim. The model still has the context; it doesn't pay for it twice.

4. Code Mode for MCP (~96% reduction)

If you've wired up MCP servers, this one's almost embarrassing. A typical MCP catalog — Linear, GitHub, Notion, Slack, a few internal ones — is 100+ tool definitions and tens of thousands of tokens every turn. Lynkr's Code Mode replaces all of them with four meta-tools (listResources, readResource, callTool, searchTools) and lets the model discover the rest at runtime. Same capability surface, ~96% fewer tokens spent on the catalog.

5. Risk-aware smart routing across model tiers

This is the one most directly relevant to the HTML debate. Generating a polished HTML artifact really does want a strong model. But the fifteen prior turns that gathered the data, ran searches, and figured out what to put in that artifact often don't.

Lynkr routes on two orthogonal axes: a 15-dimension complexity analysis (how hard is the task) and an independent risk score (how dangerous is it if the model gets this wrong). A request that touches auth/*, payments/*, migrations/*, .env, or .github/workflows, or that names high-risk concepts like authentication or deployment, is forced to the COMPLEX tier regardless of complexity score. Cheap tier for the cheap turns; frontier tier whenever the blast radius warrants it.

The four configurable tiers — TIER_SIMPLE, TIER_MEDIUM, TIER_COMPLEX, TIER_REASONING — let you map each to whatever provider:model pair makes sense. A greeting goes to a local Ollama model and costs zero. A file-read summarization goes to Haiku. The final "now write the HTML artifact" call goes to Opus or Sonnet, where it belongs.

Pay frontier prices for frontier work and high-risk work. Pay nothing for the rest.

Optionally, LYNKR_VISIBLE_ROUTING=true attaches a human-readable interaction block to each response — tier, provider, model, risk level, estimated savings — so the routing decision shows up inside Claude Code instead of buried in headers no one reads.

6. Semantic and prompt caching

Identical requests hit the prompt cache (SHA-256 keyed LRU, 5min TTL). Near-identical requests — same intent, different phrasing — hit the semantic cache (embedding cosine similarity at 0.95). For repeated "generate an HTML report of X" prompts within a working session, the second call can be effectively free.

7. Headroom sidecar (optional ML compression)

For users who really want to push it, there's an optional Python sidecar running LLMLingua-style transforms (Smart Crusher, Continuous Context Reduction, Tool Crusher, Cache Aligner, Rolling Window). Pure context-side compression — the model output doesn't change, the input it operates on gets smaller.

8. Token budget enforcement

Each model's context window is tracked. At 85% utilization, Lynkr automatically applies adaptive compression rather than letting the request blow past the window mid-generation. You don't get the 400-error-then-retry burn that costs you the input tokens twice.

What this looks like in practice

A concrete scenario: you ask Claude Code to "review this PR and produce an HTML report grouped by severity" — exactly Thariq's example.

Without a proxy layer, that's 8–12 model turns. Each turn re-sends the full system prompt, 50+ tool definitions, the growing conversation history, and accumulated tool results. The final turn produces ~2,000 tokens of HTML. Total input cost across the run: somewhere between 400k and 1.2M tokens depending on repo size. The HTML output is maybe 0.5% of the bill.

With Lynkr in the middle:

If the PR's findings are already merged or the failing check has self-resolved, preflight returns "satisfied" without a single model token spent.
Smart tool selection trims the per-turn tool-def overhead by ~60%.
Tool result compression keeps git diff and test output from dominating subsequent turns.
History compression dedupes the redundant intermediate state.
Risk-aware routing sends the search/read turns to a cheap tier; the final HTML generation — and anything touching protected paths — goes to your strongest model.
The semantic cache catches the second time you ask for the same review.

You keep the rich HTML output. You stop paying for the parts of the run that don't earn their tokens.

The takeaway

Thariq is right. HTML output really is better for the kinds of artifacts coding agents produce — and "we should use markdown because tokens are expensive" is an argument from a 32k-context-window world we no longer live in.

The critics are also right. HTML is more expensive than markdown to generate, the cost matters, and "use the richer format" without a story for cost control is a recommendation that benefits the seller more than the buyer.

What's missing from both sides of the timeline is the recognition that the output format is not the cost lever. The cost lever is everything upstream of the final response: which tools you send, how you compress prior turns, which tier you route to, what you cache, whether the work even needs to run at all.

Generate the HTML. Then put a smarter proxy in front of the model so you can afford to do it again tomorrow — and so that sometimes, when the answer is already on disk, you don't have to.

Lynkr is open source (Apache 2.0) and self-hosted: https://github.com/Fast-Editor/Lynkr. Install with npm i -g lynkr, point your coding tool's base URL at localhost:8080, and you're routing.

If you've measured your own HTML-vs-markdown token deltas in real workflows, I'd love to compare numbers — reply with your results.

Open Cowork : A Free, Alternative to claude cowork

Vishal VeeraReddy — Thu, 14 May 2026 23:05:00 +0000

How to set up a desktop AI agent on your own machine, route its model calls through a local proxy, and stop paying $20/month for chatbots that only talk.

There is a meaningful gap between AI tools that describe what to do and AI tools that do it. ChatGPT, Claude, Gemini, Perplexity — these are chat boxes. You ask, they answer in words, and you are still the one opening PowerPoint, dragging files around, summarizing the webpage by hand. The actual work hasn't moved.

The newer category — agentic desktop apps — closes that gap. Anthropic shipped Claude Cowork. The open-source community shipped Open Cowork, which does the same thing without locking you to one vendor. Pair it with Lynkr, a local Anthropic-compatible proxy, and you get a complete AI agent stack running on your own machine with no monthly subscription.

This article explains what Open Cowork is, what Lynkr is, why they pair well together, and how to set up the integration end to end.

Part I — What Is Open Cowork?

Open Cowork is an open-source desktop AI agent application for Windows and macOS. The project lives at github.com/OpenCoworkAI/open-cowork and ships as a one-click Electron installer — no terminal commands, no Python setup, no manual dependency wrangling. You download, install, and it opens as a normal desktop app.

The shape of the app is unusual compared to a chat tool. It is structured around three primary surfaces:

A chat window where you describe what you want
A workspace folder on your filesystem that the agent can read from and write to
A trace panel that shows the agent's reasoning and every tool it executes in real time

What makes it different from a chat tool is that the AI doesn't just respond. It executes. It generates real files, opens your browser, reads pages, and interacts with other applications on your computer.

Core capabilities

Document generation through the Skills system. Open Cowork ships with built-in workflows for producing PPTX, DOCX, XLSX, and PDF files. You ask for a 10-slide pitch deck and you get a real PowerPoint file with editable text, a chosen color scheme, and structured content. Not a markdown summary. Not a description of what the slides should contain. An actual file you can open in Keynote or PowerPoint.

MCP (Model Context Protocol) integration. Open Cowork connects to external services through MCP connectors — browser automation, Notion, custom internal apps. Once a connector is configured, the AI can drive those services as part of its workflow. Open a webpage, extract structured data, push it into a Notion database.

GUI automation (computer use). The app supports controlling other desktop applications by reading the screen and operating the mouse and keyboard. The recommended model for this surface is Gemini-3-Pro per their documentation, but any vision-capable model works.

Sandbox isolation via WSL2 and Lima. Every command the agent executes runs inside a virtual machine — WSL2 on Windows, Lima on macOS. The host filesystem is protected. Even if the AI is told to run something destructive, it physically cannot reach the parts of your computer you didn't authorize.

Remote control through Feishu and Slack. You can send tasks to Open Cowork from your phone via Slack messages or Feishu (the Chinese equivalent). The agent executes them on your desktop machine and reports back through the same channel.

Multimodal input. Drag images, PDFs, and other files directly into the chat input. The agent can read them as part of the conversation.

How it compares to Claude Cowork

Claude Cowork is Anthropic's first-party desktop agent app. Open Cowork is the community's open-source implementation of the same idea. The functional capabilities overlap substantially:

Feature	Claude Cowork	Open Cowork
MCP + Skills	✓	✓
Sandbox isolation	✓	✓
Remote control (Slack/Feishu)	✗	✓
GUI operation (computer use)	✗	✓
Model flexibility	Claude only	Claude, GPT, Gemini, DeepSeek, GLM, MiniMax, Kimi, Ollama, custom
Cost	Anthropic subscription	Free

The biggest practical difference is model flexibility. Claude Cowork only works with Claude, which means you pay Anthropic for every call. Open Cowork lets you plug in any provider, including a local model running on Ollama — which is where Lynkr comes in.

Configuration model

Open Cowork is configured through three primary mechanisms:

.env file in the project root. The Anthropic SDK respects standard environment variables: ANTHROPIC_AUTH_TOKEN, ANTHROPIC_BASE_URL, CLAUDE_MODEL. This is the simplest way to wire up a custom backend.

In-app Settings panel. The GUI has a full API Configuration page with provider presets (Anthropic, OpenAI, OpenRouter, Gemini, Ollama) and a custom-provider option with editable base URL, selectable protocol (anthropic / openai / gemini), and a free-text API key field.

Workspace folder selection. On first launch, you pick a folder on your filesystem that the agent will read from and write to. Everything happens inside that folder. The Lima or WSL2 VM mounts this folder so the agent can operate on it without ever touching the rest of your disk.

Part II — What Is Lynkr?

Lynkr is a Node.js proxy that exposes a unified Anthropic-compatible API surface at /v1/messages while internally routing each request to whichever provider and model is most appropriate.

The core capabilities relevant to this integration:

Anthropic and OpenAI API compatibility. Lynkr accepts requests in either format on the same port. Tools using the Anthropic SDK and tools using the OpenAI SDK can hit the same instance.
Complexity-based routing. Lynkr analyzes each incoming request, scores it for complexity, and routes simple requests to a local Ollama model and complex requests to Claude Opus or Sonnet.
Per-request model override. Clients can specify an exact model and Lynkr will honor it, otherwise it picks based on the configured tier.
Token budget enforcement. Lynkr tracks cumulative spend per project and can throttle or downshift when budgets are exceeded.
Telemetry dashboard. Every request is logged with provider, latency, tokens, and cost. The dashboard at http://localhost:8081/dashboard shows live throughput, request volume by provider, and cumulative spend.

For Open Cowork specifically, three of these matter most: complexity routing (most agent calls are short summarization or tool-result handling, which local Ollama handles fine), telemetry (see exactly how much each session costs), and API compatibility (Open Cowork's Anthropic SDK calls flow through Lynkr without any code change).

Part III — Why Pair Them?

A typical Open Cowork session involves dozens of model calls per task. The agent plans, then makes a tool call, then summarizes the tool result, then plans the next step, then makes another tool call, and so on. Each round trip is a separate API call. A single "organize my downloads folder" task can fire fifteen to twenty model calls before finishing.

If every one of those calls hits Claude Opus, you are looking at roughly $0.10-$0.30 per task. A working session of fifty tasks runs $5-$15. Continuous daily use is hundreds of dollars per month. For most people, this defeats the entire point of using a "free" open-source app.

Most of those calls don't need a frontier model. Summarizing a tool result is a 200-token job. Picking the next file to read is a 100-token job. Deciding whether to continue or stop is a 50-token job. These are exactly the kinds of tasks where a local model running on Ollama produces identical-quality output at zero cost.

Routing Open Cowork's calls through Lynkr changes the economics:

Trivial agent calls (tool result handling, status checks, simple reasoning) → local Ollama → $0
Document generation and planning → cloud Sonnet → ~$0.05 per call
GUI automation and computer use → cloud Opus or Gemini-3-Pro → $0.30 per call

In practice this comes out to a 10-20x reduction in cost per session with no loss of fidelity on the operations that actually need a capable model.

The second benefit is privacy. The calls routed to local Ollama never leave your machine. Files you reference, prompts you write, and intermediate reasoning all stay on your laptop. For users working with sensitive data, internal company information, or anything under compliance constraints, this is the difference between Open Cowork being usable and being a non-starter.

The third benefit is model choice. Lynkr can route different request shapes to different providers — a Gemini call for vision tasks, a Sonnet call for planning, a local Qwen call for short summarization. Open Cowork sees one base URL and one model name. Lynkr does the dispatch.

Part IV — Setup Guide

Prerequisites

Tool	Purpose
Node.js 22+	Run Open Cowork and Lynkr
Lima (macOS) or WSL2 (Windows)	Sandbox isolation
Ollama 0.4+	Local model inference
Lynkr	The proxy

Pull a coding-aware model into Ollama for the simple-tier routing:

ollama pull qwen2.5-coder:7b
# optional: a larger model for moderate-complexity calls
ollama pull minimax-m2.5:cloud

Step 1 — Start Lynkr

From your Lynkr installation directory:

node bin/cli.js start --port 8081

Lynkr starts, auto-discovers your local Ollama instance, and is ready to accept requests at http://localhost:8081. Verify it's running:

curl http://localhost:8081/health
# {"status":"ok"}

Open the dashboard at http://localhost:8081/dashboard in your browser and leave it visible — you'll use it later to confirm routing is working.

Step 2 — Clone and install Open Cowork

git clone https://github.com/OpenCoworkAI/open-cowork.git
cd open-cowork
npm install

The install takes about five minutes. It downloads the bundled Node binaries, builds the WSL agent (Windows) or Lima agent (macOS), bundles the MCP servers, and rebuilds better-sqlite3 against Electron's ABI. Don't be alarmed by the number of packages — Electron apps are heavy.

Step 3 — Configure the Lynkr backend

Create .env in the Open Cowork root:

# Any non-empty string. Lynkr doesn't validate the key for local providers.
ANTHROPIC_AUTH_TOKEN=local

# Point the Anthropic SDK at Lynkr instead of api.anthropic.com.
ANTHROPIC_BASE_URL=http://localhost:8081

# The model name Open Cowork sends. Lynkr's router may override this
# based on request complexity — leaving it as a cloud model name is fine.
CLAUDE_MODEL=claude-sonnet-4-6

That's the entire integration. Open Cowork uses the Anthropic SDK under the hood, the SDK respects ANTHROPIC_BASE_URL, and every call now flows through Lynkr before reaching any actual provider.

Step 4 — Launch Open Cowork

npm run dev

The first launch takes 60-90 seconds because vite is starting, the sandbox agents are being built, and Electron is opening for the first time. When the desktop window appears, you'll be prompted to pick a workspace folder. Create one:

mkdir ~/cowork-workspace

Point Open Cowork at ~/cowork-workspace. This is now the only directory the agent can read from and write to.

Step 5 — Verify the integration

Before sending your first message, make sure the Lynkr dashboard is open in another window. Then in Open Cowork, send a simple test prompt:

Read any text file in my workspace and tell me what's inside.

Watch the Lynkr dashboard. You should see:

Request count incrementing in real time
A mix of providers in the breakdown (likely ollama for the simple turns, anthropic for the planning turns)
Latency distribution showing local Ollama calls completing in 1-3s and cloud calls in 5-15s

If nothing shows up on the dashboard, Open Cowork is hitting Anthropic directly — the SDK in their agent runtime bypassed our env var. This is uncommon but possible. The fix is a one-line change to where the SDK client is constructed in their codebase to honor ANTHROPIC_BASE_URL.

Step 6 — Try a real task

Drop a file into your workspace folder and send a task that exercises the full agent loop:

Organize the files in this folder by type. Move images into an "images" subfolder, documents into "docs", and code into "code". Tell me what you moved.

You'll see the trace panel on the right populate with each tool call: list_files, read_file, move_file, and so on. Every one of those tool result summaries fires a model call. Most of them should route to local Ollama via Lynkr. The high-level plan and final summary may route to Sonnet.

Part V — Advanced Configuration

Routing tiers tuned for an agent loop

The default Lynkr complexity scoring works well for chat workloads, but agent loops have a different shape. The bulk of calls are tool-result handling and planning between tool calls, both of which are short. You probably want to lower the threshold that pushes calls to Sonnet:

{
  "routing": {
    "tiers": {
      "SIMPLE": {
        "provider": "ollama",
        "model": "qwen2.5-coder:7b"
      },
      "MODERATE": {
        "provider": "anthropic",
        "model": "claude-sonnet-4-6"
      },
      "COMPLEX": {
        "provider": "anthropic",
        "model": "claude-opus-4-7"
      }
    },
    "complexity": {
      "thresholds": {
        "simple": 25,
        "complex": 60
      }
    }
  }
}

Lower thresholds mean more calls go to Ollama. Tune until you see a routing mix of roughly 70% local, 25% Sonnet, 5% Opus on the dashboard.

Vision-capable routing for GUI tasks

Open Cowork's computer-use feature needs a model that can read screenshots. Local Ollama coding models don't support vision. Configure Lynkr to detect image content in requests and route them to Gemini-3-Pro or Claude Sonnet:

{
  "routing": {
    "vision": {
      "provider": "google",
      "model": "gemini-3.1-pro-preview"
    }
  }
}

This keeps cost low on text-only calls while routing the heavy GUI-interpretation calls to a model that can actually see the screen.

Per-session budget caps

If you want to prevent any single Open Cowork session from going over a spend ceiling, set a budget env var:

LYNKR_BUDGET_USD=2.00

Lynkr will refuse new requests once the limit is hit, preventing a runaway loop on a malformed prompt from burning through a hundred dollars overnight.

Multiple workspaces, same backend

If you want different Open Cowork workspaces (work, personal, side project) to use different routing policies, run multiple Lynkr instances on different ports and point each Open Cowork install at the right one. The Lynkr CLI supports --config <path> to load a workspace-specific routing config.

Part VI — Troubleshooting

"I sent a message but nothing showed up on the Lynkr dashboard"

The Open Cowork agent runtime (the pi-coding-agent library it depends on) is not your standard Anthropic SDK usage. It may construct its HTTP client in a way that ignores ANTHROPIC_BASE_URL. To check, look at network traffic during a session — if requests are going to api.anthropic.com instead of localhost:8081, the env var is being bypassed.

The fix is small but requires a code change. Find where the Anthropic client is instantiated in Open Cowork's source (likely under src/main/claude/ based on the file structure) and confirm it reads process.env.ANTHROPIC_BASE_URL when constructing the client. If it doesn't, add it.

"The agent says it can't read my PDF"

Three likely causes, in order of probability:

Lynkr routed the request to a local Ollama model that doesn't support PDF content blocks. PDF support is a Claude-specific feature. If your routing tier sent the request to Qwen or MiniMax, the PDF was silently dropped. Force a Claude route by setting CLAUDE_MODEL=claude-sonnet-4-6 more aggressively or saying "use Sonnet" in your prompt.
The Lima sandbox doesn't have a PDF parser installed. If you put the PDF in your workspace and asked the agent to read it via filesystem tools, it tried cat report.pdf, got binary garbage, then tried pdftotext and got "command not found." Install poppler-utils inside the Lima VM:

   limactl shell default
   sudo apt-get install -y poppler-utils

The PDF was dragged into chat but exceeded the multimodal API size limits. Anthropic caps PDFs at 32MB and about 100 pages. Move the file into your workspace folder instead and reference it by name.

"Streaming cuts off mid-response"

Usually means Lynkr routed to a model with a smaller context window than the conversation needed. The fix is either to use a model with more context (Opus or Sonnet) for that session, or to start a new conversation so the history compresses.

"Lima won't start"

On macOS, Lima needs to bootstrap once before Open Cowork can use it:

limactl start default

After that initial start, Open Cowork manages it automatically.

Part VII — When This Stack Pays Off

Open Cowork plus Lynkr makes sense when you fit roughly this profile:

You do enough AI-driven work that subscription costs feel like a real expense. You want files generated, not files described. You work with information that should stay on your machine. You don't want to bet your workflow on one vendor's pricing or feature roadmap. And you have a laptop capable enough to run a local model — anything M-series or a recent Intel chip with 16GB+ of RAM will do fine.

If you fit two or more of those, the math works. The setup is a one-time investment of maybe two hours. After that, the agent runs itself, the proxy handles routing transparently, and you stop seeing line items for AI tools on your monthly statement.

If you don't fit that profile — if you only use AI occasionally, if cost isn't a concern, if you don't care about privacy — then a managed product like Claude Cowork is genuinely simpler. There's no shame in paying for convenience. But for the people who do fit, this stack is one of the few open-source combinations where the open-source version is better than the commercial alternative, not just cheaper.

Conclusion

Open Cowork closes the gap between AI tools that talk and AI tools that work. It generates real files, drives your browser, connects to other apps, and runs everything inside a sandbox so it can't break your machine.

Lynkr makes Open Cowork affordable. By routing the boring 70% of calls to a local model and reserving the cloud models for the calls that actually need them, the per-session cost drops from dollars to cents.

The integration is two lines of .env configuration. The whole stack runs on your own machine. There's no subscription, no telemetry going to a vendor, no monthly bill.

If you've been waiting for the open-source AI agent ecosystem to grow up, this is it.

Open Cowork: github.com/OpenCoworkAI/open-cowork

Lynkr: https://github.com/Fast-Editor/Lynkr

Ollama: ollama.com

If you set this up and run into something I didn't cover here, drop a note in the comments. I'm collecting failure modes for a follow-up post.

How to use Vercel's Deepsec with ollama

Vishal VeeraReddy — Thu, 14 May 2026 01:38:46 +0000

How to run continuous, AI-powered security audits on your codebase — routed through a local proxy that picks the cheapest viable model for each file.

Most security scanners feel like spam filters from 2005. They flag every eval(), every string concatenation that looks vaguely SQL-ish, and every hard-coded constant longer than ten characters. The signal-to-noise ratio is so low that teams either stop running them or learn to ignore the output entirely.

The newer generation of scanners uses LLMs to read the code the way a human reviewer would — understanding intent before flagging pattern. Deepsec, from Vercel, is one of the most usable tools in this category. The problem is that running it across a real codebase, file by file, with a frontier model, gets expensive quickly.

This article explains what deepsec is, what it actually catches, and how to point its AI calls at Lynkr — a local Anthropic-compatible proxy — to route simple files to a local Ollama model and reserve the expensive cloud model for the cases that genuinely need it.

Part I — What Is Deepsec?

Deepsec is an AI security scanner published by Vercel as an npm package. The shape of it is unusual compared to other security tools: it is not a service, not a CI bot, not a SaaS dashboard. It is a workspace-style CLI you install into a .deepsec/ directory inside your repo, configure with project context, and run on demand.

The output is a folder of findings, organized by severity, that you read like a code review.

The pipeline

Deepsec runs in stages, and each stage has a different cost profile:

1. Scan (free). A pure regex pass over your source tree. It identifies files that contain patterns potentially worth deeper analysis — auth flows, database queries, request handlers, crypto operations, environment variable use, file system access. This stage is cheap, fast, and runs on every file. It is the funnel.

2. Process (paid, AI). The files surfaced by scan are read by an LLM (Claude Opus by default, ~$0.30 per file). The model receives:

The full file contents
The project context you supplied in INFO.md (auth primitives, threat model, false-positive paths)
Custom matchers you have written for this codebase
The deepsec built-in matcher prompts

The model produces findings: severity, location, explanation, recommended fix.

3. Revalidate (paid, AI). A second AI pass over each finding to confirm it is real. This step alone dramatically reduces false-positive rates because it forces the model to defend each conclusion against the surrounding context. Without revalidation, AI scanners hallucinate findings about as often as they find real bugs. With it, the signal becomes usable.

4. Triage (paid, AI). Findings are clustered, deduplicated, and ranked. The output is a folder of markdown files under findings/ organized by severity: CRITICAL, HIGH, HIGH_BUG, MEDIUM, LOW, BUG.

5. Export. Findings get written out in the format you want — markdown directory, JSON for CI, or a single report file.

What it actually catches

Deepsec is built around the kinds of issues that traditional SAST tools miss because they require context, not just pattern matching:

Auth bypass via missing guard. A new endpoint that forgot to call the auth middleware, in a codebase where 99% of endpoints do.
IDOR. An endpoint that accepts a resource ID and queries the database by ID but never checks ownership.
Path traversal in user-provided filenames. Not "anything that calls fs.readFile" — only the cases where the filename came from a request and was not validated.
Token leakage in logs. A logger.info call that includes the entire request body, where the request body sometimes contains a session token.
Unsafe deserialization. A JSON.parse of untrusted input that gets passed to a function expecting a specific shape, without validation.
Race conditions in auth flows. Double-spend patterns, TOCTOU bugs in permission checks, session fixation.
SSRF in URL fetchers. A fetch(url) where url came from user input and the code does not block private IP ranges or localhost.

What makes it work is the project context. When you tell deepsec "auth in this codebase is enforced by requireUser() middleware, exported from src/auth/middleware.ts" — it will flag every request handler that doesn't call it. A regex scanner cannot do this. A generic LLM scanner without project context flags too many false positives to be useful.

The configuration model

Deepsec is configured through three files inside .deepsec/:

deepsec.config.ts — the project list. Each entry points at a codebase to scan (path relative to .deepsec/). One workspace can scan multiple repos.

import { defineConfig } from "deepsec/config";

export default defineConfig({
  projects: [
    { id: "claude-code", root: ".." },
    { id: "api-gateway", root: "../../api-gateway" },
  ],
});

data/<project-id>/INFO.md — the hand-curated project context. This is the most important file in the entire setup. The scanner injects it into every AI batch, so verbose context dilutes signal. Target 50-100 lines covering:

What the codebase does (one paragraph)
The auth shape (3-5 most important primitives by name)
The threat model (2-4 sentences, ranked by impact)
Project-specific patterns to flag (3-5 unique patterns)
Known false-positives (paths or patterns that look risky but are intentional)

.env.local — the API token. Anthropic key, OpenAI key, or Vercel AI Gateway token. If you have Claude Code or Codex logged in locally, deepsec can reuse that subscription and skip the token entirely for non-sandbox stages.

What deepsec is not

It is worth being explicit about the scope.

It is not a SAST scanner replacement. It will miss issues that require deep dataflow analysis or whole-program reasoning. Use it alongside Semgrep / CodeQL, not instead of them.
It is not a runtime tool. It does not watch traffic, replay requests, or instrument your application. It reads source code.
It is not continuous by default. You run it manually or on schedule via CI. The findings are a snapshot, not a stream.
It is not free at scale. A repository of 1,000 source files at $0.30 each is $300 per full run. You will want incremental modes (only scan changed files) and routing tiers in production.

That last point is exactly where Lynkr comes in.

Part II — A Quick Recap on Lynkr

Lynkr is a Node.js proxy that exposes a unified Anthropic-compatible API surface (/v1/messages) while internally routing each request to whichever provider and model is most appropriate.

The core capabilities that matter for this article:

OpenAI-API-compatible alias. Lynkr also speaks OpenAI's API format on the same port, so tools using either SDK can hit the same instance.
Complexity-based routing. Lynkr scores each incoming request for complexity and routes simple requests to a local Ollama model, complex requests to Claude Opus or Sonnet.
Per-request model override. Clients can specify a model explicitly (e.g. claude-opus-4-7) and Lynkr honors it, otherwise picking from the configured tier.
Token budget enforcement. Lynkr tracks cumulative spend per project and can throttle or downshift when budgets are exceeded.
Telemetry and tracing. Every request is logged with provider, latency, tokens, and cost. The dashboard at localhost:8081/dashboard shows live throughput.

For deepsec specifically, two of these matter most: complexity routing (route boring files to a local model, expensive files to a cloud model) and telemetry (see exactly how much each scan costs and where the time goes).

Part III — Why Pair Them?

Deepsec's economics are simple but unforgiving: cost scales linearly with file count multiplied by model price. A repository of 1,000 source files, scanned with Opus at default settings, is roughly $300 per full pass. Running it nightly is $9,000/month before revalidation. Revalidation roughly doubles that.

Most of those files don't need a frontier model. A 30-line CSS file. A static config object. A pure-utility module that does string formatting. A test file. These get the same expensive Opus treatment as the auth middleware, even though a smaller model would reach the same "nothing here" verdict in a tenth the time and a hundredth the cost.

Routing deepsec's AI calls through Lynkr changes the math. Lynkr analyzes each request, looks at the file content and project context being passed to the model, and decides:

Trivially safe file (CSS, static config, test fixture, generated code) → local Ollama (qwen2.5-coder:7b) → $0
Application code that touches request handling or storage → cloud Sonnet → ~$0.05/file
Auth middleware, payment processing, crypto, or files with high risk signals → cloud Opus → $0.30/file

A typical codebase has the trivial-to-critical ratio at roughly 70/25/5. The blended cost drops from $300 to about $20 for a full scan — a 15× reduction with no loss of fidelity on the files that actually matter.

There is a secondary benefit: privacy. The files going to local Ollama never leave your machine. For codebases under compliance constraints (HIPAA, SOC2 with data residency requirements, government work), this is the difference between deepsec being usable and being a non-starter.

Part IV — Setup Guide

Prerequisites

Tool	Purpose
Node.js 20+	Run deepsec and Lynkr
pnpm	Install deepsec
Ollama 0.4+	Local model inference
Lynkr	The proxy (we built this in the previous article)

Pull at least one coding-aware Ollama model. For security scanning, models trained on code work best:

ollama pull qwen2.5-coder:7b
# optional: a bigger fallback for complex files
ollama pull qwen2.5-coder:32b

Step 1 — Install deepsec into your repo

From the root of the repository you want to scan:

mkdir .deepsec && cd .deepsec
pnpm init
pnpm add deepsec

Create deepsec.config.ts:

import { defineConfig } from "deepsec/config";

export default defineConfig({
  projects: [
    { id: "myapp", root: ".." },
  ],
});

Then scaffold the project data folder:

pnpm deepsec init-project ..

This creates data/myapp/INFO.md and data/myapp/SETUP.md.

Step 2 — Fill in INFO.md

Open data/myapp/INFO.md in your coding agent (Claude Code, Cursor, etc.) and have it follow data/myapp/SETUP.md to populate the context. The setup prompt is good — it tells the agent exactly what to read and what to write.

If you are doing this by hand, the rubric is:

# myapp

## What this codebase does
Next.js SaaS application. Multi-tenant. Customers sign up, integrate
their Stripe account, and use the dashboard to monitor subscription
churn. Routes under `/app/*` are authenticated; `/marketing/*` is
public.

## Auth shape
- `requireUser(req)` — server-side auth check, throws `UnauthorizedError`
- `getCurrentUser()` — client-side hook
- `withTenantScope(query, tenantId)` — every DB query MUST be wrapped
- Sessions stored in HTTP-only `__session` cookie, signed with HMAC

## Threat model
Highest impact: cross-tenant data leak via missing `withTenantScope`
or IDOR in resource endpoints. Second: Stripe webhook spoofing.
Third: token leakage via logs or error pages.

## Project-specific patterns to flag
- Any DB query under `src/db/queries/` that doesn't call `withTenantScope`
- Any handler in `src/app/api/` that doesn't call `requireUser` first
- Stripe webhook handlers that don't verify `stripe-signature` header
- `console.log` or `logger.info` calls passing entire `req` or `res`

## Known false-positives
- `src/app/api/public/*` — intentionally unauthenticated
- `src/db/queries/migrations/*` — runs without tenant scope by design
- `__tests__/fixtures/*` — fake tokens, not real secrets

The quality of your INFO.md determines the quality of your scan. Spend an hour on this. It will pay back the time within the first run.

Step 3 — Add the Lynkr base URL

This is the integration point. Deepsec uses the Anthropic SDK under the hood. The Anthropic SDK respects the ANTHROPIC_BASE_URL environment variable. Point it at Lynkr.

In .deepsec/.env.local:

# Any non-empty string — Lynkr doesn't validate for local providers
ANTHROPIC_API_KEY=local

# Route all Anthropic calls through Lynkr instead of api.anthropic.com
ANTHROPIC_BASE_URL=http://localhost:8081

If you are running Lynkr on a different host (a shared dev box, a homelab server), substitute the appropriate address.

Step 4 — Configure Lynkr's routing tiers

In your Lynkr config (typically ~/.lynkr/config.json or wherever you store it), define how to route deepsec's traffic. The key configuration is the complexity threshold and the tier mapping:

{
  "routing": {
    "tiers": {
      "SIMPLE": {
        "provider": "ollama",
        "model": "qwen2.5-coder:7b"
      },
      "MODERATE": {
        "provider": "anthropic",
        "model": "claude-sonnet-4-6"
      },
      "COMPLEX": {
        "provider": "anthropic",
        "model": "claude-opus-4-7"
      }
    },
    "complexity": {
      "thresholds": {
        "simple": 30,
        "complex": 70
      }
    }
  }
}

The defaults work fine for most cases, but for security scanning you may want to lower the complex threshold — better to over-route to Opus on files that touch auth than under-route and miss something.

Step 5 — Run a scan

From .deepsec/:

# Free regex pass — surfaces files worth deeper analysis
pnpm deepsec scan

# AI processing — routed through Lynkr
pnpm deepsec process --concurrency 5

# AI revalidation — cuts false positives
pnpm deepsec revalidate --concurrency 5

# Export findings as a folder of markdown files
pnpm deepsec export --format md-dir --out ./findings

The first run will take longer because nothing is cached. Subsequent runs are incremental — only changed files are reprocessed.

Step 6 — Inspect findings

Open .deepsec/findings/ and you will see a directory per severity:

findings/
├── CRITICAL/
│   └── 001-cross-tenant-leak-in-billing-endpoint.md
├── HIGH/
│   ├── 002-missing-stripe-signature-verification.md
│   └── 003-idor-in-user-settings-handler.md
├── MEDIUM/
│   └── 004-error-message-leaks-internal-path.md
└── LOW/
    └── 005-noisy-logging-includes-user-agent.md

Each finding is a markdown file with the location, severity, explanation, code excerpt, and recommended fix. They are written to be readable as a code review — drop them into a PR description, paste them into Linear, hand them to the engineer responsible.

Part V — Verifying the Routing

After running a scan, check the Lynkr dashboard at http://localhost:8081/dashboard. You should see:

A spike in request volume during the scan
A mix of providers (Ollama vs. Anthropic) in the request breakdown
Latency distribution showing local Ollama calls completing in 1-3s and cloud calls in 5-15s
Cumulative cost tracked per request

If everything is routing to Anthropic, your complexity scoring is too aggressive. If everything is routing to Ollama, you have a config error and the scan results will be useless — security analysis genuinely needs a capable model on the high-risk files.

A healthy distribution for a real codebase looks like:

60-75% local (qwen2.5-coder:7b)
20-30% cloud Sonnet
5-10% cloud Opus

Adjust thresholds until you see numbers in that range.

Part VI — Advanced Patterns

CI integration with budget caps

Run deepsec in your CI pipeline only on files changed in the PR, with Lynkr enforcing a hard budget ceiling per run. Add to your GitHub Actions workflow:

- name: Security scan changed files
  env:
    ANTHROPIC_API_KEY: ${{ secrets.LYNKR_KEY }}
    ANTHROPIC_BASE_URL: ${{ vars.LYNKR_URL }}
    DEEPSEC_BUDGET_USD: "2.00"
  run: |
    cd .deepsec
    git diff --name-only origin/main...HEAD > /tmp/changed
    pnpm deepsec scan --files-from /tmp/changed
    pnpm deepsec process --concurrency 3
    pnpm deepsec export --format json --out ./findings.json

Lynkr will refuse new requests once $2.00 is spent on that scan, preventing a runaway CI cost on a 200-file PR.

Custom matchers in INFO.md

The most valuable additions to deepsec are project-specific matchers — things only your codebase knows. A few real examples I have seen pay off immediately:

"Any function that accepts a customerId parameter from a request must also accept and validate tenantId. If only customerId is checked, that is a cross-tenant access bug."
"process.env.DEBUG_AUTH_BYPASS is a dev-only flag. Any code path gated only by this flag, with no other auth check, is critical regardless of where it appears."
"All Redis keys must include the tenant prefix. A redis.get(\user:${id}) without tenant prefix is a tenant-scoping bug."

These patterns live in the ## Project-specific patterns to flag section of INFO.md. Add new ones as you discover them — each one prevents an entire class of bug from ever shipping.

Scheduled deep scans + on-demand fast scans

Run a different cadence for different scan types:

Trigger	Scope	Routing	Cost
Per PR	Changed files only	Ollama-heavy via Lynkr	~$0.10
Nightly	Full repo, scan + process	Mixed	~$10
Weekly	Full repo, scan + process + revalidate	Mixed	~$20
Pre-release	Full repo with strict revalidation	Sonnet-heavy via Lynkr	~$50

The Lynkr dashboard's cost tracking makes it easy to verify these envelopes are being hit.

Part VII — When Deepsec Catches Something Real

A worked example from a real codebase, anonymized.

The codebase had a billing portal at /app/billing that let customers download invoices as PDFs. The handler took an invoiceId query parameter, looked up the invoice in the database, and streamed the PDF.

export async function GET(req: NextRequest) {
  const user = await requireUser(req);
  const invoiceId = req.nextUrl.searchParams.get("id");
  const invoice = await db.invoices.findUnique({ where: { id: invoiceId } });
  return new Response(invoice.pdfBytes);
}

A regex scanner would not flag this. The auth check is there. The query is parameterized. The output is binary data. By every shallow signal, this is fine code.

Deepsec, with the INFO.md context that every DB query must be wrapped in withTenantScope, flagged it as CRITICAL:

Cross-tenant IDOR in billing PDF download

findUnique({ where: { id: invoiceId } }) looks up an invoice by ID
with no tenant scoping. Any authenticated user can request any invoice
ID and receive the PDF, including invoices belonging to other tenants.

Fix:
const invoice = await db.invoices.findFirst({
  where: withTenantScope({ id: invoiceId }, user.tenantId)
});
if (!invoice) return new Response("Not found", { status: 404 });

That single finding paid for the entire scan budget for the year. This is the kind of bug that pattern-matching tools cannot find because it requires understanding what auth means in this codebase — and that understanding lives in INFO.md.

Part VIII — Limitations to Know Going In

A few things will trip you up if you treat deepsec as a complete solution.

It does not understand framework conventions you have not documented. If your Next.js app has unusual middleware composition that grants auth on a route prefix, deepsec doesn't know that. You will get false positives until you write it into INFO.md.

Generated code wastes tokens. Anything under dist/, .next/, build/, or autogenerated GraphQL types should be in your .deepsecignore or excluded via the scan config. Lynkr's complexity routing will route this to local Ollama, but you are still paying inference latency.

Revalidation is not a magic bullet. It catches the obvious false positives, not the subtle ones. You will still need to triage by hand. Budget 1-2 hours of human review per 100 findings.

Local Ollama models miss things. This is the trade-off you accept when routing aggressively to local inference. For most files this is fine. For files in the ## Project-specific patterns to flag paths, force them to cloud routing explicitly via Lynkr's per-path overrides.

Conclusion

Deepsec is the first AI security scanner I have run on a real codebase where the output was actually worth reading. The findings are specific, the language is direct, and the false-positive rate after revalidation is low enough that engineers stop ignoring them.

Pairing it with Lynkr solves the only real objection — cost. With local-first routing for the 70% of files that don't need a frontier model, scanning becomes cheap enough to run on every PR, nightly across the whole repo, and weekly with strict revalidation, all within a budget that doesn't require a meeting to approve.

The setup takes maybe two hours end to end: install deepsec, write a good INFO.md, install Lynkr, point the base URL, run the first scan. After that it runs itself.

Worth the afternoon.

Deepsec: https://github.com/vercel-labs/deepsec

Lynkr: https://github.com/Fast-Editor/Lynkr

Ollama: ollama.com

If you run security scans on your codebase already and have war stories — good or bad — drop them in the comments. I am collecting patterns for a follow-up post on writing custom matchers.

Open-Design : Run a Local AI Design Studio for Free

Vishal VeeraReddy — Tue, 12 May 2026 05:59:09 +0000

A Claude Design Alternative

Open-Design: Run a Local AI Design Studio for Free

How to wire up a self-hosted design generation stack that rivals Figma's AI features — without sending your work to a third-party cloud.

There is a quiet corner of the open-source world where two tools have been evolving in parallel, each solving a different half of the same problem. Open-design wants to be the AI-native design canvas. Lynkr wants to be the intelligent router that connects any AI model to any client. Together, they form a surprisingly capable stack: a browser-based design studio powered entirely by models you run yourself.

This article explains what each tool does, why they pair well, and walks you through the exact steps to get both running — from a blank machine to a working design session in under twenty minutes.

Part I — What Is Open-Design?

Open-design (github: nexu-io/open-design) is a web application that lets you describe what you want to build in plain English and receive a live, editable HTML design in return. Think of it as a Figma alternative where the "draw" action is replaced by a conversation.

The core idea

You open a project, type "Create a SaaS pricing page with three tiers, a purple gradient header, and a FAQ section below the fold," and the assistant responds with a fully rendered HTML page sitting in a split pane next to the chat. You can iterate on it — "make the CTA button larger and change the font to Inter" — and the design updates in place.

What makes this different from just asking ChatGPT for HTML and copying the output into a file is the structure open-design wraps around the conversation:

Project workspaces — each project has its own conversation history, file panel, and design system binding. Your palette and typography rules travel with the project.
Design files panel — generated HTML is not dropped in the chat as a code block. It is parsed, saved as a project file, and opened as a rendered tab in a file viewer with an iframe preview.
Skills — prebuilt workflow templates (landing page, deck, dashboard, prototype) that inject opinionated system prompts so the model follows proven patterns rather than making it up.
Design systems — you can attach a DESIGN.md that defines your color tokens, spacing scale, and component rules. The model reads this as authoritative and binds every artifact to it.
Live artifacts — a second artifact type for data-driven outputs (dashboards, reports) that can be refreshed on a schedule by re-running the generation with updated data.

Two execution modes

Open-design ships with two ways to run the AI backend.

Daemon mode spins up a local CLI agent (Codex, Claude Code, Gemini CLI) on your machine. The daemon manages the agent process, streams its output, and interprets the tool calls it makes — reading files, writing artifacts, running shell commands. This is the "full agentic" mode where the AI can explore your file system, install dependencies, and produce multi-file outputs.

API mode (also called BYOK — Bring Your Own Key) skips the local agent entirely. You point open-design at any OpenAI-compatible or Anthropic-compatible endpoint, hand it an API key, and it sends requests directly. The AI cannot use tools in this mode; it can only output <artifact> blocks, which open-design parses and routes to the Design Files panel. This is the simpler, faster mode — and it is exactly the mode Lynkr plugs into.

The artifact contract

Both modes share one key convention: the <artifact> tag.

When the AI wants to produce a design, it wraps its HTML inside:

<artifact identifier="landing-page.html" type="text/html" title="Landing Page">
<!DOCTYPE html>
<html lang="en">
  ...
</html>
</artifact>

Open-design's streaming parser watches the incoming text for this tag. The moment it sees <artifact, it opens a new file entry in the Design panel, streams the inner HTML into an iframe as the model generates it, and — when the closing </artifact> arrives — saves the file to the project folder and opens it as a tab. The user sees a live preview build up line by line, like watching someone draw.

The chat view simultaneously strips the artifact out (showing only any prose the model wrote around it) so the conversation stays clean.

Part II — What Is Lynkr?

Lynkr is an AI proxy server that presents a unified Anthropic-compatible API surface (/v1/messages) while internally routing requests to whichever provider and model makes sense for the task.

The problem it solves

If you run multiple AI providers — Ollama locally, Anthropic in the cloud, maybe Azure OpenAI for enterprise workloads — every client that talks to one of them is tightly coupled to that provider's API format. Swap the provider, update every client.

Lynkr breaks that coupling. Clients always speak Anthropic's message format. Lynkr translates on the fly to whatever the target provider expects and translates the response back.

What Lynkr actually does

Beyond simple translation, Lynkr runs an agent loop:

It receives a message request.
It forwards the request to the target model (Ollama, Anthropic, Azure, OpenRouter).
If the model responds with tool calls, Lynkr executes them server-side (web search, file reads, subtask delegation) and feeds the results back to the model.
The loop repeats until the model produces a final text answer or a terminal condition is hit.
The final response is returned in Anthropic SSE format.

This means clients that speak Anthropic's streaming protocol — including open-design in API mode — get a fully resolved, agentic response even when the underlying model is a local Ollama instance that has no native tool support.

Routing intelligence

Lynkr analyzes each incoming request for complexity (simple lookup vs. multi-step reasoning vs. heavy code generation) and routes to the appropriate tier:

Simple / fast → local Ollama model (zero cloud cost, low latency)
Complex / reasoning → cloud model (Anthropic, OpenAI, Azure)
Agent tasks → multi-step loop with tool execution

All of this is transparent to the client. Open-design sends one request; Lynkr decides where it goes.

Other capabilities

Token budget enforcement — Lynkr tracks token usage and compresses conversation history before it would overflow the context window, preserving the most recent and most important turns.
Headroom sidecar — a small Python service that monitors GPU/CPU memory and tells Lynkr how much headroom is available for local inference, enabling dynamic load shedding when the machine is under pressure.
Session memory — vector-search-backed conversation memory that lets the model recall context from previous turns in long projects.
Telemetry and tracing — structured logs, latency metrics, and per-provider cost tracking.
Dashboard — a web UI at /dashboard that shows live request throughput, provider health, and routing decisions.

Part III — Why They Pair Well

Open-design in API mode needs an endpoint that:

Speaks Anthropic's /v1/messages format with SSE streaming.
Understands the design system context injected in the system prompt.
Produces clean <artifact> HTML blocks without hallucinating tool calls or emitting ANSI escape codes into the CSS.
Routes to whatever model the user has available — local or cloud.

Lynkr provides all four. You point open-design at http://localhost:8081, select "Anthropic" as the protocol, set any string as the API key, and Lynkr handles the rest.

The integration is also meaningful in the other direction. Lynkr needs clients that exercise its capabilities in realistic ways. Open-design's rich system prompts, multi-turn conversations, and artifact streaming are exactly the kind of traffic that surfaces edge cases — model hallucinations, ANSI corruption in streamed HTML, token overflows — that make a proxy useful to stress-test.

Part IV — Setup Guide

Prerequisites

Tool	Version	Purpose
Docker	24+	Run open-design
Node.js	20+	Run Lynkr
Ollama	0.4+	Local model inference
Git	any	Clone repos

You also need at least one model pulled in Ollama. For design generation, minimax-m2.5:cloud gives strong results (it reasons visually and follows HTML conventions well). For lighter machines, qwen2.5-coder:7b or llama3.1:8b are workable.

ollama pull minimax-m2.5:cloud
# or for lighter machines:
ollama pull qwen2.5-coder:7b

Step 1 — Install and start Lynkr

# Clone the repo
git clone https://github.com/Fast-Editor/Lynkr
cd lynkr

# Install dependencies
npm install

# Start Lynkr on port 8081
node bin/cli.js start --port 8081

Lynkr starts, discovers your local Ollama instance automatically, and is ready to accept requests at http://localhost:8081/v1/messages.

You can verify it is running:

curl -s http://localhost:8081/health | jq .
# { "status": "ok", "providers": ["ollama", ...] }

To check the dashboard, open http://localhost:8081/dashboard in your browser.

Step 2 — Run open-design in Docker

# Pull and run open-design
docker run -d \
  --name open-design \
  -p 7456:7456 \
  --add-host=host.docker.internal:host-gateway \
  nexuio/open-design:latest

The --add-host flag is critical. Open-design runs inside a container, and it needs to reach Lynkr which runs on your host machine. host.docker.internal is the hostname that resolves to your host from inside a Docker container.

Open your browser at http://localhost:7456. You should see the open-design welcome screen.

Step 3 — Configure API mode to use Lynkr

In the open-design UI:

Click the Settings gear icon (top right).
Under Execution & model, click the BYOK tab (right side — "API provider").
Select the Anthropic protocol tab.
Under Quick fill provider, choose Custom provider.
Set API Key to any non-empty string (e.g. local). Lynkr does not validate it for local providers.
Set Model to the Ollama model you pulled — e.g. minimax-m2.5:cloud or qwen2.5-coder:7b.
Set Base URL to:

   http://host.docker.internal:8081

Click Test to confirm the connection, then close Settings.

The Settings panel with BYOK selected, Anthropic protocol active, and Base URL pointed at Lynkr. The model shown is claude-opus-4-5 but you can type any Ollama model name — the field accepts free text.

That is it. Open-design will now route all AI requests through Lynkr, which routes them to your local Ollama instance.

Step 4 — Create your first design

Click New Project and name it anything — "Landing Page Test".
When prompted for project kind, choose Prototype.
Type your first prompt in the chat:

Create a modern SaaS landing page with a dark hero section, gradient headline, three feature cards below, and a "Get Early Access" CTA button. Use a deep blue and violet color scheme.

Hit enter and watch what happens.

Lynkr receives the request, routes it to Ollama, the model generates an extended thinking block, then produces an <artifact> HTML block. Lynkr streams this back to open-design. Open-design's streaming parser detects the <artifact> tag, opens a Design panel tab, and renders the HTML in real time — line by line, as the model writes it.

When the stream ends, the file is saved automatically to the project and the Design tab snaps into focus with your rendered page.

The full open-design workspace after a generation completes. Left: the conversation. Center: the Design Files panel with a structured layers tree. Right: the live rendered preview — this is a 10-slide editorial pitch deck generated from a single prompt in about 60 seconds.

Step 5 — Iterate and refine

The conversation history is preserved per-project. Each turn, open-design builds the full message history and sends it to Lynkr, so the model has context from every prior design decision.

Try follow-up prompts like:

Make the hero headline larger, add a subtle animated gradient background to the hero section, and add a navigation bar at the top with the logo on the left and three nav links on the right.

or:

Add a testimonials section below the feature cards with three customer quotes and avatar placeholders. Keep the same color palette.

Each response produces an updated artifact. Open-design saves the new version and opens it, preserving the previous version in the file history.

Part V — Advanced Configuration

Using a cloud model as fallback

Lynkr supports routing heavy or complex requests to a cloud provider while keeping simple requests local. Add your Anthropic API key to Lynkr's config:

# In lynkr directory
export ANTHROPIC_API_KEY=sk-ant-...

node bin/cli.js start --port 8081

Lynkr's complexity analyzer will automatically route multi-step reasoning requests to claude-sonnet-4-6 and keep lighter requests on Ollama — without any change to your open-design configuration.

Binding a design system

Open-design lets you create a design system with a DESIGN.md that defines your brand tokens. Once bound to a project, this file is injected into every system prompt. The model reads it as authoritative and will not invent colors, fonts, or spacing outside what you defined.

A minimal DESIGN.md looks like:

## Colors
- Primary: #5B21B6 (violet-800)
- Accent: #7C3AED (violet-600)
- Background: #0F0F23
- Surface: #1A1A2E
- Text: #F8FAFC

## Typography
- Headings: Inter, weight 700
- Body: Inter, weight 400
- Code: JetBrains Mono

## Spacing
Base unit: 4px. All spacing is multiples of 4.

## Buttons
- Primary: solid violet-600, white text, 8px radius, 14px 28px padding
- Ghost: transparent, violet-600 border, violet-600 text

With this bound, every artifact the model generates will use exactly these values — no hallucinated hex codes.

Attaching skills

Skills are workflow templates that inject expert-level instructions for specific artifact types. Open-design ships with several built-in skills. You can also write your own SKILL.md and publish it to the open-design skill registry.

A good skill for landing pages would define the exact section order, component patterns (hero → social proof → features → CTA), and validation checklist the model must pass before emitting the artifact.

Part VI — Troubleshooting

"Done Xs" in the chat but no design appears

This means the model produced output but it was not recognized as an artifact. The most common causes:

The model used tool calls instead of outputting <artifact> blocks. Some models trained on agent data (like MiniMax or Qwen) reflexively try to call file-writing tools instead of producing direct output. Lynkr handles this by detecting the hallucinated tool calls, dropping them, and injecting a redirect message: "You don't have any tools available. Output the result directly as an <artifact> block." The model then produces the correct output on the follow-up. If you see this happening, it is normal — it adds one extra round trip but the design still arrives.

The HTML failed validation. Open-design requires that artifact HTML start with <!DOCTYPE html> or <html. If the model produces a prose response inside <artifact> tags (e.g. "I updated the header section"), it fails the structural check and is not saved. Try a more explicit prompt: "Output the complete HTML document in an artifact block."

Connection refused from the Docker container. Make sure you used host.docker.internal as the base URL (not localhost). From inside a Docker container, localhost refers to the container itself, not your host machine.

ANSI escape codes appearing in the generated HTML

This would have caused CSS rules like * { box-sizing: border-box } to appear as ▸ { box-sizing: border-box } with colored terminal output embedded in the HTML. Lynkr's latest version detects when text content looks like HTML and bypasses the ANSI markdown renderer, keeping the HTML clean. If you see this, make sure you are on the latest Lynkr commit.

The model keeps trying to explore the file system

If your Ollama model was trained on agent data (Claude Code, Codex), its first instinct is to run ls and read files before generating anything. Lynkr injects a system-level note when it detects a tool-less request: "You have NO tools available. Output ONLY text content directly." Combined with open-design's system prompt, this redirects the model within one or two turns.

Part VII — What This Stack Enables

Running open-design with Lynkr gives you a local AI design studio with some properties that are hard to get from fully-managed SaaS alternatives:

Privacy. Your prompts, your designs, and your conversation history never leave your machine (when using local Ollama models). Sensitive product ideas, unreleased brand concepts, confidential UI specs — none of it is sent to a third-party cloud.

Cost control. With Ollama models, inference is free. Lynkr's token budget enforcement and complexity routing mean you only pay cloud API costs for the requests that genuinely need it. A typical design session with minimax-m2.5:cloud on Ollama costs nothing.

Model flexibility. You are not locked to one vendor. If a better open-source design model releases tomorrow, you pull it with ollama pull and update the model name in open-design settings. The rest of the stack does not change.

Composability. Lynkr exposes a standard Anthropic API surface, which means anything that speaks Anthropic can use it — Claude Code, Codex, Continue.dev, your own scripts. Open-design is just one client. You can run others against the same Lynkr instance simultaneously.

Conclusion

Neither open-design nor Lynkr is trying to replace your existing design workflow wholesale. They are building blocks — a canvas that understands artifacts, and a router that understands models. Assembled correctly, they remove the most annoying friction from early-stage design: the gap between I know what I want this to look like and here is the actual HTML.

The integration is not yet seamless for every model (some still need the redirect injection to break out of agent mode), but the core loop — describe it, see it, iterate — works reliably once both services are running.

If you are running a product team and want to prototype faster without signing up for another SaaS tool, or if you are building in public and want full ownership of your AI-generated design assets, this stack is worth an afternoon of setup time.

Both projects are open source. Links below.

Open-design: github.com/nexu-io/open-design

Lynkr: https://github.com/Fast-Editor/Lynkr

Ollama: ollama.ai

If you found this useful, share it with someone building with open-source AI tools. Comments and questions are open below.

One npm Install That Makes Every AI Coding Tool Work With Every LLM Provider

Vishal VeeraReddy — Thu, 16 Apr 2026 01:27:01 +0000

Quick question: how many API keys are in your .env right now just for AI coding tools?

If you use Claude Code (Anthropic key), Codex (OpenAI key), and Cursor (another OpenAI key) — that's three providers, three billing accounts, three rate limit systems, zero flexibility.

I built Lynkr to collapse all of that into one proxy.

What It Does

Claude Code ──┐
Codex CLI ────┤
Cursor ───────┤──→ Lynkr (localhost:8081) ──→ Any LLM Provider
Cline ────────┤
Continue ─────┤
LangChain ────┤
Vercel AI ────┘

Lynkr auto-detects which tool is connecting and speaks its language:

Anthropic Messages API for Claude Code
OpenAI Responses API for Codex CLI
OpenAI Chat Completions for everything else (Cursor, Cline, Continue, KiloCode, LangChain, Vercel AI SDK, any OpenAI-compatible client)

Setup

npm install -g lynkr
lynkr start

Then configure each tool to point at Lynkr:

# Claude Code
export ANTHROPIC_BASE_URL=http://localhost:8081

# Codex CLI (~/.codex/config.toml)
# base_url = "http://localhost:8081/v1"

# Cursor
# Settings → Models → Base URL: http://localhost:8081/v1

# LangChain
# ChatOpenAI(base_url="http://localhost:8081/v1", api_key="sk-lynkr")

# Literally any OpenAI-compatible tool
# OPENAI_BASE_URL=http://localhost:8081/v1

All of them hit the same Lynkr instance. Same provider. Same routing. Same optimization.

12+ Backends

Pick your provider:

# Free (local)
MODEL_PROVIDER=ollama

# Cheap cloud
MODEL_PROVIDER=openrouter    # 100+ models
MODEL_PROVIDER=deepseek      # 1/10 Anthropic cost
MODEL_PROVIDER=zai           # 1/7 Anthropic cost

# Enterprise cloud
MODEL_PROVIDER=bedrock       # AWS, 100+ models
MODEL_PROVIDER=vertex        # Google, Gemini 2.5
MODEL_PROVIDER=databricks    # Claude Opus 4.6

Or mix them across complexity tiers:

TIER_SIMPLE=ollama:qwen2.5-coder
TIER_MEDIUM=openrouter:deepseek-r1
TIER_COMPLEX=databricks:claude-sonnet-4-5
TIER_REASONING=vertex:gemini-2.5-pro

Simple requests (rename a variable) → free local model.
Complex requests (refactor auth across 23 files) → top-tier cloud model.

The routing engine makes this decision automatically using 5-phase complexity analysis — including Graphify, which reads your actual codebase AST across 19 languages to detect high-risk changes.

For Agent Builders: LangChain, CrewAI, AutoGen

This is where Lynkr shines for automation. If you're building agents that make hundreds of LLM calls per pipeline run, most of those calls are simple (read a file, parse JSON, format output). Only a few require deep reasoning.

Without Lynkr: every call hits GPT-4o at $15/MTok. 200 calls × $0.03 = $6/run.

With Lynkr: 140 calls hit free Ollama, 40 hit OpenRouter ($0.005 each), 20 hit Databricks ($0.02 each). Total: $0.60/run. 90% savings.

# Nothing changes in your agent code
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(
    base_url="http://localhost:8081/v1",
    api_key="sk-lynkr",
    model="auto"  # Lynkr routes based on complexity
)

# Your existing chains, agents, and tools work unchanged
agent_executor.invoke({"input": "Refactor the payment module"})

Token Compression Stack

On top of routing, every request passes through 7 optimization phases:

Smart tool selection — only relevant tools sent
Code Mode — 100+ tool defs → 4 meta-tools (96% reduction, saves 16,800 tokens/request)
Distill — delta rendering via Jaccard similarity (60-80% savings)
Prompt cache — SHA-256 keyed LRU
Memory dedup — removes repeated context across turns
History compression — sliding window with structural dedup
Headroom sidecar — optional ML compression (47-92%)

Enterprise: Circuit Breakers, Telemetry, Hot-Reload

For teams running this in production:

# Health check
curl http://localhost:8081/health

# List all providers and models
curl http://localhost:8081/v1/providers
curl http://localhost:8081/v1/models

# Routing analytics
curl http://localhost:8081/v1/routing/stats
curl http://localhost:8081/v1/routing/accuracy

# Change config without restart
curl -X POST http://localhost:8081/v1/admin/reload

# Prometheus metrics
curl http://localhost:8081/metrics

Circuit breakers auto-detect provider failures. After 5 failed requests, incoming calls fail instantly instead of timing out. Half-open probes test recovery every 60 seconds. When 2 probes succeed, traffic resumes. No manual intervention.

Get Started

npm install -g lynkr && lynkr start

699 tests. Apache 2.0. Node.js only. Zero infrastructure.

GitHub: github.com/Fast-Editor/Lynkr

If you're managing multiple AI coding tools or building LLM-powered agents, Lynkr consolidates everything into one proxy with intelligent routing and real cost savings.

Star it if it helps. PRs welcome.

Run OpenClaw/Clawdbot for FREE with Lynkr (No API Bills)

Vishal VeeraReddy — Sun, 01 Feb 2026 02:00:41 +0000

Your personal AI assistant running 24/7 — without burning through API credits

If you've tried OpenClaw (also known as Clawdbot), you know it's incredible. An AI assistant that lives in WhatsApp/Telegram, manages your calendar, clears your inbox, checks you in for flights — all while you chat naturally.

But there's a catch: it needs an LLM backend, and Anthropic API bills add up fast.

What if I told you that you can run OpenClaw completely free using local models? Enter Lynkr.

🔗 What is Lynkr?

Lynkr is a universal LLM proxy that lets you route OpenClaw requests to any model provider — including free local models via Ollama.

The magic? OpenClaw thinks it's talking to Anthropic, but Lynkr transparently routes requests to your local GPU instead.

💡 Why This Matters

Problem with direct Anthropic API:

💸 Bills explode quickly (OpenClaw runs 24/7)
⚠️ Potential ToS concerns with automated assistants
🔒 Your data goes to external servers

With Lynkr + Ollama:

✅ $0/month — runs entirely on your machine
✅ ToS compliant — no API abuse concerns
✅ 100% private — data never leaves your computer
✅ Smart fallback — route to cloud only when needed

🚀 Setup Guide (15 minutes)

Step 1: Install Ollama

# macOS/Linux
curl -fsSL https://ollama.com/install.sh | sh

# Pull Kimi K2.5 (recommended for coding/assistant tasks)
ollama pull kimi-k2.5

# Also grab an embeddings model for semantic search
ollama pull nomic-embed-text

Step 2: Install Lynkr

# Option A: NPM (recommended)
npm install -g lynkr

# Option B: Clone repo
git clone https://github.com/Fast-Editor/Lynkr.git
cd Lynkr
npm install

Step 3: Configure Lynkr

Create your .env file:

# Copy example config
cp .env.example .env

Edit .env with these settings:

# Primary provider: Ollama (FREE, local)
MODEL_PROVIDER=ollama
OLLAMA_MODEL=kimi-k2.5
OLLAMA_ENDPOINT=http://localhost:11434

# Enable hybrid routing (local first, cloud fallback)
PREFER_OLLAMA=true
OLLAMA_MAX_TOOLS_FOR_ROUTING=3

# Fallback provider (optional - for complex requests)
FALLBACK_ENABLED=true
FALLBACK_PROVIDER=openrouter
OPENROUTER_API_KEY=sk-or-v1-your-key  # Only needed if using fallback

# Embeddings for semantic search
OLLAMA_EMBEDDINGS_MODEL=nomic-embed-text

# Token optimization (60-80% cost reduction on cloud fallback)
TOKEN_TRACKING_ENABLED=true
TOOL_TRUNCATION_ENABLED=true
HISTORY_COMPRESSION_ENABLED=true

Step 4: Start Lynkr

# If installed via npm
lynkr

# If cloned repo
npm start

You should see:

🚀 Lynkr proxy running on http://localhost:8081
📊 Provider: ollama (kimi-k2.5)

Step 5: Configure OpenClaw/Clawdbot

In your OpenClaw configuration, set:

Setting	Value
Model/auth provider	`Copilot`
Copilot auth method	`Copilot Proxy (local)`
Copilot Proxy base URL	`http://localhost:8081/v1`
Model ID	`kimi-k2.5`

That's it! Your OpenClaw now runs through Lynkr → Ollama → Kimi K2.5, completely free.

⚡ How Hierarchical Routing Works

The killer feature is smart routing:

OpenClaw Request
       ↓
   Is it simple?
    /        \
  Yes         No
   ↓           ↓
Ollama     Cloud Fallback
(FREE)     (with caching)

Lynkr analyzes each request:

Simple requests (< 3 tools) → Ollama (free)
Complex requests → Cloud fallback (with heavy caching/compression)

This means even if you enable cloud fallback, you'll use it sparingly.

💰 Cost Comparison

Setup	Monthly Cost	Privacy
Direct Anthropic API	$100-300+	❌ Cloud
Lynkr + Ollama only	$0	✅ 100% Local
Lynkr + Hybrid routing	~$5-15	✅ Mostly Local

🔒 Why This is ToS-Safe

Running OpenClaw directly against Anthropic's API at scale can raise ToS concerns (automated usage, high volume, etc.).

With Lynkr:

Local models = no external API terms apply
Your hardware = your rules
Fallback is minimal = within normal usage patterns

🧠 Advanced: Memory & Compression

Lynkr includes enterprise features that further reduce costs:

Long-Term Memory (Titans-inspired):

MEMORY_ENABLED=true
MEMORY_RETRIEVAL_LIMIT=5
MEMORY_SURPRISE_THRESHOLD=0.3

Headroom Compression (47-92% token reduction):

HEADROOM_ENABLED=true
HEADROOM_SMART_CRUSHER=true
HEADROOM_CACHE_ALIGNER=true

These features mean even when you hit cloud fallback, you're using far fewer tokens.

🎯 Recommended Models

Use Case	Ollama Model	Pull Command
General Assistant	kimi-k2.5	`ollama pull kimi-k2.5`
Coding Tasks	qwen2.5-coder:latest	`ollama pull qwen2.5-coder:latest`
Fast/Light	llama3.2:3b	`ollama pull llama3.2:3b`
Embeddings	nomic-embed-text	`ollama pull nomic-embed-text`

🏃 TL;DR

# Install
curl -fsSL https://ollama.com/install.sh | sh
ollama pull kimi-k2.5
npm install -g lynkr

# Configure (.env)
MODEL_PROVIDER=ollama
OLLAMA_MODEL=kimi-k2.5
PREFER_OLLAMA=true

# Run
lynkr

# Point OpenClaw to http://localhost:8081/v1

Result: OpenClaw running 24/7, $0/month, 100% private.

How I Cut My AI Coding Tool Costs by 70% (And You Can Too)

Vishal VeeraReddy — Sun, 01 Feb 2026 01:45:11 +0000

Run Cursor, Claude Code, Cline, and more on ANY LLM — including free local models

If you're like me, you've probably fallen in love with AI coding assistants. Tools like Cursor, Claude Code CLI, Cline, and OpenClaw/Clawdbot have genuinely transformed how I write code. But there's a catch — they're expensive.

Between API costs and subscription fees, I was burning through $100-300/month just on AI coding tools. That's when I built Lynkr.

🔗 What is Lynkr?

Lynkr is an open-source universal LLM proxy that lets you run your favorite AI coding tools on any model provider — including completely free local models via Ollama.

Think of it as a universal adapter. Your tools think they're talking to their native API, but Lynkr transparently routes requests to whatever backend you choose.

💡 The Problem Lynkr Solves

Here's what frustrates developers:

Vendor lock-in — Cursor only works with OpenAI/Anthropic. Claude Code CLI only works with Anthropic.
Expensive APIs — Claude API costs add up fast, especially for heavy coding sessions
No local option — Want to use your RTX 4090 for coding assistance? Too bad.
Enterprise restrictions — Many companies can't send code to external APIs

Lynkr fixes all of this.

🏗️ How It Works

┌─────────────┐     ┌─────────┐     ┌──────────────────┐
│ Cursor      │     │         │     │ Ollama (local)   │
│ Claude Code │────▶│  Lynkr  │────▶│ AWS Bedrock      │
│ Cline       │     │  Proxy  │     │ Azure OpenAI     │
│ OpenClaw    │     │         │     │ OpenRouter       │
└─────────────┘     └─────────┘     └──────────────────┘

Lynkr acts as a drop-in replacement for the Anthropic API. It:

Receives requests from your AI coding tool
Translates them to your target provider's format
Streams responses back seamlessly

Your tools don't know the difference.

🚀 Supported Providers

Lynkr supports 12+ providers:

Ollama - 100% local, FREE
AWS Bedrock - Enterprise-grade, ~60% cheaper
Azure OpenAI - Enterprise-grade
Azure Anthropic - Claude on Azure
OpenRouter - 100+ models via single API
OpenAI - Direct GPT access
Google Vertex AI - Gemini models
Databricks - Enterprise ML platform
Z.AI (Zhipu) - ~1/7 cost of Anthropic
LM Studio - Local models with GUI
llama.cpp - Local GGUF models

📦 Quick Start (5 minutes)

Option 1: Run locally with Ollama (FREE)

# Install Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Pull a coding model
ollama pull qwen2.5-coder:latest

# Clone and configure Lynkr
git clone https://github.com/Fast-Editor/Lynkr.git
cd Lynkr
cp .env.example .env

# Edit .env:
MODEL_PROVIDER=ollama
OLLAMA_MODEL=qwen2.5-coder:latest
OLLAMA_ENDPOINT=http://localhost:11434

# Start
npm install && npm start

Option 2: Use with AWS Bedrock

# Clone and configure
git clone https://github.com/Fast-Editor/Lynkr.git
cd Lynkr
cp .env.example .env

# Edit .env:
MODEL_PROVIDER=bedrock
AWS_BEDROCK_API_KEY=your-bedrock-api-key
AWS_BEDROCK_REGION=us-east-1
AWS_BEDROCK_MODEL_ID=anthropic.claude-3-5-sonnet-20241022-v2:0

# Start
npm install && npm start

Option 3: OpenRouter (Simplest Cloud Setup)

# Edit .env:
MODEL_PROVIDER=openrouter
OPENROUTER_API_KEY=sk-or-v1-your-key
OPENROUTER_MODEL=anthropic/claude-3.5-sonnet

npm start

Configure Your Tool

Point your AI coding tool to Lynkr:

# For Claude Code CLI
export ANTHROPIC_API_KEY=dummy
export ANTHROPIC_BASE_URL=http://localhost:8081

# Now use Claude Code normally!
claude "Refactor this function"

💰 Real Cost Comparison

Here's what I was spending vs. what I spend now:

Tool	Before (Direct API)	After (Lynkr + Bedrock)	Savings
Claude Code CLI	$150/month	$45/month	70%
Heavy Cursor usage	$100/month	$30/month	70%
With Ollama	-	$0/month	100%

The local Ollama option is genuinely free. If you have a decent GPU (RTX 3080+), models like qwen2.5-coder run surprisingly well.

🔒 Enterprise Use Cases

Lynkr shines in enterprise environments:

Air-gapped networks: Run entirely local with Ollama
Compliance: Keep code on AWS/Azure infrastructure you control
Cost control: Set usage limits and track spending per team
Audit trails: Log all requests for compliance

⚡ Advanced Features

Hybrid Routing: Use Ollama for simple requests, fallback to cloud for complex ones
Token Optimization: 60-80% cost reduction through smart compression
Long-Term Memory: Titans-inspired memory system for context persistence
Headroom Compression: 47-92% token reduction via intelligent context compression
Hot Reload: Config changes apply without restart
Smart Tool Selection: Automatic tool filtering to reduce token usage

🤝 Contributing

Lynkr is open source (MIT license). Contributions welcome:

🐛 Bug reports and fixes
🔌 New provider integrations
📖 Documentation improvements
⭐ Stars on GitHub!

Try It Today

Stop overpaying for AI coding tools. With Lynkr, you can:

Save 60-80% using AWS Bedrock or Azure
Pay nothing using local Ollama models
Keep code private in enterprise environments

⭐ Star on GitHub: github.com/Fast-Editor/Lynkr

📚 Full Documentation: deepwiki.com/Fast-Editor/Lynkr

What AI coding tools do you use? Have you tried running them locally? Let me know in the comments!

I Slashed My AI Coding Bills by 65% With This One Weird Trick.

Vishal VeeraReddy — Wed, 31 Dec 2025 05:57:34 +0000

The Problem Every Dev Using AI Assistants Faces.You know that moment when you're using Claude Code CLI, crushing it with AI-powered coding, and then you check your Anthropic bill at the end of the month?
Yeah. $347 for me last month. 😱
And here's the kicker: 65% of my requests were literally just "write a hello world function" or "explain this error message" - stuff that could easily run on my laptop.
I was paying premium API rates for queries that a local 7B model could handle in 300ms.
So I did what any reasonable developer would do: I spent a weekend building a solution that now saves me hundreds of dollars monthly.
Meet Lynkr: The Claude Code "Jailbreak" Nobody Asked For
Lynkr is a self-hosted proxy that sits between Claude Code CLI and... well, literally any LLM backend you want.
Databricks? ✅
Azure? ✅
OpenRouter with 100+ models? ✅
Local Ollama models that cost $0 per request? ✅✅✅
llama.cpp with your own GGUF quantized models? ✅✅✅✅
But here's where it gets interesting...
The 3-Tier Routing System That Changed Everything
Instead of sending every single request to expensive cloud APIs, Lynkr automatically routes based on complexity:

🏎️

Tier 1: Local/Free (0-2 tools needed)

Ollama or llama.cpp running on your machine
Response time: 100-500ms
Cost: $0.00
Handles: "explain this code", "write a function", "fix this bug"

💰 Tier 2: Mid-Tier Cloud (3-14 tools)

OpenRouter with GPT-4o-mini ($0.15 per 1M tokens)
Response time: 300-1500ms
Cost: ~$0.0002 per request
Handles: Multi-file refactoring, moderate complexity

🏢 Tier 3: Enterprise (15+ tools)

Databricks or Azure Anthropic (Claude Opus/Sonnet)
Response time: 500-2500ms
Cost: Standard API rates
Handles: Complex analysis, heavy workflows

The proxy automatically decides which tier to use. No configuration. No manual routing. It just works.
The Results Speak For Themselves

Here's what happened after I switched:

Metric	Before Lynkr	After Lynkr	Improvement
Avg Response Time	1500-2500ms	400-800ms	70% faster
Monthly API Bill	$347	$122	65% cheaper
Local Request %	0%	68%	$0 cost on 68% of requests
Downtime Impact	100% blocked	0% (fallback works)	∞% more reliable

That's not a typo. I'm getting 70% faster responses while spending 65% less money.
Automatic Fallback = Zero Downtime

The killer feature nobody talks about: if your local Ollama server crashes (mine does, frequently), Lynkr automatically falls back to the next tier.

Request → Try Ollama → [Connection Refused]
       → Try OpenRouter → [Rate Limited]  
       → Try Databricks → ✅ Success

MCP Server Integration (Because Why Not)

Want to integrate GitHub, Jira, Slack, or literally any other tool via Model Context Protocol?
Just drop a manifest file in ~/.claude/mcp and Lynkr automatically:

Discovers it
Launches the MCP server
Exposes the tools to your AI assistant
Sandboxes it in Docker (optional but recommended)

Production-Ready From Day One

I learned from my mistakes. This isn't a weekend hack held together with duct tape:

✅ Circuit breakers (no cascading failures)
✅ Load shedding (503s when overloaded, not crashes)
✅ Prometheus metrics api(because you can't improve what you don't measure)
✅ Kubernetes health checks (liveness + readiness probes)
✅ Graceful shutdown (zero-downtime deployments)
✅ Request ID correlation (debug production issues in seconds)

Quick Install (curl)

curl -fsSL https://raw.githubusercontent.com/vishalveerareddy123/Lynkr/main/install.sh | bash

For .env

Template 1: Databricks Only (Simple)
bash# .env
MODEL_PROVIDER=databricks
DATABRICKS_API_BASE=https://your-workspace.cloud.databricks.com
DATABRICKS_API_KEY=dapi1234567890abcdef
DATABRICKS_ENDPOINT_PATH=/serving-endpoints/databricks-claude-sonnet-4-5/invocations

PORT=8080
WORKSPACE_ROOT=/path/to/your/project
PROMPT_CACHE_ENABLED=true

Template 2: Ollama Only (100% Local)
bash# .env
MODEL_PROVIDER=ollama
OLLAMA_ENDPOINT=http://localhost:11434
OLLAMA_MODEL=qwen2.5-coder:latest
OLLAMA_TIMEOUT_MS=120000

PORT=8080
WORKSPACE_ROOT=/path/to/your/project
PROMPT_CACHE_ENABLED=true

Template 3: Hybrid Routing (Cost Optimized)
bash# .env
MODEL_PROVIDER=databricks
PREFER_OLLAMA=true
FALLBACK_ENABLED=true

# Ollama (Free Tier)
OLLAMA_ENDPOINT=http://localhost:11434
OLLAMA_MODEL=qwen2.5-coder:latest
OLLAMA_MAX_TOOLS_FOR_ROUTING=3

# OpenRouter (Mid Tier)
OPENROUTER_API_KEY=sk-or-v1-your-key-here
OPENROUTER_MODEL=openai/gpt-4o-mini
OPENROUTER_MAX_TOOLS_FOR_ROUTING=15

# Databricks (Heavy Tier)
DATABRICKS_API_BASE=https://your-workspace.cloud.databricks.com
DATABRICKS_API_KEY=dapi1234567890abcdef

PORT=8080
WORKSPACE_ROOT=/path/to/your/project

That's it. You're now running Claude Code CLI with:

Real-World Use Cases (AKA "Will This Actually Help Me?")

For Indie Developers

Use free Ollama models for 90% of your work. Only pay for complex tasks. Your $347/month bill becomes $35/month.

For Enterprise Teams

Route simple queries to on-premise llama.cpp servers. Complex queries go to your Databricks workspace. Data never leaves your network for simple requests.

For AI Researchers

Test your own fine-tuned models with Claude Code CLI. Compare them side-by-side with GPT-4, Claude, Gemini via OpenRouter.

For Privacy-Conscious Devs

Run Ollama or llama.cpp locally. Code never leaves your machine unless you explicitly need cloud capabilities.

The Part Where I Show You The Code

Okay fine, here's how the hybrid routing actually works under the hood:

javascript// Simplified version - actual code has more checks
async function routeRequest(request) {
  const toolCount = request.tools?.length || 0;

  // Tier 1: Local/Free (0-2 tools)
  if (toolCount <= 2 && config.PREFER_OLLAMA) {
    try {
      return await ollamaClient.send(request);
    } catch (err) {
      logger.warn('Ollama failed, falling back to cloud');
      // Fallback to next tier...
    }
  }

  // Tier 2: Mid-Tier (3-14 tools)
  if (toolCount <= 14 && config.OPENROUTER_API_KEY) {
    try {
      return await openRouterClient.send(request);
    } catch (err) {
      logger.warn('OpenRouter failed, falling back to Databricks');
      // Fallback to next tier...
    }
  }

  // Tier 3: Enterprise (15+ tools)
  return await databricksClient.send(request);
}

The circuit breaker wraps each client, so after 5 consecutive failures, requests fail fast (100ms instead of 30s timeout).

Models That Actually Work Well

Through extensive testing, here's what actually performs:

For Ollama (Local):

qwen2.5-coder:7b - Best for code generation
llama3.1:8b - Best for general tasks
mistral:7b - Fastest responses

For OpenRouter (Mid-Tier):

openai/gpt-5.1 - Best value ($0.15/1M tokens)
meta-llama/llama-3.1-8b-instruct:free - Actually free (rate limited)

For llama.cpp (Maximum Control):

Any GGUF model works
I use Qwen2.5-Coder-7B-Instruct-Q5_K_M.gguf
Point to your llama.cpp server's OpenAI-compatible endpoint

The Catches (Because Nothing's Perfect)

Ollama doesn't support all Claude features

No extended thinking mode
No prompt caching (Lynkr adds its own though)
Tool calling works but varies by model

You need to run local inference

Ollama = ~8GB RAM for 7B models
llama.cpp = ~6GB RAM with quantization
Not great for 4GB laptops

Initial setup requires some config

Environment variables for API keys
Workspace paths
Model selection

But the wizard handles 90% of this automatically.

Get Started Now

GitHub: https://github.com/Fast-Editor/Lynkr
Docs: fast-editor.github.io/Lynkr/
npm: npm install -g lynkr
Apache licensed. PRs welcome. Built with Node.js, SQLite, and determination.

The Future Roadmap

Things I'm working on:

[ ] Response caching layer (Redis-backed)
[ ] Per-file diff comments (like Claude's review UX)
[ ] Better LSP integration for more languages
[ ] Claude Skills compatibility layer
[ ] Historical metrics dashboard

Final Thoughts

Look, I'm not saying Anthropic's hosted service is bad. It's excellent. But for developers who want:

Control over their infrastructure
Cost optimization
Privacy for simple queries
Custom model integration

Lynkr gives you all of that while keeping the Claude Code CLI experience you already love.

Try it for a week. Track your costs. I bet you'll see similar savings.

And if you don't? Well, it's open source. Make it better and send a PR. 😉

Questions? Comments? Roasts? Drop them below. I'll answer everything except "why did you waste a weekend on this" (because I saved $225 already).

⭐ Star the repo if you found this useful: https://github.com/Fast-Editor/Lynkr