Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add instructions/deliveryhero/asya/agents-mdgit clone --depth 1 https://github.com/deliveryhero/asyaWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.04405 | $0.04405 |
| Opus 5 | $0.02202 | $0.02202 |
| Sonnet 5 | $0.00881 | $0.00881 |
| Haiku 4.5 | $0.00441 | $0.00441 |
Grade C, and why
asya AGENTS.md scanned grade C with 2 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Downloads and executes remote codehighSupply chain
curl | sh runs whatever the server returns today, which is not necessarily what it returned when this was reviewed.
**Prerequisites**: uv (`curl -LsSf https://astral.sh/uv/install.sh | sh`), Go 1.24+, Python 3.13+, Docker, Make Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
**Prerequisites**: uv (`curl -LsSf https://astral.sh/uv/install.sh | sh`), Go 1.24+, Python 3.13+, Docker, Make How it starts
The opening of the file, as written. The whole thing — 362 lines — stays where its author put it; the contents beside it link to each section on GitHub.
AGENTS.md
AI developer guidance for the Asya project.
Project Overview
Asya is an Actor Mesh framework for running AI workloads on Kubernetes using choreography (decentralized) instead of centralized orchestration. Actors communicate by passing envelopes through message queues; routing is embedded in each envelope, not managed by a central coordinator. Implemented with Crossplane Compositions for declarative actor deployment with inline sidecar rendering.
Core components (all in src/):
- asya-sidecar (Go): envelope router injected into actor pods; Queue → Sidecar → Runtime → Sidecar → Next Queue
- asya-runtime (Python): lightweight socket server loaded via ConfigMap; executes user handler,
returns result. Source of truth:
src/asya-runtime/asya_runtime.py(single file, no deps).deploy/helm-charts/asya-crossplane/files/asya_runtime.pyis a symlink — editing the source automatically reflects in the Crossplane chart's ConfigMap. No manual sync needed. - asya-gateway (Go): optional MCP/HTTP gateway; exposes async actor pipelines as synchronous HTTP
- asya-crew (Python): system actors —
x-sink(persist results),x-sump(DLQ handling),x-pause(checkpoint envelope to S3 and signalpaused),x-resume(restore envelope from S3 and re-inject into the mesh) - asya-lab (Python): CLI tools (
asya mcp ...,asya flow ...) for debugging and flow compilation - asya-testing (Python): shared test fixtures and utilities
- asya-state-proxy (Go): optional sidecar that gives actors virtual persistent state via filesystem
emulation; actors read/write
/state/...paths, runtime intercepts Python file I/O and forwards to the proxy over Unix socket; proxy translates to actual storage backend (S3, GCS, Redis, NATS KV) with configurable LWW or CAS guarantees; actors remain stateless Deployments — no StatefulSets
Project structure:
asya/
├── src/
│ ├── asya-gateway/
│ ├── asya-sidecar/
│ ├── asya-runtime/
│ ├── asya-crew/
│ ├── asya-testing/
│ └── asya-cli/
├── deploy/helm-charts/
│ ├── asya-crew/ # pre-built generic actors (like x-sink, x-sump)
│ ├── asya-crossplane/ # contains AsyncActor XRD
│ └── asya-gateway/ # sync stateful HTTP gateway exposing actors and flows as MCP tools or A2A agents
├── testing/
│ ├── component/ # docker-compose
│ ├── integration/ # docker-compose
│ ├── e2e/ # local kind cluster
│ └── shared/ # shared docker-compose configurations
└── examples/
│ ├── asyas/ # sample XR definitions
└── flows/ # sample Python flows
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 362 lines · 4,405 tokens per session scan C eddd9b21a8d8
asya AGENTS.md is an instructions file published in the GitHub repository deliveryhero/asya (59 stars, last pushed 6d ago), licensed Apache-2.0. It adds 4,405 tokens to every session, about $0.0220 per session on Opus 5. A static security scan graded it C with 2 findings (downloads and executes remote code, makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other instructions, from other repositories
superplane AGENTS.md
AGENTS.md instructions for superplanehq/superplane, covering repository guidelines, project overview, repository layout, prerequisites & setup and build, test & lint commands.
superplane CLAUDE.md
Claude Code instructions for superplanehq/superplane, a project described as: Open source factory for one-shot engineering.
netdata AGENTS.md
AGENTS.md instructions for netdata/netdata, covering agents.md, goals, requirement language, mandatory development principles and sow system.
agent-sandbox AGENTS.md
Instructions for kubernetes-sigs/agent-sandbox, covering agents.md, project summary, repository layout, agent skills and build, test, lint.
agent-sandbox copilot-instructions.md
Instructions for kubernetes-sigs/agent-sandbox: Project Context & Architecture: Refer to AGENTS.md for full project background, module layout, toolchain versions, and core conventions.
sortie copilot-instructions.md
Instructions for sortie-ai/sortie, covering sortie coding & review standards, 1. layered imports (downward only; violation is critical), 2. concurrency safety, 3. workspace path safety (critical: security boundary) and 4. persistence (sqlite).