modelexpress
AGENTS.md202 starsChanged 31 days agoApache-2.0View on GitHub
Rust-based model cache management service and GPU-to-GPU weight transfer system using NVIDIA NIXL over RDMA. This file holds the always-on rules for every AI coding agent working in this repository. Multi-step procedures live as skills under .agents/skills/ and load on demand. Both are shared across tools: Edit AGENTS.md or the skill; never add a tool-specific copy. When a section here grows into a procedure, move it to a skill and list it below. Reference documentation: - docs/ARCHITECTURE.md - Project structure,…
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,542 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository6 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .github/copilot-instructions.mdCopilot instructions
- add-cli-argumentSkill
- add-grpc-serviceSkill
- bump-versionSkill
- dcoSkill
The file
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
13 rules. About 0 are common, 9 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 25
All cargo dependencies go in the root Cargo.toml.
- Distinctive: line 28
No emojis in code or comments.
- Distinctive: line 29
Do not create markdown files to document code changes or decisions.
- Distinctive: line 30
Do not over-comment code. Removing code is fine without adding comments to explain why.
- Distinctive: line 31
Use mermaid diagrams instead of ASCII art in markdown files.
- Distinctive: line 32
Prefer established crates over hand-rolled implementations.
- Distinctive: line 51
Run pre-commit after every code change, even before creating commits:
- Very specific: line 77
Every commit must carry a Signed-off-by: Real Name <email> trailer.
- Very specific: line 78
Use the contributor's real name and the email configured in git config user.name / user.email.
- Very specific: line 80
Do not add Co-Authored-By or tool-attribution trailers.
- Distinctive: line 85
Always read files to understand context before making changes.
- Distinctive: line 86
Do not implement changes eagerly.
- Distinctive: line 94
When making changes, update the appropriate documentation files:
≈ “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.
Files
ModelExpress
Rust-based model cache management service and GPU-to-GPU weight transfer system using NVIDIA NIXL over RDMA.
This file holds the always-on rules for every AI coding agent working in this repository. Multi-step procedures live as skills under .agents/skills/ and load on demand. Both are shared across tools:
| Tool | Always-on rules | Skills |
| Codex | AGENTS.md (native) | .agents/skills/ (native) |
| Cursor | AGENTS.md (native) | .agents/skills/ (native) |
| Claude Code | CLAUDE.md imports this file via @AGENTS.md | .claude/skills/<name> symlinks into .agents/skills/<name> |
| GitHub Copilot | Coding agent reads AGENTS.md; Copilot Chat is pointed here by .github/copilot-instructions.md | via AGENTS.md pointers below |
Edit AGENTS.md or the skill; never add a tool-specific copy. When a section here grows into a procedure, move it to a skill and list it below.
Reference documentation:
docs/ARCHITECTURE.md- Project structure, crate catalog, gRPC services, server internals, Python client, NIXL integrationdocs/DEPLOYMENT.md- Configuration reference, Docker, Kubernetes, Helm, P2P transfer setup, debuggingCONTRIBUTING.md- Development setup, available commands, pre-commit hooks, environment variables, DCOdocs/CLI.md- CLI tool usage, commands, output formats, integration examples
Coding Standards
unwrap()is strictly forbidden except in benchmarks.expect()is allowed in tests. Always handle errors withmatch,?, or custom error types.- All cargo dependencies go in the root
Cargo.toml. Sub-crates use workspace dependencies exclusively. Never editCargo.tomlorCargo.lockby hand to add or update dependencies - usecargo addso you always get the latest version. - Python dependencies go in
pyproject.toml. Never edit dependency files by hand - useuv addso you always get the latest version. cargo clippymust pass with no warnings.- No emojis in code or comments.
- Do not create markdown files to document code changes or decisions.
- Do not over-comment code. Removing code is fine without adding comments to explain why.
- Use mermaid diagrams instead of ASCII art in markdown files.
- Prefer established crates over hand-rolled implementations. Check existing workspace dependencies before adding new ones.
Build and Test Commands
cargo build # Build
cargo build --release # Release build
cargo test # Run all tests
cargo clippy # Lint (must pass, no warnings)
cargo run --bin modelexpress-server # Run server
cargo run --bin config_gen -- --output model-express.yaml # Generate config
cargo run --bin test_client -- --test-model "google-t5/t5-small" # Test client
cargo run --bin fallback_test # Fallback test
cargo bench # Criterion benchmarks
./run_integration_tests.sh # Integration tests (starts server)Pre-commit Hooks
Run pre-commit after every code change, even before creating commits:
pre-commit run # Staged files only
pre-commit run --all-files # All files (recommended after significant changes)Hooks: cargo fmt, cargo clippy (--fix), cargo check, trailing whitespace, end-of-file, YAML/TOML/JSON validation, merge conflict detection, large file check.
Procedures (skills)
Load the matching skill before starting any of these. Each is a SKILL.md under .agents/skills/:
| Task | Skill |
| Add or change a client CLI argument or env var | add-cli-argument |
| Add a gRPC service | add-grpc-service |
| Bump the release version or public-image tags | bump-version |
| Commit sign-off and DCO repair | dco |
Git Workflow
Feature branches use <username>/feature-name format, forked from main.
Commits and DCO
- Every commit must carry a
Signed-off-by: Real Name <email>trailer. Always commit withgit commit -s. The DCO check is required CI and fails the PR otherwise. - Use the contributor's real name and the email configured in
git config user.name/user.email. Check both before committing on an unfamiliar machine. - Preserve existing trailers when amending, rebasing, squashing, or cherry-picking. Use
git rebase --signofforgit cherry-pick --signoffonly when the person running the command is the one certifying the change. - Do not add
Co-Authored-Byor tool-attribution trailers. - See the DCO section of
CONTRIBUTING.mdfor the full policy.
Tips
- Always read files to understand context before making changes.
- Do not implement changes eagerly. When discussing a problem or new feature, investigate thoroughly first, report findings, propose changes, and ask if they are acceptable before writing code.
- Flush Redis on redeploy: stale metadata causes P2P transfer failures.
- Long startup times are normal: DeepSeek-V3 takes ~40 min to warm up.
- Set
UCX_LOG_LEVEL=DEBUGfor NIXL/RDMA diagnostics. - NIXL agents must match ranks: source rank 0 -> target rank 0.
Documentation Updates
When making changes, update the appropriate documentation files:
| Change type | Files to update |
| Architecture, components, NIXL, gRPC services | docs/ARCHITECTURE.md |
| Coding standards, build commands, new patterns, agent rules | AGENTS.md (the only agent-instruction file; CLAUDE.md and .github/copilot-instructions.md are pointers) |
| CLI arguments or commands | docs/CLI.md + .agents/skills/add-cli-argument/SKILL.md |
| Configuration, environment variables | docs/DEPLOYMENT.md |
| Deployment (Docker, K8s, Helm, P2P) | docs/DEPLOYMENT.md |
| Known issues, FP8 handling | docs/ARCHITECTURE.md |
| Dev setup, scripts, pre-commit hooks | CONTRIBUTING.md |
| Contribution process, DCO | CONTRIBUTING.md |
| New binary targets, crates, Python modules | docs/ARCHITECTURE.md |
| Version-bump procedure changes | .agents/skills/bump-version/SKILL.md |
| Agent procedures (multi-step how-tos) | .agents/skills/<name>/SKILL.md + the Procedures table in AGENTS.md |
A feature is incomplete until documentation is updated.
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
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.

