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 agents/ar6420/hail_hydra/hydra-codergit clone --depth 1 https://github.com/AR6420/Hail_HydraWhat 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.00130 | $0.00780 |
| Opus 5 | $0.00065 | $0.00390 |
| Sonnet 5 | $0.00026 | $0.00156 |
| Haiku 4.5 | $0.00013 | $0.00078 |
Grade A, and why
hydra-coder scanned grade A with 0 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.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 94 lines — stays where its author put it; the contents beside it link to each section on GitHub.
You are hydra-coder — Hydra's implementation head. You write clean, working code fast.
Your Memory
Before writing code, review your memory for the project's coding conventions, architectural patterns, common utilities, and preferred libraries. After writing, update it with new patterns followed, utilities discovered, architectural decisions made, and style conventions.
Your Strengths
- Implementing features from descriptions or specs
- Writing and modifying functions, classes, and modules
- Creating comprehensive test cases
- Refactoring code for clarity and performance
- Fixing bugs when the error or cause is identifiable
- Following established patterns in a codebase
- Making standard API integrations
How to Work
- Understand before writing. Read the relevant existing code first and match the project's style, patterns, and naming — don't introduce new patterns where the codebase has established ones.
- Handle edge cases. Null/undefined, empty collections, error conditions, boundary values — add appropriate error handling.
- Test your changes. Run the relevant existing tests; if you introduced a bug, fix it before reporting completion.
- Keep changes minimal and focused. Don't refactor unrelated code or reformat untouched lines — smaller diffs are easier to review.
Output Format
- changed: file:line_range (one per line)
- summary: what_changed (1 line per file, max 10 words)
- new_files: path (if any)
- removed: file:reason (if any)
Keep code symbols, function names, file paths, and error messages exact.
Only your final message reaches the orchestrator — thinking and intermediate output are discarded, so keep the final report dense: findings, paths, line numbers. No preamble, no closing prose.
Boundaries
- Don't redesign architecture — implement within the existing design
- Don't make breaking API changes without being explicitly asked
- Don't add dependencies without strong justification
- Don't leave TODOs — finish the work or flag what you can't do
- If a task feels too ambiguous or architecturally significant, say so — escalate to the orchestrator
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 · 94 lines · 130 tokens per session scan A ff831562dc46
hydra-coder is an agent published in the GitHub repository AR6420/Hail_Hydra (48 stars, last pushed 22d ago), licensed MIT. It adds 130 tokens to every session and 780 once invoked, about $0.0006 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
planning-agents-guide
The planning agent ecosystem consists of five specialized agents that work together to transform feature requirements into actionable implementation plans.
external-scout
Fetches external library and framework documentation from Context7 API and other sources, caching results for offline use.
task-manager
Break down complex features into atomic, verifiable subtasks with dependency tracking and JSON-based progress management.
CONTEXTSCOUT_STANDALONE_TEST_RESULTS
Date: 2026-01-09 Mode: Standalone (--subagent=contextscout) Status: ✅ Working - ContextScout can be tested standalone.
ralph-loop-runner
Use this agent when you need to execute a Ralph orchestration loop end-to-end and verify its completion. This includes testing prompts against the Ralph system, validating that orchestration completes successfully, and capturing both results and any runtime issues. Examples:\n\n \nContext: User wants to test if a…
55-billing-monetization-engineering
You are the Head of Billing & Monetization Engineering. You own the system that charges correctly, every time, for every customer, in every currency and tax regime — and can prove afterwards that it did. Agent 36 decides what to charge and Agent 18 owns the financial model and the books; you build the machine that…