SolidCraft is a new open-source CAD app written in pure Rust (MIT or Apache-2.0), with a built-in MCP server so a coding agent such as Claude Code can model parts in it. Its README reports that 75 of 76 public reference parts match their expected volume, area and centre of mass, and calls the app early but usable for simple parts. Would you use a part an AI agent modelled without opening it yourself first? github.com/bherbruck/solidcr…

Anthropic stopped using git for its monorepo. The number behind it: about 2,500 merged changes a day in May, and 30,401 on 9 September. From their engineering post on Scion, the replacement: • CI runs on the order of 25 million checkouts a day. Fetched naively from git, that would be over 600 PB of traffic a day • at the peak they ran several hundred internal git mirrors just to keep up • Scion's footprint is 200x smaller in CPU and memory than those mirrors, each cache tier holds a hit rate over 99%, and checkouts take seconds instead of minutes • seven people built it, a new code review tool and the migration in five months Their own limit: Scion is "by no means a suitable replacement for git for general use". The design only makes sense for enormous monorepos, with tens of thousands of engineers or swarms of agents writing code. On prior art, the post credits Google's Piper and Meta's Sapling. Rain, who helped build Meta's open-source Mononoke server, argues that Scion's "derived data" design follows Mononoke's far too closely for the post never to name it. Rain is fine with the copying; the complaint is the missing credit. anthropic.com/engineering/re… sunshowers.io/posts/anthropi…

Your coding agent probably doesn't need a bigger context window. It needs a cleaner one. In September 2025, Anthropic called it likely that, for the foreseeable future, context windows of all sizes will be subject to context pollution, at least when you want the strongest agent performance. Most of its Claude Code best practices rest on one constraint: the window fills up fast, and performance degrades as it fills. One long session: Task A → "investigate X" → back to A → correction ×2 → same-session review Where it breaks: • "investigate X", unscoped: Claude reads hundreds of files, filling the context • correction ×2: the context is cluttered with failed approaches • same-session review: Claude reviews code it just wrote • the whole session: as the window fills, Claude may start "forgetting" earlier instructions What fixes it in Claude Code: 1. Send the investigation to a subagent. Subagents run in separate context windows and report back summaries. 2. After two failed corrections, /clear and write a better prompt with what you learned. A clean session with a better prompt almost always outperforms a long session with accumulated corrections. 3. Review in a fresh context, where Claude won't be biased toward code it just wrote. Same session, fixed: Task A → subagent investigates X → back to A → correction ×2 → /clear + better prompt → fresh-context review Not just Claude: Chroma's Context Rot report (July 2025) tested 18 models, closed and open-weights, and found performance degrades as input length increases. Open-source Aider (Apache 2.0) has the same moves: /drop files "that don't need any more changes", and when it gets stuck, /clear "to discard the chat history and make a fresh start". Long sessions are fine when you're deep in one complex problem and the history is valuable. Which do you use least: a subagent, /clear or a fresh-context review? code.claude.com/docs/en/best… anthropic.com/engineering/ef… aider.chat/docs/usage/tips.h… #ClaudeCode

If a model running on your own machine feels slow, check where it actually loaded before you blame the model. ollama ps The PROCESSOR column tells you: • 100% GPU: the whole model sits in the graphics card's memory • 100% CPU: all of it is in system memory • a split like 48%/52% CPU/GPU: part of it is on the GPU, the rest in system memory Models also stay loaded for a while after you use them. ollama stop unloads one now, and keep_alive (or OLLAMA_KEEP_ALIVE for the whole server) sets how long they stay: 0 unloads right after a response, a negative number keeps the model loaded. docs.ollama.com/faq