robot_lab 0.2.8 → 0.3.0

data/examples/15_memory_network_and_bus/output/final_article.md

@@ -1,13 +1,8 @@
-# Final Article — APPROVED
+# Final Article — NOT APPROVED (max revisions reached)
 
-For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on budget, tolerance for system maintenance, and—most important—the workload. Local inference, quantized experimentation, LoRA-style fine-tuning, and full-scale multi-GPU training place very different demands on a machine. Each platform has real strengths. macOS offers a polished, low-friction experience on Apple Silicon, with excellent power efficiency and increasingly capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style AI development. Linux, meanwhile, remains the closest match to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-style workflows. BSD is more niche, but still relevant for users who value storage integrity and system control.
+**Choosing an Operating System for a Home AI Research Lab**
 
-Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually deliver the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home fine-tuning and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU setups. macOS is less modular and often more expensive upfront, but Apple Silicon offers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the heat, noise, and power draw of a traditional tower.
+A home AI research lab is no longer a single-purpose machine; it is usually a mixed environment for LLM inference, fine-tuning, embeddings, RAG pipelines, image generation, and long-running experiments. That makes the operating-system decision less about ideology and more about where the workload, hardware, and maintenance burden intersect. macOS, Windows, and Linux/BSD are all credible choices, but they optimize for different strengths: Apple Silicon efficiency and unified memory, Windows breadth and NVIDIA compatibility, or Linux control, containerization, and reproducibility.
 
-The software stack is where Linux keeps its advantage. Most modern machine-learning infrastructure is developed and deployed with Linux as the default target, so CUDA, PyTorch, DeepSpeed, vLLM, Docker, and many research repositories are typically best supported there. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends. TensorFlow support is more uneven than it once was in native Windows setups, however, and many users now rely on WSL2 for a more current Linux-compatible path. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but Apple Silicon does not offer NVIDIA/CUDA-class upgradeability or equally broad support for large-scale training stacks.
-
-Ease of use depends on what kind of friction matters most. macOS is arguably the easiest platform to live with day to day: its Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project of its own. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, productivity, and media-heavy desktop applications; broad driver support and a vast library of community tutorials are significant advantages. Linux demands more initiative up front, but rewards that effort with stronger reproducibility, better remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better understood as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
-
-The practical recommendation depends on what “home AI lab” means in your case. If your workload is primarily local inference, evaluation, scripting, and moderate fine-tuning, macOS is an excellent fit. If you want a single versatile workstation for image generation, local model serving, and NVIDIA-accelerated experimentation—with access to Linux tooling when needed—Windows is highly compelling. If your priority is full training compatibility, containerized workflows, remote operation, or a setup that mirrors production and rented GPU environments, Linux is the strongest foundation.
-
-For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are built and run. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single all-purpose workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over maximum training flexibility. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.
+**macOS: the efficient, low-maintenance local-inference platform**  
+macOS is strongest when the home lab prioritizes quiet operation, low power draw, and a polished developer environment. Apple Silicon’s unified memory architecture is the key advantage: a 64GB Mac can run 7B, 13B, and many 30B-class quantized models comfortably, and can handle 70B-class Q4/Q5 models with reduced context or partial offload, while a 128GB machine becomes a much more practical platform for larger local inference work. The software stack has also matured: PyTorch MPS, MLX, MLX-LM, llama.cpp, Ollama, LM Studio, Hugging Face Transformers, and parameter-efficient fine-tuning tools give Apple a credible path into LLM experimentation, while Stable Diffusion, SDXL, and local image-generation workflows are increasingly usable through Metal, Core ML, and MLX backends. The tradeoffs are cost and hardware flexibility. A 64GB Apple Silicon machine may cost roughly $2,000–$4,500 depending on chassis, and 128GB configurations can reach $5,500–$8

data/examples/15_memory_network_and_bus/output/linux_draft.md

@@ -1,7 +1,7 @@
 # linux_writer Draft
 
-If you’re building a home AI research lab for LLM fine-tuning, image generation, and local inference, Linux/BSD is the best foundation because it gives you full control of the hardware and software stack in a way consumer desktop OSes simply don’t. On Ubuntu/Debian, that means straightforward NVIDIA CUDA installation, broad compatibility with PyTorch, TensorFlow, JAX, Hugging Face Transformers, bitsandbytes, vLLM, Ollama, and Stable Diffusion toolchains like AUTOMATIC1111, ComfyUI, and InvokeAI. Fedora/RHEL brings the same AI-ready strengths with newer kernels, strong NVIDIA and AMD support, and excellent container workflows through Podman and Docker-compatible tooling, plus SELinux for safer multi-service setups. And if your lab values long-term predictability and data integrity, FreeBSD is compelling for its ZFS snapshots, lightweight jails, and bhyve virtualization—especially for storing large model checkpoints, datasets, and reproducible experiment environments.
+For a home AI research lab, Linux is the most practical foundation because it gives you direct control over the exact stack that matters most: GPUs, drivers, containers, and ML frameworks. Whether you choose Ubuntu/Debian for its mature apt ecosystem or Fedora for newer kernels and tooling, you get first-class support for CUDA, cuDNN, PyTorch, and the container runtimes that modern AI workflows depend on. That means you can move cleanly from local inference with Ollama, vLLM, or llama.cpp to LLM fine-tuning with PyTorch, Transformers, PEFT, and LoRA-based workflows, then into image generation with Stable Diffusion, ComfyUI, or WebUI-style stacks—all without fighting OS-level abstraction layers. If your goal is rapid experimentation with current hardware, Fedora’s near-latest drivers and strong RHEL-compatible toolchain are especially attractive, while Ubuntu and Debian offer the kind of long-term stability that makes a home lab easy to maintain.
 
-Performance and workflow are where Linux/BSD really pull ahead. AI researchers want server-parity: the same CUDA libraries, Python environments, container images, SSH workflows, and orchestration patterns they’ll use on rented GPUs or lab servers. Linux is the default target for most ML infrastructure, so fine-tuning with PyTorch + DeepSpeed, FSDP, PEFT/LoRA, Axolotl, llama.cpp, or text-generation-webui generally works first and best there. ROCm support for AMD is also primarily Linux-first. Developer tooling is mature and frictionless: apt, dnf, pip, conda, uv, poetry, tmux, systemd, Podman/Docker, NVIDIA Container Toolkit, and VS Code Remote SSH all fit naturally into a research workflow. That makes it easy to run one box as a local inference host, another as a training node, and package both with containers for repeatable deployments.
+The software ecosystem is another major advantage. Linux is where Docker, Podman, GPU containers, and cluster-oriented tooling are most natural, so you can reproduce environments reliably across machines and experiments. That matters when you are juggling multiple workloads: fine-tuning a 7B or 13B model, running local inference, and serving image-generation pipelines at the same time. You can isolate projects in containers, use SELinux or AppArmor where supported, and keep a clean separation between experimental code, datasets, and long-running services. For a research lab, that repeatability is not a nice-to-have—it is the difference between a hobby setup and a serious system.
 
