Simon Willison TIL

Using uvx in GitHub Actions in a cache-friendly way

2026-07-14T00:56:20+00:00

I often find myself wanting to run a quick Python tool inside of GitHub Actions using uvx name-of-tool - but I don't want that to result in a network request to PyPI every time the workflow runs. I want the tool to be fetched the first time and then reused from the GitHub Actions cache for subsequent runs.

I've tried unsuccessfully to find patterns I like for this in the past, especially given the standard pattern in GitHub Actions of using the hashed contents of a file - often pyproject.toml or requirements.txt - as a key for the cache.

This is usually a good pattern, but for simple scripts I don't want to have to maintain an additional file just to get the cache to work correctly.

Today (with the help of GPT-5.6 Sol) I finally found a pattern I like.

My goal was to be able to drop uvx name-of-tool into a GitHub Actions workflow anywhere I like, while still trusting that the tool would be cached between builds - and could be cache-invalidated if I needed to.

The key turned out to be the UV_EXCLUDE_NEWER environment variable. This works the same as uvx --exclude-newer DATE, allowing you to tell uv to install the most recent package as-of a specific date.

That date can then also be used as part of the cache key for GitHub Actions! This means you can set the date in the script once and get a repeatable set of installed versions for all of the tools. Then any time you want to bust the cache you can increment the date in that one place:

name: Run tools

on:
  workflow_dispatch:

env:
  # Bump this date to allow newer package releases and a fresh cache:
  UV_EXCLUDE_NEWER: "2026-07-12"

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Install uv and restore cache
        id: setup-uv
        uses: astral-sh/setup-uv@11f9893b081a58869d3b5fccaea48c9e9e46f990 # v8.3.2
        with:
          enable-cache: true
          cache-dependency-glob: ""
          cache-suffix: "tools-${{ env.UV_EXCLUDE_NEWER }}"
          prune-cache: false
    
      - name: Require cache-only uv on cache hits
        if: steps.setup-uv.outputs.cache-hit == 'true'
        run: echo "UV_OFFLINE=1" >> "$GITHUB_ENV"
    
      - name: Run sqlite-utils
        run: uvx sqlite-utils --version
    
      - name: Run datasette
        run: uvx --pre datasette --version
    
      - name: Run LLM
        run: uvx llm --version

astral-sh/setup-uv is Astral's official Action for getting uv. I'm annoyed that it appears to hit Astral's own releases.astral.sh site every time it runs but if that's how they want it to work I guess that's on them.

Those settings:

enable-cache: true turns on GitHub Actions caching
cache-dependency-glob: "" disables the feature where it looks for pyproject.toml or similar to use as a cache key
cache-suffix: "tools-${{ env.UV_EXCLUDE_NEWER }}" is the bit that uses our single UV_EXCLUDE_NEWER value for the cache key
prune-cache: false is necessary because Astral default to deliberately pruning your cache of any downloaded wheels, the exact opposite of what I want!

I should note that my preferences here go directly against what uv advises:

However, in continuous integration environments, persisting pre-built wheels may be undesirable. With uv, it turns out that it's often faster to omit pre-built wheels from the cache (and instead re-download them from the registry on each run).

Personally I'd rather suffer from very slightly slower CI builds (presumably because GitHub's cache restore operations are slower than fresh installations from PyPI?) than optimize my builds by hitting the PyPI CDN for every tool execution.

This block here enforces that the cache is used correctly:

      - name: Require cache-only uv on cache hits
        if: steps.setup-uv.outputs.cache-hit == 'true'
        run: echo "UV_OFFLINE=1" >> "$GITHUB_ENV"

Setting that UV_OFFLINE=1 environment variable causes uvx tool-name to fail if the tool has not been previously installed. We only run that if we got a cache hit from the GitHub Actions cache.

This means that if you add a new tool to the workflow without also bumping the UV_EXCLUDE_NEWER date you'll get an error.

Cloudflare CAPTCHA on at least one ampersand

2026-06-16T00:21:36+00:00

I use Cloudflare's CAPTCHA (they call it a "Managed Challenge") on simonwillison.net/search/ to prevent crawlers from following every single possible combination of my faceted search UI.

This was getting pretty annoying, since I had to wait for the challenge every time I searched my own site.

I don't particularly care about regular ?q=term searches. Where things get messy is if a crawler starts hitting every combination of:

?q=term&type=entry
?q=term&type=entry&year=2006
?q=term&type=entry&year=2006&tag=browsers

etc.

I decided to switch the Cloudflare rules around to activating only on hits to /search/ that included at least one & in the query string section.

Here's what that rule expression looks like:

(http.request.uri.path wildcard r"/search/*" and http.request.uri.query contains "&")

Trying the Cloudflare MCP

I originally tried to figure this out using Claude Code and Cloudflare's MCP server. I got that working by creating a dedicated folder:

mkdir cloudflare-dev
cd cloudflare-dev

And then setting up the MCP so it would only be active for Claude Code sessions started in that folder:

echo '{
  "mcpServers": {
    "cloudflare-api": {
      "type": "http",
      "url": "https://mcp.cloudflare.com/mcp"
    }
  }
}' > .mcp.json
mkdir .claude
echo '{
  "enabledMcpjsonServers": [
    "cloudflare-api"
  ]
}' > .claude/settings.local.json

(I actually set it up by pasting the MCP JSON into Claude Code and saying "set this up to only work in this project folder", but the above is effectively what it did.)

Then I ran claude in the folder and used the /mcp command, selected the Cloudflare MCP and used the authenticate option to jump through an OAuth flow.

... which didn't work, because as far as I can tell Cloudflare's MCP doesn't yet implement tools to view and modify the rules in question.

Claude did suggest using the API instead, but I'd need an API token.

Using the API instead

I created an API token using dash.cloudflare.com/profile/api-tokens.

Cloudflare have a template for "Read all resources", and it turns out you can use that as a starting point.

I flipped the "Zone WAF" one to "Edit" and set the key to expire tomorrow. Then I copied the resulting key into a token.txt file.

(In the Cloudflare dashboard I believe this feature is called "Web Application Firewall > Custom rules".)

Then I let Claude Code handle the rest. Here's a rough version of what it did, assuming a token in a $TOKEN environment variable:

export TOKEN="$(cat token.txt)"
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones?name=simonwillison.net" \
  | jq '{success, errors, zones: [.result[] | {id, name}]}'

This got back the zone ID, which is 2ce4f4f41f239d041e25f8320ad3c3fd.

Then to list the custom WAF rules:

export ZONE="2ce4f4f41f239d041e25f8320ad3c3fd"
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE/rulesets/phases/http_request_firewall_custom/entrypoint" \
  | jq '{success, errors, rules: [.result.rules[]? | {description, action, expression, enabled}]}'

This started with:

