向量浮屠

Keep Claude Code's prompt cache warm while idle — meet cwarm If you use Claude Code , you've probably hit this: you're deep in a session, step away for a meeting, come back — and it feels like it re-reads the entire conversation before answering. That's a prompt-cache miss . Why it happens Anthropic's prompt cache has a time-to-live: roughly 1 hour on Max and 5 minutes on Pro . Idle past that and the cache expires, so your next turn pays the full cost of re-reading the context. On macOS/Linux you can poke the session with something like tmux to keep it warm — but on Windows-native (Git Bash) there was no clean path . That's where cwarm started. What cwarm does It runs claude inside a pseudo-terminal (PTY) it controls, and when you've been idle past your plan's threshold it injects a tiny keepalive so the cache stays warm. The key part: the injection is an in-process PTY write , unrelated to window state — so it keeps working when the window i...

讓 Claude Code 的 prompt cache 不再「放著就冷掉」——開源小工具 cwarm 用過 Claude Code 的人應該都有這經驗：寫到一半離開去開會、回來繼續，結果它好像「重新讀了一遍整個對話」才回你——這就是 prompt cache 過期 （cache miss）。 為什麼會這樣？ Anthropic 的 prompt cache 有存活時間（TTL）： Max 約 1 小時、Pro 約 5 分鐘 。閒置超過就過期，下次互動得重付一次「讀完整上下文」的成本。Mac／Linux 的人可以用 tmux 之類的方式定時戳一下保溫，但 Windows 原生（Git Bash）沒有這條路 ——這就是我寫 cwarm 的起點。 cwarm 做什麼？ 它把 claude 跑在一個自己控制的 PTY（虛擬終端）裡，當你閒置超過方案門檻時，自動注入一個極小的 keepalive 讓 cache 不過期。重點是—— 注入是行程內部的寫入，跟視窗狀態無關 ：你把視窗縮到工作列、切到別的桌面、它在背景，照樣保溫；只有真正關掉視窗才會停。 一個有趣的技術坑 一開始我想「直接對終端視窗送鍵盤訊息不就好了？」結果 mintty （Git Bash 的終端）跟 PuTTY 一樣， 完全無視外部合成的鍵盤訊息 （ PostMessage ／ SendMessage ／甚至 WM_PASTE 實測全不通），而 SendInput 又得搶焦點。最後的結論跟 tmux／expect／VS Code 終端用的是同一招—— 你得自己當那個 PTY 的主人 ，才能乾淨地把輸入餵進去。 特點 跨平台 ：Windows / macOS / Linux， 不需要 tmux （已在 Windows 與 Raspberry Pi 4 / Linux aarch64 實測）。 自動依方案調門檻 ：Max 約 58 分、Pro 約 4 分才注入，且有冷卻。 焦點／縮小／背景都照常保溫 。 選配「cache 倒數」statusline ：會包裝你現有的、不偷蓋、可一鍵還原。 安裝 & 使用 npm i -g claude-cache-keepalive cwarm ...

自架跨裝置 Obsidian 同步（Windows + Raspberry Pi + Android + iPhone）：哪些行得通、哪些是死路、為什麼 一份 2026-06 的實戰紀錄：把同一個 Obsidian vault 自架、免費地，同步到一台 Windows 桌機、一台 24 小時開機的 Raspberry Pi、三台 Android 手機、一台 iPhone。 這 不是 又一篇「快樂路徑」教學——各工具的官方文件都寫得很好。這篇補的是平常少有人寫的部分： 那些撞牆的死路、為什麼別走、以及各平台特有的陷阱 （尤其是 ARM 樹莓派和 iOS）。如果你正要做同一件事，這篇大概能幫你省下好幾個晚上。 作者：fifthadj。歡迎自由取用，不負任何保證——工具更新很快，請把這篇當「某個時間點的快照」，不是會維護的權威指南。 先講結論——最後行得通的方案 裝置 同步方式 Windows 桌機 Syncthing （同時兼任 iOS 的「橋」，見下） Raspberry Pi 4（24 小時開機的 Linux 中樞） Syncthing 中樞 + CouchDB （給 iOS 用） Android 手機（×3） Obsidian App + Syncthing-Fork iPhone Obsidian App + Self-hosted LiveSync ↔︎ CouchDB 兩套同步刻意並存： 桌機 + Android → Syncthing。 點對點、即時、雙向、私密（走 mesh VPN）。Android 的 Obsidian 可以「 Open folder as vault 」，直接開 Syncthing 同步的資料夾。 iPhone → obsidian-livesync（CouchDB）。 因為 iOS 的 Obsidian 不能開外部資料夾 （沙盒限制），所以「Syncthing 同步到某資料夾」這招在 iOS 是死路。LiveSync 改成在 App 內部、透過資料庫同步。 最重要的一條心得： 唯一長得像 Obsidian、用起來像 Obsidian 的，就是 Obsidian 本人。 每一個「用瀏覽器看你的 vault」的捷徑，付出的代價都比省下的多。 目標與...