-Just as important, Linux/BSD gives you massive community support and a free, open ecosystem that rewards experimentation instead of fighting it. If you hit a CUDA mismatch, need a custom kernel module, want to pin an older Python for a model repo, or need community-tested guides for QLoRA fine-tuning on an RTX 4090, the answer is almost always documented somewhere for Ubuntu, Debian, Fedora, or another major distro. That depth of packages, tutorials, and forum knowledge matters when you’re juggling GPU drivers, model servers, vector databases, and web UIs at home. In practical terms: Linux is the native habitat of AI/ML tooling, Fedora/RHEL offers a modern and enterprise-grade path, Ubuntu/Debian maximize ease and compatibility, and FreeBSD adds unmatched storage discipline and clean isolation. For a serious home AI lab, Linux/BSD isn’t just a good choice—it’s the platform that most directly aligns with how modern AI systems are actually built and run.
+Finally, the breadth of community support makes Linux and BSD the safer long-term bet. Ubuntu, Debian, and Fedora have deep documentation, broad driver support, and active communities around AI tooling, so when something breaks, you are not alone. And if you want to go further, FreeBSD adds a genuinely valuable complementary layer: ZFS-backed data integrity, snapshotting, and strong isolation through jails and bhyve can be excellent for protecting datasets, preserving experiment state, and running isolated workloads. In practical terms, the best home lab often uses Linux as the primary training and inference platform, with FreeBSD as a hardened storage and experiment-isolation node—giving you performance, reliability, and data protection in one coherent system.

data/examples/15_memory_network_and_bus/output/mac_draft.md

@@ -1,7 +1,7 @@
 # mac_writer Draft
 
-macOS is a remarkably strong choice for a home AI research lab, especially if your work centers on LLM fine-tuning, image generation, and local inference. On Apple Silicon, you get an unusually compelling mix of CPU, GPU, and unified memory in one quiet, power-efficient system. That matters in real workflows: local inference with tools like Ollama, LM Studio, and llama.cpp runs smoothly on M-series Macs, while PyTorch has native Metal Performance Shaders support so models can use the integrated GPU without needing a discrete NVIDIA card. For image generation, projects such as Stable Diffusion, ComfyUI, and AUTOMATIC1111 can run effectively on macOS, and Apple’s unified memory architecture is especially useful when working with larger models or batching workflows that would otherwise be constrained by separate VRAM limits.
+For a home AI research lab, macOS running on Apple Silicon is one of the most practical platforms you can build around, especially when the workload is LLM fine-tuning, image generation, and local inference. The key advantage is the combination of Apple’s unified memory architecture, Metal Performance Shaders, and a Unix-based developer environment. On a high-memory Mac such as an M3 Max or M4 Max machine with 64–128 GB of unified memory, you can comfortably run quantized 7B, 13B, 30B, and even some 70B-class open-weight models for local inference without relying on a separate CUDA server. That makes macOS ideal for a low-noise, low-power lab that can sit in a closet, office, or bedroom and stay available for experiments, embeddings, RAG pipelines, and model evaluation.
 
-The software ecosystem is another major advantage. macOS gives you a Unix foundation with first-class terminal tooling, Homebrew for package management, and easy access to Python, Conda, Docker alternatives, Git, SSH, tmux, and Jupyter-based workflows. For AI development specifically, you can work with PyTorch on Metal, TensorFlow with Apple’s ML extensions, Hugging Face Transformers, llama.cpp, ONNX Runtime, MLX, and Core ML. Apple’s MLX framework is particularly exciting for home researchers because it is built for Apple Silicon and makes training and inference on local hardware feel much more natural. Core ML also gives you a path to highly optimized deployment for local apps and edge-style workflows, which is useful if your lab includes benchmarking, model packaging, or building inference tools for personal use.
+The software ecosystem has matured into a real AI research environment. PyTorch’s MPS backend works well with Hugging Face Transformers, Diffusers, Accelerate, and common fine-tuning stacks for LoRA, QLoRA, and parameter-efficient training. For image generation, you can run Stable Diffusion, SDXL, Flux-style pipelines, and local ComfyUI-style workflows with reasonable performance, especially when the model is memory-efficient. For LLMs, tools like LM Studio, Ollama, llama.cpp, MLX, and MLX-LM give you strong local inference options, while MLX is particularly attractive because it is built specifically for Apple Silicon and can make fine-tuning, evaluation, and inference feel native rather than emulated. If you want tighter integration with Apple’s hardware, Core ML and CoreMLTools let you optimize models for on-device and Apple-Silicon deployment, which is useful when you are testing prompts, agents, multimodal models, or local assistants.
 
-What makes macOS arguably the best home-lab platform is how well the whole stack fits together. Hardware compatibility is simple because Apple controls the platform end to end; you are not spending weekends debugging GPU drivers, CUDA mismatches, or power and cooling issues. An M2 Max, M3 Pro, or higher-end M-series system can serve as a capable always-on research workstation that handles experimentation, scripting, quantized fine-tuning, evaluation, and media generation while drawing far less power than a traditional multi-GPU tower. Add in strong developer tooling like Xcode, VS Code, iTerm2, and excellent community support around Apple Silicon optimization, and you get a platform that is stable, efficient, and genuinely productive. If you want a home AI lab that prioritizes practical local experimentation over endless infrastructure maintenance, macOS is hard to beat.
+What makes macOS especially compelling for a home lab is the balance between power, usability, and ecosystem support. You get a real Unix terminal, Python toolchains, Homebrew, Docker workflows, VS Code, Jupyter, Ray, Git, and the same command-line culture as a Linux server, but without the hassle of maintaining a separate machine or dealing with Windows driver friction. Apple Silicon Macs are also extremely efficient: they draw far less power than many comparable GPU workstations, run cool and quiet, and can stay on for days running local LLM servers, embedding pipelines, or image-generation experiments. For a solo researcher or small team building a local-first AI lab, macOS offers a credible path to serious fine-tuning, generation, and inference work while keeping the setup compact, fast, and easy to manage.

data/examples/15_memory_network_and_bus/output/memory.json

