---

license: apache-2.0

language:

• en
• zh
• multilingual

tags:

• gguf
• qwen3
• qwen3.6
• reasoning
• coding
• academic-writing
• uncensored
• rys
• lora
• iq4_nl
• bf16

base_model:

• jackasda211233/Qwen3.6-27B-AEON-RYS-15-20-GGUF
• AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored

---

Qwen3.6 AEON RYS SignalLatch GGUF

> 👁️ Vision Support Added — This model now supports image input! Download a mmproj projector file from the file list and add --mmproj to enable vision. See the Vision Support section below for details.

This is a merged fine-tuned GGUF upgrade candidate for the existing AEON RYS 15/20 Q4NL release.

Important runtime requirement: this model is built for the custom AEON ik-llama fork:

https://github.com/noonr48/qwen36-aeon-ik-llama

Use that fork with Jinja and DeepSeek reasoning formatting. This is not a stock llama.cpp GGUF release.

> Newer release available — Qwen3.6-27B-AEON-RYS-Agentic-Coder-PatchCode: an agentic-coder behaviour distil built on top of this SignalLatch release. Try PatchCode first if you want a coding-agent-tuned model.

Vision Support (mmproj)

> This model supports vision/image input. Qwen3.6-27B is natively a vision-language model. Download one of the mmproj (multimodal projector) files below and pass it with --mmproj to enable image understanding.

The projector is extracted from the official Qwen/Qwen3.6-27B base model. Since text fine-tuning does not modify the vision encoder, one projector works across all three RYS variants (base, SignalLatch, PatchCode).

Download a projector

| File | Precision | Size | Link |

|---|---|---:|---|

| mmproj-Qwen3.6-27B-base-f32.gguf | F32 (full precision) | 1.8 GB | ⬇ Download |

| mmproj-Qwen3.6-27B-base-f16.gguf | F16 (half precision) | 885 MB | ⬇ Download |

| mmproj-Qwen3.6-27B-base-q8_0.gguf | Q8_0 (8-bit quantized) | 601 MB | ⬇ Download |

Recommended: mmproj-Qwen3.6-27B-base-f16.gguf — best balance of quality and size.

Usage

Add --mmproj to your llama-server command:

./build/bin/llama-server -m Qwen3.6-27B-AEON-RYS-Agentic-Coder-PatchCode.IQ4_NL.gguf \
  --mmproj mmproj-Qwen3.6-27B-base-f16.gguf \
  --jinja -ngl 999 -c 200000

Then send images via the standard OpenAI-compatible API:

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"messages":[{"role":"user","content":[
    {"type":"image_url","image_url":{"url":"data:image/jpeg;base64,..."}},{"type":"text","text":"Describe this image"}
  ]}]}'

For higher-resolution images, add --image-max-tokens 16384 (default is 4096). Requires an ik-llama / llama.cpp build from May 2026 or later with Qwen3VL mtmd support.

Quick File Pick

| File | Use | Size | Notes |

|---|---|---:|---|

| Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Lite-Mixed-Q4NL.gguf | default practical download | about 16 GB | smaller replacement for the original Q4NL-style release; stronger on the newer agentic/codebase tests |

| Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Plus-Mixed-Q4NL.gguf | best practical quality | about 18 GB | strongest all-around mixed-quant candidate from the latest real-world tests |

| Qwen3.6-27B-AEON-RYS-SignalLatch-ckpt386-s010-IQ4_NL.gguf | original baseline | about 16.6 GB | first published SignalLatch Q4NL-style artifact, kept for comparison and reproducibility |

| Qwen3.6-27B-AEON-RYS-SignalLatch-ckpt386-s010-BF16.gguf | source-quality artifact | about 57.6 GB | use for inspection, re-quantization, or downstream work, not normal inference |

Documentation + Lineage

Historical fine-tune HTML breakdown for the original ckpt386-s010 SignalLatch baseline, covering the merge, test process, strength choice, and practical coding-agent checks:

https://noonr48.github.io/qwen36-aeon-ik-llama/ckpt386-s010-testing-process/index.html

SignalLatch release overview:

https://noonr48.github.io/qwen36-aeon-ik-llama/qwen36-aeon-rys-signallatch/index.html

