cendor-sdk
A governed agent in 10 lines. cendor-sdk is a thin, provider-agnostic agent SDK where
governance — budgets, tamper-evident audit, PII redaction, record/replay testing — is the
foundation, not a plugin. Local-first · no servers · Apache-2.0. Available for
Python (pip install cendor-sdk) and TypeScript/JavaScript (npm i @cendor/sdk).
Building with Copilot, Claude Code, or Cursor? The SDK ships inline Type Teach and a paste-in trap sheet → For AI assistants, or wire it in one command with
npx @cendor/init/uvx cendor-init.
A first look
A budget-capped run in both languages — the answer comes back with a real cost receipt, and an over-budget call never fires:
from cendor.sdk import Agent, run, budget
agent = Agent(name="assistant", model="gpt-4o", instructions="Be helpful.")
with budget(usd=0.10, on_exceed="block"): # pre-flight cap — refused if the call would exceed
result = run(agent, "Summarize today's standup notes.")
print(result.output, result.cost) # the answer + Decimal money, never a float
import { Agent, run, withBudget } from '@cendor/sdk';
const agent = new Agent({ name: 'assistant', model: 'gpt-4o', instructions: 'Be helpful.' });
const result = await withBudget({ usd: 0.10, onExceed: 'block' }, () => // pre-flight cap — refused if it would exceed
run(agent, "Summarize today's standup notes."));
console.log(result.output, result.cost?.toString()); // the answer + decimal money, never a float
That’s one governance layer; Getting started wires up all four — budget, audit, PII guard, and record/replay — in ten lines.
Which door do I need?
Cendor is production plumbing for LLM applications, and there are two front doors into it:
- The libraries — plumbing beneath your framework. Already using LangChain,
LlamaIndex, or a provider SDK directly? Keep it, and compose the libraries underneath with one
instrument()wrap. cendor-sdk(these docs) — the whole loop, governed. Starting fresh, or don’t want to pick a framework and wire libraries together? The SDK gives youAgent,tool, andrunwith every governance layer one import away.
Both doors expose the same primitives — budget, Policy, AuditLog, trace are the real
library objects, re-exported, and guard is acttrace’s policy enforcement in the SDK’s scope
form. Start on the SDK and drop down to the libraries later (or mix them in the same process);
it’s continuous, never a migration.
Already using LangChain, LlamaIndex, or a provider client directly? Keep it — compose the seven libraries underneath with one instrument() wrap. Libraries docs →
Starting fresh, or don't want to wire a framework together? The SDK gives you Agent, tool, and run with every governance layer one import away. (These docs.)
Pages
| Page | What it covers |
|---|---|
| Getting started | Install, a first governed agent, and where each concept lives. |
| Architecture | The two layers — the loop on top, the seven libraries beneath — and where each library is used in the SDK. |
| For AI assistants | SDK-specific call-shape traps + the four ways (Type Teach, rules files, MCP, init) to make your assistant fluent. |
| Agents & the loop | Agent, tool, run, Result, structured output, streaming, multimodal. |
| Governance | Budgets, spend attribution, audit + redaction, record/replay testing. |
| Guardrails | Agent(guardrails=[…]) — a deterministic gate at four stages (input / tool call / tool output / output). |
| Memory & sessions | Session, durable stores, summarization, fitting memory to the window. |
| Retrieval (RAG) | Governed embeddings, VectorIndex, always-on and agentic retrieval. |
| Multi-agent | Handoff, supervisor, pipelines — one correlated, governed tree. |
| Providers | The ten provider paths, Hugging Face / Microsoft Foundry (formerly Azure AI Foundry) / Foundry Local setup, pricing custom models. |
| Ecosystem & interop | MCP tools, A2A, Foundry/Copilot, OpenTelemetry, human-in-the-loop. |
| Production hardening | Retries, checkpointed/resumable runs, durable memory. |
| Eval & regression testing | Replay recorded trajectories as CI tests — behaviour and spend. |
| FAQ | Common questions, including “libraries or SDK?” in depth. |
What “governed” means here
Five production concerns ride every run without per-call wiring, because the SDK executes each
model and tool call through cendor-core’s event bus. Each concern is owned by one
of the libraries the SDK bundles — the SDK adds no governance logic of its own, it just wires them
to the loop:
- Cost —
budget(...)caps a run before an over-budget call executes;track(...)attributes spend per feature/user for free. Owned by tokenguard. - Safety —
Agent(guardrails=[…])gates input / tool calls / tool output / output with deterministic checks: block (fail-closed, pre-spend at input), redact, or flag. Owned by cendor-guardrails. - Evidence — an
AuditLogrecords every step in a tamper-evident hash chain you canverify()offline. Owned by acttrace. - Privacy —
guard(Policy...)redacts PII before the provider ever sees it. Also acttrace. - Testability —
cassetterecords a run once and replays it forever: offline, deterministic, free. Owned by cassette.
Context assembly is governed too: Agent(context_budget=…) fits history to a token budget through
contextkit (squeeze compression engages via direct contextkit
use, not the SDK’s trim path). The full map of which SDK surface each library powers:
| SDK surface | Library | Learn more |
|---|---|---|
Agent(context_budget=…) — fit history to a token budget | contextkit (squeeze via direct contextkit use) | /docs/contextkit, /docs/squeeze |
budget() / track() / price estimation | tokenguard | /docs/tokenguard |
Agent(guardrails=[…]) / rules.* — the four-stage gate | cendor-guardrails | /docs/guardrails |
guard(Policy…) / AuditLog / decision() | acttrace | /docs/acttrace |
cassette record/replay / EvalCase | cassette | /docs/cassette |
the event bus / instrument() / provider detection | cendor-core | /docs/core |
The full per-library map — every SDK symbol, the library beneath it, and where each library plugs
into the loop — lives on Architecture. These are seven libraries: the six
governance tools above plus the cendor-core foundation they all ride.
Every layer is optional — an ungoverned run() works with just cendor-core installed.
Install
pip install "cendor-sdk[openai,anthropic]" # Python — provider SDKs are optional extras
# Using uv? Same names, same extras: `uv add` instead of `pip install`.
npm i @cendor/sdk openai # TypeScript/JS — providers are peer dependencies
Full install options, extras, and the first runnable example: Getting started. Language parity (what’s ported, what’s Python-only): /docs/languages.
Design principles
- Cooperate through core. The SDK hard-depends only on
cendor-core; every governance tool integrates through core’s bus and interceptor seams — nothing patches anything. - Governed by default, escapable. Each layer is one argument or one
withblock; removing it never breaks the loop. - Local-first, no servers. Sessions, checkpoints, audit chains, and cassettes are local files. Cloud and OpenTelemetry export are optional and opt-in.
- Same API in both languages.
snake_case↔camelCase, identical defaults and error names — see the parity matrix.
See the CHANGELOG (opens in a new tab) for release history.