@@ -3,11 +3,11 @@
   "results": [],
   "messages": [],
   "custom": {
-    "ubuntu_specialist": "Ubuntu/Debian is a strong choice for a home AI research lab because it offers excellent hardware and driver support, especially for NVIDIA CUDA setups, while keeping software installation straightforward through the apt ecosystem. It’s also stable, well-documented, and widely used in research and server environments, which makes troubleshooting, automation, and reproducing experiments much easier.",
-    "windows_draft": "Windows is the strongest all-around choice for a home AI research lab because it gives you the best combination of raw GPU support, hardware flexibility, and practical developer workflow. For LLM fine-tuning, image generation, and local inference, NVIDIA CUDA support on Windows is first-class: PyTorch, TensorFlow, xFormers, bitsandbytes, TensorRT, ONNX Runtime, and popular tools like Ollama, LM Studio, ComfyUI, AUTOMATIC1111, and Stable Diffusion WebUI all have strong Windows paths. If you want the highest-performance consumer GPUs for AI work, Windows pairs especially well with NVIDIA RTX hardware, from a single 4070 Ti Super up to multi-GPU prosumer setups. And if you need Linux-native scripts or package workflows, WSL2 gives you a near-seamless Ubuntu environment on the same machine, so you can run Hugging Face Transformers, PEFT, DeepSpeed, vLLM, llama.cpp, JupyterLab, and CUDA-enabled Linux tooling without giving up native Windows apps.\n\nWindows also wins on hardware compatibility and ecosystem breadth. A home lab often mixes gaming-class GPUs, high-core-count CPUs, fast NVMe storage, USB devices, capture cards, and sometimes unusual motherboard or networking gear; Windows consistently offers the widest driver support and easiest setup across that mix. Beyond CUDA, Windows also supports DirectML, which broadens acceleration options on AMD and Intel hardware for local inference and experimentation. On the tooling side, it integrates cleanly with Visual Studio Code, Visual Studio, Docker Desktop, PowerShell, Windows Terminal, Git for Windows, and enterprise-friendly tools for remote access, file sharing, backup, and virtualization. In practice, that means you can fine-tune a LoRA in WSL2, monitor GPUs with native Windows utilities, manage datasets on NTFS storage, launch ComfyUI or LM Studio from the desktop, and still have access to familiar scripting and automation.\n\nJust as important, Windows has massive community support for home AI builders. Most consumer AI guides now assume either native Windows or Windows plus WSL2, especially for Stable Diffusion workflows, local LLM front ends, and single-node fine-tuning recipes. Troubleshooting is easier when there are abundant guides for CUDA driver versions, PyTorch wheels, Flash Attention builds, and model-serving stacks on common RTX cards. For someone building a serious home AI lab, Windows offers the most practical balance: top-tier NVIDIA performance, Linux compatibility when you need it, broad hardware support, and a mature tool ecosystem that scales from casual experimentation to disciplined research workflows.",
-    "mac_draft": "macOS is a remarkably strong choice for a home AI research lab, especially if your work centers on LLM fine-tuning, image generation, and local inference. On Apple Silicon, you get an unusually compelling mix of CPU, GPU, and unified memory in one quiet, power-efficient system. That matters in real workflows: local inference with tools like Ollama, LM Studio, and llama.cpp runs smoothly on M-series Macs, while PyTorch has native Metal Performance Shaders support so models can use the integrated GPU without needing a discrete NVIDIA card. For image generation, projects such as Stable Diffusion, ComfyUI, and AUTOMATIC1111 can run effectively on macOS, and Apple’s unified memory architecture is especially useful when working with larger models or batching workflows that would otherwise be constrained by separate VRAM limits.\n\nThe software ecosystem is another major advantage. macOS gives you a Unix foundation with first-class terminal tooling, Homebrew for package management, and easy access to Python, Conda, Docker alternatives, Git, SSH, tmux, and Jupyter-based workflows. For AI development specifically, you can work with PyTorch on Metal, TensorFlow with Apple’s ML extensions, Hugging Face Transformers, llama.cpp, ONNX Runtime, MLX, and Core ML. Apple’s MLX framework is particularly exciting for home researchers because it is built for Apple Silicon and makes training and inference on local hardware feel much more natural. Core ML also gives you a path to highly optimized deployment for local apps and edge-style workflows, which is useful if your lab includes benchmarking, model packaging, or building inference tools for personal use.\n\nWhat makes macOS arguably the best home-lab platform is how well the whole stack fits together. Hardware compatibility is simple because Apple controls the platform end to end; you are not spending weekends debugging GPU drivers, CUDA mismatches, or power and cooling issues. An M2 Max, M3 Pro, or higher-end M-series system can serve as a capable always-on research workstation that handles experimentation, scripting, quantized fine-tuning, evaluation, and media generation while drawing far less power than a traditional multi-GPU tower. Add in strong developer tooling like Xcode, VS Code, iTerm2, and excellent community support around Apple Silicon optimization, and you get a platform that is stable, efficient, and genuinely productive. If you want a home AI lab that prioritizes practical local experimentation over endless infrastructure maintenance, macOS is hard to beat.",
-    "fedora_specialist": "Fedora and RHEL are strong choices for a home AI research lab because they combine up-to-date kernels, excellent NVIDIA/AMD driver support, and robust container tooling like Podman, making it easy to run modern ML workloads reliably. They also offer strong SELinux security, reproducible enterprise-style workflows, and a clear path from experimentation on Fedora to long-term stability on RHEL-compatible systems.",
-    "freebsd_specialist": "FreeBSD is a strong choice for a home AI research lab because it offers excellent stability, predictable system behavior, and powerful storage features through ZFS, which is ideal for protecting large datasets and snapshots of experiment environments. Its lightweight jails and bhyve virtualization make it easy to isolate services and test setups efficiently, while the base system’s consistency helps reduce maintenance overhead for long-running workloads.",
-    "linux_draft": "If you’re building a home AI research lab for LLM fine-tuning, image generation, and local inference, Linux/BSD is the best foundation because it gives you full control of the hardware and software stack in a way consumer desktop OSes simply don’t. On Ubuntu/Debian, that means straightforward NVIDIA CUDA installation, broad compatibility with PyTorch, TensorFlow, JAX, Hugging Face Transformers, bitsandbytes, vLLM, Ollama, and Stable Diffusion toolchains like AUTOMATIC1111, ComfyUI, and InvokeAI. Fedora/RHEL brings the same AI-ready strengths with newer kernels, strong NVIDIA and AMD support, and excellent container workflows through Podman and Docker-compatible tooling, plus SELinux for safer multi-service setups. And if your lab values long-term predictability and data integrity, FreeBSD is compelling for its ZFS snapshots, lightweight jails, and bhyve virtualization—especially for storing large model checkpoints, datasets, and reproducible experiment environments.\n\nPerformance and workflow are where Linux/BSD really pull ahead. AI researchers want server-parity: the same CUDA libraries, Python environments, container images, SSH workflows, and orchestration patterns they’ll use on rented GPUs or lab servers. Linux is the default target for most ML infrastructure, so fine-tuning with PyTorch + DeepSpeed, FSDP, PEFT/LoRA, Axolotl, llama.cpp, or text-generation-webui generally works first and best there. ROCm support for AMD is also primarily Linux-first. Developer tooling is mature and frictionless: apt, dnf, pip, conda, uv, poetry, tmux, systemd, Podman/Docker, NVIDIA Container Toolkit, and VS Code Remote SSH all fit naturally into a research workflow. That makes it easy to run one box as a local inference host, another as a training node, and package both with containers for repeatable deployments.\n\nJust as important, Linux/BSD gives you massive community support and a free, open ecosystem that rewards experimentation instead of fighting it. If you hit a CUDA mismatch, need a custom kernel module, want to pin an older Python for a model repo, or need community-tested guides for QLoRA fine-tuning on an RTX 4090, the answer is almost always documented somewhere for Ubuntu, Debian, Fedora, or another major distro. That depth of packages, tutorials, and forum knowledge matters when you’re juggling GPU drivers, model servers, vector databases, and web UIs at home. In practical terms: Linux is the native habitat of AI/ML tooling, Fedora/RHEL offers a modern and enterprise-grade path, Ubuntu/Debian maximize ease and compatibility, and FreeBSD adds unmatched storage discipline and clean isolation. For a serious home AI lab, Linux/BSD isn’t just a good choice—it’s the platform that most directly aligns with how modern AI systems are actually built and run."
+    "ubuntu_specialist": "Ubuntu and Debian provide a stable, well-documented apt ecosystem with broad driver and library support, making it easy to install CUDA, cuDNN, PyTorch, and other research tools. Their strong hardware compatibility and long-term updates help keep a home lab reliable and low-maintenance.",
+    "fedora_specialist": "Fedora offers near-latest kernels, drivers, and ML tooling while remaining stable, making it well-suited for rapid AI development. Its RHEL compatibility, SELinux hardening, and mature container/cluster tooling give a home lab the security and repeatability needed for serious research.",
+    "freebsd_specialist": "FreeBSD’s ZFS integration provides reliable snapshots and data integrity, helping protect valuable research datasets from accidental loss. Its jails and bhyve virtualization make it easy to isolate experiments, and its long-running stability is well suited for home AI research workloads.",
+    "windows_draft": "Windows gives a home AI research lab the broadest practical foundation, especially when you need NVIDIA CUDA performance without sacrificing access to Linux-centric tooling. With a native Windows environment, you get first-class NVIDIA driver and CUDA support, making it easy to run PyTorch, Hugging Face Transformers, PEFT/LoRA fine-tuning scripts, TensorBoard, and local inference stacks such as Ollama, llama.cpp, or text-generation-webui. At the same time, WSL2 gives you a near-native Linux userspace with GPU passthrough, so you can work in Ubuntu, Docker, or containerized pipelines while still using Windows-native tools like Visual Studio Code, Windows Terminal, and Docker Desktop. That combination is rare: you get the Linux ecosystem that much of the AI community expects, without being locked out of the desktop experience, hardware compatibility, and driver maturity that Windows still handles best.\n\nFor image generation and local inference, Windows is especially convenient because it supports both CUDA and DirectML paths. If you are using an NVIDIA GPU, you can run Stable Diffusion WebUI, ComfyUI, InvokeAI, or SD.Next with strong CUDA backend support, then move to ONNX Runtime, DirectML, or OpenVINO when you need broader hardware flexibility. For AMD or Intel GPUs, DirectML and ONNX Runtime can still provide a usable local inference stack, while the widest consumer and workstation GPU selection on Windows means you can build a high-VRAM lab without needing a single vendor ecosystem. That matters for a home setup: you can mix high-end NVIDIA cards, consumer accelerators, large local SSDs, and Windows-native management tools while keeping the same machine useful for everyday work.\n\nThe software ecosystem and community support also favor Windows for a hybrid lab workflow. You can develop in Windows-native Python environments, use Miniconda or PyCharm, and run the same CUDA-accelerated PyTorch and Hugging Face workflows that are common in production, while falling back to WSL2 when a package, dataset, or framework expects a Linux environment. The result is a lab that is flexible rather than ideological: CUDA when performance and compatibility are priority one, WSL2 when Linux tooling is expected, DirectML/ONNX when hardware breadth matters, and a large Windows/NVIDIA/Python community to lean on when debugging drivers, VRAM issues, or fine-tuning pipelines. For a home LLM fine-tuning, image generation, and local inference setup, that balance is exactly why Windows is such a strong choice.",
+    "mac_draft": "For a home AI research lab, macOS running on Apple Silicon is one of the most practical platforms you can build around, especially when the workload is LLM fine-tuning, image generation, and local inference. The key advantage is the combination of Apple’s unified memory architecture, Metal Performance Shaders, and a Unix-based developer environment. On a high-memory Mac such as an M3 Max or M4 Max machine with 64–128 GB of unified memory, you can comfortably run quantized 7B, 13B, 30B, and even some 70B-class open-weight models for local inference without relying on a separate CUDA server. That makes macOS ideal for a low-noise, low-power lab that can sit in a closet, office, or bedroom and stay available for experiments, embeddings, RAG pipelines, and model evaluation.\n\nThe software ecosystem has matured into a real AI research environment. PyTorch’s MPS backend works well with Hugging Face Transformers, Diffusers, Accelerate, and common fine-tuning stacks for LoRA, QLoRA, and parameter-efficient training. For image generation, you can run Stable Diffusion, SDXL, Flux-style pipelines, and local ComfyUI-style workflows with reasonable performance, especially when the model is memory-efficient. For LLMs, tools like LM Studio, Ollama, llama.cpp, MLX, and MLX-LM give you strong local inference options, while MLX is particularly attractive because it is built specifically for Apple Silicon and can make fine-tuning, evaluation, and inference feel native rather than emulated. If you want tighter integration with Apple’s hardware, Core ML and CoreMLTools let you optimize models for on-device and Apple-Silicon deployment, which is useful when you are testing prompts, agents, multimodal models, or local assistants.\n\nWhat makes macOS especially compelling for a home lab is the balance between power, usability, and ecosystem support. You get a real Unix terminal, Python toolchains, Homebrew, Docker workflows, VS Code, Jupyter, Ray, Git, and the same command-line culture as a Linux server, but without the hassle of maintaining a separate machine or dealing with Windows driver friction. Apple Silicon Macs are also extremely efficient: they draw far less power than many comparable GPU workstations, run cool and quiet, and can stay on for days running local LLM servers, embedding pipelines, or image-generation experiments. For a solo researcher or small team building a local-first AI lab, macOS offers a credible path to serious fine-tuning, generation, and inference work while keeping the setup compact, fast, and easy to manage.",
+    "linux_draft": "For a home AI research lab, Linux is the most practical foundation because it gives you direct control over the exact stack that matters most: GPUs, drivers, containers, and ML frameworks. Whether you choose Ubuntu/Debian for its mature apt ecosystem or Fedora for newer kernels and tooling, you get first-class support for CUDA, cuDNN, PyTorch, and the container runtimes that modern AI workflows depend on. That means you can move cleanly from local inference with Ollama, vLLM, or llama.cpp to LLM fine-tuning with PyTorch, Transformers, PEFT, and LoRA-based workflows, then into image generation with Stable Diffusion, ComfyUI, or WebUI-style stacks—all without fighting OS-level abstraction layers. If your goal is rapid experimentation with current hardware, Fedora’s near-latest drivers and strong RHEL-compatible toolchain are especially attractive, while Ubuntu and Debian offer the kind of long-term stability that makes a home lab easy to maintain.\n\nThe software ecosystem is another major advantage. Linux is where Docker, Podman, GPU containers, and cluster-oriented tooling are most natural, so you can reproduce environments reliably across machines and experiments. That matters when you are juggling multiple workloads: fine-tuning a 7B or 13B model, running local inference, and serving image-generation pipelines at the same time. You can isolate projects in containers, use SELinux or AppArmor where supported, and keep a clean separation between experimental code, datasets, and long-running services. For a research lab, that repeatability is not a nice-to-have—it is the difference between a hobby setup and a serious system.\n\nFinally, the breadth of community support makes Linux and BSD the safer long-term bet. Ubuntu, Debian, and Fedora have deep documentation, broad driver support, and active communities around AI tooling, so when something breaks, you are not alone. And if you want to go further, FreeBSD adds a genuinely valuable complementary layer: ZFS-backed data integrity, snapshotting, and strong isolation through jails and bhyve can be excellent for protecting datasets, preserving experiment state, and running isolated workloads. In practical terms, the best home lab often uses Linux as the primary training and inference platform, with FreeBSD as a hardened storage and experiment-isolation node—giving you performance, reliability, and data protection in one coherent system."
   }
 }

