ZCode Integration and Configuration

① Provider Configuration (Copy-Paste Ready)

File .zcode\v2\provider_config.json. Values are the current effective version; evolution on ②③.

// Provider body
{
  "providerId": "88ff30fa-af55-4443-a1ff-ba8a7ff681c6",
  "providerName": "Local Ollama",
  "config": {
    "group": "standard-personal",
    "access": { "type": "api-key", "apiKey": "ollama-local-no-key" },
    "api": { "type": "openai-chat-completions",
             "baseUrl": "http://127.0.0.1:11435/v1" },
    "personalModelIds": ["qwen3.8:27b-offload"],
    "modelOrder": ["qwen3.8:27b-offload"]
  }
}

// Model rules (capability declarations must match the model's real capabilities)
{
  "modelId": "qwen3.8:27b-offload",
  "config": { "properties": {
    "contextWindow": 256000,
    "requiresMfjsToolSchema": false,
    "supportsToolCall": true,
    "supportsJsonSchemaOutput": false,
    "supportsMidConversationSystem": false,
    "inputFormat":  { "supportsText": true, "supportsImage": true },
    "outputFormat": { "supportsText": true }
  }}
}

② Two Numbers Must Be Maintained in Pair

Server -c and client contextWindow — adjusting one side only guarantees the fault recurs.

Where the 1.26 coefficient comes from: three measurements in the same environment, ZCode's token estimate underestimating 5.5% → 15% → 26% (unstable bias). Compression requests also add ~2,563 token instructions on top of the history. So the check formula must take the worst observed value and then keep a margin — do not configure "just enough". Counterexample: 98,304 × 1.26 + 2,563 ≈ 126,426 > 114,688, so the old-era trigger point cannot be raised to 98,304.

③ Why the Compression Line Is 65%, Not 85%

ZCode's auto compression line is not "a percentage of the window", it is "the window first fixed-deducts 34,000 tokens".

Both reserves are hard-coded constants — 185 compression events, across 6 window tiers, including the cloud 1M model, the values never changed. So the "compress at 85%" intuition holds only at large windows. Two practical conclusions:

1. The only effective way to gain usable space is to enlarge the window: 81,920 → 98,304 moved the trigger line from 47,920 → 64,304, usable tokens +34%;
2. The denominator of the panel's "used X/limit (P%)" is the window, not the trigger line — seeing compression at 70% means actual tokens have already crossed that line.

Reproduction command: python D:\_Qwen3.8-27b\_zcode_setup\_compact_probe.py (parses ZCode's jsonl logs).

④ Change List (new / modified / backup)

The full picture of files created and modified during integration — in troubleshooting, first think "which file does this feature live in".

New files (core items):

Modified files (each maps to a true cause):

All changes have timestamped backups (*.bak_date_time); rollback is copy-overwrite.

⑤ Boot Chain (Two, Independent of Each Other)

Design goal: model auto-loads 20 seconds after boot; each path is idempotent (probe /health first), and simultaneous triggers do not interrupt a loading model.

Main path (Startup folder):
NVFP4_llama-server.lnk
  → wscript.exe autostart_local_llm.vbs        (fully hidden window)
    → autostart_local_llm.bat                  (wait 20s for GPU driver)
      → is_ready.ps1 probes /health
         ├─ already 200 → log one line, do nothing (idempotent)
         └─ not serving → start_local_llm.bat to launch
      → also raises CherryStudio's proxy (if 11436 is free)
      → raises watchdog (60s cycle; restarts if the service disappears)

Redundant path (Registry Run key LocalLLM_ensure):
powershell.exe -WindowStyle Hidden -File ensure_model.ps1
  → First self-heal: convert LF line endings of .bat/.cmd/.vbs/.ps1 to CRLF in place
  → Then call the same autostart_local_llm.bat

Why the redundant path: the main path once failed silently for two days, with no log trace at all (the LF line-ending accident). The redundant path is written in PowerShell (unaffected by that trap) and self-heals line endings every boot. The Task Scheduler version is stronger but was rejected — Register-ScheduledTask reports 0x80070005 access denied in an unprivileged environment.

Troubleshooting order for "not usable after boot": status_local_llm.bat → by [1] Processes (0 = model is gone) → [9] Watchdog (running = wait 1 minute for auto-raise; NOT running = manual cscript //nologo //B watchdog.vbs) → [8] Logon autostart (whether it ran at boot) → [5] log tail (should have listening on).

⑥ Six UE Sub-Agents

The motive is saving tokens: the full tool schema eats ~46K, while each sub-agent carries only 6 basic tools (Read/Write/Edit/Glob/Grep/Bash), dropping the schema to ~7K and freeing 39K for the task itself.

Loop design philosophy (a second-iteration conclusion): the true state of UE assets can only be known by reading the CDO at runtime, so exploratory loops must be retained (read-back verification after each Bash step); what was cut was the useless overhead in the loop — Monolith goes through the Python client (not the MCP schema, which would eat 46K), default_timeout=120 (a 15-second timeout false-fails when the editor is busy), a hard 2-4 cap per step to prevent repeated retries, output ≤ 200 lines. Three strategies compared: uncapped loop 71 minutes (25% repeated operations), single script falsely fast, second iteration 10-15 minutes with adaptivity preserved.

⑦ Four Daily-Use Disciplines

Common commands:

D:\_Qwen3.8-27b\start_local_llm.bat     REM manual launch
D:\_Qwen3.8-27b\stop_local_llm.bat      REM release VRAM immediately
D:\_Qwen3.8-27b\status_local_llm.bat    REM one-click health check (run this first on trouble)