agentleFS
vizuhvizuh/sabi/AGENTS.md

sabi

AGENTS.md17 starsChanged 56 days agoMITView on GitHub

Begin every response with VIZUH. On Hugo's host, read the HugoOS root AGENTS.md first; this file is the project overlay for this repository. Sabi is a Vizuh product: adaptive inference scheduling for AI agents — per-round routing of model, effort and provider across a coding-agent trajectory, while the host harness keeps its own loop.

The file

We split this AGENTS.md into the rules it gives an agent

1 rule. About 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Keep docs short and true; TODO — ask Hugo beats invented detail.

    line 29

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

Sabi — agent instructions

Begin every response with VIZUH. On Hugo's host, read the HugoOS root AGENTS.md first; this file is the project overlay for this repository.

Sabi is a Vizuh product: adaptive inference scheduling for AI agents — per-round routing of model, effort and provider across a coding-agent trajectory, while the host harness keeps its own loop.

Repository

Where things live

  • docs/context.md — what Sabi is, constraints, risks
  • docs/decisions.md — running decision log (template: www/_shared/templates/workflow/docs/decisions.md)
  • docs/handoff.md — current status; update at the end of meaningful work
  • docs/research/ — verified external research (prior art, harness capabilities)
  • docs/research/public-installation-plan.md — public CLI, daemon, host integration and release gates
  • log.md — append-only change log; one entry per meaningful change set
  • Current code groups: packages/core, packages/server, packages/controller, packages/evals, and packages/adapters/{command-code,deepseek-harness,hermes,oh-my-pi,opencode,orca,prime-agent}.

Working rules

  • Verified vs unverified is explicit. Cite exact repos, commits, dates and observed numbers for upstream claims. Never invent benchmarks, model capabilities, pricing or quota behavior — verify against live sources or label the claim unverified.
  • Read installed runtimes before designing adapters. Harness docs drift from releases (Prime Agent is a known example); the installed contract wins over copied upstream syntax.
  • Keep the harness loop native. Sabi schedules inference rounds; it does not fork or patch a host harness beyond its supported extension surface.
  • Secrets never enter Git. Provider keys live in the environment only; no credentials, cookies or raw usage logs in the repo.
  • Delivery discipline. Push deliberately; a local commit is not delivery and a push is not a deployment. No external publication without explicit approval.
  • Keep docs short and true; TODO — ask Hugo beats invented detail.

Current controller and release boundary

  • sabi setup --hooks and sabi hooks install install the experimental Claude, Codex and OpenCode controller bridges. They fail open when Sabi is unavailable. On the borrowed-authentication route Sabi may choose which model inside a subscription serves a round — the harness keeps its own credential and keeps sending it, and Sabi forwards it. It does not change entitlement, does not add a second credential, and does not spend money the harness was not already entitled to spend.
  • sabi replay --last=<n> is read-only telemetry aggregation; it does not re-run historical tasks or compile policy lessons.
  • The root controller remains a private monorepo workspace, while npm run build:controller produces the separate @vizuh/sabi-controller public-package staging artifact. The @vizuh/sabi (v*) tag release still publishes only the packaged Command Code adapter; controller changes ship via controller-v* tags and DSH via dsh-v* tags.
  • Report controller support as separate evidence layers: source/tests, merged GitHub state, installed-config mutation, live host activation, and real cross-terminal execution. Do not promote one layer into another.
<!-- SPECKIT START -->

For additional context about technologies to be used, project structure, shell commands, and other important information, read the current plan at specs/001-evidence-aware-scheduler/plan.md

<!-- SPECKIT END -->

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.