data/examples/15_memory_network_and_bus/output/revision_1.md

@@ -1,18 +1,29 @@
 # Revision 1
 
-This is strong as written. Here’s a lightly tightened editorial version with a slightly smoother cadence and clearer conclusion:
+This is already a strong, balanced article. It meets the brief: it acknowledges each platform, compares them fairly, maps scenarios to OS choices, and ends with a nuanced but clear recommendation. The tone is appropriately editorial rather than advocacy-heavy, and the structure is clean.
 
-For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on your hardware budget, tolerance for system maintenance, and the kind of AI work you plan to do. Each platform has legitimate strengths. macOS offers a polished, low-friction experience on Apple Silicon, combining strong power efficiency with capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style development. Linux, meanwhile, remains the closest analogue to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-oriented tooling. BSD is more niche, but still relevant for users who care deeply about storage integrity and system control.
+A few optional refinements would make it slightly sharper:
 
-Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually offer the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home training and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU configurations. macOS is less modular and often more expensive upfront, but Apple Silicon delivers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the noise, heat, and power demands of a traditional tower.
+1. **Make the cost comparison a little more explicit**  
+   You mention cost briefly in the macOS paragraph, but the comparison across all three platforms could be slightly more balanced. A small phrase in the introduction or in the Linux paragraph could help, e.g.:
+   - macOS: high upfront cost for memory and hardware  
+   - Windows: broadest cost flexibility across consumer, workstation, and mixed hardware  
+   - Linux: often lower acquisition cost, but higher maintenance cost
 
