A Kill Switch Stops a Release, Not the Copy on Your Disk

On 16 October, POLITICO reported that Anthropic has been pitching US lawmakers a draft bill that would limit when the federal government can block the release of a frontier AI model. According to POLITICO, which obtained a confidential draft and spoke to three people granted anonymity, the government could block a model's release or use only if it poses a "foreseeable, imminent risk" of more than $1 billion in damages, or of killing or seriously injuring more than 50 people. This is a draft pitch, not introduced legislation: there is no bill number, no vote and no committee action.

Anthropic's spokesperson told POLITICO: "This bill represents the proposals outlined in Anthropic's Advanced AI Framework, which we have been advocating for with federal and state lawmakers since June. These are sensible policies we believe Congress should act on." Heidy Khlaaf of the AI Now Institute called the proposal "autocratic" in a social-media post, saying it lets the company set the thresholds while excluding harms happening today. What matters for this blog is the mechanics: a kill switch acts on a release, and anyone running models on their own hardware is in a different position from someone renting one.

What the draft can reach when you run AI locally

Look at who the reported mechanism points at. Independent evaluators would register with the Commerce Department and assess labs and their frontier models periodically. The lab may pay them, as long as the payment is not contingent on the results.

If an evaluator finds "imminent enumerated risk", it must report to Commerce within 72 hours. Only Commerce may take the request to a federal judge in the District Court for the District of Columbia, and that judge could order a suspension. The draft explicitly bars any other US department, agency or officer from suspending a model's development, deployment or internal use.

The risk has to come from one of three things: the creation or release of a biological weapon, the model evading its developer's controls, or a cyberattack. POLITICO reports the language mirrors California's AI laws, including SB 53. The draft would also preempt some state AI laws covering public disclosure of risk, third-party evaluation and reporting of critical incidents, and would require safety frameworks, transparency reports for new frontier models, whistleblower protections, and reporting of critical safety incidents to Commerce.

Every step in that chain is aimed at a developer and an event: a lab releasing, deploying or using a frontier model. The control point is the company's servers, download page and API.

A file already on your disk sits somewhere else. Once a GGUF file or a folder of safetensors has finished downloading, it is bytes on your SSD that llama.cpp or vLLM reads at startup. The file does not check in with anyone before it runs, and nothing in the process POLITICO described recalls copies that already exist. A suspension can stop the next download. It does not reach back into the last one.

I am describing a reported draft, not law, and I am not a lawyer. Whether a given open-weight model would even count as a "frontier model" is not something the reporting settles. The durable point is narrower: control over a release sits with whoever ships it, and control over a copy sits with whoever holds it.

The summer precedent: access that depends on one vendor

This has already happened in a different form. POLITICO reports that over the summer Anthropic was subject to sweeping export controls that shut down two of its most advanced models, a decision made in a series of phone calls between administration officials and company executives.

I do not read that as "the government is coming for your model". The lesson I take is simpler. If your access to a model runs through one vendor's API, your continuity depends on that vendor's continued permission to serve it.

Renting a frontier model is often the right call; I covered the trade-offs in what a rented frontier model changes in a self-hosted AI stack. Keep renting if it works for you, but know what you would run if the rented model went away, and have it on disk before you need it.

How to run AI locally on a real box

My own setup is boring on purpose: open-weight models, a pinned runtime, and model files I can point to by path.

Pin the runtime

Do not run :latest. Pick a version you have tested and write it down. For Ollama in Docker:

docker run -d --name ollama --gpus=all \
  --label com.centurylinklabs.watchtower.enable=false \
  -v ollama:/root/.ollama \
  -v /srv/models:/models \
  -p 127.0.0.1:11434:11434 \
  ollama/ollama:X.Y.Z

Replace X.Y.Z with the release you tested. The label stops Watchtower from upgrading the container behind your back. On bare metal, the install script accepts a version too: curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=X.Y.Z sh.

For llama.cpp, build from a release tag instead of whatever is on the main branch. Release tags are a b followed by a build number:

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout bNNNN
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

