Skip to content

What is merido?

merido is a local-first, OpenAI-compatible AI gateway written in Rust. It sits between your coding tools and the LLM providers you pay for, and gives you one stable endpoint that can speak to 40+ upstreams — translating wire formats, compressing tool output to save tokens, and falling back across accounts and providers when one fails.

The problem it solves

If you use several coding CLIs (Claude Code, Codex, Cursor, …) and several model providers, you end up juggling base URLs, API keys, rate limits, and pricing in every tool. You also have little visibility into what you actually spend, and no easy way to cut it.

merido centralizes all of that:

  • One endpoint, many providers. Point any tool at merido and route it to OpenAI, Anthropic, Gemini, OpenRouter, DeepSeek, and dozens more — without changing the tool.
  • One place to save tokens. Tool-result compression and an optional output-compression mode run on every request, with a ledger that proves the savings.
  • One place to see cost. Every request is tracked, costed, and auditable.

Who it's for

  • Developers who route multiple coding CLIs through multiple LLM providers and want one control point.
  • Teams who want fallback, rate limiting, budgets, and usage reporting without standing up a heavyweight platform.
  • Anyone who wants to spend less per request and prove it.

One binary, two planes

merido ships as a single executable that serves everything on one port (8788 by default):

  • the OpenAI-compatible API (/v1/*),
  • the React dashboard (/app),
  • a static landing page (/),
  • and these docs (/docs).

Internally it separates two concerns:

  • Data plane — the LLM request path under /v1/*. Auth → resolve model/virtual-model → route to a provider/account → compress tokens → translate formats → execute with retry/fallback → track usage.
  • Control plane — the dashboard and admin API under /api/*: providers, keys, virtual models, usage, savings, the advisor, settings, and more.

Profiles

The same code runs in two profiles, selected by MERIDO_PROFILE:

  • local (default) — embedded SQLite under ~/.merido, single-user, no external services.
  • cloud — Postgres (+ optional Redis), multi-tenant, built for a shared deployment.

You don't fork between them — they are the same binary behind the storage/cache abstractions.

Feature overview

FeatureWhere to read more
Point a coding CLI at meridoConnect a coding CLI
Client keys vs. upstream provider credentialsAdd providers & keys
Cost/latency/health-aware routing with fallbackVirtual models & fallback
tool_result compression + Caveman modeToken saving
Request dedup + semantic cacheCaching
Usage tracking + the Token-Optimization AdvisorUsage & the Advisor
Hardening + Docker/Fly.io deployDeploy to production
Self-serve multi-tenant modeMulti-tenancy
Running multiple instances on shared RedisHigh availability

Ready to run it? Head to the Quick start.

© merido. All rights reserved.