In extract_base_config, linear_q_proj_dim is derived from linear_num_key_heads * linear_key_head_dim (line 162), making it always equal to linear_k_proj_dim. For the Qwen3.5 DeltaNet architecture the query and key projections share the same head count and dimensions, so this is the correct formula. However, there is no separate variable for linear_num_query_heads or linear_query_head_dim — the assumption that Q and K have the same projection dimension is hardcoded. If any future Qwen3.5 variant uses different Q-head vs K-head counts (GQA-style for linear attention), this will produce incorrect splits of in_proj_qkv.weight in the converter, leading to wrong model weights at inference time. The assumption should at least be documented with a comment, and ideally the converter should cross-check the derived linear_q_proj_dim + linear_k_proj_dim + linear_v_proj_dim against the actual weight row count before splitting.

In build_gated_deltanet, the deltanet_beta_bias field (populated from linear_attn_dt_bias.weights) is applied to a_logits (the gate path), and deltanet_gate_bias (populated from linear_attn_A_log.weights) is also applied to the gate. The naming is inverted: deltanet_beta_bias contains dt_bias which is added to the gate's input, while deltanet_gate_bias contains A_log which scales the gate. These names are the reverse of what the stored data actually represents — deltanet_beta_bias stores a gate parameter, and deltanet_gate_bias stores another gate parameter. This makes the code very hard to maintain and understand. The struct field names in LayerWeights should align with the actual parameter semantics (e.g., deltanet_dt_bias and deltanet_a_log).

In post_init, when inferring dimensions from weight shapes (the fallback path at line 108), deltanet_value_dim_ is set to inferred_key_dim — the same value as deltanet_key_dim_. This is correct only when V_dim == K_dim for the linear attention layer. If a model has different key and value dimensions (e.g., linear_value_head_dim != linear_key_head_dim), this fallback will produce an incorrect value dimension, leading to a mismatched state tensor shape in build_gated_deltanet and ultimately a runtime error or silent wrong output. The fallback should either derive value_dim from the v_weight buffer shape or document clearly that this path requires V_dim == K_dim.

The skip_layers variable is declared static, making it a static local variable that is initialized once and shared across all invocations of forward(). This is a pattern used in other models (e.g., model_qwen.cpp) as a debug hook to skip layers, but it is initialized to an empty set. This is not a functional bug (the set is always empty), but it is confusing and potentially a maintenance hazard — if someone adds layer-skipping debug code in one model's forward pass, the change might be assumed to not persist across calls. This pattern is consistent with the existing codebase convention.

When model_type_str.startswith('qwen3_5') is true and the in_proj_qkv tensor is found but any of q_dim, k_dim, v_dim is 0 (the model config doesn't expose linear_num_key_heads/linear_key_head_dim), the whole in_proj_qkv is saved as a combined weight file, but the split Q/K/V files (linear_attn_q.weights, linear_attn_k.weights, linear_attn_v.weights) are silently not written. The C++ load_weights_to_graph will then try mmap_required for those split files and throw a runtime error. There should be a warning or error when the split cannot be produced, rather than letting the runtime fail during model loading.

The format_qwen_style function now emits <think>\n (with a newline) as the generation prompt prefix when template_has_think is true. However, if both template_has_think is true AND tools_json is non-empty, the tools path (<think>\n</think>\n\n) is skipped. This means tool-call generation for a Qwen3-Thinking model will start with an open <think> tag and never close it before emitting tool-call JSON, which may break the tool-call parser. If template_has_think should take priority even when tools are present, the previous <think>\n</think>\n\n handling for tools should also be accounted for in this branch.