SignalLatch v1.1 production quantization process and release-candidate breakdown:

https://noonr48.github.io/qwen36-aeon-ik-llama/signallatch-v1-1-production-process/index.html

Base non-finetuned HTML breakdown, covering the AEON RYS 15/20 model this was built from:

https://noonr48.github.io/qwen36-aeon-ik-llama/qwen36-aeon-rys-15-20/index.html

The base record explains how the underlying AEON RYS 15/20 model was made and selected before this SignalLatch behavior merge: layer selection, RYS transformation, quantization-survival checks, runtime profile, practical-test notes, caveats, and why the release centered on the IQ4_NL GGUF. This model card is the quick download/runtime page; the linked records are where the full build and testing details live.

For future planned RYS and RYS fine-tune releases, this is the expected pattern: a concise model card for use, plus public companion records for transparency.

Project Positioning

SignalLatch keeps the same practical local-worker goal as the base AEON RYS Q4_NL release: capable, functional local models that fit realistic hardware and can get work done without getting in the way. The reproducible 24 GB-class SignalLatch profile we have logged is -c 65536 with FP16 KV at about 20.8 GiB on a single RTX 3090. A larger 160k total-context FP16 KV profile fits a 32 GB RTX 5090 reference at about 27.5 GB VRAM, but should not be read as a 24 GB-class memory claim.

The difference is behavior. SignalLatch is a minimal behavior fine-tune on top of the AEON RYS Q4_NL path, aimed at coding-agent reliability rather than broad benchmark chasing. It is trained around a Review -> Align -> Latch -> Repair -> Confirm loop: review the scoped context, align to the user goal and constraints, latch onto concrete tool or command signals, repair from evidence when something fails, and confirm through validation before calling the task done.

The intent is simple: one 24 GB-class GPU can run a serious local coding worker; more GPUs let you run more workers in parallel. SignalLatch is the variant for cases where task discipline, tool formatting, repair behavior, and clean completion matter more than changing the base model's personality wholesale.

The first published SignalLatch runtime file was built around the original reasoning/coding IQ4_NL quantization path. It was meant to preserve the strong coding and reasoning behavior of the AEON RYS base while adding the SignalLatch behavior merge.

The newer v1.1 Lite and v1.1 Plus files keep that practical small-file goal, but were selected with a stronger emphasis on retaining the fine-tuned SignalLatch habits: review-before-edit behavior, instruction latching, tool-shaped reasoning, repair from evidence, and validation before completion.

New v1.1 quant information

The two new public files are exact renamed versions of the best release candidates from the mixed-quant sweep:

| Public file | Internal candidate | Exact mixed-quant recipe | Role |

|---|---|---|---|

| Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Lite-Mixed-Q4NL.gguf | c718_fa_iq3kt_ryssig_q6k | full-attention Q/K/V/O tensors at iq3_kt; RYS 15..24 signal-path tensors at q6_K | smaller practical SignalLatch replacement |

| Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Plus-Mixed-Q4NL.gguf | c154_fao_bf16_faqk_q8_lateffn_q8 | full-attention output tensors at bf16; full-attention Q/K tensors at q8_0; late FFN gate/down tensors at q8_0 | best practical quality SignalLatch variant |

Full self-contained v1.1 production record, including the test prompts, verifier categories, result tables, graphs, exact artifact details, and public decision trace:

https://noonr48.github.io/qwen36-aeon-ik-llama/signallatch-v1-1-production-process/index.html

Supplementary testing material for the full mixed-quant sweep is published separately. This heavier all-results supplement explains what the scores mean, lists the stable and comprehensive test tasks, and includes every summarized candidate row, large score graphs, real-world harness rows, and recipe annotations for the tested combinations:

https://noonr48.github.io/qwen36-aeon-ik-llama/signallatch-v1-1-all-results/index.html

These are not generic benchmark-chasing quants. They were selected through a larger production-style sweep focused on whether the model still behaves like a reliable local coding agent after quantization. The BF16 artifact is included for people who want to inspect, re-quantize, or continue work from the merged fine-tuned model.

!SignalLatch behavior loop: Review, Align, Latch, Repair, Confirm.

Historical fine-tune testing/process write-up for the original ckpt386-s010 baseline:

https://noonr48.github.io/qwen36-aeon-ik-llama/ckpt386-s010-testing-process/index.html

Upgrade target:

• existing repo: https://huggingface.co/jackasda211233/Qwen3.6-27B-AEON-RYS-15-20-GGUF
• existing Q4NL file: Qwen3.6-27B-AEON-RYS-MaxThinkCoder-IQ4_NL-ik-llama-custom-mixed.gguf

That non-finetuned Q4_NL release was already close to its BF16 source on the mixed probe snapshot:

The following table describes the non-finetuned AEON RYS 15/20 base artifact only. It is not a SignalLatch fine-tune score.

| Probe | BF16 | released IQ4_NL |

|---|---:|---:|

| mixed 4-probe mean | 0.7299 | 0.7244 |

| math_16 | 0.8421 | 0.7897 |

| eq_16 | 0.7123 | 0.7111 |

| math_4 | 0.4851 | 0.5170 |

| gsm8k_5 | 0.8800 | 0.8800 |

Mixed four-probe snapshot change: -0.0055 absolute, about -0.75% relative. This release keeps that small-form-factor Q4_NL path as the main deployment target and tests whether the SignalLatch fine-tune improves practical coding-agent behavior on top of it.

Practical fine-tune test: we also ran SignalLatch on an isolated Krita-like canvas-agent task: a local app with layers, brushes, transforms, opacity controls, and a local-only AI image generation stub. Under the same temp 0.7, 131072 context, conservative FP32 KV cache, flash-attention, graph-split setup, SignalLatch IQ4_NL completed cleanly with rc=0 and verifier score 1.0. FP32 KV was used here to isolate the model/task behavior from KV precision questions; separate long-context checks with FP16/default KV have reached about 160k context without showing the earlier failure pattern. In the same comparison, the non-finetuned AEON RYS IQ4_NL passed on retry but had a first-attempt invalid tool/diff failure, unsloth/Qwen3.6-27B-GGUF IQ4_NL passed cleanly, and unsloth/Qwen3.6-27B-GGUF Q8_0 produced complete verified files but timed out during final agent wrap-up. This canvas comparison is not a claim that SignalLatch beats Unsloth IQ4_NL; both completed cleanly in this small practical check.

For v1.1, selection was based on a larger manual quantization and real-world agentic test sweep. The mixed-quant combinations started as hand-designed tensor-group recipes over known model regions such as full-attention Q/K/V/O, full-attention output, token/output tensors, RYS signal-path tensors, RYS FFN tensors, duplicate-boundary tensors, and late FFN control tensors. Scripts then expanded, built, scheduled, and scored those recipe families; the starting combinations were manual engineering hypotheses, not a black-box automatic per-tensor optimizer.

• 163 hard-suite candidate runs across a 12 task reasoning/habit suite, for 1,956 scored prompt-level results.
• 32 real-world ClawCode harness runs across KritaLite, SyncBoard, and a legacy-codebase memory migration task:

- KritaLite: build a local Krita-like canvas application with layers, brushes, transforms, opacity controls, and a local-only image-generation stub.

- SyncBoard: implement and repair a small collaborative board/state-management app with hidden tests for undo/redo, filtering, import/export, replay, and merge-conflict behavior.

- Legacy-codebase memory migration: work inside a private legacy agent-system codebase and implement a narrow production slice for moving from a retrieval-heavy memory design toward session memory, object/item indexing, local evidence packets, and deterministic hard-facts verification, while preserving the existing retrieval path.

• 564 verifier component checks across those real-world harness runs.
• Final release candidates were compared against the original SignalLatch Q4NL file and Unsloth Qwen3.6 IQ4_NL / Q8_0 baselines.

The goal was not to prove universal superiority. The goal was to avoid publishing a quant that scored well numerically but lost the SignalLatch fine-tune habits in realistic coding-agent workflows, including more human-like prompts where the user gives an implementation direction and the agent must inspect the codebase, choose the relevant files, plan, implement, test, and refine.

First-shot UI example: a separate Open Design-style workstation prompt produced the interface concept below in one shot after the model was instructed to inspect the existing code and intended function, understand the workflow, and make a frontend shell. This is a qualitative example, not a scored UI benchmark. The local footer was cropped before publication.

