diff --git a/CLAUDE.md b/CLAUDE.md
index 8a3eecd..2e5021c 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -83,8 +83,8 @@ cat llm-setup.md | ssh -o ControlPath=~/.ssh/cm67 admin@192.168.110.67 'cat > /h
 | 目录 | 跑什么 | 卡 | 显存 | 对外 |
 |------|--------|----|------|------|
 | `deploy-scripts/` | Qwen3.8-27B-Q5_K_M（llama.cpp，容器 `llm38`） | 0-3 分片 | **57.3 GB**（256K 上下文，2 槽位） | 8000 → `qwen.wudaima.com` |
-| `raylight/` | **2026-08-22 起 h3-console 的默认后端**：ComfyUI + Raylight 插件，4卡当一个 FSDP 集群跑 MiniMax-H3（不是4个独立worker，任何时刻只处理1个请求）。`server.py`（8100）对外契约兼容旧 `gateway.py`+`api.py`，管理常驻 ComfyUI 进程（8188，仅内部） | 0-3 全部（FSDP集群） | 832×480×64帧实测峰值约20-21GB/卡；**124帧会OOM**，见 `raylight/README.md`「已知限制」 | 8100（内部，h3-console 的 `H3_GATEWAY_URL` 指向这） |
-| `minimax-h3/` | **热备份（2026-08-24 起彻底禁用，双重保险）**。MiniMax-H3 FL2VA/Ref2VA NF4 文生视频，`api.py` 四实例（GPU0-3，端口 8010-8013）+ `gateway.py` 调度层（端口 8000），四卡各自独立能同时处理4个请求。代码/权重保留，但 `start-all.sh`/`start-gateway.sh` 和 `api.py`/`gateway.py` 本体都已改名成 `.disabled-20260824`（见目录内 `DISABLED-README.md`）——2026-08-24 反复出现"停了又自己起来"，查了半天不是 cron/systemd，也不是 PM2（那两个是 sd-forge/embedding 的事，见下），真正触发源没查到，干脆把 `api.py`/`gateway.py` 本体也改名，`python -m uvicorn api:app` 从 import 这层就会失败，不管谁/什么在尝试重启都没用。别再凭记忆当"还能秒级拉回"用，得先把三份改名的文件都恢复原名 | 四卡各一进程（停着，彻底禁用） | 单卡 fp32 峰值约 9-14 GB（视时长/分辨率），另占 CPU 内存约 32 GB/worker | 8000（停着） |
+| `raylight/` | **2026-08-22 起 h3-console 的默认后端**：ComfyUI + Raylight 插件，4卡当一个 FSDP 集群跑 MiniMax-H3（不是4个独立worker，任何时刻只处理1个请求）。`server.py`（8100）对外契约兼容旧 `gateway.py`+`api.py`，管理常驻 ComfyUI 进程（8188，仅内部） | 0-3 全部（FSDP集群） | ⚠️「124帧会OOM」是旧结论，2026-08-22切SAGE_FP16后已推翻——**0参考图**时1344×768能撑412帧不OOM；但**带参考图（ref2va/fl2va）时这份表不适用**，2026-08-24实测同一份"1344×768×362帧×3参考图"配置5次4次失败，真实上限没测过，见 `raylight/README.md`「已知限制」第1条 | 8100（内部，h3-console 的 `H3_GATEWAY_URL` 指向这） |
+| `minimax-h3/` | **代码已删除（2026-08-24），只剩权重/venv/日志**。之前是 MiniMax-H3 FL2VA/Ref2VA NF4 文生视频的旧架构（`api.py` 四实例+`gateway.py`调度层，四卡各自独立worker）。先改名 `.disabled-20260824` 禁用，结果 2026-08-24 晚上还是被人手动 `mv` 回原名+手动启动过一次（跟 raylight 抢 GPU1，导致 console 短暂路由错乱），于是**把 `gateway.py`/`api.py`/`DiffSynth-Studio/`/`scripts/`等路由代码整个删掉**（不只是改名），从根上杜绝再被手动复活。删前打包备份，见 CLAUDE.md「MiniMax-H3 脚本」一节。服务器 `/data/models/minimax-h3/` 目录还在，但只剩 `console/`（h3-console 在用）、`models/`（53GB权重）、`venv/`、`outputs/`、`logs/` | 无（进程已停，代码已删） | 权重仍在，如需复活须先从备份包恢复代码 | 无 |
 | `h3-console/` | H3 Web 管理台：上传/生成/预览三界面 + 任务持久化。两个进程共享同一份 sqlite/assets：**8080**（局域网直连，`BASE_PATH` 空）+ **8081**（`H3_CONSOLE_BASE_PATH=/console`，专供公网子路径用）。**2026-08-22 起两个实例的 `H3_ENABLE_SUPERVISOR` 都关了**——fl2va/ref2va 弹性调度器（按partition flip某张卡）是给 minimax-h3 那套"4个独立worker"架构设计的，raylight 的FSDP集群架构下没有"单卡分区"这个维度，开着会出错 | 不占显存（自己不跑模型） | — | 局域网 `http://192.168.110.67:8080`；公网 `http://qwen.wudaima.com/console`（frp `locations=/console` 分流，`gateway.wudaima.com` 那条独立域名确认走不通，缺口在 frp 服务端 60.205.214.169，见 CHANGELOG） |
 
 ⚠️ **"（常驻）whisper GPU3 3.2GB"这条 2026-08-24 确认是过期信息**——当时机器上根本没有任何
