LLM | Shunyang Wang

A Chemist's Notes on Agentic Coding using Claude

Mon, 25 May 2026 00:00:00 +0000

Six weeks of token usage, in numbers. I’m a slow adopter. This is what catching up looks like.

Where I started

I’m a computational chemist at a pharma. I write code, but I’m slow to pick up new tools. This time I want that to change.

The timeline:

GPT era (late 2022 – mid 2023): I thought it was an ads event. Overpresented, underdelivering.
Mid 2023: Tried coding with it. Copy-paste from chat to IDE, paste back, ran it. Treated it like a slightly faster Stack Overflow.
Mid 2024 – early 2025: Started using LLMs for information search instead of Google. The switch was about a year behind when I should have made it.
Through 2025: Started reviewing what it wrote, line by line. Caught some things, missed others. Trust grew slowly.
Spring 2026 (now): Letting an agent take over most of the code-writing for a dozen active projects. Reviewing diffs, not lines. Weekly load grew about 12× in five weeks.

This essay is what a slow adopter looks like when the thing finally clicks.

Why I care about token usage

It is obviously wrong to optimize for maximum tokens, but as a beginner I realized token use is a decent proxy for how familiar I am with the tool.

More tokens per task usually means fewer back-and-forth turns, more self-evaluation, and more iteration. It pushed me to think about better harnessing and how to interact with the agent like a code reviewer.

Through this journey, I learned how to set up tools, skills, and memories.

What the numbers say

Weekly volume, normalized to week 1 (laptop + cluster combined):

The eye goes to the spike on the right — week 5 was about 12× week 1. But the more interesting number is hidden in weeks 3 and 4: load stayed level while requests dropped (3,167 → 1,719). I wasn’t running more turns. I was running heavier ones.

86K → 216K is a 2.5× fold change in payload per call. Output tokens per call grew 1.5× over the same window (512 → 778). Much denser sessions.

What’s more, I slowly moved all work from my laptop to the cluster — long-running sessions under tmux or Zellij, with a sandbox where the agent could run autonomously without me re-approving every command.

Six weeks, six unlocks

W1 — 186M tokens · 2,164 requests

First cluster sessions. First three skill templates landed: experiment runs, cluster submission, PR descriptions. Earliest memory rules: file scope (don’t touch other users’ code), review-figures-before-commit. The unlock was vocabulary — naming the rules the agent would follow.

W2 — 544M tokens · 3,551 requests

First two project repos shipped. No new infrastructure — pure use of W1 scaffolding. 3× the token volume of W1; the unlock was just committing to real projects.

W3 — 382M tokens · 3,167 requests

“No login-node abuse” memory written after a long BFS scan slowed the host. Slurm cluster reference memory added.

W4 — 362M tokens · 1,719 requests

Heavy iteration on existing projects. Set up repos and READMEs so projects could reference each other.

W5 — 1,762M tokens · 8,168 requests

Six new project repos shipped first commits in five days. First skill promotions — a job-resume skill and a figure-review skill, both graduated from feedback memories that kept firing. First three hooks landed: a Stop-event lint, a Stop-event commit-recommend, and a PreToolUse pre-commit hook that blocks git commit when the staged diff touches numerical logic until the math is articulated in the message body. Multiagent workloads also drove the usage spike. The unlock was compounding — projects, skills, and hooks all landed the same week because the spine made each one cheap.

W6 — 1,094M tokens · 5,063 requests

Tightening week. Two new PreToolUse hooks finally landed: a Slurm-submission validator and a login-node-abuse blocker (promoted from the W3 memory to a skill). Four new diagnostic skills — status dashboards across projects, cluster shortcuts. Eleven new memory rules, most of them workflow tightenings after I ran the built-in /insights command.

Each week added something the next week built on. None of it was strategic — each piece came from a specific friction in the prior week that I got tired of.

What changed

In the order I learned them. Not all stuck the first time.

1. Build infrastructure before features

Weeks 1–2 were 80% project work. By week 5 it was the inverse — and that’s when output went up. Hooks, memories, skills, scaffolding compound. New projects start at week-5 productivity.

2. Solve permissions once

Every “do you want to run this?” is friction. The project’s permissions config ended up with 91 shell allowlist entries and 17 file-access entries. Plus a deny list covering 8 sibling user directories so I can’t edit colleagues’ code by accident. Most operations now run without a prompt. Sandbox or running in a container is a better option, but both are limited by available resources.

3. Solve the boring plumbing

Set up the cluster submission path so a sandboxed compute environment could submit jobs without a shared filesystem. Remote VS Code pointed at GPU nodes. Job logs streamed back to my laptop without manual rsync. Each one removes ~5 minutes of friction × dozens of times per day.

