--- 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](#vision-support-mmproj) from the file list and add `--mmproj` to enable vision. See the [Vision Support section](#vision-support-mmproj) 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](https://huggingface.co/jackasda211233/Qwen3.6-27B-AEON-RYS-Agentic-Coder-PatchCode-GGUF):** 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](https://huggingface.co/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](https://huggingface.co/jackasda211233/Qwen3.6-27B-AEON-RYS-SignalLatch-GGUF/resolve/main/mmproj-Qwen3.6-27B-base-f32.gguf) | | `mmproj-Qwen3.6-27B-base-f16.gguf` | F16 (half precision) | 885 MB | [⬇ Download](https://huggingface.co/jackasda211233/Qwen3.6-27B-AEON-RYS-SignalLatch-GGUF/resolve/main/mmproj-Qwen3.6-27B-base-f16.gguf) | | `mmproj-Qwen3.6-27B-base-q8_0.gguf` | Q8_0 (8-bit quantized) | 601 MB | [⬇ Download](https://huggingface.co/jackasda211233/Qwen3.6-27B-AEON-RYS-SignalLatch-GGUF/resolve/main/mmproj-Qwen3.6-27B-base-q8_0.gguf) | **Recommended:** `mmproj-Qwen3.6-27B-base-f16.gguf` — best balance of quality and size. ### Usage Add `--mmproj` to your llama-server command: ```bash ./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: ```bash 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.](assets/signallatch_loop.svg) 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.](assets/signallatch-one-shot-workstation.png) 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: ```bash ./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: ```bash -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: ```bash -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: ```bash ./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 `-slot0` and `-slot1`. Minimal OpenCode-style provider shape: ```json { "provider": { "signallatch-q4nl-p2": { "npm": "@ai-sdk/openai-compatible", "name": "SignalLatch Q4_NL p2", "options": { "baseURL": "http://:/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.