Download the model as a file you keep

ollama pull stores models as hash-named blobs under ~/.ollama/models (/usr/share/ollama/.ollama/models for the Linux service install). I prefer to fetch the GGUF myself, pinned to a specific Hugging Face commit, so I know exactly which file I have:

hf download ORG/MODEL-GGUF MODEL-Q4_K_M.gguf \
  --revision COMMIT_SHA \
  --local-dir /srv/models/MODEL

Take COMMIT_SHA from the commit history on the model page. Without --revision you get whatever the main branch holds today. For vLLM, download the whole safetensors repo the same way and leave out the filename.

Then point the runtime at the file. With llama.cpp:

./build/bin/llama-server -m /srv/models/MODEL/MODEL-Q4_K_M.gguf \
  -ngl 99 -c 8192 --host 127.0.0.1 --port 8080

With Ollama, save a one-line file at /srv/models/MODEL/Modelfile containing FROM /models/MODEL/MODEL-Q4_K_M.gguf (the path as the container sees it), then run docker exec ollama ollama create mymodel -f /models/MODEL/Modelfile. With vLLM, pin the image tag the same way:

docker run -d --gpus all --ipc=host \
  -v /srv/models:/models \
  -p 127.0.0.1:8000:8000 \
  vllm/vllm-openai:vX.Y.Z \
  --model /models/MODEL

Keep the licence, checksum and provenance next to the weights

cd /srv/models/MODEL
hf download ORG/MODEL-GGUF LICENSE README.md --revision COMMIT_SHA --local-dir .
sha256sum MODEL-Q4_K_M.gguf > MODEL-Q4_K_M.gguf.sha256
echo "ORG/MODEL-GGUF @ COMMIT_SHA, downloaded $(date -I)" > PROVENANCE.txt

Not every repo has a file called LICENSE; some put the terms in the model card, which is why I grab README.md too. For a model you pulled with Ollama, ollama show MODEL --license > LICENSE.txt saves the licence text.

Size it to your VRAM

A model you cannot load is not a fallback. As a first estimate, the GGUF file size is roughly what the weights need in memory, plus room for the context window. Mixture-of-experts models are where people get caught: the active parameter count sounds small, but every expert still has to be loaded somewhere. I covered that trap in MoE VRAM requirements: total vs active parameters.

Where running locally does not save you

A future release can still be stopped. Open weights are still released by someone. If a model is blocked before it ships, there is no file to download. Your disk protects what you already have, not what comes next.

Licences can change for future versions. The licence you saved records the terms that version shipped under. The next version can come with different terms, so read them again before you upgrade.

You own patching and security. Ollama, llama.cpp and vLLM all ship fixes, and a pinned version stops getting them until you move the pin. Pinning means you upgrade on purpose, not never. Keep ports 11434 and 8000 bound to 127.0.0.1, and put a reverse proxy with authentication in front if you need remote access.

A small local model is not a frontier model. What fits on one consumer GPU will not match the best hosted models on hard reasoning, long documents or work across a large codebase. Plan for your fallback being worse, and decide which jobs can live with that.

Five things to do this week

Pin the runtime version. Replace :latest with a tested tag for Ollama or vLLM, or a release tag for llama.cpp, and write it into your compose file.
Keep a second copy of the weights. One disk is not a backup. Run rsync -a /srv/models/ /mnt/backup/models/ to another drive or another machine.
Keep the licence file. Store it in the same folder as the weights so the two never get separated.
Note provenance and checksum. Repo, commit, filename, date and SHA-256 in a text file. Run sha256sum -c MODEL-Q4_K_M.gguf.sha256 after every copy.
Decide your fallback. For each job that uses a hosted model, write down which local model takes over if it disappears, and test the switch once while nothing is on fire.

The part you control

A kill switch, whatever threshold it uses, is a control on a release. The weights on your disk, the runtime you pinned and the box you can unplug are the parts you actually control.

If you would rather have someone set this up and harden it for you, see the services page. Fiverr: hiteshsaini459 · Upwork: hiteshsaini25