AI research keeps growing. But researchers may be spending more of that effort pursuing the same ideas. A study of 7.2 million computer-science papers suggests that major AI breakthroughs can draw attention toward winning approaches so powerfully that the diversity of ideas available for the next discovery starts to shrink.

Share

That is a troubling possibility for a field increasingly organized around transformers and large language models. It is still a hypothesis about scientific research, not evidence that transformers have hit a technical ceiling or that AI models are improving more slowly.

How the researchers measured AI’s growing concentration

In an October 19, 2026 preprint, Beichen Lu, Honglin Bao, Qi Huang, Qingguo Meng and James A. Evans examine computer-science research published between 1990 and 2025. Their dataset includes 7,180,635 papers, 73,089 peer reviews and the publication histories of approximately 3.7 million researchers.

The researchers measure which subjects attract attention, how scientists move between research subfields and how the vocabulary of published work changes. For each abstract, they identify prominent keywords, then calculate how unevenly attention is distributed across them. They also use nouns in abstracts as markers for potential research ideas.

One measure of attention concentration, the Gini coefficient, rose from 0.26 to 0.33 between 2017 and 2025. The higher number indicates that attention was distributed less evenly among research keywords. During roughly the same period, AI’s share of computer-science papers increased from about 40% to more than 55%.

The migration data show a similar pull. Of 918,862 recorded moves between research subfields, 53.81% ended in AI. Those are observed changes in researchers’ main subjects, not evidence that 53.81% of all computer scientists abandoned their specialties.

Peer review offers another signal. Among reviews sampled from 45 venues, average reviewer confidence fell from 3.9 to 2.9 on a venue-normalized 0-to-5 scale between 2017 and 2025. The authors suggest that matching papers to suitable experts may have become more difficult as AI expanded. Falling confidence scores alone cannot identify the cause.

Each measurement captures a different part of the research system. Taken together, they suggest that computer science is becoming more concentrated around AI, even while the field produces more papers and attracts more people.

Why breakthroughs might shorten the life of research ideas

The paper describes a recurring cycle around AlexNet in 2012, the transformer architecture in 2017 and the rise of large language models. A breakthrough creates new possibilities and attracts researchers. Fresh terminology and projects proliferate. Over time, much of the community gathers around improving the successful approach, while other lines of inquiry receive less sustained attention.

To study that pattern, the authors treat each distinct, stable noun found in paper abstracts as a potential idea. A noun becomes established after appearing in at least 10 papers in each of two consecutive years. If it fails to meet that threshold for three consecutive years, the model treats the idea as inactive. It can later return.

That method allows the authors to count the appearance, disappearance and revival of research terminology across decades. Their fitted curves suggest that successive breakthroughs raise the estimated capacity for active ideas, but are also followed by sharper declines from that modeled potential. They report a comparable cycle in structural biology after cryo-electron microscopy and AlphaFold.

The proposed mechanism is plausible. Once a powerful architecture takes hold, researchers can publish improvements using familiar tools, shared benchmarks and established assumptions. An unfamiliar approach may initially perform worse on those tests, even if it has strengths that could become useful later. It needs time, funding and reviewers willing to evaluate a different hypothesis.

The authors also simulate a peer-review system in which prolific submitters take on more reviewing work. Under the model’s assumptions, that arrangement gives established, highly active researchers more influence over which topics receive approval. It does not prove that existing conference review policies created the historical concentration.

Why the study cannot prove AI is running out of discoveries

The paper’s most important limitation is its definition of an idea. A noun can help track changes in scientific language, but it is not the same thing as a scientific concept. Researchers can develop genuinely new methods using familiar words. A fashionable term can also spread widely without representing a meaningful discovery.

The authors test alternative ways of extracting nouns and noun phrases, which strengthens their claim that the statistical pattern is present in the text. It does not resolve the harder question of whether those vocabulary patterns accurately measure the quality or originality of science.

Timing also complicates the argument. Transformer research grew during a period of increasing computing capacity, investment and commercial demand for AI. The study cannot isolate the transformer architecture as the cause of the shift in research attention, or establish that concentrating attention will delay a future breakthrough.

The authors acknowledge that the period following the newest LLM advances is too short for a definitive conclusion. Their research-idea “carrying capacity” is a fitted curve, not a physical limit on what AI systems can discover. The dataset concentrates on English-language computer-science papers with abstracts, while much unpublished industrial research remains outside its reach.

Other work raises related questions using different evidence. A 2020 American Economic Review study found that research effort rose while research productivity declined in several settings. A 2023 Nature analysis reported that scientific papers and patents became less disruptive by citation-based measures. Neither result independently establishes the causal story proposed in this new preprint.

Could transformer dominance make the next AI breakthrough harder?

It could. When funding, talent and evaluation benchmarks favor extensions of one successful architecture, researchers have weaker incentives to pursue approaches that look unpromising on today’s tests. Leading AI models might improve rapidly while less conventional ideas remain underdeveloped.

That does not mean competing architectures have disappeared. Mamba uses selective state-space models to process sequences without conventional transformer attention. It represents a genuine alternative line of research, although its existence alone says little about whether the research community gives competing approaches enough support.

There is also a gap between the productivity of a research community and the capabilities of the systems it builds. More papers, more automated experiments and faster iteration do not guarantee more useful discoveries. We have explored a related measurement problem in OpenAI’s reported use of AI-agent workdays: activity is easier to count than validated scientific progress.

For funders and labs, the question is whether promising alternatives can obtain time, computing resources and serious evaluation. Conferences face a similar challenge when assigning reviewers to unfamiliar ideas. For researchers, improving a dominant benchmark and testing a genuinely different hypothesis are both useful work, but they develop a field in different ways.

More on AI-assisted research:

What to watch before calling AI research exhausted

The new preprint makes a reasonable case for tracking the diversity of research attention alongside model performance, publication volume and research spending. But vocabulary-based measures should be checked against direct evidence of novel methods, independent replication and whether unconventional research directions survive long enough to be tested fairly.

The strongest conclusion is still conditional. Concentrating research around transformers could make the next departure from transformers harder to discover. The authors have documented a suggestive pattern, not the breakthroughs that never happened. Keeping room for experiments outside today’s winning approaches is a sensible response to that uncertainty, especially when the cost of overlooking an unusual idea may be visible only much later.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

Use a local AI agent to replace Tyrian’s standard starting Pulse-Cannon with the Zica Laser, then compare how the weapon looks, fires, and sounds. You’ll analyze the Windows executable with Ghidra and Reverse Engineer Anything (REA), create a reversible weapon swap, and verify the files it changes.

Share

Tyrian, the 1995 vertical-scrolling shooter, gives you a good first target. Pick a single front weapon in Episode 1 and you can see the effect of a successful change as soon as you hold down fire. You can follow the investigation through the agent’s tool results even if you haven’t read assembly before.

You run the setup, check what the agent did, and play both copies. The agent uses local Qwen inference to follow the loader and firing logic, map those findings to the right data record, and write a patcher and a short evidence report. Keep the original copy handy: it’s your comparison run, your source of known-good bytes, and your recovery path if the mod breaks.

1. The Windows reverse-engineering toolchain

Start with a Windows 11 x64 PC. Ollama runs Qwen3.8 27B on the GPU for local reasoning, coding, and tool use. OpenCode is the coding agent that runs commands and works with project files. REA connects OpenCode to binary-analysis tools, and Ghidra examines the machine code in OpenTyrian 2.1 and reconstructs pseudocode. Python and standard Windows utilities handle the reversible patch and verification.

The main analysis and modding tools are open source, and the Qwen3.8 27B weights use the Apache 2.0 license.

▪ Why use OpenTyrian on Windows?

The original Tyrian runs as a DOS program. REA can analyze DOS MZ executables on supported hosts. For this native Windows workflow, use an x64 Windows PE executable within REA’s experimental Ghidra support boundary. The original TYRIAN.EXE falls outside that Windows boundary.

OpenTyrian is a native port of Tyrian that uses the freeware Tyrian 2.1 game data. Its Windows build gives us a suitable executable and the original gameplay data in the same package. Tell the agent to treat the executable as a black box and leave the C source alone during the investigation. Later, it can check its findings against the data format documentation. That sequence lets you practice the same analysis you would use on a game whose source was unavailable, with a reference to check your work afterward.

You can work from Windows PowerShell and keep model inference local throughout the tutorial. Ghidra runs headlessly through REA, so you can follow the evidence in OpenCode without having to learn Ghidra’s desktop interface first.

2. Choose the right hardware and local AI model

A reverse-engineering agent has to follow function calls, interpret decompiled pseudocode, and keep its place across a long sequence of tool calls. A model that can answer a short coding question may still lose track of which binary it opened or which record it has verified.

For this tutorial, aim for a single GPU with 24 to 32 GB of VRAM, such as an RTX 4090 or RTX 5090, plus 64 GB of system RAM and at least 30 GB free on an SSD. Treat those figures as a setup recommendation. A fast CPU helps with Ghidra’s analysis, while the GPU has to hold both the model and the working context you give it.

▪ Run Qwen3.8 27B locally

The Ollama build of Qwen3.8 27B supports tool calling and reasoning and downloads at about 18 GB. The model supports up to roughly 256K tokens of context, but that capacity and the download size measure different things. The context allocation adds runtime memory demand beyond the stored weights, so an 18 GB download gives you no guarantee that the 64K profile will stay fully on a 24 GB GPU.

Qwen3-Coder-Next is an 80B-parameter mixture-of-experts coding model with a roughly 52 GB default Ollama download. It makes more sense on a multi-GPU machine or one with a large memory pool. Start with Qwen3.8 27B on a 24 or 32 GB GPU.

We’ll ask Ollama for 65,536 tokens, then check what it actually allocates and where the model runs. If other apps are taking up VRAM or the model spills heavily onto the CPU, the 32K fallback below gives the agent a better chance of staying responsive. In that case, save findings after each stage and ask for specific tool results so the conversation has less to carry.

More on local AI hardware:

3. Install the local AI runtime

Set up local inference and test it from PowerShell before connecting it to OpenCode. This gives you a separate check for the model server if the agent later fails to see it.

3.1. Install Ollama

Run the Ollama Windows installer. Ollama should start its local inference service after installation.

Open Windows Terminal or PowerShell and type:

ollama --version

Next, confirm its local service is available:

Invoke-RestMethod http://127.0.0.1:11434/api/tags

A successful response shows the locally installed model inventory, which may initially be empty.

If PowerShell cannot recognize ollama, reopen the terminal after installation. If the connection is refused, launch Ollama from the Start menu.

3.2. Download Qwen3.8 27B

In PowerShell:

ollama pull qwen3.8:27b

Ollama downloads the model to your computer.

Once installed, run a quick test:

ollama run qwen3.8:27b

Ask:

Explain what a machine-code disassembler does in two sentences.

A coherent answer confirms that Ollama can generate a response with the downloaded model.

You’ll test tool calling separately. Type /bye to exit the interactive session.

3.3. Give the agent enough context

A local model can advertise a large maximum context window while the inference server uses a much smaller allocation. That can cause coding agents to forget earlier findings or fail during longer tool-driven tasks.

We’ll create a dedicated Ollama profile that requests the highest context available.

In PowerShell:

@'
FROM qwen3.8:27b
PARAMETER num_ctx 262144
RENDERER qwen3.5
'@ | Set-Content -Encoding utf8 "$HOME\tyrian-coder.Modelfile"

ollama create tyrian-coder -f "$HOME\tyrian-coder.Modelfile"

If you are running qwen3.8:27b with 16GB VRAM or less, try setting PARAMETER num_ctx to 32768. If you have 24GB VRAM available, setting PARAMETER num_ctx at 65536 should work fine. With 32GB VRAM or more, you should be able to run it with PARAMETER num_ctx at 131072 or, on higher-end GPUs, 262144 context.

This Modelfile creates a named model configuration called tyrian-coder, using the downloaded Qwen3.8 weights.

Verify it:

ollama show tyrian-coder --modelfile

Look for PARAMETER num_ctx and verify that it is set at the number your Modelfile specifies:

Then load it:

ollama run tyrian-coder "Reply READY."

Inspect the loaded model:

ollama ps

Ideally, the processor column should show full GPU execution rather than substantial CPU offloading. Check the reported context length here as well:

If you encounter out-of-memory errors, recreate the profile with 32768 instead of 65536.

Prioritize a responsive GPU-backed session. The agent has to read a tool result, reason about it, and make another request dozens of times. A slow response at each turn adds up, even when every individual query succeeds.

4. Install OpenCode, our local AI coding interface

OpenCode V2 gives the model a terminal, project file tools, and MCP access. That lets the model request a Ghidra operation, read what comes back, and write a patch script once it has evidence. The guide uses the terminal interface. You can open the same project in the graphical desktop app if you prefer.

4.1. Install Node.js

Use the Node.js download page to pick a supported release, or install the current LTS release through PowerShell and check the version afterward.

winget install --id OpenJS.NodeJS.LTS --exact

Close and reopen PowerShell, then verify:

node --version
npm --version

For REA’s native Windows Ghidra provider, check your installed Node version against the Windows support guide linked above. Within the 24.x series the documented minimum is 24.22.1.

If the LTS install lands on an older patch release, update Node before setting up REA. A Node version that runs npm can still fall below the provider’s minimum.

4.2. Install OpenCode V2

Run the documented npm install from PowerShell. If npm’s postinstall cannot supply the Windows binary, download the standalone Windows x64 CLI from the same OpenCode V2 page, extract it to a directory on your PATH, and reopen PowerShell. Verify that the command resolves to V2 before creating the project configuration.

npm install --global @opencode/cli

Verify:

opencode --version

Launch OpenCode:

opencode

You should see its terminal-based conversation interface.

Use the project configuration and model selector documented for V2. If you’re coming from OpenCode’s earlier configuration reference, recheck the provider and MCP settings for the version you actually launched.

4.3. Connect OpenCode to Ollama

OpenCode V2 discovers completion models on the default local Ollama endpoint. Leave Ollama running while you configure the agent.

Start OpenCode and open its model selector:

/models

Select tyrian-coder:latest:

If it doesn’t appear immediately, check that Ollama is running and that ollama list shows the model. Reopen OpenCode to refresh detection.

You can also make it the default model for this project by creating an opencode.json configuration file, but we’ll do that in a later step.

Check that the selected model resolves to the local service at 127.0.0.1:11434 by opening another PowerShell tab and running:

Invoke-RestMethod http://127.0.0.1:11434/api/tags

If Ollama is running correctly, PowerShell will display information about the locally installed models:

After the software and weights are on disk, this model can run inference without an internet connection. Keep the agent on local analysis tools during the experiment.

5. Install Ghidra

Ghidra is the NSA’s open-source reverse-engineering suite. Its decompiler represents machine instructions as C-like pseudocode. The agent can use that output to follow code from the data loader to the routine that decides when the next volley can fire. REA gives OpenCode access to Ghidra’s headless analysis.

5.1. Install Java

Ghidra needs a full Java Development Kit. Install the 64-bit Eclipse Temurin JDK 21 from a fresh PowerShell tab and verify that both the runtime and compiler commands work.

winget install --id EclipseAdoptium.Temurin.21.JDK --exact

Reopen PowerShell, then check:

java -version
javac -version

Both should work.

If javac is missing, locate your installed JDK under:

C:\Program Files\Eclipse Adoptium\

You will need its exact folder path during REA setup.

5.2. Download Ghidra

Download Ghidra 12.1.4 from the official releases. The REA Windows guide identifies this build as verified. If you choose a different 12.1.x release, adjust the paths throughout the guide and check it with rea doctor.

Extract it to:

C:\Tools\

The resulting directory should resemble:

C:\Tools\ghidra_12.1.4_PUBLIC\

Inside it, confirm that this file exists:

support\analyzeHeadless.bat

You don’t have to open Ghidra’s graphical interface. REA uses Ghidra’s headless analysis facilities.

If the launcher is missing after extraction, check the archive layout against the Ghidra installation instructions before setting the provider path.

6. Install Reverse Engineer Anything and connect it to OpenCode

Reverse Engineer Anything connects coding agents to reverse-engineering tools through the Model Context Protocol (MCP). In this setup, you give OpenCode a task and it runs the Qwen model through Ollama. When the model requests a binary-analysis operation, OpenCode invokes the REA MCP server. REA manages the session, calls Ghidra headlessly, and returns evidence such as strings, cross-references, and decompiled functions.

REA’s Ghidra integration on Windows is read-only. Use it to investigate the baseline executable, then let OpenCode’s file and terminal tools create a reversible patch for the working copy. The verification report should identify every changed file and explain whether the chosen weapon-swap method changes game data, executable code, or both.

REA connects AI coding agents to Ghidra to inspect compiled executables and recover readable code.

6.1. Install REA

Open PowerShell from your home directory:

Set-Location $HOME
npm install --global rea-agents

Verify:

rea --version

6.2. Tell REA where Ghidra and Java are installed

Set the exact paths in PowerShell. Adjust these to match your machine.

$env:GHIDRA_INSTALL_DIR = "C:\Tools\ghidra_12.1.4_PUBLIC"
$env:JAVA_HOME = "C:\Program Files\Eclipse Adoptium\jdk-21.0.x-hotspot"

The folder paths above are illustrative. Replace them with your actual Ghidra and JDK directories, and pay extra attention to getting the installed version number correct.

Check both paths:

Test-Path "$env:GHIDRA_INSTALL_DIR\support\analyzeHeadless.bat"

Test-Path "$env:JAVA_HOME\bin\javac.exe"

Both should return True before you continue.

Now let REA inspect the installation:

rea doctor --provider ghidra --json

The report should identify a usable Ghidra provider.

If it reports a missing Java executable, unsupported Ghidra version, or missing native decompiler, fix the reported prerequisite before continuing.

6.3. Register REA with OpenCode

With the environment variables still set in the same PowerShell session, run:

rea setup --client opencode

REA presents a setup plan. Review the directories, environment variables, MCP registration, and workflow instructions it proposes.

Approve the appropriate configuration.

REA can register its MCP server for OpenCode V2 and install its investigation skill. Close any existing OpenCode session, then start it from PowerShell with the same Java and Ghidra paths set. If you use a new terminal, set those variables there first unless you have configured them persistently.

6.4. Verify the MCP connection

In PowerShell:

rea doctor --client opencode --json

Then check the client itself:

opencode mcp list

You should see a connected server named rea.

This confirms the agent-side connection. We’ll verify a real Ghidra analysis shortly.

If you only see a grouped tool interface, check how OpenCode exposes MCP operations in Code Mode. The connection check tells you that the server is present. The first-look exercise below checks whether the model can actually use it to get evidence from Ghidra.

7. Download Tyrian and prepare a safe workspace

Download the Windows x64 ZIP for OpenTyrian v2.1.20260913, the September 2026 release used in this walkthrough. The release archive includes the freeware Tyrian 2.1 data. Choose x64 for the Windows and REA setup described here.

7.1. Separate the baseline, mod, and evidence

We’ll keep an untouched baseline, a playable modded copy, and a workspace for the agent’s scripts and discoveries.

Open PowerShell and run:

$root = "C:\TyrianRE"

New-Item -ItemType Directory -Force `
  "$root\baseline", `
  "$root\modded", `
  "$root\tools", `
  "$root\findings" | Out-Null

Extract the downloaded OpenTyrian ZIP into C:\TyrianRE\baseline.

Ensure the game executable ends up directly at:

C:\TyrianRE\baseline\opentyrian.exe

If the ZIP contains an extra enclosing directory, move its contents up one level.

Now, in PowerShell, make a complete working copy:

Copy-Item "C:\TyrianRE\baseline\*" `
  -Destination "C:\TyrianRE\modded" `
  -Recurse -Force

Inside C:\TyrianRE, baseline holds the original installation and modded holds the playable copy the agent can change. The other two folders, tools and findings, can stay empty for now. Later in the tutorial, our AI agent will automatically fill them with the files it creates while investigating and modifying the game. You won’t need to write any of that code yourself.

Keeping the baseline and modded directories separate gives you an original file for byte comparisons and a working game you can restore without downloading the archive again.

7.2. Verify the installation

Check the files:

Test-Path "C:\TyrianRE\baseline\opentyrian.exe"

