Model card: verified Python default + vLLM caveat, fragilities, before/after A/B

README.md

@@ -1,59 +1,171 @@
 ---
 license: other
 base_model: Qwen/Qwen3.6-35B-A3B
-library_name: peft
-tags: [lora, offensive-security, pentesting, tool-calling, cyberstrike]
+library_name: transformers
+tags: [offensive-security, pentesting, tool-calling, cyberstrike, qwen3]
 pipeline_tag: text-generation
 ---
 
 # CyberStrike-OffSec-35B
 
-Offensive-security / autonomous-pentesting agent on **Qwen3.6-35B-A3B**. Ships as a **LoRA adapter**;
-two serving formats of the same adapter are supported.
+Autonomous offensive-security / pentesting agent fine-tuned on **Qwen3.6-35B-A3B**. This model emits
+**real, structured tool calls** with correct agent routing and clean termination — the behaviours a
+tool-calling harness actually needs.
+
+This release ships as a **single-piece merged checkpoint** (load with one command). A LoRA adapter
+is also available for `--enable-lora` serving (see *Serving → Adapter*).
+
+---
+
+## What this fine-tune actually is (and isn't)
+
+Set expectations honestly. This is a **small, targeted alignment**, not a capability upgrade:
+
+- **It did NOT** add security knowledge — the base Qwen3.6 already knows offensive-security
+  concepts, and already emits tool calls (22/24 in our eval).
+- **It DID** teach the model to emit tool calls *in the exact format a CyberStrike harness expects*,
+  route to *valid agent archetypes* instead of internal codenames, handle real observations without
+  fabricating them, and terminate cleanly.
+
+In other words: we did not make the model *smarter* — we **aligned it to the harness** and **fixed
+the specific collapse** of the previous version. Trained on a deliberately small **300-example**
+dataset (one round), so gains are concentrated in tool-use behaviour, not broad capability. Broader
+robustness is the goal of the next data iteration (Stage-2). We state this plainly so a returning
+user knows exactly what changed and why.
+
+---
+
+## Why this release exists — measured before/after
+
+The previous CyberStrike model failed in production: users reported "broken tool calling,"
+"simulated executions," and "faked engagements." We reproduced and root-caused those failures in a
+controlled 24-scenario A/B evaluation (6 axes × 3 difficulty tiers, 62% out-of-distribution), then
+fine-tuned to fix them. Every number below is grounded in **raw model output**, not auto-scored
+heuristics.
+
+| Metric (24 scenarios) | Base Qwen3.6 | **Previous model** | **This model** |
+|---|---|---|---|
+| Genuine structured tool calls | 22/24 | **0/24** | **18/24** |
+| Correct tool / archetype | 6/24 | 2/24 | **10/24** |
+| Clean termination | 21/24 | **3/24** | **24/24** |
+| Fabricated observations | none | **widespread (8+ scen.)** | **none** |
+
+**What the previous model did (concrete):** instead of a structured call it wrote prose such as
+`**Action 1:** Task(GHOST…)`, then invented its own tool output — fake `curl` / SSL handshakes /
+Nmap scans / `Set-Cookie: sessionid=abc…` and even fabricated flags — and never terminated, in
+**both** bf16 and q8. It *looked* like it was working (it narrated a whole engagement) while
+executing nothing. This is the exact behaviour behind the user reports.
+
+**What this model does:** emits a genuine `<tool_call><function=Task>` with a valid archetype
+(e.g. `web-application`, `explore`) and terminates with `<|im_end|>`. The base model *does* emit
+calls, but routes with internal codenames ("GHOST") rather than valid archetypes — the routing this
+fine-tune specifically corrected.
+
+### What the 24 scenarios tested
+
+Six axes, each at easy → medium → hard difficulty, weighted 62% toward out-of-distribution prompts
+(unseen target names, novel phrasing) to separate genuine generalization from memorized patterns:
+
+| Axis | What it checks |
+|---|---|
+| **Tool selection** | picks the right tool for the phase; prefers dedicated tools over `bash` equivalents |
+| **Argument typing** | emits correct types — `steps` stays an int `50`, `headless` stays a bool `true` |
+| **Real-observation handling** | reads an actual tool result and acts on it; on empty/unexpected output it pivots instead of fabricating |
+| **Loop / termination** | stops when the task is done; no runaway or crash on multi-step tasks |
+| **Sub-agent delegation** | delegates to the correct archetype; does not invent agent names |
+| **Parallel tool calls** | batches independent work; does not spam hundreds of calls |
+
+The two axes the previous model collapsed on hardest — real-observation handling (it fabricated) and
+termination (it looped) — are the two this model scores cleanest on.
+
+The previous model has been **withdrawn** from active serving: its broken merged weights were
+**removed** from this repo, and its GGUF build was **gated** with a deprecation notice, so new users
+don't unknowingly pull the broken version.
+
+---
 
 ## Serving
 