!Sanitized first-shot SignalLatch workstation UI example.

Release files:

• Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Lite-Mixed-Q4NL.gguf
• Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Plus-Mixed-Q4NL.gguf
• Qwen3.6-27B-AEON-RYS-SignalLatch-ckpt386-s010-IQ4_NL.gguf
• Qwen3.6-27B-AEON-RYS-SignalLatch-ckpt386-s010-BF16.gguf
• SHA256SUMS

Use these as merged GGUF files. They are not intended to be loaded as live LoRAs at inference time.

The recommended practical deployment files are the v1.1 Lite and Plus mixed-quant GGUFs. The original ckpt386-s010-IQ4_NL file remains available as the first published SignalLatch Q4NL baseline. The BF16 GGUF is provided as a single source-quality exploration artifact, not the normal runtime target.

Which file should I use?

Most people should start with the Lite file if they want the smallest practical SignalLatch runtime artifact:

Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Lite-Mixed-Q4NL.gguf

Use the Plus file if you can spare the extra disk/VRAM margin and want the strongest practical mixed-quant candidate from the current testing:

Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Plus-Mixed-Q4NL.gguf

Use the original ckpt386-s010-IQ4_NL only if you specifically want the first published SignalLatch Q4NL baseline.

Use the single-file BF16 GGUF only if you want to explore the merged model directly, make your own quant, compare conversion settings, or continue downstream work from the fine-tuned merge.

At a glance

• base line: Qwen3.6-27B-AEON-RYS-15-20
• upstream AEON source: AEON-7/Qwen3.6-27B-AEON-Ultimate-Uncensored
• fine-tune: checkpoint-386 behavioral LoRA
• merge strength: 0.10
• main release artifacts: v1.1 Lite and v1.1 Plus mixed-quant GGUFs
• goal: maximum practical behavior in a small-form-factor GGUF
• recommended runtime file sizes: about 16 GB for Lite and about 18 GB for Plus
• companion source-quality artifact: single-file BF16 GGUF, about 57.6 GB
• intended runtime: https://github.com/noonr48/qwen36-aeon-ik-llama
• focus: practical coding-agent and tool-use behavior
• public name: SignalLatch
• behavior loop: Review -> Align -> Latch -> Repair -> Confirm
• not a general chat benchmark claim
• not a stock llama.cpp release

What changed vs the previous AEON RYS Q4NL release

The previous AEON RYS 15/20 Q4NL file is the base deployment target this is meant to improve:

Qwen3.6-27B-AEON-RYS-MaxThinkCoder-IQ4_NL-ik-llama-custom-mixed.gguf

That file is hosted here:

https://huggingface.co/jackasda211233/Qwen3.6-27B-AEON-RYS-15-20-GGUF

This upload merges a small behavioral LoRA into that already-strong AEON RYS 15/20 Q4_NL line before exporting to IQ4_NL. The goal is not to make a new general-purpose model family. The goal is to improve practical code-agent behavior while preserving the practical small-file deployment path: following repo-edit instructions, handling tool-shaped context, finishing concrete patches, and avoiding repeated timeout-like failures.

Training summary:

• dataset: 10,800 behavior examples
• training completion: checkpoint 386, one epoch
• LoRA rank: 8
• LoRA alpha: 32
• LoRA dropout: 0.05
• selected merge strength: 0.10

Recommended runtime

Use the custom AEON ik-llama fork:

https://github.com/noonr48/qwen36-aeon-ik-llama

Tested single-GPU baseline server shape:

./build/bin/llama-server \
  -m /path/to/Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Lite-Mixed-Q4NL.gguf \
  -c 65536 \
  -ngl 999 \
  -np 1 \
  -fa on \
  -sm none \
  --temp 0.7 \
  --jinja \
  --reasoning-format deepseek \
  --reasoning-budget 0

For one visible GPU, use -sm none. -sm graph is only valid when the process can see at least two GPU devices; otherwise ik-llama exits during model load with a split-mode error.

For long-context use, increase context as your system allows. The default KV type is f16. The current measured long-context reference is -c 160000 -np 2 on a 32 GB RTX 5090, which creates two 80k slots and uses about 27.5 GB VRAM:

  -c 160000 \
  -np 2 \
  -ctk f16 \
  -ctv f16