@@ -111,14 +111,21 @@ stable-diffusion-webui-forge`）和一个 embedding 服务（gunicorn:7590），
 
 回滚依赖三样东西，**都不要删**：镜像 tag `llamacpp-rollback:b9570`、模型文件 `/data/models/Qwen/Qwen3.6-27B-GGUF/`、脚本 `restore.sh`。
 
-## MiniMax-H3 脚本
+## MiniMax-H3 脚本（⚠️ 2026-08-24 代码已删除，只剩备份压缩包）
 
-`minimax-h3/scripts/` 对应服务器 `/data/models/minimax-h3/scripts/`（`run.sh` 在
-`/data/models/minimax-h3/run.sh`）。**权威文档是 `minimax-h3/README.md`**——为什么官方示例
-照抄跑不起来、Turing 的 dtype/attention/量化实测结论、多卡为什么只能做独立 worker。
+`minimax-h3/scripts/`（含 `probe-*.py` 兼容性探测四件套、`api.py`/`gateway.py` 等路由代码）
+**本地仓库和服务器上都已经删除**，不再是能直接跑的目录。删除原因：生产已全面切到
+`raylight/`，2026-08-24 又发现这套旧代码被人手动复活过一次（跟 raylight 抢 GPU1），干脆连
+代码一起删掉，杜绝再被误启动。
 
-其中 `probe-*.py` 四件套是当初得出兼容性结论的探测脚本。
-**换硬件或升级 torch / bitsandbytes 后，先跑这四个再动别的。**
+删之前打了包，**换硬件或升级 torch / bitsandbytes 需要重新跑 `probe-*.py` 时，先从这里
+解压出来**：
+- 本地：`~/Documents/lemonAI/2080tiserver-backups/minimax-h3-local-repo-backup-20260824.zip`
+- 服务器实际删除内容（更全，含 `DISABLED-README.md` 等本地没有的文件）：同目录
+  `minimax-h3-code-backup-20260824.tar.gz`
+
+服务器上 `/data/models/minimax-h3/` 目录本身还在，但只剩 `console/`（h3-console 正在用，
+别动）、`models/`（53GB NF4 权重，没删）、`venv/`、`outputs/`（历史生成结果）、`logs/`。
 
 ## 当前状态（2026-08-18）