Rebadge bundle qwen35 -> qwen36 + doc the workaround

Re-flip general.architecture in the bundled Q4_K_M GGUF to qwen36, the architecturally-honest label. Reverses f0d70ee (which itself reverted 2dbe526). No released llama.cpp / Ollama recognizes qwen36 yet (reconfirmed 2026-05-19 against llama.cpp 389ff61 + Ollama 0.24.0), so the bundle is unloadable on stock loaders until upstream adds the arch entry. README/Modelfile/CHANGELOG updated with the qwen36 -> qwen35 rebadge workaround (scripts/rename_arch.py is metadata-only, tensor data byte-identical). Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

CHANGELOG.md

@@ -7,6 +7,27 @@ and documentation**, not the underlying base model.
 
 ## [Unreleased]
 
+### Changed
+- **BREAKING (loaders).** Bundle re-stamped from
+  `general.architecture: 'qwen35'` to `'qwen36'` — the
+  architecturally-honest label. No released llama.cpp / Ollama
+  recognizes `qwen36` yet (reconfirmed 2026-05-19 against llama.cpp
+  389ff61 and Ollama 0.24.0), so `ollama run hf.co/FoolDev/Thanatos-27B`
+  and direct `llama-server -m Thanatos-27B.Q4_K_M.gguf` both fail with
+  `unknown model architecture: 'qwen36'` until upstream adds the entry.
+  To load *today*, rebadge to qwen35 locally with
+  `scripts/rename_arch.py --from-arch qwen36 --to-arch qwen35` — see
+  the README "Architecture" section for the one-liner. Tensor data
+  stays byte-identical; only metadata flips. Reverses prior commit
+  `f0d70ee` which had restored qwen35 for compatibility; deliberate
+  re-flip with eyes open about the breakage.
+- README "Heads up" callout near the top of the model card, TL;DR,
+  loader matrix, Quick start Ollama block, and Modelfile preamble
+  all updated to flag the qwen36 stamp and point users at the
+  rebadge workaround. Quick-start option B (`make build` from
+  unsloth) called out as the loads-today path, since unsloth still
+  ships qwen35-stamped GGUFs.
+
 ### Added
 - README "Vision via llama.cpp" subsection now leads with the
   `llama-server --mmproj` HTTP path (always built into stock llama.cpp,

Modelfile

@@ -6,11 +6,22 @@
 # Ollama uses when an mmproj is attached). Use llama.cpp directly for
 # image input, or wait for the fix. See the Vision section in README.md.
 #
-# This repo bundles a single GGUF: Thanatos-27B.Q4_K_M.gguf (~17 GB).
-# The FROM line below points at it, so a fresh clone (with LFS smudge
-# enabled) supports the no-script path:
+# This repo bundles a single GGUF: Thanatos-27B.Q4_K_M.gguf (~17 GB),
+# stamped `general.architecture: 'qwen36'`. The FROM line below points
+# at it, but no released llama.cpp / Ollama recognizes `qwen36` yet, so
+# `ollama create thanatos-27b -f Modelfile && ollama run thanatos-27b`
+# fails today with `unknown model architecture: 'qwen36'`. To load now,
+# rebadge the bundle to `qwen35` first:
 #
-#     ollama create thanatos-27b -f Modelfile && ollama run thanatos-27b
+#     python3 scripts/rename_arch.py --from-arch qwen36 --to-arch qwen35 \
+#         Thanatos-27B.Q4_K_M.gguf Thanatos-27B.Q4_K_M.qwen35.gguf
+#     # then temporarily point FROM at the qwen35 file, or use:
+#     #   echo "FROM $PWD/Thanatos-27B.Q4_K_M.qwen35.gguf" > /tmp/Modelfile.qwen35
+#     #   ollama create thanatos-27b -f /tmp/Modelfile.qwen35
+#
+# Once upstream adds the qwen36 arch entry the workaround disappears
+# and the FROM line below works as-is. See README "Architecture" for
+# the full story.
 #
 # For other quants (Q3_K_S, Q5_K_M, Q6_K, etc.), `make build QUANT=Q3_K_S`
 # downloads the chosen quant from unsloth/Qwen3.6-27B-GGUF and patches

README.md

@@ -61,6 +61,15 @@ pipeline_tag: image-text-to-text
 
 A personal sibling to [`FoolDev/Janus-35B`](https://huggingface.co/FoolDev/Janus-35B). Same teacher (Claude Opus 4.7), same dataset family, but built on the **dense** [Qwen/Qwen3.6-27B](https://huggingface.co/Qwen/Qwen3.6-27B) base instead of the 35B-A3B MoE. Smaller, easier to deploy, no expert-routing surprises.
 
+> ⚠️ **Heads up — bundle is stamped `qwen36`.** As of 2026-05-19 the
+> bundled GGUF declares `general.architecture: 'qwen36'`, which no
+> released llama.cpp / Ollama recognizes yet. `ollama run
+> hf.co/FoolDev/Thanatos-27B` and `llama-server -m
+> Thanatos-27B.Q4_K_M.gguf` both fail today with `unknown model
+> architecture: 'qwen36'`. To load now, rebadge locally to `qwen35`:
+> see [Architecture](#architecture) for the one-liner. Once upstream
+> ships qwen36 the workaround disappears.
+
 ## TL;DR
 
 One-liner via Hugging Face (pulls a GGUF + this repo's root-level
@@ -69,12 +78,16 @@ template — HF's Ollama bridge ingests those three files, not
 `Modelfile`):
 
 ```bash
-ollama run hf.co/FoolDev/Thanatos-27B           # ~17 GB Q4_K_M (the only bundled quant)
+ollama run hf.co/FoolDev/Thanatos-27B           # ~17 GB Q4_K_M, qwen36-stamped (see Heads-up above)
 ```
 
+That command fails today with `unknown model architecture: 'qwen36'`
+until you rebadge locally — see [Architecture](#architecture).
+
 For other quants (Q3_K_S ~12 GB, Q5_K_M ~20 GB, etc.), `make build
-QUANT=Q3_K_S` downloads from `unsloth/Qwen3.6-27B-GGUF` and creates the
-local Ollama tag. See [Quick start](#quick-start) below.
+QUANT=Q3_K_S` downloads from `unsloth/Qwen3.6-27B-GGUF` (which still
+ships `qwen35`-stamped GGUFs) and creates the local Ollama tag.
+See [Quick start](#quick-start) below.
 
 Or build locally (uses this repo's `Modelfile`, kept in sync with the
 three bridge files) for any quant:
@@ -131,16 +144,18 @@ The 27B is **dense**: every parameter participates in every forward pass. It's s
 | `README.md` | This file |
 
 This repo ships a single GGUF to back the HF/Ollama "Use this model"
-widget — `Thanatos-27B.Q4_K_M.gguf` (~17 GB):
+widget — `Thanatos-27B.Q4_K_M.gguf` (~17 GB, qwen36-stamped):
 
 ```bash
-ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M (only bundled quant)
+ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M, qwen36 — fails today, see Heads-up above
 ```
 
-For 16 GB GPUs / unified-memory laptops, `make build QUANT=Q3_K_S`
-downloads the smaller ~12 GB Q3_K_S quant from `unsloth/Qwen3.6-27B-GGUF`
-and creates a local `thanatos-27b` Ollama tag (does not redistribute via
-this repo).
+For 16 GB GPUs / unified-memory laptops — and as a working-today
+fallback while the bundle waits on upstream qwen36 support —
+`make build QUANT=Q3_K_S` downloads the smaller ~12 GB Q3_K_S quant
+from `unsloth/Qwen3.6-27B-GGUF` (qwen35-stamped, loads on every
+current llama.cpp / Ollama build) and creates a local `thanatos-27b`
+Ollama tag. Does not redistribute via this repo.
 
 For other quants or local builds, pull from
 [`unsloth/Qwen3.6-27B-GGUF`](https://huggingface.co/unsloth/Qwen3.6-27B-GGUF)
@@ -169,39 +184,42 @@ If you want the safetensors for `transformers`, fetch them from [`Qwen/Qwen3.6-2
   current loader compatibility.
 - Multi-token prediction (MTP) head trained for speculative decoding
 
-The bundled GGUF declares `general.architecture: 'qwen35'`, not
-`'qwen36'`, on purpose. Upstream `ggml-org/llama.cpp` and `ollama/ollama`
-both register Qwen 3.5 and Qwen 3.6 under the same `qwen35` / `qwen35moe`
-arch tags because the hybrid SSM + attention stack is shared between
-the two generations — there is no separate `qwen36` arch entry in
-either project (checked 2026-05-19, master / main respectively).
-Rebadging the GGUF to `qwen36` makes it unloadable (`error loading
-model architecture: unknown model architecture: 'qwen36'`).
-`scripts/rename_arch.py` is in the repo for the day that changes
-upstream — flipping `qwen35 → qwen36` (or back) is a metadata-only
-operation, tensor data stays byte-identical.
-
-Want to retest the qwen36 path on your machine? Smudge LFS, then:
+**The bundled GGUF declares `general.architecture: 'qwen36'`** — the
+architecturally-honest stamp. Upstream `ggml-org/llama.cpp` and
+`ollama/ollama` currently only register the hybrid SSM + attention
+stack under `qwen35` / `qwen35moe`; no `qwen36` arch entry exists yet
+(reconfirmed 2026-05-19 against llama.cpp 389ff61 and Ollama 0.24.0).
+Consequence: **the bundle is unloadable on current stock loaders.**
+`ollama run hf.co/FoolDev/Thanatos-27B` and `llama-server -m ...` both
+fail with `error loading model architecture: unknown model
+architecture: 'qwen36'` (Ollama 0.24 surfaces it as a 500 wrapping a
+generic `unable to load model: <blob>` — check `journalctl --user -u
+ollama` for the underlying line).
+
+This is intentional. The bundle is the *correct* metadata; the
+loaders are the lagging side. The flip is reversible until upstream
+catches up — go the other direction locally with
+`scripts/rename_arch.py` (metadata-only, tensors stay byte-identical):
 
 ```bash
+# Get the bundle in a loadable state on today's llama.cpp / Ollama:
 python3 scripts/rename_arch.py \
+    --from-arch qwen36 --to-arch qwen35 \
     Thanatos-27B.Q4_K_M.gguf \
-    Thanatos-27B.Q4_K_M.qwen36.gguf
-# Use an absolute path — ollama resolves a relative FROM against the
-# Modelfile's directory, not your CWD, so `FROM ./...` in /tmp/ fails
-# with a misleading 400 / "unable to load model" before the loader runs.
-echo "FROM $PWD/Thanatos-27B.Q4_K_M.qwen36.gguf" > /tmp/Modelfile.qwen36
-ollama create test-qwen36 -f /tmp/Modelfile.qwen36
-ollama run test-qwen36 hi
+    Thanatos-27B.Q4_K_M.qwen35.gguf
+# Then either build a local Ollama tag (note absolute path —
+# `ollama create` resolves a relative FROM against the Modelfile's
+# directory, not your CWD):
+echo "FROM $PWD/Thanatos-27B.Q4_K_M.qwen35.gguf" > /tmp/Modelfile.qwen35
+ollama create thanatos-27b -f /tmp/Modelfile.qwen35
+ollama run thanatos-27b hi
+# …or point llama-server at the qwen35 file directly:
+llama-server -m Thanatos-27B.Q4_K_M.qwen35.gguf -ngl 99 -c 8192
 ```
 
-Today that last line errors with `500 Internal Server Error: unable
-to load model: <blob path>`. The CLI no longer surfaces the arch
-name; check `journalctl --user -u ollama` (or wherever your server
-logs go) for the underlying `error loading model architecture:
-unknown model architecture: 'qwen36'`. The day that line succeeds is
-the day the bundle can be flipped (reconfirmed 2026-05-19 against
-Ollama 0.24.0).
+Once upstream adds the `qwen36` arch entry — patch landed in
+`ggml-org/llama.cpp` and propagated into Ollama — the bundle works
+as-is and the workaround above can be deleted.
 
 ## Quick start
 
@@ -211,10 +229,13 @@ Two paths:
 
 ```bash
 # A. Pull straight from HF (uses the bundled Q4_K_M + root-level
-#    template / system / params files):
-ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M (only bundled quant)
+#    template / system / params files). Fails today with
+#    `unknown model architecture: 'qwen36'`; see Architecture for
+#    the qwen36 → qwen35 rebadge workaround.
+ollama run hf.co/FoolDev/Thanatos-27B           # 17 GB Q4_K_M, qwen36-stamped
 
-# B. Build locally for a different quant (downloads from unsloth):
+# B. Build locally for a different quant (downloads qwen35-stamped
+#    GGUFs from unsloth — these load on today's llama.cpp / Ollama):
 make build                                              # Q4_K_M  -> thanatos-27b
 make build QUANT=Q3_K_S                                 # 12 GB smaller quant
 make build QUANT=Q5_K_M                                 # 20 GB higher quality
@@ -240,12 +261,16 @@ python examples/ollama_chat.py      # full demo: chat, streaming, tools, OpenAI-
 
 ### Local apps
 
-The bundled `Thanatos-27B.Q4_K_M.gguf` works in any GGUF-compatible local
-app — point it at this repo and load.
+The bundled `Thanatos-27B.Q4_K_M.gguf` is `qwen36`-stamped — every row
+below assumes you've rebadged it to `qwen35` per
+[Architecture](#architecture), or that you're pulling a `qwen35`-stamped
+GGUF from `unsloth/Qwen3.6-27B-GGUF` instead. The "fails today with
+`unknown model architecture: 'qwen36'`" caveat applies to every row
+until that's done.
 
 | App | How to load this model |
 |---|---|
-| **Ollama** | `ollama run hf.co/FoolDev/Thanatos-27B` (default Q4_K_M). Pulls the GGUF + the root-level `template` / `system` / `params` files in one step (HF's Ollama bridge ingests these three files; it does **not** read `Modelfile`). For other quants, `make build QUANT=Q3_K_S` downloads from unsloth and creates a local Ollama tag using the `Modelfile`, which is kept in sync with the bridge files. |
+| **Ollama** | `ollama run hf.co/FoolDev/Thanatos-27B` (default Q4_K_M). Pulls the GGUF + the root-level `template` / `system` / `params` files in one step (HF's Ollama bridge ingests these three files; it does **not** read `Modelfile`). For other quants, or to bypass the qwen36 block today, `make build QUANT=Q3_K_S` downloads from unsloth (qwen35-stamped) and creates a local Ollama tag using the `Modelfile`, which is kept in sync with the bridge files. |
 | **LM Studio** | Search → `FoolDev/Thanatos-27B` → pick `Thanatos-27B.Q4_K_M.gguf`. Uses the GGUF's embedded jinja chat template (Qwen 3.6 ChatML); set the system prompt manually from the `SYSTEM` block in this repo's `Modelfile`. |
 | **Jan** | Hub → "Import from Hugging Face" → `FoolDev/Thanatos-27B`. Same template behavior as LM Studio. |
 | **llama.cpp** | `hf download FoolDev/Thanatos-27B Thanatos-27B.Q4_K_M.gguf --local-dir .` then `llama-server -m Thanatos-27B.Q4_K_M.gguf` (or `llama-cli`, `llama-mtmd-cli` for vision via the upstream `mmproj-F16.gguf`). |

Thanatos-27B.Q4_K_M.gguf

@@ -1,3 +1,3 @@
 version https://git-lfs.github.com/spec/v1
-oid sha256:5ed60d0af4650a854b1755bd392f9aef4872643dc25a254bc68043fa638392a0
+oid sha256:b2b63b941d714b0aff5e9afc9b337e7607b84e371ba991c182d92d0f7805c0e9
 size 16817244384