Skip to page content
SAVRN
Search Plan a project

Open-weight model · Text generation

hydra-nano-git

by Rahul kumar rahul05ranjan/hydra-nano-git

hydra-nano-git is an open-weight model for text generation from Rahul kumar, released under Apache License 2.0. It has 752M parameters and a 262,144-token context. At 16-bit it needs about 1.8 GB of GPU memory, which fits on 1x MI300X from $1.85 an hour, at the lowest prices in the SAVRN Index. It draws 99 downloads a month.

A 0.75B-parameter local model that lets a coding agent hand off routine, read-only repository work. Hydra Nano is the model behind Hydra, a CLI that a frontier coding agent (Claude Code, Codex and others) calls instead of running noisy commands itself.

Parameters752M
Context262,144
Weights2.3 GB
Licenseapache-2.0
AccessOpen weights
Monthly Downloads99

Runs On

What it takes to serve hydra-nano-git (752M parameters): the memory its weights need at each precision, and the cheapest way to rent enough data-center GPUs to hold them.

PrecisionWeightsMemory neededCheapest setupPer hourAlso fits
16-bit 1.5 GB 1.8 GB 1x MI300X (192 GB)
Vultr
$1.85 1x H100 $1.99 · 1x MI325X $2.00
8-bit 0.8 GB 0.9 GB 1x MI300X (192 GB)
Vultr
$1.85 1x H100 $1.99 · 1x MI325X $2.00
4-bit 0.4 GB 0.5 GB 1x MI300X (192 GB)
Vultr
$1.85 1x H100 $1.99 · 1x MI325X $2.00

Memory is the weights at that precision plus 20% for the runtime and a short context; a long context needs more. Prices are the lowest on-demand hourly rates in the SAVRN Index, read Oct 16, 2026.

hydra-nano-git on every accelerator the SAVRN Index prices, at every precision

Model Card

By Rahul kumar, published under apache-2.0, revision 185a9a9e5005.

A 0.75B-parameter local model that lets a coding agent hand off routine, read-only repository work. Hydra Nano is the model behind Hydra, a CLI that a frontier coding agent (Claude Code, Codex and others) calls instead of running noisy commands itself. Hydra asks the model to choose from a fixed menu of read-only probes, runs those probes in code, and returns the command's own output lines. The model never writes a shell command. One model serves all five Hydra heads: All figures are end-to-end Hydra results: the task counts as solved only when the probe plan is right and the returned evidence contains every expected fact with nothing forbidden. Errors and timeouts count as failures. Every…

Read Rahul kumar's full model card

Hydra Nano

A 0.75B-parameter local model that lets a coding agent hand off routine, read-only repository work.

Hydra Nano is the model behind Hydra, a CLI that a frontier coding agent (Claude Code, Codex and others) calls instead of running noisy commands itself. Hydra asks the model to choose from a fixed menu of read-only probes, runs those probes in code, and returns the command's own output lines. The model never writes a shell command.

One model serves all five Hydra heads:

Head Job Typical question
git Repository state, history, blame, branches "which files changed in the last commit?"
files Where a symbol is defined or used "where is parseConfig defined?"
read Return one function, range or outline of a file "show login in src/auth.ts"
test Digest a failing test or build log hydra run -- npm test
os Ports, processes, disk, memory, environment "what is listening on port 5432?"
Release v2, 2026-10-14
Parameters 752,393,024
Base model Qwen/Qwen3.5-0.8B
Files model.safetensors (FP16, standard Transformers layout) and hydra-nano-git-Q8_0.gguf (llama.cpp)
Context used by Hydra 8,192 tokens
Language English
License Apache 2.0

Evaluation

All figures are end-to-end Hydra results: the task counts as solved only when the probe plan is right and the returned evidence contains every expected fact with nothing forbidden. Errors and timeouts count as failures. Every row was produced with the Q8_0 GGUF in this repository (SHA-256 6d6542c8…410be).

Head Development Held-out Notes
Git 200/200 · extended 800/800 · paraphrase 800/800 963/1,000 (96.3%) sealed git1; 96.17% usage-weighted Sealed set never used for training or tuning; only its aggregate score was read.
Files 192/200 (96.0%) 980/1,000 (98.0%) Real CPython, Node.js, Go and Rust sources.
Read 199/200 (99.5%) 961/1,000 (96.1%) Most tasks are answered by deterministic slicing with no model call.
Test 198/200 (99.0%) · extended 559/572 (97.7%) 944/1,000 (94.4%) Small failure regions are returned whole; the model is called only for long ones (24 of 1,000 held-out tasks).
OS 200/200 · extended 397/400 (99.25%) 1,000/1,000 (100%) Probe outputs are synthetic Windows/macOS/Linux fixtures, not live host runs.
  • Hardware. All rows ran locally on an Apple Silicon laptop with llama.cpp b11563. The same GGUF scored 927/1,000 on the sealed set on an NVIDIA T4 with the earlier Hydra code.
  • Latency. The median model call takes about 0.07 s for Files and OS on the Apple Silicon laptop.
  • Separation. Development, held-out and training data come from separate generators, seeds and phrasings. Held-out failures were never inspected.
  • Receipts. Every row has a JSON receipt in the Hydra repository.

