api-verification

Model Citizen

Privacy

Data and external services in the Claude Directory plugin

The plugin does not contact a Model Citizen-operated service. Some workflows can contact other services when you ask Claude Code to perform the corresponding work:

• git and gh can send repository content and metadata, issue or pull-request text, and related account information to GitHub or the remote you configured.
• Web-capable roles can send URLs and search queries through Claude Code's WebFetch and WebSearch tools to retrieve public web content.
• A workflow can use another tool or service you explicitly choose for the task.

These actions are user-directed, remain subject to Claude Code's native permissions, and are governed by the selected service's terms and privacy policy. The plugin has no background data transmission. See the privacy policy for the boundary between this plugin and the separately installed harness.

The control plane for your coding agents, however you run them.

Model Citizen is the layer under your coding agents. You write your rules, skills, roles and stances once, as your own primitives. The harness projects them into Claude Code and Codex, enforces them with hooks, and keeps a ledger of what every session did and spent. It sits under whatever rules library you like and whatever orchestration you run, so you can change how your agents work without changing how you run them.

Every file it touches goes in an ownership journal, and uninstall puts things back. The same ledger exports over OTLP to Langfuse, Phoenix or Opik, off by default.

Model Citizen is not an LLM API gateway, a model provider or a replacement agent runtime. Claude Code and Codex remain responsible for model access, native permissions and client behavior.

What it does for you

The same six groups are held as data in product.json, so this list, the reference site and the GitHub description cannot drift apart.

Guardrails that leave room for judgment

Hooks handle the few things that should be deterministic, and each has an id you can switch off; the four that enforce need your acknowledgement first. Everything else stays the agent's call.

• Graded shell commands: Every command is graded from read-only to irreversible, and your autonomy stance, plus any per-repository levels in a local policy, decides which grades stop and ask.
• Stop gate: The turn doesn't end while your repo's own gate is red.
• Fresh-context review: Scope is checked against the ask, then quality, by agents that never saw the code, and a framework's own review spawns are held to that whatever they call themselves.
• Secrets and personal data: Lint catches tokens, keys and personal strings before they're committed.
• Untrusted tool output: Text that comes back from a tool is data, never instructions.
• Sandboxing: Fence the filesystem and network before you leave a loop unattended.

Settings you own, on every runtime you run

Sync keeps a journal of what it changed and refuses to overwrite what it does not own. Uninstall puts it back. The same rules then go to both runtimes.

• Reversible: Sync has a dry run, diff shows drift, an ownership journal records prior and applied values, and uninstall restores what it adopted.
• Shared primitives: Rules, skills, roles and workflows live in one place and sync into both runtimes, leaving out any you switch off. Skills also install as a Claude Code or Codex plugin.
• Same policy on both: A Claude Code spawn and a Codex spawn resolve to the same delegation policy.
• Declared integrations: A planning framework declares itself in one descriptor. bin/citizen integration check|apply installs its overrides, and the spawn hook confines its review layers.
• Honest compatibility: The catalog says which clients are qualified and where the gaps are: two runtimes today, and the headline does not claim more.
• Worktrees and workspaces: Each agent works in its own worktree and claims the paths it writes. Your .code-workspace files decide which repositories a session sees, instructions included.

See and steer what your agents spend

A hard cap cuts an agent off after it has already spent the tokens. I'd rather tell it what things cost and let it pace itself.

• Cost postures: Pick frugal, balanced or max, or write your own. One table sets model, effort and a soft budget per role.
• Model tiering: Roles ask for a capability class, one of frontier, strong, standard and light, not a model name. Gathering files doesn't run on the model that reviews your code.
• Band workers: A spawn that names no role gets a right-sized worker instead of your most expensive model.
• A budget in every brief: Each subagent is told its expected tokens and tool calls. Finish if you're close, otherwise return what you have.
• Live usage feed: The orchestrator sees what each turn and each subagent cost, and hears once when its context passes the size your stance sets. A decision log records what a hook decided.
• Lean context: Always-loaded instructions are capped at 225 lines, and lint fails the commit past that. Noisy tool output is filtered before it lands in the transcript.

Answers and plans you can actually read

Most agent output is a wall of text. This puts the verdict first and the ask where you can find it.

• Voice stances: Choose concise, answer-card or scannable. Same content, shaped for how you read.
• Scannable output style: Verdict first, action items in one place, and status in plain words: Fixed, Partially fixed, Not fixed, Unverified.
• Review Card plans: Every plan opens with a one-screen card and stops at a build gate until you say build.
• Bounded subagent returns: Subagents come back with findings and a word cap, not their whole transcript.
• Conciseness rules: Explain a decision once. Comments say why, not what.

Rules you can measure, and prune

Every project in this field writes instructions and hopes. Here a rule nobody can observe is a rule nobody can prune, and lint says so before the commit lands.

Every rule names a deterministic detector over the agent's own transcript, or says in one line why nothing i