發表文章

Keep Claude Code's prompt cache warm while idle — meet cwarm

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 不再「放著就冷掉」——開源小工具 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哪些行得通哪些是死路為什麼

自架跨裝置 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

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

Bad ipv4 兩年下來的列表

雖然,使用ban ipv4的手段有點被動,但在資安上,還是一個辦法。 檔案內的ipv4,是這兩年來,五台主機受到嗅探攻擊或是各種其他類型攻擊,整理的ipv4,可以將這些將入到貴司的防火牆指令中。 以下有23560筆,跟之前發布的資料6288筆,多了很多! 1.11.62.190 1.116.115.169 1.116.27.174 1.116.38.108 1.117.192.120 1.117.223.59 1.117.68.165 1.117.73.36 1.117.87.203 1.117.94.196 1.119.148.126 1.12.220.16 1.12.230.7 1.13.195.178 1.13.79.144 1.14.104.230 1.14.107.89 1.14.153.90 1.14.20.112 1.14.255.112 1.14.8.251 1.14.93.77 1.15.171.183 1.15.234.166 1.15.252.13 1.15.51.35 1.15.68.208 1.15.79.234 1.156.23.232 1.161.99.6 1.162.238.172 1.164.111.182 1.168.111.97 1.169.67.47 1.177.63.26 1.177.63.29 1.177.63.30 1.180.219.210 1.180.98.210 1.192.102.206 1.20.156.196 1.20.93.137 1.200.114.126 1.200.33.242 1.200.35.248 1.200.39.200 1.207.250.77 1.212.197.132 1.212.225.99 1.214.214.114 1.22.168.7 1.22.33.66 1.234.31.117 1.234.80.51 1.234.80.73 1.235.192.131 1.235.197.58 1.235.222.197 1.237.137.30 1.238.106.229 1.24.37.84 1.26.70.2 1.27.171.154 1.28.126.94 1.28.192.130 1.28.87.246 1.31.80.222 1.33.107.121 1.36.116.2...