Quick start

With Hydra (recommended)

One command installs a pinned llama.cpp runtime, downloads this GGUF, verifies its SHA-256 and starts a local server on port 11435:

npx --yes --package=github:rahul05ranjan/hydra hydra-install
hydra ask --head git "which branch am I on and what is modified?"
hydra run -- npm test

With llama.cpp

llama-server -m hydra-nano-git-Q8_0.gguf --alias hydra-nano:git --host 127.0.0.1 --port 8080 -c 8192

Hydra sends each request with a JSON schema (response_format), so llama.cpp constrains decoding to valid JSON. Do the same if you call the model yourself. Unconstrained output can be malformed JSON.

With Transformers

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "rahul05ranjan/hydra-nano-git"
tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(model_id, dtype=torch.float32)  # FP16 on CPU can overflow

messages = [
    {"role": "system", "content": 'Choose read-only git probes. Reply with JSON {"probes":[{"probe":...}]}. '
                                  'Probes: status, log, diff, show, blame, branches, stash, worktrees.'},
    {"role": "user", "content": "which branch am I on?"},
]
inputs = tokenizer.apply_chat_template(messages, add_generation_prompt=True, enable_thinking=False,
                                       return_tensors="pt", return_dict=True)
output = model.generate(**inputs, max_new_tokens=64, do_sample=False)
print(tokenizer.decode(output[0, inputs["input_ids"].shape[-1]:], skip_special_tokens=True))

On a GPU, use dtype=torch.bfloat16 and device_map="auto". The production prompts and probe menus are in skills/hydra/scripts/lib. The model is trained on those prompts, so a different prompt gives weaker results.

How it stays safe

  • No generated commands. The model returns a JSON choice from a fixed menu, and code builds and runs the command.
  • Read-only menus. No head can commit, push, reset, delete or write files.
  • Checked arguments. A path, revision, author or search term from the model is used only if it appears in the question and the tool confirms it exists.
  • Verbatim evidence. Results are the command's own lines. The model only chooses which lines to show, and whole lists or explicitly requested slices are returned in full.
  • Secret guardrail. The OS head refuses environment variables whose names look like keys, tokens, passwords or credentials.

These guarantees come from the Hydra CLI. If you run the model on its own, it is just a text generator.

Training

  1. Supervised fine-tuning with LoRA. Qwen3.5-0.8B was tuned on synthetic Git planning prompts in MLX and the adapter was fused into the weights.
  2. Full-parameter fine-tuning, stage 1. All 752M parameters were trained on 1,040 newly written synthetic examples covering all ten Git probes and four evidence families: 67 optimizer updates at learning rate 2e-6.
  3. Full-parameter fine-tuning, stage 2. Training continued on 1,560 more varied examples covering phrasing, filenames, authors, references and scope combinations: 62 updates at learning rate 1e-6. The total is 129 updates.

Both full-parameter stages ran on one NVIDIA T4. They used FP32 master weights, an AdamW optimizer whose state lives on the CPU, FP16 activations with gradient checkpointing, and loss on assistant tokens only.

No evaluation inputs were used for training: no sealed git1 worlds, phrasings or word lists, and no development or held-out tasks. The checkpoint's SHA-256 is 7b6b4662dbba3542fd296696b1c94e06240b28931e5b8ac6eec5cb99fc3dc8f0.

The GGUF was converted with llama.cpp convert_hf_to_gguf.py at commit a05e58c (--outtype q8_0). Converting this checkpoint again reproduces the same file byte for byte.

Limitations

  • Test head. It solves 94.4% of held-out tasks, just under the 95% target. Held-out failures are not inspected, so their causes are unknown. Read the raw log when a digest looks incomplete.
  • OS evaluation is synthetic. It tests planning and evidence on fixture outputs with the real secret guardrail. On macOS and Windows the memory probe does not yet report swap.
  • Token savings are not proven. In a 36-session trial on real repositories, Claude Opus used Hydra in 0 of 12 sessions where it was merely available. Forcing delegation used 72% more tokens on those source-extraction tasks. Hydra is a correctness-preserving offload path; it is not a proven way to save tokens.
  • Scope. The model was trained for Git planning and evidence only. Its behavior on the other heads comes from Hydra's prompts and code. It is not a general assistant, and English is the only language tested.

