SANNR.

An API client
that gets better
with every lesson.

And it shows its work. Every lesson your agents record about an API goes into your repo with the date and where it came from, so anyone on the team can open it and check.

In our accumulation experiment, cold agents averaged 1.06 incidents a session. Warm agents, which inherited the notes from the sessions before them, averaged 0.06: one trap hit in 16 sessions. One small service, one planted trap, and both arms finished every task. Read the experiment

public alpha

Install it with one prompt.

Paste this into Claude Code or Codex from your repository root:

Install Sannr in this repository. From the repo root, run `npx --yes @sannr/sannr@alpha connect` and follow what it prints. It adds the Sannr skills, registers its MCP server and adds a short pointer block to AGENTS.md / CLAUDE.md. Then run `npx --yes @sannr/sannr@alpha doctor` and show me the result. doctor announces one GET to https://api.github.com/zen before sending it, so I can see the API client work (use `--offline` to skip it). Everything is stored on this machine and in this repo: no account, no Sannr server, no telemetry. If it asks for a restart, tell me; when I reopen the agent here I'll say "Finish sannr setup." What it does: https://sannr.dev/install
See exactly what it does

Questions? Ask in the Sannr Discord.

the receipts

Better, and
you can check.

“Gets better” means something you can open. Every lesson sits under the API operation it belongs to, with who recorded it and when. Here’s one operation from a made-up refunds API, with two lessons on it.

"POST /v1/refunds": {
  "effect": "write",
  "notes": [
    "Refunds above the original charge return 422, not the 400 the contract lists.",
    "A second refund with the same Idempotency-Key returns 409 and the first refund's id."
  ],
  "notes_provenance": [
    { "by": "agent", "at": "2026-10-02" },
    { "by": "agent", "at": "2026-10-06" }
  ],
  "noted_at": "2026-10-06",
  "noted_by": "agent"
}

Illustrative example, not a real API. Field names are the ones Sannr writes today.

what it is

Two tools,
one folder.

The map and the client are the tools; the .sannr folder is what they remember. It holds your API knowledge, its settings and the skills, committed with your code. Setup also puts what your agent needs where it looks: the MCP registration (.mcp.json, .codex/config.toml), copies of the skills, and a short pointer block in AGENTS.md and CLAUDE.md.

A map.

Point it at a repository and it inventories the APIs it finds: the services, the routes it recognizes, who calls whom, and routes your code implements that the contract leaves out. The map is generated from your files, offline, without calling anything.

The folder.

The knowledge file, .sannr/stacks/sannr.json, records what agents observe about each operation: response shapes, the enum values a contract declares, the gotchas the documentation omits, and the decisions no traffic ever reveals, such as why an integration was rejected. It is committed with the code, so it travels with the repository.

A client.

A request client your agent calls through MCP or the command line. It sends the request, applies your credentials from environment references, returns a bounded result with the assertions you asked for, and records what it observed. The client makes the calls; the folder is what it remembers.

how it works

Import. Verify.
Deliver.

How it works, in detail

Import what you already have.

Sannr reads Postman and Bruno collections, and seeds operations from an OpenAPI contract. Every import comes with a loss report. Scripts are never executed during an import; review the report and the generated suite before you run anything.

Verify against the running service.

Read-only checks record what is actually true about each operation: the status codes seen, the field names and types, the drift between the contract and the server. Field values are never recorded unless the contract itself declares them; request and response bodies, headers and credentials never are.

Deliver it where the agent already reads.

The lessons agents record are listed, each with its operation, in the instruction files your agent loads at the start of a session, so a new session has them in view without being told to go and look.

who it's for

Teams that
ship with agents.

Sannr is for developers and teams who use coding agents to build and integrate APIs: your own services, and everyone else's. If an agent on your team has ever re-discovered the same undocumented precondition a colleague hit last month, that is the problem. Sannr is additive. Keep your API client, your collections and your specs. It sits beside them and keeps what the next developer or agent needs to know.

It works today with Claude Code and Codex, on Node 22 or newer.

teams

Rolling this out
to a team?

We're working closely with a few teams during the alpha. Tell us what you're building and we'll get in touch.

We'll use this to get in touch and to send Sannr updates.

what stays put

No accounts. No telemetry.
Nothing phones home.

Sannr has no account to create and sends nothing to us. Credentials are referenced by environment variable name; the configuration stores the name, never the value. Recorded knowledge holds field names and types, and only the values a contract declares. Request evidence stays in a local folder that Sannr's own .gitignore keeps out of the repository. The API knowledge, its settings and the skills in the .sannr folder are what's meant to be shared, and they are designed to be safe to commit.

