rewynd
Enables coding agents to debug backend requests by providing tools to list, view, wait for, diagnose, and clear request traces.
README
<p align="center"> <img src="demo/banner.png" alt="rewynd — the flight recorder for your backend, for humans and the agents that debug with them" width="100%"> </p>
<p align="center"> <a href="https://github.com/SrinjoyDev/rewynd/actions/workflows/ci.yml"><img src="https://github.com/SrinjoyDev/rewynd/actions/workflows/ci.yml/badge.svg" alt="CI"></a> <a href="./LICENSE"><img src="https://img.shields.io/badge/license-MIT-blue.svg" alt="MIT License"></a> <img src="https://img.shields.io/badge/Go-1.25+-00ADD8?logo=go&logoColor=white" alt="Go 1.25+"> <img src="https://img.shields.io/badge/Node-18+-339933?logo=node.js&logoColor=white" alt="Node 18+"> <img src="https://img.shields.io/badge/PRs-welcome-brightgreen.svg" alt="PRs welcome"> </p>
A zero-config, OTLP-native flight recorder for your backend. It silently records every
request — and background job — your backend handles, with the database queries, outbound calls,
logs, and exceptions each one caused, correlated per request, during local development. You
— or your coding agent — see exactly what happened. No console.log, no re-running.
<p align="center"> <img src="demo/tui.gif" alt="rewynd TUI — live requests with the N+1 waterfall" width="100%"> </p>
<p align="center"><sub>Above: the human view — click the broken request, see its whole story. Below: the same recording, driven by your coding agent.</sub></p>
<p align="center"> <img src="demo/agent-loop.gif" alt="rewynd agent loop — clear, trigger, watch, diagnose" width="100%"> </p>
Laravel Telescope, reborn for the terminal and language-agnostic — the first backend recorder your coding agent can actually drive. Works with any OpenTelemetry stack (Node, Python, Go, Ruby, Java, …); OpenTelemetry under the hood, zero config on top. Runs entirely on your machine.
v0.2.1 is live. The core, the TUI, the CLI, the agent loop, the MCP server, capture across Node / Python / Go / Ruby / any OpenTelemetry language, distributed traces, background jobs, and the load view all work today — install below. Stars and feedback welcome.
Install
# npm (the CLI + the Node capture shim) — the command it installs is `rewynd`:
npm i -D @rewynd/cli
# …Python (the capture shim + `rewynd-run`):
pip install rewynd
# …or grab the binary directly (macOS / Linux):
curl -fsSL https://raw.githubusercontent.com/SrinjoyDev/rewynd/main/scripts/install.sh | sh
# …or with Go:
go install github.com/SrinjoyDev/rewynd/core/cmd/rewynd@latest
Windows binaries are on the releases page, or build from source — see CONTRIBUTING.
The npm package is
@rewynd/cli(npm reserves the barerewyndname); the installed command is stillrewynd. Python ispip install rewyndthenrewynd-run <your command>.
The problem
Frontend devs have the Chrome DevTools network tab. Backend devs have print. When an
endpoint is slow or broken, you sprinkle console.log, re-run the request five times, and
squint at which SQL fired. And coding agents have it worse — they write backend code and fly
blind, unable to see what it actually did.
rewynd is the network tab for your backend — for humans and agents.
Quick start
# In your Node project (Express, Fastify, …), after installing (see Install above):
# run your normal dev command through rewynd — it auto-starts the recorder:
rewynd run npm run dev
# In another terminal:
rewynd tui # the live dashboard — watch requests stream in, click the broken one
rewynd ls # or list them; `rewynd show <id>` for one request's full story
$ rewynd show 6928a80f
GET /api/users -> 200 (15ms)
DETECTIONS
! n_plus_one — N+1 query — 10 identical statements
QUERIES (11)
2ms SELECT id, name FROM users ORDER BY id
18ms SELECT id, title FROM posts WHERE user_id = ? ×10 (avg 1.8ms)
LOGS (2)
[info] listing users
[info] assembled users with posts
For your coding agent — the differentiator
rewynd gives agents a tight, structured clear → trigger → watch → read → fix loop so they
can debug a backend autonomously:
rewynd clear # clean slate
curl localhost:3000/api/orders # the agent triggers the endpoint
rewynd watch --status 5xx --timeout 10s --json # blocks until it lands, prints the full trace
rewynd diagnose <id> # "what's wrong here" in one line
watch returns the failing SQL with its params, the exception and stack, and any detected
N+1 — as JSON the agent reads directly.
Or skip the CLI: rewynd ships an MCP server so agents introspect the backend natively. Drop this into your Claude Code / Cursor MCP config:
{
"mcpServers": {
"rewynd": { "command": "rewynd", "args": ["mcp"] }
}
}
Tools: get_stats, get_load_stats, list_requests, get_request, wait_for_request,
diagnose, get_last_error, clear. The server also sends the whole debugging protocol as
MCP instructions on connect, so the agent knows when and how to use them.
Ready-made integrations for Claude Code (skill + MCP), Cursor (rules + MCP), Windsurf,
OpenCode, Codex, Cline, and Devin live in integrations/ — drop the right
file into your project and any agent learns the clear → trigger → watch → read → fix loop.
Does it actually help an agent? — a benchmark
We measured it. Four realistic backend bugs; the same coding agent and the same prompt in both arms — the only difference is whether it can read the rewynd trace.
<p align="center"> <img src="bench/agent-eval/chart.png" alt="Does rewynd help a coding agent find the bug? Without rewynd 3/4; with rewynd 4/4." width="100%"> </p>
The agent found the root cause in 4/4 bugs with rewynd vs 3/4 without — and, more telling,
was correct and confident 4/4 vs 2/4. The miss was a silently-failing background job: with
only the source and the logs the agent confidently invented the wrong cause (a job-type
mismatch); with the recorded trace it read the actual SMTPConnectError and got it right.
Without ground truth, agents don't just fail — they hallucinate a fix. rewynd replaces the
guess with what actually happened.
It's fully reproducible — the tasks, the OTLP seeder, and the grader live in
bench/agent-eval/. Bring your own agent and add your own bugs.
What it captures, correlated per flow
| HTTP requests | method, path, status, timing |
| Background jobs | queue consumers, workers, cron — recorded as first-class flows, ok/fail (example) |
| DB queries | SQL + params + duration, with N+1 detection |
| Outbound calls | method, URL, status, duration |
| Logs | console / pino / winston, stamped with the flow's trace |
| Exceptions | type, message, stack |
Commands
| Command | What it does |
|---|---|
rewynd run <cmd> |
Run your dev command with recording on (auto-starts the core) |
rewynd ls |
List requests (--status 5xx, --slow, --has-error, --path, --json) |
rewynd show <id> |
Full correlated trace for one request (--json) |
rewynd export <id> |
Write the trace as a self-contained HTML file (-o trace.html) — share it, attach it to a PR or CI |
rewynd stats |
Load summary: throughput, latency p50/p95/p99, error rate, by endpoint. --save <name> then --baseline <name> to see if a fix helped (--json) |
rewynd watch |
Block until a matching request is recorded, then print it (--json) |
rewynd tail |
Stream requests as they arrive |
rewynd diagnose <id> |
Summarize what's wrong (N+1, exceptions, slow queries) |
rewynd last-error |
The most recent 5xx, in full |
rewynd clear |
Wipe the buffer |
rewynd status |
Is the core running, how many requests buffered |
Privacy — it's all local
No cloud, no account, no telemetry on you. The core binds 127.0.0.1 and never makes an
outbound connection. A hard prod guard refuses to start under NODE_ENV=production.
Secrets are redacted; bodies are size-capped. Your request data never leaves your machine.
How it works
your app ─(stock OpenTelemetry, configured by the shim)→ OTLP ─→ rewynd core ─→ SQLite
(HTTP :4318 · gRPC :4317) │
TUI · CLI · MCP read the same recording
The shim stands on OpenTelemetry's auto-instrumentation (you never see OTel config). The Go core is a single static binary: OTLP receiver (HTTP and gRPC) → correlation → detections → embedded SQLite, with the TUI, CLI, and MCP as thin clients over it. Any OTel-emitting service connects — gRPC is what most SDKs default to.
It scales with your project. Because correlation keys on the OpenTelemetry trace, this is
not a single-app toy: run a whole polyglot stack locally — several Node and Python services, a
worker, a gateway — all pointed at the one core. A request that fans out across services is
stitched back into one trace: the entry service is the root, and every query, outbound
call, and log is tagged with the service it ran in, so you see the whole distributed flow in
one view (runnable example). The store is a WAL'd ring buffer that
keeps the most recent requests (1000 by default); set REWYND_MAX_REQUESTS higher for a long
session or a busy app that wants to leave nothing behind.
Supported stacks
Node.js — Express, Fastify, NestJS (anything on Node's http); pg, mysql2, Drizzle,
Sequelize, Knex; fetch / axios; console, pino, winston. One command:
rewynd run <your dev command>.
Python — FastAPI, Flask, Django; psycopg2, SQLAlchemy; requests, httpx; stdlib
logging. One command: pip install rewynd && rewynd-run <your command>.
Go — go get github.com/SrinjoyDev/rewynd/sdk/go, then rewynd.Start(ctx) at boot and
standard OpenTelemetry instrumentation (otelhttp, otelsql). Go has no runtime
auto-instrumentation, so it's minimal setup rather than zero — but it feeds the same core. See
sdk/go and examples/go-service.
Any other language — Java, .NET, Ruby, PHP, Rust, … — works through its standard
OpenTelemetry auto-instrumentation. rewynd run -- <your command> sets the OTLP environment
variables, so e.g. rewynd run -- java -javaagent:opentelemetry-javaagent.jar -jar app.jar
records a JVM app with no code change. See docs/languages.md.
They all feed the same core over OTLP, so the TUI, CLI, and MCP work identically across languages — one local recorder for every backend, human or agent.
Roadmap
- [x] Zero-config capture + per-request correlation (Node, ESM/
tsx) - [x] Go core: OTLP receiver, SQLite store, N+1 detection
- [x] CLI + the agent
watchloop,rewynd runlauncher - [x] MCP server (
rewynd mcp) +mcp.jsonquickstart - [x] The live TUI (request list + waterfall)
- [x] N+1, slow-query, and slow-request detection
- [x] Header capture + redaction; outbound HTTP
- [x] Python shim (FastAPI/Flask/Django) over the same core — the multi-language unlock
- [x] Request/response body capture (redacted, size-capped)
- [x] v0.2.1 released: cross-platform binaries +
curl | shinstaller +go install - [x] Agent-native: MCP instructions +
get_stats; drop-in integrations for Claude Code, Cursor, Windsurf, OpenCode, Codex, Cline, Devin - [x] TUI control panel: live search, slow filter, scrollable enriched detail
- [x] OTLP/gRPC intake (:4317) alongside HTTP — most SDKs default to gRPC
- [x] Distributed traces: multi-service stitching with per-service attribution
- [x] Background jobs / queue consumers recorded as first-class flows (not just HTTP)
- [x] Load view:
rewynd stats+get_load_stats+ TUISpanel (throughput, p50/p95/p99, error rate, by endpoint) - [x] Go SDK (
sdk/go) —rewynd.Start(ctx)+ standard OTel instrumentation - [x] Any OTel language via
rewynd run(Java/.NET/Ruby/PHP); regression diff (stats --save/--baseline) - [x] npm (
@rewynd/cli) and PyPI (rewynd) published — install paths all live - [x] Shareable trace export:
rewynd export <id>→ a self-contained HTML page for PRs/CI - [x] Agent-value benchmark: reproducible eval showing agents debug better with the trace (
bench/agent-eval) - [ ] Zero-config shims that bundle the OTel agent for more languages (Ruby gem, Java helper)
Contributing
See CONTRIBUTING.md. The repo is a pnpm + Go monorepo: core/ (the Go
core + CLI/TUI/MCP), packages/ (the Node shim + npm wrapper + Python shim), sdk/go/ (the Go
SDK), and examples/ (express-postgres, distributed, jobs, go-service, ruby-service).
License
推荐服务器
Baidu Map
百度地图核心API现已全面兼容MCP协议,是国内首家兼容MCP协议的地图服务商。
Playwright MCP Server
一个模型上下文协议服务器,它使大型语言模型能够通过结构化的可访问性快照与网页进行交互,而无需视觉模型或屏幕截图。
Magic Component Platform (MCP)
一个由人工智能驱动的工具,可以从自然语言描述生成现代化的用户界面组件,并与流行的集成开发环境(IDE)集成,从而简化用户界面开发流程。
Audiense Insights MCP Server
通过模型上下文协议启用与 Audiense Insights 账户的交互,从而促进营销洞察和受众数据的提取和分析,包括人口统计信息、行为和影响者互动。
VeyraX
一个单一的 MCP 工具,连接你所有喜爱的工具:Gmail、日历以及其他 40 多个工具。
graphlit-mcp-server
模型上下文协议 (MCP) 服务器实现了 MCP 客户端与 Graphlit 服务之间的集成。 除了网络爬取之外,还可以将任何内容(从 Slack 到 Gmail 再到播客订阅源)导入到 Graphlit 项目中,然后从 MCP 客户端检索相关内容。
Kagi MCP Server
一个 MCP 服务器,集成了 Kagi 搜索功能和 Claude AI,使 Claude 能够在回答需要最新信息的问题时执行实时网络搜索。
e2b-mcp-server
使用 MCP 通过 e2b 运行代码。
Neon MCP Server
用于与 Neon 管理 API 和数据库交互的 MCP 服务器
Exa MCP Server
模型上下文协议(MCP)服务器允许像 Claude 这样的 AI 助手使用 Exa AI 搜索 API 进行网络搜索。这种设置允许 AI 模型以安全和受控的方式获取实时的网络信息。