robot_lab 0.0.1 → 0.0.6

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (187) hide show
  1. checksums.yaml +4 -4
  2. data/.github/workflows/deploy-github-pages.yml +9 -9
  3. data/.irbrc +6 -0
  4. data/CHANGELOG.md +140 -0
  5. data/README.md +263 -48
  6. data/Rakefile +71 -1
  7. data/docs/api/core/index.md +53 -46
  8. data/docs/api/core/memory.md +200 -154
  9. data/docs/api/core/network.md +13 -3
  10. data/docs/api/core/robot.md +490 -130
  11. data/docs/api/core/state.md +55 -73
  12. data/docs/api/core/tool.md +205 -209
  13. data/docs/api/index.md +7 -28
  14. data/docs/api/mcp/client.md +119 -48
  15. data/docs/api/mcp/index.md +75 -60
  16. data/docs/api/mcp/server.md +120 -136
  17. data/docs/api/mcp/transports.md +172 -184
  18. data/docs/api/messages/index.md +35 -20
  19. data/docs/api/messages/text-message.md +67 -21
  20. data/docs/api/messages/tool-call-message.md +80 -41
  21. data/docs/api/messages/tool-result-message.md +119 -50
  22. data/docs/api/messages/user-message.md +48 -24
  23. data/docs/api/streaming/context.md +157 -74
  24. data/docs/api/streaming/events.md +114 -166
  25. data/docs/api/streaming/index.md +74 -72
  26. data/docs/architecture/core-concepts.md +360 -116
  27. data/docs/architecture/index.md +97 -59
  28. data/docs/architecture/message-flow.md +138 -129
  29. data/docs/architecture/network-orchestration.md +197 -50
  30. data/docs/architecture/robot-execution.md +199 -146
  31. data/docs/architecture/state-management.md +255 -187
  32. data/docs/concepts.md +311 -49
  33. data/docs/examples/basic-chat.md +89 -77
  34. data/docs/examples/index.md +222 -47
  35. data/docs/examples/mcp-server.md +207 -203
  36. data/docs/examples/multi-robot-network.md +129 -35
  37. data/docs/examples/rails-application.md +159 -160
  38. data/docs/examples/tool-usage.md +295 -204
  39. data/docs/getting-started/configuration.md +347 -154
  40. data/docs/getting-started/index.md +1 -1
  41. data/docs/getting-started/installation.md +22 -13
  42. data/docs/getting-started/quick-start.md +166 -121
  43. data/docs/guides/building-robots.md +418 -212
  44. data/docs/guides/creating-networks.md +143 -24
  45. data/docs/guides/index.md +0 -5
  46. data/docs/guides/mcp-integration.md +152 -113
  47. data/docs/guides/memory.md +220 -164
  48. data/docs/guides/rails-integration.md +244 -162
  49. data/docs/guides/streaming.md +137 -187
  50. data/docs/guides/using-tools.md +259 -212
  51. data/docs/index.md +46 -41
  52. data/examples/01_simple_robot.rb +6 -9
  53. data/examples/02_tools.rb +6 -9
  54. data/examples/03_network.rb +19 -17
  55. data/examples/04_mcp.rb +5 -8
  56. data/examples/05_streaming.rb +5 -8
  57. data/examples/06_prompt_templates.rb +42 -37
  58. data/examples/07_network_memory.rb +13 -14
  59. data/examples/08_llm_config.rb +169 -0
  60. data/examples/09_chaining.rb +262 -0
  61. data/examples/10_memory.rb +331 -0
  62. data/examples/11_network_introspection.rb +253 -0
  63. data/examples/12_message_bus.rb +74 -0
  64. data/examples/13_spawn.rb +90 -0
  65. data/examples/14_rusty_circuit/comic.rb +143 -0
  66. data/examples/14_rusty_circuit/display.rb +203 -0
  67. data/examples/14_rusty_circuit/heckler.rb +63 -0
  68. data/examples/14_rusty_circuit/open_mic.rb +123 -0
  69. data/examples/14_rusty_circuit/prompts/open_mic_comic.md +20 -0
  70. data/examples/14_rusty_circuit/prompts/open_mic_heckler.md +23 -0
  71. data/examples/14_rusty_circuit/prompts/open_mic_scout.md +20 -0
  72. data/examples/14_rusty_circuit/scout.rb +156 -0
  73. data/examples/14_rusty_circuit/scout_notes.md +89 -0
  74. data/examples/14_rusty_circuit/show.log +234 -0
  75. data/examples/15_memory_network_and_bus/editor_in_chief.rb +24 -0
  76. data/examples/15_memory_network_and_bus/editorial_pipeline.rb +206 -0
  77. data/examples/15_memory_network_and_bus/linux_writer.rb +80 -0
  78. data/examples/15_memory_network_and_bus/os_editor.rb +46 -0
  79. data/examples/15_memory_network_and_bus/os_writer.rb +46 -0
  80. data/examples/15_memory_network_and_bus/output/combined_article.md +13 -0
  81. data/examples/15_memory_network_and_bus/output/final_article.md +15 -0
  82. data/examples/15_memory_network_and_bus/output/linux_draft.md +5 -0
  83. data/examples/15_memory_network_and_bus/output/mac_draft.md +7 -0
  84. data/examples/15_memory_network_and_bus/output/memory.json +13 -0
  85. data/examples/15_memory_network_and_bus/output/revision_1.md +19 -0
  86. data/examples/15_memory_network_and_bus/output/revision_2.md +15 -0
  87. data/examples/15_memory_network_and_bus/output/windows_draft.md +7 -0
  88. data/examples/15_memory_network_and_bus/prompts/os_advocate.md +13 -0
  89. data/examples/15_memory_network_and_bus/prompts/os_chief.md +13 -0
  90. data/examples/15_memory_network_and_bus/prompts/os_editor.md +13 -0
  91. data/examples/16_writers_room/display.rb +158 -0
  92. data/examples/16_writers_room/output/.gitignore +2 -0
  93. data/examples/16_writers_room/output/opus_001.md +263 -0
  94. data/examples/16_writers_room/output/opus_001_notes.log +470 -0
  95. data/examples/16_writers_room/prompts/writer.md +37 -0
  96. data/examples/16_writers_room/room.rb +150 -0
  97. data/examples/16_writers_room/tools.rb +162 -0
  98. data/examples/16_writers_room/writer.rb +121 -0
  99. data/examples/16_writers_room/writers_room.rb +162 -0
  100. data/examples/README.md +197 -0
  101. data/examples/prompts/{assistant/system.txt.erb → assistant.md} +3 -0
  102. data/examples/prompts/{billing/system.txt.erb → billing.md} +3 -0
  103. data/examples/prompts/{classifier/system.txt.erb → classifier.md} +3 -0
  104. data/examples/prompts/comedian.md +6 -0
  105. data/examples/prompts/comedy_critic.md +10 -0
  106. data/examples/prompts/configurable.md +9 -0
  107. data/examples/prompts/dispatcher.md +12 -0
  108. data/examples/prompts/{entity_extractor/system.txt.erb → entity_extractor.md} +3 -0
  109. data/examples/prompts/{escalation/system.txt.erb → escalation.md} +7 -0
  110. data/examples/prompts/frontmatter_mcp_test.md +9 -0
  111. data/examples/prompts/frontmatter_named_test.md +5 -0
  112. data/examples/prompts/frontmatter_tools_test.md +6 -0
  113. data/examples/prompts/{general/system.txt.erb → general.md} +3 -0
  114. data/examples/prompts/{github_assistant/system.txt.erb → github_assistant.md} +8 -0
  115. data/examples/prompts/{helper/system.txt.erb → helper.md} +3 -0
  116. data/examples/prompts/{keyword_extractor/system.txt.erb → keyword_extractor.md} +3 -0
  117. data/examples/prompts/llm_config_demo.md +20 -0
  118. data/examples/prompts/{order_support/system.txt.erb → order_support.md} +8 -0
  119. data/examples/prompts/os_advocate.md +13 -0
  120. data/examples/prompts/os_chief.md +13 -0
  121. data/examples/prompts/os_editor.md +13 -0
  122. data/examples/prompts/{product_support/system.txt.erb → product_support.md} +7 -0
  123. data/examples/prompts/{sentiment_analyzer/system.txt.erb → sentiment_analyzer.md} +3 -0
  124. data/examples/prompts/{synthesizer/system.txt.erb → synthesizer.md} +3 -0
  125. data/examples/prompts/{technical/system.txt.erb → technical.md} +3 -0
  126. data/examples/prompts/{triage/system.txt.erb → triage.md} +6 -0
  127. data/lib/generators/robot_lab/templates/initializer.rb.tt +0 -13
  128. data/lib/robot_lab/ask_user.rb +75 -0
  129. data/lib/robot_lab/config/defaults.yml +121 -0
  130. data/lib/robot_lab/config.rb +183 -0
  131. data/lib/robot_lab/error.rb +6 -0
  132. data/lib/robot_lab/mcp/client.rb +1 -1
  133. data/lib/robot_lab/memory.rb +10 -34
  134. data/lib/robot_lab/network.rb +13 -20
  135. data/lib/robot_lab/robot/bus_messaging.rb +239 -0
  136. data/lib/robot_lab/robot/mcp_management.rb +88 -0
  137. data/lib/robot_lab/robot/template_rendering.rb +130 -0
  138. data/lib/robot_lab/robot.rb +240 -330
  139. data/lib/robot_lab/robot_message.rb +44 -0
  140. data/lib/robot_lab/robot_result.rb +1 -0
  141. data/lib/robot_lab/run_config.rb +184 -0
  142. data/lib/robot_lab/state_proxy.rb +2 -12
  143. data/lib/robot_lab/streaming/context.rb +1 -1
  144. data/lib/robot_lab/task.rb +8 -1
  145. data/lib/robot_lab/tool.rb +108 -172
  146. data/lib/robot_lab/tool_config.rb +1 -1
  147. data/lib/robot_lab/tool_manifest.rb +2 -18
  148. data/lib/robot_lab/utils.rb +39 -0
  149. data/lib/robot_lab/version.rb +1 -1
  150. data/lib/robot_lab.rb +89 -57
  151. data/mkdocs.yml +0 -11
  152. metadata +121 -135
  153. data/docs/api/adapters/anthropic.md +0 -121
  154. data/docs/api/adapters/gemini.md +0 -133
  155. data/docs/api/adapters/index.md +0 -104
  156. data/docs/api/adapters/openai.md +0 -134
  157. data/docs/api/history/active-record-adapter.md +0 -195
  158. data/docs/api/history/config.md +0 -191
  159. data/docs/api/history/index.md +0 -132
  160. data/docs/api/history/thread-manager.md +0 -144
  161. data/docs/guides/history.md +0 -359
  162. data/examples/prompts/assistant/user.txt.erb +0 -1
  163. data/examples/prompts/billing/user.txt.erb +0 -1
  164. data/examples/prompts/classifier/user.txt.erb +0 -1
  165. data/examples/prompts/entity_extractor/user.txt.erb +0 -3
  166. data/examples/prompts/escalation/user.txt.erb +0 -34
  167. data/examples/prompts/general/user.txt.erb +0 -1
  168. data/examples/prompts/github_assistant/user.txt.erb +0 -1
  169. data/examples/prompts/helper/user.txt.erb +0 -1
  170. data/examples/prompts/keyword_extractor/user.txt.erb +0 -3
  171. data/examples/prompts/order_support/user.txt.erb +0 -22
  172. data/examples/prompts/product_support/user.txt.erb +0 -32
  173. data/examples/prompts/sentiment_analyzer/user.txt.erb +0 -3
  174. data/examples/prompts/synthesizer/user.txt.erb +0 -15
  175. data/examples/prompts/technical/user.txt.erb +0 -1
  176. data/examples/prompts/triage/user.txt.erb +0 -17
  177. data/lib/robot_lab/adapters/anthropic.rb +0 -163
  178. data/lib/robot_lab/adapters/base.rb +0 -85
  179. data/lib/robot_lab/adapters/gemini.rb +0 -193
  180. data/lib/robot_lab/adapters/openai.rb +0 -159
  181. data/lib/robot_lab/adapters/registry.rb +0 -81
  182. data/lib/robot_lab/configuration.rb +0 -143
  183. data/lib/robot_lab/errors.rb +0 -70
  184. data/lib/robot_lab/history/active_record_adapter.rb +0 -146
  185. data/lib/robot_lab/history/config.rb +0 -115
  186. data/lib/robot_lab/history/thread_manager.rb +0 -93
  187. data/lib/robot_lab/robotic_model.rb +0 -324