-The software stack is where Linux keeps its edge. It remains the default environment for much of modern machine-learning infrastructure: CUDA, PyTorch, JAX, DeepSpeed, vLLM, Docker, and countless research repositories tend to land there first. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, TensorFlow, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends, while WSL2 allows users to mix native desktop convenience with Linux workflows on the same machine. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but it still lacks the same universality for cutting-edge training stacks and does not offer a straightforward route to top-tier discrete-GPU performance.
+2. **Tighten the final recommendation slightly**  
+   The final paragraph is good, but it could be marginally more decisive while remaining nuanced. For example:
 
-Ease of use depends on what kind of friction matters most to you. macOS is arguably the easiest platform to live with day to day: the Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project in itself. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, general productivity, and media-heavy desktop applications; its broad driver support and vast library of community tutorials are real advantages. Linux demands more initiative up front, but rewards that effort with better reproducibility, stronger remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better viewed as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
+   > In short: choose macOS if your lab is memory-constrained, low-noise, and Apple-centric; choose Windows if you want the broadest hardware flexibility with a familiar desktop; and choose Linux if you want the most control and reproducibility. For most serious home AI labs, Linux or Windows-with-WSL2 will be the more broadly practical choices, while macOS remains an excellent option when efficiency, simplicity, and local inference are the main priorities.
 
-The practical recommendation is straightforward, even if the answer is not one-size-fits-all. For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are developed and deployed. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single versatile workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over absolute training performance. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.
+3. **Clarify “Linux/BSD” vs. “FreeBSD”**  
+   The article currently treats BSD mainly through FreeBSD, which is fine, but a small clarification would make that smoother. For example:
+   - “Linux—and, in some cases, BSD—”
+   - or keep “Linux/BSD” but specify later that FreeBSD is the most relevant BSD choice for data integrity and isolation.
 
-If you want, I can also:
-- make it more magazine-like and opinionated,
-- make it shorter and punchier,
-- or remove the final “Linux-first” tilt to make it even more neutral.
+4. **Minor wording polish**  
+   A few small phrases could be tightened:
+   - “maximum-throughput training server” → “large-scale training server”
+   - “most practical all-round option” → “most versatile practical option”
+   - “strongest foundation” → “strongest foundation for a serious lab”
+
+If you want, I can also produce a **tighter final version** of the article with these edits incorporated, or rewrite it in a slightly more **magazine-style editorial voice** versus a **technical blog voice**.

data/examples/15_memory_network_and_bus/output/revision_2.md

@@ -1,13 +1,50 @@
 # Revision 2
 
-For a home AI research lab, the operating-system decision is less ideological than practical. The right choice depends on budget, tolerance for system maintenance, and—most important—the workload. Local inference, quantized experimentation, LoRA-style fine-tuning, and full-scale multi-GPU training place very different demands on a machine. Each platform has real strengths. macOS offers a polished, low-friction experience on Apple Silicon, with excellent power efficiency and increasingly capable support for local inference and lighter fine-tuning. Windows remains the most flexible consumer platform for pairing NVIDIA GPUs with mainstream desktop workflows, and WSL2 has made it far more credible for Linux-style AI development. Linux, meanwhile, remains the closest match to professional AI infrastructure, with the broadest native support for CUDA, containers, automation, and server-style workflows. BSD is more niche, but still relevant for users who value storage integrity and system control.
+User wants revise article. Feedback: previous response was meta-review? Wait they likely mean the article I gave? Actually user says "This is a meta-review, not the article itself. Please submit the actual piece for editorial review. If this text is intended as the final submission, it fails as a publication article because it lacks concrete platform details, technical evidence, and standalone structure. Convert it into an editorial with clear sections for macOS, Windows, and Linux/BSD, include specific cost and technical comparisons, clarify the BSD scope, and end with a decisive recommendation."
 
-Cost and hardware flexibility are among the clearest dividing lines. For maximum GPU throughput, Windows and Linux usually deliver the best price-performance because both support commodity x86 systems built around upgradeable NVIDIA RTX hardware, still the dominant option for home fine-tuning and image-generation workloads. They also accommodate a wider range of components, from motherboards and high-speed storage to networking gear and multi-GPU setups. macOS is less modular and often more expensive upfront, but Apple Silicon offers a different kind of value: compact, quiet systems with efficient integrated acceleration and unified memory that work well for local inference, quantized models, and practical experimentation without the heat, noise, and power draw of a traditional tower.
+Need produce actual editorial, not meta-review. Clear sections for macOS, Windows, Linux/BSD. Include specific cost and technical comparisons. Clarify BSD scope. End decisive recommendation. Professional editorial voice. Objective. Need likely 4-6 paragraphs? Original brief said 4-6 paragraphs article. Now says clear sections for macOS, Windows, Linux/BSD. Could use headings and sections. Need include concrete details: Apple M4 Max 36/48/64/128GB, $3,999-? M4 Max Base 36GB $3,999? M3 Max 48GB $5,499? Need be accurate but not too exact? We can mention approximate prices. Need avoid false specifics. Let's check known Apple prices: M4 MacBook Pro 14-inch: $1,599 base 16GB/24? M4 Pro 24GB $1,999? M4 Max 36GB $3,999? M4 Max 48GB +$200? M4 Max 128GB +$? Apple Mac mini M4 Pro 24GB $1,399; Mac Studio M4 Max 36GB $1,999, M4 Max 48/64/128? M4 Max 128GB maybe $3,499? Actually Mac Studio M4 Max starts $1,999 36GB, up to 128GB maybe $3,499. MacBook Pro M4 Max 128GB maybe $6,999? Need careful. Could say "a 128 GB Mac Studio or MacBook Pro can cost $3,500–$7,000 or more". Good approximate.
 
-The software stack is where Linux keeps its advantage. Most modern machine-learning infrastructure is developed and deployed with Linux as the default target, so CUDA, PyTorch, DeepSpeed, vLLM, Docker, and many research repositories are typically best supported there. It is also the strongest option for AMD ROCm users. Windows runs a close second for NVIDIA-based labs, with broad support for PyTorch, ONNX Runtime, Stable Diffusion toolchains, and local-LLM front ends. TensorFlow support is more uneven than it once was in native Windows setups, however, and many users now rely on WSL2 for a more current Linux-compatible path. macOS has improved substantially, especially for inference and smaller-scale development through Metal, MLX, Core ML, llama.cpp, and Apple-optimized PyTorch paths, but Apple Silicon does not offer NVIDIA/CUDA-class upgradeability or equally broad support for large-scale training stacks.
+Windows cost: entry 8GB useless; 32GB RAM with RTX 4060 Ti 16GB around $1,500-$2,000; RTX 4090/5090 24/32GB system $4,000-$8,000+. Could say "a practical 32 GB system with a 16 GB RTX card can be built for roughly $1,500–$2,000; a 24/32 GB single-GPU lab often lands in the $4,000–$8,000 range". Good.
 
-Ease of use depends on what kind of friction matters most. macOS is arguably the easiest platform to live with day to day: its Unix base is familiar to developers, hardware support is consistent, and driver management is rarely a project of its own. Windows is often the easiest starting point for users already comfortable with consumer PC hardware, especially if they want one machine for AI work, productivity, and media-heavy desktop applications; broad driver support and a vast library of community tutorials are significant advantages. Linux demands more initiative up front, but rewards that effort with stronger reproducibility, better remote-management habits, and closer alignment with cloud and lab environments. BSD, for its part, is better understood as a specialist foundation for storage and isolation than as a mainstream AI-compute platform.
+Linux cost: same hardware as Windows, no OS license, but maintenance time; used enterprise gear; Fedora/Ubuntu free; FreeBSD free. Specific GPU support: NVIDIA driver, CUDA, cuDNN, PyTorch, vLLM. Need technical evidence: unified memory: Apple can load 70B Q4 in ~40GB? Llama 3.1 70B Q4 ~40GB, fits 64GB. M-series memory bandwidth: M4 Max up to 546GB/s? M3 Max 400GB/s, M4 Max 546GB/s? Apple M4 Max 546GB/s? M3 Ultra 819GB/s. Need mention approximate inference token rates? Could avoid exact. But technical evidence: 64GB unified memory can hold quantized 70B and leave headroom; 128GB can run 123B? Could say "a 64 GB Apple Silicon machine can hold a 70B Q4/Q5 checkpoint with room for KV cache; a 128 GB machine can accommodate larger MoE or 120B-class models." Good.
 
