One thing that stopped me (and even you) from switching completely to px0 was the lack of inline editing. That changes today... because px0 now lets you edit files too :) And the implementation is super efficient and minimal... You can tap the edit button and start editing files inline. What you do not get is autocomplete or syntax highlighting during edits. Also, this does not increase RAM usage because ... all files open in read-only mode by default, unless you tap Edit and switch to edit mode. The read-only mode implementation is inspired by how NES games like Contra and Mario are rendered. Apart from this, a couple of important features are out as well. You can now create new files and folders right from the IDE, and explore previous commits, access their files, and view individual diffs. There is also a bunch of work under the hood to make language servers more reliable, improve incremental document syncing, and keep the UI responsive. If you already have px0 installed, run: > `px0 --update` If you have not tried px0.ai yet, give it a shot. px0 is a speed-first, lightweight, browser-based IDE for skimming and reviewing AI-generated code. Give it a try.

Every harness leverages prompt caching differently. I was skimming through a few to understand what they do, how they do it, and the implications. Here is a quick gist... Every model provider gives us ways to control prompt caching through prefix-based caching. You can pass a breakpoint or marker to indicate how far into the prompt you want to cache. As long as the prefix remains the same, inference for that portion of the prompt can be skipped. Which means that if anything changes early in the prompt, it invalidates the cache for everything after it. This means the harness has to order the prompt from the most stable content to the least stable content. So, coding harnesses decide where to place that marker and what cache key to use. - Claude Code puts the static system prompt and tools first, then project memory, followed by session context, and only then the messages. - OpenCode caches the first 2 system messages and the last 2 non-system messages. - Pi marks the system prompt, the last user message, and the last tool. Interestingly, some harnesses do not just cache system messages. They also cache the prefix up to the last couple of messages. This essentially helps them reuse cached computations across multiple use cases that share the same system prompt, as well as across subsequent turns in a specific conversation. The pattern is simple - static content first, volatile content last, and a stable key per session. If a harness breaks that order even once, say by editing the system prompt mid-session, you end up paying (cost and energy both) for the entire prefix again. Hope this helps.