A true two-worker 160k-per-slot launch would be -c 320000 -np 2. That did not fit on the 32 GB RTX 5090 with FP16 KV; the loader estimated about 38.0 GiB required.

Practical single-GPU deployment note: the SignalLatch Q4_NL release is small enough for practical use on a single RTX 3090 / 24 GB-class card at the baseline 65536 context profile, where the logged run used about 20.8 GiB VRAM. Treat this as a deployment reference point, not a guaranteed memory benchmark.

For the later 131k practical canvas-agent comparison, we used FP32 KV as a conservative isolation setting to make sure any failure would not be caused by KV precision:

  -c 131072 \
  -ctk f32 \
  -ctv f32

Runtime notes:

• use the merged GGUF as the deployment artifact
• prefer the IQ4_NL file for practical deployment
• use the single-file BF16 GGUF as the source-quality merged artifact for downstream quantization or further work
• the strength-sweep / comparison profile used flash attention and graph split
• live LoRA loading is not the production path for this release
• the chat/runtime format should use Jinja plus DeepSeek reasoning formatting
• -c 65536 is the logged 24 GB-class baseline profile; larger context needs more VRAM
• FP32 KV was used for the 131k canvas comparison as a conservative validation setting, not because FP16 KV is known-bad. For normal practical use, start with default/FP16 KV and reduce context or KV precision only if your system needs it.
• Do not pass --ctx-checkpoints 0 for RAM prompt-cache deployments. The prompt may still match, but without recurrent context checkpoints the server can fall back to full prompt reprocessing.
• no GPU IDs, private hosts, or machine-specific paths are required for the public command shape

Parallel RAM-cache and agent-harness setup

The custom AEON ik-llama fork now includes a runtime adjustment for explicit slot lanes and RAM prompt-cache reuse. This matters for agent harnesses such as OpenCode, where you may want one long-running worker on slot0 and another on slot1 instead of letting requests bounce between slots.

Generic two-slot server shape:

./build/bin/llama-server \
  -m /path/to/Qwen3.6-27B-AEON-RYS-SignalLatch-v1.1-Lite-Mixed-Q4NL.gguf \
  -c 360000 \
  -np 2 \
  -ngl 999 \
  -b 256 \
  -ub 64 \
  -fa on \
  -sm layer \
  -ctk f16 \
  -ctv f16 \
  --temp 0.7 \
  --jinja \
  --reasoning-format deepseek \
  --reasoning-budget 0 \
  --alias qwen36-aeon-rys-signallatch-q4nl \
  -cram 65536

How to read that setup:

• -np 2 creates two parallel slots.
• -c 360000 is the total server context budget; with two slots, each lane receives roughly half.
• -cram 65536 enables RAM prompt cache. The value is MiB and is server-wide, so adjust it to your host memory budget.
• keep context checkpoints enabled. Do not add --ctx-checkpoints 0 if you want RAM prompt-cache restores to avoid full prompt reprocessing.
• use -sm layer for this two-GPU / two-slot RAM-cache path. On this recurrent/hybrid path, -sm graph disables the checkpoints needed for actual restore.
• set a stable --alias, then point the agent harness at <alias>-slot0 and <alias>-slot1.

Minimal OpenCode-style provider shape:

{
  "provider": {
    "signallatch-q4nl-p2": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "SignalLatch Q4_NL p2",
      "options": {
        "baseURL": "http://<host>:<port>/v1",
        "timeout": false
      },
      "models": {
        "qwen36-aeon-rys-signallatch-q4nl-slot0": {
          "name": "SignalLatch Q4_NL slot0",
          "reasoning": true,
          "interleaved": { "field": "reasoning_content" },
          "limit": { "context": 180096, "input": 171904, "output": 8192 }
        },
        "qwen36-aeon-rys-signallatch-q4nl-slot1": {
          "name": "SignalLatch Q4_NL slot1",
          "reasoning": true,
          "interleaved": { "field": "reasoning_content" },
          "limit": { "context": 180096, "input": 171904, "output": 8192 }
        }
      }
    }
  }
}

