Experimented with a barebones agent that forced the model to reply only in Python, and then automatically executed the generated python. I tried it with Qwen-2.5-Coder, Gemma4 E4B, and Qwen3-4B-Instruct. The idea was to remove the need for a bash/powershell tool, and have the agent write complex tool call chains in a single program output. The first approach extracted python code blocks from the reply and executed them. The second approach exposed python as a regular tool.
tl;dr - Right now, what annoys me the most with Easy Diffusion is the startup time and friction, and how Easy Diffusion isn’t actually “easy” anymore - the default model (SD 1.5) is bad, users take too long to get productive, and new models require a lot of configuration. That’s what v4 aims to bring under control. Easy Diffusion v4 needs to ship soon, this has gone on long enough.
Zed quietly calls your selected model to generate the title of an agent session, and sends a huge amount of input context along with it (including tool call results). And we pay for that. That’s really not cool. This ends up using a frontier model to generate a 4-5 word summary for the chat window title, which is crazy. Noticed this in my OpenRouter logs.
Shipped a bunch of regression tests that test Blender’s XR API automatically - https://github.com/cmdr2/blender-xr-regression-tests Next: Contribute a patch to Blender so that it can run headless in XR. This will unblock running these regression tests weekly in a CI runner.
Added support for Krea2 in Easy Diffusion v4, in the beta channel.
Helped investigate a recent regression in Blender, which broke ‘pass-through’ (i.e. AR) support on Quest 3. Pass-through works reliably on Blender 4.3, 4.4, 4.5 and 5.0, but has been broken since Blender 5.1. git bisect didn’t help, because “good” commits would suddenly turn “bad” (and vice versa). It was really strange. And most of the code for passthrough hasn’t changed in 2 years (when it was first committed). The root-cause turned out to be a bad struct initialization. Without proper initialization, we’d OR against garbage values, instead of zero-initialized flags. That is:
Switched to Zed from VS Code. It’s really quite cool, mainly in terms of RAM usage and startup time. For my projects, a single VS Code window consumes around 2 GB of RAM, while the same project in Zed consumes around 90 MB. It really is quite insane. And Zed’s cold-start bootup latency is around 3 seconds (for me), compared to around 10-12 seconds in VS Code (before it’s ready to use). I don’t use a lot of extensions in VS Code.
Bah. I just lost all of the work that I did yesterday. I’ve been using a new text editor over the past few months, which I “vibe-coded” for myself using AI. I never really reviewed its code, and it’s worked fairly well so far. Yes, it is vibe-coded in the full sense of the word, and now the bill has come due. Today, a weird race-condition bug in the editor caused an open file to get deleted (along with my work).
Refactored Puppetry by splitting the monolithic single file (3500 lines) into separate modules. Also added thorough test coverage, which will make it easier to develop new features without breaking existing ones. I tested the new version manually, verified that the automated tests cover all the critical paths, and read through all of the test implementations. I also tested on older versions of bpy. The CI deployment job will also automatically run the tests against a bunch of old and new versions of Blender, before releasing to the users.
the concept of batched run might not make sense anymore in Fabricator, since copilot is moving away from request-based billing to token-based. but many of the other providers still have some concept of subscription billing, and I suspect that we might see subscriptions coming back (since subscriptions are good for business, i.e. negative working capital). once the current financial pressure of inference eases a bit. so maybe I’ll keep the batching code intact, but stop using it for now in Fabricator until it makes sense. I’ll also have to start thinking about cleaning up my inputs, and the reasoning level that’s used (higher produces more intermediate tokens, which may not always be necessary). for now, I don’t think I need to react right away, especially since my AI costs are within my monthly budget. So I can worry about efficiency and optimization later, as necessary, and continue to focus on increasing throughput on my task backlog.