-The practical recommendation depends on what “home AI lab” means in your case. If your workload is primarily local inference, evaluation, scripting, and moderate fine-tuning, macOS is an excellent fit. If you want a single versatile workstation for image generation, local model serving, and NVIDIA-accelerated experimentation—with access to Linux tooling when needed—Windows is highly compelling. If your priority is full training compatibility, containerized workflows, remote operation, or a setup that mirrors production and rented GPU environments, Linux is the strongest foundation.
+Windows: WSL2 GPU passthrough, CUDA 12.x, Docker Desktop WSL2 backend; RTX 4060 Ti 16GB can run 13B QLoRA, 70B inference with offload; RTX 4090 24GB for LoRA/QLoRA 13B and local SDXL; 32GB VRAM 5090 for larger. AMD/Intel via DirectML/ONNX/OpenVINO. Mention CUDA libraries, cuBLAS, TensorRT. Cost: flexible.
 
-For most serious home AI labs, Linux is the best long-term choice, especially Ubuntu, Debian, or Fedora, because it aligns most directly with how contemporary AI systems are built and run. Windows is the best fit for users who want top consumer GPU performance with fewer lifestyle compromises, particularly on a single all-purpose workstation. macOS is the best option for researchers who value stability, efficiency, and a tightly integrated experience over maximum training flexibility. Put simply: choose Linux for infrastructure fidelity, Windows for GPU-driven versatility, and macOS for elegant, low-maintenance local experimentation.
+Linux/BSD: Ubuntu LTS, Fedora, Debian; CUDA, PyTorch, vLLM, SGLang? container isolation; FreeBSD ZFS, jails, bhyve; not typical for CUDA unless NVIDIA FreeBSD? Actually NVIDIA does not officially support FreeBSD for CUDA; important clarify BSD scope: FreeBSD not for primary CUDA training; use for storage, snapshots, VM isolation; Linux for GPU work. Need clarify: BSD scope means primarily FreeBSD as data-isolation/storage node, not CUDA host. That's important.
+
+Need sections. Could title. Need decisive recommendation: e.g. "For most home AI research labs, choose Windows with WSL2 if you want maximum practical compatibility and GPU flexibility; choose Linux if you want a serious reproducible lab; choose macOS only if Apple Silicon unified memory and low maintenance are core." But need decisive recommendation singular? "If I had to recommend one default for a home lab that must do inference, fine-tuning, and image generation without over-specializing: Windows with WSL2." Then note Linux for serious, macOS for compact. Or maybe recommend Linux? The sources: Windows broadest, Linux serious. Need decisive but nuanced. Let's pick: "For a typical home AI research lab, start with Windows + WSL2 if you are building around consumer/workstation NVIDIA GPUs and need a usable daily machine. If your lab will run many long-lived services and containerized experiments, move to Linux as primary OS. macOS is the best choice when low noise, efficiency, and unified memory matter more than CUDA." But decisive recommendation? Could say "The best default is Windows with WSL2, with Linux as the more serious alternative." That satisfies.
+
+Need include concrete cost and technical comparisons. Need standalone structure.
+
+Need ensure 4-6 paragraphs? User says clear sections, likely headings with multiple paragraphs. Could be 6 sections: intro, macOS, Windows, Linux/BSD, recommendation. But original asked 4-6 paragraphs article; now asks clear sections. Could produce headings and 1-2 paragraphs each, total 6-8 paragraphs. That's okay? Need maybe not violate. "Clear sections for macOS, Windows, Linux/BSD" implies headings. We can have 5 sections. Need maybe 4-6 paragraphs overall? Could do 5 paragraphs with headings? Headings not paragraphs. Let's produce title and sections. Each section maybe one or two paragraphs. Need professional editorial voice.
+
+Need include concrete platform details and technical evidence. Need avoid overclaiming. Let's draft.
+
+Potential final:
+
+Title: Choosing an OS for a Home AI Research Lab
+
+Intro: A home AI lab is not one workload... The OS choice should be based on memory architecture, GPU path, ecosystem, cost, and maintenance.
+
+Section: macOS: unified memory and quiet local inference
+- Apple Silicon M4 Max, 36/48/64/128GB unified memory; $2k-$7k; 64GB can run 70B Q4, 128GB can run larger. MLX, llama.cpp, Ollama, PyTorch MPS, LoRA/QLoRA, Stable Diffusion/ComfyUI; no CUDA, no multi-GPU, high RAM cost, Docker virtualized.
+- Scenario: quiet office/bedroom, local inference, RAG, embeddings, image gen.
+
+Section: Windows: CUDA plus a familiar desktop
+- Broad hardware, NVIDIA CUDA native, WSL2 Linux, RTX cards 16/24/32GB. 16GB card for 7B/13B QLoRA/SDXL; 24GB for 13B LoRA/70B offload; 32GB for bigger. DirectML/ONNX for AMD/Intel. Cost $1.5k-$8k+. Easier consumer hardware, drivers. Tradeoffs fragmentation, WSL2 abstraction.
+- Scenario: NVIDIA GPU, mixed use, max hardware flexibility.
+
+Section: Linux/BSD: control, reproducibility, and serious services
+- Ubuntu LTS/Debian/Fedora; NVIDIA drivers, CUDA, cuDNN, PyTorch, vLLM, Docker/Podman, vLLM/SGLang? Isolation. Same hardware as Windows but no license; used server gear lower. Maintenance. BSD scope: FreeBSD not CUDA host; use ZFS, jails, bhyve for storage isolation/VMs; Linux primary.
+- Scenario: long-running services, reproducible experiments, data protection.
+
+Section: Recommendation
+- Decisive: For most home labs, Windows + WSL2 is best default if using NVIDIA GPUs and want usable machine. If serious multi-service/containerized/reproducible, Linux primary. If low noise and unified memory, macOS. Need maybe rank? "If forced to choose a single default: Windows with WSL2." But also say not for macOS? Need clear.
+
+Need perhaps include table? User asks article, not table. Could include a short comparison table? "include specific cost and technical comparisons" maybe table helps. But article with sections. Could include a compact table in final? Editorial could have table. But maybe not. Let's include a small table? It would be clear. But article should be prose. Could include a "At a glance" bullet list. But user wants editorial with clear sections. A table may be okay, but "article" maybe no table. Let's produce prose with specific numbers.
+
+Need ensure no unsupported exact token rates. Could include examples: 7B Q4 ~4-5GB, 13B Q4 ~8GB, 70B Q4 ~40GB. That's technical evidence. Need mention KV cache. Good.
+
+Need mention cost specifics: Mac Studio M4 Max 36GB $1,999; 64GB +$200? Actually Apple upgrades: 36 to 64 +$200? maybe $2,199. 128GB +$? maybe $3,499. MacBook Pro M4 Max 128GB $6,999. Could say "a 64 GB Mac Studio starts around $2,200, while a 128 GB MacBook Pro can exceed $6,000". Need avoid exact if uncertain. Let's say "roughly $2,000 to $7,000". Good.
+
+Windows: "A 16 GB RTX 4060 Ti or 5060 Ti system with 32 GB RAM is often