@@ -0,0 +1,206 @@
1
+ #!/usr/bin/env ruby
2
+ # frozen_string_literal: true
3
+
4
+ # Example 15: OS Research Editorial Pipeline — Network + Memory + Bus + Spawn
5
+ #
6
+ # Three writers advocate for different operating systems (macOS, Windows,
7
+ # Linux/BSD) for home AI research labs. The Linux writer spawns distro
8
+ # specialists. An editor synthesizes. An editor-in-chief gives final approval.
9
+ #
10
+ # This showcases all three coordination mechanisms working together:
11
+ #
12
+ # NETWORK (parallel pipeline + shared memory)
13
+ # ┌──────────────────────────────────────────────────────┐
14
+ # │ mac_writer ──┐ │
15
+ # │ win_writer ──┼── editor ──→ combined article │
16
+ # │ linux_writer ──┘ │
17
+ # │ └── spawns distro specialists via spawn() │
18
+ # │ │
19
+ # │ MEMORY carries drafts between stages │
20
+ # │ :mac_draft, :windows_draft, :linux_draft │
21
+ # └──────────────────────────────────────────────────────┘
22
+ # │
23
+ # BUS (review loop)
24
+ # │
25
+ # ┌─────┴──────┐
26
+ # │ chief │
27
+ # └────────────┘
28
+ #
29
+ # - NETWORK orchestrates 3 parallel writers → editor synthesis
30
+ # - MEMORY passes advocacy drafts between pipeline stages
31
+ # - BUS enables editor ↔ chief revision loop after pipeline
32
+ # - SPAWN creates distro specialists dynamically within pipeline
33
+ #
34
+ # Usage:
35
+ # bundle exec ruby examples/15_memory_network_and_bus/editorial_pipeline.rb
36
+
37
+ ENV["ROBOT_LAB_TEMPLATE_PATH"] ||= File.join(__dir__, "prompts")
38
+
39
+ require_relative "../../lib/robot_lab"
40
+ require "fileutils"
41
+
42
+ RubyLLM.configure { |c| c.logger = Logger.new(File::NULL) }
43
+
44
+ MAX_REVISIONS = 3
45
+ OUTPUT_DIR = File.join(__dir__, "output")
46
+
47
+ FileUtils.mkdir_p(OUTPUT_DIR)
48
+
49
+ # ── Load robot classes ────────────────────────────────────
50
+
51
+ require_relative "os_writer"
52
+ require_relative "linux_writer"
53
+ require_relative "os_editor"
54
+ require_relative "editor_in_chief"
55
+
56
+ # ── Build Everything ──────────────────────────────────────
57
+
58
+ bus = TypedBus::MessageBus.new
59
+
60
+ mac_writer = OsWriter.new(
61
+ name: "mac_writer",
62
+ template: :os_advocate,
63
+ local_tools: [RobotLab::AskUser],
64
+ context: {
65
+ os_name: "macOS",
66
+ strengths: "Apple Silicon (M-series) performance, Metal GPU framework, Unix foundation, CoreML integration, energy efficiency"
67
+ },
68
+ memory_key: :mac_draft
69
+ )
70
+
71
+ win_writer = OsWriter.new(
72
+ name: "win_writer",
73
+ template: :os_advocate,
74
+ local_tools: [RobotLab::AskUser],
75
+ context: {
76
+ os_name: "Windows",
77
+ strengths: "NVIDIA CUDA first-class support, WSL2 Linux compatibility, DirectML, widest hardware selection, enterprise tool integration"
78
+ },
79
+ memory_key: :windows_draft
80
+ )
81
+
82
+ linux_writer = LinuxWriter.new(
83
+ name: "linux_writer",
84
+ template: :os_advocate,
85
+ local_tools: [RobotLab::AskUser],
86
+ context: {
87
+ os_name: "Linux/BSD",
88
+ strengths: "Full GPU stack control, Docker-native, free and open source, server parity, massive community packages"
89
+ },
90
+ memory_key: :linux_draft,
91
+ bus: bus
92
+ )
93
+
94
+ editor = OsEditor.new(
95
+ name: "editor",
96
+ template: :os_editor,
97
+ bus: bus
98
+ )
99
+
100
+ # Editor handles revision requests from the chief via bus
101
+ revision_count = 0
102
+ editor.on_message do |message|
103
+ revised = editor.run(message.content).reply.strip
104
+ editor.instance_variable_set(:@article, revised)
105
+
106
+ revision_count += 1
107
+ path = File.join(OUTPUT_DIR, "revision_#{revision_count}.md")
108
+ File.write(path, "# Revision #{revision_count}\n\n#{revised}\n")
109
+ puts " Editor [revised]: #{revised[0..120]}..."
110
+ puts " [editor] Revision written to #{path}"
111
+
112
+ editor.send_reply(to: message.from.to_sym, content: revised, in_reply_to: message.key)
113
+ end
114
+
115
+ chief = EditorInChief.new(
116
+ name: "chief",
117
+ template: :os_chief,
118
+ bus: bus
119
+ )
120
+
121
+ # Network orchestrates the writing pipeline
122
+ network = RobotLab.create_network(name: "os_editorial") do
123
+ task :mac_writer, mac_writer, depends_on: :none
124
+ task :win_writer, win_writer, depends_on: :none
125
+ task :linux_writer, linux_writer, depends_on: :none
126
+ task :editor, editor, depends_on: [:mac_writer, :win_writer, :linux_writer]
127
+ end
128
+
129
+ # Give each pipeline robot a direct reference to shared memory.
130
+ # extract_run_context's delete() pattern mutates the shared run_params
131
+ # hash, so parallel steps lose network_memory after the first one runs.
132
+ shared_memory = network.memory
133
+ [mac_writer, win_writer, linux_writer, editor].each do |robot|
134
+ robot.shared_memory = shared_memory
135
+ end
136
+
137
+ # Monitor shared memory changes during the pipeline
138
+ network.memory.subscribe(
139
+ :mac_draft, :windows_draft, :linux_draft,
140
+ :ubuntu_specialist, :fedora_specialist, :freebsd_specialist
141
+ ) do |change|
142
+ puts " [memory] :#{change.key} updated by #{change.writer}"
143
+ end
144
+
145
+ # ── Run ──────────────────────────────────────────────────────
146
+
147
+ puts "=" * 60
148
+ puts "Example 15: OS Research Editorial Pipeline"
149
+ puts " Network + Memory + Bus + Spawn"
150
+ puts "=" * 60
151
+ puts
152
+ puts network.visualize
153
+ puts
154
+
155
+ # ── Phase 1: Writing Pipeline (Network + Memory + Spawn) ──
156
+
157
+ puts "Phase 1: Writing Pipeline (Network + Memory + Spawn)"
158
+ puts "-" * 40
159
+
160
+ # Gather the research focus from the user via AskUser
161
+ ask = RobotLab::AskUser.new
162
+ focus = ask.call(
163
+ "question" => "What AI research focus areas for the home lab article?",
164
+ "default" => "LLM fine-tuning, image generation, and local inference"
165
+ )
166
+
167
+ topic = "Write about your operating system's advantages for building a home AI research lab focused on #{focus}."
168
+
169
+ result = network.run(message: topic)
170
+ article = editor.article
171
+
172
+ puts
173
+ puts " Article excerpt: #{article[0..200]}..." if article
174
+ puts
175
+ puts " Memory keys: #{network.memory.keys.join(', ')}"
176
+ puts " Specialists spawned: #{linux_writer.specialists.size}"
177
+
178
+ # ── Phase 2: Editorial Review (Bus) ──────────────────────
179
+
180
+ puts
181
+ puts "Phase 2: Editorial Review (Bus)"
182
+ puts "-" * 40
183
+
184
+ # Chief reviews the article via bus — may trigger revision loop
185
+ chief.send_message(to: :editor, content: article)
186
+
187
+ final_article = editor.article
188
+ final_path = File.join(OUTPUT_DIR, "final_article.md")
189
+ status = chief.accepted ? "APPROVED" : "NOT APPROVED (max revisions reached)"
190
+ File.write(final_path, "# Final Article — #{status}\n\n#{final_article}\n")
191
+
192
+ puts
193
+ puts "-" * 60
194
+ puts "Revisions: #{chief.rounds} | Accepted: #{chief.accepted}"
195
+ puts "Specialists spawned: #{linux_writer.specialists.size}"
196
+ puts "Output directory: #{OUTPUT_DIR}"
197
+ puts "=" * 60
198
+
199
+ puts
200
+
201
+ require "json"
202
+
203
+ memory_path = File.join(OUTPUT_DIR, "memory.json")
204
+ File.write(memory_path, JSON.pretty_generate(shared_memory.to_h))
205
+ puts
206
+ puts "Memory written to #{memory_path}"
@@ -0,0 +1,80 @@
1
+ # frozen_string_literal: true
2
+
3
+ # Linux writer spawns distro specialists before writing its draft.
4
+ # Demonstrates the spawn() pattern for dynamic robot creation.
5
+ class LinuxWriter < OsWriter
6
+ attr_reader :specialists
7
+
8
+ def initialize(**opts)
9
+ super(**opts)
10
+ @specialists = []
11
+ end
12
+
13
+ def call(result)
14
+ message = extract_message(result)
15
+
16
+ # Spawn distro specialists and collect their analyses
17
+ distro_analyses = spawn_distro_specialists(message)
18
+
19
+ # Build an enriched prompt with specialist input
20
+ enriched = <<~PROMPT
21
+ #{message}
22
+
23
+ Your team of distro specialists has provided the following analyses.
24
+ Incorporate their insights into your advocacy piece:
25
+
26
+ #{distro_analyses}
27
+ PROMPT
28
+
29
+ robot_result = run(enriched, network_memory: @shared_memory)
30
+
31
+ if @shared_memory
32
+ draft = robot_result.reply.to_s
33
+ @shared_memory.current_writer = @name
34
+ @shared_memory.set(@memory_key, draft)
35
+
36
+ path = File.join(OUTPUT_DIR, "#{@memory_key}.md")
37
+ File.write(path, "# #{@name} Draft\n\n#{draft}\n")
38
+ puts " [#{@name}] Draft written to memory[:#{@memory_key}] and #{path} (with #{@specialists.size} specialist inputs)"
39
+ end
40
+
41
+ result.with_context(@name.to_sym, robot_result).continue(robot_result)
42
+ end
43
+
44
+ private
45
+
46
+ def spawn_distro_specialists(topic)
47
+ distros = [
48
+ { name: "ubuntu_specialist", label: "Ubuntu/Debian",
49
+ prompt: "You are a Ubuntu/Debian specialist for AI research. Focus on apt ecosystem, CUDA support, and wide hardware compatibility." },
50
+ { name: "fedora_specialist", label: "Fedora/RHEL",
51
+ prompt: "You are a Fedora/RHEL specialist for AI research. Focus on cutting-edge kernels, SELinux security, and enterprise tooling." },
52
+ { name: "freebsd_specialist", label: "FreeBSD",
53
+ prompt: "You are a FreeBSD specialist for AI research. Focus on ZFS, jails, bhyve virtualization, and stability for long-running experiments." }
54
+ ]
55
+
56
+ analyses = []
57
+
58
+ distros.each do |distro|
59
+ puts " [#{@name}] Spawning #{distro[:label]} specialist..."
60
+ specialist = spawn(name: distro[:name], system_prompt: distro[:prompt])
61
+ @specialists << specialist
62
+
63
+ analysis = specialist.run(
64
+ "Briefly describe why #{distro[:label]} is a strong choice for a home AI research lab. 2-3 sentences."
65
+ ).reply.strip
66
+
67
+ puts " [#{distro[:name]}] #{analysis[0..80]}..."
68
+ analyses << "### #{distro[:label]}\n#{analysis}"
69
+
70
+ # Write each specialist's analysis to shared memory
71
+ if @shared_memory
72
+ memory_key = distro[:name].to_sym
73
+ @shared_memory.current_writer = distro[:name]
74
+ @shared_memory.set(memory_key, analysis)
75
+ end
76
+ end
77
+
78
+ analyses.join("\n\n")
79
+ end
80
+ end
@@ -0,0 +1,46 @@
1
+ # frozen_string_literal: true
2
+
3
+ # Reads all three drafts from memory, synthesizes a combined article.
4
+ # Also handles revision requests from the chief via bus.
5
+ #
6
+ # Like OsWriter, uses a direct shared_memory reference to avoid the
7
+ # extract_run_context mutation issue with parallel pipeline steps.
8
+ class OsEditor < RobotLab::Robot
9
+ attr_accessor :shared_memory
10
+ attr_reader :article
11
+
12
+ def initialize(**opts)
13
+ super(**opts)
14
+ @article = nil
15
+ end
16
+
17
+ def call(result)
18
+ # Read all three drafts from shared memory
19
+ mac_draft = @shared_memory&.get(:mac_draft) || "No draft available."
20
+ windows_draft = @shared_memory&.get(:windows_draft) || "No draft available."
21
+ linux_draft = @shared_memory&.get(:linux_draft) || "No draft available."
22
+
23
+ composite_prompt = <<~PROMPT
24
+ Here are three advocacy drafts for different operating systems for home AI research labs.
25
+ Synthesize them into a balanced article.
26
+
27
+ ## macOS Advocacy
28
+ #{mac_draft}
29
+
30
+ ## Windows Advocacy
31
+ #{windows_draft}
32
+
33
+ ## Linux/BSD Advocacy
34
+ #{linux_draft}
35
+ PROMPT
36
+
37
+ robot_result = run(composite_prompt, network_memory: @shared_memory)
38
+ @article = robot_result.reply.to_s
39
+
40
+ path = File.join(OUTPUT_DIR, "combined_article.md")
41
+ File.write(path, "# Combined Article (Editor Draft)\n\n#{@article}\n")
42
+ puts " [#{@name}] Combined article written to #{path}"
43
+
44
+ result.with_context(@name.to_sym, robot_result).continue(robot_result)
45
+ end
46
+ end
@@ -0,0 +1,46 @@
1
+ # frozen_string_literal: true
2
+
3
+ # Base writer that runs LLM and stores its draft in shared memory.
4
+ # Used by mac_writer and win_writer directly; LinuxWriter extends this.
5
+ #
6
+ # NOTE: We bypass extract_run_context for network_memory access because
7
+ # its delete() pattern mutates the shared run_params hash — in parallel
8
+ # pipeline steps, only the first step to run would get the memory object.
9
+ # Instead, each robot holds a direct reference via shared_memory=.
10
+ class OsWriter < RobotLab::Robot
11
+ attr_accessor :shared_memory
12
+
13
+ def initialize(memory_key:, **opts)
14
+ super(**opts)
15
+ @memory_key = memory_key
16
+ end
17
+
18
+ def call(result)
19
+ message = extract_message(result)
20
+
21
+ robot_result = run(message, network_memory: @shared_memory)
22
+
23
+ if @shared_memory
24
+ draft = robot_result.reply.to_s
25
+ @shared_memory.current_writer = @name
26
+ @shared_memory.set(@memory_key, draft)
27
+
28
+ path = File.join(OUTPUT_DIR, "#{@memory_key}.md")
29
+ File.write(path, "# #{@name} Draft\n\n#{draft}\n")
30
+ puts " [#{@name}] Draft written to memory[:#{@memory_key}] and #{path}"
31
+ end
32
+
33
+ result.with_context(@name.to_sym, robot_result).continue(robot_result)
34
+ end
35
+
36
+ private
37
+
38
+ def extract_message(result)
39
+ case result.value
40
+ when Hash then result.value[:message]
41
+ when RobotLab::RobotResult then result.value.reply
42
+ when String then result.value
43
+ else result.value.to_s
44
+ end
45
+ end
46
+ end
@@ -0,0 +1,13 @@
1
+ # Combined Article (Editor Draft)
2
+
3
+ # Choosing the Right Operating System for Your Home AI Research Lab
4
+
5
+ Building a home AI research lab requires careful consideration of your operating system, as this foundational choice will impact everything from GPU acceleration to software compatibility. Each major platform—macOS, Windows, and Linux/BSD—brings distinct advantages that appeal to different research priorities and workflows.
6
+
7
+ **macOS excels in energy efficiency and unified architecture benefits**, particularly for researchers using Apple Silicon machines. The M-series chips' unified memory architecture eliminates traditional CPU-GPU bottlenecks, making them surprisingly effective for large language model work within memory constraints. Apple's MLX framework and Metal Performance Shaders provide optimized acceleration paths, while the Unix foundation ensures compatibility with the Python scientific stack. However, this platform's strength is primarily limited to Apple hardware, and CUDA support remains unavailable for NVIDIA-dependent workflows.
8
+
9
+ **Windows offers the broadest hardware compatibility and vendor support**, making it the go-to choice for researchers prioritizing maximum GPU options and plug-and-play simplicity. First-class NVIDIA CUDA support, DirectML for multi-vendor GPU acceleration, and WSL2 for Linux compatibility create a comprehensive environment. The platform particularly shines for users wanting access to consumer-friendly tools like AUTOMATIC1111's Stable Diffusion interfaces or LM Studio, backed by extensive community documentation. The trade-off comes in system overhead and potential stability concerns during intensive, long-running training jobs.
10
+
11
+ **Linux and BSD systems provide unmatched control and stability** for serious computational work. These platforms offer the most direct access to GPU drivers, the latest kernel optimizations, and mature containerization through Docker and Podman. FreeBSD's ZFS filesystem adds enterprise-grade data integrity, while Linux distributions like Ubuntu provide comprehensive package management for AI frameworks. The open-source nature ensures transparency and customizability, though it demands more technical expertise for optimal configuration.
12
+
13
+ **The optimal choice depends on your specific research profile**: Choose macOS if you're already invested in Apple hardware and prioritize energy efficiency for smaller-scale experiments. Select Windows if you want maximum hardware flexibility with minimal configuration overhead, especially for image generation and consumer-oriented AI tools. Opt for Linux/BSD if you're running large-scale training jobs requiring maximum stability and performance, or if you need the flexibility of custom configurations and bleeding-edge framework support. For most researchers, the decision ultimately comes down to balancing technical expertise against time-to-productivity—Windows for quick starts, Linux for maximum control, and macOS for Apple ecosystem integration.
@@ -0,0 +1,15 @@
1
+ # Final Article — APPROVED
2
+
3
+ # Choosing the Right Operating System for Your Home AI Research Lab
4
+
5
+ Building a home AI research lab requires careful consideration of your operating system, as this foundational choice will impact everything from GPU acceleration to software compatibility. Each major platform—macOS, Windows, and Linux/BSD—brings distinct advantages that appeal to different research priorities and workflows.
6
+
7
+ **macOS excels in energy efficiency and unified architecture benefits**, particularly for researchers using Apple Silicon machines. The M-series chips' unified memory architecture eliminates traditional CPU-GPU bottlenecks, making them surprisingly effective for large language model work within memory constraints. Apple's MLX framework and Metal Performance Shaders provide optimized acceleration paths, while the Unix foundation ensures compatibility with the Python scientific stack. Tools like Hugging Face Transformers run seamlessly with MPS backend support, and applications like DiffusionBee leverage Metal for Stable Diffusion workflows. The platform's energy efficiency allows intensive training sessions without thermal throttling issues common in high-end PC builds. However, this strength is limited to Apple hardware, CUDA support remains unavailable for NVIDIA-dependent workflows, and the premium hardware costs can be prohibitive for budget-conscious researchers.
8
+
9
+ **Windows offers the broadest hardware compatibility and vendor support**, making it the ideal choice for researchers prioritizing maximum GPU options and plug-and-play simplicity. First-class NVIDIA CUDA support provides seamless access to CUDA 12.x, cuDNN, and TensorRT—essential for PyTorch, TensorFlow, and JAX frameworks powering modern models. DirectML enables hardware-agnostic ML acceleration across AMD, Intel, and NVIDIA GPUs, while WSL2 provides Linux compatibility without sacrificing Windows' superior hardware support. The platform excels with consumer-friendly tools like AUTOMATIC1111's Stable Diffusion interfaces, LM Studio for local LLM serving, and ComfyUI workflows, all backed by extensive community documentation. Windows licensing costs add to overall expenses, and the system overhead can impact stability during long-running training jobs, but the ease of setup makes it attractive for researchers who want to focus on experiments rather than system administration.
10
+
11
+ **Linux and BSD systems provide unmatched control and stability** for serious computational work. These platforms offer direct access to GPU drivers, the latest kernel optimizations, and mature containerization through Docker and Podman. Ubuntu and Debian provide comprehensive package repositories with one-command installations of PyTorch, TensorFlow, and CUDA toolkits, while Fedora delivers cutting-edge kernel support for new GPU architectures. FreeBSD's ZFS filesystem adds enterprise-grade data integrity with automatic checksums and snapshots—critical for protecting valuable datasets and model checkpoints. The open-source nature ensures transparency and customizability, with server-grade stability that prevents crashes during extended training sessions. The trade-off is a steeper learning curve requiring technical expertise for optimal configuration, though the performance benefits and zero licensing costs often justify the investment for serious researchers.
12
+
13
+ **Cost considerations significantly impact platform selection**. Linux systems offer the best value proposition with no licensing fees and compatibility with budget hardware, while macOS requires premium Apple hardware that can cost 2-3x equivalent PC specifications. Windows falls in the middle with moderate licensing costs but maximum hardware flexibility, allowing researchers to optimize price-performance ratios across different GPU options.
14
+
15
+ **The optimal choice depends on your specific research profile and technical comfort level**: Choose macOS if you're already invested in Apple hardware, prioritize energy efficiency for smaller-scale experiments, and value the seamless integration of Unix-based tools with premium hardware. Select Windows if you want maximum hardware flexibility with minimal configuration overhead, especially for image generation workflows and consumer-oriented AI tools, and prefer extensive community support for troubleshooting. Opt for Linux/BSD if you're running large-scale training jobs requiring maximum stability and performance, need custom system configurations, or want to minimize costs while maximizing control. For most researchers, the decision balances technical expertise against time-to-productivity—Windows for quick starts and broad compatibility, Linux for maximum performance and control, and macOS for energy-efficient workflows within the Apple ecosystem.
@@ -0,0 +1,5 @@
1
+ # linux_writer Draft
2
+
3
+ When building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, Linux and BSD systems stand as the undisputed champions for serious researchers. Unlike proprietary alternatives, these open-source platforms give you complete control over your GPU stack—from low-level CUDA drivers to high-level ML frameworks. Ubuntu and Debian shine with their comprehensive package repositories, offering one-command installations of PyTorch, TensorFlow, Hugging Face Transformers, and CUDA toolkits without dependency hell. For bleeding-edge work, Fedora provides the latest kernel support ensuring day-one compatibility with new GPU architectures like RTX 4090s or H100s, while its SELinux security model protects your valuable training data and model weights. The containerization story is equally compelling: Docker and Podman run natively, allowing you to spin up isolated environments for different experiments—imagine running Stable Diffusion XL in one container while fine-tuning a 7B parameter LLaMA model in another, all without conflicts.
4
+
5
+ The performance and reliability advantages become even more pronounced for serious research workflows. FreeBSD's ZFS filesystem provides bulletproof data integrity with automatic checksums and snapshots—critical when you're storing multi-terabyte datasets and irreplaceable model checkpoints from weeks-long training runs. The system's deterministic behavior ensures reproducible experiments, while jails offer lightweight isolation perfect for testing different versions of frameworks like DeepSpeed or Triton. Linux distributions excel in GPU compute with mature NVIDIA CUDA support, ROCm for AMD cards, and emerging Intel XPU capabilities. The community ecosystem is unmatched: from PyTorch Hub to Hugging Face Model Hub integration, from Jupyter notebooks to MLflow experiment tracking, everything runs optimally on these platforms. Server-grade stability means your 48-hour LoRA fine-tuning jobs won't crash from desktop OS quirks, while the vast package repositories provide everything from ONNX Runtime for optimized inference to Weights & Biases for experiment monitoring—all maintained by thousands of contributors who understand the needs of computational researchers.
@@ -0,0 +1,7 @@
1
+ # mac_writer Draft
2
+
3
+ **macOS: The Ultimate Platform for Home AI Research Labs**
4
+
5
+ When building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, macOS stands as the clear winner, primarily due to Apple Silicon's revolutionary architecture. The M-series chips deliver exceptional performance per watt, with unified memory architectures that eliminate traditional CPU-GPU memory bottlenecks—crucial for handling large language models that demand substantial RAM. For LLM fine-tuning, frameworks like MLX (Apple's native machine learning framework) provide optimized performance that often surpasses CUDA-based solutions on consumer hardware. The Metal Performance Shaders framework offers direct GPU acceleration for PyTorch and TensorFlow operations, while tools like Hugging Face Transformers run seamlessly with MPS backend support. Energy efficiency means you can run intensive training sessions without the thermal throttling and power consumption issues that plague high-end PC builds.
6
+
7
+ The software ecosystem further solidifies macOS's position as the premier AI development platform. CoreML integration allows for seamless deployment of trained models with hardware-optimized inference, while the Unix foundation provides access to the entire Python scientific computing stack—NumPy, SciPy, pandas, and scikit-learn all install effortlessly through Homebrew or conda. For image generation workflows, Stable Diffusion runs exceptionally well through optimized implementations like DiffusionBee and Draw Things, leveraging Metal's compute capabilities. The developer experience is unmatched: Xcode provides excellent debugging tools, Jupyter notebooks integrate perfectly with the system, and Docker Desktop for Mac ensures reproducible environments. The growing community around Apple Silicon ML development, exemplified by projects like whisper.cpp and llama.cpp with Metal acceleration, demonstrates the platform's momentum. Combined with tools like Ollama for local LLM serving and the seamless integration between macOS development tools and popular AI frameworks, macOS offers the most cohesive and powerful environment for serious AI research at home.
@@ -0,0 +1,13 @@
1
+ {
2
+ "data": {},
3
+ "results": [],
4
+ "messages": [],
5
+ "custom": {
6
+ "ubuntu_specialist": "Ubuntu/Debian offers exceptional package management through apt with extensive pre-built libraries for AI frameworks like PyTorch, TensorFlow, and CUDA toolkit, eliminating complex compilation steps. The distributions provide excellent hardware compatibility across diverse GPU vendors (NVIDIA, AMD, Intel) and architectures, while maintaining strong community support with comprehensive documentation for AI-specific configurations. Their LTS releases ensure stable, long-term environments crucial for reproducible research workflows.",
7
+ "fedora_specialist": "Fedora/RHEL excels for AI research due to its cutting-edge kernel support that ensures compatibility with the latest GPU drivers and hardware accelerators, while SELinux provides robust security isolation for sensitive research data and multi-tenant workloads. The enterprise-grade tooling ecosystem, including containers (Podman), orchestration, and package management, offers production-ready infrastructure that scales from development to deployment, making it ideal for researchers who need both bleeding-edge capabilities and rock-solid stability.",
8
+ "mac_draft": "**macOS: The Ultimate Platform for Home AI Research Labs**\n\nWhen building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, macOS stands as the clear winner, primarily due to Apple Silicon's revolutionary architecture. The M-series chips deliver exceptional performance per watt, with unified memory architectures that eliminate traditional CPU-GPU memory bottlenecks—crucial for handling large language models that demand substantial RAM. For LLM fine-tuning, frameworks like MLX (Apple's native machine learning framework) provide optimized performance that often surpasses CUDA-based solutions on consumer hardware. The Metal Performance Shaders framework offers direct GPU acceleration for PyTorch and TensorFlow operations, while tools like Hugging Face Transformers run seamlessly with MPS backend support. Energy efficiency means you can run intensive training sessions without the thermal throttling and power consumption issues that plague high-end PC builds.\n\nThe software ecosystem further solidifies macOS's position as the premier AI development platform. CoreML integration allows for seamless deployment of trained models with hardware-optimized inference, while the Unix foundation provides access to the entire Python scientific computing stack—NumPy, SciPy, pandas, and scikit-learn all install effortlessly through Homebrew or conda. For image generation workflows, Stable Diffusion runs exceptionally well through optimized implementations like DiffusionBee and Draw Things, leveraging Metal's compute capabilities. The developer experience is unmatched: Xcode provides excellent debugging tools, Jupyter notebooks integrate perfectly with the system, and Docker Desktop for Mac ensures reproducible environments. The growing community around Apple Silicon ML development, exemplified by projects like whisper.cpp and llama.cpp with Metal acceleration, demonstrates the platform's momentum. Combined with tools like Ollama for local LLM serving and the seamless integration between macOS development tools and popular AI frameworks, macOS offers the most cohesive and powerful environment for serious AI research at home.",
9
+ "freebsd_specialist": "FreeBSD excels for AI research labs due to its rock-solid stability and predictable performance, ensuring long-running training jobs won't be interrupted by system instability. ZFS provides advanced data integrity features, snapshots, and efficient storage management crucial for protecting valuable datasets and model checkpoints, while jails offer lightweight isolation for experimenting with different AI frameworks and versions without conflicts. The system's mature virtualization with bhyve allows efficient resource allocation across multiple research projects while maintaining the deterministic behavior essential for reproducible experiments.",
10
+ "windows_draft": "**Windows: The Ultimate Platform for Your Home AI Research Lab**\n\nWhen building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, Windows stands as the unequivocally superior choice. The platform's **first-class NVIDIA CUDA support** provides seamless access to the full GPU acceleration stack that modern AI workloads demand. Unlike other operating systems that often require complex driver configurations or suffer from compatibility issues, Windows delivers out-of-the-box support for CUDA 12.x, cuDNN, and TensorRT—essential for frameworks like PyTorch, TensorFlow, and JAX that power cutting-edge models like Llama 2, Stable Diffusion XL, and Mistral. Microsoft's **DirectML** further enhances this ecosystem by enabling hardware-agnostic ML acceleration across AMD, Intel, and NVIDIA GPUs, giving you unparalleled flexibility in hardware selection. With **WSL2**, you get native Linux compatibility without sacrificing Windows' superior hardware support, allowing you to run containerized models via Docker or Podman while maintaining access to Windows-exclusive tools.\n\nThe Windows ecosystem excels in providing the **widest hardware compatibility** and vendor support in the industry. Whether you're deploying multiple RTX 4090s for distributed training, experimenting with Intel Arc GPUs for cost-effective inference, or scaling up to workstation-class Quadro cards, Windows ensures optimal driver support and performance tuning. The platform's enterprise-grade tooling integration shines for serious researchers: **Visual Studio Code** with GPU debugging extensions, **Weights & Biases** desktop integration, **Anaconda** with native Windows conda-forge packages, and seamless **Git LFS** support for managing large model checkpoints. Popular frameworks like **Hugging Face Transformers**, **ComfyUI** for Stable Diffusion workflows, and **text-generation-webui** for local LLM serving all provide superior Windows support with pre-compiled binaries and automated installers. The vibrant Windows AI community, centered around platforms like the AUTOMATIC1111 ecosystem and LM Studio, offers extensive documentation, troubleshooting resources, and model optimization guides specifically tailored to Windows environments—making your research journey both productive and well-supported.",
11
+ "linux_draft": "When building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, Linux and BSD systems stand as the undisputed champions for serious researchers. Unlike proprietary alternatives, these open-source platforms give you complete control over your GPU stack—from low-level CUDA drivers to high-level ML frameworks. Ubuntu and Debian shine with their comprehensive package repositories, offering one-command installations of PyTorch, TensorFlow, Hugging Face Transformers, and CUDA toolkits without dependency hell. For bleeding-edge work, Fedora provides the latest kernel support ensuring day-one compatibility with new GPU architectures like RTX 4090s or H100s, while its SELinux security model protects your valuable training data and model weights. The containerization story is equally compelling: Docker and Podman run natively, allowing you to spin up isolated environments for different experiments—imagine running Stable Diffusion XL in one container while fine-tuning a 7B parameter LLaMA model in another, all without conflicts.\n\nThe performance and reliability advantages become even more pronounced for serious research workflows. FreeBSD's ZFS filesystem provides bulletproof data integrity with automatic checksums and snapshots—critical when you're storing multi-terabyte datasets and irreplaceable model checkpoints from weeks-long training runs. The system's deterministic behavior ensures reproducible experiments, while jails offer lightweight isolation perfect for testing different versions of frameworks like DeepSpeed or Triton. Linux distributions excel in GPU compute with mature NVIDIA CUDA support, ROCm for AMD cards, and emerging Intel XPU capabilities. The community ecosystem is unmatched: from PyTorch Hub to Hugging Face Model Hub integration, from Jupyter notebooks to MLflow experiment tracking, everything runs optimally on these platforms. Server-grade stability means your 48-hour LoRA fine-tuning jobs won't crash from desktop OS quirks, while the vast package repositories provide everything from ONNX Runtime for optimized inference to Weights & Biases for experiment monitoring—all maintained by thousands of contributors who understand the needs of computational researchers."
12
+ }
13
+ }
@@ -0,0 +1,19 @@
1
+ # Revision 1
2
+
3
+ This is an excellent, well-balanced synthesis of the three advocacy pieces. You've successfully transformed partisan arguments into an objective analysis that fairly represents each platform's strengths while acknowledging their limitations.
4
+
5
+ **Strengths of your synthesis:**
6
+
7
+ - **Fair representation**: You extracted the core technical arguments from each advocacy piece without the hyperbolic language
8
+ - **Clear structure**: Each platform gets dedicated coverage with consistent evaluation criteria (performance, compatibility, ease of use)
9
+ - **Practical guidance**: The final paragraph provides actionable decision-making criteria based on different user profiles
10
+ - **Technical accuracy**: You correctly highlighted key differentiators like Apple Silicon's unified memory, Windows' CUDA support, and Linux's containerization advantages
11
+
12
+ **Minor suggestions for enhancement:**
13
+
14
+ - Consider adding a brief mention of **cost considerations** (macOS hardware premium, Windows licensing, Linux being free)
15
+ - The **learning curve** aspect could be slightly more explicit—Linux requiring the most technical expertise, Windows being most accessible, macOS in the middle
16
+
17
+ **Editorial tone assessment**: You've struck exactly the right professional, measured tone for a technology publication. The piece reads as genuinely helpful guidance rather than advocacy, which is precisely what readers need when making infrastructure decisions.
18
+
19
+ This synthesis effectively serves readers who need to make informed decisions about their AI research environment without being swayed by platform evangelism.
@@ -0,0 +1,15 @@
1
+ # Revision 2
2
+
3
+ # Choosing the Right Operating System for Your Home AI Research Lab
4
+
5
+ Building a home AI research lab requires careful consideration of your operating system, as this foundational choice will impact everything from GPU acceleration to software compatibility. Each major platform—macOS, Windows, and Linux/BSD—brings distinct advantages that appeal to different research priorities and workflows.
6
+
7
+ **macOS excels in energy efficiency and unified architecture benefits**, particularly for researchers using Apple Silicon machines. The M-series chips' unified memory architecture eliminates traditional CPU-GPU bottlenecks, making them surprisingly effective for large language model work within memory constraints. Apple's MLX framework and Metal Performance Shaders provide optimized acceleration paths, while the Unix foundation ensures compatibility with the Python scientific stack. Tools like Hugging Face Transformers run seamlessly with MPS backend support, and applications like DiffusionBee leverage Metal for Stable Diffusion workflows. The platform's energy efficiency allows intensive training sessions without thermal throttling issues common in high-end PC builds. However, this strength is limited to Apple hardware, CUDA support remains unavailable for NVIDIA-dependent workflows, and the premium hardware costs can be prohibitive for budget-conscious researchers.
8
+
9
+ **Windows offers the broadest hardware compatibility and vendor support**, making it the ideal choice for researchers prioritizing maximum GPU options and plug-and-play simplicity. First-class NVIDIA CUDA support provides seamless access to CUDA 12.x, cuDNN, and TensorRT—essential for PyTorch, TensorFlow, and JAX frameworks powering modern models. DirectML enables hardware-agnostic ML acceleration across AMD, Intel, and NVIDIA GPUs, while WSL2 provides Linux compatibility without sacrificing Windows' superior hardware support. The platform excels with consumer-friendly tools like AUTOMATIC1111's Stable Diffusion interfaces, LM Studio for local LLM serving, and ComfyUI workflows, all backed by extensive community documentation. Windows licensing costs add to overall expenses, and the system overhead can impact stability during long-running training jobs, but the ease of setup makes it attractive for researchers who want to focus on experiments rather than system administration.
10
+
11
+ **Linux and BSD systems provide unmatched control and stability** for serious computational work. These platforms offer direct access to GPU drivers, the latest kernel optimizations, and mature containerization through Docker and Podman. Ubuntu and Debian provide comprehensive package repositories with one-command installations of PyTorch, TensorFlow, and CUDA toolkits, while Fedora delivers cutting-edge kernel support for new GPU architectures. FreeBSD's ZFS filesystem adds enterprise-grade data integrity with automatic checksums and snapshots—critical for protecting valuable datasets and model checkpoints. The open-source nature ensures transparency and customizability, with server-grade stability that prevents crashes during extended training sessions. The trade-off is a steeper learning curve requiring technical expertise for optimal configuration, though the performance benefits and zero licensing costs often justify the investment for serious researchers.
12
+
13
+ **Cost considerations significantly impact platform selection**. Linux systems offer the best value proposition with no licensing fees and compatibility with budget hardware, while macOS requires premium Apple hardware that can cost 2-3x equivalent PC specifications. Windows falls in the middle with moderate licensing costs but maximum hardware flexibility, allowing researchers to optimize price-performance ratios across different GPU options.
14
+
15
+ **The optimal choice depends on your specific research profile and technical comfort level**: Choose macOS if you're already invested in Apple hardware, prioritize energy efficiency for smaller-scale experiments, and value the seamless integration of Unix-based tools with premium hardware. Select Windows if you want maximum hardware flexibility with minimal configuration overhead, especially for image generation workflows and consumer-oriented AI tools, and prefer extensive community support for troubleshooting. Opt for Linux/BSD if you're running large-scale training jobs requiring maximum stability and performance, need custom system configurations, or want to minimize costs while maximizing control. For most researchers, the decision balances technical expertise against time-to-productivity—Windows for quick starts and broad compatibility, Linux for maximum performance and control, and macOS for energy-efficient workflows within the Apple ecosystem.
@@ -0,0 +1,7 @@
1
+ # win_writer Draft
2
+
3
+ **Windows: The Ultimate Platform for Your Home AI Research Lab**
4
+
5
+ When building a home AI research lab focused on LLM fine-tuning, image generation, and local inference, Windows stands as the unequivocally superior choice. The platform's **first-class NVIDIA CUDA support** provides seamless access to the full GPU acceleration stack that modern AI workloads demand. Unlike other operating systems that often require complex driver configurations or suffer from compatibility issues, Windows delivers out-of-the-box support for CUDA 12.x, cuDNN, and TensorRT—essential for frameworks like PyTorch, TensorFlow, and JAX that power cutting-edge models like Llama 2, Stable Diffusion XL, and Mistral. Microsoft's **DirectML** further enhances this ecosystem by enabling hardware-agnostic ML acceleration across AMD, Intel, and NVIDIA GPUs, giving you unparalleled flexibility in hardware selection. With **WSL2**, you get native Linux compatibility without sacrificing Windows' superior hardware support, allowing you to run containerized models via Docker or Podman while maintaining access to Windows-exclusive tools.
6
+
7
+ The Windows ecosystem excels in providing the **widest hardware compatibility** and vendor support in the industry. Whether you're deploying multiple RTX 4090s for distributed training, experimenting with Intel Arc GPUs for cost-effective inference, or scaling up to workstation-class Quadro cards, Windows ensures optimal driver support and performance tuning. The platform's enterprise-grade tooling integration shines for serious researchers: **Visual Studio Code** with GPU debugging extensions, **Weights & Biases** desktop integration, **Anaconda** with native Windows conda-forge packages, and seamless **Git LFS** support for managing large model checkpoints. Popular frameworks like **Hugging Face Transformers**, **ComfyUI** for Stable Diffusion workflows, and **text-generation-webui** for local LLM serving all provide superior Windows support with pre-compiled binaries and automated installers. The vibrant Windows AI community, centered around platforms like the AUTOMATIC1111 ecosystem and LM Studio, offers extensive documentation, troubleshooting resources, and model optimization guides specifically tailored to Windows environments—making your research journey both productive and well-supported.
@@ -0,0 +1,13 @@
1
+ ---
2
+ description: OS advocate for home AI research labs
3
+ parameters:
4
+ os_name: null
5
+ strengths: null
6
+ ---
7
+ You are a passionate advocate for <%= os_name %> as the ideal operating system for a home AI research lab.
8
+
9
+ Key strengths to emphasize: <%= strengths %>
10
+
11
+ Write a 2-3 paragraph advocacy piece arguing why <%= os_name %> is the best choice for someone building a home AI research lab. Cover hardware compatibility, software ecosystem, performance, and community support. Be specific about AI/ML frameworks, GPU support, and developer tooling.
12
+
13
+ Be persuasive but factual. Use concrete examples of tools and workflows.
@@ -0,0 +1,13 @@
1
+ ---
2
+ description: Editor-in-chief who gives final approval on articles
3
+ ---
4
+ You are the editor-in-chief of a technology publication. Review the submitted article for:
5
+
6
+ 1. Balance — does it fairly represent all platforms?
7
+ 2. Accuracy — are technical claims correct?
8
+ 3. Recommendation quality — is the conclusion well-supported?
9
+ 4. Readability — is it clear and well-structured?
10
+
11
+ If the article meets your standards, respond starting with APPROVED followed by a brief note on what makes it strong.
12
+
13
+ If it needs work, respond starting with REVISE: followed by specific, actionable feedback on what to improve. Be concise.
@@ -0,0 +1,13 @@
1
+ ---
2
+ description: Editor who synthesizes OS advocacy drafts into a balanced article
3
+ ---
4
+ You are a senior technology editor specializing in AI infrastructure.
5
+
6
+ You will receive three advocacy drafts arguing for different operating systems (macOS, Windows, Linux/BSD) for home AI research labs. Synthesize them into a balanced 4-6 paragraph article that:
7
+
8
+ 1. Acknowledges the strengths of each platform
9
+ 2. Compares them fairly across key dimensions (cost, GPU support, software ecosystem, ease of use)
10
+ 3. Identifies which scenarios favor which OS
11
+ 4. Ends with a clear, nuanced recommendation
12
+
13
+ Write in a professional editorial voice. Be objective even though your sources are advocates.