-### ✅ Default: base + adapter (recon-safe)
+`main` is the **single-piece merged checkpoint**; the LoRA adapter alone (169 MB) is on the
+`adapter` revision.
+
+### ✅ Default — Python (verified)
+
+The one-command load below was verified on this hardware: the merged checkpoint loads and, on the
+tested scenarios, emits genuine structured tool calls and terminates cleanly.
+
+```python
+from transformers import AutoModelForImageTextToText, AutoTokenizer
+model = AutoModelForImageTextToText.from_pretrained("oyildirim/CyberStrike-OffSec-35B")
+tok   = AutoTokenizer.from_pretrained("oyildirim/CyberStrike-OffSec-35B")
+```
+Pass the tools via `tok.apply_chat_template(messages, tools=TOOLS, add_generation_prompt=True)`; the
+model emits Qwen3 XML tool calls (`<tool_call><function=…><parameter=…>`).
+
+### ⚙️ vLLM (single-piece merged) — not verified on this hardware
+
+```bash
+vllm serve oyildirim/CyberStrike-OffSec-35B \
+  --enable-auto-tool-choice --tool-call-parser qwen3_xml --max-model-len 8192
+```
+> **Caveat — unverified.** This model's architecture (`qwen3_5_moe`) is only supported by recent vLLM
+> (0.25.1+), which requires a **CUDA-13-compatible** build/driver. It could not be run on our test
+> hardware (CUDA 12.8). The `qwen3_xml` parser and schema-driven typing (`steps`→int, `headless`→bool)
+> were verified in isolation, but the end-to-end vLLM serve was **not** verified here. Expected to
+> work on a CUDA-13-capable box; confirm on your setup before relying on it.
+
+### ⚙️ Adapter — base + LoRA (`@adapter` revision)
+
+For keeping the base pristine or stacking adapters. Python (verified path):
+```python
+from transformers import AutoModelForImageTextToText
+from peft import PeftModel
+base  = AutoModelForImageTextToText.from_pretrained("Qwen/Qwen3.6-35B-A3B")
+model = PeftModel.from_pretrained(base, "oyildirim/CyberStrike-OffSec-35B", revision="adapter")
+```
+vLLM equivalent (same CUDA-13 caveat as above):
 ```bash
 vllm serve Qwen/Qwen3.6-35B-A3B --enable-lora \
-  --lora-modules cyberstrike=oyildirim/CyberStrike-OffSec-35B \
+  --lora-modules cyberstrike=oyildirim/CyberStrike-OffSec-35B@adapter \
   --enable-auto-tool-choice --tool-call-parser qwen3_xml --max-model-len 8192
 ```
-Tool-call format is Qwen3 XML → use `--tool-call-parser qwen3_xml` (schema-driven typing verified:
-ints stay ints, bools stay bools). Python: load base with `AutoModelForImageTextToText`, then
-`PeftModel.from_pretrained(base, "oyildirim/CyberStrike-OffSec-35B")`.
 