data/examples/15_memory_network_and_bus/output/revision_3.md

@@ -0,0 +1,8 @@
+# Revision 3
+
+**Choosing an Operating System for a Home AI Research Lab**
+
+A home AI research lab is no longer a single-purpose machine; it is usually a mixed environment for LLM inference, fine-tuning, embeddings, RAG pipelines, image generation, and long-running experiments. That makes the operating-system decision less about ideology and more about where the workload, hardware, and maintenance burden intersect. macOS, Windows, and Linux/BSD are all credible choices, but they optimize for different strengths: Apple Silicon efficiency and unified memory, Windows breadth and NVIDIA compatibility, or Linux control, containerization, and reproducibility.
+
+**macOS: the efficient, low-maintenance local-inference platform**  
+macOS is strongest when the home lab prioritizes quiet operation, low power draw, and a polished developer environment. Apple Silicon’s unified memory architecture is the key advantage: a 64GB Mac can run 7B, 13B, and many 30B-class quantized models comfortably, and can handle 70B-class Q4/Q5 models with reduced context or partial offload, while a 128GB machine becomes a much more practical platform for larger local inference work. The software stack has also matured: PyTorch MPS, MLX, MLX-LM, llama.cpp, Ollama, LM Studio, Hugging Face Transformers, and parameter-efficient fine-tuning tools give Apple a credible path into LLM experimentation, while Stable Diffusion, SDXL, and local image-generation workflows are increasingly usable through Metal, Core ML, and MLX backends. The tradeoffs are cost and hardware flexibility. A 64GB Apple Silicon machine may cost roughly $2,000–$4,500 depending on chassis, and 128GB configurations can reach $5,500–$8

data/examples/15_memory_network_and_bus/output/windows_draft.md

@@ -1,7 +1,7 @@
 # win_writer Draft
 
-Windows is the strongest all-around choice for a home AI research lab because it gives you the best combination of raw GPU support, hardware flexibility, and practical developer workflow. For LLM fine-tuning, image generation, and local inference, NVIDIA CUDA support on Windows is first-class: PyTorch, TensorFlow, xFormers, bitsandbytes, TensorRT, ONNX Runtime, and popular tools like Ollama, LM Studio, ComfyUI, AUTOMATIC1111, and Stable Diffusion WebUI all have strong Windows paths. If you want the highest-performance consumer GPUs for AI work, Windows pairs especially well with NVIDIA RTX hardware, from a single 4070 Ti Super up to multi-GPU prosumer setups. And if you need Linux-native scripts or package workflows, WSL2 gives you a near-seamless Ubuntu environment on the same machine, so you can run Hugging Face Transformers, PEFT, DeepSpeed, vLLM, llama.cpp, JupyterLab, and CUDA-enabled Linux tooling without giving up native Windows apps.
+Windows gives a home AI research lab the broadest practical foundation, especially when you need NVIDIA CUDA performance without sacrificing access to Linux-centric tooling. With a native Windows environment, you get first-class NVIDIA driver and CUDA support, making it easy to run PyTorch, Hugging Face Transformers, PEFT/LoRA fine-tuning scripts, TensorBoard, and local inference stacks such as Ollama, llama.cpp, or text-generation-webui. At the same time, WSL2 gives you a near-native Linux userspace with GPU passthrough, so you can work in Ubuntu, Docker, or containerized pipelines while still using Windows-native tools like Visual Studio Code, Windows Terminal, and Docker Desktop. That combination is rare: you get the Linux ecosystem that much of the AI community expects, without being locked out of the desktop experience, hardware compatibility, and driver maturity that Windows still handles best.
 
-Windows also wins on hardware compatibility and ecosystem breadth. A home lab often mixes gaming-class GPUs, high-core-count CPUs, fast NVMe storage, USB devices, capture cards, and sometimes unusual motherboard or networking gear; Windows consistently offers the widest driver support and easiest setup across that mix. Beyond CUDA, Windows also supports DirectML, which broadens acceleration options on AMD and Intel hardware for local inference and experimentation. On the tooling side, it integrates cleanly with Visual Studio Code, Visual Studio, Docker Desktop, PowerShell, Windows Terminal, Git for Windows, and enterprise-friendly tools for remote access, file sharing, backup, and virtualization. In practice, that means you can fine-tune a LoRA in WSL2, monitor GPUs with native Windows utilities, manage datasets on NTFS storage, launch ComfyUI or LM Studio from the desktop, and still have access to familiar scripting and automation.
+For image generation and local inference, Windows is especially convenient because it supports both CUDA and DirectML paths. If you are using an NVIDIA GPU, you can run Stable Diffusion WebUI, ComfyUI, InvokeAI, or SD.Next with strong CUDA backend support, then move to ONNX Runtime, DirectML, or OpenVINO when you need broader hardware flexibility. For AMD or Intel GPUs, DirectML and ONNX Runtime can still provide a usable local inference stack, while the widest consumer and workstation GPU selection on Windows means you can build a high-VRAM lab without needing a single vendor ecosystem. That matters for a home setup: you can mix high-end NVIDIA cards, consumer accelerators, large local SSDs, and Windows-native management tools while keeping the same machine useful for everyday work.
 
-Just as important, Windows has massive community support for home AI builders. Most consumer AI guides now assume either native Windows or Windows plus WSL2, especially for Stable Diffusion workflows, local LLM front ends, and single-node fine-tuning recipes. Troubleshooting is easier when there are abundant guides for CUDA driver versions, PyTorch wheels, Flash Attention builds, and model-serving stacks on common RTX cards. For someone building a serious home AI lab, Windows offers the most practical balance: top-tier NVIDIA performance, Linux compatibility when you need it, broad hardware support, and a mature tool ecosystem that scales from casual experimentation to disciplined research workflows.
+The software ecosystem and community support also favor Windows for a hybrid lab workflow. You can develop in Windows-native Python environments, use Miniconda or PyCharm, and run the same CUDA-accelerated PyTorch and Hugging Face workflows that are common in production, while falling back to WSL2 when a package, dataset, or framework expects a Linux environment. The result is a lab that is flexible rather than ideological: CUDA when performance and compatibility are priority one, WSL2 when Linux tooling is expected, DirectML/ONNX when hardware breadth matters, and a large Windows/NVIDIA/Python community to lean on when debugging drivers, VRAM issues, or fine-tuning pipelines. For a home LLM fine-tuning, image generation, and local inference setup, that balance is exactly why Windows is such a strong choice.

data/examples/16_writers_room/tools.rb

@@ -23,8 +23,8 @@ class BroadcastTool < RobotLab::Tool
               "Use for discussion, proposals, questions, or announcements. " \
               "Don't broadcast trivially — only when you have something substantive."
 
-  param :message, type: "string",
-        desc: "What to say to the room", required: true
+  parameter :message, type: "string",
+        description: "What to say to the room", required: true
 
   def execute(message:)
     log&.info("#{robot.name} TOOL broadcast (#{message.length} chars)")
@@ -42,10 +42,10 @@ class DirectMessageTool < RobotLab::Tool
               "Use for feedback on their chapter, coordination on handoffs, " \
               "or questions that don't concern the whole room."
 
-  param :to, type: "string",
-        desc: "Name of the writer to message", required: true
-  param :message, type: "string",
-        desc: "What to say", required: true
+  parameter :to, type: "string",
+        description: "Name of the writer to message", required: true
+  parameter :message, type: "string",
+        description: "What to say", required: true
 
   def execute(to:, message:)
     log&.info("#{robot.name} TOOL direct_message -> #{to} (#{message.length} chars)")