4. Ask the agent to ask me questions

“Ask me three clarifying questions before you start.”

Highest-impact line I added to my prompts. Half the time the questions made me realize I didn’t know what I wanted.

5. Plan before execute

Plan mode. Reviewable artifact before any code is written. Saves the revert-and-retry cycle.

6. Write memories with reasoning, not just rules

Every memory file has a Why: line and a How to apply: line. The agent learns the rule’s boundary, not just the rule. Memories that say “do X” without saying why decay; memories that say “do X because Y last quarter” survive.

7. Promote memories to skills when they keep firing

A “resume the partial job, don’t re-run from scratch” memory became a /resume-job invocable skill after the same procedure ran three times. Memory layer compounds through promotion — not just by accumulation.

8. Let projects talk

One project consumes utility tools written in another. A third will feed its outputs back as priors into the first. The portfolio isn’t 12 independent projects — it’s a graph. Each project’s outputs become another’s inputs.

9. Multiagent for parallel branches

Background subagents for independent tasks (search this repo / draft this analysis / find this dataset). Subagent context shields the main session from large outputs. Three branches in flight without context contamination.

Unexpected side effects

Negative results published in the repo. A full fine-tune on a published embedding model lost to a simpler baseline. Logged as Exp X.YZ NEGATIVE, linked from the project’s manuscript. Failed runs that get committed become next quarter’s prior, not buried compute.
Pre-commit quality gates. A hook that blocks git commit when staged changes touch numerical logic, until I articulate the math in the commit body. Came after I caught the agent producing markdown with estimated numbers that the actual data later contradicted by 50–100% per day. Wrong numbers don’t fail tests; they just ship. Now they fail commits instead.
Tracking my own learning. This essay exists. Tracking it makes the meta-improvements visible — like load-per-call rising while request count fell. Only see it if you look.

Infrastructure inventory

As of May 2026:

25 memory files — autonomous-mode rules, cluster-resource defaults, scoring-API references
6 skills — domain-specific reasoning, cluster-submit, experiment-run, figure-review, resume-job, PR-description
3 hooks — numerical-review gate, cluster-job-ID capture, ruff lint
119 permission entries — 91 shell allowlist, 17 file-access, 11 deny rules (maybe there are smarter ways?)
36 documented patterns — from “Agent vs Pipeline” (#1) to “Memory→skill promotion” (#36)

The portfolio plateaued at 12 once the infrastructure stopped being the bottleneck. Growth now is depth-per-project — one of the agents going Phase 1 → 6b in three days is what depth growth looks like when the spine is in place.

Analogies from chemistry

Reaction rate isn’t throughput. More turns per hour doesn’t help if half are clarifying questions. Spec quality is the rate-limiting step. So I ask the agent to ask me questions instead of letting it guess.

Catalysts beat reagents. A small piece of well-placed infrastructure accelerates everything downstream. A hook that blocks numerical commits costs nothing and prevents an entire failure mode.

For a chemist starting today

One project. One CLAUDE.md. One AGENTS.md. Don’t scaffold for 12 on day one.
Wait until you’ve corrected the agent on the same thing three times before writing the first memory. Earlier than that and the rules don’t generalize.
Solve permissions early. Twenty allowlist entries on week one removes hundreds of prompts on week three.
Tell the agent to ask you clarifying questions when you’re vague.
Plan before execute.
Track your weekly load. Mine grew 12× in five weeks; without a routine pull on usage telemetry I wouldn’t have noticed.

What’s next

Now I can easily use up my weekly quota, so I need to think about token efficiency.

The thing that gets faster isn’t the adoption itself. It’s the time between seeing other people do it and deciding to actually try it.

Run a Free Local LLM and Share It with Your Family and Friends in 4 Hours

Wed, 29 Jan 2025 00:00:00 +0000

Introduction

The release of the distilled DeepSeek-R1 model has revolutionized the field. I decided to build one locally, and to my surprise, the process was smoother than I expected. With the knowledge I had, I was able to deploy the model and allow my family to access it through ZeroTier. This tutorial will guide you through setting up a local DeepSeek-R1 model using Open WebUI, ZeroTier, and Docker on Windows with an NVIDIA RTX 3090. (According to my tests, an AMD Ryzen 5900X can also support basic functions, albeit with a response time of several minutes.) By following these steps, you’ll be able to run DeepSeek-R1 locally and share it with your family and friends over the network.

Below is a comparison of DeepSeek-R1’s performance against other models in different benchmarks, highlighting its strengths in accuracy and efficiency:

With 24GB of memory, DeepSeek-R1:32B can achieve 90% of the performance of ChatGPT-O1. This makes it a powerful yet cost-effective alternative for local deployments, especially for users who need high accuracy but want to run models independently without relying on cloud-based solutions.

Prerequisites

Before proceeding, ensure you have the following:

A Windows machine (Windows 10/11 recommended) with an NVIDIA RTX 3090 (You can opt for a smaller model if you have limited GPU memory.)
Docker installed (Download Docker)
NVIDIA GPU drivers and CUDA installed (Download CUDA)
Docker CUDA Container (NVIDIA Docker CUDA)

Step 1: Install and Configure Open WebUI (1 hour)

Open WebUI is a user-friendly interface for interacting with local LLMs.

Run Open WebUI with Docker using GPU support:

docker run --user=0:0 \
--env=USE_CUDA_DOCKER=true --env=USE_CUDA_DOCKER_VER=cu121 \
--env=USE_EMBEDDING_MODEL_DOCKER=sentence-transformers/all-MiniLM-L6-v2 \
--volume=open-webui:/app/backend/data --network=bridge --workdir=/app/backend \
-p 3000:8080 --runtime=nvidia -d ghcr.io/open-webui/open-webui:cuda

Explanation of Main Parameters

--runtime=nvidia: Enables GPU acceleration for the container, allowing Open WebUI to leverage CUDA for faster performance.
-p 3000:8080: Maps port 8080 inside the container to 3000 on the host machine, allowing access via http://localhost:3000.
--volume=open-webui:/app/backend/data: Ensures persistent storage for Open WebUI’s data, preventing loss after container restarts.
--env=USE_CUDA_DOCKER=true: Configures the container to use CUDA, enabling GPU acceleration for AI model execution.
--env=USE_EMBEDDING_MODEL_DOCKER=sentence-transformers/all-MiniLM-L6-v2: Specifies the embedding model to be used within the container.
--network=bridge: Sets the container to use a bridge network mode, allowing it to communicate with other services inside the same Docker network.
-d: Runs the container in detached mode, so it continues running in the background.

Note: The --hostname parameter is optional and generally not required unless you need to set a specific hostname inside the container.

Step 2: Configure Open WebUI and Download the Model (1 hour)

Open your browser and access Open WebUI at http://localhost:3000.
Create and configure your login credentials.
Pull the DeepSeek-R1:32B model within Open WebUI.
Test the model locally and monitor your CPU/GPU usage to ensure optimal performance.

Step 3: Enable Remote Access with ZeroTier (40 minutes)

ZeroTier enables secure remote access to your local setup, allowing your family and friends to connect. The free version supports up to 50 connected devices, making it ideal for personal and small-scale use.

Download and install ZeroTier from ZeroTier’s website.
Create a ZeroTier account and set up a new network.
Join the network from your Windows machine:
```
zerotier-cli join <network_id>
```
Or, use the ZeroTier GUI to join the network, for both WebUI server and user computer. You need to repeat this every time having a new user device. (Mac, Windows, Pad, Phone…)
Authorize your device in the ZeroTier web console.
Retrieve your virtual IP address for remote access and share it with trusted users.
Configure managed routes to properly map the ports through ZeroTier for external access.

Step 4: Configure Windows Firewall for External Access (20 minutes)

To allow external access, configure the Windows firewall:

Open Windows Defender Firewall.
Navigate to Advanced Settings > Inbound Rules.
Create a new rule to allow inbound traffic on the required port (e.g., 3000).
Apply the rule and restart the system if needed.

Step 5: Enjoy Your Local LLM Server (30 minutes)

With Open WebUI set up and ZeroTier configured, your local LLM model is now accessible over the network. Access the server using your ZeroTier-assigned IP and the configured port:

http://<zerotier_ip>:3000

Share this link with trusted users to allow them access to your local LLM without exposing it to the public internet. Add them as new users if needed.

Troubleshooting and Optimization

Common Issues

Docker not starting: Ensure virtualization is enabled in BIOS.
ZeroTier not connecting: Check firewall settings and authorize the device.
Slow performance: Ensure CUDA is correctly installed and the GPU is being utilized.

Performance Tuning

Allocate more resources to Docker if needed.
Use a dedicated GPU like the RTX 3090 for faster inference.

Conclusion

You now have a fully functional local DeepSeek-R1 setup with Open WebUI, ZeroTier, and Docker on Windows. You can interact with the model via Open WebUI and even share it with your family and friends over the network using ZeroTier.

For further improvements, consider integrating additional plugins or experimenting with different model configurations. Happy coding!