Intended use

Use it for: local, read-only inspection that a coding agent delegates through Hydra, on developer machines and CI runners.

Do not use it for: any operation that writes, deletes or changes state; security decisions; or answering questions without the Hydra evidence path.

Citation

@software{hydra_nano_2026,
  title  = {Hydra Nano: a local read-only coprocessor model for coding agents},
  author = {rahul05ranjan},
  year   = {2026},
  url    = {https://huggingface.co/rahul05ranjan/hydra-nano-git}
}

Configuration

Architecture
Qwen3_5ForCausalLM
Context length (tokens)
262,144
Layers
24
Hidden size
1,024
Feed-forward size
3,584
Attention heads
8
Key/value heads
2
Head dimension
256
Vocabulary size
248,320
Model type
qwen3_5_text

Identity and Version

Repository
rahul05ranjan/hydra-nano-git
Publisher
Rahul kumar
Task
Text generation
Modality
Text
Library
transformers
Parameters
752M parameters
Languages
en
Revision
185a9a9e50058322d2fc194a838f638878d7cfe2
First published
2026-10-10
Last updated
2026-10-15

Files and Weights

9 files, 2.3 GB in total. The weights are 2 files totalling 2.3 GB in gguf, safetensors.

Weights2 files · 2.3 GB
Configuration2 files · 2.0 KB
Tokenizer2 files · 20.0 MB
Documentation1 file · 10.2 KB
Other1 file · 7.8 KB
Repository1 file · 1.6 KB
Every file
FileTypeSizeSHA-256
hydra-nano-git-Q8_0.ggufWeights811.8 MB 6d6542c8afae
model.safetensorsWeights1.5 GB 7b6b4662dbba
config.jsonConfiguration1.8 KB —
generation_config.jsonConfiguration138 B —
README.mdDocumentation10.2 KB —
chat_template.jinjaOther7.8 KB —
.gitattributesRepository1.6 KB —
tokenizer.jsonTokenizer20.0 MB a5cd9732badc
tokenizer_config.jsonTokenizer1.5 KB —

License and Download

License
apache-2.0
Access
Open weights, no gate
Download size
2.3 GB
Download from Rahul kumar

Released by Rahul kumar through its official repository on Hugging Face. Read the license.

Built From

Evaluations

Each result is shown as reported, with the conditions its reporter stated. None is a SAVRN measurement. A comparison lines two results up only when their configuration, unit and setup are all stated and identical.

BenchmarkConditionsResultReported byRevisionDate
Files holdout (1,000 tasks) Task Code search term planning (Files head)Metric SolvedComparison conditions not established 98 rahul05ranjan
Publisher reported
Evaluated revision not stated —
OS holdout (1,000 tasks, synthetic probe outputs) Task Read-only OS inspection planning (OS head)Metric SolvedComparison conditions not established 100 rahul05ranjan
Publisher reported
Evaluated revision not stated —
Read holdout (1,000 tasks) Task File slicing (Read head)Metric SolvedComparison conditions not established 96.1 rahul05ranjan
Publisher reported
Evaluated revision not stated —
Test holdout (1,000 tasks) Task Test and build log digestion (Test head)Metric SolvedComparison conditions not established 94.4 rahul05ranjan
Publisher reported
Evaluated revision not stated —
git1 (sealed, 1,000 tasks) Task Read-only Git probe planning and evidence selectionMetric SolvedComparison conditions not established 96.3 rahul05ranjan
Publisher reported
Evaluated revision not stated —
git1 (sealed, 1,000 tasks) Task Read-only Git probe planning and evidence selectionMetric Solved, usage-weightedComparison conditions not established 96.17 rahul05ranjan
Publisher reported
Evaluated revision not stated —

Memory Requirements

PrecisionWeights in memory
As published2.3 GB
16-bit1.5 GB
8-bit0.8 GB
4-bit0.4 GB

Weights only, from the published parameter count; the key-value cache and runtime add to this.

Questions About hydra-nano-git

How much GPU memory does hydra-nano-git need?

About 1.8 GB at 16-bit and 0.5 GB at 4-bit: the weights (752M parameters) plus a working margin. A long context needs more.

What is the cheapest GPU to run hydra-nano-git on?

At 16-bit, 1x MI300X from $1.85 an hour; at 4-bit, 1x MI300X from $1.85 an hour, at the lowest on-demand prices the SAVRN Index lists.

Can I use hydra-nano-git commercially?

Yes. hydra-nano-git is released under Apache License 2.0. The Apache License 2.0 is a permissive open-source license. It permits commercial use, modification and redistribution. It requires keeping the license and copyright notices and any NOTICE file, stating significant changes, and it includes an express patent grant from contributors.

What is hydra-nano-git's context length?

262,144 tokens, from the maximum position embeddings in its published configuration.

Similar Models

Model · Text generation

dQwen3.5-0.8B-Base

IFML

A masked diffusion language model adapted from Qwen3.5-0.8B. The backbone is hybrid: only its attention layers are made bidirectional, and the Gated DeltaNet layers stay causal. This is a base model, with no instruction tuning. Paper: dQwen3.5: Hybrid-Attention Diffusion Language Models. Code: https://github.com/AntonXue/dQwen Needs a CUDA GPU and transformers>=5.13 (tested with torch 2.7.1+cu128, flash-linear-attention 0.5.1). generate decodes the whole canvas at once, committing positions above a confidence threshold (tau=0.9); pass blocklength=32 for left-to-right block decoding, or tau=None, stepsperblock=k for a fixed budget. The 50B-token checkpoint from the paper is…

Open weights apache-2.0 752M parameters 262,144 tokens transformers

This is a separate research bf16 LoRA adapter (r=16, alpha=32) on Qwen/Qwen3.5-0.8B, trained with Unsloth on a laptop Blackwell GPU, with a derived merged artifact also present in the repository. "Placeholder" describes release status, not absence of weights. It does not overwrite ReceiptAgent v2 Sizes were read from the Hub listing; no weight file was downloaded or hashed by this pass, and the revision SHA was not captured. The Hub-hosted banner referenced by the szl-forge card (holo-banner.svg) is not on this tree, so it is not embedded here. The training receipt records 180 training rows and train loss 0.0537. Training loss is not evaluation. The receipt describes the local laptop…

Open weights apache-2.0 752M parameters 262,144 tokens peft

Model · Text generation

petal-w1-4bit

Aayush Pokharel

petal-w1 turns raw dictation into the text you meant to type. It is the on-device cleanup model in Petal, a free macOS dictation app. It runs with MLX on Apple silicon. It is a full fine-tune of Qwen3.5-0.8B, and it does one job: - Removes fillers, stutters, false starts, and verbal tics ("you know what I mean?"). - Keeps only the final version of a self-correction ("Friday, no wait, Thursday" becomes "Thursday"), also when speech recognition mishears the correction words. - States a point once when the speaker repeats it in different words, and keeps every detail. - Condenses rambles into clear sentences, and keeps every fact, name, number, and request. - Keeps questions as questions and…

Open weights apache-2.0 752M parameters 262,144 tokens mlx

Model · Text generation

petal-w1

Aayush Pokharel

petal-w1 turns raw dictation into the text you meant to type. It is the on-device cleanup model in Petal, a free macOS dictation app. It runs with MLX on Apple silicon. It is a full fine-tune of Qwen3.5-0.8B, and it does one job: - Removes fillers, stutters, false starts, and verbal tics ("you know what I mean?"). - Keeps only the final version of a self-correction ("Friday, no wait, Thursday" becomes "Thursday"), also when speech recognition mishears the correction words. - States a point once when the speaker repeats it in different words, and keeps every detail. - Condenses rambles into clear sentences, and keeps every fact, name, number, and request. - Keeps questions as questions and…

Open weights apache-2.0 752M parameters 262,144 tokens mlx

Model · Text generation

qwen3p5-0p8b-medical-mlp5

Aditya G

Qwen/Qwen3.5-0.8B fine-tuned directly (no LoRA/adapters) on medical reasoning data, to turn a general-purpose model into a domain-focused one. Overfitting to the training data was an accepted trade-off of this experiment; the goal was to study the training/validation loss behaviour. Loss is computed on the assistant response only (reasoning + answer); the prompt is masked. Best validation loss at epoch. See losscurve.png for train vs validation loss. - Research into domain adaptation, partial fine-tuning, and overfitting behaviour of small models. - Offline experimentation with medical-style question answering and reasoning formats. - Clinical decision support, diagnosis, treatment…

Open weights apache-2.0 752M parameters 262,144 tokens transformers

Model · Text generation

ThinCtx-Qwen3.5-0.8B

Thinletter

ThinCtx by thinletter. ThinCtx-Qwen3.5-0.8B is the ThinCtx conversion of Qwen3.5-0.8B that keeps the GPU memory for the context small: it grows 20 to 30 times more slowly than the base model's cache (0.43 GB instead of 6.0 GB at half a million tokens). The part of the context kept on the GPU is small and grows slowly with the length of the conversation or document; the full context is kept in ordinary system memory. ThinCtx trades some speed for this (see Speed below). Chat and tool calling use the Qwen3.5 chat template. Runtime required. ThinCtx models run on the thinctx runtime (pip install thinctx, below). The runtime is what keeps the context memory small; other inference libraries do…

Open weights other 752M parameters 262,144 tokens thinctx