@@ -63,8 +63,8 @@ class ReadMemoryTool < RobotLab::Tool
               "Use to check the story bible, outline, chapter claims, " \
               "or read another writer's chapter draft."
 
-  param :key, type: "string",
-        desc: "Memory key to read (e.g. story_bible, outline, claims, chapter_3)", required: true
+  parameter :key, type: "string",
+        description: "Memory key to read (e.g. story_bible, outline, claims, chapter_3)", required: true
 
   def execute(key:)
     value = robot.shared_memory.get(key.to_sym)
@@ -86,10 +86,10 @@ class WriteMemoryTool < RobotLab::Tool
               "Use to store the story bible, outline, claim a chapter, " \
               "or submit a finished chapter draft."
 
-  param :key, type: "string",
-        desc: "Memory key (e.g. story_bible, outline, claims, chapter_1)", required: true
-  param :value, type: "string",
-        desc: "Content to store", required: true
+  parameter :key, type: "string",
+        description: "Memory key (e.g. story_bible, outline, claims, chapter_1)", required: true
+  parameter :value, type: "string",
+        description: "Content to store", required: true
 
   def execute(key:, value:)
     log&.info("#{robot.name} TOOL write_memory :#{key} (#{value.length} chars)")
@@ -124,8 +124,8 @@ class SpawnWriterTool < RobotLab::Tool
   description "Bring a new writer into the room to help with the workload. " \
               "Use when there are more unclaimed chapters than active writers."
 
-  param :name, type: "string",
-        desc: "Name for the new writer (e.g. writer_4)", required: true
+  parameter :name, type: "string",
+        description: "Name for the new writer (e.g. writer_4)", required: true
 
   def execute(name:)
     log&.info("#{robot.name} TOOL spawn_writer '#{name}'")

data/examples/19_token_tracking.rb

@@ -14,7 +14,7 @@
 #   naturally increase as conversation context accumulates.
 #   Use a fresh robot.build when you need a genuinely fresh context.
 #
-# Ollama reports usage counts like the hosted providers do, so the tracking
+# LM Studio reports usage counts like the hosted providers do, so the tracking
 # API behaves identically — only the price per token differs. Token counts are
 # zero for providers that don't report usage data.
 #
@@ -23,7 +23,7 @@
 
 require_relative "common"
 
-# Cost model. A local Ollama model bills nothing, so the interesting number is
+# Cost model. A local LM Studio model bills nothing, so the interesting number is
 # what the same traffic WOULD have cost on a hosted model — set RATE_INPUT_CPM
 # and RATE_OUTPUT_CPM to your provider's $-per-1M-token rates to see it.
 # Defaults are zero: local inference is free.

data/examples/20_circuit_breaker.rb

@@ -39,9 +39,9 @@ class MultiStepProcessor < RubyLLM::Tool
     the status is "complete".
   DESC
 
-  param :step_number,
+  parameter :step_number,
         type: "integer",
-        desc: "Which step to execute. Start at 1, increment by 1 each call."
+        description: "Which step to execute. Start at 1, increment by 1 each call."
 
   TOTAL_STEPS = 50  # far more than any sensible max_tool_rounds
 
@@ -125,7 +125,7 @@ section "Part 3: No Circuit Breaker — Task Terminates Naturally"
 
 class SingleStep < RubyLLM::Tool
   description "Doubles a number and returns the result immediately."
-  param :value, type: "integer", desc: "The number to double"
+  parameter :value, type: "integer", description: "The number to double"
 
   def execute(value:)
     { result: value * 2, status: "complete" }

data/examples/22_context_compression.rb

@@ -156,7 +156,7 @@ puts "cheaper robot does the summarizing for the medium-relevance band."
 show_code <<~RUBY
   summarizer_bot = RobotLab.build(
     name:          "summarizer",
-    provider:      "ollama",
+    provider:      "lms",
     model:         "qwen2.5:7b",
     system_prompt: "Summarize the following text in one sentence."
   )

data/examples/27_incident_response/README.md

@@ -0,0 +1,65 @@
+# Example 27: Production Incident War Room
+
+A simulated payment-service outage, used to demonstrate RobotLab's Phase 5
+infrastructure features: **reactive memory**, **BusPoller serialized
+delivery**, and **poller groups**.
+
+## What it does
+
+A network runs four robots against one incident ("elevated HTTP 500s, p99
+latency spiked to 8s"):
+
+- **Three SRE scouts** (`db_scout`, `net_scout`, `app_scout`) investigate the
+  database, network, and application layers in parallel. Each makes one LLM
+  call, writes its two-sentence finding to shared **reactive memory**
+  (`:db_finding`, `:net_finding`, `:app_finding`), and broadcasts a status
+  line to the war room over TypedBus.
+- **The war room** receives those bus messages through **BusPoller**, which
+  serializes delivery — if two scouts finish at the same instant, their
+  updates queue and are processed one at a time, in arrival order, with no
+  re-entrancy and nothing dropped.
+- **The incident commander** depends on all three scouts and blocks on
+  `memory.get(:db_finding, :net_finding, :app_finding, wait: 60)` — an
+  IO.pipe-backed waiter woken by `IO.select`, so there is no busy-wait and it
+  cooperates with Async. When all findings land it makes one synthesis call
+  and writes a 3-5 bullet action plan.
+
+Also on display:
+
+- **Poller groups** — the scouts run in `poller_group: :investigation`, the
+  commander in `:command`, declared per task on the network.
+- **Memory subscriptions** — a `memory.subscribe` callback prints a line as
+  each finding is written.
+- **Timeout degradation** — `Memory#get(wait:)` raises
+  `RobotLab::AwaitTimeout` rather than returning a sentinel; the commander
+  rescues it and re-reads without `wait:`, so a slow scout degrades the
+  report instead of killing the run.
+
+## How to run
+
+From the gem root (an LM Studio server must be running — `lms server start`;
+provider/model come from `examples/common.rb`):
+
+```bash
+bundle exec ruby examples/27_incident_response/incident_response.rb
+```
+
+Note that `examples/run_all.rb` does **not** include this demo — it only runs
+the top-level `NN_*.rb` files, so run it explicitly as above.
+
+The run makes four LLM calls (three scout diagnoses plus the commander's
+synthesis), so expect a few minutes on the default local model;
+`LLM_PROFILE=small` shortens it.
+
+## Output
+
+- Console: the network graph, each memory write as it happens, the war-room
+  updates in BusPoller delivery order, the scouts' findings, and the final
+  action plan.
+- `output/incident_report.md` — the commander's incident action plan.
+
+## Files
+
+- `incident_response.rb` — the whole demo: `SREScout`, `WarRoom`, and
+  `IncidentCommander` robot classes plus network wiring and the run itself
+- `output/` — where the incident report is written

data/examples/28_mcp_discovery.rb

@@ -12,7 +12,7 @@
 # == Key config
 #
 #   robot = RobotLab.build(
-#     provider: "ollama", model: "qwen3.6:latest",
+#     provider: "lms", model: "qwen/qwen3.8-27b",
 #     mcp_discovery: true,    # ← enables semantic filtering
 #     mcp: [ ... ]            # ← candidate servers, each with :description
 #   )
@@ -95,7 +95,7 @@ section "mcp_discovery: true on a Robot"
 show_code <<~RUBY
   robot = RobotLab.build(
     name:          "assistant",
-    provider:      "ollama",
+    provider:      "lms",
     model:         "qwen3.6:latest",
     mcp_discovery: true,
     mcp: [