{
  "success": true,
  "errors": [],
  "rules": [
    {
      "description": "/search/ extra protection",
      "action": "managed_challenge",
      "expression": "(http.request.uri.path wildcard r\"/search/*\")",
      "enabled": true
    },

To edit that rule via API we need the ruleset ID and the rule ID:

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE/rulesets/phases/http_request_firewall_custom/entrypoint" \
  | jq '{ruleset_id: .result.id, rule: (.result.rules[] | select(.description=="/search/ extra protection") | {id, description, action, expression, enabled})}'

Returning:

{
  "ruleset_id": "0682fdbd40cc444cbe1e93d136e2b174",
  "rule": {
    "id": "8b2766d7802e4e988163531670976cb9",
    "description": "/search/ extra protection",
    "action": "managed_challenge",
    "expression": "(http.request.uri.path wildcard r\"/search/*\"",
    "enabled": true
  }
}

And finally we can update that with the new expression:

export RS=0682fdbd40cc444cbe1e93d136e2b174
export RULE=8b2766d7802e4e988163531670976cb9

curl -s -X PATCH \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  "https://api.cloudflare.com/client/v4/zones/$ZONE/rulesets/$RS/rules/$RULE" \
  --data '{
    "action": "managed_challenge",
    "expression": "(http.request.uri.path wildcard r\"/search/*\" and http.request.uri.query contains \"&\")",
    "description": "/search/ extra protection",
    "enabled": true
  }'

Setting a custom price for a model in AgentsView

2026-06-09T21:35:31+00:00

I'm a recent convent to AgentsView, Wes McKinney's (previously of Pandas fame) Python toolkit for analyzing transcripts of coding agents from your own computer.

AgentsView can calculate your token spending based on those transcripts, across multiple different coding agents (Claude Code, Codex, Pi and more.)

You can run it via uvx like this to get as ASCII table of spending numbers in your terminal:

uvx agentsview usage daily

Example output:

DATE        INPUT     OUTPUT   CACHE_CR  CACHE_RD    COST      MODELS
----        -----     ------   --------  --------    ----      ------
...
2026-06-04  5248968   387578   149428    78087993    $77.72    gpt-5.5, claude-opus-4-8
2026-06-05  963595    115773   0         8383360     $8.62     gpt-5.5, gpt-5.4-mini, deepseek/deepseek-v4-flash, meta-llama/llama-3.2-3b-instruct:free, nvidia/nemotron-nano-9b-v2:free
2026-06-06  324888    36869    0         3231872     $4.35     gpt-5.5
2026-06-07  669027    46379    0         7486464     $8.48     gpt-5.5
2026-06-08  3346262   253637   0         49214208    $48.95    gpt-5.5
2026-06-09  787043    427018   1098673   78305086    $97.79    claude-fable-5, gpt-5.5, claude-haiku-4-5-20251001
----        -----     ------   --------  --------    ----      ------
TOTAL       73610282  7260576  4399393   1717538611  $1472.87

Anthropic's latest model Claude Fable 5 came out today. The pricing data AgentsView uses doesn't yet include that model.

So I had Claude Fable 5 reverse engineer AgentsView with the following prompt against claude.ai:

Clone https://github.com/kenn-io/agentsview and tell me how I can set a price for a model that it does not know the price of yet

It turns out you can add custom pricing information to your ~/.agentsview/config.toml file. Here's what I added:

[custom_model_pricing."claude-fable-5"]
input = 10.0
output = 50.0
cache_creation = 12.50
cache_read = 1

I think those numbers are right, I got them from this pricing page. Fable is 2x the price of Opus for input and output.

With the config file edited I can run Fable again to get pricing estimates. I used the serve command to get a web application on port 8080:

I've used the equivalent of $82.92 in tokens since getting access to Fable 5 about four and a half hours ago. This is all included in my $100/month Claude Max subscription though, which based on prior experience will likely give me around 10x the token usage compared to if I was paying list price.

Using LLM in the shebang line of a script

2026-05-11T18:48:57+00:00

This comment on Hacker News inspired me to investigate patterns for using my LLM CLI tool in a shebang line:

But seriously, you can put a shebang on an english text file now (if you're sufficiently brave) [...]

LLM can end up installed in all sorts of unpredictable places so the best way to run it is via the #!/usr/bin/env pattern.

Here's how to make English (or Spanish or any other language) text executable via LLM:

#!/usr/bin/env -S llm -f
Generate an SVG of a pelican riding a bicycle

Save this as pelican.sh and make it executable with:

chmod +x pelican.sh

Then run it:

./pelican.sh

Other arguments will be passed through to LLM, so if you want to use a different model:

./pelican.sh -m gpt-5.4-nano

This prompt often returns commentary in addition to an SVG. To extract just the first code block in the response add the -x LLM option:

#!/usr/bin/env -S llm -x -f
Generate an SVG of a pelican riding a bicycle

The -f option needs to come last as it will be passed the path to the script file.

How this works

#!/usr/bin/env -S llm -f

The -S (for split) option to env is required because, without it, the env command will treat the rest of the line as the full name of the command, producing this error:

/usr/bin/env: 'llm -f': No such file or directory

With -S the -f is passed as an argument to LLM, and then the path to the file itself is passed after that:

llm -f path/to/pelican.sh

This takes advantage of LLM's fragments mechanism. The argument to -f is the path to a file, and the contents of that file will then be appended to the prompt.

Adding tools

Scripts like this are a lot more interesting if they can execute tools.

LLM has some default tools which you can try out. Here's how to use the llm_time tool which makes the current time available for the model to call:

#!/usr/bin/env -S llm -T llm_time -f
Write a haiku that mentions the exact current time

I got (at 17:52 UTC):

Whispers of the hour,
Seventeen fifty-two chimes,
Time flows ever on.

Using templates

LLM supports templates - YAML files that can mix a prompt, system prompt, model options, and tool definitions.

These can be used with a shebang line by ending that line with a -t, for example:

#!/usr/bin/env -S llm -t
prompt: Write a haiku
system: Output Spanish

I got this:

Brisa en el bosque,
hojas susurran sueños,
paz en el silencio.

Templates can include parameters, for example:

#!/usr/bin/env -S llm -t
prompt: |
  Two line poem about $animal who lives in $place

This needs to be run like this:

./poem.sh -p animal skunk -p place "hovercraft port"

In hovercraft's hum, where the engines start,
A skunk claims his kingdom, with pride and art.

Templates with tools

The most interesting way to use templates is with embedded tool functions. Here's a simple example of that, saved as calc.sh:

#!/usr/bin/env -S llm -t
model: gpt-5.4-mini
system: |
  Use tools to run calculations
functions: |
  def add(a: int, b: int) -> int:
      return a + b
  def multiply(a: int, b: int) -> int:
      return a * b

Then:

chmod 755 calc.sh
./calc.sh 'what is 2344 * 5252 + 134' --td

Which outputs (thanks to the --td tool debug option):

Tool call: multiply({'a': 2344, 'b': 5252})
  12310688

Tool call: add({'a': 12310688, 'b': 134})
  12310822

2344 × 5252 + 134 = **12,310,822**

Here's a more complex example which defines a tool for searching my blog:

#!/usr/bin/env -S llm -t
model: gpt-5.5
system: |
  You answer questions from Simon Willison's blog
functions: |
  import httpx

  url = "https://datasette.simonwillison.net/simonwillisonblog.json"
  sql = """
  WITH results AS (
    SELECT 'entry' AS type, blog_entry.id AS id, blog_entry.slug AS slug,
           blog_entry.title AS title, blog_entry.created AS created,
           snippet(blog_entry_fts, -1, '<mark>', '</mark>', '…', 100) AS snippet,
           blog_entry_fts.rank AS rank
    FROM blog_entry_fts JOIN blog_entry ON blog_entry.rowid = blog_entry_fts.rowid
    WHERE blog_entry_fts MATCH :q
    UNION ALL
    SELECT 'blogmark', blog_blogmark.id, blog_blogmark.slug,
           blog_blogmark.link_title, blog_blogmark.created,
           snippet(blog_blogmark_fts, -1, '<mark>', '</mark>', '…', 100),
           blog_blogmark_fts.rank
    FROM blog_blogmark_fts JOIN blog_blogmark ON blog_blogmark.rowid = blog_blogmark_fts.rowid
    WHERE blog_blogmark_fts MATCH :q
    UNION ALL
    SELECT 'quotation', blog_quotation.id, blog_quotation.slug,
           blog_quotation.source, blog_quotation.created,
           snippet(blog_quotation_fts, -1, '<mark>', '</mark>', '…', 100),
           blog_quotation_fts.rank
    FROM blog_quotation_fts JOIN blog_quotation ON blog_quotation.rowid = blog_quotation_fts.rowid
    WHERE blog_quotation_fts MATCH :q
    UNION ALL
    SELECT 'note', id, slug, title, created,
           -- crude snippet: ~100 chars around the first match
           -- because notes do not yet have FTS enabled
           '…' || substr(body, max(1, instr(lower(body), lower(:q)) - 40), 200) || '…',
           0.0  -- no real rank available
    FROM blog_note
    WHERE body LIKE '%' || :q || '%' OR title LIKE '%' || :q || '%'
  )
  SELECT snippet FROM results
  ORDER BY rank
  LIMIT 20
  """

  def search_blog(query: str) -> str:
      """Search Simon's blog"""
      return httpx.get(url, params={"sql": sql, "q": query}).text

This sets up a tool called search_blog(query) which then executes an HTTP request against my datasette.simonwillison.net Datasette instance carrying a SQL query that searches various types of content.

Result:

./blog.sh "Has Simon implemented GraphQL?"

Output:

Yes. Simon implemented GraphQL support for Datasette as a plugin called datasette-graphql.

He described it as “a plugin that adds GraphQL query support to Datasette,” and later as a “Datasette plugin providing an automatic GraphQL API for your SQLite databases.” It can expose Datasette tables through GraphQL, including nested fields based on foreign-key relationships.

Here's the full log of that response showing the tool calls that were executed.

SQL functions in Google Sheets to fetch data from Datasette

2026-04-20T02:33:58+00:00

I've been experimenting with ways to fetch data from Datasette and display it in Google Sheets.

I've found three patterns that work so far. importdata() and "named functions" can only fetch from public Datasette instances. Apps Script can fetch from API key protected instances as well.

Using IMPORTDATA()

The easiest way to get this up and running doesn't involve any custom sheets functions at all. The IMPORTDATA() default function can fetch any CSV data from a URL and load it into the sheet - and Datasette exports CSV by default.

https://latest.datasette.io/fixtures/roadside_attractions.csv - the CSV data for the roadside_attractions table.
https://latest.datasette.io/fixtures/-/query.csv?sql=select+pk%2C+name%2C+address%2C+url%2C+latitude%2C+longitude+from+roadside_attractions - a SQL export of a database query, in this case one that returns all rows from that table.

Either of these URLs can be used in a Google Sheets cell like this:

=importdata("https://latest.datasette.io/fixtures/-/query.csv?sql=select+pk%2C+name%2C+address%2C+url%2C+latitude%2C+longitude+from+roadside_attractions&_size=max")

Using a named function

Ideally I'd like to use =sql("SELECT ...") in my spreadsheet cells instead. Google Sheets lets you define new "named functions" on a per-sheet basis, which can use existing Sheets functions and formulas - including importdata().

Go to Data -> Named functions and select "Add new function". Call it SQL and add a single argument placeholder called query, then set the following formula definition:

=IMPORTDATA(
  "https://latest.datasette.io/fixtures/-/query.csv?sql=" &
  ENCODEURL(query)
)

Now you can use =SQL("select * from roadside_attractions") in a cell to execute that SQL query and load in the CSV data:

Using Apps Script

There's one big downside of importdata() or a named function built on top of it: only unauthenticated URLs to CSV exports are supported. If your Datasette instance is protected by authentication and requires API keys to be sent as HTTP headers you will not be able to use them.

(importdata() can work fine here if the API key is a query string argument though. Here's how to enable that using the datasette-auth-tokens plugin.)

Apps Script lets you define custom server-side JavaScript functions which can then be called from a Google Sheets cell. These can be a lot more flexible, including sending API tokens in HTTP headers.

To create an Apps Script for a spreadsheet, use "Extensions -> Apps Script". This will start you on a code editor with a Code.gs file that you can edit. Here's a function definition for a =datasette_sql(query) custom function:

function datasette_sql(query) {
  var baseUrl = 'https://latest.datasette.io/fixtures'
  var token = '';

  // Strip a trailing slash so we control the join
  baseUrl = baseUrl.replace(/\/+$/, "");

  var url = baseUrl + "/-/query.json?sql=" + encodeURIComponent(query);

  var options = { muteHttpExceptions: true };
  if (token) {
    options.headers = { Authorization: "Bearer " + token };
  }

  var response = UrlFetchApp.fetch(url, options);
  var json = JSON.parse(response.getContentText());

  if (!json.ok) {
    throw new Error(json.error || "Query failed");
  }

  var rows = json.rows;
  if (!rows || rows.length === 0) return [["No results"]];

  var cols = Object.keys(rows[0]);
  var result = [cols];

  for (var i = 0; i < rows.length; i++) {
    var row = [];
    for (var j = 0; j < cols.length; j++) {
      var val = rows[i][cols[j]];
      row.push(val === null ? "" : val);
    }
    result.push(row);
  }

  return result;
}

You can set the base URL and an optional API token in variables at the top of the script.

You can ignore that "Deploy" button entirely, it's not necessary for custom functions for sheets. I had to hit the Command+S key combination to save my changes - confusingly I could not find a "save" button in the editor UI.

Apps Script has a script and document properties mechanism which theoretically could be used to keep secret values separate from that code, but I wasn't able to get that to work without confusing permission dialogs popping up.

As far as I can tell users who have "view" permission but not "edit" permission on the spreadsheet are unable to view the source code, so it should be safe to keep read-only API tokens in the source code even for shared spreadsheets.

I've prepared this demo sheet showing all three of the above solutions - importdata(), a named sql() function and a datasette_sql() function defined using Apps Script.

Running OpenClaw in Docker

2026-02-01T23:59:07+00:00

I'm not brave enough to run OpenClaw (aka Clawdbot aka Moltbot) directly on my Mac, so I decided to try running it in a Docker instead container.

OpenClaw has Docker support out of the box, described on this page of their documentation. Here's what worked for me.

Use their Docker Compose configuration

First, clone their GitHub repository:

git clone https://github.com/openclaw/openclaw

It contains a script for running OpenClaw in Docker called docker-setup.sh which in turn uses Docker Compose and their docker-compose.yml file.

The script will create two folders directly on your Mac which will then be mounted as volumes in the Docker container:

~/.openclaw is the configuration directory. This will eventually contain OpenClaw memory, configuration, third party API keys, etc.
~/openclaw/workspace is the workspace directory full of files that are directly available to the agent as it runs inside the container. Files the agent creates will be saved here too.

Answering all of those questions

On first run OpenClaw asks you a lot of questions. Most of these are reasonably obvious but I still had to start over a couple of times to get everything right. Some that I found tricky:

Onboarding mode: manual
What do you want to set up?: Local gateway (this machine)
Model provider. I decided to go for OpenAI Codex with ChatGPT OAuth, which then allowed me to authenticate against ChatGPT to spend tokens already covered by my $20/month OpenAI subscription. I did this because I've heard that OpenClaw can spend a lot of tokens on API plans, and using ChatGPT put an easy upper limit on how much it could spend. When you opt for this OpenClaw gives you a URL to open in your browser which redirects back to a non-running localhost service and displays an error message - you then copy and paste that localhost URL back into OpenClaw to complete the authentication. Here's what that looks like.
Tailscale: I tried to configure this the first time and it resulted in a machine I couldn't use, so the second time I said "no".

Once it's up and running you can run:

docker ps

To see the container. Mine is running the image openclaw:local and has a container name openclaw-openclaw-gateway-1.

Running administrative commands

The other container provided by Docker Compose is called openclaw-cli and can be used to run the openclaw CLI commands for managing the instance.

This works for that, but you must run it in the same folder as that docker-compose.yml file.

docker compose run --rm openclaw-cli status

Setting up a Telegram bot

OpenClaw can communicate via a number of different messaging platforms, including WhatsApp and iMessage and Telegram and Slack and Discord. This means you can control the instance in your container directly from your phone.

I decided Telegram looked like the least hassle to set up.

You'll need a Telegram account. Then create a new bot by chatting to @BotFather on Telegram.

Start a chat with @BotFather
Send the command /newbot
Follow the instructions to name your bot and get a token

That token can then be provided to OpenClaw as part of the initial setup wizard.

There's one remaining step: you have to pair your Telegram account with your new bot and your OpenClaw instance.

OpenClaw will send you a message via Telegram with the pairing code, then run this:

docker compose run --rm openclaw-cli pairing approve telegram <CODE>

At this point you should be able to message your bot directly from Telegram on your phone!

Accessing the web UI

OpenClaw runs a default web UI on port 18789. If you access this directly at http://localhost:18789 you'll see an error telling you that you need to authenticate first.

To do that you need a special ?token=... URL parameter. This may have been displayed during setup, but if you lose it you can get a new one like this:

docker compose run --rm openclaw-cli dashboard --no-open

Follew the URL that spits out to access the interface.

Sometimes that's not enough either - you may see this error:

disconnected (1008): pairing required

For some reason the openclaw-cli container didn't work for me here, but this alternative way of running the openclaw commands did:

docker compose exec openclaw-gateway \
  node dist/index.js devices list

That shows a list of pairings, hopefully including a request that is not yet approved like this one:

Pending (1)
┌──────────────────────────────────────┬───────────────────────────────────┬──────────┬────────────┬────────┬────────┐
│ Request                              │ Device                            │ Role     │ IP         │ Age    │ Flags  │
├──────────────────────────────────────┼───────────────────────────────────┼──────────┼────────────┼────────┼────────┤
│ 6f9db1bd-a1cc-4d3f-b643-2c195262464e │ 8b7bbf4f69633058dc3beee8a56adbccf │ operator │ 172.18.0.1 │ 2m ago │        │
│                                      │ aafc8be8058bea8a06be1cb7bfad9b3   │          │            │        │        │
└──────────────────────────────────────┴───────────────────────────────────┴──────────┴────────────┴────────┴────────┘

To approve that, run this command:

docker compose exec openclaw-gateway \
  node dist/index.js devices approve \
  6f9db1bd-a1cc-4d3f-b643-2c195262464e

The dashboard UI looks like this, and has a whole load of different debugging tools plus a web chat interface:

Running commands as root

I found myself wanting to install some extra packages, but the OpenClaw bot itself runs as a user without sudo access (probably for the best!)

You can access a Bash shell as root like this:

docker compose exec -u root openclaw-gateway bash

I installed extra packages there like this:

apt-get update && apt-get install -y ripgrep

Cloudflare response header transform rules

2026-01-23T15:08:25+00:00

I serve Python files from my tools.simonwillison.net subdomain, which is a GitHub Pages site that's served via Cloudflare. For example:

https://tools.simonwillison.net/python/q3_tts.py

This is meant to be used with uv as described here:

uv run https://tools.simonwillison.net/python/q3_tts.py \
  'I am a pirate, give me your gold!' \
  -i 'gruff voice' -o pirate.wav

By default files with .py extensions are served with a content-type: application/octet-stream header. This means browsers will download them rather than displaying them directly to the user.

For code that you're going to execute on your machine it's nice to be able to preview it in your browser first!

Here's that default content-type header:

~ % curl -I 'https://tools.simonwillison.net/python/q3_tts.py'
HTTP/2 200 
date: Fri, 23 Jan 2026 14:52:54 GMT
content-type: application/octet-stream

I can't control how GitHub Pages serves files, but since the site is behind Cloudflare I can fix the problem there instead.

Navigating the Cloudflare dashboard

The area to look for here is called "Rules". Within that area the "Create rule" button has an option to create a "Response Header Transform Rule":

I created a rule that looks like this:

The response header transform rule

My new rule has the following settings:

Rule name: tools.simonwillison.net .py files to text/plain
When incoming requests match: Custom filter expression
Filter expression:
- Hostname equals tools.simonwillison.net
- AND URI Path ends with .py
Then:
- Set static content-type to text/plain; charset=utf-8

I clicked 'Deploy' and within a few seconds saw this result:

~ % curl -I 'https://tools.simonwillison.net/python/q3_tts.py'
HTTP/2 200 
date: Fri, 23 Jan 2026 14:52:58 GMT
content-type: text/plain; charset=utf-8

And now https://tools.simonwillison.net/python/q3_tts.py displays the Python code directly in my browser.

Previewing Claude Code for web branches with GitHub Pages

2026-01-22T16:43:41+00:00

I'm a big user of Claude Code on the web, Anthropic's poorly named cloud-based version of Claude Code which can be driven via the web or their native mobile and desktop applications.

I mostly use it through the Claude iPhone app.

The biggest downside of this way of working is that, beyond CLI tools or code libraries, it's difficult to preview its work while it is iterating on the code.

I've started using GitHub Pages against private repositories to work around this limitation recently - at least for HTML projects - and it's working really well.

Here's how I'll spin up a new experimental prototype such that I can preview it on my phone.

Create a new private repository at https://github.com/new - include an empty README here to ensure the repo has been initialized.
Start a task in Claude Code against that repo - you may need to restart the app to ensure it picks up the newly created repo.
Tell Claude Code what to build, using a variation on "self-contained HTML file, vanilla JavaScript, no build step, load any dependencies from a CDN" - this ensures that the code it writes will run directly in a browser without needing to mess with npm

Claude Code will get to work, and after a few minutes will create a branch in your repository. Here's the clever bit:

Navigate to the Pages area of your repository settings, make sure "Deploy from a branch" is selected (the default) and then open the branch picker and select the claude/... branch that Claude Code just created

Wait about a minute for the deploy to complete and your new preview should become available at this (secret) URL:

https://your-username.github.io/your-repo/index.html

This will serve the full static contents of your repository so you can also reuse the same private repository for other projects like this in the future, though you'll have to manually select the new branch that Claude creates each time.

Crucially, your Claude Code for web session is still running. You can request changes from Claude - and even drop in screenshots of what it's built so far - and Claude will make changes and then push them to the existing branch, which means they'll be available in your preview shortly afterwards.

I've not found a limit on how long these Claude sessions stay available - it's possible you could keep that session and PR running indefinitely, continually pushing changes to your deployed environment for many weeks to come.

When you land the PR don't forget to update the Pages settings to point back to the main branch.

Unlike Claude's own Artifacts feature there are no CSP restrictions on what apps deployed to GitHub Pages can do, which means they can interact directly with JSON APIs hosted on other domains.

There are other good options for deploying previews of branches - I've used Cloudflare Pages for this in the past - but it's nice to be able to get this done using GitHub alone.

Taking Neon I at the Crucible

2026-01-11T17:34:29+00:00

I took the Neon I intensive week-long evening class at the Crucible in Oakland, with teachers Dan Kuppe and Kat. I learned to make a neon sign! It's still awaiting final infusion of gas, but I'll share photos here once it's finished.

Here's much of what I learned, at least the parts that can be translated into text.

At the Neon 1 level, the craft is almost entirely around making shapes out of glass. The starting point is lengths of glass tubes - I think ours were 10mm in diameter and 4 feet long.

The way you make those shapes is by heating up and bending that glass, using a variety of gas torches.

This can be done mostly by naked hand - protective gloves weren’t necessary for the bends that we made.

You hold the glass over the gas flame and rotate it constantly to ensure it is equally warmed. Then after som time - usually 15-30s - the glass becomes malleable enough that you can bend it.

The key trick to getting the right bend is heating the right section of the glass. For a tight corner you heat just the very short segment that will form the corner. For a long curve you heat the section that will be part of the curve.

Bending the glass upwards is more effective than bending it downwards - you can use gravity to help, especially useful for larger curves where the glass will naturally sag once it hits the right temperature.

For corners you need to ensure the glass both stays sealed but has a hole that the neon can flow through later. You can help achieve this by blowing air into the glass tube, using a stopper at one end and a rubber hose attached to a mouthpiece at the other.

In a Jedi-make-their-own-lightsabers move, we created our own mouthpieces for the hose by putting a 90 degree bend in a thin tube and then heating and flaring out the end using a torch and a file. I dropped one of these and had to make another one.

It is crucial you don’t blow into the glass while it is in the flame because it is likely to burst! Instead you blow when the glass has just come out of the flame but is still hot - this can visibly affect the shape of the bend you are making. The goal is to have as close to a round hole in the center of the pipe as possible, although even a misinformed oval will still be OK as long as air (and eventually neon) can flow through it.

The best way to achieve a specific shape is to draw it precisely on paper, then cover that paper with a wire mesh so you can drop the glass onto it while it’s still malleable and form it to match the illustration. If you forget the mesh (I did that once) your paper will catch fire!

A tricky skill is planning out the sequence of bends that you will perform on a piece of glass. I haven’t developed a good instinct for this yet. You need to consider the rotation of the glass on the burner - if you create the wrong corners too early you won’t be able to safely position it on the gas such that you can rotate it without burning your hand or getting the glass caught on the apparatus.

Cutting the glass is quite easy: score one edge with a file and then tap it firmly such that it breaks. Some of my breaks were clean and others were jagged, and I’m not sure why but people with better technique consistently achieved clean breaks.

By far the hardest technique (for me at least) was welding. This is when you have two glass tubes and you wish to join them together as if they are one - important for combining pieces of the right shape, fixing breaks and attaching the electrodes at the end (more on that below).

To weld you wedge one glass piece firmly on a table with weights such that the end you attach to protrudes over the edge. Then you align the other glass piece with it and use a hand-held torch to rotate around and heat the ends of the glass tubes - keeping them about half a centimeter away from each other.

Once they are hot enough you kiss them together, then continue to heat the junction to get it malleable. Then you remove the heat and blow down the tube while stretching it out a little to try to get a clean merged section - ideally looking as close to a regular tube of glass as possible.

Doing this requires depth perception and a lot of practice. I only have one working eye, which usually doesn’t affect me much but turns out to make welding incredibly hard do to the need to align two glass tubes and a hand torch all at the same time.

The final step is to attach electrodes to the ends of your glass segments. These come as short glass tubes with wires coming out of them, which you weld onto the ends.

One of those electrodes will have a thin glass tube protruding from the end. This is used later on to insert the neon (or argon) gas as the final part of the process.

A few more miscellaneous tips I picked up:

The final piece should not have two glass tubes touching each other as this can cause arcs to interfere with each other. A thin layer of silicon between the tubes fixes this.
Neon comes out orange, argon comes out purple. There are colored glasses that can achieve other colors but we didn’t use these in our beginners’ class.
It’s important to wrap your rubber hose around your arm in a way that avoids it coming into contact with the burner or hot glass.
Use wooden paddles to help flatten glass shapes while they are still warm. Using cold metal can cause the glass to weaken or fracture.

Downloading archived Git repositories from archive.softwareheritage.org

2025-12-30T23:43:48+00:00

Last February I blogged about a neat script called sqlite-s3vfs which was released as MIT licensed open source by the UK government's Department for Business and Trade.

I went looking for it today and found that the github.com/uktrade/sqlite-s3vfs repository is now a 404.

Since this is taxpayer-funded software and was released MIT I felt a moral obligation to try and restore the repository!

My restored copy can be found at github.com/simonw/sqlite-s3vfs. Here's how I made it.

Claude suggested trying the Software Heritage archive and sure enough a search for https://github.com/uktrade/sqlite-s3vfs on their site resolved to this archived page, which appeared to have a full copy of the repo.

Downloading a snapshot of the most recent state was easy enough, but I wanted the full Git history. I stumbled across this Hacker News comment which helped me figure out the right way to do this.

Software Heritage have all sorts of different IDs. The ID that worked for me was something they call a "snapshot ID". I found this in their "Permalinks" sidebar under the "snapshot" tag:

It started swh:1:snp: - the ID for this repository was:

swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf

You can then make an API call to request a Git bundle for that snapshot:

curl -XPOST 'https://archive.softwareheritage.org/api/1/vault/git-bare/swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf/'

This returned JSON that looks like this:

{
  "fetch_url": "https://archive.softwareheritage.org/api/1/vault/git-bare/swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf/raw/",
  "progress_message": null,
  "id": 417949633,
  "status": "done",
  "swhid": "swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf"
}

That fetch_url is what you need to download the Git bundle as a .tar.gz file. It redirects to blob storage so you need to use -L with curl:

curl -L -o bundle.tar.gz 'https://archive.softwareheritage.org/api/1/vault/git-bare/swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf/raw/'

Then decompress it:

tar -xzvf bundle.tar.gz

The result starts like this:

x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/HEAD
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/branches/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/config
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/description
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/hooks/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/info/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/info/exclude
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/info/refs
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/objects/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/objects/info/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/objects/info/packs
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/objects/pack/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/objects/pack/pack-9946e5e52f40fd1df3352da074f9ac059e87ca9d.idx
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/objects/pack/pack-9946e5e52f40fd1df3352da074f9ac059e87ca9d.pack
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/heads/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/heads/dependabot/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/heads/dependabot/github_actions/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/heads/dependabot/github_actions/dot-github/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/heads/dependabot/github_actions/dot-github/workflows/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/heads/dependabot/github_actions/dot-github/workflows/actions/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/heads/dependabot/github_actions/dot-github/workflows/actions/download-artifact-4.1.7
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/heads/main
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/pull/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/pull/11/
x swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git/refs/pull/11/head
...

That swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git is a bare Git repository. You can clone it into a usable working copy like this:

git clone swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git sqlite-s3vfs

I created an empty repo on GitHub and ran these commands to push everything up:

cd sqlite-s3vfs
git remote set-url origin git@github.com:simonw/sqlite-s3vfs.git
git push --all origin
git push --tags origin

I had to use set-url because the original origin was that /tmp/swh:1:snp:1930ecd7bcc8c8666c721c4def3944c98d650abf.git local path.

Building an HTML tool to make this easier in the future

It turns out all of the relevant APIs are unauthenticated and support CORS headers, so I had Claude Code build me a page for automating part of this process in the future:

https://tools.simonwillison.net/software-heritage-repo

Here's that tool with the old GitHub repo URL pre-filled, just click the button:

https://tools.simonwillison.net/software-heritage-repo#https%3A%2F%2Fgithub.com%2Fuktrade%2Fsqlite-s3vfs

And here's the Claude Code transcript I used to build this.

Subtests in pytest 9.0.0+

2025-12-05T05:44:04+00:00

pytest 9.0.0 was released on November 8th 2025. I just got around to looking at the release notes and the biggest new feature is subtests, previously available as the separate pytest-subtests plugin.

I copied the documentation into Claude Code and told it to find a good place to try them in the Datasette test suite. It suggested tests/test_docs.py, which currently make heavy use of the @pytest.mark.parametrize mechanism. I wrote about how that works a few years ago in Documentation unit tests - here's an example test:

@pytest.mark.parametrize("setting", app.SETTINGS)
def test_settings_are_documented(settings_headings, setting):
    assert setting.name in settings_headings

Understanding subtests

The idea behind subtests is to allow a test to programatically create new subtest within itself at runtime.

My above example does the same thing using @pytest.mark.parametrize - but it relies on the list of settings being known at test collection time. This might not be possible for things that need to be introspected after the test has run some initial setup code.

Here's the above test ported to use subtests instead:

def test_settings_are_documented(settings_headings, subtests):
    for setting in app.SETTINGS:
        with subtests.test(setting=setting.name):
            assert setting.name in settings_headings

subtests is a new default pytest fixture - if you list that as a parameter to your test function you can use it in the body of the test.

Using with subtests.test(...) creates a new subtest. Here I'm doing that in a loop. The keyword arguments passed to subtests.test() are used to identify the subtest in the test report.

That's all it takes! Here's a commit that ported several of my parameterized tests to use subtests instead.

How subtests differ from parametrize

If you use @pytest.mark.parametrize pytest will behave as if every one of your parameter combinations is a separate test function. Running the old pytest tests/test_docs.py tests looked like this:

============================= test session starts ==============================
platform darwin -- Python 3.14.0, pytest-9.0.1, pluggy-1.6.0
SQLite: 3.50.4
rootdir: /private/tmp/datasette
configfile: pytest.ini
plugins: anyio-4.12.0, xdist-3.8.0, timeout-2.4.0, asyncio-1.3.0
asyncio: mode=Mode.STRICT, debug=False, asyncio_default_fixture_loop_scope=None, asyncio_default_test_loop_scope=function
collected 120 items                                                            

tests/test_docs.py ..................................................... [ 44%]
...................................................................      [100%]

============================= 120 passed in 0.84s ==============================

Porting to subtests causes each test to be reported just once:

...
collected 9 items                                                             

tests/test_docs.py .........                                            [100%]

============================== 9 passed in 0.15s ==============================

But... if you add -v for verbose output you get back a report that does include every subtest. Truncated, that looks like this:

...
collected 9 items                                                                                                

tests/test_docs.py::test_settings_are_documented SUBPASSED(setting='default_page_size')                    [ 11%]
tests/test_docs.py::test_settings_are_documented SUBPASSED(setting='max_returned_rows')                    [ 11%]
...
tests/test_docs.py::test_settings_are_documented PASSED                                                    [ 11%]
tests/test_docs.py::test_plugin_hooks_are_documented SUBPASSED(plugin='actor_from_request')                [ 22%]
tests/test_docs.py::test_plugin_hooks_are_documented SUBPASSED(plugin='actors_from_ids')                   [ 22%]
tests/test_docs.py::test_plugin_hooks_are_documented PASSED                                                [ 22%]...

...
tests/test_docs.py::test_rst_heading_underlines_match_title_length PASSED                                  [ 66%]
tests/test_docs.py::test_homepage PASSED                                                                   [ 77%]
tests/test_docs.py::test_actor_is_null PASSED                                                              [ 88%]
tests/test_docs.py::test_signed_cookie_actor PASSED                                                        [100%]

============================== 9 passed, 116 subtests passed in 0.15s ==============================

The last line shows how many subtests passed in addition to how many tests.

It looks to me like subtests run substantially faster than the eqpuivalent parameterized tests. I'm more interested in the fact that subtests can now be programatically generated at runtime based on test setup code.

Dependency groups and uv run

2025-12-03T04:55:17+00:00

I've adopted a new (to me) pattern for my Python projects to make them easier to hack on using uv run. I'm using a PEP 735 dependency group called dev to declare my development dependencies - in particular pytest - such that running uv run pytest executes the tests for my project without me having to even think about setting up a virtual environment first.

Here's the pattern I'm using. I start by creating a new library using uv init --lib like this:

mkdir my-new-library
cd my-new-library
uv init --lib

This creates a pyproject.toml file like this:

[project]
name = "my-new-library"
version = "0.1.0"
description = "Add your description here"
readme = "README.md"
authors = [
    { name = "Simon Willison", email = "...@gmail.com" }
]
requires-python = ">=3.10"
dependencies = []

[build-system]
requires = ["uv_build>=0.9.15,<0.10.0"]
build-backend = "uv_build"

It also creates a src/my_new_library/__init__.py file with a hello() example function.

Next, I add pytest as a development dependency using this command:

uv add --dev pytest

Doing so adds a new section to the end of that pyproject.toml file:

[dependency-groups]
dev = [
    "pytest>=9.0.1",
]

This also creates the virtual environment in .venv and uv.lock file, but we don't need to think about those.

Then I create a test:

mkdir tests
echo  'from my_new_library import hello

def test_hello():
    assert hello() == "Hello from my-new-library!"' > tests/test_my_new_library.py

Now I can run that test suite using:

uv run pytest

The dev dependency group is a special case for uv run - it will always install those dependencies as well such that commands like pytest can work correctly.

When you package a project for distribution the dev dependencies will not be automatically installed for users of your package.

The importance of [build-system] for specifying a package

That [build-system] section is crucial, because it tells uv that the directory should be treated as a "package". This means that when uv run executes it installs the current directory as an editable package in the virtual environment.

Removing [build-system] and then rm -rf .venv to delete the virtual environment results in the following error when trying to run uv run pytest:

________________ ERROR collecting tests/test_my_new_library.py _________________
ImportError while importing test module '/private/tmp/my-new-library/tests/test_my_new_library.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/opt/homebrew/Caskroom/miniconda/base/lib/python3.10/importlib/__init__.py:126: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
tests/test_my_new_library.py:1: in <module>
    from my_new_library import hello
E   ModuleNotFoundError: No module named 'my_new_library'
=========================== short test summary info ============================
ERROR tests/test_my_new_library.py
!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!
=============================== 1 error in 0.07s ===============================

Adding the [build-system] section back in gets rid of this error.

There's an alternative to having a [build-system] section, which is to add this to the pyproject.toml file instead:

[tool.uv]
package = true

I had Claude Code investigate this and it found this section of code explaining what's going on:

pub fn is_package(&self, require_build_system: bool) -> bool {
    // If `tool.uv.package` is set, defer to that explicit setting.
    if let Some(is_package) = self.tool_uv_package() {
        return is_package;
    }
    // Otherwise, a project is assumed to be a package if `build-system` is present.
    self.build_system.is_some() || !require_build_system
}

So there's no need to use that [tool.uv] section if you already have a [build-system] section.

Installation in CI

If you're still using regular pip in your CI scripts you'll need to ensure the dev dependency group is installed like this:

pip install . --group dev

The end result

Projects that use this pattern become a whole lot easier for other people to hack on. I first used this for my datasette-extract package, with the result that checking out and running the tests is now a case of running just the following commands:

git clone https://github.com/datasette/datasette-extract
cd datasette-extract
uv run pytest

No need to think about virtual environments or development dependencies - this just works.

Building a distributable wheel of the project is a one-liner as well:

uv build

This creates two files:

dist/datasette_extract-0.2a0-py3-none-any.whl
dist/datasette_extract-0.2a0.tar.gz

The .tar.gz file should contain everything including the tests - the .whl file should contain just the non-development Python code.

Bonus tip: defining dev in terms of other dependency groups

The dev group is a special case: tools like uv run will install everything in that group automatically.

What if you want to divide up your dependencies into test dependencies, documentation dependencies and so on?

Thanks to Martín Gaitán's python-package-copier-template I learned about this pattern for defining dev in terms of other groups:

[dependency-groups]
test = [
    "pytest",
    "pytest-asyncio"
]
docs = [
    "sphinx"
]
dev = [
    { include-group = "test" },
    { include-group = "docs" }
]

Now if you just want to use the test dependencies you can run this:

uv run --group test pytest

Using Codex CLI with gpt-oss:120b on an NVIDIA DGX Spark via Tailscale

2025-11-07T07:16:55+00:00

I've written about the DGX Spark before. Here's how I got OpenAI's Codex CLI to run on my Mac against a gpt-oss:120b model running on the DGX Spark via a Tailscale network.

Setting up Tailscale

I installed Tailscale on the Spark a while ago and didn't make detailed notes. The Spark runs Ubuntu so I followed the Tailscale Linux installation instructions.

My Mac is signed into Tailscale as well. I obtained the IP address for the Spark from the MacOS system tray menu: Network Devices -> My Devices -> spark-18b3 (the hostname).

For me that was:

100.113.1.114

Ollama on the Spark

I installed Ollama on the Spark using their installation script. This got it running as a service, but the default settings bind it to localhost only. I wanted to access it from other machines, so I did the following (with the help of Claude Code):

sudo mkdir -p /etc/systemd/system/ollama.service.d
sudo bash -c 'cat > /etc/systemd/system/ollama.service.d/override.conf <<EOF
[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"
EOF'

Then restarted Ollama:

sudo systemctl daemon-reload
sudo systemctl restart ollama

I confirmed it was running by visiting this URL on my Mac:

http://100.113.1.114:11434/

Which returned the text:

Ollama is running

Hitting Ollama from the Mac

I had Ollama installed on my Mac already as well, which meant the ollama client tool was available.

Setting the OLLAMA_HOST environment variable to point to the Spark means that client tool can talk to that Ollama server instead.

Here's an example session on my Mac. ollama ls on its own shows the models installed locally on my Mac:

~ % ollama ls
NAME                ID              SIZE      MODIFIED      
gpt-oss:20b         aa4295ac10c3    13 GB     7 weeks ago      
gemma3:270m         b16d6d39dfbd    241 MB    2 months ago     
gemma3:4b           c0494fe00251    3.3 GB    7 months ago     
deepseek-r1:1.5b    a42b25d8c10a    1.1 GB    9 months ago     
llama3.2:3b         a80c4f17acd5    2.0 GB    10 months ago

But if I add OLLAMA_HOST= before the command I talk to the Spark instead:

~ % OLLAMA_HOST=100.113.1.114:11434 ollama ls
NAME            ID              SIZE      MODIFIED    
llama3.2:3b     a80c4f17acd5    2.0 GB    6 weeks ago    
gpt-oss:120b    f7f8e2f8f4e0    65 GB     7 weeks ago    
gpt-oss:20b     aa4295ac10c3    13 GB     7 weeks ago    
qwen3:4b        e55aed6fe643    2.5 GB    7 weeks ago

It already had the 120b model, but if it didn't I could pull it with this command:

OLLAMA_HOST=100.113.1.114:11434 ollama pull gpt-oss:120b

I can start an interactive chat session with the model like this:

~ % OLLAMA_HOST=100.113.1.114:11434 ollama run gpt-oss:120b  
>>> hi
Thinking...
The user says "hi". Need to respond friendly. Probably ask how can help.
...done thinking.

Hello! 👋 How can I assist you today?

Or use my LLM tool with the llm-ollama plugin like so:

uv tool install llm
llm install llm-ollama
OLLAMA_HOST=100.113.1.114:11434 llm -m gpt-oss:120b \
   "Write a haiku about Tailscale"

Cute:

Clouds become a thread  
Phones and laptops link as one  
Network breathes as one

Setting export OLLAMA_HOST=100.113.1.114:11434 saves me from having to type it each time.

Running the Codex CLI

This was harder to figure out - I'm not sure the Ollama mechanis is particularly stable, so I ended up checking out openai/codex and having Codex with GPT-5 figure out how to configure that OLLAMA_HOST setting. Here's that transcript.

The recipe that worked for me was this one:

CODEX_OSS_BASE_URL=http://100.113.1.114:11434/v1 \
  codex --oss --model gpt-oss:120b

The CODEX_OSS_BASE_URL environment variable tells Codex CLI where to find the Ollama server API endpoint. By default it uses the smaller gpt-oss:20b model, but passing --model gpt-oss:120b tells it to use the 120b model instead.

Building Space Invaders

I ran this sequence of prompts inside Codex:

make /tmp/invaders and cd to that
build space invaders as a single HTML file
init a git repo and commit your code
Make the space invaders different colors

Here's the resulting game, and a copy of the transcript.

So it works! I can now run Codex on my Mac against a competent-enough model on the Spark, via Tailscale which means I can access it using my laptop anywhere in the world.

I don't think I'll use this heavily - GPT-5 and Sonnet 4.5 remain wildly more capable than gpt-oss:120b - but it's neat to be able to do this.

Exploring OpenAI's deep research API model o4-mini-deep-research

2025-10-18T18:46:03+00:00

I was reviewing some older PRs and landed this one by Manuel Solorzano adding pricing for o4-mini-deep-research and o3-deep-research to my llm-prices.com site. I realized I hadn't tried those models yet so I decided to give one of them a go.

o4-mini-deep-research is significantly cheaper than o3-deep-research - $2/$8 per million for input/output compared to $10/$40 - so I tried that one.

These models are only available via the Responses API and recommend running using their "background" mode. My LLM tooling doesn't support that yet so I used curl instead.

Here's what I tried:

curl https://api.openai.com/v1/responses \
  -H "Authorization: Bearer $(llm keys get openai)" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "o4-mini-deep-research-2025-06-26",
    "input": "Find locations of every surviving orchestrion in the world. Include the city, country, venue, latitude, longitude, brief description and if available a history of when and where that orchestrion was made and its path to its current location. Return a JSON array of objects. Include a notes field for anything interesting that doesn'\''t fit the other fields.",
    "reasoning": { "summary": "auto" },
    "background": true,
    "tools": [
      { "type": "web_search_preview" },
      { "type": "code_interpreter", "container": { "type": "auto" } }
    ]
  }'

Here's the prompt I'm using (I really like orchestrions):

Find locations of every surviving orchestrion in the world. Include the city, country, venue, latitude, longitude, brief description and if available a history of when and where that orchestrion was made and its path to its current location. Return a JSON array of objects. Include a notes field for anything interesting that doesn't fit the other fields.

This returned a response ID and `"status": "queued", which started like this:

{
  "id": "resp_04911070f2b5d8560068f3ccd776788190b51f5497d7b27a30",
  "object": "response",
  "created_at": 1760808151,
  "status": "queued",

I then polled that ID for the result, looking at the "status" field with jq each time:

curl https://api.openai.com/v1/responses/resp_04911070f2b5d8560068f3ccd776788190b51f5497d7b27a30 \
  -H "Authorization: Bearer $(llm keys get openai)" \
  -H "Content-Type: application/json" | jq .status

That returned "in_progress" for a while, and then finally "succeeded".

Here's the full JSON that came back from that final request. That's 90KB of data (after pretty-printing with jq).

First lets look at the cost. That JSON ended with this "usage" block:

{
    "input_tokens": 60506,
    "input_tokens_details": {
        "cached_tokens": 0
    },
    "output_tokens": 22883,
    "output_tokens_details": {
        "reasoning_tokens": 20416
    },
    "total_tokens": 83389
}

Running this through llm-prices.com for $2/$8 per million input/output tokens gives a total of 30.4076 cents.

But what about the searches it ran? Annoyingly, OpenAI don't include those in the "usage" block. As far as I can tell you have to calculate them yourself by counting the number of "web_search_preview" tool calls it made.

I count 77 of those. OpenAI's pricing page says $10.00 / 1K calls, so 1 cent per call, so that's 77 cents on search.

It also fired up code interpreter for a few things (mostly co-ordinate trasforms with pyproj) - the pricing page says "$0.03 / session" so I guess that's another 3 cents.

Total cost: 77 + 30.4076 + 3 = 110.4076 cents, $1.10.

The results

I added a feature (with GitHub Copilot coding agent to my JSON string extractor tool to help display the result. Here's the long strings extracted from that full JSON.

The thought process started like this:

Searching for orchestrions

I’m looking at a static page about the historical context of orchestrions, but it seems like it doesn't list where surviving ones are located. This museum might be in Switzerland and could include images. To find currently existing orchestrions, I need to explore mechanical music museums like Speelklok or check old hotels that might still have them. An orchestrion is a large self-playing instrument, often with pipes or violins. Let's search for mechanical music museums featuring orchestrions!

I vibe-coded up a quick viewer for this using Claude Code, here's that full trace in a UI. That one claims 45 searches rather than 77, I asked Claude Code and it noted that some of those "type": "web_search_preview" calls were "action": "search" but others were "action": "open_page". I don't know if "open_page" calls count the same as searches for pricing, but the tool shows 45 searches and 24 pages visited (and 12 code executions).

The output also included the JSON I had asked for - a JSON array of 19 orchestrions. I dropped that in a Gist and opened it in Datasette Lite to explore it.

Then I switched back to Claude Code and had it convert that to GeoJSON, so I could view it GitHub's GeoJSON viewer.

Finally I had Claude Code knock out a custom HTML viewer just for that file, with de-duplication across identical venues. Here's the resulting HTML, which you can see rendered via gitpreview.github.io here:

https://gistpreview.github.io/?b9f5416b37c4ceec46d8447b52be0ad2

I'm using a secret URL Gist served through gistpreview.github.io here to reduce the chance of this unverified slop content getting indexed by crawlers and making it out into the wider world.

How well did it do?

It found me 19 orchestrions across 7 venues in 7 different countries.

I haven't fact-checked them all, but the first one - at the Musical MUseum in Brentford, London - is one that I've seen with my own eye.

This clearly isn't a comprehensive list, but I'm not sure asking "deep research" tools for a comprehensive list really plays into their strengths. There's a limit on how many tool calls they can churn through in a single session.

I don't consider the results publishable outside of a TIL post explaining what I did precisely because the information still needs to be verified.

It did however highlight both Museum Speelklok in Utrecht and The Sanfilippo Foundation in Barrington, Illinois as two places I should make a pilgrimage to as soon as possible!

Testing different Python versions with uv with-editable and uv-test

2025-10-09T02:47:48+00:00

A quick uv recipe I figured out today, for running the tests for a project against multiple Python versions.

The key command option is uv run --with-editable .[test].

Start with any Python project that has a [test] extra defined, for example:

cd /tmp
git clone https://github.com/simonw/datasette
cd datasette

Then run uv against it with a specific Python version like this:

uv run --python 3.14 --isolated --with-editable '.[test]' pytest -n auto

Here I'm using --isolated to make sure nothing from any other environments sneaks in.

The --with-editable '.[test]' part is important - it tells uv to install the current project in editable mode so that changes you make will be picked up. I first tried this using --with '.[test]' and was confused as to why changes I made to the code weren't being picked up when I re-ran the tests.

Datasette uses pytest-xdist to run tests in parallel, so I added -n auto to have it automatically use all available CPU cores.

uv-test

I wrote a little helper script (with ChatGPT's help) to make this easier to remember. It uses Python 3.14 by default but you can pass a different version as the -p argument. Any subsequent arguments will be passed to pytest.

#!/bin/sh
set -eu  # (no pipefail in POSIX sh)

usage() {
  echo "Usage: uv-test [-p|--python PY_VER] [pytest args...]"
  echo "  -p, --python  Set Python version (default: \$UV_PY or 3.14)"
  echo "  -h, --help    Show this help"
}

PYVER="${UV_PY:-3.14}"

# Parse only our flags; pass the rest to pytest
while [ $# -gt 0 ]; do
  case "$1" in
    -p|--python)
      shift
      [ $# -gt 0 ] || { echo "error: -p/--python requires a version" >&2; exit 2; }
      PYVER="$1"; shift ;;
    -h|--help) usage; exit 0 ;;
    --) shift; break ;;
    *) break ;;
  esac
done

command -v uv >/dev/null 2>&1 || { echo "error: 'uv' not found in PATH" >&2; exit 127; }
if [ ! -f pyproject.toml ] && [ ! -f setup.py ]; then
  echo "error: no project file found (need pyproject.toml or setup.py). Run from project root." >&2
  exit 1
fi

exec uv run --python "$PYVER" --isolated --with-editable '.[test]' -- python -m pytest "$@"

Make it executable and put it somewhere in your PATH, then you can run it like this:

uv-test

Or for a specific Python version:

uv-test -p 3.13

And for custom pytest arguments:

uv-test -k permissions

Or combined:

uv-test -p 3.12 -k permissions -vv

Variants: tadd and radd

For Datasette issue #2549 I found myself needing to run the test suites for many different Datasette plugins against my local not-released main branch of Datasette. I ended up creating two new utility scripts, chmod 755 and on my path.

Here's tadd, for "test against Datasette dev":

#!/bin/sh
uv run --no-project --isolated \
  --with-editable '.[test]' --with-editable ~/dev/datasette \
  python -m pytest "$@"

And radd, for "run against Datasette dev":

#!/usr/bin/env bash
set -euo pipefail

datasette_args=()
uv_with_args=()

# Parse CLI: take any --with X (or --with=X) for uv; everything else -> passed to datasette
while [ "$#" -gt 0 ]; do
  case "$1" in
    --with)
      if [ "$#" -lt 2 ]; then
        echo "tadd: missing value for --with" >&2
        exit 2
      fi
      uv_with_args+=(--with "$2")
      shift 2
      ;;
    --with=*)
      uv_with_args+=(--with "${1#--with=}")
      shift
      ;;
    --) # explicit separator: rest go to pytest_args verbatim
      shift
      # preserve original quoting/word boundaries
      datasette_args+=("$@")
      break
      ;;
    *)
      # anything else goes to pytest/datasette
      datasette_args+=("$1")
      shift
      ;;
  esac
done

# Run
exec uv run "${uv_with_args[@]}" --no-project --isolated \
  --with-editable '.[test]' --with-editable "$HOME/dev/datasette" \
  -- datasette "${datasette_args[@]}"

They both take arguments, e.g.:

tadd -x --pdb
radd content.db -p 8004 --root