Self-hosting multi-device Obsidian sync (Windows + Raspberry Pi + Android + iPhone): what worked, what didn't, and why A point-in-time field report (2026-06) on getting one Obsidian vault synced, self-hosted and free, across a Windows desktop, an always-on Raspberry Pi, three Android phones and an iPhone. This is not another happy-path tutorial — the official docs for each tool are excellent. It's the part that's usually missing: the dead ends, the why-not, and the platform-specific traps (especially on ARM Raspberry Pi and on iOS). If you're about to do the same thing, this should save you a few evenings. Author: fifthadj. Use freely. No warranty — tools move fast; treat this as a snapshot, not a maintained guide. TL;DR — the setup that actually worked Device Sync method Windows desktop Syncthing (also doubles as the iOS "bridge", see below) Raspberry Pi 4 (always-on Linux hub) Syncthing hub + CouchDB (for iOS) Android phones (×3...

還是筆記一下，免得日後忘了。 首先，會先呼叫get_journalctl_bad_ipv4.py，這支程式會把Linux journalctl相關的ssh login錯誤等ipv4提取出來，放到定的檔案，如下例： ./get_journalctl_bad_ipv4.py ./bad_ipv4_ww1.txt 然後，get_journalctl_bad_ipv4.py內部會先呼叫compare_ipv4_list.py這支程式，將bad_ipv4_ww1.txt與已經執行過的security_ipblocked_ipv4.txt比對，把沒有執行過封鎖的ipv4再寫回bad_ipv4_ww1.txt這個檔案中，這樣避免重複執行已經封鎖過ipv4，提升效率。 接著，./report_bad_ipv4.py ./bad_ipv4_ww1.txt ./bad_ipv4_new.txt ./last_report_timestamp.txt 呼叫report_bad_ipv4.py把bad_ipv4_ww1.txt回報到指定的伺服器，並告知上次的執行時間戳last_report_timestamp.txt，並把從伺服器回應的新的bad ipv4存到bad_ipv4_new.txt。 得到伺服器新的清單檔案後，./compare_ipv4_list.py ./security_ipblocked_ipv4.txt ./security_ipblock_ipv4.txt ./bad_ipv4_ww1.txt ./bad_ipv4_new.txt ./bad_ipv4_io.txt 呼叫compare_ipv4_list.py，把過去執行過的檔案都加入是否已經執行的檢查，再把沒執行過的放到bad_ipv4_io.txt 有了bad_ipv4_io.txt，即可再次使用./get_journalctl_bad_ipv4.py ./bad_ipv4_io.txt 執行封鎖ipv4的動作。最後，把所有的檔案，透過unique_ipv4.py ./unique_ipv4.py ./security_ipblocked_ipv4.txt ./security_ipblock_ipv4.txt ./bad_ipv4_ww1.txt ./bad_ipv4_new.txt ....

好像兩年才發布一次bad ipv4，間隔太久了，很難達成資安的防範的目的，因此，特別撰寫程式，每天公布bad ipv4的壓縮檔案。 檔案下載的網址如下： https://byggs.ddns.net/bad_ipv4/{日期}.zip 其中，{日期}為2024-02-27這樣的格式，也就是今天的日期，每天凌晨00:00，伺服器會自動將資料庫的bad ipv4整理到壓縮檔案內。只要定時下載該檔案，解壓縮後，把列表的ipv4加入防火牆即可。👍