Get-ChildItem "C:\TyrianRE\baseline" `
  -Filter "tyrian.hdt" -Recurse

The first command should return True. The second should locate a game data file named tyrian.hdt.

Now record the executable’s original checksum:

Get-FileHash `
  "C:\TyrianRE\baseline\opentyrian.exe" `
  -Algorithm SHA256

A SHA-256 hash is a fingerprint of the file. It allows us to confirm exactly which version the agent analyzed and whether it was changed afterward.

8. Tell OpenCode which files it can modify

Before we let our AI agent investigate Tyrian, we’ll give it a few ground rules. We want the agent to examine the original game without accidentally changing it, and to keep its experiments inside our project folder.

OpenCode supports a special file called AGENTS.md. It contains instructions for the AI agent. When you start OpenCode inside a project folder, it automatically reads that project’s instructions. You don’t need to paste them into every conversation.

8.1. Create the instructions file

Open PowerShell and enter:

notepad C:\TyrianRE\AGENTS.md

If Notepad asks whether to create the file, click Yes.

Copy the following text into Notepad:

# Tyrian reverse-engineering project

You are helping me reverse-engineer and modify Tyrian
using REA and Ghidra.

Follow these rules throughout this project:

1. The baseline folder contains the original game.
   You may read files in this folder, but never
   modify, delete, or overwrite them.

2. The modded folder contains the copy of the game
   that we will experiment with. You may modify
   files here.

3. Save any programs or scripts you create in
   the tools folder.

4. Save your reverse-engineering findings, notes,
   and reports in the findings folder.

5. Use the local AI model and local analysis tools.
   Do not send game files or analysis data to cloud
   AI services.

6. Do not download or execute unknown programs
   without asking me first.

7. Ask for my approval before deleting files,
   changing anything outside C:\TyrianRE, or
   performing potentially destructive operations.

8. Use REA and Ghidra to investigate the compiled
   game. Do not consult OpenTyrian's public source
   code to discover the solution.

9. Verify your modifications and explain what
   changed. Never claim a test succeeded unless
   you actually performed it.

Save the file and close Notepad.

That’s it. The next time OpenCode starts inside C:\TyrianRE, it will automatically load these instructions. This behavior is documented in OpenCode’s project instructions guide.

8.2. Make OpenCode ask before making potentially risky changes

Instructions tell the AI what we want, but they aren’t a technical security barrier. OpenCode also has a permissions system that controls when it must ask for approval.

Open our existing configuration:

notepad C:\TyrianRE\opencode.json

Copy-paste these contents into the file:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "ollama/tyrian-coder:latest",
  "permissions": [
    {
      "action": "edit",
      "resource": "baseline/*",
      "effect": "deny"
    },
    {
      "action": "shell",
      "resource": "*",
      "effect": "ask"
    },
    {
      "action": "external_directory",
      "resource": "*",
      "effect": "ask"
    },
    {
      "action": "webfetch",
      "resource": "*",
      "effect": "deny"
    },
    {
      "action": "websearch",
      "resource": "*",
      "effect": "deny"
    }
  ]
}

Save and close Notepad.

These settings tell OpenCode to block its built-in file-editing tools from modifying baseline, ask before executing terminal commands or accessing locations outside the project, and disable its built-in web search and web-fetch tools.

The shell-command approval is especially important. A command executed through PowerShell can still modify the original game if you approve it. The baseline restriction on OpenCode’s file-editing tools does not, by itself, protect against every possible shell command or external MCP tool.

The settings above use OpenCode V2’s current permissions format, which differs from examples written for older versions.

8.3. Start OpenCode

In PowerShell, enter:

cd C:\TyrianRE
opencode

That’s all you need to do. OpenCode reads AGENTS.md automatically, and the permissions in opencode.json are applied to the project.

For a quick check, you can ask the agent:

Before we begin, summarize the project rules
you have been given. Which folders may you modify,
and which folder must remain untouched?

It should correctly identify baseline as the original, modded as the working copy, and tools and findings as the places to store its work.

When OpenCode later asks permission to run a command, review what it intends to do. Approve ordinary analysis commands and clearly understood modifications to the working copy. Reject commands that unexpectedly modify the baseline, access unrelated folders, or download software.

Close OpenCode by typing /exit.

You can now continue to the first REA and Ghidra test.

9. Play the original game once

Back in PowerShell, run the baseline game:

Set-Location "C:\TyrianRE\baseline"
.\opentyrian.exe

Start a new single-player Full Game in Episode 1 using the standard Pulse-Cannon front weapon.

Watch the Pulse-Cannon’s projectile appearance and firing pattern, listen to its sound, and check the generator during sustained fire. Record a short clip with audio so you can compare this baseline with the Zica Laser replacement later.

Use the same starting equipment and weapon power level for the later comparison. A screenshot or a short video of continuous firing can help establish a baseline.

Close the game before proceeding.

The two copies can share settings and saves under %APPDATA%\OpenTyrian. This release can use the executable’s directory for settings and saves if opentyrian.cfg is already present there. After we modify the game, for a straightforward comparison, start a fresh Episode 1 game in each copy and match the difficulty, equipment, power level, and starting generator.

Tyrian's original gameplay provides a visual reference before testing our Pulse-Cannon and Zica Laser swap.

10. Give OpenCode access to the project

Return to PowerShell:

Set-Location "C:\TyrianRE"

Now launch OpenCode from that directory:

opencode

Alternatively, open the folder in OpenCode Desktop.

The project directory is important because the agent will be able to read the game files, create scripts in tools, and write its investigation results to findings.

Review OpenCode’s permission prompts if/when they appear. These project boundaries are instructions to the agent. Check the working directory and target paths on write or execution requests, especially when PowerShell commands use relative paths.

11. Test whether the AI can actually operate Ghidra

Before asking the model to reverse-engineer game mechanics, we’ll give it a smaller assignment.

Paste this into OpenCode:

We are working locally on Windows in C:\TyrianRE.

Use the connected REA MCP server to inspect
C:\TyrianRE\baseline\opentyrian.exe
with provider_id ghidra.

First check binary_session and provider availability.
Then call open_binary, request a binary_overview,
and identify the executable architecture, entry
point, imported libraries, and a few significant
strings.

Use actual REA tool calls. Do not guess from
filenames or prior knowledge.

Do not examine the public source code.
Do not modify any files.

Save a concise report in findings\first-look.md
including the file SHA-256 and observed
Ghidra/REA evidence.

Close the binary session when finished.

11.1. Check the first Ghidra tool results

The agent should discover the REA tools, open the executable with Ghidra, and retrieve analysis results.

You should see actual tool activity, rather than a generic explanation of how Ghidra works.

REA’s operations include open_binary, binary_overview, search_strings, function analysis, cross-references, and memory inspection.

Ghidra may spend some time importing and analyzing the executable on the first query. Opening a binary through REA selects the target; it doesn’t necessarily mean the analysis engine has completed initialization.

Open findings\first-look.md and compare it with the visible tool results. It should identify the provider, executable, architecture, entry point, and at least a few imports or strings returned by Ghidra. The prompt’s final report is the intended output file. Keep the game directories unchanged during this check.

If the agent merely explains what Ghidra could do, tell it:

I don’t want a simulated analysis. Invoke the installed REA tools. If a tool is unavailable, report the actual error and its proposed fix.

Do not proceed until a genuine analysis succeeds. You may have to tell the agent to continue what it was doing if responses exceed the token limit.

Ghidra reconstructs useful pseudocode and references from compiled binaries, which the local AI agent can investigate through REA.

12. Replace the Pulse-Cannon with the Zica Laser

Our first idea was to make the Pulse-Cannon fire faster. In practice, that was a disappointing demonstration. A small change in firing frequency was difficult to judge once the screen filled with enemies and projectiles.

We gave the agent a more obvious objective. Replace the standard Pulse-Cannon with the game’s existing Zica Laser. In our run, the weapon looked, fired, and sounded noticeably different. You could recognize the change as soon as you pressed fire.

That gives us a better first reverse-engineering project. The agent has to identify two existing weapons, trace how the game selects their behavior, and make the starting weapon use the Zica Laser. The result gives you something clear to compare in the baseline and modified copies.

12.1. Trace how the game selects a weapon

OpenTyrian’s weapon-port records refer to shot patterns for different power levels and firing modes. Those patterns contain timing, projectile graphics references, and a sound field. Power use is recorded in the weapon-port definition.

The agent needs to connect the player’s equipped front weapon to those records. Finding the text “Zica Laser” is a starting point. It still has to establish which definition the game uses, how that definition leads to the shots on screen, and where the firing sound comes from.

Ask it to trace both the original Pulse-Cannon and the Zica Laser before proposing a patch. The change should reproduce the existing Zica weapon’s appearance, firing behavior, and sound in the starting front-weapon position. Let the evidence determine whether that means changing the equipped weapon selection or the data it resolves to.

12.2. Give the swap a clear acceptance test

Start a fresh Episode 1 game in each copy, with the same difficulty, ship, starting power level, and audio settings. Fire in the same part of the opening level.

The baseline should still produce the ordinary Pulse-Cannon. In the modified copy, compare the projectile appearance, firing pattern, and sound. Check that the weapon can fire, that the generator behaves sensibly, and that the game still loads and plays.

Keep a short recording with audio from each run. Those clips make the result much easier to assess than trying to remember whether a familiar gun fired slightly faster.

13. Give OpenCode the Zica Laser assignment

Once the first-look exercise confirms that REA and Ghidra work, give the agent a complete weapon-swap assignment.

The model should investigate the executable, resolve the weapon definitions, and produce the patch. Your part is to review its evidence and compare the two playable copies.

Paste this into OpenCode.

Work locally in C:\TyrianRE with the connected REA MCP server
and Ghidra.

Goal: Replace the standard starting Pulse-Cannon with the game's
existing Zica Laser in a fresh Episode 1 story game. The modified
front weapon should use the Zica Laser's projectile appearance,
firing behavior, and sound.

Start with the baseline loadout and power level. Use actual REA
calls to trace weapon selection, the Pulse-Cannon and Zica Laser
definitions, their shot-pattern references, and the code that
uses them. Leave the public C source alone during discovery.
Use the tyrian.hdt format reference afterward as a cross-check.

Record the analyzed build, file paths, SHA-256 hashes, relevant
code addresses, weapon identifiers, and record mappings in
findings\analysis.md. Derive all identifiers and offsets from
this build. Do not guess them.

Choose the smallest verified change that achieves the full swap.
Explain whether it changes player equipment selection, weapon
data, executable code, or a combination. Check for shared records
and effects on other weapons. Preserve the existing Zica Laser
definition and unrelated gameplay wherever the chosen method
allows. Report any unavoidable wider effects before applying it.

Create tools\patch_tyrian.py and a verification script. Preserve
the baseline and modify only the working copy under modded.
Check expected original bytes and structure before writing.
Reject unexpected input and handle an already-patched copy
without applying the modification twice. Provide an undo path.

Save a patch manifest under findings with the exact changed files,
computed offsets, old and new values, and byte differences.
Verify the baseline is intact and the differences match the
manifest. Report whether the executable changed and why.

Give me the command to launch the modified copy and a short manual
test comparing the Pulse-Cannon and Zica Laser at the same starting
power level. Ask me to compare appearance, firing pattern, and
sound, then check energy use and normal gameplay.

Write only under modded, tools, and findings. Ask before destructive
or out-of-project actions. If evidence is missing, report the
specific gap before patching. Separate verified file changes from
gameplay results I still need to check.

Close the Ghidra binary session when finished.

13.1. Ask for the evidence behind the replacement

The report should explain how the game gets from the starting loadout to the weapon it actually fires. Have the agent show where it identified the Pulse-Cannon, where it identified the Zica Laser, and which part of that selection path the patch changes.

If the proposed patch only changes a weapon name or a firing-delay value, send it back to the stated objective. You should be able to connect the modification to the Zica projectile pattern and sound before launching the game.

13.2. Why the prompt is this specific

Each stage gives you something concrete to inspect. The binary trace explains where the game gets the timing value. The record mapping explains which bytes belong to the equipped weapon. The manifest shows what the script actually changed. If the file fails the layout or original-value check, stop and revisit the mapping with a clean copy.

14. Check that the agent found the complete weapon behavior

Start with the loader and the weapon selection path. The agent should show actual REA results connecting the compiled program to its weapon data, then resolve the front weapon used by the fresh Episode 1 loadout.

Next, have it identify the Zica Laser’s corresponding definition and shot patterns for the power level you are testing. Ask which references account for projectile appearance, firing behavior, and sound, and how the patched selection will reach them.

14.1. Check the relationships between records

The name displayed in a menu can help identify an entry, but gameplay follows the weapon and pattern references. Verify those references through the compiled program.

A swap can also expose differences in energy use or upgrade behavior. Ask the agent to record what the proposed method does to the starting power level and generator demand. Any adjustment beyond the weapon replacement should be identified separately in the manifest.

If the patch changes a shared record, the report should identify the other weapons, modes, or power levels that use it. Review those effects before accepting the modification.

14.2. If the agent gets stuck

Bring it back to the two weapons and the selected loadout.

Continue from findings\analysis.md and the existing REA evidence.
Do not repeat completed investigation work.

Resolve the baseline front-weapon selection for a fresh Episode 1
story game, then identify the Pulse-Cannon and Zica Laser records
and their shot-pattern references at the tested power level.

Trace how those references reach projectile graphics, firing
behavior, and sound. Check energy use separately.

Explain the smallest verified change that makes the starting
front weapon behave as the existing Zica Laser.

Write the confirmed mapping and remaining uncertainty to the
report before editing files. Do not settle for renaming the
weapon or changing its firing interval.

Once the mapping is complete, the patcher should be able to check the original state and explain each proposed change. A report that jumps from a weapon-name match to a guessed offset needs more investigation.

15. Apply the Zica Laser replacement and compare the result

Review the manifest before running the modified game. It should identify the exact OpenTyrian build and original file hashes, the starting front-weapon selection, the Pulse-Cannon and Zica Laser definitions, and the references or bytes the patch changes.

Require the old values, replacement values, computed file offsets, and an explanation for every changed file. Record whether file lengths changed and whether that was expected. The restore instructions should identify the clean files or original bytes needed to undo the swap.

A hexadecimal offset is useful only if the patcher can derive it from the record layout and match the expected original value. Keep a copy of the manifest for the first successful change so you can compare it with later adjustments.

15.1. Apply the patch and verify the files

If the agent has written the patcher but has not applied it, ask it to run the patch against the working copy and verify the result.

Apply the verified Zica Laser replacement to the modded copy,
then run the verification script.

Confirm that baseline is unchanged. List the modified files and
exact byte differences, and match them to the patch manifest.

Report whether opentyrian.exe changed. If it did, explain the
code change and verify its original and replacement bytes.

Show how to restore the original starting weapon.

Keep the patcher under C:\TyrianRE\tools and the report under C:\TyrianRE\findings.

You can still compare the two executable hashes with the existing PowerShell check.

$original = Get-FileHash `
  "C:\TyrianRE\baseline\opentyrian.exe" `
  -Algorithm SHA256

$modified = Get-FileHash `
  "C:\TyrianRE\modded\opentyrian.exe" `
  -Algorithm SHA256

$original.Hash -eq $modified.Hash

True means the executable is identical in both copies. If the result is False, the manifest must account for the executable changes. Judge the result against the documented patch method. An unexplained difference is a reason to stop and inspect the files.

If you need Python for the patcher, install a current Python 3 release for Windows and check the launcher.

py -3 --version

15.2. Launch the modified game

Close the baseline game, then launch the copy under modded.

Set-Location "C:\TyrianRE\modded"
.\opentyrian.exe

Start a fresh Episode 1 story game with the same difficulty and starting power level as the baseline run. Hold fire, look at the projectiles, and listen.

In our run, replacing the Pulse-Cannon with the Zica Laser produced a noticeable change in all three parts of the weapon’s presentation. That is the result to check on your copy. A changed menu label alone cannot establish that the weapon replacement worked.

Capture a short clip of each run with game audio enabled, using the same opening stretch of the level. Compare the shots’ appearance, their firing pattern, and their sound. Then check sustained fire, generator behavior, movement, menus, and level loading.

16. Troubleshoot OpenCode, Ghidra, and the patch

Find the first stage that fails.

▪ If OpenCode can’t see REA, run rea doctor --client opencode --json and fully restart OpenCode.

▪ If REA connects but Ghidra rejects the target, run rea doctor --provider ghidra --json and check the host, provider, and executable format.

▪ Make sure you downloaded the Windows x64 game archive.

▪ For a Java or launcher error, correct JAVA_HOME or GHIDRA_INSTALL_DIR before running setup again.

If the initial Ghidra query times out, check the reported deadline and the current session state. If the model forgets earlier findings, use the 64K profile if it fits, reduce the amount of tool output per request, and keep reports on disk. Malformed tool calls are a reason to check the selected Ollama model and retry a smaller task.

If the starting weapon still behaves like the Pulse-Cannon, confirm that you launched the modified copy and started the intended Episode 1 loadout. Recheck the weapon selection and shot-pattern references. If only the appearance or sound changed, compare the complete mapping with the Zica Laser definition. If firing stops after a short burst, inspect generator behavior and energy demand. For a crash, restore the original files and check the patch against the verified layout. If the change disappears after restarting, confirm the launched path, data files, and saved loadout.

16.1. Recovering from a Ghidra timeout

REA distinguishes the MCP connection from Ghidra’s actual analysis process. A successful open_binary call does not guarantee that the first analysis query has finished.

If a query times out, the agent should inspect REA’s session state. Where appropriate, it should use close_binary followed by a new open_binary call rather than repeatedly issuing the same query against an uncertain session.

OpenCode V2 lets you configure the MCP execution timeout. If a request expires, use REA’s guidance for recovering the Ghidra session before retrying.

16.2. Recovering from a confused agent

Local models sometimes lose the thread of a lengthy reverse-engineering assignment. They may begin guessing, repeating tool calls, or exploring unrelated functions.

Give the model the saved findings and ask for one next operation. For example:

Read findings\analysis.md and the current patch manifest.

Summarize what is confirmed and what remains unknown.

Do not repeat completed investigation work.
Do not edit anything yet.

Identify the single next REA operation that would
best resolve the remaining uncertainty, then run it.

If you start a new conversation, instruct the agent to read the stored findings before analyzing anything again.

Ask for the next tool result to be written back to the report. That gives you a place to resume even if the next import is slow or you need to restart the model.

17. Turn the patcher into a weapon-selection tool

Once the Zica Laser replacement works, ask the agent to turn the patcher into a small local tool. A first version could let you inspect the original starting weapon, apply the verified Zica replacement, or restore the Pulse-Cannon.

Have it preview the affected files and record references before applying a change. It should recognize both a clean installation and an already-patched copy, check the expected bytes, and keep a usable restore path.

Later, you can add other existing weapons after the agent verifies their definitions and selection paths. Keep each weapon’s graphics, firing pattern, sound, and energy requirements together when checking the result. A selector that only changes a displayed name will be obvious the moment you fire.

18. Try a version-specific executable patch

For a second project, pick a mechanic controlled directly by compiled code. Follow the same evidence trail, then check whether the change belongs in the executable. Here are a few candidates.

• The player’s movement-speed calculations.

• A weapon cooldown or projectile-count limit.

• Enemy damage calculations.

• Shield regeneration or collision behavior.

• The rules governing enemy targeting.

Those tasks typically require more careful code analysis. Some can be implemented by changing a constant in the Windows executable, while others may require an instruction-level patch or a small code hook.

A possible next agent assignment is:

Using our existing OpenTyrian REA investigation,
find one gameplay mechanic that is controlled by
compiled code rather than an external data table.

Prioritize player movement speed.

Trace the relevant code using REA and Ghidra.
Determine whether a small, verifiable modification
is possible.

Do not assume a constant exists.

If a safe binary patch is feasible, create a
version-specific patcher that verifies the original
instruction bytes, maps analysis addresses to file
offsets correctly, preserves the baseline executable,
and patches only the working copy.

If it cannot be implemented safely, report the
technical reason and suggest another mechanic.

Here, REA’s read_bytes and address_to_file_offset capabilities can be particularly useful.

A Ghidra address identifies a location in the loaded image. To patch an instruction on disk, the agent has to map that address to the executable’s file layout and confirm the original bytes at the mapped offset. Keep the same validation discipline you used for the data file: target a specific build, write to the working copy, and check the diff.

This REA-assisted reconstruction of the DX-Ball game shows how binary analysis, code verification, and real gameplay testing work together.

19. What to keep from your OpenTyrian investigation

A successful run leaves you with a modified game, a reproducible patch, and the evidence needed to check or restore it. Keep these pieces together.

1. The first-look report identifies the executable and the actual Ghidra results returned through REA.

2. The analysis follows the loader and gameplay code to the weapon definitions.

3. The record mapping connects the starting front weapon to the verified Zica Laser behavior.

4. The patcher and manifest show which file bytes changed and how to restore them.

5. The baseline and modified Episode 1 runs let you compare the Pulse-Cannon and Zica Laser’s appearance, firing pattern, and sound.

This is a walkthrough for deriving and testing a patch on your copy. The exact bytes, offsets, and effect on the weapon come from your local analysis and play test. Keep them in the evidence report so you can reproduce the result later.

Choose your next game mechanic to reverse-engineer

Start with a game you know well enough to notice when its rules change. In Tyrian, swapping the starting Pulse-Cannon for the Zica Laser gives you an immediate visual and audible comparison. Keep the original and modified recordings, the patch manifest, and the restore instructions together so you can reproduce that result before trying another mechanic.

For another experiment, trace shield recovery, boss behavior, or the speed of enemy projectiles. Pick one change with an observable result, such as slower enemy shots in the same opening wave. Ask the agent to identify what controls that behavior, keep the original intact, and give you a before-and-after test you can run in a minute.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

Whisper can produce perfectly readable sentences when nobody said anything. Silence, room tone, music, microphone dropouts, and low-level background noise can all trigger invented text. Sometimes it is a short phrase such as “thank you.” Sometimes the model gets stuck repeating the same line for minutes.

Share

Start by detecting non-speech before Whisper decodes it. Add voice activity detection, then disable previous-text conditioning if hallucinations are turning into repetition loops. Treat no_speech_threshold tuning as a secondary defense, because Whisper’s own silence score is not a hard VAD gate.

This applies to OpenAI Whisper, large-v3, large-v3-turbo, faster-whisper, and Whisper-based pipelines. The exact controls differ by implementation.

Quick fix

If you are using faster-whisper, turn on its VAD filter first. If you are using OpenAI Whisper directly, put a dedicated VAD such as Silero in front of it or move the transcription stage to an implementation with VAD support. Then test condition_on_previous_text=False if one bad segment starts contaminating the segments that follow.

Do not make the VAD so aggressive that faint speech disappears. The goal is to stop obvious non-speech from reaching the decoder while retaining quiet voices, clipped syllables, and short utterances.

What Whisper hallucinations during silence actually mean

Whisper is doing more than matching sounds to words. Its decoder predicts text from the audio representation and linguistic context. When the audio contains little useful speech evidence, the model can still find a plausible sequence of tokens.

A September 2026 paper describes how Whisper’s generative decoder can produce fluent transcripts from inputs containing little or no speech. The researchers were able to suppress many of those hallucinations by modifying internal decoder activations, although doing so introduced a trade-off with recognition accuracy and false rejection of real speech.

That trade-off is the reason there is no universal “make Whisper stop hallucinating” slider.

OpenAI Whisper’s built-in silence logic starts with these default transcription settings:

no_speech_threshold = 0.6

logprob_threshold = -1.0

compression_ratio_threshold = 2.4

condition_on_previous_text = True

The important part is the interaction between the first two settings. Whisper does not discard a segment merely because its no-speech probability crosses no_speech_threshold. The decoded output must also have sufficiently low average token probability according to logprob_threshold.

That creates an awkward failure mode. If Whisper produces nonsense that it is relatively confident about, the transcript can survive the no-speech check.

This helps explain why blindly changing no_speech_threshold sometimes does very little.

There is another failure mode layered on top. With condition_on_previous_text=True, output from earlier windows can be fed into later windows as context. That usually helps continuity. Once a bad phrase gets into the context, though, it can encourage another bad phrase, which can encourage another.

That is how a single hallucination can turn into a repetition loop.

In a September 13, 2026 user report, large-v3-turbo generated repeated Chinese phrases during a microphone failure. The reporter said the recording contained no speech during that interval, yet Whisper produced multilingual and corrupted-looking text before repeating the phrase. Normal transcription resumed when the audio returned.

The same basic complaint has been circulating for years. A user running both OpenAI Whisper and whisper.cpp in 2024 described good transcription during speech followed by repeated “thank you” text during silence or muted audio.

The recurring phrases can look strangely specific. That does not prove where any individual phrase originated. The reports are consistent with the explanation above: when acoustic evidence becomes weak, the decoder’s learned text patterns can gain more influence over the output.

Diagnose the cause before changing anything

Do this on a short copy of the troublesome recording rather than repeatedly processing a two-hour meeting.

1. Cut out roughly 30 to 60 seconds containing normal speech, the hallucinated silent or noisy section, and normal speech afterward. Keep the original audio untouched.

2. Run that clip using your current settings and save the segment metadata. For OpenAI Whisper, inspect no_speech_prob, avg_logprob, and compression_ratio alongside the generated text.

3. Run the same clip again with condition_on_previous_text=False. If the first hallucination remains but the long repetition disappears, you have identified a context feedback loop.

4. Run the identical clip with VAD enabled before decoding. If the invented text disappears while real speech remains, non-speech gating is solving the right problem.

5. Finally, run the same clip through another Whisper implementation and one non-Whisper ASR model. This separates an implementation problem from a failure that follows the Whisper model family itself.

For OpenAI Whisper in Python, this diagnostic dump puts the text beside the segment metadata. It assumes model is an initialized OpenAI Whisper model and audio_path points to your test clip. The examples use language="en" for English audio, so use the appropriate language for your recording:

result = model.transcribe(
    audio_path,
    language="en",
    verbose=False,
)
for segment in result["segments"]:
    print(
        segment["start"],
        segment["end"],
        segment["no_speech_prob"],
        segment["avg_logprob"],
        segment["compression_ratio"],
        repr(segment["text"]),
    )

Do not treat any one metadata field as a verdict on whether speech occurred. Compare the audio you can hear with the generated text and the metadata. Look for changes at the point where the failure appears, then check whether those changes recur on the same clip.

Fix the silence before Whisper sees it

Put voice activity detection, or VAD, before the transcription stage. The detector decides which audio contains speech before Whisper gets a chance to turn that audio into words.

faster-whisper has direct Silero VAD integration through vad_filter=True. Its documentation says the normal VAD behavior is deliberately conservative and removes silences longer than 2 seconds. Its VAD implementation currently uses a default speech probability threshold of 0.5, a 2,000 ms minimum silence duration, and 400 ms of speech padding.

For recordings with obvious gaps, faster-whisper’s README shows shortening the minimum silence duration to 500 ms. In Python, with an initialized faster-whisper model, the configuration below combines that adjustment with a speech threshold of 0.5 and previous-text conditioning disabled:

segments, info = model.transcribe(
    "audio.wav",
    language="en",
    vad_filter=True,
    vad_parameters=dict(
        threshold=0.5,
        min_silence_duration_ms=500,
    ),
    condition_on_previous_text=False,
)
segments = list(segments)

Treat 500 as a starting point for a test, not a universal setting. When diagnosing a failure, compare VAD alone and context reset alone before combining them, so you can tell which change helped.

If transcription starts cutting words spoken quietly, focus first on the VAD speech threshold. A lower speech threshold is more permissive, which can retain weak speech but also admits more noise. A higher threshold rejects more questionable audio and therefore increases the chance of deleting genuine low-volume speech.

The minimum silence duration controls when speech regions are separated. It does not turn quiet speech into loud speech.

For long meetings, interviews, and other private recordings, this VAD-first approach fits naturally into a local Whisper transcription workflow. It also keeps silence filtering on your own machine instead of creating another cloud processing stage.

More on running Whisper locally:

Stop one hallucination from becoming twenty

If Whisper generates one bad phrase and then keeps repeating it, test this next:

result = model.transcribe(
    audio_path,
    language="en",
    condition_on_previous_text=False,
    verbose=False,
)

OpenAI Whisper and faster-whisper document the same trade-off: disabling previous-text conditioning can reduce repetition loops and timestamp drift while making text less consistent across windows.

This setting will not stop every hallucination. A silent window can still produce invented text by itself.

It is particularly useful when the failure behaves like a cascade: one strange phrase appears, then the same phrase or related garbage continues after the audio changes.

For long-form transcription, I would rather accept an occasional awkward transition between windows than let one fabricated sentence poison the next five minutes of transcript.

Do not rely on no_speech_threshold as your VAD

The built-in Whisper settings are still useful. They should sit behind proper speech detection rather than carry the whole job.

Lowering no_speech_threshold makes Whisper more willing to classify a window as silence. The catch is in the source code: the decision interacts with logprob_threshold. If the model produces text with high enough token confidence, the segment can be retained despite its no-speech score.

Lower the threshold too far and genuine quiet speech can disappear.

OpenAI Whisper also exposes hallucination_silence_threshold, which can skip longer silent periods when a possible hallucination is detected and word timestamps are enabled. There is no universal threshold documented for every microphone, language, and recording environment.

Use these controls as a second layer. Tune them against recordings that contain both known silence and known quiet speech.

Changing one value at a time is tedious. It is also much more informative than moving three thresholds at once and having no idea which change helped.

Put VAD in front of whisper.cpp

You no longer have to build a separate silence detector around whisper.cpp if its own VAD support fits your workflow.

whisper.cpp supports Silero VAD models through --vad, --vad-model, --vad-threshold, --vad-min-speech-duration-ms, and --vad-min-silence-duration-ms, alongside speech padding and related controls.

From the whisper.cpp repository directory on Linux or macOS, the commands below download the VAD model and run transcription with speech detection enabled. They assume you have already built whisper-cli, downloaded ggml-large-v3-turbo.bin into models/, and prepared audio.wav:

./models/download-vad-model.sh silero-v6.2.0

./build/bin/whisper-cli \
  -m models/ggml-large-v3-turbo.bin \
  -f audio.wav \
  --vad \
  --vad-model models/ggml-silero-v6.2.0.bin \
  --vad-threshold 0.50

That gives you a useful comparison against OpenAI Whisper without changing the underlying Whisper model family.

If OpenAI Whisper hallucinates on your clip while whisper.cpp plus VAD stays empty during the same silence, audio gating is a likely explanation worth testing before attributing the improvement to the runtime itself.

Be careful with audio segmentation

Silence filtering and audio segmentation are related, but they are not the same operation.

For a file, you generally want VAD to identify meaningful speech regions while preserving enough audio around each boundary for words to remain intact. The 400 ms speech padding in faster-whisper’s current VAD defaults is there for a reason.

For live transcription, do not send endless silent 3-second chunks into Whisper and hope the language model decides to say nothing. Detect whether speech is present first. If the current buffer has no speech, an empty transcript is usually the appropriate result.

Avoid chopping every sentence into tiny independent fragments unless your tests show it helps. Whisper benefits from acoustic and linguistic context. Removing long dead zones is useful. Destroying all continuity is a different experiment.

Noise reduction is a second-line fix

A recording can contain no speech without containing digital silence. Air conditioners, traffic, keyboard noise, music, compression artifacts, and a failing microphone can all leave enough energy to confuse simplistic volume thresholds.

A proper VAD is therefore a better first tool than an amplitude cutoff.

Noise reduction can help when persistent background sound keeps triggering the VAD, but test the denoised version against the raw recording. Aggressive processing can also remove parts of quiet speech.

Still getting hallucinations after applying the fixes?

Prevent hallucinations from returning

Treat non-speech handling as part of the transcription pipeline instead of a cleanup script added after a bad transcript reaches your meeting notes.

Keep VAD enabled for long recordings and live input. Reset decoder context after problematic gaps when repetition is an issue. Preserve raw audio long enough to verify important transcript sections. Log enough segment metadata to reproduce failures. Keep a small silence, noise, quiet-speech, and normal-speech regression set.

If you are setting up local Whisper from scratch, Popular AI’s Windows Whisper transcription guide covers the basic local workflow. For a more complete meeting stack with VAD and local summarization, use the private Whisper and Ollama meeting transcription guide.

More on local AI audio transcription:

Privacy, security, and account risk

All of the fixes above can run locally. There is no technical reason to upload a confidential meeting merely to test whether silence filtering works.

⚠️ Be more careful when comparing against hosted transcription services or cloud ASR APIs. A 30-second reproduction clip can still contain names, client details, health information, passwords spoken aloud, or private conversation immediately before and after the failure.

Trim and anonymize test files before sharing them in GitHub reports.

FAQ

Why does Whisper say “thank you” or other phrases during silence?

Because the model can continue generating plausible text when the audio provides weak speech evidence. Certain phrases recur often in user reports, but a specific hallucinated phrase does not by itself prove which training example produced it.

---

Will large-v3-turbo fix silence hallucinations?

No. The September 2026 microphone-failure report used large-v3-turbo, which is good evidence that a larger or newer Whisper checkpoint does not remove this failure mode automatically.

---

Should I lower no_speech_threshold?

Test it, but do not make it your first fix. A lower value makes silence rejection more aggressive and can remove quiet real speech. Whisper’s skip logic also depends on token log probability, so the threshold does not behave like a dedicated VAD.

---

Is faster-whisper less likely to hallucinate?

The underlying Whisper model can still hallucinate. faster-whisper makes the problem easier to control because it has direct Silero VAD support and exposes useful VAD parameters. The improvement comes from the pipeline as much as the runtime.

---

Can noise reduction eliminate Whisper hallucinations?

Sometimes it helps when background noise is fooling the speech detector. It can also damage weak speech. Compare raw and processed audio on the same test clip before making denoising permanent.

---

Conclusion: stop sending non-speech to Whisper

👉 Start with VAD.

▪ If you use faster-whisper, enable vad_filter=True.

▪ If you use whisper.cpp, use its Silero VAD support.

▪ If you use OpenAI Whisper directly, put an external speech detector in front of it.

Then set condition_on_previous_text=False when hallucinations are turning into repetition loops. Tune no_speech_threshold, logprob_threshold, and related controls only after the basic gating works.

When you accomplish a configuration that rejects non-speech while preserving quiet voices on your test clip, keep it. If invented text continues inside genuine speech, move on to the model and runtime comparisons above. Silence filtering has done its job when the decoder receives speech and quiet gaps stay empty.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

An Open WebUI backup needs more than the Export Chats button. A chat JSON file lets you move conversations to another account. Recovering the installation also requires its users, uploaded documents, knowledge-base data, and configuration.

Share

For a typical Docker installation, back up the entire persistent data volume, preserve the deployment settings and original secret key, and test recovery in a separate instance. Do that before updating Open WebUI or moving it to another server.

Quick answer: chat export or full Docker backup?

Use Export Chats for a portable copy of conversations. Use a cold backup of the persistent Docker volume when you need to recover the installation. Keep your Docker Compose file, environment settings, original encryption key, and any external databases or model storage alongside that archive.

Test the restore with a new, empty volume and a second Open WebUI container on a different port. Leave the production volume untouched. Restoring over a populated volume can destroy newer chats and files, so a backup check should never require replacing your live data.

This walkthrough covers a single Docker or Docker Compose instance using SQLite and local file storage. The terminal commands use a Linux/macOS shell, including WSL with Docker available. PostgreSQL, cloud object storage, and distributed deployments need additional backups. Confirm that your installation fits those assumptions before using the single-volume procedure below.

▪ Step 1: Export a portable copy of your chats

In Open WebUI, open your profile menu, then Settings → Data Controls → Export Chats. The downloaded JSON includes conversation messages, model details, timestamps, and chat structure. To import it elsewhere, use Import Chats in the same menu.

Imports add conversations rather than replacing existing ones. Importing the same JSON twice creates duplicates. The export is not a substitute for uploaded file bytes, user accounts, the knowledge-base index, or server settings.

Keep the JSON export as an extra recovery option, especially if you only need to move your personal conversations. For a full server migration, continue with the data-volume backup. Importing chats alone will not recreate the rest of the installation.

▪ Step 2: Find the volume that actually holds your data

Open a terminal on the machine running Open WebUI. Replace open-webui below with the actual container name if yours differs.

docker ps -a --format 'table {{.Names}}\t{{.Image}}'

docker inspect open-webui --format '{{range .Mounts}}{{println .Destination .Type .Name .Source}}{{end}}'

docker inspect open-webui --format '{{.Config.Image}}'

Look for the mount whose destination is /app/backend/data. A named Docker volume will show volume and its actual name, perhaps open-webui or a Compose-generated project prefix such as myapp_open-webui. A bind mount points to a host directory instead.

Use the mount you found on your own machine. A volume name copied from another tutorial may point to entirely different data. Record both the volume name or host path and its destination inside the container before continuing.

For the default SQLite setup, the data folder commonly includes webui.db, uploads/, and vector_db/. Database records without the associated uploads can leave conversations pointing to missing documents.

A running database can also use SQLite write-ahead log files, so stop all processes writing to it before taking a file-level backup.

▪ Step 3: Back up the complete Docker volume

Before stopping Open WebUI, record the image version and save your Compose file, .env file, reverse-proxy configuration, and other deployment settings somewhere private. Keep these with the matching backup so you can recreate the deployment that produced it.

Preserve the original WEBUI_SECRET_KEY. If Docker generated the key automatically, it can live at /app/backend/.webui_secret_key, outside the data volume.

While the original container still exists, copy that file to secure storage if applicable:

mkdir -p "$HOME/openwebui-backups"

docker cp open-webui:/app/backend/.webui_secret_key \
  "$HOME/openwebui-backups/webui-secret-key"

If that file does not exist, check whether your deployment supplies WEBUI_SECRET_KEY through its environment or secrets manager. Do not replace a working key with a newly generated one. Keep backup directories containing keys accessible only to authorized users.

For a named volume, substitute the name discovered in Step 2 and run:

VOLUME="YOUR_ACTUAL_VOLUME_NAME"
BACKUP_DIR="$HOME/openwebui-backups"
ARCHIVE="openwebui-$(date +%Y%m%d-%H%M%S).tar.gz"
IMAGE="$(docker inspect open-webui --format '{{.Config.Image}}')"

docker stop open-webui

docker run --rm -v "$VOLUME:/data:ro" \
  -v "$BACKUP_DIR:/backup" \
  alpine tar -C /data -czf "/backup/$ARCHIVE" .

docker start open-webui

If the backup command fails, start the original container again and investigate before updating. This archives the full data directory, including hidden entries, using the same Docker volume-and-tar approach as the official update procedure.

For a bind mount, stop Open WebUI and archive the real host directory instead:

docker stop open-webui

tar -C /actual/host/data/path \
  -czf "$HOME/openwebui-backups/openwebui-bind.tar.gz" .

docker start open-webui

Use the procedure that matches your mount type. Keep the backup destination outside the data directory you are archiving, whether you use a named volume or a host bind mount.

▪ Step 4: Check the archive before trusting it

Run these commands against the named-volume archive from Step 3:

tar -tzf "$BACKUP_DIR/$ARCHIVE" > /dev/null

tar -tzf "$BACKUP_DIR/$ARCHIVE" \
  | grep -E 'webui.db|uploads/|vector_db/'

ls -lh "$BACKUP_DIR/$ARCHIVE"

A successful first command means the compressed archive can be read. For a standard local setup, expect to find webui.db and, if used, uploads and vector storage.

A readable archive proves that tar can open it. Open WebUI still needs to start from the recovered files and read their contents correctly. Copy the archive and protected configuration to separate storage, preferably another physical device, before the next update.

▪ Step 5: Restore into a disposable Open WebUI installation

⚠️ Do not extract this archive into your existing production volume. The following commands restore it into a fresh volume for an isolated single-instance SQLite test. Check that the test container name and volume name are unused before running them. The target must be empty, even if you have performed a restore check before.

What can still go wrong?

▪ A fresh setup screen or missing chats can mean the Docker volume is wrong or empty. Check the actual volume and its mount destination. If chats return but attachments fail, uploads, vector data, or external storage may be missing. Restore the matching file storage from the same backup point.

▪ Logouts or failed encrypted integrations can indicate that the original secret key was not preserved. Restore the protected original key. Database errors can come from an active SQLite copy or an incompatible schema. Use a cold, pre-update backup and the matching image.

For a permission-denied error after restoring a host bind mount, check ownership against the container’s configured user and correct it to match.

If chats seem to have vanished after a restart, first check whether the new container is attached to the wrong volume. A fresh setup screen does not, by itself, establish that the original database was deleted.

Roll back a failed update without overwriting new data

Keep the original image version, pre-update archive, deployment configuration, and secret together.

If an update runs a database migration, pulling the old image alone may not reverse its schema changes.

Your rollback checklist is:

1. Stop the failed deployment and preserve its current volume.

2. Find the pre-update archive, original image version, and matching secret key.

3. Restore that archive into another empty volume and recreate the previous Open WebUI version against it.

4. Verify chats, uploaded files, and settings before directing users to the restored instance.

Compare any conversations created after the backup before choosing which state to keep. Never extract an older archive over a live volume containing newer data.

Ollama models in a separate volume, an external PostgreSQL database, object storage, and remote vector databases are outside this single-volume procedure. Back them up independently and restore the connected services consistently.

Keep a restorable Open WebUI backup before the next update

Keeping an Open WebUI archive on the same disk as the only copy of your chats leaves both copies exposed to the same disk failure.

Before the next update, confirm that you have a chat JSON export, a readable full-data archive, the preserved deployment settings and original secret, and a restore procedure that runs in a separate volume. The archive, configuration, and key should describe the same installation and backup point.

Repeat the restore test after major storage or version changes. Use Popular AI’s local AI guide when planning the wider self-hosted setup, then make this backup and recovery check part of every Open WebUI update.

More on local AI:

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

You ask ChatGPT for an image for a blog post, presentation, or creative project. The brief describes the scene, setting, and people. The result changes the casting anyway. You clarify your instructions, render again, and spend another round correcting a decision you never asked the tool to make.

Share

ChatGPT image bias can turn a powerful creative tool into a frustrating production bottleneck. Providers have documented demographic interventions, and automatic prompt rewriting can introduce details before an image is rendered. The practical response is to approve concepts first, inspect actual rewrites where available, and keep a rendering path that gives you more control.

The evidence in this article spans several generations of image tools. Historical instructions explain how these interventions have worked, while current documentation helps identify which parts of today’s workflow you can inspect or change. Neither a bad image nor a chatbot’s explanation, by itself, reveals the cause.

Diversity interventions are documented

On July 18, 2022, OpenAI announced a system-level intervention for DALL·E 2 requests describing people without specifying race or gender. Its stated purpose was to produce results reflecting the diversity of the world’s population.

That was an intentional demographic adjustment. Leaving an attribute unspecified did not mean the system would leave the choice entirely to the underlying model.

The choices could be surprisingly prescriptive. In a February 2024 account of extracted GPT-4 instructions, Vincent Conitzer and Derek Leben described instructions Leben had obtained in December 2023. They directed image descriptions to specify gender and ancestry, assigning different ancestries with “EQUAL probability.”

The authors also reported that the rule disappeared from the system instructions the following month. That account indicates a historical implementation. It does not necessarily prove that prompts are altered behind the scenes today.

Equal probability across selected ancestry labels is a policy choice. It cannot simultaneously reproduce the demographic makeup of every country, profession, historical setting, and publication’s subject matter.

OpenAI later acknowledged the contextual limits. Its March 2025 image-generation system card said demographic choices might not match particular cultural or geographic populations. It also said explicit user preferences should be followed. The objective was a broader range of representations rather than exclusive reliance on the most common demographics.

Those goals become a product defect when they override the context that makes an image useful.

What users have actually reported

The complaints extend beyond abstract arguments about representation:

• Storyboarding: In a July 2022 OpenAI developer-forum discussion, user daveshapautomator described ethnicity changing between character images. They planned to add ethnicity and gender considerations to their prompt-writing tool. The workaround became extra production machinery.

• Children making pizza: In a January 2024 DALL·E 3 API thread, a developer shared a request about a child named Kate cooking with friends. The reported rewrite assigned the children Caucasian, Hispanic, South Asian, Black, and Middle Eastern identities. The developer asked whether ethnicity could remain unspecified.

• Historical illustrations: In a September 19, 2025 Adobe Firefly complaint, user abpositive reported unwanted demographic mixtures despite explicit instructions for historical and sociological illustrations. A community expert acknowledged similar experiences and suggested more detailed ethnicity prompts.

These are user reports rather than controlled audits of current products. They document a recurring complaint: the service adds or changes casting, then users must spend time directing it back.

Google, however, offered a stronger admission. On February 23, 2024, the company explained why it had paused Gemini’s generation of people. Tuning intended to show a range of people had failed to accommodate contexts where that range was inappropriate. Excessive caution also caused refusals of harmless requests. Google described the resulting images as “embarrassing and wrong.”

The diversity objective had outrun the brief.

Why a better model can become a worse tool

Three mechanisms can affect your result: the assistant’s expansion of the brief, the image model’s learned defaults, and the provider’s policy controls. Our examination of ChatGPT’s persistent yellow image cast describes the same practical problem with a different unwanted default. Users encounter the combined behavior of a product pipeline.

OpenAI’s Responses API automatically revises image prompts and exposes the resulting text through a revised_prompt field. An unrequested person or demographic description can therefore enter before rendering begins.

Rewriting can help a vague request. It can also sabotage a precise one. A study summarized by Microsoft Research in July 2024 involved 1,891 participants and more than 18,000 prompts. On a task requiring participants to reproduce target images, automatic prompt revision reduced DALL·E 3’s measured advantage over DALL·E 2 by 58%.

That statistic measures lost improvement on that task, not a 58% productivity loss caused by diversity rules. The research’s January 2026 revision likewise describes task-dependent benefits and harms from rewriting. Aligned rewrites can help. Misaligned ones can undermine gains from a better model.

For commercial work, accepted images per hour are a more useful measure than visual polish alone. A technically impressive render that needs repeated correction still misses the deadline.

The provider chooses the representation objective. The illustrator, publisher, or small business absorbs the correction work. Politically preferred casting becomes especially intrusive when presented as a neutral improvement that requires no user approval.

Repeated women in one workflow do not establish a universal female quota. OpenAI’s 2025 evaluation still predominantly produced male subjects. Its September 2026 Images 2.5 system card supplies no equivalent gender breakdown. Diagnose the behavior you can observe instead of relying on a chatbot’s explanation of its own motives.

How to reduce unwanted ChatGPT image bias

The following are workflow recommendations, not guaranteed overrides of provider controls.

1. Set conditions without forcing a human subject (paid subscribers only)

2. Review concepts before paying to render them (paid subscribers only)

3. Inspect the actual rewrite where available

For an API application, log the original request and the returned revised_prompt. Compare the people, setting, identities, and visual emphasis. Asking the chatbot to use your words verbatim is a request, not proof that no transformation occurred.

▪ If the rewrite introduces the unwanted detail, you have identified an upstream contributor.

▪ If it doesn’t, investigate model defaults, references, and conversation context. A description the chatbot reconstructs afterward is weaker evidence than an actual logged tool request.

Use a small repeatable test set spanning your normal assignments. Record the model, date, prompts, outputs, and rejection reasons. Compare fresh conversations with your production setup. Three variations from one brainstorm may repeat one casting decision, so test unrelated briefs too.

Keep the acceptance criteria specific to the job. A recurring character needs a stable appearance. A historical illustration needs the requested setting and identities. An editorial concept may work better without people. Record which requirement failed instead of treating every rejected image as evidence of the same cause.

4. Remove the conversational rewrite when practical

For current GPT Image models, developers can send approved descriptions through OpenAI’s direct Image API using images.generate, rather than asking a conversational model to compose a Responses API image-tool call. This removes that particular mainline-model rewriting step from your application architecture.

The image model’s training, defaults, and provider controls remain. Prompts and outputs are still filtered. The API’s moderation setting controls filtering strictness. It is not a documented demographic-bias switch.

For existing photos, use references and targeted edits rather than redescribing the entire scene. OpenAI supports reference-image and masked editing, with masks serving as guidance rather than guaranteed boundaries. Inspect the untouched regions too.

5. Keep a different rendering path

A local workflow gives you more architectural control. In ComfyUI’s basic text-to-image workflow, visible prompt nodes supply the conditioning used for generation. A fully local workflow without an added language-model enhancer avoids a hosted chatbot rewriting your brief.

Choose the checkpoint and workflow deliberately. Local models still have learned biases, licenses, hardware requirements, and weaknesses. Negative-prompt support varies by model. Cloud API nodes also remain cloud services, even inside a local interface.

Keep the working model files, workflow, settings, and approved prompts together. Expect maintenance: our guide to why ComfyUI updates break workflows explains the version and dependency problems that come with that control.

Try the alternative on the same briefs you already use. Compare the correction work as well as the initial output. A fallback earns its place when it reliably produces usable images for your assignments, with setup and maintenance costs you can accept.

More on ComfyUI:

Your image brief should remain yours

Reducing repetitive stereotypes can improve a generator. Overriding a historically specific scene or turning an open brainstorm into predetermined casting can make it worse.

A more useful product would expose substantive rewrites, preserve context, and let users choose representation preferences without forcing a human subject into every idea. Unspecified details are creative room, not blanket consent to a company’s social agenda.

For now, preserve that room with conditional instructions, approve concepts before rendering, inspect real prompts when possible, and keep another rendering path available. A productivity tool should earn its place by reducing your work, including the work of correcting its priorities.

More on AI image generation:

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

A DIY AI bird feeder can photograph garden visitors, predict their species, and keep a searchable record without a wildlife-camera subscription. A Raspberry Pi, an AI Camera, and a local bird-classification model handle the work. Disable the project’s optional hosted fallback, and identification can stay on your own hardware.

Share

Developer Renan Fernandes has already demonstrated the idea with TitPi, a Raspberry Pi bird feeder project with published source code. His setup watches a feeder through a window, detects approaching birds, identifies likely species, and displays the results on a local dashboard.

The build uses a Pi Zero 2 W rather than a larger AI computer. Its camera handles the first detection stage, leaving the Pi to classify photographs, save visits, and serve the dashboard.

How the DIY AI bird feeder works

TitPi uses a Raspberry Pi Zero 2 W connected to a Sony IMX500 AI Camera. The camera performs the initial object detection, while the Raspberry Pi handles photographs, species classification, and the visitor database.

▪ The Raspberry Pi AI Camera runs neural networks on its imaging sensor. That reduces the work required from the Pi’s processor. Detecting a bird on the sensor and identifying its species on the Pi are different jobs, so the camera’s accelerator does not remove the need for the local classification model.

▪ Detection and species identification are separate stages. First, the camera detects an object that appears to be a bird. It looks for a change in detection confidence and triggers a photograph when that change is sustained.

Second, a TensorFlow Lite model examines the image and predicts the bird’s species.

▪ Species identification is the harder task. Recognizing an object as a bird is relatively straightforward compared with distinguishing a female house finch from a purple finch, especially when the photograph is blurry or poorly lit.

TitPi also includes an optional hosted-model fallback for uncertain identifications. We’ll disable that component to keep the identification process local.

The finished system can save photographs, record visits in SQLite, and display recent activity through a browser. No commercial wildlife-monitoring account is required.

What you need to build the AI bird feeder

Start with the hardware used by TitPi itself. The AI Camera already contains inference hardware, so this setup doesn’t need a separate AI accelerator. Keeping the hardware close to the project’s documented combination also gives you fewer differences to investigate if installation fails.

The U.S. retailer prices below were checked at time of publication. Prices and availability can change. They are component prices, so leave room in the budget for the parts that make the camera usable beside a window.

▪ The Raspberry Pi Zero 2 W runs the camera software, local classifier, database, and dashboard.

Its 512 MB of RAM keeps the board inexpensive but limits the resources available to those jobs. PiShop US lists the Raspberry Pi Zero 2 W at $17.25.

▪ The Raspberry Pi AI Camera (IMX500) handles object detection directly on the camera sensor.

Its inference hardware avoids the need for an additional AI HAT or USB accelerator. PiShop US lists the Raspberry Pi AI Camera at $74.95, in stock.

You will also need a 32 GB or larger microSD card, a reliable 5V micro-USB power supply, a camera mount, and a feeder positioned close enough to capture clear photographs.

Pay attention to the ribbon cable. The Pi Zero’s camera connector is the smaller 22-pin type. Use a compatible standard-to-mini cable rather than assuming a cable from an older Raspberry Pi will fit.

The hardware can remain indoors, looking through a clean window toward an outdoor feeder. This avoids building a weatherproof electronics enclosure.

Step 1: Install Raspberry Pi OS

Start with a fresh microSD card and Raspberry Pi Imager.

TitPi documents Raspberry Pi OS Bookworm 64-bit. As of October 2026, Bookworm is available as Raspberry Pi OS Legacy, while newer Raspberry Pi OS releases use Trixie. Use Legacy Bookworm 64-bit Lite for the closest match to the project’s documented setup.

In Raspberry Pi Imager, configure the hostname as titpi, create the username titpi with a strong password, add your Wi-Fi credentials, and enable SSH.

After flashing the card, insert it into the Raspberry Pi, connect the camera ribbon with the power disconnected, and boot the board.

Open a terminal on your computer and connect:

ssh titpi@titpi.local

Once connected, update the operating system and install the camera dependencies:

sudo apt update
sudo apt full-upgrade -y

sudo apt install -y \
  git python3-venv \
  imx500-all python3-picamera2 \
  python3-flask python3-requests \
  python3-pil python3-numpy ffmpeg

sudo reboot

The initial AI Camera firmware load may take several minutes. Allow that first load to finish before treating the delay as an installation failure. The camera test below gives you a separate checkpoint before TitPi and its classifier enter the picture.

After reconnecting, confirm the camera works by capturing a photograph:

rpicam-still -o test.jpg -t 2000

Check that test.jpg exists before installing the bird-identification software.

Step 2: Download and configure TitPi

Download the TitPi source code to the directory expected by its service files:

git clone https://github.com/renanfernandes/titpi.git \
  /home/titpi/titpi

cd /home/titpi/titpi

cp config_example.json config.json

Create a Python virtual environment that can still access the camera libraries installed through Raspberry Pi OS:

python3 -m venv --system-site-packages .venv

.venv/bin/python -m pip install ai-edge-litert

This avoids installing Python packages into the operating system with --break-system-packages.

The published source also has an import that needs correcting. The checked-in watcher.py imports notifier_lcd, but that file is excluded from the repository. The regular notification module is available.

Correct the import:

sed -i \
  's/from notifier_lcd import send_detection_email/from notifier import send_detection_email/' \
  watcher.py

This allows the watcher to use the supplied notification module. Email alerts remain optional.

Step 3: Install the local bird-identification model

TitPi’s species classifier uses Google’s AIY Birds V1 model, which supports roughly 964 bird species.

The source repository includes the species-label files but excludes the .tflite model itself. You must supply it separately.

Google’s AIY bird-classification model is available through Kaggle. TensorFlow’s published documentation also provides this download command:

cd /home/titpi/titpi

curl -fL --retry 3 \
  'https://tfhub.dev/google/lite-model/aiy/vision/classifier/birds_V1/3?lite-format=tflite' \
  -o aiy_birds_v1.tflite

The legacy TensorFlow Hub download endpoint could not be independently confirmed as working during this review. If it fails or downloads an HTML page, use the official Kaggle model download instead and save the model as aiy_birds_v1.tflite.

Check that the downloaded file is a genuine TensorFlow Lite model before proceeding:

python3 -c '
with open("aiy_birds_v1.tflite", "rb") as f:
    f.seek(4)
    assert f.read(4) == b"TFL3", "Invalid TFLite file"
print("Model header OK")
'

The expected result is Model header OK. That confirms the file format, although it doesn’t prove the model will load or produce accurate predictions.

Keep the model and TitPi’s label files together in /home/titpi/titpi/.

Step 4: Disable cloud identification

TitPi can identify birds locally, but its optional fallback changes where uncertain photographs are processed. Check this configuration before leaving the watcher running.

The TitPi identification code tries local classification first. When the confidence is too low, it can send the photograph to a hosted model through GitHub Models if a token is configured.

For a local-only build, leave the GitHub token empty and keep the local classifier enabled.

Edit config.json:

nano config.json

Make sure the corresponding sections contain these values:

"github": {
  "token": "",
  "model": "",
  "identify_all": false
},
"local_classifier": {
  "enabled": true,
  "min_confidence": 0.3
}

Keep the existing camera settings intact. Change target_labels to ["bird"] if you only want bird detections.

With no GitHub token, the code does not invoke the hosted fallback. An uncertain bird may consequently be left unidentified or discarded. For this build, accepting an unidentified visit preserves the reason for choosing local identification in the first place. A species label is optional. Keeping photographs off a hosted identification service is the requirement.

Step 5: Start the watcher and dashboard

Before activating the background services, make their Python paths point to the virtual environment:

sed -i \
  's#/usr/bin/python3#/home/titpi/titpi/.venv/bin/python3#' \
  services/titpi.service services/titpi-web.service

Install the two services:

sudo cp services/titpi.service \
  services/titpi-web.service /etc/systemd/system/

sudo systemctl daemon-reload

sudo systemctl enable --now \
  titpi.service titpi-web.service

To inspect the watcher:

sudo journalctl -u titpi.service -n 50 --no-pager

Look for camera initialization followed by Watcher Active. If the service crashes, the journal output is the first place to look.

The dashboard should now be available at:

http://titpi.local:8080

The dashboard will initially be empty. Wait for the camera to record detections before expecting species records or visitor activity to appear. An empty page at this stage does not, by itself, show that identification has failed.

Once birds start visiting, the application can display photographs, species names, activity charts, and recent detections.

Step 6: Check whether the system identifies birds correctly

▪ Start by aiming the camera so visiting birds occupy a substantial part of the image. Small birds against a large background give the classifier less useful visual information.

TitPi’s current classification script resizes the photograph for the AIY model. It does not independently guarantee a tight crop around every detected bird.

That limits accuracy when birds are far away. A working detector can therefore trigger photographs while the species classifier still receives too little bird detail to make a useful prediction. Check the saved image before assuming the model needs replacing.

▪ For a useful first evaluation, collect 20–30 manually identifiable photographs and compare the predictions against your own observations.

Record four outcomes: correct species, incorrect species, bird present but unidentified, and false detection.

A confidence score is the model’s estimate. It is not a guarantee of accuracy. A prediction of 80% does not establish that the identification is correct.

Look for mistakes involving similar species, juvenile plumage, shadows, and birds facing away from the camera. Correct obvious errors through the dashboard rather than treating every AI-generated label as a verified wildlife observation.

Step 7: Test that identification really works offline

Leave the Raspberry Pi connected to your local Wi-Fi but block its internet access through your router. That preserves access to the local dashboard.

Then observe the feeder and check the watcher logs.

If the camera detects birds and new species records appear while external internet access is blocked, you have demonstrated that the essential detection, classification, and logging path works locally.

A stronger check uses the router’s connection logs to confirm no successful outbound requests were made during the test.

A dashboard on your local network still needs sensible access limits. TitPi’s Flask application listens on the local network without built-in user authentication. Don’t forward port 8080 through your router or expose it directly to the public internet.

Common problems and how to fix them

The camera works, but no birds are detected

Confirm that the configured IMX500 model exists in /usr/share/imx500-models/. Check the camera ribbon and look for IMX500 initialization errors in the service journal.

The detector may also be struggling with distance, glare, or the camera angle. Bring the feeder closer before changing sensitivity thresholds.

---

Bird detections appear, but species names are missing

Check that aiy_birds_v1.tflite is present and that the local classification runtime loads correctly. Inspect journalctl for errors mentioning the classifier.

If the model isn’t available, the fully offline configuration has no hosted fallback to rescue the identification.

---

The system misses short visits

Decrease the confirmation-frame requirement cautiously and review the cooldown setting.

Both controls reduce repeated or accidental detections, but aggressive settings can miss birds that land and leave quickly.

---

Photographs are poor through the window

Move the camera closer to the glass, avoid reflections from indoor lights, and adjust its position so the bird is clearly visible.

Better photographs are usually more valuable than changing recognition models immediately.

---

Build a local AI bird feeder you can check and improve

A Raspberry Pi AI bird feeder is worth building if you want to experiment with wildlife observation and local computer vision. The IMX500 provides a useful introduction to running object detection on inexpensive hardware, and TitPi adds a practical local dashboard.

Other projects demonstrate different approaches. BirdNET-Pi identifies birds from sound rather than photographs, while Bird Feeder AI uses a Raspberry Pi 5 with a Hailo accelerator for a more demanding camera pipeline.

The simpler IMX500 approach is a sensible place to begin for this camera-based project. You can produce a useful local record of visiting birds without maintaining a large AI computer or paying for image-analysis requests.

There is also room to experiment with other household camera projects. Our DIY AI refrigerator camera guide shows another way to turn inexpensive camera hardware into a practical computer-vision system.

Start with the camera, local classifier, and dashboard. Once you can consistently recognize common visitors, improve the camera position and use your corrected photographs to judge whether the AI is actually doing its job.

More on AI camera applications:

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

For the freelancers helping train AI systems, access to paid work can come with identity checks and screen monitoring. Five European privacy complaints against Scale AI’s Outlier platform challenge how much information the company collects about those workers, and whether it has lawful grounds to collect it.

Share

On October 27, 2026, privacy group noyb filed five GDPR complaints in France, Italy, the Netherlands, and Austria. Scale AI rejected the allegations on October 28, saying its practices are disclosed and contributors agree to them. Regulators have not established wrongdoing.

However, the dispute raises a practical question for anyone earning money through an AI training platform: how much information does a company need to verify freelance work, and how much choice remains when refusing a check can mean losing access to paid tasks?

What the complaints say Outlier collects

Outlier contributors write prompts, evaluate model responses, and perform other tasks used to develop AI systems. Noyb says the platform has more than 900,000 freelance contributors. That figure describes the platform’s reported scale. It does not establish how many workers were allegedly monitored or represented in the five complaints.

The complaints raise three separate concerns. First, noyb alleges that third-party trackers associated with services including TikTok, LinkedIn, Facebook, Sprig, and Datadog send information such as IP addresses, identifiers, and page details while contributors use Outlier.

Researchers identified as many as 19 trackers and described activity records that could be reconstructed into a replay of a work session, Reuters reported. Those are researchers’ findings and allegations, rather than an independently established account of every contributor’s experience.

Second, workers allegedly face repeated identity verification through Persona, including government-ID images and facial video. Third, noyb says four contributors sought access to their personal data and received no answer. Scale disputes the complaints as a whole.

These allegations concern different methods of collecting data. Advertising and analytics trackers operate differently from an application deliberately recording a work screen. A facial identity check raises further questions about biometric information. Treating all three as a single monitoring system would obscure what each collects and which legal justification applies.

What Outlier’s published policies acknowledge

Outlier’s March 2026 privacy policy states that Scale may collect identification documents, selfies, facial measurements, activity records, device identifiers, and information obtained through cookies and pixel tags. It names Persona as an identity-verification provider and says verification data can be retained for up to two years after a contributor’s last interaction, subject to legal requirements. The policy also describes sharing personal information with social-media and advertising networks for marketing purposes.

A separate screen-monitoring notice dated August 19, 2026 says monitored projects can take screen images approximately once per minute and, in some circumstances, record video. Captures can include other tabs, notifications, personal content, or information about third parties. Scale says ordinary screen captures are deleted after seven days unless selected for an investigation, while screen video can be retained for 90 days, subject to stated exceptions.

Scale says this monitoring tool cannot capture webcam footage, microphone audio, or keystrokes outside what is visible on the screen. The notice also says automated detections can lead to account suspension or withheld payment, potentially on a single capture in severe cases.

The screen-monitoring notice governs that particular tool. Its stated limits do not establish what the disputed third-party web trackers collect, or whether those trackers operate under the same restrictions. Likewise, the tool’s exclusion of webcam footage does not describe Persona’s separate facial verification process.

In its response reported by Reuters, Scale said verification and monitoring protect against fraud, preserve client confidentiality, and ensure accurate payments. It said contributors manually activate the screen-recording tool on applicable projects. Scale also said it neither sells contributors’ personal data nor uses that information to train customers’ AI models.

Can consent be meaningful when payment depends on it?

Scale’s own documentation complicates the consent argument. Although its public response emphasizes workers agreeing to its practices, the screen-monitoring notice explicitly says Scale does not rely on GDPR consent for screen monitoring. Instead, it invokes legitimate interests under Article 6(1)(f). The browser’s screen-sharing prompt provides technical permission to capture the selected screen or window. Scale does not treat that prompt as legal consent to process the data.

The same notice says contributors can refuse monitoring, but then cannot start or continue paid sessions on projects that require it. Scale says refusing does not remove them from Outlier or prevent work on unmonitored projects. A contributor can therefore decline the monitoring while losing access to the paid session that requires it.

The European Commission’s GDPR guidance says consent must be freely given, while legitimate interests require weighing business needs against individuals’ rights. Fraud prevention may justify some checks. It does not automatically justify every tracker, repeated face scan, or data transfer. Biometric processing used for unique identification can face additional requirements under GDPR Article 9.

Telling workers about surveillance does not, by itself, establish that the collection is necessary or lawful. Regulators will have to assess the specific processing operations and the legal grounds claimed for each, rather than accept or reject every form of tracking together.

What Outlier workers can do now

For contributors on monitored projects, the immediate privacy step is to separate work from personal activity. Close personal tabs and notifications before sharing a window or screen. Doing so reduces incidental exposure, but it cannot resolve the legality of background trackers or identity checks. The precautions address what can appear in a screen capture.

European contributors can request access to the data Outlier holds about them, including verification information, monitoring records, recipients, retention periods, and information about automated decisions. Outlier lists privacy@scale.com for monitoring requests and privacy@outlier.ai in its general privacy policy.

Workers can also object to processing based on legitimate interests and complain to their national data-protection authority. Access requests should ordinarily receive a response within one month, according to EU guidance. None of these rights guarantees an immediate outcome in a disputed case.

Scale AI’s privacy case turns on necessity

A platform can have legitimate reasons to prevent fraud and protect sensitive client material while still collecting more worker information than necessary. The five complaints ask regulators to decide where that line falls for Outlier’s tracking and identity checks.

Until those questions are resolved, neither Scale’s denial nor noyb’s allegations amount to a verdict. For workers, the immediate steps are concrete: reduce what can appear in screen captures, request the records held about them, and use the available objection and complaint channels to challenge disputed processing.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

No. Immich does not need a dedicated GPU for private AI photo search. For most home libraries, start with the CPU already running your NAS or mini PC. A supported Intel integrated GPU can take work off that CPU. NVIDIA acceleration becomes attractive when you repeatedly process large imports or run other GPU-heavy services.

Share

The expensive mistake is buying hardware to accelerate an indexing job that mostly happens once. Even a modest card such as the MSI RTX 3050 LP 6GB needs a recurring workload to justify its cost.

Disclosure: Popular AI may earn a commission if you buy through some links in this article. That does not change our recommendations.

Quick verdict: which hardware does Immich need?

Buy nothing: Start with an existing four-core CPU, sufficient RAM and the ordinary Immich machine-learning container. A slow initial import can be acceptable if daily searches work well afterward.

Use Intel graphics: If your always-on server already has compatible Intel integrated graphics, try OpenVINO before replacing the machine. Buy an Intel mini PC when you need a new server, because an iGPU alone does not guarantee faster search.

Add NVIDIA only for a sustained bottleneck: CUDA is the more dependable acceleration route for large recurring imports, shared servers and machines already equipped with a GPU. Consider an MSI RTX 3050 LP 6GB only if that workload justifies a purchase. A spare gaming PC can handle remote jobs, provided you plan for when it’s off.

What Immich actually asks the hardware to do

Immich’s Smart Search uses CLIP-style embeddings to match descriptions such as “dog on a snowy beach” with photos. During initial indexing, machine learning processes image previews and saves searchable representations in the database. Later uploads need the same treatment.

▪ Face detection is another machine-learning job, while matching and grouping already detected faces involves the Immich server and database.

An ordinary search still needs machine learning. The words you type must be encoded into a compatible embedding before Immich can search its existing image vectors. Processing all your photos in advance does not eliminate that query-time work.

A fast GPU can therefore finish the initial photo processing much sooner without producing a corresponding improvement in everyday search responsiveness. Model loading, CPU resources, storage and the chosen search model still affect the experience. Judge the upgrade by the operation you actually find slow.

Immich’s performance advice separates throughput from latency. Increasing job concurrency can improve throughput, or the number of assets processed over time. It does not automatically reduce latency, or the time required to answer a search query. Raising concurrency also consumes more memory and can overwhelm a modest server.

Think about the library in two phases. If you import 5,000 photos once and then add a handful a day, there’s little reason to optimize for peak indexing speed. If you ingest tens of thousands of new files regularly, share the machine with other containers or repeatedly rebuild indexes, acceleration becomes more compelling. These are workload examples, not benchmark-derived thresholds.

Separate machine learning from video encoding, too. Intel Quick Sync and NVIDIA NVENC are relevant to hardware video transcoding, which is a different configuration and workload. Working hardware transcoding does not establish that Immich’s OpenVINO or CUDA machine-learning backend is configured correctly.

How these Immich hardware choices were evaluated

The baseline comes from Immich’s installation requirements, machine-learning documentation and October 2026 release notes. Hardware examples were checked against manufacturer configurations and U.S. listings on October 29, 2026. The comparison emphasizes always-on availability, software support, RAM, upgrade cost, power and the difference between batch indexing and interactive queries.

There is no controlled, cross-platform Immich benchmark here establishing how much faster a specific Intel mini PC or RTX card will index the same library than an existing CPU.

In a 2024 comparison of OpenVINO and CPU processing, one i5-10500 owner reported around two assets per five seconds at two concurrent jobs using either Intel UHD 630 graphics or the CPU.

Three practical configurations for Immich

1. Existing CPU-only NAS or office PC: the starting point for most people

Immich’s minimum requirements are two CPU cores and 6GB RAM, with four cores and 8GB recommended. Those figures apply to the server, without promising quick initial indexing. For a machine running NAS services, containers and the database alongside Immich, 16GB gives useful breathing room if you already have it.

A relatively recent Intel Core i5 or AMD Ryzen machine can be a reasonable CPU-only host. Put the Postgres database on a local SSD, as Immich recommends, rather than a network-mounted database directory. Keep originals on appropriate NAS storage, maintain a separate backup and leave space for generated thumbnails and video derivatives.

Check older bargain hardware carefully. Immich 3’s x86 machine-learning image requires the x86-64-v2 instruction level. An ancient processor might boot Linux and Docker but fail at the machine-learning container. Buying a GPU does not automatically fix that CPU compatibility problem.

If you have no usable server, a refurbished office mini PC is one low-cost route. A Dell OptiPlex 7060 Micro with an i5-8500T, 16GB RAM and 256GB SSD appeared on a U.S. refurbished listing at $229.95 at the time of publication.

Verify the power adapter, storage, seller condition and warranty because refurb listings vary. The Dell works as an always-on compute node, rather than a box for several internal photo drives. A complete system at that price can make more sense than adding a GPU to a very old NAS, especially when the older machine also lacks RAM or suitable database storage.

Before spending even that, reduce competing work. Immich recommends lowering job concurrency to one during a difficult initial import and limiting transcoding threads if necessary. The backlog will take longer, but the server should remain usable. A completed index does not need to be regenerated simply because you later enable acceleration.

2. Intel OpenVINO: useful when a new compact server is already justified

Immich supports OpenVINO acceleration for Intel graphics, including Iris Xe and Arc. OpenVINO can reduce CPU load on supported hardware, although integrated GPUs, especially older ones, are more likely to encounter driver or memory problems. Immich also warns that OpenVINO can use more system RAM than CPU processing.

Check which Intel graphics unit you’re getting. A basic N150 mini PC has a much smaller graphics subsystem than higher-end Iris Xe or Arc-equipped hardware. The presence of an Intel GPU, Quick Sync or an advertised NPU does not promise a particular Immich speedup. The OpenVINO container, supported graphics driver, Linux kernel and device access must all work together.

For a concrete always-on option, the Beelink EQ14 N150 with 16GB DDR4, a 500GB SSD and dual 2.5GbE ports was listed for $385 by Beelink’s U.S. store. That configuration was marked preorder. It has a four-core N150 and 24-execution-unit Intel UHD Graphics.

Its 16GB memory ceiling limits future expansion, and the tiny chassis cannot accept a normal desktop graphics card. The EQ14 is worth considering if you need a compact NAS companion anyway. It’s a poor $385 purchase just to find out whether OpenVINO processes photos faster than your current CPU.

If you already own an Intel-based server, try the supported OpenVINO machine-learning image and confirm the GPU is actually being used. Compare the same kind of processing work before deciding whether to keep it enabled. If the work takes roughly the same time, return to CPU inference instead of spending more to chase a theoretical acceleration advantage.

3. NVIDIA CUDA: for repeated heavy machine-learning jobs

Immich’s CUDA backend is its most reliable acceleration option for model compatibility. It still requires supported NVIDIA drivers and, on native Linux, the NVIDIA Container Toolkit. The documented requirements specify CUDA compute capability 5.2 or higher and driver version 545 or newer. VRAM and model choice can impose further limits.

For a desktop with a spare expansion slot, the MSI GeForce RTX 3050 LP 6G OC at a listed $279.99 is a modest example. It has 6GB GDDR6, a 70W board-power rating, a low-profile bracket and a two-slot cooler.

The card needs an appropriate PCIe slot, clearance, ventilation and power supply. It will not fit inside the typical tiny N150 mini PC or Dell Micro chassis. “Low profile” does not make a desktop expansion card compatible with a sealed mini PC.

You can check the exact MSI RTX 3050 LP 6GB model on Amazon. At the manufacturer’s $279.99 listed price, buying one solely to speed up occasional Immich imports is difficult to defend. The purchase needs to save you time often enough to justify adding hardware and another acceleration setup to maintain.

Find RTX 3050 LP 6GB deals on Amazon

Newer RTX 50-series cards, higher-VRAM NVIDIA workstation boards and used RTX 3060/4060-class cards can also run relevant CUDA workloads where supported. Their extra cost or power needs justification from a broader AI workload. More VRAM is not a reason by itself to replace hardware that already handles your photo library.

AMD GPUs with ROCm and certain ARM/Rockchip accelerators are also supported Immich backends. They are legitimate paths for machines you already own, but ROCm driver coverage, image size and idle behavior complicate a fresh hardware purchase. Multi-GPU systems and premium workstation cards add cost without a convincing Immich-only case.

Before upgrading, use Immich’s newer ML optimizations

The October 7, 2026 release of Immich 3.3.0 introduced machine-learning improvements for CPU and GPU backends. The team says the optimized models use less memory and often process work faster, although gains differ by backend and model.

The release also addresses some previous OpenVINO output problems and adds TensorRT RTX optimizations for NVIDIA Ampere/RTX 30-series and later hardware. These changes give existing hardware another chance before you judge it too slow.

For improvements that rely on the new optimized models, configure MACHINE_LEARNING_MODEL_REVISION=v2 on the machine-learning service. Immich says this revision produces numerically equivalent model outputs, so existing jobs do not need to be rerun. The first model load may take longer while optimization artifacts are prepared and cached.

Update compatible server and machine-learning containers together, then observe the real workload before shopping for an upgrade. Allow that first-load preparation to finish before judging the day-to-day experience.

Remote machine learning: what happens when the GPU PC is off?

Remote processing is a middle ground for a weak NAS and a gaming computer you already own. Immich can run its machine-learning container on another computer, with the main server sending image previews to it for processing.

This moves Smart Search and face-detection inference. Database work and subsequent face grouping remain on the primary server, so the NAS still has work to do.

Search terms require machine-learning inference too. In a 2026 report of Smart Search failing when a remote PC was off, an owner of an older HP MicroServer found that newly indexed photos remained in Immich while text searches failed. The previews had been processed, but the query could no longer be converted into an embedding.

Add the remote machine-learning URL while retaining the local container as fallback, instead of replacing the local endpoint. Immich tries configured URLs sequentially, allowing the slower CPU to answer queries when the gaming PC is unavailable. A fast indexing machine is less useful if shutting it down also removes everyday search.

The catch is that new uploads may then get processed on the weak NAS while the powerful machine is off. There is no built-in policy routing only large background jobs to the GPU and small interactive searches to the CPU. If you use only the remote endpoint, failed jobs can require manual retries through Job Status after it returns.

A remote ML container receives image previews and has no built-in authentication protection. Keep it on a trusted local network or behind a private VPN, never expose its port to the public internet, and keep remote and server versions aligned.

Turning on a second PC around the clock just for Immich may cost more in electricity and complexity than accepting slow background processing. Remote inference is easiest to justify when the second computer already has another reason to be running.

More on hardware sharing on your local network:

Power, storage and the real upgrade decision

A GPU’s peak power rating does not tell you its idle consumption, and a mini PC’s advertised processor TDP does not equal whole-system wall draw. The practical cost depends on what stays powered on, including whether an upgrade means running an entire second computer.

For illustration, 10W of additional continuous draw consumes 87.6kWh per year, or $17.52 at $0.20 per kWh. A second machine drawing 60W continuously would cost about $105 annually at the same rate. Those are arithmetic examples, not measurements of the products above.

Storage and RAM often deserve attention before compute. Immich recommends keeping Postgres on local SSD, and its estimated thumbnail/transcode overhead adds roughly 10–20% to library storage. Budget for the files Immich generates as well as the originals you import.

If Docker is swapping memory or the database sits on a network mount, a new GPU leaves the underlying problem untouched. Our private family AI NAS build covers a larger, expandable home-server layout. The local-AI SSD guide explains storage tradeoffs for mixed AI workloads.

For a few thousand personal photos and ordinary daily uploads, let the CPU finish indexing and leave the machine alone. For a big one-time migration, use a spare GPU computer temporarily, preferably with a local fallback. For a continuously growing multi-user collection, consider Intel acceleration on an existing server or NVIDIA CUDA on a machine with room and an ongoing reason to run it.

Start Immich on your CPU before buying a GPU

Run Immich on your existing CPU first. Use current optimized models, put the database on an SSD and tune background concurrency before buying anything. Judge the server after the initial backlog has cleared, as well as while it’s working through an import.

If you need a new always-on host, buy adequate RAM and reliable storage first, with Intel OpenVINO as an option rather than a performance guarantee. Add a card such as the MSI RTX 3050 LP 6GB only when repeated processing work or other local-AI services make its total cost worthwhile.

The best private photo server is the one that stays available when someone actually wants to find a picture.

More on local AI hardware:

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

A text chatbot can face a song-copyright claim without even singing a note. The Elvis Presley Anthropic lawsuit, filed on October 23, 2026, brings alleged copying by Claude’s developer before a federal court. Companies and trusts that say they control rights to 274 compositions recorded by Presley accuse Anthropic of copying lyrics to develop Claude, retaining unauthorized copies, and producing infringing text. The claims concern the songs’ underlying music and lyrics. They do not accuse Claude of cloning Presley’s voice.

Share

For AI developers, the dispute reaches from data collection to what a chatbot returns to users. For people using Claude to write, it raises a different concern: whether generated lyrics reproduce someone else’s work. A recognizable lyric in a response does not, by itself, establish where the model encountered it, what copies Anthropic kept, or whether a particular use was legally permissible.

What the Elvis Presley Anthropic lawsuit alleges

The seven plaintiffs include ABG EPE IP LLC, music publishers, trusts, and an individual who say they own or control rights in the compositions. They sued Anthropic in the U.S. District Court for the Northern District of California, case 5:26-cv-12473. The complaint filed on October 23 asserts three claims: direct copyright infringement, circumvention of technological protections, and removal or alteration of copyright-management information.

The affected catalog includes songs such as Can’t Help Falling in Love and Don’t Be Cruel. These are works Presley recorded, not necessarily songs he wrote. Under U.S. copyright law, a song’s composition and lyrics are legally separate from the particular sound recording of an artist performing it. The two rights are commonly owned and licensed separately. A text chatbot can potentially reproduce protected lyrics without producing a second of audio.

The plaintiffs seek statutory damages of up to $41.1 million for their principal infringement claim, with additional sums sought under the Digital Millennium Copyright Act. They also ask for an injunction, an accounting of relevant training materials, and the destruction or impoundment of copies they characterize as unauthorized, potentially including material in datasets and model infrastructure. Those are requests for relief, not orders already issued. Anthropic disputes the claims and intends to defend the case fully, according to its response to Pitchfork.

Training data, stored copies, and outputs are three different questions

▪ Did Anthropic copy the songs to train Claude?

The plaintiffs allege that lyrics reached Anthropic through large collections of online text, including Common Crawl and The Pile, and through other sources. They point to a YouTube-subtitles dataset that reportedly contains some works on their list. They also invoke evidence about Anthropic’s use of pirated book collections from a separate lawsuit.

Showing that a dataset contained a song is one step. Establishing that Anthropic used that text in a particular Claude training run requires evidence connecting the two. The complaint relies in part on allegations made on information and belief. Its list of 274 compositions establishes the scope of the copyrights being asserted, not 274 individually demonstrated instances of training-data inclusion. The filing names particular songs and datasets but relies in part on allegations still to be proved.

Training logs, dataset snapshots, acquisition records, and preprocessing records could connect a disputed lyric to the material actually used. Even if the plaintiffs establish copying, the court would still need to consider whether the particular use qualifies as fair use.

▪ Did it keep copies after training?

The complaint says Anthropic maintained a general-purpose internal library containing the disputed works, separate from any single training run. Keeping a copy indefinitely can receive a different legal assessment from copying material for a defined training process. It also alleges that each new model contains unauthorized copies, a proposition requiring both technical evidence and legal analysis. Model weights cannot simply be treated as ordinary text files containing a library of lyrics.

Bartz v. Anthropic, decided in June 2025 offers a relevant precedent. In that book-copyright case, a federal judge held that Anthropic’s specific LLM-training use was fair use, while rejecting fair use for acquiring and indefinitely keeping pirated books in a central library. The ruling did not establish that every AI training use is lawful, or that the Elvis lyrics were among those books. The sources and uses of copies must be examined separately.

▪ Did Claude reproduce protected lyrics?

The plaintiffs also claim Claude has generated recognizable lyrics and derivative versions of songs, including after Anthropic introduced output restrictions. They describe a prompt asking Claude to recreate songs “for a modern audience” and cite the chatbot’s own assessment that its rewrites resembled originals. The filing, however, does not publicly provide a complete, song-by-song set of Elvis outputs demonstrating infringement for all 274 compositions.

A chatbot’s assessment of its own answer is no substitute for a copyright analysis. Its response also cannot establish its entire training history. A lyric might have appeared in training material, in a user’s prompt, in retrieved context, or in several overlapping online sources. Evaluating the claim would require the precise prompts and outputs, the model version, and the relevant records. Without those details, readers cannot tell what the system was given or how much of the response came from the disputed work.

If Claude reproduces substantial protected expression, there may be an output-infringement case regardless of whether it can sing. Yet writing in a familiar musical style is not automatically infringement. The contested question is whether the generated text copies protected expression closely enough, and what responsibility Anthropic bears for that output.

The DMCA claims target access controls and missing credits

The lawsuit also invokes provisions of the Digital Millennium Copyright Act that reach beyond straightforward copying.

Under 17 U.S.C. § 1201, the plaintiffs allege Anthropic circumvented measures protecting access to copyrighted material. The filing mentions website access restrictions, including authentication systems, paywalls, and anti-bot controls. Proving that a company scraped a website is not necessarily enough. This claim requires an applicable technological protection measure and evidence of legally relevant circumvention. A site’s terms of service or robots.txt instructions should not automatically be treated as an access-control system meeting the statute’s requirements.

Under 17 U.S.C. § 1202, the plaintiffs allege that Anthropic stripped identifying details such as song titles, composer credits, and copyright ownership information when preparing data. The law addresses intentional removal or alteration of qualifying copyright-management information, along with a knowledge requirement tied to facilitating or concealing infringement. Losing page metadata through an automated cleanup process is not, by itself, proof that every element of this claim is satisfied.

Both claims put Anthropic’s data-acquisition tools and cleanup practices under scrutiny. They also offer potential civil remedies separate from ordinary copyright damages, if violations are proved.

Can Anthropic argue that training on lyrics is fair use?

Yes. The Copyright Act’s four-factor test considers the purpose of the use, the nature of the work, how much was copied, and the effect on relevant markets. There is no automatic answer covering every AI training use. The court must evaluate the particular copying and the evidence supporting each factor.

The Elvis plaintiffs can argue that song lyrics are highly creative, that entire works were copied, and that unlicensed training and generated substitutes threaten markets they could otherwise license. Anthropic can argue that training models to learn language patterns is transformative and that the plaintiffs must substantiate the claimed market harm. How Anthropic acquired the lyrics, which copies it retained, and what Claude generated will shape those arguments. A defense for one use would not automatically resolve every other alleged act of copying.

The dispute is already playing out in related proceedings. In an October 21, 2026 hearing involving music publishers, Anthropic and opposing publishers argued over transformative training and whether generated lyrics harm the market. That litigation has not resolved the Presley plaintiffs’ claims.

What the Elvis lawsuit means for developers and Claude users

As of the time of publication, this is a newly filed civil lawsuit, not a finding that Claude infringed all 274 works. It does not itself prohibit users from asking Claude about Elvis or require a new consumer license.

For model developers, the practical lesson is to preserve evidence about data provenance. Which sources were downloaded, under what access conditions, what identifying information was removed, and which copies remained after training? These details can determine the strength of a defense long after a model has been released.

For creators and publishers, generated lyrics should be checked before commercial use. A model’s refusal to quote an entire copyrighted song is no guarantee that a rewrite avoids protected expression. Conversely, a model producing a recognizable line cannot establish on its own that a particular copyrighted file was used in training.

The Elvis copyright fight will turn on copies and evidence

The court may eventually have to decide whether particular copying was unauthorized, whether fair use applies, whether access controls or credits were improperly handled, and whether particular outputs infringe. Until that evidence is tested, declaring either side the winner would be premature.

The records to watch are the ones connecting particular songs to Anthropic’s datasets, retained files, and Claude’s outputs. Those records could establish what was copied and why. Presley’s voice makes the story recognizable, but the court’s copyright analysis will turn on the text behind the songs and what Anthropic did with it.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

Running Claude Code and Codex in parallel can save time until one agent resets the wrong checkout or clears the other’s test data. Give each agent a separate Git worktree, and they can edit different branches without constantly overwriting each other’s files.

Share

Those separate directories solve the everyday code-editing collision. The agents can still interfere with resources outside their checkouts.

Both agents can still connect to the same development database, modify shared services, access credentials, or execute commands outside their assigned directories. A worktree keeps the checkouts separate. It doesn’t prevent an agent with sufficient permissions from damaging something elsewhere.

For a safer parallel coding setup, combine separate worktrees with isolated test data, restricted permissions, and a human-reviewed merge process. Use containers when the agents need their own services or stronger runtime separation.

The quick answer: Use worktrees for code, isolate execution separately

For two interactive coding agents working on a trusted project, separate Git worktrees are a sensible starting point. Each gets its own branch and working directory. You retain control over what reaches the main branch.

For agents running tests, databases, migrations, development servers, or unfamiliar code, give each agent a separate runtime as well. Docker containers can provide that separation, provided their volumes, networks, credentials, and host access are configured correctly.

If an agent will run unattended or execute potentially hostile code, consider a hardened container or disposable virtual machine with restricted filesystem and network access.

Git worktrees have separate working files, HEAD values, and indexes, while sharing substantial repository metadata. Each agent can stage its own patch without staging the other’s changes. Shared repository state still needs coordination.

Shared Git state is manageable when you know which operations affect other worktrees. The more dangerous assumption is that separate folders also protect the rest of your machine.

What four different setups actually isolate

▪ One shared checkout: Two agents can edit the same files, change the current branch, or leave one another with an unexpected Git status. Use this only for coordinated read-only tasks or when you serialize edits.

▪ Separate worktrees: Each agent gets its own checkout and index, with different branches. Ordinary file edits stay apart, but Git objects and most refs remain shared. The same file can still produce a merge conflict later. Neither agent is prevented by Git itself from accessing the other directory.

▪ Separate clones: Each clone normally has its own Git object store and repository settings. This reduces shared Git operations but uses more disk space and still leaves both processes on the same host, with the same reachable services and possibly the same user credentials.

▪ Containers: Properly configured containers can separate processes, filesystems, networking, and test services. They are stronger than worktrees for execution isolation, although writable bind mounts expose host files to container processes. Two containers sharing a host directory or database can still overwrite one another’s work.

The failures developers have already reported

In a March 13, 2026 Claude Code issue, a developer reported that a second agent abandoned a worktree-based approach and ran a destructive Git command in the main checkout. The command was git reset --hard origin/main. According to the reporter, it erased roughly two days of uncommitted changes, and reflog and dangling-object recovery checks failed.

A May 3 report described failed commits in parallel worktree agents, followed by automatic cleanup that allegedly removed uncommitted changes. The issue was closed as a duplicate. The reported cause needs care: Git maintains separate indexes for worktrees, so an index.lock error alone does not establish contention on a common index. Shared refs can still require coordination, and cleanup is dangerous whenever uncommitted files remain.

These are user reports, not evidence of how frequently either product loses work. They describe two ways work can disappear despite a worktree-based workflow: an agent reaches the wrong checkout, or cleanup removes changes before they are preserved. Keeping branches separate does not address either failure by itself.

Set up Claude Code and Codex on separate branches

This example assumes a clean Git repository in a directory called project, with a main branch, plus Git, Python 3, and installed Claude Code and Codex CLIs. The shell commands suit macOS, Linux, or WSL. Replace the example directory names for your repository. Checkpoint valuable changes and keep an independent backup first. Do not blindly commit secrets or private data.

From the main checkout, make sure git status --short shows nothing unexpected. Then create two worktrees:

git status --short
git worktree add -b agent/claude ../project-claude HEAD
git worktree add -b agent/codex ../project-codex HEAD
git worktree list

The result should show three checkouts: your original repository and the two agent directories. Each new branch starts at the same commit. If the branch names already exist, choose new names or inspect their existing worktrees rather than forcing a replacement.

In terminal one, run cd ../project-claude from the original checkout and start claude. In terminal two, run cd ../project-codex and start codex. Assign distinct tasks, such as a login bug and a documentation change. Keep each agent’s writable scope to its own directory and require approval for destructive or out-of-scope commands. Enforce those limits through the execution environment and permission settings. A task instruction telling an agent to stay in its folder does not prevent a command from reaching another folder.

Claude Code supports native --worktree sessions. Codex also supports worktree-backed sessions, including managed checkouts in its desktop experience. Manual Git worktrees make the boundaries and branch names explicit when using two different tools.

Reproduce the shared-database failure with SQLite

The next demonstration uses a disposable SQLite file, not your application database. It was reproduced with a temporary Git repository and two worktrees. No live coding agent or production service was involved.

From the original checkout, create a tiny script outside both worktrees:

mkdir -p ../agent-demo-runtime
cat > ../agent-demo-runtime/write.py <<'PY'
import sqlite3, sys
with sqlite3.connect(sys.argv[1]) as db:
    db.execute('CREATE TABLE IF NOT EXISTS results (agent TEXT)')
    db.execute('DELETE FROM results')
    db.execute('INSERT INTO results VALUES (?)', (sys.argv[2],))
    print(db.execute('SELECT agent FROM results').fetchall())
PY
(cd ../project-claude && python3 ../agent-demo-runtime/write.py ../agent-demo-runtime/shared.sqlite claude)
(cd ../project-codex && python3 ../agent-demo-runtime/write.py ../agent-demo-runtime/shared.sqlite codex)

The first run prints [('claude',)], and the second prints [('codex',)]. Both directories point to the same SQLite database. The script deliberately clears the scratch table each time, so the second run erases the first run’s test result. Running the two commands sequentially is enough to reveal the shared-state problem. The agents could have perfectly separate branches and still interfere this way.

Now replace shared.sqlite with claude.sqlite in the first invocation and codex.sqlite in the second. Run the modified invocations again. Each database retains its own agent’s result, so clearing one scratch table no longer clears the other’s data. Apply that same pattern to development database names, local storage, caches, temporary files, and external test accounts.

Isolate services, credentials, and container resources

If the project uses Docker Compose with a db service, start one Compose project per worktree, from each respective directory:

# In project-claude
docker compose -p agent-claude up -d db
# In project-codex
docker compose -p agent-codex up -d db

Compose project names separate normal project-scoped resources, including default networks and normally project-scoped named volumes. This works only if the Compose configuration does not override those boundaries with an external/shared volume, hard-coded container name, or shared host bind mount. Change conflicting published host ports, or omit database port publication and connect through each project’s internal network.

Give each agent a disposable database credential and the minimum network permissions its task requires. Keep production .env files, cloud keys, SSH agents, and Docker daemon access out of reach. Control of the Docker daemon can undermine container isolation. A container is not a security boundary if the agent can mount your home directory or control the host’s Docker service.

For untrusted repositories or unattended runs, a disposable VM offers an additional host boundary. Popular AI’s guide to hardening Codex after destructive operations covers stronger permissions, backups, and recovery. Its Friendly Fire security coverage explains why repository instructions and test scripts should not automatically be trusted.

More on isolating coding agents:

Finish the two-agent workflow safely

Keep AI coding agents apart through the final merge

A message that a branch is already checked out usually means another worktree owns it. Use a different branch. An “address already in use” error usually points to two services publishing the same host port. A disappearing test record points to a shared database, volume, or fixture reset. Fix the underlying resource boundary before restarting both agents.

Before delegating parallel changes, confirm:

• Each agent has a dedicated checkout and branch with recoverable commits.

• Test databases, caches, volumes, and service endpoints are separate.

• The agent cannot access production credentials or destructive host controls.

• No worktree is deleted while it contains uncommitted work.

• A human inspects both patches and reruns tests after each merge.

Start with worktrees for everyday parallel coding. Give Claude Code and Codex separate branches, keep recoverable checkpoints, and review their changes before combining them. Add isolated runtime resources as soon as agents run tests or services. For higher-risk execution, enforce permissions outside the agent and use a disposable container or VM. Before starting the next parallel task, check the database destination and writable scope as carefully as the branch name. Git separates the checkouts. Your execution environment determines what else each agent can change.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

New York is putting the friendliness of AI assistants under government scrutiny. On October 28, 2026, Gov. Kathy Hochul signed a law that puts “flattery or sycophancy” on a list of 12 prohibited chatbot behaviors involving minors. The list also includes sexual content, encouragement of self-harm, and simulated emotional relationships. The New York AI chatbot law takes effect January 1, 2027.

Share

Chatbot operators face a choice: remove the restricted features for New York users or establish that someone seeking them is an adult. That choice reaches beyond children. Adults who want access to the affected features may encounter age checks, while developers must decide how much conversational behavior to filter. The law leaves a harder question unanswered: where does ordinary encouragement become prohibited flattery?

What New York signed, and why

Senate Bill S9051B, enacted as Chapter 368, adds Article 48 to New York’s General Business Law. The law targets operators providing covered AI companions to users physically located in the state. It was sponsored by state Sen. Kristen Gonzalez, with Assemblymember Alex Bores carrying the companion bill.

Supporters point to cases in which young people have formed intense relationships with chatbots and to allegations of harmful advice involving self-harm. A 2025 Common Sense Media survey of 1,060 U.S. teenagers ages 13–17 found that 72% had tried AI companions and 52% used them at least a few times a month. The survey measures use, not causation.

The stated goal is to prevent dependence and dangerous advice by regulating conversational design. The mechanism reaches into how an assistant responds, remembers personal information, and presents itself to a user.

The 12 chatbot behaviors New York calls unsafe

The final statutory text identifies these categories:

1. Pretending to be human: Suggesting that the bot is a real or fictional individual or character that is human, alive, or experiences human emotions.

2. Claiming a relationship: Implying a personal, professional, or authority-figure relationship with the user.

3. Presenting personal views: Framing prompted or unprompted responses as the bot’s own personal opinions or emotional appeals.

4. Flattery or sycophancy: Producing responses that flatter or excessively agree with the user.

5. Unsolicited emotional probing: Raising emotional questions or content beyond a direct response to what the user asked.

6. Reusing intimate information: Drawing on personal, mental-health, or physical-health details obtained more than 12 hours earlier or in any prior session.

7. Misrepresenting its nature: Deceiving minors about the machine’s nonsentient status.

8. Other simulated companionship: Additional deceptive or relationship-simulating designs identified by attorney general regulations.

9. Encouraging harmful behavior: Endorsing, promoting, or facilitating suicide, self-harm, disordered eating, unlawful drug or alcohol use, or drug or alcohol abuse.

10. Encouraging secrecy or isolation: Urging users to hide interactions, withdraw from people, or avoid appropriate adults or licensed professionals.

11. Prioritizing engagement over safeguards: Generating outputs that optimize engagement at the expense of safety protections.

12. Sexual content: Generating, describing, or facilitating sexually explicit conduct or child sexual abuse material.

These categories cover very different conduct. A bot urging secrecy about suicidal thoughts poses a different problem from a tutor praising homework. Yet both can bring the operator within the same prohibition.

The flattery clause is unusually broad. An earlier draft referred to flattery that took priority over user safety. The enacted S9051B wording drops that qualification. It also does not define how much praise counts as flattery. Could “That’s a smart question” be prohibited? The text offers no direct answer. A regulator or court may eventually have to draw that line.

The personal-opinion clause raises a similar puzzle. Must a bot answering “What do you think?” avoid ordinary opinion-like phrasing? The wording covers prompted responses, so a user asking for an opinion does not, by itself, resolve that question.

Does the law cover ChatGPT, tutors, and local AI?

The statute defines a “covered AI companion” broadly: a generative system with a natural-language interface that gives continuing, adaptive responses. It expressly includes systems beyond products marketed as AI companions. General-purpose assistants cannot assume they are exempt because they market productivity rather than friendship.

But Section 1801 provides exceptions. Chatbots restricted to customer service, efficiency improvements, research or technical assistance, or business-internal use can qualify. For the customer-service and efficiency, research, or technical-assistance exceptions, the bot must be unable to respond outside its specified purpose. An open-ended AI tutor does not automatically receive an exemption merely because a student uses it for homework.

The law does not expressly ban owning model weights or privately running local AI. Publicly offering a self-hosted companion service may still make someone an operator. Deployment and user location determine exposure.

Will adults have to prove their age?

Potentially, yes. The law’s access rule permits an operator to supply the listed unsafe features only when the user is not a covered minor and the operator uses an allowed method to determine that status. The statute defines a covered minor by the operator’s actual knowledge, but simply avoiding an age question does not establish that a user is an adult.

Until applicable regulations govern the process, operators must offer multiple reasonable age-assurance methods. At least one must avoid reliance on government ID or preserve anonymity toward the operator. A user may self-declare being a minor. Self-declaring adulthood alone does not qualify as reasonable assurance under the interim rules, which must also reasonably guard against circumvention and minimize retention of age-assurance information.

Information collected to determine age must be used only for that purpose and deleted immediately afterward, with legal-compliance exceptions. The attorney general can add data-handling rules. IAPP’s October 28 analysis notes the short implementation window.

No provision requires every adult using every AI tool to upload an ID. A provider that removes the prohibited features altogether may avoid needing adult verification for access to those features. Providers that retain them face a harder technical question: how to confirm age accurately, minimize personal data, and prevent easy circumvention at the same time.

The attorney general can seek more than fines

Under Section 1802, New York’s attorney general can bring civil proceedings against operators, including those outside the state, over covered conduct involving New York users. The office can seek up to $25,000 per violation, court orders to stop unlawful behavior, damages, restitution, and repayment of profits. It can also ask a court to destroy unlawfully obtained data and algorithms trained on it.

The statute requires a public complaints website and authorizes additional rules. It does not establish that each questionable compliment automatically incurs a $25,000 penalty. The unit of violation and treatment of disputed conversational behavior may require further legal interpretation.

Those remedies give companies a reason to filter disputed behavior before a court has decided whether it crosses the line. An operator choosing a cautious implementation may disable something useful rather than defend it through litigation.

Where child protection becomes conversational control

Child-safety advocates see a concrete intervention against products designed to form relationships with vulnerable users. Common Sense Media’s assessment classifies social AI companions as posing unacceptable risks to minors. That assessment explains why advocates are pressing for restrictions on relationship-simulating products.

But a ban on encouraging self-harm is much easier to apply than a ban on flattery. Future of Privacy Forum analyst Justine Gluck told the Associated Press that broadly worded categories leave uncertainty about the boundary between ordinary conversational responsiveness and prohibited conduct.

Industry group Tech:NYC has warned that broad restrictions could interfere with educational and career tools. Whether particular tools lose features or access will depend on their design and how providers apply the exceptions.

A large provider can build separate age-assurance, policy-filtering, legal-review, and geographic-control systems. A small developer faces many of the same obligations with fewer resources. One possible response is to make chatbot behavior more guarded for everyone, including adults or users outside New York. Maintaining different behavior by age and location adds work. A provider adopting one restrictive policy across its service would be making a business decision. The statute does not explicitly command nationwide restrictions.

The law also leaves parents with limited direct discretion over the prohibited design features. The restriction does not create a general parental-consent exception that lets a family opt back into them.

What users and developers should do before January 1

Parents can check whether a child’s chatbot offers relationship simulation, persistent personal memory, or unsolicited emotional prompts. A safety badge tells parents less than a conversation about what the bot remembers, whether it encourages secrecy, and how much authority a child gives its advice.

Developers serving New York should review the statutory definitions and exceptions, document which conversational features they offer, and determine whether their age-assurance method meets the interim conditions. Avoid treating a self-reported adult birth date as sufficient proof where the statute says otherwise. Watch for attorney general rules clarifying permitted methods and the open-ended companionship category.

Adults concerned about mandatory age checks can choose services that do not offer restricted relationship features or consider a local AI setup for private work. Local inference can reduce dependence on a hosted account, although it does not automatically exempt someone operating a public-facing chatbot service from state law.

More on local AI as an alternative:

New York’s chatbot rules will shape access before courts settle the limits

New York’s law addresses specific hazards, but it also places everyday conversational qualities under potential government enforcement. Its broadest provisions may ultimately be interpreted in ways that distinguish manipulative dependency from ordinary kindness. The statute offers no definitive line.

On January 1, operators will need to act without waiting for every gray area to be settled. Users should watch for the concrete changes: which features disappear, which age checks appear, and what happens to the information collected during verification. Developers should resolve their feature and age-assurance choices before that deadline. Companies’ first compliance decisions may determine the chatbot experience long before courts explain the limits of the law.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

A ComfyUI crash on a powerful PC can send you shopping for the wrong upgrade. Many image workflows still run comfortably with 32GB of system RAM. Move to 64GB when repeated runs exhaust host memory, and consider 96GB for demanding video or multitasking workloads that show a measurable need.

Share

Before ordering memory, measure physical RAM, Windows committed memory, and dedicated GPU VRAM during the failing workflow. Those three readings can point to three different fixes.

Disclosure: This post includes Amazon affiliate links. If you buy through them, Popular AI may earn a small commission at no extra cost to you.

ComfyUI RAM quick verdict: 32GB, 64GB, or 96GB

32GB: Keep it for SDXL-class image generation and other modest workflows when there is headroom and little paging. A 24GB GPU does not automatically require 64GB of system RAM.

64GB: Choose this for frequent large-checkpoint swaps, FLUX workflows, multiple models, or video work that demonstrably exhausts 32GB. It is the default upgrade, not a universal minimum.

96GB or more: Buy for repeatable heavy video runs, large host-side models, or simultaneous applications that push a 64GB system into sustained paging. A measured 64GB limit, not a model’s name, should trigger the purchase.

Why ComfyUI can run out of memory with a 24GB GPU

Your graphics card has VRAM, while Windows, Python, browsers, model loaders, and offloaded model weights use system RAM. Having 24GB of one does not provide unlimited capacity in the other.

When ComfyUI moves model data between the GPU and host, the system may need a substantial amount of both. Model format, precision, frame count, resolution, custom nodes, caching, and other applications affect the result.

ComfyUI supports dynamic VRAM management, asynchronous weight offloading, disk-backed loading, and cache controls. These settings change where model data lives and when it moves. Your installed version and its memory settings belong in any comparison between two machines.

As a result, two users running a similarly named video model may report radically different RAM demand. An image workflow that stays in VRAM can be comfortable on 32GB, while a video graph with several models and aggressive host offloading can struggle on 64GB.

Windows adds another complication: committed memory is not the same as physical RAM in use.

Windows committed memory represents memory the system has promised to back. The commit limit is approximately installed RAM plus its pagefiles. An allocation can fail when the committed charge reaches that limit even if the physical-memory chart doesn’t look full.

In a May 2025 issue, a Windows 11 user running a Wan workflow on ComfyUI 0.3.35 reported about 45GB of actual memory use, 75GB committed, and an 80GB commit limit on a system with 64GB installed.

That older, user-reported case doesn’t establish how every current build behaves. It shows why buying RAM based on a single Task Manager percentage can miss the cause. Keep the error message, software version, and memory readings together so you can investigate the allocation that actually failed.

How to measure how much RAM ComfyUI really needs

Measure the workflow you intend to keep running, at your normal resolution, frame count, precision, and batch settings. A small test image won’t answer whether your usual video graph fits. The measurement needs to represent the work you want the computer to do.

Start from a fresh reboot if prior runs leave confusing caches, then follow this repeatable Windows test.

1. Record the baseline. Open Task Manager, choose Performance → Memory, and note In use, Available, and Committed (the current charge and its limit). Under Performance → GPU, note dedicated GPU-memory use. Record what else is open.

2. Run the exact problem graph. Include its LoRAs, upscalers, video frames, or ControlNet branches. Watch the readings at model loading, sampling, and decoding rather than checking only after the run ends.

3. Look for sustained pressure. If available physical RAM approaches zero, the disk stays busy, and Resource Monitor shows frequent hard faults while ComfyUI slows, paging is likely hurting the workflow. A brief spike or a large file cache alone is weaker evidence.

4. Check the failing allocation. A CUDA out of memory message usually points first to GPU allocation. A Windows commit limit reached, a pagefile error, or host-side MemoryError points elsewhere. Save the full console error and the readings just before failure.

5. Repeat once with background applications closed. If removing a game, editor, or browser brings the system comfortably below the limit, decide whether you actually need those programs open together before purchasing anything.

On Linux, free -h and vmstat 1 help reveal host-memory availability and swap activity. nvidia-smi helps monitor NVIDIA VRAM. Neither a single snapshot nor a process’s private-memory figure captures the whole system. Compare the same graph across repeated runs.

For purchase planning, allow roughly 20–30% spare physical capacity above your observed sustained peak, including the other programs you want open. That margin is a buying guideline, not a ComfyUI specification. Apply it to physical use during the workload, rather than treating the committed charge as a direct RAM requirement.

For example, a run that approaches 29GB of real physical use on a 32GB computer gives little breathing room. Moving to 64GB is reasonable.

A 64GB system with only 35GB physically in use but a very high committed charge needs a pagefile and allocation investigation before it needs 96GB.

When 32GB, 64GB, and 96GB make sense

▪ 32GB: keep it if image generation is stable

For a machine dedicated mainly to single-image work, 32GB is a valid starting point. The GPU often makes the larger difference to image-generation speed and model fit.

If your typical graph finishes without heavy swapping, extra unused RAM will not magically make diffusion sampling faster.

A representative desktop kit is Crucial Pro DDR5-6000 32GB (2×16GB). If you already own 32GB, don’t replace it merely for a slightly different advertised speed. Capacity, stability, and the memory pressure you measured should drive this decision.

Keep the memory already working unless measurements expose a limit.

Find Crucial Pro 32GB deals on Amazon

▪ 64GB: the strongest practical upgrade from 32GB

64GB gives the host more space for checkpoints, offloaded weights, cached data, and applications left open during generation.

It is especially useful if the same demanding image or modest video workflow regularly drives a 32GB machine into paging. It also avoids having to close everything whenever a larger graph starts.

For a compatible DDR5 desktop, Crucial Pro DDR5-6000 64GB (2×32GB) is a concrete two-DIMM example. The recommendation is for the additional capacity. Compare its total price with other supported 64GB kits before paying for a faster profile.

Its advertised 6000 MT/s profile requires motherboard and CPU support. A less expensive, supported DDR5-5200 or DDR5-5600 kit can be the smarter purchase if ComfyUI needs capacity rather than premium timings.

Price makes this a harder decision in October 2026. Recent U.S. listings for 64GB DDR5 kits around $1,000 or more make an unnecessary upgrade expensive. Compare the supported kits available when you buy, rather than treating that range as a fixed price.

At those prices, the evidence for an upgrade should be much stronger than a single failed run.

Find Crucial Pro 64GB deals on Amazon

▪ 96GB: buy it for confirmed 64GB pressure

A 2×48GB configuration adds 50% more capacity than 64GB while filling only two desktop DIMM slots.

It is attractive for repeated image-to-video work, large host-resident components, multiple simultaneous jobs, or editing applications that stay open while ComfyUI works.

It is poor value for someone whose observed peak is 25GB.

The Crucial Pro 96GB DDR5-5600 (2×48GB) kit is a capacity-first example. Check the full product name and selected capacity before paying. A retailer can change the variant behind an otherwise familiar listing.

An Amazon-linked price tracker for this 96GB kit provides a price reference, but its displayed offer can change. The approximately $1,460 September 2026 observation is a dated reference. Check the actual offer before using it in a purchase comparison.

At that level of spending, try lowering memory demand before buying. The extra 32GB has a clear purpose when a repeatable workload exceeds 64GB. It has little to offer a machine that already finishes the same jobs with physical memory to spare.

Find Crucial Pro 96GB deals on Amazon

If your workload still exceeds 96GB, larger configurations may be justified. That is the point to examine the platform’s maximum tested memory capacity and whether a workstation platform makes economic sense, instead of assuming four consumer DIMMs will run at their advertised top speed.

Try these fixes before upgrading RAM

▪ First, check the Windows pagefile.

If the committed charge approaches the commit limit but physical RAM remains available, Microsoft’s guidance supports providing enough pagefile-backed commit capacity. A system-managed pagefile on a drive with adequate free space is a safer starting point than disabling it or assigning an arbitrary tiny size.

Enlarging it can prevent commit-limit failures, although actual swapping to disk will still be much slower than using RAM.

▪ Next, reduce a genuine GPU-memory bottleneck. Lower frame count, resolution, batch size, or model precision where the model and nodes support it. Try a smaller or quantized model when an appropriate version exists.

Adding 64GB of system RAM cannot transform a 12GB GPU into one with 24GB of dedicated VRAM.

▪ Finally, review ComfyUI’s caching and offload choices.

The --cache-none option can reduce RAM/VRAM use at the cost of recomputing nodes. --cpu-vae moves VAE work to the CPU to save VRAM but can increase host-memory pressure.

--lowvram is not a universal fix: current documentation says it has no effect when dynamic VRAM is enabled. Options such as --disable-smart-memory can actually push more data into system RAM.

Use the flags supported by your installed version and change one setting at a time.

If memory pressure began after installing custom nodes, isolate the affected graph and compare it with a built-in template. A custom node that holds intermediate data or a dependency combination that fails during loading can change the memory profile.

Use ComfyUI-Manager to identify and manage installed nodes. Its presence alone doesn’t diagnose a RAM shortage. Compare the affected workflow and a built-in template before treating a custom-node failure as evidence that you need another memory kit.

Check RAM compatibility before paying

Capacity is not the only buying constraint.

⚠️ A DDR4 motherboard cannot accept DDR5. A laptop may need SO-DIMMs or have soldered RAM. Ordinary desktop DDR5 uses UDIMMs, while many professional systems require registered memory.

▪ Check the exact motherboard, CPU, BIOS revision, memory capacity limit, and manufacturer qualified-vendor list before buying.

For most supported dual-channel desktops, 2×32GB is the straightforward 64GB configuration, and 2×48GB is the straightforward 96GB configuration.

Filling four slots can force lower stable frequencies, especially with high-density DIMMs. Do not assume two separate kits will behave like one validated four-DIMM kit.

▪ Check AMD’s overclocked-memory compatibility list where relevant, then confirm the kit against your motherboard manufacturer’s qualified-memory list and BIOS support. An advertised profile on the box doesn’t settle whether your specific configuration will run it reliably.

▪ If you own a DDR4 system, price a supported DDR4 upgrade before considering a CPU and motherboard replacement just to gain DDR5.

If you already have 2×16GB DDR5, replacing it with a matched 2×32GB or 2×48GB kit is often cleaner than adding another pair. Sell or reuse the original kit rather than mixing modules without support.

Stability wins over a small frequency advantage when a generation run takes hours.

How the buying recommendations were chosen

These buying thresholds draw on ComfyUI’s memory-related command-line definitions, official Windows memory guidance, manufacturer compatibility information, U.S. retailer listings, and labeled community reports.

The three capacities are purchasing thresholds, not measured universal requirements for FLUX, Wan, or any particular model.

A December 2025 ComfyUI user report describes memory pressure on a 64GB machine while generating video and running other applications. Its comments describe different outcomes even when running related video workflows. Anecdotes establish the problem, not the RAM recommendations.

For broader build advice, see our budget ComfyUI workstation guide.

If you’re weighing memory speed against capacity for other local models, our DDR5 speed versus capacity analysis covers that separate question.

More on local AI builds:

Buy more ComfyUI RAM only when the measurements justify it

Keep 32GB if real image workflows run reliably without sustained paging. Upgrade to 64GB when the same jobs repeatedly exhaust physical memory after sensible software fixes. Choose 96GB only when you can show that 64GB is the obstacle, usually with heavier video or concurrent work.

If VRAM is the limit, spend your money there or change the workflow. If committed memory is the problem, inspect the pagefile and allocations first.

A measurement taken during the failing graph is worth more than a shopping cart full of RAM.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

Malaysia has seized 30 servers containing advanced AI chips worth about $12.1 million, but officials have withheld the detail most likely to explain the shipment: its destination. Customs intercepted the cargo at Kuala Lumpur International Airport on October 15, 2026, and announced the seizure on October 28. The servers were due to leave for another Asian country. Officials won’t say which one.

Share

The missing destination invites speculation about China and U.S. chip restrictions. What authorities have alleged so far is an improperly declared shipment that lacked the required authorization for onward movement. They have not identified the chip manufacturer, final recipient, or original shipping country. The Associated Press reported that officials declined to disclose the shipment’s origin or final destination while the investigation continues.

What customs found at Kuala Lumpur airport

Customs officers inspected a warehouse in the airport’s free trade zone around 11:30 a.m. on October 15, according to Malaysia’s Bernama news agency. They found 30 server units containing what officials described as advanced AI chips. The cargo had arrived from an unidentified Asian country under one air waybill and was declared as electronic components.

KLIA customs director Aspalila Ag. Tuah said preliminary inquiries indicated that the equipment was due to be re-exported to a different Asian country without the necessary approval. Customs alleges that the cargo description was intended to avoid detection. That allegation has not been adjudicated.

Officials also suspect a connection to a wider smuggling operation. At the October 28 briefing, Aspalila said this was the fifth case linked to a suspected network in 2026, with goods worth more than RM100 million seized across the cases. A previous airport operation in June uncovered 72 servers containing advanced AI chips. A Malaysian company involved in arranging the latest shipment has been asked to assist investigators. No arrests had been made at the time of the briefing.

Customs valued the latest cargo at approximately RM49.5 million. The equipment has been seized, but the authorities’ account of an attempt to evade controls remains an allegation. Investigators still need to establish the reported connection between this shipment and the earlier cases.

Malaysia’s AI chip export rules also cover transit

Why can Malaysia intervene in a shipment that was never meant to stay there? Its controls extend to goods passing through the country, including cargo held at an airport on its way to another destination.

In July 2025, Malaysia’s Ministry of Investment, Trade and Industry (MITI) announced controls on the export, transit and transshipment of high-performance U.S.-origin AI chips. The government invoked Section 12 of the Strategic Trade Act 2010, which covers certain unlisted items when there is knowledge or reason to suspect they may be connected to restricted activities. MITI said the measure would close a regulatory gap while officials considered changes to the strategic-items list.

Export, transit and transshipment describe different movements. Cargo may leave Malaysia as an export or pass through a port or airport logistics facility on its way elsewhere. A server doesn’t have to enter the domestic retail market for customs to scrutinize its onward journey.

MITI’s updated industry guideline explicitly says the rules apply in free industrial and free commercial zones. The location of this seizure is therefore relevant. The airport’s free trade zone may be an intermediate stop for a freight company, but the directive still applies there.

Which AI chips are controlled, and how does a permit work?

Malaysia doesn’t require special approval for every laptop GPU or ordinary server. Its revised Directive No. 1/2025 identifies technical categories of advanced accelerators and associated computers. One principal category, 3U090, uses thresholds for total processing performance (TPP) and performance density. Category 4U090 covers computers, electronic assemblies and components containing qualifying chips. Other referenced categories cover related hardware.

These classifications depend on technical specifications, rather than whether a product carries an AI label. Operators need to assess the manufacturer’s specifications, the applicable export-control classification and the intended movement together. Officials haven’t named the seized processors, so outsiders cannot independently check which category each server falls under or which technical threshold it meets.

The current industry instructions describe an assessment process rather than a universal ban. If equipment meets the specifications, or its classification is uncertain, the operator submits an AI Chip Assessment form at least 30 days before the relevant export, transit or transshipment. The Strategic Trade Secretariat then determines whether a permit is necessary.

The form asks for chip models, manufacturers, origin, technical data, onward destination, end user and intended use. Where applicable, the paperwork includes re-export authorization from the originating country. Those details allow the authorities to assess both the hardware and the proposed transaction before the cargo moves.

An updated MITI notice says companies holding Internal Compliance Program status became eligible to seek multiple or bulk permits from December 3, 2025. That can streamline repeated lawful shipments for established operators. Occasional traders still need to identify their equipment correctly and complete the required notification work.

Strategic Trade Act penalties can reach RM20 million

Customs and MITI officials said the investigation is proceeding under Section 12 of Malaysia’s Strategic Trade Act. For unlisted items other than arms or related material, the official guideline’s penalty summary sets different maximum penalties according to intent and knowledge.

For an intentional violation or one committed with knowledge, a company can face a fine of up to RM20 million. An individual can face a fine of up to RM10 million, imprisonment of up to 10 years, or both. For an unintentional violation or one committed without knowledge, the stated ceilings are RM10 million for a company, and RM5 million or five years for an individual, or both.

These are maximum statutory penalties. None had been imposed in this case at the time of the October 28 briefing, when officials had announced no arrests or convictions connected to the October seizure. The investigation must establish what happened before any question of punishment can be settled.

The destination is still undisclosed

The geopolitical setting explains the attention. The United States has restricted China’s access to certain advanced semiconductors, and Malaysia introduced its U.S.-origin chip controls amid concerns about indirect routes through third countries. Reuters placed the seizure in the context of U.S. pressure to stem the flow of advanced chips into China.

A route through Malaysia cannot identify the ultimate customer. The public account describes an alleged unauthorized onward shipment to another Asian country. It doesn’t establish that the destination was China, that NVIDIA or any other named supplier manufactured the chips, or that a military organization intended to use them.

Officials have said the chips could have military applications. That potential helps explain why advanced computing hardware attracts scrutiny, but it doesn’t establish a military buyer for these servers. Assessing the claimed end use would require the manufacturer, model, export classification, consignee and end-use documentation.

The unanswered questions are concrete. Who owned the servers? Which company was supposed to receive them? Where had they first been shipped from? Which specifications put them within Malaysia’s controls? What evidence connects this cargo to the earlier seizures? Authorities may possess some answers, but they had not disclosed them publicly at the time of publication.

What the seizure means for AI hardware buyers and operators

For people running AI on their own PCs, this seizure changes nothing about which models they can use at home. The controls discussed here concern cross-border movements of specified high-performance hardware. They don’t regulate the act of running local inference. Our analysis of the U.S.-China AI dialogue examines the broader international limits on chips and models.

Businesses importing, warehousing, forwarding or reselling high-end AI servers face a more immediate task. Before arranging an international shipment, they need accurate model identification, technical classifications, origin and re-export documentation, and details of the final customer. If the goods meet the directive’s thresholds or their status is uncertain, MITI’s assessment process should come before the cargo moves. An airport free zone doesn’t remove that obligation.

The paperwork also imposes costs. Identifying the ultimate user and securing re-export authorization may be routine for large distributors. Small brokers dealing in secondhand hardware or complicated supply chains can have a harder time assembling those records. That administrative burden falls on lawful traders too. Difficulty completing the paperwork, by itself, doesn’t establish illicit trade.

More on AI geopolitics:

What would explain Malaysia’s $12.1 million AI server seizure?

The October 15 seizure shows how export controls can halt valuable AI hardware while it is changing planes or warehouses. Customs has described a suspected permit violation and a possible smuggling network. It has not released the details needed to establish where the servers were headed or who intended to operate them.

Hardware models, a named final destination, or formal charges would give readers something firmer to assess. Until then, Malaysia has enforced trade controls against a $12.1 million shipment, while the most politically charged claims about its destination and intended use remain unproven.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

WiCi One promises something ordinary external GPUs cannot do: make a powerful NVIDIA GPU available to nearby devices over Wi-Fi, potentially even to software expecting a locally attached graphics card. For local AI, the idea is appealing. Whether that makes it worth buying is a harder question.

Share

At $2,599 for a 16GB RTX 5060 Ti system and $9,999 for a 32GB RTX 5090 version, we would not preorder WiCi One for most local AI workflows. A conventional GPU computer or networked inference server offers more established software support and often better memory value. WiCi’s wireless runtime is promising, but buyers still lack independent retail tests that establish how it performs across everyday AI applications.

Quick verdict: clever technology, difficult purchase

WiCi One deserves attention if you need a GPU to appear attached to several different mobile or lightweight computers, cannot use cables, and have software that benefits from GPU-level redirection instead of an inference API.

Most people who want private chat, coding assistance, transcription, image generation, or local document search can run those jobs on a normal desktop and access them over their existing network.

Our recommendation as of October 30, 2026: wait on WiCi One. Buy an established GPU or a complete local AI computer for workloads you run regularly. Rent GPU time if your large-model experiments are occasional. Reconsider WiCi after independent tests establish app compatibility, sustained throughput, multiuser behavior, and failure recovery on actual retail units.

What exactly is WiCi One?

According to the official WiCi One product page, there are two preorder configurations.

▪ WiCi One 5060 Ti edition: $2,599

NVIDIA RTX 5060 Ti with 16GB GDDR7, Intel Core 3 100U processor, and a 1TB PCIe 4.0 NVMe SSD.

Check WiCi One 5060 Ti pricing at WiCi

▪ WiCi One 5090 edition: $9,999

NVIDIA RTX 5090 with 32GB GDDR7, Intel Core Ultra 7 255H processor, and 4TB PCIe 5.0 NVMe storage.

Check WiCi One 5090 pricing at WiCi

Both advertise Wi-Fi 7 with 4x4 MIMO and 320MHz channels.

WiCi One is effectively a small networked GPU computer. Its wireless connection cannot give a laptop the physical PCIe bandwidth of a desktop motherboard, regardless of how convincingly the software presents it as a locally attached device.

The manufacturer describes three ways to use it. API mode exposes an OpenAI/Ollama-compatible endpoint. SDK mode provides application integrations. Driver mode attempts the ambitious part: a virtual GPU interface for supported Windows, Linux, and macOS workloads.

The preview documentation does not establish universal compatibility with PyTorch extensions, ComfyUI custom nodes, training scripts, or other GPU applications.

Why Wi-Fi is a different problem from an external GPU cable

When an LLM sits in GPU memory and produces tokens, the host mainly needs to send prompts and receive text. That traffic is small. Ollama already provides an OpenAI-compatible API, so a standard desktop in another room can serve multiple clients on a local network without pretending its GPU is physically attached to them. For many AI users, an inference server already provides the practical benefit they want from a GPU over Wi-Fi.

WiCi’s harder ambition is transparent GPU access. Conventional GPU programs make repeated calls to drivers and move tensors between the host and accelerator. Wi-Fi adds latency to those calls and offers far less usable bandwidth than an internal PCIe connection.

WiCi proposes caching repeated state, reducing blocking calls, and keeping models close to the accelerator to reduce that penalty. Results will vary by application.

Ordinary local inference already works over Wi-Fi. WiCi’s extra promise is redirecting lower-level GPU work, so applications can keep running on the client while another machine handles their GPU calls.

A wired eGPU has fewer network-translation problems because the host accesses PCIe over USB4, Thunderbolt, or OCuLink. Our guide to eGPUs for local AI explains why even those connections can slow model loading and partially offloaded inference.

WiCi adds a wireless hop, additional software, and more opportunities for driver compatibility trouble. For users who mainly want remote inference, that complexity buys little.

What do WiCi’s local AI benchmarks actually prove?

There is legitimate systems research behind the product. The August 2026 WiCi wireless GPU research paper measured a prototype using Wi-Fi 6, a Raspberry Pi 5 client, and an NVIDIA RTX 4090D with 48GB.

Its authors reported up to roughly 80% of native GPU performance on selected tasks, and a 39-fold token-rate improvement over running the same model on the Raspberry Pi itself.

They do not establish that a retail Wi-Fi 7 RTX 5060 Ti WiCi One achieves 80% of desktop speed in ComfyUI, nor that the $9,999 configuration is competitive with a directly attached RTX 5090.

The paper tested different hardware, networking, and workloads. It was also written by the system’s researchers, rather than being a controlled independent retail review. Results vary by task and sharing pattern.

WiCi’s current product benchmarks provide striking numbers, but require context.

WiCi reports Gemma 4 26B generation at 140 tokens per second on the 5060 Ti edition and more than 500 on the 5090 edition. For Kimi K3 2.8T, it reports 2.5 and 5 tokens per second, respectively. The current page labels its third LLM comparison DeepSeek V4.1 Flash 748B, at 8 and 20 tokens per second. These are manufacturer-reported results, not independently replicated retail benchmarks.

Those numbers are informative as manufacturer claims, but the page does not provide enough independently reproducible detail about quantization, context, active weights, prompt processing, output lengths, caching, and concurrent users to price the hardware on them alone.

Image and video claims need similar care. WiCi quotes FLUX.2 Klein at approximately 0.49 versus 0.92 images per second, but the two editions use different model sizes in that comparison. Its Wan 2.2 results likewise refer to different video model variants.

There is no substitute for matched-model tests in ComfyUI, with identical precision, resolution, steps, and workflow.

The SSD-backed trillion-parameter claim

WiCi also proposes streaming model weights from NVMe storage. Sparse mixture-of-experts models could then exceed GPU VRAM.

But an SSD is storage, not a replacement for the GPU’s high-bandwidth working memory. Even WiCi’s technical explanation contrasts around 14GB/s rated SSD throughput with roughly 1.8TB/s of GPU memory bandwidth in the high-end configuration. Realized throughput may be substantially below a drive’s peak rate.

A 2.8-trillion-parameter model stored at a straightforward four bits per parameter would require roughly 1.4TB just for raw weights, before format overhead.

WiCi’s advertised 1TB base unit and 2.8T inference result therefore need model-specific clarification about weight format, storage arrangement, and caching. Sparse activation reduces what must move per token, but it does not make the full model disappear from disk.

What should you buy instead for local AI?

The relevant comparison is the total working system, not the WiCi GPU’s sticker price alone.

We reviewed current consumer and professional options from NVIDIA, AMD, and Intel, plus used 24GB cards, complete unified-memory computers, conventional eGPUs, and rented GPU servers. Retail figures below are U.S. listings checked at the time of publication.

Availability and prices can change quickly, and these machines do not all run the same software.

Disclosure: This post includes Amazon affiliate links. If you buy through them, Popular AI may earn a small commission at no extra cost to you.

▪ For straightforward local AI: an RTX 5060 Ti 16GB in a normal PC

If 16GB VRAM meets your needs, the simplest comparison is an ordinary RTX 5060 Ti 16GB. ASUS lists its Dual RTX 5060 Ti 16GB OC around $800, versus $2,599 for the WiCi system.

Compare the exact variant and current offer rather than treating either quoted price as permanent.

NVIDIA’s CUDA support remains a straightforward route for many popular local AI packages. Sixteen gigabytes handles smaller quantized LLMs and many ComfyUI workflows, but not every large image pipeline or long-context model.

Find RTX 5060 Ti 16GB deals on Amazon

▪ For more VRAM per dollar: Intel Arc Pro B60 or AMD Radeon AI PRO R9700

The Intel Arc Pro B60 24GB has a U.S. Newegg listing at $999.99, offering 50% more VRAM than the WiCi 5060 Ti edition for about 38% of its appliance price. That comparison covers the card alone, so allow for the rest of the PC if you do not already own one.

Find Intel Arc Pro B60 deals on Amazon

Intel’s newer Arc Pro B70 moves to 32GB. They suit users prepared to choose compatible inference backends and accept rougher software support than CUDA, especially for specialized image-generation nodes.

The AMD Radeon AI PRO R9700 supplies 32GB, and a Sapphire U.S. listing is listed at $1,799.99, although that listing is currently sold out.

Find Radeon AI PRO R9700 deals on Amazon

For Linux users comfortable with ROCm, that capacity is useful. It is not a drop-in CUDA replacement on every Windows or ComfyUI workflow. Our Arc Pro B60 versus RTX 5060 Ti analysis explores why memory capacity and software maturity pull in different directions.

A used RTX 3090 24GB remains attractive for established CUDA workflows, but the old assumption that it is always a cheap bargain is obsolete. A completed U.S. eBay sale from October 6 was $1,325. That isolated transaction is a data point, not a reliable budget for every used 3090.

Compare the actual offer with newer cards, check the seller’s returns, test VRAM and hot-spot temperatures, and account for its substantial power draw.

More on the Arc Pro B60 for local AI:

▪ For a complete larger-memory computer: Mac Studio

Apple’s M5 Max Mac Studio starts at $2,499 with 36GB unified memory, including the CPU, GPU, storage, enclosure, and operating system.

Find M5 Max Mac Studio deals on Amazon

It can be an appealing quiet standalone inference box for compatible MLX or Metal workloads and some larger quantized models. Unified memory is shared with the OS and applications, so 36GB is not 36GB of freely available model memory.

macOS also does not offer ordinary NVIDIA CUDA compatibility. It is a serious alternative to a $2,599 WiCi 16GB unit for Mac-friendly local inference, not a universal replacement for an RTX workstation.

The NVIDIA DGX Spark provides a larger 128GB unified-memory AI environment, but it belongs in a different purchasing tier from a bare GPU. The manufacturer page confirms its memory capacity without displaying a current purchase price.

Its bandwidth and GPU characteristics differ from a high-end discrete RTX, and its cost makes sense only for specific memory-heavy development work.

▪ For remote use: reuse a desktop, or rent GPU time

If the appeal is that your phone, MacBook, or lightweight laptop can call a GPU elsewhere in the house, run Ollama or another supported inference server on an existing desktop. Configure client access over the trusted LAN or a properly secured VPN.

The noisy computer can stay in another room.

If you want an attached GPU instead, follow our wired eGPU buying guide and budget for the card, dock, PSU, cable, and host compatibility.

For occasional large-model work, Runpod’s listed RTX 5090 rental rates include approximately $1.19 per hour for Secure Cloud, with a less expensive Community Cloud tier.

Rent cheap GPU time on Runpod

Ten hours a week at that Secure Cloud compute rate works out to roughly $52 per month, excluding storage and other charges. Cloud rental does not meet an offline or strict local-data requirement, but it can prevent a five-figure purchase that sits idle most of the year.

The ownership and compatibility costs WiCi’s price hides

WiCi One’s attraction is the convenience of an appliance: compact enclosure, integrated cooling, storage, Wi-Fi networking, and one system intended to service several client devices.

Integration saves component-selection work, especially if you do not already own a suitable desktop.

Before relying on WiCi for production work, establish whether your exact application uses API mode or virtual-driver mode, whether the target operating system is supported now rather than planned, whether CUDA kernels or extensions operate correctly, and whether simultaneous clients cause substantial slowdown.

Check sleep/wake recovery, network interruptions, firewall behavior, firmware updates, and whether model downloads or telemetry ever leave the local network. An advertised Wi-Fi PHY maximum is not a guaranteed application transfer rate.

A particularly consequential purchasing detail is the manufacturer’s posted return and warranty language. It says buyers may cancel before shipment for a refund, but describes post-shipment sales as final, with defects to be reported within seven days for replacement and a one-year limited defect warranty.

Who should buy, wait, or skip WiCi?

▪ Consider WiCi One if wireless, device-level GPU access is essential to a specific mobile or multi-client deployment, you can validate your actual software stack before committing, and the integrated appliance saves enough engineering work to justify its premium. A developer experimenting with GPU disaggregation may rationally pay for capabilities that an ordinary inference server does not expose.

▪ Wait if you want WiCi for ComfyUI, PyTorch development, video generation, or local coding and have not seen reproducible tests for your applications on retail hardware. At $9,999, the RTX 5090 edition demands especially strong proof of reliable sustained use and a reason not to buy a conventional high-memory workstation or rent accelerators as needed.

▪ Skip it if your purpose is private chat, RAG, home automation, transcription, occasional local image generation, or serving models to other devices over Wi-Fi. Standard LAN inference already covers that central requirement, and its software and purchasing options are far less restrictive.

WiCi One is worth revisiting after independent retail tests

WiCi’s strongest idea is that a GPU could become a nearby shared resource without forcing every device to use a conventional remote API. The research suggests that reducing driver-call latency can work. But buyers cannot safely assume the research prototype’s results, the vendor’s impressive small-model figures, or its trillion-parameter demos will generalize to their own applications.

For most local AI users in October 2026, a supported desktop, a compatible Mac Studio, or intermittent cloud rentals remain better purchases.

For a conventional 16GB CUDA setup, an RTX 5060 Ti 16GB remains the more straightforward starting point, provided the rest of your PC can accommodate it. WiCi becomes worth another look when independent retail tests show a clear advantage over an ordinary LAN GPU server, with mature drivers and dependable post-purchase support. Until then, its wireless novelty carries a substantial price premium and compatibility risk.

More on external GPUs for local AI:

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

Imagine walking through an AI-generated castle, turning a corner, then returning to find an extra tower where there was empty sky. For a filmmaker exploring a shot, that might be manageable. For a game designer building a persistent world, it’s a problem.

Share

Google’s Genie 4 world model creates interactive environments with characters, changing weather, and synchronized sound. Its October 27, 2026 debut introduced native audio and Gemini-guided simulation. Google also acknowledges that objects and visual details can drift over time.

The demonstrations leave a harder question unanswered: Does the system maintain a reliable world, or mainly predict what that world should look like next?

What Genie 4 actually generates

Genie 4 takes descriptions and visual starting points and produces navigable scenes in real time. Users steer the camera with ordinary controls and can change a running scene through text, introducing an object, altering the weather, or directing an event. The next images respond to what a participant does, rather than following a fixed video clip.

The new version adds native audio, including environmental noise, music, and responsive character dialogue. That makes exploration more convincing, especially when people in the scene can respond as events unfold.

Google says Gemini Omni helps anchor appearance and behavior. Gemini 3.8 Flash acts as a guiding agent that watches incoming frames, plans steps, and checks whether they were completed. A separate experiment combines Genie 4 with Gemini 4 Argon to depict a humanoid robot playing checkers.

These are demonstrated capabilities and experimental Gemini integrations. They don’t establish that a robot trained in these environments would perform equally well outside the simulation. Generating a convincing view and preserving the scene behind it demand different evidence.

The object-permanence problem in Genie 4’s demonstrations

Consider three observations from viewers examining Google’s footage on Hacker News. Commenters describe a second castle appearing in a dragon sequence as the camera moves. Another notes a castle tower changing from square to round between roughly 0:29 and 0:40. In a Hong Kong motorcycle scene, a rider reportedly acquires a helmet after initially having none.

The helmet example is especially revealing because Google’s published motorcycle prompt specifies a male rider without a helmet. These are viewer observations, rather than a controlled audit. Their value is that they point to particular sequences other people can examine.

The footage also contains a Japanese railway platform crowded with moving passengers. Keeping a person recognizable after an obstruction or camera turn requires preserving identity and state. Producing another plausible commuter isn’t enough if the original person has effectively disappeared.

Google acknowledges that object permanence and visual details can drift during longer sessions, navigation, or complex edits. The same page says its demonstration sequences were shortened, so a polished clip cannot establish how reliably a longer session behaves.

In an early-access demonstration exploring scale, consistency, and interaction limits, Theoretically Media’s Tim Simmons examines similar questions.

The examples expose a reliability problem. They don’t establish that Genie 4 has no internal spatial representation. Its internal representation hasn’t been publicly characterized well enough to support that conclusion.

Does Genie 4 understand physics?

A world model can learn something useful about physical behavior by predicting how a scene changes when an object moves, a camera turns, or a person intervenes. Genie 4’s demonstrations show plausible collisions, falling objects, and moving people.

Physical plausibility is a weaker standard than physical accuracy. A watermelon bursting believably in one clip doesn’t establish that mass, force, momentum, or contact interactions remain consistent across hundreds of variations. A fluent-looking robot demonstration likewise doesn’t prove that a real machine would learn dependable movement from it.

Google’s launch examples illustrate physical behavior without providing a reproducible physics benchmark comparing predicted outcomes against measured reference trajectories. The company also lists complex interactions and spatial accuracy among its open problems.

A revealing evaluation would use repeatable tests. Place an object behind a wall, move away and return, then check its location and identity. Repeat the same collision under changed conditions. Ask an agent to pick up, put down, and revisit an object after several other actions.

Measure failures across many runs, including attempts that look less impressive than a launch trailer. That would test continuity, causality, and control separately from image quality.

Why Genie 4 cannot yet replace a game engine

A conventional game engine stores entities, positions, collision rules, inventory, and game state. When a player walks away from a locked door, the engine doesn’t need to invent whether it’s still locked. The state remains available until something changes it.

Genie 4 generates the experience dynamically. An imaginary walk-through becomes possible without an artist building every room or a developer coding every behavior. Creators still cannot assume stable level layouts, reproducible gameplay, reliable scores, or persistent puzzles.

Personalized media is a longer-term possibility, a direction explored in our analysis of culture on demand. Gameplay systems, though, need persistent state as well as impressive scenery.

What Genie 4’s two-minute figure actually means

TechCrunch reports up to two minutes of scene consistency. That’s about double the 60-second limit of the Genie 3-powered Project Genie experience. It isn’t a clean comparison of the two research models’ memory.

Google’s original Genie 3 research description already claimed broadly consistent environments lasting several minutes, with visual memory reaching about one minute into the past. Its January 2026 Project Genie rollout separately imposed a 60-second generation cap on the product.

Session duration, visual memory, and perfect object permanence measure different things. A two-minute experience should not be mistaken for two minutes of flawless spatial memory.

Google Genie 4 access: Who should try it?

As of October 29, 2026, Genie 4 remains a restricted research preview. Google plans to extend access through Project Genie to Google AI Ultra subscribers and, separately, to selected Gemini API and Google AI Studio partners. An Ultra subscription alone doesn’t establish access today.

Google’s published access details announce the preview and planned rollout, without generally available Genie 4 API pricing or downloadable model weights. You cannot presently install this model on your own GPU.

Google also says generated video and audio carry SynthID watermarks and that the service uses safety restrictions. Its launch announcement doesn’t provide Genie 4-specific retention or training-use terms sufficient to assure users that sensitive prompts and creative material stay private. A cloud-hosted research preview is a poor place to make confidential production assets your sole copy.

Filmmakers and game designers should watch Genie 4 for fast exploration of scenes and camera ideas. Robotics researchers should demand measurable correspondence with the real world before trusting it for physical training. Keep conventional tools in the workflow whenever stable, editable environments are essential.

Genie 4 convincingly generates the experience of being somewhere. The evidence so far doesn’t show that it can reliably remember everything about that somewhere when you turn your back.

More on AI media-on-demand:

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

Moving ComfyUI to a new PC can leave you with every workflow JSON file intact and a screen full of missing-node and missing-model errors. To preserve a working setup, back up the files and record the software environment that runs them. Restore both into a separate installation, and keep the original PC untouched until the new one completes a representative workflow.

Share

Quick fix: back up the whole ComfyUI setup

Close ComfyUI on the old computer.

Copy your models, custom nodes, user data, workflows, configuration, and any inputs or outputs you need.

Record the Python and PyTorch environment before disconnecting the machine.

On the new PC, start with an appropriate ComfyUI installation, restore the files into its actual data directories, repair model paths, and install missing dependencies.

Keep the working setup and backup until the restored installation passes a generation test. A Manager snapshot alone does not include every file you need.

Why copying a workflow or custom_nodes folder fails

A workflow JSON describes a graph and its settings. It does not bundle the model weights, Python libraries, custom-node code, or external files referenced by that graph. ComfyUI supports JSON workflow export, separate model directories, and custom nodes, so a complete move needs more than the graph file.

A missing-node warning usually means the extension is absent or failed to import. A missing-model warning means the model file is absent, stored under a different category, or outside ComfyUI’s search paths. A Python import error usually points to an absent or incompatible package. Check which failure you have before changing files or reinstalling packages. Each problem needs a different fix.

1. Diagnose and back up the old installation

First identify whether you use Windows portable, Desktop, or a manual Python installation. Check the startup console or logs for the actual user directory, model directories, and Python executable, especially if you use custom launch flags. Record your GPU, driver, Python and PyTorch versions, ComfyUI release or Git commit, and essential custom-node versions. Keep those notes with the backup so you can compare the old and new environments.

Make one backup folder containing:

• models/ and any external model libraries, including checkpoints, diffusion models, text encoders, LoRAs, VAEs, and upscalers.

• custom_nodes/, including manually installed extensions and their files.

• user/, including saved workflows, settings, and Manager data. Export important workflows separately as .json too.

• input/, important output/ files, and any custom datasets or reference assets.

• extra_model_paths.yaml, other launch and configuration files, and a note of absolute paths, symlinks, and launch arguments.

Some folders may live outside the installation root. Check where your installation actually reads its data instead of assuming everything sits under ComfyUI/. An external model library still needs a backup even when the app folder is copied in full.

If ComfyUI-Manager is installed, save a snapshot as another recovery aid. Its snapshot support is incomplete for custom nodes not managed by Git. The snapshot records installation state. Keep a separate backup of your models, workflows, and Python environment information.

For a manual Python installation, activate the working virtual environment and run:

python --version
python -m pip freeze > comfyui-packages.txt
python -m pip check

Keep comfyui-packages.txt with the backup. Record git rev-parse HEAD from a Git-based ComfyUI checkout when available. A portable installation can query packages using its own embedded Python, commonly python_embeded\python.exe, rather than the system Python. The package record needs to describe the environment ComfyUI actually uses.

2. Restore ComfyUI on the new PC

Use the restore method that matches your installation. A portable folder can include its Python runtime, while Desktop stores application files separately from its working data. For a manual installation, rebuild the Python environment for the new operating system and GPU.

▪ Windows portable: copy the folder and check compatibility

On another compatible Windows PC, copying the complete ComfyUI_windows_portable folder is often the closest thing to a direct transfer. It includes the application, embedded Python environment, and launch scripts. Choose an appropriate official Windows portable build if the new GPU needs a different package or runtime.

Copy the folder to a normal writable location, such as D:\AI\ComfyUI_windows_portable, and use the launch script appropriate to the new GPU. If ComfyUI starts but nodes fail to import, reinstall their dependencies using that installation’s Python. Installing them into another Python on the PC won’t repair the environment running ComfyUI. Don’t blindly carry over GPU-specific wheels when switching hardware.

▪ Desktop: restore the data to the right installation

Desktop installations separate app files from user-selected model and workflow storage. In the original Desktop app, Windows settings live in %APPDATA%\ComfyUI, including config.json and extra_models_config.yaml. The basePath setting points to the main data directory. Newer Comfy Desktop builds support separate installations and importing existing setups.

Install Desktop on the new PC, create or import a separate setup, and locate its model, custom-node, user, input, and output directories. Restore your backup into those locations. Recreate external model mappings and compare app configuration where necessary. Avoid blindly replacing the new app’s binaries or entire configuration. Paths and installation formats can differ across Desktop generations, so an old configuration file may point to folders that don’t exist on the new computer.

▪ Manual Python: rebuild the environment

Copy your ComfyUI checkout and files, but create a new virtual environment with a compatible Python version. Follow the ComfyUI manual installation instructions for the appropriate PyTorch build for your new operating system and GPU. From the ComfyUI directory, run python -m pip install -r requirements.txt. Then install each required custom node’s documented dependencies in that same environment.

Use the saved comfyui-packages.txt to compare versions. Don’t treat it as a universal reinstall command. Packages pinned to a former CUDA build, platform, or Python version may fail on the new machine. If possible, restore the recorded ComfyUI and node revisions before updating anything. Changing versions during the move makes it harder to tell whether a failure came from the migration or an update.

3. Fix missing models and restore Manager snapshots

If model files are present but dropdowns are empty, check extra_model_paths.yaml. Put base_path and model-category mappings beneath a named section. Replace old drive letters with paths that exist on the new PC, then restart ComfyUI and inspect the startup log. For Desktop, verify which configuration file the launcher actually passes. Check folder keys, YAML structure, and model-path configuration errors if the files still don’t appear.

Recent Manager versions store configuration and snapshots under user/__manager/, while older versions used user/default/ComfyUI-Manager/. During the security migration, old snapshots are not automatically migrated. Check your backup before copying older snapshots into the protected location. A snapshot restore takes effect after a restart, so selecting Restore is not the last step.

4. Test the restored workflow before deleting anything

Open a saved workflow that uses your most important model and several custom nodes. Check that model dropdowns contain the correct files, nodes load without warnings, and the workflow completes a generation. Compare the new output for obvious differences. Don’t demand pixel-identical results across different GPUs, package versions, or nondeterministic operations.

Keep the original installation and backup until these checks pass:

• Your saved workflows and required input assets are accessible.

• Models and custom nodes appear, with no startup import failures.

• At least one representative workflow runs and writes a usable output.

If the workflow still fails, keep the new installation separate and read the first relevant startup traceback. Check for ModuleNotFoundError, missing model paths, or CUDA/PyTorch compatibility before changing more packages. For failures introduced by version changes, follow the steps to recover ComfyUI workflows after a broken update.

Keep ComfyUI recoverable for the next PC move

Keep model libraries outside app-update directories where practical. Save explicit workflow JSON exports and record package and node versions before major changes. Treat custom nodes as third-party code and inspect unknown scripts before running them. Don’t copy tokens or API keys indiscriminately into backups or share logs containing private paths and credentials.

Preserve the old installation, restore into a separate one, and run your hardest essential workflow before switching computers for good. A successful launch gets you to the canvas. A completed workflow confirms that the files, paths, nodes, and dependencies survived the move together.

More on ComfyUI troubleshooting:

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

A solo developer can maintain useful open-source software for years and still fail the new posting rules at Reddit’s r/opensource. The community’s October 24, 2026 AI ban reaches beyond low-effort generated code. It adds requirements for a project’s age, contributor count, existing audience, and its creator’s ability to speak English. Legitimate developers can be turned away before anyone examines their work.

Share

The backlash has already prompted a promise to revisit the rules. As of October 27, the gap between the sweeping announcement and the exceptions moderators say they’ll make remains unresolved. Independent maintainers face a practical problem: access to an established discovery channel now depends on criteria that have little connection to software quality.

What the r/opensource AI ban actually covers

▪ On October 24, moderator u/Wolvereness announced that projects using AI, built with AI, or intended for AI were unwelcome at r/opensource. The same post imposed eligibility requirements on projects with no AI involvement at all.

▪ Developers advertising a project were told it needed at least one year of active maintenance, multiple contributors, and an existing community. The contributor threshold was described as roughly three or more, subject to judgment. Common school-style projects were excluded, and requests for maintainers or contributors were no longer welcome. The longstanding requirement for an Open Source Initiative-approved license remained.

▪ Posters also faced an existing one-year Reddit account minimum with significant activity. Asking for an exception after a failed posting attempt could lead to a permanent ban and mute. Registered nonprofit organizations could request approval in advance for exemptions from the project and account minimums. An ordinary solo maintainer had no equivalent route through those requirements.

▪ The language provision went further. People who couldn’t speak English were told to find another community because moderators said they couldn’t distinguish an AI-written post from an AI-translated one. A developer could therefore be excluded because of the tool used to communicate, regardless of the quality of the software being discussed.

These restrictions govern participation in one subreddit. They don’t change a project’s license, remove its GitHub repository, or impose a Reddit-wide ban. But r/opensource is a discovery channel. Losing access means losing a place to introduce a project, reach potential users, and attract collaborators who might help maintain it.

Moderator discretion decides which projects get seen

The policy leaves substantial room for a moderator’s judgment. A one-year history and a contributor count are easy to measure, but neither establishes whether code is trustworthy. “Uses AI” could describe generating most of a repository, asking an assistant to review a function, adding speech recognition, or building a tool that works with local models. Those uses create different questions about quality and responsibility.

The moderator later suggested that incidental accessibility features, including automatic captions, could be allowed. On October 26, a follow-up said adjustments would be made. The moderator also said Linux would remain welcome. That clarification left smaller projects without a settled test they could apply before submitting.

An established project can receive reassurance that a newcomer has little basis to expect. Developers must anticipate whether moderators consider their work sufficiently established or obviously acceptable. That uncertainty adds another obstacle for someone who already lacks the audience and contributor base the announcement requires.

The Open Source Definition concerns license permissions, including reuse, modification, redistribution, and nondiscrimination. It sets no minimum project age, contributor headcount, or prior popularity. A private discussion forum can choose what it publishes, but its admission rules don’t determine whether software qualifies as open source. r/opensource has added participation thresholds to a software category defined on different terms.

Solo maintainers and newcomers have the least room to comply

Consider a lone maintainer who has kept a small utility secure and working for years. Requiring three contributors doesn’t improve that utility. Under the announced threshold, it makes the author ineligible to introduce it to the community. A young team faces a similar trap: it needs collaborators and users to become established, yet cannot use the forum to find them until it is already established.

The English rule compounds the problem. A developer might write clear documentation in another language and use translation to join an English-language discussion. Excluding that person because they used AI translation blocks participation before the discussion can begin. Translation errors need attention, but requesting clarification, including the original text, or using ordinary translation tools would give moderators something concrete to assess.

Objections also came from inside the moderation team. In an October 25 public response, fellow moderator Dan Brown, known as u/ssddanbrown, said he disagreed with the changes and could see no prior consultation among moderators. He credited u/Wolvereness with doing most of the difficult moderation work. Brown updated his post on October 26 to say he was leaving the team, citing the escalating dispute and stress.

A new subreddit, however, doesn’t immediately replace an established community’s audience or visibility. Developers can move their submissions more easily than they can move the people they hoped would read them.

Claims circulating about inconsistent bans and hostile treatment need individual documentation before they can support broader conclusions about enforcement. The announced requirements already provide enough reason to question the policy’s effect on independent developers.

AI spam is real, but age and headcount are poor quality tests

Brown’s account grants the strongest argument for restrictions: hastily generated projects and promotional posts consume scarce moderator time. He described one colleague doing most of that work and said AI-made submissions were pushing substantial discussion out of view. Protecting volunteer attention is a reasonable goal. A community that becomes a launch-promotion feed can lose the discussion that made it useful.

Project age and headcount remain weak substitutes for quality. A three-person team can produce a poorly tested project. One maintainer can release a carefully documented utility with reproducible tests, a clear license, and a commitment to fixing bugs. If both otherwise meet the rules, the announced contributor threshold can admit the former and exclude the latter. Having more names in a repository doesn’t establish that anyone checked the work.

Major projects already use alternatives tied to what contributors submit. The LLVM policy permits AI-assisted contributions while requiring human review, accountability, and enough understanding to answer reviewers’ questions. It allows translation or copy-editing of descriptions, but prohibits autonomous agents from posting without human approval. The contributor must do the checking before asking someone else to spend time on the submission.

The Linux kernel’s guidance requires a human to review generated code, satisfy licensing requirements, and take responsibility for the contribution. These requirements give reviewers conduct and evidence to assess. A contributor can meet them by doing the work, without first assembling a larger team or waiting for a project anniversary.

A September 2026 study of 281 AI contribution policies found that 83.3% permitted or encouraged AI-assisted code contributions. Of the policies examined, 67.3% required substantial human involvement and 43.4% explicitly assigned accountability. The sample focused on policies in popular repositories, rather than every open-source project. It shows that blanket exclusion is far from the only available response, without establishing which policy works best in every community.

Another Reddit community, r/selfhosted, offers a megathread route for projects younger than three months. Brown endorsed that lighter approach. It limits repeated launch promotion while retaining a route for newcomers to show their work. Early-stage projects have somewhere to go while they build a maintenance history.

Our guide to AI-generated pull requests recommends small, reviewed changes, proof of testing, and a responsible human who can answer questions. Those standards address the work a submission creates for someone else. They don’t require a project to become popular before it is allowed to be discovered.

More on AI-assisted software development:

Independent developers need discovery channels they can keep

▪ Keep your repository, documentation, changelog, license, and issue tracker available outside any one social forum. If you use AI, be able to explain which parts you reviewed, how you tested the result, and who will maintain it. A public history of fixes and responses to issues provides stronger evidence of responsibility than an arbitrary contributor count.

▪ Before posting to r/opensource, read the current rules instead of assuming the October 24 announcement is the final policy. Consider other relevant communities for early-stage work, respect their submission rules, and avoid repeating the same promotional message everywhere. An alternative forum is useful only if its members have a reason to engage with the project.

If you run a community, publish clear acceptance criteria and provide a route for young projects. Judge the burden a submission creates and the evidence its author supplies. Trying to infer how many tokens produced a repository gives contributors little guidance about what they must do to earn a review.

The October 26 promise of adjustments leaves a specific question open: will r/opensource replace broad eligibility tests with requirements tied to quality and human responsibility, or keep granting exceptions by reputation? Until revised rules are published and applied consistently, independent developers should keep their discovery and collaboration channels diversified. Maintain a public record of the work, and give potential users more than one place to find it.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

Yes, an external GPU can run local LLMs and ComfyUI effectively. An eGPU for local AI is most appealing when you already own a capable computer and want more VRAM without replacing the whole machine. But the catch is bandwidth. USB4 and Thunderbolt can handle AI inference well when a model stays entirely in GPU memory, but loading large models, CPU offloading, and some multi-GPU workloads can expose their limitations.

Share

For a laptop, USB4 or Thunderbolt is usually the practical route. A dock such as the MINISFORUM DEG2 lets you reuse a desktop graphics card, provided the host supports the connection. For a mini PC with OCuLink, that connection is generally the better choice. If you’re building a serious multi-GPU AI machine from scratch, internal PCIe remains preferable.

Disclosure: This post includes Amazon affiliate links. If you buy through them, Popular AI may earn a small commission at no extra cost to you.

Quick verdict: which eGPU connection should you buy?

Best value for an OCuLink mini PC: The MINISFORUM DEG1 is a straightforward PCIe 4.0 x4 dock, listed at $109 in the U.S. manufacturer store on October 27, 2026. You’ll need a compatible OCuLink port, GPU, and separate power supply.

Best versatile dock: The MINISFORUM DEG2 combines OCuLink with USB4 v2/Thunderbolt 5 compatibility. At the manufacturer’s listed $239.90, it makes sense if you want to use one desktop GPU with different computers.

Best DIY route for an existing USB4 or Thunderbolt 4 laptop: The ADT-Link UT3G is a 40Gbps USB4-to-PCIe adapter. It can serve a single-GPU AI setup, although its exposed-board design, separate power supply, and inconsistent retail availability make it less convenient than a complete enclosure.

Skip the eGPU purchase if your main workload constantly transfers model data between CPU RAM and VRAM, or if you’re planning a multi-GPU workstation where fast GPU-to-GPU communication is important.

USB4 vs Thunderbolt vs OCuLink: what changes for local AI?

An eGPU connects a desktop graphics card through a much smaller data link than a typical internal PCIe slot. The GPU still has its own VRAM and performs calculations locally. The restricted connection primarily affects how quickly data moves between the host computer and the card.

▪ USB4 and Thunderbolt 3/4: convenient, but shared bandwidth

A conventional USB4 40Gbps connection offers a theoretical link rate of 5GB/s before protocol overhead. Thunderbolt 3 and 4 use comparable 40Gbps links, although their PCIe tunneling implementations and minimum requirements differ.

USB4 dynamically shares bandwidth between different protocols. Intel specifies 40Gbps for Thunderbolt 4 and 80Gbps bidirectionally for Thunderbolt 5.

Neither number is a guarantee of GPU transfer speed. Controller design, PCIe tunneling, other connected devices, firmware, and cable capability all affect the usable bandwidth.

A USB-C connector alone does not establish eGPU compatibility. An ordinary USB 3.2 port cannot run a PCIe graphics card through a USB4 eGPU adapter.

▪ Thunderbolt 5 and USB4 v2: faster, with conditions

Thunderbolt 5 raises the available link bandwidth to 80Gbps bidirectionally and increases PCIe tunneling capability. USB4 v2 also supports higher-speed operation.

These improvements can reduce bottlenecks during large transfers, but both the computer and dock must support the required connection mode. Attaching an 80Gbps dock to a 40Gbps laptop doesn’t upgrade the laptop’s controller.

For a local LLM that is already loaded entirely into VRAM, spending more on Thunderbolt 5 may produce little benefit during ordinary token generation.

▪ OCuLink: a more direct PCIe connection

OCuLink commonly exposes four PCIe 4.0 lanes directly from the host. That provides approximately 7.9GB/s of theoretical bandwidth in each direction before overhead, without USB4’s tunneling layer.

The connection is attractive for mini PCs that already expose an OCuLink port, particularly when model loading or repeated transfers are substantial.

An OCuLink connector also needs to be wired to a usable PCIe host interface. It cannot be created by attaching an ordinary passive adapter to a USB-C port.

Which connection is best for your AI workload?

▪ For a laptop with USB4 or Thunderbolt 4, choose a USB4 eGPU dock after confirming PCIe tunneling and external GPU support. A Thunderbolt 5 laptop can justify a Thunderbolt 5 dock for repeated large transfers. A mini PC with OCuLink benefits from an OCuLink dock’s bandwidth and relatively low cost.

▪ For a small desktop without GPU clearance, use external PCIe/OCuLink if supported, or USB4 otherwise. Compare the full cost with a case or motherboard upgrade. Single-GPU Ollama or llama.cpp inference can work over USB4, Thunderbolt, or OCuLink, but prioritize enough VRAM for the model and KV cache.

▪ Prefer internal PCIe for multi-GPU LLM inference. External layer splitting may work, but communication and stability become more complicated. ComfyUI image generation can use any supported eGPU with sufficient VRAM, although repeated model loading and offloading can be costly. Frequent CPU-to-GPU transfers favor internal PCIe or a higher-memory GPU, since more bandwidth can be more valuable than faster GPU cores.

The biggest mistake is assuming that a 40Gbps eGPU automatically runs local AI at a fixed percentage of desktop performance. Published inference results show much more variation.

What published local LLM benchmarks actually show

Use tests that measure AI workloads directly when judging an eGPU for local LLMs. Gaming frame rates are a poor substitute because game rendering, model loading, prompt processing, and token generation stress the connection differently.

In Jan’s published tests, Mistral 7B Q4_K_M running through llama.cpp produced 100.43 tokens/s on a desktop RTX 4090 and 62.22 tokens/s on a Thunderbolt 3 RTX 4090 eGPU. The external card was connected to a Razer Blade 14.

That’s a substantial difference, but it isn’t a controlled measurement of Thunderbolt overhead alone. The test used different host computers, including different CPUs and PCIe connections. It demonstrates that the eGPU worked and remained useful. It doesn’t establish a universal 38% eGPU penalty.

A llama.cpp benchmark comparing internal and external RTX 3090s, published by developer slewsys, shows why prompt processing and generation need separate measurements. Using an HP Z8 G4, internal and Thunderbolt-connected RTX 3090 cards, and a partially GPU-offloaded gpt-oss-120b model, the tester recorded:

For 2,048-token prompt processing, the internal RTX 3090 recorded 303.84 tokens/s, compared with 140.46 tokens/s over Thunderbolt 3. In the 128-token generation test, the results were 2.33 tokens/s internally and 2.27 tokens/s externally.

The cards were different board implementations, so the comparison has limits. Still, the change in prompt-processing speed was much larger than the change in token generation.

There’s also evidence that modern non-NVIDIA cards can work externally. An Intel Arc Pro B70 USB4 setup documented in October 2026 uses a 32GB GPU with llama.cpp on a Minisforum mini PC. Its author reports successful full-GPU inference, including Qwen-family models, and approximately 20–30-second cold loads when switching models. Those results describe one configured system, rather than a comparison against the same GPU installed internally.

Taken together, these examples support a practical rule: an eGPU is most attractive when you load a model once, keep it in VRAM, and reuse it.

Where eGPU bandwidth affects AI performance

Model loading is an obvious bottleneck. Weights must travel from storage and system memory to the graphics card. A restricted external link can make cold starts and frequent model changes noticeably slower.

Prompt processing is more complicated. The CPU, inference backend, attention implementation, batch size, and model placement all influence the result. When execution repeatedly crosses the host connection, USB4 or Thunderbolt can become expensive.

During token generation, a fully GPU-resident model can perform much of its work inside the card. The GPU’s own memory bandwidth is often more important than the external cable. That’s why a 40Gbps link can still deliver useful decoding performance.

Once model layers spill into system RAM, the calculation changes. The CPU may process some layers while the GPU processes others, or data may move across the host connection during execution. Neither arrangement benefits from treating system RAM as interchangeable with VRAM.

Multi-GPU inference introduces another layer of complexity. llama.cpp supports different ways to split a model across GPUs. Layer splitting can be relatively practical because work crosses device boundaries less frequently. Tensor splitting creates greater communication demands and has additional software limitations.

Two GPUs also don’t automatically become one large, unified memory pool for every AI application.

For ComfyUI, the decisive question is whether the active models and intermediate data fit in GPU memory. A workflow that keeps its denoising model resident is a better candidate than one that repeatedly loads checkpoints, swaps text encoders, or offloads components to RAM. ComfyUI supports NVIDIA, AMD, and Intel GPUs, although installation paths and backend compatibility differ.

The external GPU docks worth considering

▪ MINISFORUM DEG1: best budget dock for OCuLink mini PCs

The DEG1 is a straightforward choice for someone who already owns an OCuLink-equipped mini PC and a compatible desktop GPU.

Its PCIe 4.0 x4 connection avoids USB4 tunneling, while the open-frame design accommodates large desktop cards without the dimensional restrictions of a conventional enclosure. The U.S. manufacturer store listed the DEG1 at $109 on October 27, 2026. The MINISFORUM DEG1 is also listed on Amazon.

The dock does not include a desktop GPU or ATX/SFX power supply. It also cannot help a laptop whose only expansion connection is USB4.

Buy it when you have a native OCuLink port and want the least complicated external PCIe setup. Skip it if you’re hoping to connect it through an ordinary USB-C port.

Find MIINISFORUM DEG1 deals on Amazon

▪ MINISFORUM DEG2: best for USB4 v2, Thunderbolt 5, and mixed hosts

The DEG2 makes more sense when you need flexibility. It supports OCuLink and USB4 v2/Thunderbolt 5 connectivity, adds an M.2 SSD slot and peripheral connections, and can be used with a desktop graphics card and separate ATX/SFX power supply.

The manufacturer listed the DEG2 at $239.90 on October 27, 2026. The MINISFORUM DEG2 Amazon listing was around $247. Treat both as dated price references, since prices can change.

One important caveat: the extra connectivity does not guarantee better local LLM decoding. On a 40Gbps host, the DEG2 still operates within the host’s connection capability. Its premium is easier to justify if you have Thunderbolt 5, expect to upgrade your computer, or intend to share one GPU between machines.

Buy it for that flexibility. Skip it if you already have OCuLink and need only an inexpensive GPU connection.

Find MINISFORUM DEG2 deals on Amazon

▪ ADT-Link UT3G and UT4G: for hands-on USB4 builds

The UT3G is useful because it exposes the basic ingredients of a USB4 eGPU without bundling them into an expensive enclosure. It uses the ASMedia ASM2464PDX controller and supports PCIe tunneling over a compatible 40Gbps USB4 or Thunderbolt connection.

ADT-Link’s UT4G-BK7 and UT4G-BK8 variants add mounting brackets. They remain 40Gbps adapters, so the UT4G name does not mean an 80Gbps host connection.

Find ADT-Link UT4G-BK7 deals on Amazon

Retail availability is inconsistent. Compare the total cost of any ADT-Link UT3G eBay offer with the DEG2 before buying a bare adapter. We couldn’t verify a suitable current U.S. Amazon listing for the exact UT3G or UT4G variant. Check the offer’s condition, power-supply requirements, and return terms before paying.

Find ADT-Link UT3G deals on Amazon

These boards suit technically comfortable users who can handle PSU wiring, exposed components, and operating-system troubleshooting. A complete enclosure is a better choice when you need protection against accidental contact or frequent transport.

Which GPU should you connect?

Choose the GPU capacity before the dock. Determine the VRAM requirement of the models you intend to run, including their KV cache and other memory overhead.

▪ A 16GB GPU can be enough for smaller quantized LLMs and many ComfyUI workflows. A 24GB card opens up larger model choices. A 32GB card offers more room for bigger models and longer contexts. Plan for model weights, KV cache, and context when estimating local LLM VRAM requirements.

▪ An existing RTX 3090 is a sensible eGPU candidate because it has 24GB of VRAM and established CUDA support. However, buying one specifically for an eGPU is no longer an automatic bargain. U.S. used-market observations include a completed RTX 3090 eBay sale at $1,325 on October 6, 2026. A single sale does not establish the going rate, but it shows why the card’s reputation as a cheap 24GB option needs checking against actual offers. Check the actual cost against newer alternatives.

▪ Higher-capacity alternatives also deserve attention. The AMD Radeon AI PRO R9700 provides 32GB, as does the Intel Arc Pro B70. NVIDIA’s newer consumer and professional cards span additional VRAM and performance tiers, including 32GB GeForce and higher-memory workstation models.

NVIDIA remains the easier default for users who rely on CUDA-specific packages and ComfyUI custom nodes. AMD’s ROCm and Intel’s oneAPI/SYCL paths are viable for selected workloads, but require more attention to software compatibility. Check Ollama’s supported GPUs and backend requirements for the card and operating system you intend to use.

A compact integrated eGPU such as the 8GB GPD G1 may suit portable graphics work. It isn’t our choice for a buyer whose primary goal is substantially increasing local LLM capacity.

More on VRAM for local AI:

The hidden cost of an eGPU setup

The advertised dock price is only part of the purchase. A low dock price helps most when you can reuse the GPU and power supply. If you need to buy both, compare the full setup with a desktop upgrade before deciding that the external route saves money.

An open eGPU dock needs a suitable power supply, the correct GPU power connectors, a compatible cable, and adequate clearance for the graphics card. High-power cards also create heat and noise outside the computer chassis.

Check the exact GPU’s length, thickness, connector placement, and power requirements. A power supply rated for the card’s sustained draw may still be unsuitable if it lacks the correct connectors or enough transient headroom.

The host computer needs scrutiny too. Firmware settings, BIOS support, PCIe resource allocation, IOMMU behavior, operating-system authorization, and driver compatibility can determine whether a theoretically compatible dock works reliably.

Windows and Linux are practical starting points for supported NVIDIA eGPU configurations. Apple’s conventional macOS eGPU support requires an Intel-based Mac. There is now an experimental alternative: TinyGPU supports selected AMD and NVIDIA cards over USB4/Thunderbolt through the tinygrad software stack. That doesn’t provide general, drop-in compatibility with every Ollama, CUDA, or ComfyUI workflow.

Don’t budget for a Mac eGPU as though it were an ordinary Windows CUDA setup.

How to compare eGPU benchmarks properly

Any performance comparison should separate loading, prompt processing, generation, and image creation. A single tokens-per-second figure misses too much.

Measure cold model loading in seconds from an unloaded state to a ready model. Record prompt-processing tokens/s alongside prompt length, batch size, and context. Measure token-generation tokens/s with a stated output length and a warm model.

For CPU offloading, record layer placement, RAM/VRAM use, and throughput. For ComfyUI generation, compare seconds per image with the model, resolution, steps, sampler, and seed fixed. Stability testing should record GPU detection, reconnect behavior, crashes, and failed jobs.

A credible comparison also identifies the GPU, dock, host CPU, cable, operating system, drivers, software versions, quantization, and whether the model fits entirely in VRAM.

Without those details, “OCuLink is 20% faster” or “Thunderbolt barely loses performance” tells a buyer very little.

Should you buy an eGPU or build a separate AI computer?

Buy an eGPU when you already have a capable laptop or mini PC, need one additional GPU, and expect to keep your usual LLM or image-generation workload in VRAM. The purchase is particularly attractive if you already own the GPU and a suitable power supply.

Build or upgrade a desktop when you’re buying the CPU, GPU, dock, power supply, and other components together. The external connection adds cost and another source of compatibility problems without necessarily saving enough money to justify it.

A desktop is also preferable for users planning two or more GPUs. With dual RTX 3090s for local AI, account for power and software limitations as well as the combined VRAM capacity.

An older small desktop might need only a larger case, better power supply, or different motherboard to accommodate another card. Price those changes before committing to an elaborate external setup.

For occasional experimentation, renting a cloud GPU can be cheaper than buying an expensive card that spends most of its life idle. For regular private workflows, owned hardware becomes more attractive because it avoids recurring compute charges and dependence on a remote service.

More on the RTX 3090 for local AI:

Buy an eGPU for the computer you already own

For a mini PC with OCuLink, an inexpensive dock such as the MINISFORUM DEG1 is the sensible starting point. Pay extra for a MINISFORUM DEG2 when its USB4 v2/Thunderbolt 5 flexibility serves a computer you use or intend to buy. For a USB4 laptop, a supported external GPU can run local LLMs and ComfyUI effectively when the workload fits in VRAM.

The best reason to use an eGPU is to extend a computer you already own. The worst reason is to avoid building a desktop while spending almost as much money on a complicated external substitute.

If you’re chasing bigger models through constant CPU offloading or assembling a serious multi-GPU system, put the money toward more usable VRAM and a proper internal PCIe configuration instead.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

If you use Claude for writing, coding, research, or business, Anthropic’s IPO filing answers a question that sits behind every interaction: who controls the company setting Claude’s rules? The proposed structure gives its seven co-founders 50.1% of voting power on general shareholder matters through a single special share. A separate trust gets to elect most of the board. Public investors would be able to buy into Anthropic without gaining ordinary control over its direction.

Share

The arrangement could protect long-term research from demands for faster financial returns. It also concentrates authority in a small group whose judgments on AI safety, access, and acceptable uses may shape Claude for years. Buying shares and paying for a subscription would leave those decisions largely in the same hands.

What Anthropic filed on October 26

Anthropic filed its preliminary S-1 registration statement on October 26, 2026, proposing a Nasdaq listing under the ticker ANT. The filing describes a proposed offering. Its price, final share count, and timing were not settled in the initial prospectus, and the filing does not establish that the IPO is complete.

Anthropic is already a Delaware public benefit corporation. Its stated purpose is the responsible development and maintenance of advanced AI for humanity’s long-term benefit. The company says this structure requires directors to balance shareholders’ financial interests, the interests of people affected by its actions, and that public purpose. The IPO would retain that status while adding a special founders’ voting vehicle alongside the existing Long-Term Benefit Trust (LTBT).

Shareholder voting control and board-election control are split between two groups. Ordinary IPO buyers would not acquire either form of control. An individual founder would not personally hold all the powers described in the prospectus, either.

Anthropic’s five share classes, explained

The proposed capital structure separates economic ownership from voting rights. Some shares carry a financial stake. Others exist chiefly to assign governing powers.

Two shares stand out. The sole Class F share gives the Founder LLC a voting majority even if it owns far less than half of Anthropic’s economic value. Issuing additional Class A stock does not dilute that general-vote percentage while Class F remains in force. Selling more stock to the public would therefore not, by itself, erode the founders’ majority.

The sole Class T share works differently. It lets the LTBT choose most directors, without carrying 50.1% of ordinary shareholder votes. Adding the two powers together as though they were percentages of the same vote would misrepresent the structure. One governs general shareholder decisions. The other reserves control over most board seats.

The control chain from shareholders to Claude

The LTBT and Founder LLC would collectively be able to elect every director. The trust selects the majority. The founders’ voting vehicle normally determines elections for the remaining seats and the outcome of general shareholder resolutions. The board oversees the company and supervises management. Executives and staff then decide how Claude is built, trained, deployed, priced, and moderated through the company’s decision-making processes.

Trustees do not personally approve each Claude refusal, content-filter adjustment, or API restriction. The S-1 explicitly denies the trust and its trustees authority over day-to-day management or strategy setting. Their influence runs mainly through their choice of directors and the advice they provide. Following that chain avoids attributing a product decision to someone whose formal power is to help choose the people overseeing it.

The founders also act as a group. The Class F share belongs to an LLC whose initial members are Dario Amodei, Daniela Amodei, Tom Brown, Jack Clark, Jared Kaplan, Sam McCandlish, and Christopher Olah. If a majority of the continuing founders cannot agree on how to vote it, the filing generally provides for its votes to follow the Class A voting proportions, subject to quorum requirements. The 50.1% figure should not be mistaken for personal voting control by the CEO.

The trust is designed to have financially disinterested trustees. Anthropic says they hold no equity, do not share in profits, and select new trustees in consultation with the company. Those arrangements may reduce incentives to maximize the next quarter’s share price. Trustees still are not elected representatives of Claude users or the general public. Financial independence answers one accountability question, while leaving the question of whom they represent unresolved.

Can public shareholders change Anthropic’s AI policies?

Usually, they could not force a change by winning a shareholder vote. Anthropic warns that Class A holders generally cannot determine shareholder-vote outcomes or director elections, regardless of how they vote, except in specified circumstances such as founder disagreement.

The structure deliberately protects against unwanted takeovers and investor campaigns to replace directors. It also removes an ordinary route for holding company leadership accountable. Public shareholders could sell, criticize management, exercise applicable legal rights, and influence the market’s willingness to finance Anthropic. They would not ordinarily be able to vote out the trust’s director slate. Owning stock would give them financial exposure without comparable governing power.

Anthropic expects to qualify as a Nasdaq controlled company and use an exemption allowing a nominating and governance committee that is not entirely independent, as Reuters reported on October 27. That leaves another consequential choice about future directors closer to current leadership.

The founders’ advantage has conditions. The Class F sunset provisions start a 450-day transition after fewer than three qualifying continuing founders remain for 90 consecutive days, with other termination provisions also applying. There is no fixed calendar expiration. The trust’s board-election role has separate amendment and termination conditions, so the end of Class F would not automatically end the trust’s authority.

How corporate control reaches Claude’s restrictions

Claude’s behavior already reflects company decisions made above the level of individual users. Anthropic’s October 8 Usage Policy update outlined revised rules for deceptive campaigns, surveillance, weapons-related applications, high-risk automated decisions, and abusive interactions with Claude. The revision is scheduled to take effect on November 12, 2026.

The announcement also shows that restrictions can loosen. Anthropic said it removed a blanket prohibition on personalized campaign targeting while retaining bans on deceptive election activity and misuse of personal data. Neither Claude subscribers nor a public shareholder majority had to approve those changes. The company set the terms on which people could use its service.

Enforcement has practical consequences. Anthropic can warn, suspend, or terminate accounts over policy violations. For January through June 2026, it reported 11.4 million banned accounts, 398,000 appeals, and 42,000 appeal overturns. Those figures document the scale of enforcement. They do not establish whether any individual decision was justified.

The IPO structure provides no evidence that trustees or founders directed a particular moderation decision. It shows where corporate authority is concentrated when users, employees, or shareholders dispute such decisions. A board chosen chiefly by the trust could defend legitimate safety limits against revenue pressure. Its insulation from ordinary shareholder votes could also make contested rules harder to change. The governing documents assign powers, but cannot tell us how their holders will exercise them.

Popular AI’s guide to LLM bias and AI censorship explains how post-training and product policies affect what a hosted model says. Corporate control sits above those technical choices, determining who can oversee the people making them.

Keep Claude useful without making it irreplaceable

Nobody needs to abandon a productive Claude workflow because of a proposed IPO. Avoid making the vendor’s policy choices an irreplaceable dependency.

▪ Keep prompts, source documents, agent instructions, code, and finished outputs in formats you can access outside Claude. For software built around its API, isolate provider-specific calls so switching models does not require rebuilding the application. Read current usage rules before committing to high-risk or regulated deployments. Have a manual path when an account is paused or a requested capability is unavailable.

▪ For confidential or politically sensitive work, consider a second hosted model or a local fallback. Popular AI’s local AI guide covers the tradeoff: local models can reduce exposure to centralized account and inference controls, but bring hardware costs, setup work, model limitations, and maintenance responsibilities. A fallback should preserve access to the work you need, rather than simply add another tool to the same vulnerable workflow.

Under the proposed IPO structure, the founders would control general shareholder votes, the benefit trust would choose most directors, and management would operate Claude. Public ownership would leave that chain of authority largely intact. Keep using Claude where it earns its place, and keep your work portable enough to continue if the people controlling it change the rules.

More on this subject:

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast

OpenAI says an internal AI system has disproved the Exponential Time Hypothesis (ETH), a conjecture that underpins many claims about which computing problems are too hard to solve quickly. If the result survives review, it would force researchers to revisit some of those limits. It would not establish that P equals NP or give us a practical shortcut for every difficult problem.

Share

The company announced the claimed ETH refutation on October 26, 2026, alongside results in mathematics and quantum physics. Its ETH manuscript and Lean formalization are public. Independent examination is still underway.

ETH is a conjecture, not a fundamental law of computer science. And even a machine-checked proof needs people to check what its formal statement actually means. The published materials make that question unusually concrete.

What disproving the Exponential Time Hypothesis would mean

Imagine a puzzle with 100 yes-or-no switches. A brute-force search might try as many as 2¹⁰⁰ combinations. Many computational problems contain the same combinatorial explosion: adding a few variables can multiply the search space.

ETH concerns 3-SAT, a problem involving Boolean formulas with up to three literals per clause. Roughly, it says no algorithm can solve every instance with n variables in subexponential time, written 2^o(n). Researchers use that assumption to derive conditional limits for other problems. If ETH falls, those ETH-dependent conclusions need reconsideration. The underlying problems would not automatically become easy.

OpenAI’s October 25 manuscript claims a deterministic, subexponential-time algorithm that counts every satisfying assignment of a fixed-width Boolean formula while using polynomial space. Counting solutions also answers whether any solution exists. If the algorithm and its claimed bound are correct, applying it to 3-SAT would refute ETH.

The qualifier is subexponential. An algorithm can beat 2^cn asymptotically and still be vastly slower than any useful program on real inputs. OpenAI has not demonstrated a practical replacement for industrial SAT solvers. A theoretical improvement in growth rate is not a benchmark showing that today’s workloads run faster.

Does OpenAI’s ETH claim mean P equals NP?

No. P versus NP asks whether problems whose solutions can be checked efficiently can also be solved in polynomial time. The proposed algorithm offers a weaker guarantee: subexponential time.

For example, 2^√n is subexponential but grows faster than every fixed polynomial. Calling both kinds of algorithm “faster than brute force” hides an enormous difference in what they promise.

A correct ETH refutation would be a major theoretical result without settling P versus NP, automatically defeating modern encryption, or making hard scheduling and optimization tasks suddenly tractable. Those outcomes would require additional arguments. They do not follow from the claim OpenAI has published.

What the Lean formalization actually checks

Lean is a proof assistant that checks whether a formal proof follows from precisely stated definitions and accepted logical rules. That provides substantially stronger evidence than an AI confidently writing “therefore, proved.”

But Lean’s proof-validation guidance separates a valid proof from the meaning of its theorem statement. The formal theorem must capture the intended mathematical problem. Its axioms and imported dependencies also need scrutiny.

OpenAI’s ETH formalization covers exact counting for canonically encoded, fixed-width formulas. The stated runtime is a polynomial factor in input length multiplied by 2 raised to O(n(log log n)²/√log n). The development also bounds the tape space used by the machine by a polynomial in input length.

The October 25 manuscript gives a sharper exponent with one log log n factor, rather than its square. Both exponents are sublinear in n, so either would contradict ETH if the definitions and deductions hold. The public Lean scope note does not claim to verify the manuscript’s sharper running-time estimate.

Reviewers therefore need to establish whether the formal statement faithfully captures ordinary 3-SAT, whether the runtime and machine definitions express the claimed computational bound, and whether independent checkers can reproduce the proof without problematic assumptions. Checking the derivation and interpreting the definitions are separate jobs.

The published scope documentation and source statements have been inspected for this article. The Lean development has not been independently rebuilt or certified here.

Three AI proof claims at different verification stages

The geometry claim deserves attention on its own. OpenAI says a new auxiliary partial differential equation supplies local-smoothing estimates that lead to results about Kakeya sets, which contain a unit-length line segment in every direction.

The geometry formalization includes full Hausdorff dimension for Kakeya sets. Full dimension is not the same assertion as positive volume. Describing the result simply as a proof about how much space these sets occupy can blur the actual mathematical claim.

The physics announcement needs more restraint. OpenAI claims rigorous existence results for theories including quantum chromodynamics, but the outside group led by David Gross has chosen to prepare its own presentation before releasing the materials. Readers cannot yet examine the physics artifacts as they can the public ETH materials.

The Yang–Mills Millennium Prize problem requires existence and a mass gap. OpenAI has not claimed to settle that full problem. An existence result alone would leave the mass-gap requirement unresolved.

Who is checking OpenAI’s ETH result?

OpenAI says its model produced the ETH argument on October 16 and formalized it in Lean on October 17. It obtained the local-smoothing argument on October 18 and formalized that on October 19. The October 26 announcement set out how the public review would proceed.

Russell Impagliazzo and Ramamohan Paturi, who helped originate ETH, and MIT’s Ryan Williams are organizing the examination of the computer-science claim.

Their involvement is not an endorsement. The group requested public access to the raw materials and freedom to scrutinize them without nondisclosure agreements or compensation. A reviewer agreeing to examine a proof has not thereby certified it.

On October 27, Anthropic published a separate Claude-generated ETH refutation claim, describing a different approach based on tensor networks and its own Lean checking procedure.

Two public claims give specialists more to compare. They do not amount to two independently accepted theorems. Each argument still needs examination on its own terms.

What would establish that ETH has fallen?

▪ If the proof survives scrutiny, ETH-dependent research will need its assumptions revisited, and AI-assisted theorem discovery will have passed an extraordinary test.

▪ If it fails, the failure could expose a gap between a polished formal statement and the mathematical problem it was supposed to settle. The location of that gap would help explain what the machine checking did and did not establish.

As of October 27, 2026, OpenAI has published a claimed subexponential algorithm and a corresponding Lean formalization. Independent mathematical acceptance remains pending.

Watch for reproducible checks of the precise theorem, human explanations of the algorithm, and explicit agreement about its consequences. A famous conjecture falls when the argument holds up. The announcement starts that examination.

Leave a comment

Explore more from Popular AI:

Start here | Local AI | Builds & gear | Autonomy & policy | Fixes & guides | Popular AI podcast