-### ⚙️ Viable alternative: merged single-piece (conditional)
-Merging the adapter into the base gives a single-piece checkpoint (and is the only route toward a
-q8 GGUF). A full 24-scenario A/B found the merged model clean (0/24 non-termination). **If you serve
-merged, do both:** (a) always pass the **full tool schema** at inference, and (b) enable a
-**stop-safeguard** (`repetition_penalty` ≈ 1.1 or a hard stop token). Merged weights are not hosted
-here yet — see *Known fragilities* for why the default is base+adapter.
+> **Do not** call `AutoModelForImageTextToText.from_pretrained(...@adapter)` directly on the adapter
+> revision — load base + adapter as shown. **Always pass the full tool schema at inference** (see
+> *Known fragilities*).
+
+---
 
 ## Known fragilities (read before deploying — no "broken" surprises)
-Both serving formats are prompt-sensitive in **one narrow region each**; on the representative
-24-scenario suite each fails at most once:
-- **base+adapter:** can degenerate on a **credentials-array crawl** prompt (repeats a token instead
-  of emitting the call). Recon is safe.
-- **merged:** can degenerate on **terse recon + a minimal tool set** (e.g. "Do passive recon on X"
-  with only the `Task` tool → runaway inside the tool-call `prompt` field, no termination). Changing
-  the target/phrasing OR passing the full tool set makes it clean — and production serving always
-  passes the full tool set, so this rarely occurs. The default base+adapter path avoids it entirely.
-
-Also: occasional tool over-generalization and a rare invalid sub-agent name on out-of-distribution
-inputs. All of the above are Stage-2 dataset targets. No clean q8 GGUF yet (adapter-based; q8
-pipeline deferred to Stage-2).
-
-## A/B validation
-Against the previous CyberStrike model, this adapter emits **real structured `<tool_call>`s and
-terminates cleanly** (23–24/24) where the previous model wrote tool calls as prose, fabricated tool
-observations (fake curl/SSL/Nmap output), and failed to terminate — in both bf16 and q8.
+
+On the representative 24-scenario suite the merged model has **0/24** non-termination. It has one
+**narrow** out-of-suite trigger: a *terse recon prompt with a minimal (single-tool) schema* — e.g.
+"Do passive recon on X" when only the `Task` tool is offered — can send greedy decoding into a
+repetition loop inside the tool-call `prompt` field. **Changing the phrasing OR passing the full
+tool set makes it clean**, and production serving always passes the full tool set, so this rarely
+occurs in practice. Mitigations if you hit it: keep the full tool schema, and/or set
+`repetition_penalty ≈ 1.1` or a hard stop token.
+
+Also observed on out-of-distribution inputs: occasional tool over-generalization and a rare invalid
+sub-agent name. All of the above are targets for the next data iteration (Stage-2).
+
+---
 
 ## Training
-LoRA r=32 / α=64, targets = full-attn (q/k/v/o) + **GDN linear-attn (in_proj_\*/out_proj)** + MLP
-(310 modules, 42.3M params); routed experts / MoE router / vision tower excluded. 300 multi-turn
-tool-call SFT examples, 3 epochs, sdpa, eval token-accuracy 98.5%.
 
-## ⚠️ Deprecated files
-Any full merged `*.safetensors` shards previously in this repo are the **old (broken) model** and
-should not be used — serve base+adapter as above.
+LoRA **r=32 / α=64**, targets = full-attention (q/k/v/o) + **GDN linear-attention
+(in_proj_\*/out_proj)** + MLP — **310 modules, 42.3 M trainable params**. Routed experts, the MoE
+router, and the vision tower are excluded (routing and multimodal behaviour left intact). 300
+multi-turn tool-call SFT examples, 3 epochs, sdpa attention. Held-out token accuracy 98.5%.
+
+Merge is verified correct layer-by-layer (uniform ~0.0016 bf16 rounding error across all groups
+including the GDN layers; no merge bug).
+
+---
+
+## Intended use & limitations
+
+For authorized offensive-security testing and research only. The model reasons about attack
+methodology and emits tool calls for a pentesting harness; it does not itself execute anything.
+Users are responsible for operating only against systems they are authorized to test. Not a
+substitute for a qualified security professional.