👁️ 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).
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.
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:
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:
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:
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:
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.
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
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.
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:
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.
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.
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
1 -c 160000\2 -np 2\3 -ctk f16 \4 -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
1 -c 131072\2 -ctk f32 \3 -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.
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:
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.