The important part is the model-name suffix. If your server alias is qwen36-aeon-rys-signallatch-q4nl, the OpenAI-compatible request model names qwen36-aeon-rys-signallatch-q4nl-slot0 and qwen36-aeon-rys-signallatch-q4nl-slot1 pin requests to the matching server slot.

Rationale: a long-running agent benefits from a stable context lane. If a harness sends related work sometimes to slot 0 and sometimes to slot 1, the live KV/recurrent checkpoint state for that lane may not match the next request and the server may need to reprocess more of the prompt. Slot suffixes make the lane explicit. In the unpatched pinned-slot path we tested, those suffixes selected the slot but skipped RAM prompt-cache save/load. The current fork fixes that by running the RAM prompt-cache path for pinned slots too.

Verification we performed: direct A/B/A requests against the current fork showed the expected cache behavior. The repeated A request produced found better prompt, prompt cache load took ..., and restored context checkpoint in the server log instead of a full prompt reprocess. When --ctx-checkpoints 0 was present, the prompt match could still be found, but the server had no checkpoint state to restore and fell back to reprocessing. That is why the RAM-cache profile above leaves checkpoints enabled.

Full runtime and fine-tune details are in the companion records:

• https://noonr48.github.io/qwen36-aeon-ik-llama/qwen36-aeon-rys-signallatch/index.html
• https://noonr48.github.io/qwen36-aeon-ik-llama/ckpt386-s010-testing-process/index.html

Practical eval snapshot

These numbers are from an internal practical code-agent edit matrix run on 2026-05-05. This is not an academic benchmark. It is a production-style patching matrix covering GitHub MCP behavior and local-search process/race/timeout fixes.

Runtime for the comparison:

• custom ik_llama.cpp
• temp 0.7
• graph split
• flash attention enabled
• Jinja template
• DeepSeek reasoning format
• reasoning budget 0
• context 65536

The later canvas-agent comparison used the same runtime family with context 131072 and conservative FP32 KV cache (-ctk f32 -ctv f32) to isolate runtime precision from model behavior. FP16/default KV has also been tested to about 160k context without showing the earlier failure pattern.

Five task matrix:

• github_mcp_commits_fix_repeat
• github_mcp_pr_details_fix
• local_search_search_timeout_fix
• local_search_web_search_race_fix
• local_search_kill_excess_fix

Base AEON RYS Q4NL vs this upload candidate:

| Candidate | Strict pass | Mean score | Timeout-like tasks | Read |

|---|---:|---:|---:|---|

| previous AEON RYS Q4NL | 1/5 | 0.550 | 4 | underperformed on this practical matrix |

| ckpt386 s0.10 IQ4_NL | 4/5 | 0.950 | 0 | selected upload candidate |

Task-level comparison:

| Task | Previous AEON RYS Q4NL | ckpt386 s0.10 IQ4_NL |

|---|---:|---:|

| commits branch fix | 0.75 fail | 1.00 pass |

| PR details fix | 1.00 pass, full-timeout run | 1.00 pass |

| kill excess process fix | 0.25 fail, full-timeout run | 1.00 pass |

| search timeout fix | 0.25 fail, full-timeout run | 0.75 fail |

| web search race fix | 0.50 fail, full-timeout run | 1.00 pass |

Repeat stability for the selected upload strength:

| Candidate | Runs | Strict pass | Strict mean | Read |

|---|---:|---:|---:|---|

| ckpt386 s0.10 IQ4_NL | 3 | 9/15 | 0.842 | best default candidate |

| ckpt386 s0.10 IQ4_NL, crash-adjusted | 3 | 9/14 | 0.884 | excludes one invalid server-crash task before a normal model attempt |

Other merge strengths had stronger isolated first runs, but less stable repeat evidence. That is why s0.10 was the original upload candidate.

Limitations

• This is an upgrade candidate for the AEON RYS 15/20 Q4NL deployment path, not a universal quality claim.
• The evaluation is an internal practical coding-agent matrix, not a standardized public benchmark.
• High variance remains at temp 0.7.
• The model should be run with the custom AEON ik-llama fork and the matching Jinja/DeepSeek reasoning setup.
• Use the merged GGUF file for deployment. Do not present live LoRA loading as the supported production path for this release.