on the record

What's true
today.

Sannr is Old Norse for “true,” so we stick to what we can show. Here is what the public alpha does today.

It keeps what your agents learn. Once Sannr has an OpenAPI file for an API, it saves what your agents record about that API in your repo, with the date, the operation it belongs to and where it came from, and makes it available to the next session.

It brings in your collections. A Postman or Bruno collection becomes a runnable suite with a loss report. Review both before you run anything.

It sends nothing to us. No account, no Sannr server, no telemetry.

When we publish a number, we publish the experiment behind it. Read the findings.

questions

Questions,
answered.

What is Sannr?
An API client that remembers, built for coding agents such as Claude Code and Codex. What your agents learn about an API is kept beside the code, with the date, the operation it belongs to and where it came from, and made available to the next session. Public alpha on npm as @sannr/sannr@alpha. No pricing yet.
How do I install it?
Paste the prompt at the top of this page into Claude Code or Codex from your repository root. What each part does, step by step: sannr.dev/docs
Is this the .NET validation library called Sannr?
No. That is an unrelated open-source project. This Sannr is sannr.dev, an API client that remembers, for teams using coding agents to build and integrate APIs.
Do I have to drop my API client?
No. Keep the collections and tools you already use. Sannr imports them and sits beside them.
Which agents does it work with?
Claude Code and Codex, through an MCP server and a command line. It needs Node 22 or newer on macOS or Linux; native Windows isn't supported yet.
What does it import?
Postman and Bruno collections, as runnable suites with a loss report to review before you run them, and OpenAPI contracts.
Do I need an OpenAPI spec?
Not to install it or make calls. Sannr starts remembering an API once it has an OpenAPI file for it: the vendor's published spec, or one your agent drafts from your code or docs. The map lists the routes it recognizes in your code, a starting point for that draft.
Does it send anything to you?
No. Everything is stored on your machine and in your repo: no account, no Sannr server, no telemetry. Credentials are referenced by environment variable name and never stored. The team form on this page is the only thing here that talks to us.
What gets committed to my repository?
The .sannr folder: the knowledge file, configuration that names environments and credential variables, and the skills your agent uses. Setup also registers the MCP server in your agent's config (.mcp.json, .codex/config.toml), copies the skills to where each agent reads them, and adds a short pointer block to AGENTS.md and CLAUDE.md. Local request evidence is ignored by Git.
How is this different from writing a markdown file?
A well-kept markdown file works. Sannr is the thing that produces and maintains that file from what your agents observe and record, with the date, the operation it belongs to and where each note came from. We have not yet measured Sannr against a hand-kept file, and we say so.
What is an API client for coding agents?
An API client built for the agent to call, rather than for a person clicking through a UI. The agent uses it as a tool: it sends the request, fills in your credentials from environment variable references and returns a short result with the assertions the agent asked for. Sannr also saves what the agent learns about each API to your repo, so the next session starts with it.
How do I stop my coding agent repeating the same API mistake?
Write the lesson down where the next session will read it, next to the code. Sannr saves each lesson on the API operation it belongs to, with the date and where it came from. It lists recorded lessons in the instruction files the agent loads when a session starts, and returns them with the result whenever an agent calls that operation again.
How do I give Claude Code context about my API?
Claude Code reads CLAUDE.md at the start of every session, so what it needs to know about your API has to be there or somewhere CLAUDE.md points. Start from what you already have: an OpenAPI file and your Postman or Bruno collections. With Sannr, one prompt from the repo root adds its skills, registers its MCP server and adds a short pointer block to AGENTS.md and CLAUDE.md. Once Sannr has an OpenAPI file for an API, what the agent learns about it is kept in the repo.
Is Sannr an MCP server?
Partly. It includes an MCP server, which is how Claude Code and Codex call it, and the same client runs from a terminal as sannr request. What your agents learn is kept in a plain .sannr folder in your repository, not inside the server.
Is Sannr a Postman alternative?
Not a replacement. It works beside Postman: keep using Postman, and bring your collections in too. Sannr turns them into runnable suites your agent can use, with a loss report that names anything it couldn’t carry over. Once Sannr has an OpenAPI file for an API, what your agents learn about it is kept in your repo.
How do you pronounce it?
SAH-ner. Old Norse sannr, meaning “true.”

tune in

Catch the
next drop.

who

Built by a developer
who kept walking over to Joe.

Sannr is built by Sterling Chin in the San Francisco Bay Area. He writes about APIs, coding agents and the knowledge that never makes it into the docs on LinkedIn and X.