Open Source
Explore the latest AI open-source projects from GitHub and HuggingFace.
Explore the latest AI open-source projects from GitHub and HuggingFace.
**Switchyard** is NVIDIA's Rust proxy and library for LLM traffic, and it landed at **#5 on GitHub Trending this week with 1,326 new stars**, now sitting at **1,590 stars and 144 forks**. It is **Apache-2.0**, lives under the **NVIDIA-NeMo** organization, and is genuinely new — the repository was created on **19 May 2026**, shipped **v0.1.0 on 30 June** and **v0.2.0 on 10 August 2026**. The pitch is narrow and concrete: point a coding agent such as **Claude Code, Codex CLI, or OpenClaw** at an open-source model. Switchyard translates between the **OpenAI Chat Completions, Anthropic Messages, and OpenAI Responses** formats, so the agent keeps speaking its native API while the request is actually served by **vLLM, NVIDIA NIM, Ollama, or any OpenAI-compatible endpoint**. That is a different problem from what a hosted gateway solves — this is about keeping a client that only knows one dialect usable against a backend that speaks another, with the translation happening in a process you run. There are three entry points, and picking the right one matters. The **launcher path** is the shortest: install `uv`, then `uv tool install --python 3.10 "nemo-switchyard[cli]"`, set `OPENROUTER_API_KEY`, and run `switchyard launch claude --model switchyard` (or `codex`, or `openclaw`). The agent binary has to already be on your `PATH`, and this path does *not* install the standalone server. The **server path** is `cargo install --locked switchyard-server`, a `routes.toml`, a `--dry-run` validation pass, then `switchyard-server --config routes.toml --host 127.0.0.1 --port 4000` with a `/health` endpoint to check. The **library path** is the interesting one for anyone already running a gateway: `switchyard-libsy` **never calls a model itself** — an algorithm decides which target to use and hands every model call back to you, so it drops into an existing proxy or agent runtime without owning an HTTP stack. Routing is where the design shows its opinion. Four typed strategies ship: **`llm_classifier`**, where request content decides whether a turn needs the weak or strong tier; **`stage_router`**, which reads signals already present in the conversation — tool results, errors — so most turns route without an extra model call; an **escalation** mode (`llm_classifier` with `mode = "escalation"`) that runs every turn on the weak tier first and has a judge decide whether to re-send to the strong tier; and **`random`** for fixed traffic splits during A/B tests and cost experiments. A `passthrough` route registers one target under one model ID with no decision at all. **Prometheus metrics** cover requests, errors, latency, tokens, and routing overhead — so the cost claim is measurable rather than asserted. The codebase splits into four crates: `switchyard-server`, `switchyard-libsy`, `switchyard-protocol`, and `switchyard-translation`. The honest counterweight is maturity, and the project says so itself in a warning block: **"Experimental software. Not for production use."** The README calls it **pre-alpha**, with the API and algorithms expected to change significantly before v1.0, and there are **100 open issues** against a project less than three months old. The library crates are documented as **git dependencies** rather than published crates.io versions, so embedding `switchyard-libsy` means pinning a commit. The stage router's premise — that conversation signals are a good enough proxy for difficulty — is also unproven at this stage; nothing in the repository establishes how often it routes correctly on real agent traffic.