Cloud AI APIs are great until they are not. Rate limits, usage costs, privacy concerns, and network latency all add up. For quick tasks like code review, drafting, or testing prompts, a local model that runs entirely on your hardware has real advantages: zero API costs, no data leaving your machine, and consistent availability.

Google’s Gemma 4 is interesting for local use because of its mixture-of-experts architecture. The 26B parameter model only activates 4B parameters per forward pass, which means it runs well on hardware that could never handle a dense 26B model. On my 14” MacBook Pro M4 Pro with 48 GB of unified memory, it fits comfortably and generates at 51 tokens per second. Though there’s significant slowdowns when used within Claude Code from my experience.

The Gemma 4 model family

Google released Gemma 4 as a family of four models, not just one. The lineup spans a wide range of hardware targets:

The “E” models (E2B, E4B) use Per-Layer Embeddings to optimize for on-device deployment and are the only variants that support audio input (speech recognition and translation). The 31B dense model is the most capable, scoring 85.2% on MMLU Pro and 89.2% on AIME 2026.

Why I picked the 26B-A4B. The mixture-of-experts architecture is the key. It has 128 experts plus 1 shared expert, but only activates 8 experts (3.8B parameters) per token. A common rule of thumb estimates MoE dense - equivalent quality as roughly sqrt(total x active parameters), which puts this model around 10B effective. In practice, it delivers inference cost comparable to a 4B dense model with quality that punches well above that weight class. On benchmarks, it scores 82.6% on MMLU Pro and 88.3% on AIME 2026, close to the dense 31B (85.2% and 89.2%) while running dramatically faster.

The chart below tells the story. It plots Elo score against total model size on a log scale for recent open-weight models with thinking enabled. The blue-highlighted region in the upper left is where you want to be: high performance, small footprint.

Gemma 4 26B-A4B (Elo ~1441) sits firmly in that zone, punching well above its 25.2B parameter weight. The 31B dense variant scores slightly higher (~1451) but is still remarkably compact. For context, models like Qwen 3.5 397B-A17B (~1450 Elo) and GLM-5 (~1457 Elo) need 100-600B total parameters to reach similar scores. Kimi-K2.5 (~1457 Elo) requires over 1,000B. The 26B-A4B achieves competitive Elo with a fraction of the parameters, which translates directly into lower memory requirements and faster local inference.

This is what makes MoE models transformative for local use. You do not need a cluster or a high-end GPU rig to run a model that competes with 400B+ parameter behemoths. A laptop with 48 GB of unified memory is enough.

For local inference on a 48 GB Mac, this is the sweet spot. The dense 31B would consume more memory and generate tokens slower because every parameter participates in every forward pass. The E4B is lighter but noticeably less capable. The 26B-A4B gives you 256K max context, vision support (useful for analyzing screenshots and diagrams), native function/tool calling, and reasoning with configurable thinking modes, all at 51 tokens/second on my hardware.

What changed in LM Studio 0.4.0

LM Studio has been a popular desktop app for running local models for a while. Version 0.4.0 changed the architecture fundamentally by introducing llmster, the core inference engine extracted from the desktop app and packaged as a standalone server.

The practical result: you can now run LM Studio entirely from the command line using the lms CLI. No GUI required. This makes it usable on headless servers, in CI/CD pipelines, SSH sessions, or just for developers who prefer staying in the terminal.

Key additions in 0.4.0:

• llmster daemon: a background service that manages model loading and inference without the desktop app

• lms CLI: full command-line interface for downloading, loading, chatting, and serving models

• Parallel request processing: continuous batching instead of sequential queuing, so multiple requests to the same model run concurrently

• Stateful REST API: a new /v1/chat endpoint that maintains conversation history across requests

• MCP integration: local Model Context Protocol support with permission-key gating

Installation

Install the lms CLI with a single command:

# Linux/Mac
curl -fsSL https://lmstudio.ai/install.sh | bash

# Windows
irm https://lmstudio.ai/install.ps1 | iex

Then start the headless daemon:

lms daemon up

On macOS, update both inference runtimes:

lms runtime update llama.cpp
lms runtime update mlx

Downloading Gemma 4

With the daemon running, download Google’s Gemma 4 26B model:

lms get google/gemma-4-26b-a4b

The CLI shows you the variant it will download (Q4_K_M quantization by default, 17.99 GB) and asks for confirmation:

   ↓ To download: model google/gemma-4-26b-a4b - 64.75 KB
   └─ ↓ To download: Gemma 4 26B A4B Instruct Q4_K_M [GGUF] - 17.99 GB

About to download 17.99 GB.

? Start download?
❯ Yes
  No
  Change variant selection

If you already have the model, the CLI tells you and shows the load command:

✔ Start download? yes
Model already downloaded. To use, run: lms load google/gemma-4-26b-a4b

Checking your local model library

List all downloaded models:

lms ls

You have 10 models, taking up 118.17 GB of disk space.

LLM                                   PARAMS     ARCH             SIZE         DEVICE
gemma-3-270m-it-mlx                   270m       gemma3_text      497.80 MB    Local
google/gemma-4-26b-a4b (1 variant)    26B-A4B    gemma4           17.99 GB     Local
gpt-oss-20b-mlx                       20B        gpt_oss          22.26 GB     Local
llama-3.2-1b-instruct                 1B         Llama            712.58 MB    Local
nvidia/nemotron-3-nano (1 variant)    30B        nemotron_h       17.79 GB     Local
openai/gpt-oss-20b (1 variant)        20B        gpt-oss          12.11 GB     Local
qwen/qwen3.5-35b-a3b (1 variant)      35B-A3B    qwen35moe        22.07 GB     Local
qwen2.5-0.5b-instruct-mlx             0.5B       Qwen2            293.99 MB    Local
zai-org/glm-4.7-flash (1 variant)     30B        glm4_moe_lite    24.36 GB     Local

EMBEDDING                               PARAMS    ARCH          SIZE        DEVICE
text-embedding-nomic-embed-text-v1.5              Nomic BERT    84.11 MB    Local

Worth noting: several of these models use mixture-of-experts architectures (Gemma 4, Qwen 3.5, GLM 4.7 Flash). MoE models punch above their weight for local inference because only a fraction of parameters activate per token.

Running an interactive chat

Start a chat session with stats enabled to see performance numbers:

lms chat google/gemma-4-26b-a4b --stats

 ╭─────────────────────────────────────────────────╮
 │ 👾 lms chat                                     │
 │ Type exit or Ctrl+C to quit                     │
 │                                                 │
 │ Chatting with google/gemma-4-26b-a4b            │
 │                                                 │
 │ Try one of the following commands:              │
 │ /model - Load a model (type /model to see list) │
 │ /download - Download a model                    │
 │ /clear - Clear the chat history                 │
 │ /help - Show help information                   │
 ╰─────────────────────────────────────────────────╯

With --stats, you get prediction metrics after each response:

Prediction Stats:
  Stop Reason: eosFound
  Tokens/Second: 51.35
  Time to First Token: 1.551s
  Prompt Tokens: 39
  Predicted Tokens: 176
  Total Tokens: 215

51 tokens/second on a 14” MacBook Pro M4 Pro (48 GB) with a 26B model is solid. Time to first token at 1.5 seconds is responsive enough for interactive use.

Checking loaded models and memory

See what is currently loaded:

lms ps

IDENTIFIER                MODEL                     STATUS    SIZE        CONTEXT    PARALLEL    DEVICE    TTL
google/gemma-4-26b-a4b    google/gemma-4-26b-a4b    IDLE      17.99 GB    48000      2           Local     60m / 1h

The model occupies 17.99 GB in memory with a 48K context window and supports 2 parallel requests. The TTL (time-to-live) auto-unloads the model after 1 hour of idle time, freeing memory without manual intervention.

For detailed model metadata, pipe through jq:

lms ps --json | jq

lms ps --json | jq
[
  {
    "type": "llm",
    "modelKey": "google/gemma-4-26b-a4b",
    "format": "gguf",
    "displayName": "Gemma 4 26B A4B",
    "publisher": "google",
    "path": "google/gemma-4-26b-a4b",
    "sizeBytes": 17990911801,
    "indexedModelIdentifier": "google/gemma-4-26b-a4b",
    "deviceIdentifier": null,
    "paramsString": "26B-A4B",
    "architecture": "gemma4",
    "quantization": {
      "name": "Q4_K_M",
      "bits": 4
    },
    "variants": [
      "google/gemma-4-26b-a4b@q4_k_m"
    ],
    "selectedVariant": "google/gemma-4-26b-a4b@q4_k_m",
    "identifier": "google/gemma-4-26b-a4b",
    "ttlMs": 3600000,
    "lastUsedTime": 1775316805638,
    "vision": true,
    "trainedForToolUse": true,
    "maxContextLength": 262144,
    "contextLength": 48000,
    "status": "idle",
    "queued": 0,
    "parallel": 2
  }
]

Key fields from the JSON output:

• "architecture": "gemma4" with "quantization": {"name": "Q4_K_M", "bits": 4}

• "vision": true and "trainedForToolUse": true - Gemma 4 supports both image input and tool calling

• "maxContextLength": 262144 - the model supports up to 256K context, though the default load is 48K

• "parallel": 2 - two concurrent inference requests via continuous batching

Memory estimates by context length

Before loading a model, you can estimate memory requirements at different context lengths using --estimate-only. I wrote a small script to test across the full range:

The base model takes about 17.6 GiB regardless of context. Each doubling of context length adds roughly 3-4 GiB. At the default 48K context, you need about 21 GiB. On my 48 GB MacBook Pro, I can push to the full 256K context at 37.48 GiB and still have about 10 GB free for the OS and other apps. A 36 GB Mac could comfortably run 200K context with headroom.

The estimation command is straightforward:

lms load google/gemma-4-26b-a4b --estimate-only --context-length 48000

Model: google/gemma-4-26b-a4b
Context Length: 48,000
Estimated GPU Memory:   21.05 GiB
Estimated Total Memory: 21.05 GiB

Estimate: This model may be loaded based on your resource guardrails settings.

This is useful for capacity planning. If you want to run Gemma 4 alongside other applications, check the estimate at your target context length first.

Here is the full script I used to generate the table above. You can swap in any model name and context length list to profile a different model:

#!/usr/bin/env bash

model="google/gemma-4-26b-a4b"
contexts=(4096 8000 16000 24000 32000 48000 64000 96000 128000 200000 256000)

table_contexts=()
table_gpu=()
table_total=()

for ctx in "${contexts[@]}"; do
  output="$(lms load "$model" --estimate-only --context-length "$ctx" 2>&1)"

  parsed_context="$(printf '%s\n' "$output" | awk -F': ' '/^Context Length:/ {print $2; exit}')"
  parsed_gpu="$(printf '%s\n' "$output" | awk -F': +' '/^Estimated GPU Memory:/ {print $2; exit}')"
  parsed_total="$(printf '%s\n' "$output" | awk -F': +' '/^Estimated Total Memory:/ {print $2; exit}')"

  table_contexts+=("${parsed_context:-$ctx}")
  table_gpu+=("${parsed_gpu:-N/A}")
  table_total+=("${parsed_total:-N/A}")
done

printf '| Model | Context Length | GPU Memory | Total Memory |\n'
printf '|---|---:|---:|---:|\n'
for i in "${!table_contexts[@]}"; do
  printf '| %s | %s | %s | %s |\n' \
    "$model" "${table_contexts[$i]}" "${table_gpu[$i]}" "${table_total[$i]}"
done

Tuning model loading for your hardware

The default lms load or lms chat commands pick reasonable defaults, but you can tune several parameters to match your specific hardware and use case. Here is a practical decision framework.

Context length: match it to your memory budget

The memory table above is your starting point. Subtract the OS overhead (macOS typically uses 4-6 GB) from your total memory, then find the largest context length that fits.

Load with a specific context length:

lms load google/gemma-4-26b-a4b --context-length 128000

If you are unsure, always run --estimate-only first. It accounts for flash attention and vision model overhead in its calculation.

GPU offloading

On Apple Silicon, the unified memory architecture means CPU and GPU share the same memory pool, so --gpu mostly controls how much computation runs on the GPU versus CPU cores. The default auto setting works well, but you can force full GPU offloading:

lms load google/gemma-4-26b-a4b --gpu=1.0

Use --gpu=max to offload everything possible. On discrete GPU systems (Linux/Windows with NVIDIA cards), this becomes more important because GPU VRAM and system RAM are separate. If your model does not fit entirely in VRAM, partial offloading (--gpu=0.5) splits layers between GPU and CPU, trading some speed for the ability to run larger models.

Parallel requests and continuous batching

LM Studio supports concurrent inference through continuous batching, where multiple requests are dynamically combined into a single computation batch. This is useful when serving the model to multiple clients or running parallel tool calls. The feature requires the llama.cpp runtime (v2.0.0+) and is not yet available for the MLX backend.

Configure it through the GUI: open the model loader, toggle Manually choose model load parameters, select a model, then toggle Show advanced settings to set Max Concurrent Predictions (defaults to 4). There is no CLI flag for this setting; it is configured through the desktop app or per-model defaults.

Each parallel slot consumes additional memory proportional to the context length, so on memory-constrained systems, reduce the parallel count or lower the context length to compensate. With Gemma 4 on 48 GB, 2 parallel slots at 48K context is a good balance.

TTL: auto-unload idle models

The time-to-live setting automatically unloads models after a period of inactivity, freeing memory:

lms load google/gemma-4-26b-a4b --ttl 1800

That sets a 30-minute idle timeout (value is in seconds). The default is 3600 seconds (1 hour). For shared server setups where multiple models might be needed, shorter TTLs help cycle between models without manual lms unload commands. Set TTL to 0 or -1 to disable auto-unloading.

Per-model defaults

If you always load Gemma 4 with the same settings, save them as per-model defaults through the desktop app. Navigate to My Models, click the gear icon next to the model, and configure your preferred GPU offloading, context size, and flash attention settings. These defaults apply everywhere, including when loading via lms load from the CLI.

Speculative decoding

LM Studio supports speculative decoding for dense models, which pairs your main model with a smaller “draft” model to speed up generation. The draft model proposes tokens quickly, and the main model verifies them in batch, which is faster than generating each token independently.

However, speculative decoding is problematic for MoE models like Gemma 4 26B-A4B. During verification, the main model must load the union of all experts activated across all speculative tokens. Since different tokens route to different experts, this blows up memory bandwidth usage and can actually slow things down. Benchmarks on Mixtral showed a 39% speedup on code but a 54% slowdown on math with the same settings, meaning no single configuration works reliably. This is an active research area with approaches like MoE-Spec (expert budgeting) and SP-MoE (expert prefetching) working to solve it, and some newer MoE architectures like Qwen 3.5’s hybrid design are more amenable to speculative approaches. For now, skip speculative decoding with Gemma 4 26B-A4B and rely on its already-fast MoE inference instead.

Flash attention

Flash attention is an optimization that reduces memory usage for the KV cache during inference, letting you fit longer context lengths in the same memory. It is available per-model in LM Studio’s settings. For Gemma 4 on Apple Silicon, enabling flash attention can reduce memory usage at higher context lengths by a meaningful margin. The --estimate-only flag accounts for flash attention in its calculations, so check estimates with and without to see the difference.

The LM Studio desktop app

Everything above used the headless CLI, but LM Studio also ships a full macOS desktop app. The GUI is useful for visual monitoring and quick experiments before committing to a CLI workflow.

The screenshot below shows the desktop app’s server view with Gemma 4 loaded. A few things worth noting:

• Server status shows “Running” with the local endpoint at

http://192.168.1.121:1234

• , reachable by any device on the network

• Loaded Models displays the active model with live stats: 29 generations, 1,087 tokens processed, 17.99 GB in memory

• Supported endpoints include LM Studio API, OpenAI-compatible, and Anthropic-compatible formats, with POST /v1/messages for the Anthropic protocol

• Developer Logs stream prompt processing progress in real time, useful for watching long prompts like code analysis work through the model

The desktop app also supports Gemma 4’s vision capabilities. In below screenshot, you can see the model analyzing an image of the Timezone Scheduler promotional graphic. It correctly identifies the title, world map with timezone color bars, the schedule grid comparing Brisbane/New York/London, feature badges, and the tech stack icons at the bottom. It generated 504 tokens at 54.51 tok/sec with a 3.15s time to first token.

Claude Code alias claude-lm with Google Gemma 4 analysing my Timezones Scheduler benchmark comparison GitHub repository.

The system monitor overlay in the screenshots tells the real story of what local inference looks like on hardware. On my M4 Pro (4 E-Cores + 10 P-Cores, 20 GPU-Cores):

• Memory pressure: 46.69 GB used out of 48.00 GB physical, with 38.07 GB wired memory (that is mostly the model plus context). Swap used: 27.49 GB. The system stays responsive despite near-full memory utilization

• GPU utilization: 90% during inference, with P-Cluster frequency at 4.50 GHz and GPU at 1.45 GHz

• CPU utilization: E-Core at 82.42%, P-Core at 35.96% during generation

• Temperature: CPU cores averaging 91 degrees C, GPU averaging 92.46 degrees C, which is within normal sustained load range for the M4 Pro

• Power draw: 23.56W package total (CPU 11.06W, GPU 13.32W), which is efficient for running a 26B parameter model

This is what makes Apple Silicon compelling for local LLM work. The unified memory architecture means the CPU and GPU share the same memory pool, so there is no copying data between separate CPU RAM and GPU VRAM like on discrete GPU setups. The model loads once into unified memory and both the CPU and GPU access it directly.

Serving models via API

Once a model is loaded, start the local server:

lms server start

This exposes an OpenAI-compatible API at http://localhost:1234/v1. Any tool that works with OpenAI’s API format (Continue, Cursor, custom scripts) can point at your local server instead. LM Studio 0.4.0 also added an Anthropic-compatible endpoint at POST /v1/messages, which means tools that speak the Anthropic protocol can connect directly without an adapter. You can change the port with lms server start --port 8080 if 1234 conflicts with something else.

The server also supports JIT (Just-In-Time) model loading: if a client requests a model that is not currently loaded, LM Studio can auto-load it on demand and auto-unload it after the TTL expires. This is useful for serving multiple models without keeping them all in memory.

To monitor what the server is doing in real time, stream the logs:

lms log stream --source model --stats

This shows each request’s input/output along with tokens/second and latency. For a machine-readable feed, add --json. You can also filter to just server-level events (startup, endpoint hits) with --source server.

Combined with the headless daemon, you can run this on a dedicated machine and serve models across your network. The server is reachable at your machine’s local IP (e.g.,

http://192.168.1.121:1234

), so other devices on the same network can use it as a shared inference endpoint. If you need access control, enable Require Authentication in server settings and generate API tokens with per-token permissions, accessed via the standard Authorization: Bearer $LM_API_TOKEN header.

Using Gemma 4 as a Claude Code backend

The Anthropic-compatible endpoint opens up an interesting use case: running Claude Code against a local model instead of the Anthropic API. This means fully offline, zero-cost coding assistance with no data leaving your machine.

I set up a shell function in ~/.zshrc called claude-lm that configures all the necessary environment variables and launches Claude Code pointed at the local LM Studio server:

claude-lm() {
    export ANTHROPIC_BASE_URL=http://localhost:1234
    export ANTHROPIC_AUTH_TOKEN=lmstudio
    export CLAUDE_CODE_MAX_TOOL_USE_CONCURRENCY="2"
    export CLAUDE_CODE_NO_FLICKER="0"
    export ANTHROPIC_MODEL="gemma-4-26b-a4b"
    export CLAUDE_CODE_AUTO_COMPACT_WINDOW="48000"
    export CLAUDE_AUTOCOMPACT_PCT_OVERRIDE="90"
    export ANTHROPIC_DEFAULT_OPUS_MODEL="google/gemma-4-26b-a4b"
    export ANTHROPIC_DEFAULT_SONNET_MODEL="google/gemma-4-26b-a4b"
    export ANTHROPIC_DEFAULT_HAIKU_MODEL="google/gemma-4-26b-a4b"
    export CLAUDE_CODE_SUBAGENT_MODEL="google/gemma-4-26b-a4b"
    export API_TIMEOUT_MS="30000000"
    export BASH_DEFAULT_TIMEOUT_MS="2400000"
    export BASH_MAX_TIMEOUT_MS="2500000"
    export CLAUDE_CODE_MAX_OUTPUT_TOKENS="8000"
    export CLAUDE_CODE_FILE_READ_MAX_OUTPUT_TOKENS="8000"
    export CLAUDE_CODE_ATTRIBUTION_HEADER="0"
    export CLAUDE_CODE_DISABLE_1M_CONTEXT="1"
    export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING="1"
    claude "$@"
}

What the key variables do:

• ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN point Claude Code at the local LM Studio server. The token value lmstudio is a placeholder; LM Studio does not require authentication by default

• ANTHROPIC_MODEL and the three DEFAULT_*_MODEL variables force all Claude Code model selections (Opus, Sonnet, Haiku) to route through Gemma 4. Without these, Claude Code would try to call Anthropic model names that LM Studio does not recognize

• CLAUDE_CODE_SUBAGENT_MODEL ensures any subagents Claude Code spawns also use the local model

• CLAUDE_CODE_AUTO_COMPACT_WINDOW and CLAUDE_AUTOCOMPACT_PCT_OVERRIDE manage context window compaction. At 48K context, compaction triggers at 90% usage to avoid hitting the limit mid-task

• API_TIMEOUT_MS is set high (30 million ms / ~8.3 hours) because local inference is slower than the Anthropic API and complex tasks need time to complete

• BASH_DEFAULT_TIMEOUT_MS and BASH_MAX_TIMEOUT_MS extend shell command timeouts to 40-42 minutes for long-running operations

• CLAUDE_CODE_MAX_OUTPUT_TOKENS and CLAUDE_CODE_FILE_READ_MAX_OUTPUT_TOKENS cap output at 8K tokens per response, which keeps generation times reasonable on local hardware

• CLAUDE_CODE_DISABLE_1M_CONTEXT and CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING turn off features that assume Anthropic API capabilities the local model does not support

After adding this to ~/.zshrc and running source ~/.zshrc, you can start a fully local Claude Code session with:

claude-lm

It works like normal Claude Code but every request stays on your machine. The trade-off is speed: Gemma 4 at 51 tok/sec is noticeably slower than the Anthropic API for large code generation tasks, but for code review, small edits, and exploration it is perfectly usable.

What I learned

MoE models are the sweet spot for local inference. Gemma 4's 26B-A4B architecture (26B total, 4B active) delivers roughly 10B dense - equivalent quality at 4B inference cost. Look for similar MoE models when choosing what to run locally.

The headless daemon changes the workflow. Before 0.4.0, LM Studio required the desktop app open. Now lms daemon up runs in the background and you interact entirely through the CLI or API. This makes it practical for server deployments and SSH sessions.

Context length is the main memory variable. The model itself takes a fixed ~17.6 GiB. Context scaling is roughly linear, so you can pick exactly the trade-off you want between context window and available memory.

--estimate-only prevents surprises. Always check memory estimates before loading a large model at an aggressive context length. It takes a second and saves you from OOM situations.

The Anthropic-compatible endpoint is a game changer. Being able to point Claude Code at a local model with a shell alias means you can switch between cloud and local inference depending on the task. Privacy-sensitive code review, offline work, or just saving API costs on exploratory sessions all benefit.

What did not work

Gemma 4 does not identify itself by name in lms chat. When asked “what model are you?”, it responds generically as “an AI assistant.” This is a minor limitation of how LM Studio handles system prompts, not a Gemma issue. You can override this with a custom system prompt.

The default 48K context is conservative for a model that supports 256K. If you have the memory, it is worth loading with a higher context length for tasks like long document analysis or multi-file code review.

Running Claude Code with a local model is not a drop-in replacement for the Anthropic API. Complex multi-step tasks that rely on Claude’s extended thinking or very large context windows will hit limitations. The local setup works best for focused, single-file tasks where the 48K context window is sufficient.

Memory pressure on a 48 GB machine with Gemma 4 loaded is real. The system used 46.69 GB out of 48 GB with 27.49 GB of swap during the test. If you run memory-hungry applications alongside the model, expect some swap thrashing. A 64 GB or higher configuration would be more comfortable for sustained use.

What is next

I am testing other local models alongside Gemma 4 for different use cases: Qwen 3.5 35B for coding tasks, GLM 4.7 Flash for quick drafting, and Nemotron 3 Nano for structured extraction. A comparison post covering where each model performs best is in the pipeline.

If you want to try this setup:

• Install: curl -fsSL https://lmstudio.ai/install.sh | bash

• Start the daemon: lms daemon up

• Download Gemma 4: lms get google/gemma-4-26b-a4b

• Chat locally: lms chat google/gemma-4-26b-a4b --stats

• Connect Claude Code: add the claude-lm function to your ~/.zshrc, then run claude-lm instead of claude

If you’re interested in practical AI building for web apps, developer workflows, and infrastructure, subscribe for future posts. You can also follow my shorter updates on Threads (@george_sl_liu) and Bluesky (@georgesl.bsky.social) or subscribe and follow along.

Buy Me A Coffee

The problem with single-AI code analysis

When Claude Code is the only AI looking at your code, you get one perspective. That is usually fine for routine tasks. But for complex refactors, security-sensitive changes, or architecture decisions, a single perspective has blind spots. I found this the hard way when building Timezone Scheduler – Claude Code missed encoding edge cases that a second AI flagged immediately.

So I used my custom Claude Code skills that let me ask a question once and get parallel answers from two different AI models, with a structured comparison at the end. No copy-pasting between tools, no switching browser tabs. Just type /consult-codex or /consult-zai and both AIs work simultaneously. I’ve been using skills within Claude Code for the past 3 months with great success.

What the skills do

consult-codex pairs a custom code-searcher subagent (from my GitHub starter template repository) with OpenAI’s Codex (GPT-5.4) running in readonly mode. consult-zai pairs the same code-searcher with z.ai’s glm-4.7. Both follow the same pattern:

1. You ask a code question

2. The skill wraps your question with structured output requirements (file paths with line numbers, confidence levels, limitations)

3. Both AIs run in parallel – no serial waiting

4. You get a side-by-side comparison table showing where they agree, where they diverge, and which source provided better evidence

The comparison output includes an agreement level indicator: High Agreement (both reached similar conclusions, higher confidence), Partial Agreement (overlapping findings with unique additions from each), or Disagreement (contradicting findings, manual verification needed).

In practice, I use consult-codex most often for security reviews and large commits. During the Timezone Scheduler build, a Day 3 API commit spanning 837 lines went through dual analysis. Codex caught request limit concerns that Claude alone did not flag, while the code-searcher agent found a caching optimization that Codex overlooked. Neither AI alone would have produced the same result.

Prerequisites

Before setting up these skills, you need three things installed and working.

1. Claude Code

Install Claude Code if you have not already. Use whichever package manager you have:

# npm
npm install -g @anthropic-ai/claude-code

# bun
bun install -g @anthropic-ai/claude-code

Verify it works: claude --version

2. OpenAI Codex CLI (for consult-codex)

Install the Codex CLI globally:

npm install -g @openai/codex

Authenticate with your OpenAI API key or login to your OpenAI ChatGPT subscription:

export OPENAI_API_KEY="your-openai-api-key"

Add that export to your ~/.bashrc or ~/.zshrc so it persists. Verify it works: codex --help

3. Z.AI GLM Coding Plan (for consult-zai)

Z.AI provides access to glm-4.7 through a Claude Code-compatible API. It is a subscription service starting at roughly $3/month for the Lite plan (~120 prompts per 5 hours), with Pro (~600 prompts) and Max (~2,400 prompts) tiers available.

Prerequisites: Node.js 18 or newer and a Z.AI API key from z.ai.

The zai alias is a shell function that sets environment variables and launches Claude Code pointed at z.ai’s API endpoint. Add this to your ~/.bashrc or ~/.zshrc:

zai() {
    export ANTHROPIC_AUTH_TOKEN="your-zai-api-key"
    export ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic"
    export API_TIMEOUT_MS="3000000"
    claude "$@"
}

Reload your shell (source ~/.bashrc) and verify: zai --version should show the Claude Code version, confirming the alias works.

For Windows PowerShell:

function zai {
    $env:ANTHROPIC_AUTH_TOKEN = "your-zai-api-key"
    $env:ANTHROPIC_BASE_URL = "https://api.z.ai/api/anthropic"
    $env:API_TIMEOUT_MS = "3000000"
    claude $args
}

By default, Z.AI maps Claude model names to GLM models automatically: Opus and Sonnet map to glm-4.7, Haiku maps to glm-4.5-air. You do not need to configure model names manually.

If you want to override and pin to a specific model – for example to try newer releases – add the model env vars to the function:

zai() {
    export ANTHROPIC_AUTH_TOKEN="your-zai-api-key"
    export ANTHROPIC_BASE_URL="https://api.z.ai/api/anthropic"
    export API_TIMEOUT_MS="3000000"
    export ANTHROPIC_DEFAULT_OPUS_MODEL="glm-5"
    export ANTHROPIC_DEFAULT_SONNET_MODEL="glm-5-turbo"
    export ANTHROPIC_DEFAULT_HAIKU_MODEL="glm-4.5-air"
    claude "$@"
}

Available GLM models at time of writing: glm-4.7, glm-5, glm-5-turbo, glm-5.1. Leaving the overrides out lets Z.AI update the mapping automatically as new models release, so only pin if you have a specific reason to.

For privacy: Z.AI states it does not store any content you provide or generate. All services are based in Singapore. See their privacy policy for details.

Setting up the skills

Both skills live in your project’s .claude/skills/ directory. You can grab them from my Claude Code starter template, which is publicly available and includes these skills plus additional agents and workflow tooling.

Skill file structure

.claude/
  skills/
    consult-codex/
      SKILL.md
    consult-zai/
      SKILL.md
  agents/
    codex-cli.md
    zai-cli.md
    code-searcher.md

Each skill has a single SKILL.md file that tells Claude Code when and how to use it. The agents directory contains the CLI wrapper definitions that the skills invoke.

How consult-codex works internally

When you run /consult-codex "analyze the auth middleware for security issues", the skill:

1. Wraps your question with structured output requirements – it asks both AIs for summaries, key findings with file:line citations, confidence levels, and acknowledged limitations

2. Writes a temp file ($CLAUDE_PROJECT_DIR/tmp/codex-prompt.txt) to avoid shell quoting issues with complex prompts

3. Launches both AIs in parallel using a single message with multiple tool calls:

4. Codex runs via: bash -i -c 'codex -p readonly exec "$(cat $CLAUDE_PROJECT_DIR/tmp/codex-prompt.txt)" --json 2>&1'

5. code-searcher runs as a custom Claude Code subagent (defined in .claude/agents/code-searcher.md in the starter template)

6. Parses Codex JSON output using jq recipes to extract reasoning, agent messages, and command executions from the JSONL stream

7. Cleans up the temp file, then builds the comparison table

The readonly permission mode for Codex is important – it can read your codebase but cannot modify files, which keeps the consultation safe.

How consult-zai works internally

The consult-zai skill follows the same architecture but calls the z.ai CLI instead:

bash -i -c 'zai -p "$(cat $CLAUDE_PROJECT_DIR/tmp/zai-prompt.txt)" --output-format json --append-system-prompt "You are GLM 4.7 model accessed via z.ai API." 2>&1'

The --append-system-prompt flag tells the model its identity, which helps when the comparison table attributes findings to each source.

The comparison output

Both skills produce a structured comparison with:

• Raw responses from each AI

• A table comparing file paths found, line number specificity, code snippet quality, unique findings, and accuracy

• An agreement level assessment

• A synthesized summary that prioritizes findings corroborated by both agents

• A recommendation on which source was more helpful for that specific query

What I learned

Parallel execution matters. Running both AIs simultaneously instead of sequentially cuts total wait time roughly in half. The skill architecture launches both as concurrent tool calls in a single message.

Structured prompts produce comparable output. Without the enhanced prompt wrapper, each AI returns answers in different formats, making comparison difficult. Requiring file:line citations and confidence levels from both makes the comparison table meaningful.

Agreement level is a useful signal. When both AIs agree, I have higher confidence. When they disagree, that is exactly where I should look manually. Partial agreement – where each found something the other missed – is the most common and most valuable outcome.

The temp file pattern solves a real problem. Shell quoting breaks when your prompt contains quotes, backticks, or special characters. Writing to a temp file and reading with $(cat ...) avoids all of that.

What did not work

The initial version tried to pass prompts directly as shell arguments. That broke constantly with complex code questions containing special characters. The temp file approach was the fix.

Codex CLI can be slow to respond – sometimes over a minute for large codebase scans. The skill sets a 10-minute timeout to handle this, but it means you should not expect instant results on complex queries. You may find that Claude response will complete before the Codex CLI response. In which case you can prompt Claude to take into account Codex CLI’s response.

Z.AI’s token limits on the Lite plan can be constraining for large analysis tasks. If you plan to use consult-zai heavily, the Pro tier is worth considering.

What is next

These skills are part of my Claude Code starter template, which includes the full setup: skills, agents, memory bank system, shell aliases, git worktree launchers, and more. I will cover the complete template in a dedicated post.

If you want to try these skills today, clone the starter template repo and copy the .claude/skills/consult-codex/ and .claude/skills/consult-zai/ directories into your own project. Make sure you also grab the agent definitions from .claude/agents/.

If you’re interested in practical AI building for web apps, developer workflows, and infrastructure, subscribe for future posts. You can also follow my shorter updates on Threads (@george_sl_liu) and Bluesky (@georgesl.bsky.social) or subscribe and follow along.

Buy Me A Coffee

Instead, I built a Claude Code skill that generates images from the terminal and also via Claude Desktop MacOS app (see Claude Cowork example below). One command, any AI model, with transparent backgrounds, reference image editing, prompt engineering patterns, and composite banner generation built in. Every image on my Timezone Scheduler site was created this way without ever leaving my code editor.

This post walks through what the skill does, how it works under the hood, and why building image generation into a developer workflow changes how you think about visual assets.

What problem this solves

If you are a developer building web apps, you probably treat image assets as a separate workflow. You switch to a browser-based AI tool, type a prompt, download the result, maybe resize it with a separate tool, then move it into your project. Each image is a context switch.

The ai-image-creator skill eliminates that. It runs inside Claude Code, so you stay in your terminal the whole time. You describe what you want in natural language, Claude Code enhances your prompt using built-in patterns, picks the right model, and generates the image directly into your project directory. If you need multiple sizes for social media or ad banners, a separate composite mode handles that from a single config file.

The skill supports five AI image models through OpenRouter’s API, all proxied through Cloudflare AI Gateway for monitoring and cost control:

• Gemini 3.1 Flash Image Preview (Google Nano Banana 2)

• FLUX.2 Max

• Riverflow v2 Pro

• Seedream 4.5

• GPT-5 Image

Example image created for my Centmin Mod site’s Nginx page. I asked Claude Code read each local copy of my sites’ pages and generate an image that accurately depicts the content conveyed on each page.

How SKILL.md uses progressive disclosure

Before getting into what the skill does, it is worth explaining how it is structured, because the design pattern is reusable for any complex Claude Code skill.

The SKILL.md file is the entry point. It uses progressive disclosure: only the instructions immediately needed for any given task are loaded into context. The bulk of the knowledge lives in separate reference files that are only read when a specific category is detected.

Here is how it works in practice. SKILL.md contains a routing table:

If the request mentions “product shot” or “product photo” → read prompt-core.md + prompt-categories.md section product_hero

When you ask for a product shot, Claude Code reads only those two files. If you ask for a social media graphic, it reads a different pair. If you ask for a simple image with a basic prompt, it skips the reference files entirely and generates directly.

The alternative would be loading all ~25,000 words of prompt engineering reference into every single request. That would consume a large portion of the context window even for trivial requests like “generate a blue circle.” Progressive disclosure keeps the skill lightweight for simple tasks and deep for complex ones.

The three reference files behind the routing:

• prompt-core.md – foundational rules: narrative prompting, camera/lens specs, lighting setups, text rendering rules, model recommendations

• prompt-categories.md – 11 category formulas with templates and complete example prompts

• prompt-platforms.md – social media ratios, IAB ad sizes, web dimensions, POD specs

A fourth file, composite-reference.md, is only loaded when composite banner mode is detected. The analyze mode has its own analyze-reference.md. The setup guide is in setup-guide.md. None of these are loaded unless the routing logic determines they are needed.

This pattern keeps skill files maintainable too. When I update the product_hero formula, I edit one section of one file. When I add a new model, I update one table in SKILL.md. No sprawling monolith to edit.

How it works

The skill is a Python script (~1,300 lines) that runs through uv (a fast Python runner). The core workflow is three steps:

1. Write or enhance a prompt. For simple requests, pass an inline prompt. For anything complex, write to a temp file. The skill includes prompt engineering reference files covering 11 categories (product hero shots, lifestyle photos, social media graphics, marketing banners, icons, illustrations, food photography, architecture, infographics, print-on-demand designs, and image analysis). Each category has a formula template with camera specs, lighting setups, and composition guidance.

2. Generate the image. The script calls OpenRouter’s API (or Google AI Studio directly), routing through Cloudflare AI Gateway when configured. You control aspect ratio, resolution, model selection, and output path.

3. Post-process if needed. Resize, convert formats, or generate transparent backgrounds using FFmpeg and ImageMagick pipelines.

A typical command looks like this:

uv run python generate-image.py \
  -o "assets/hero-banner.png" \
  -m gemini \
  -a "16:9" \
  -s "2K" \
  -p "A flat-design globe icon with timezone band lines in blue and teal"

This will generate a image at with an accompanying markdown file which contains the actual prompt the ai-image-creator skill used

ls -lAh
total 4696
-rw-r--r--@ 1 george  staff   2.3M  5 Apr 02:12 hero-banner.png
-rw-r--r--@ 1 george  staff   249B  5 Apr 02:12 hero-banner.prompt.md

# Prompt

- **Model:** google/gemini-3.1-flash-image-preview
- **Provider:** openrouter (gateway)
- **Aspect ratio:** 16:9
- **Image size:** 2K
- **Elapsed:** 38.5s

## Prompt Text

A flat-design globe icon with timezone band lines in blue and teal

The prompt engineering layer

This is where most of the value lives. The difference between a mediocre AI image and a professional one is almost entirely in the prompt. The skill includes three reference files totalling ~25,000 words of prompt patterns I refined through hundreds of generations.

Core principle: narrative over keywords. “A warm afternoon in a sunlit cafe with a steaming latte on a marble table” produces dramatically better results than “latte, cafe, warm, marble, afternoon, sunlit.” The reference files teach Claude Code to compose prompts as scene direction, not tag lists.

Camera language triggers photorealism. Including real camera specs (Sony A7R IV, 85mm macro at f/2.8) pushes models toward photorealistic output. The reference files map camera/lens/aperture combinations to specific use cases: 85mm macro for product shots, 100mm macro for food, 24mm tilt-shift for architecture, 35mm for lifestyle scenes.

Quality modifiers are wasted tokens. Words like “4K”, “ultra HD”, “masterpiece” are ignored by modern image models. The reference files focus on describing what you actually want instead of asking for generic quality.

Text rendering has specific rules. AI models can render text in images but need precise instructions. Always wrap text in quotation marks. Describe font style (“bold condensed sans-serif”), not font names (“Bebas Neue”). Specify placement, case, and how text integrates with the design. Following these rules gets 95%+ text accuracy.

Each of the 11 categories has a formula template. Here is the product hero pattern:

Create a [lighting] product photograph of [detailed product description] on/against [surface/background]. Shot with [camera] [lens] at [aperture]. [Lighting description]. [Composition notes]. [Mood/atmosphere].

Claude Code detects the category from your request and loads the matching pattern automatically. If you ask for “a product shot of headphones,” it reads the product_hero template and composes a detailed prompt with camera specs, lighting direction, surface material, and atmosphere. You still control what you want. The skill just makes sure the prompt is structured for the best possible output.

Transparent backgrounds without Photoshop

One feature I use constantly is transparent mode (-t). It generates images with transparent backgrounds using a three-step pipeline:

1. The prompt is augmented to place the subject on a solid green (#00FF00) screen

2. FFmpeg removes the green background and cleans up green fringe from edges

3. ImageMagick auto-crops the transparent padding

Gives you clean PNGs with alpha channels for icons, logos, mascots, sprites, and any asset that needs to sit on different backgrounds. No manual masking, no Photoshop.

uv run python generate-image.py \
  -o "mascot.png" -t \
  -p "A friendly robot mascot character in flat illustration style"

Reference image editing

Multimodal models (Gemini and GPT-5) accept reference images alongside text prompts. This enables editing, style transfer, and guided generation:

# Edit an existing image
uv run python generate-image.py \
  -o "edited.png" -r "photo.png" \
  -p "Make the background white"

# Style transfer with multiple references
uv run python generate-image.py \
  -o "combined.png" -r "style.png" -r "content.png" \
  -p "Apply the style of the first image to the second"

When you provide a reference, the prompt should describe what to change, not the entire scene. The model sees the original and needs edits, not a full new description. This is useful for iterating on designs: generate a base image, then refine it through successive edits without starting over.

Composite banners: consistent branding at every size

The second script in the skill (composite-banners.py) solves a different problem. When you have an existing logo and need it rendered consistently across 15 different banner sizes (social media covers, IAB ad formats, email headers, OG images), AI generation is the wrong tool. Each generation would produce slightly different styling.

Composite mode uses ImageMagick for offline compositing. No API calls, no network required. You define your brand in a JSON config (logo path, brand name, tagline, colors, font preferences) and specify which banner sizes you need. One command generates all of them with pixel-perfect consistency.

# Initialize a config
uv run python composite-banners.py --init

# Generate all banners
uv run python composite-banners.py \
  -c banner-config.json -o ./banners/

The config supports horizontal, horizontal-compact, and centered layouts. It includes presets for IAB standard ad sizes (leaderboard, billboard, medium rectangle, skyscraper), social media covers (Twitter, LinkedIn, Facebook, YouTube), and web assets (hero banners, OG images, email headers, favicons).

The most powerful workflow combines both scripts. Use generate-image.py to AI-create a hero background or textured pattern, then use composite-banners.py to overlay your logo and text onto that background at all standard sizes. Creative AI visuals plus pixel-perfect logo consistency.

Image analysis

The skill also works in reverse. Instead of generating images, you can analyze existing ones using multimodal AI vision:

uv run python generate-image.py \
  --analyze -r "assets/cafe-latte.png" \
  -p "Describe the subject, style, colors, and composition"

This returns a JSON response with the model’s analysis. Useful for generating alt text, comparing before/after versions, or understanding what a competitor’s visual assets are doing well. You can analyze multiple images together for comparison.

Claude Code Opus 4.6 response:

Subject: A first-person POV inside a cozy Parisian cafe — steaming latte with latte art on a marble table, two books (including “The Hidden Life of Trees” with tortoise-shell glasses resting on top), a hand holding an open book, and a large window overlooking a bustling street with trees and passersby.

Style: Digital photograph with a filmic quality — visible grain, shallow depth of field, candid/documentary feel.

Colors: Warm, natural palette — rich browns from wood and the cup, greens from potted plants and outdoor trees, stone-beige masonry, warm gold/yellow from overhead lighting, faded whites from furniture.

Composition: Two-part split (indoor/outdoor) separated by the window frame. Shallow depth of field keeps the foreground sharp (hand, books, cup) while the background softens. Window panes and wood trim act as leading lines toward the center. Asymmetrical but balanced table arrangement.

An example of using ai-image-creator skill —analyze to deconstruct an image into JSON structured data with Google Nano Banana 2 and compare it to Claude Opus 4.6’s own native visual image support. Google Nano Banana 2 picked up more details than Clause Opus 4.6 with my Claude Cowork desktop chat session.

Now that Claude understands the reference images style and composition, I can assign this style a name Substack Comic Style - for this Substack’s creative images that I create for each of my Substack article posts. You’ll need to subscribe to my Substack to find out what article these generated images belong to 😉

Cost tracking

Every generation is logged to a local .ai-image-creator/costs.json file in your project directory. Running --costs shows per-model breakdown: generation count, total tokens, elapsed time, and recent entries. No API keys or credentials are ever stored, just usage metadata.

This matters when you are generating dozens of images for a project. You can see exactly which models you are using, how much each generation costs, and where your budget is going.

The Cloudflare AI Gateway layer

All API calls can be routed through Cloudflare AI Gateway using BYOK (Bring Your Own Key). Your API keys are stored securely in Cloudflare’s dashboard, never sent in request headers from your machine. The gateway provides unified logging across all models and providers, cost monitoring at the account level, rate limiting to prevent accidental overspend, and automatic fallback to direct API calls if the gateway is unavailable.

This is the same gateway pattern I use for other AI integrations. Once you have it set up, every AI API call in every project goes through the same monitoring and cost control layer.

One practical note on credentials: the script supports a .env file at scripts/.env inside the skill folder. This matters for desktop AI tools like Cowork, which run in sandboxed shells that do not inherit your ~/.zshrc exports. Populate the .env with your gateway variables, zip the skill folder, and install it in Cowork -- the script loads credentials automatically using only stdlib (no extra dependencies) and never overwrites keys already set in the environment. Running from a regular terminal with shell exports works the same as before.

Using the skill in other AI coding tools

The skill format follows the open Agent Skills standard, which means it works in more than just Claude Code. The same ai-image-creator/ directory can be transplanted into Codex CLI, Gemini CLI, Kilo Code, and OpenCode with minimal changes. Each tool has its own discovery path:

• Codex CLI – Copy the skill folder to ~/.codex/skills/ for global availability, or to .agents/skills/ at the project root for repo-scoped use.

• Gemini CLI – Place the skill inside ~/.gemini/extensions/<extension-name>/skills/ for a user-level extension, or in .agents/skills/ in your workspace.

• Kilo Code – Drop it into .kilocode/skills/ at the project root, or add the path via skills.paths in your kilo.jsonc config for global availability across projects.

• OpenCode – Global skills go in ~/.config/opencode/skills/. Project-scoped skills go in .opencode/skills/ and take higher priority.

The SKILL.md frontmatter (name, description, allowed-tools, compatibility) is read by all of these tools to discover and describe the skill. The generate-image.py script itself is tool-agnostic: it runs via uv run python, which works the same regardless of which AI coding harness invokes it.

One thing to check across tools: the ${CLAUDE_SKILL_DIR} variable used in SKILL.md to reference script paths. Claude Code expands this automatically. Other tools may not. If a tool does not expand ${CLAUDE_SKILL_DIR}, replace it with an absolute path or a $(dirname "$0")-style resolution in the script invocations.

What I learned building this

Prompt structure matters more than model choice. Switching from a keyword-style prompt to a narrative prompt with camera specs improved output quality more than switching between models. The reference files encode this knowledge so you do not have to rediscover it for each generation.

Transparent backgrounds are harder than they look. My first attempt used simple color replacement, which left green fringe artifacts around edges. The FFmpeg chroma key pipeline with edge cleanup handles this properly, but it took several iterations to get clean results on complex shapes like hair or translucent materials.

Composite mode saved the most time. Generating 15 banner sizes individually with AI would take 15 API calls, 15 different results, and manual checking for brand consistency. Composite mode does it in one local operation with zero API cost and guaranteed consistency.

Cost tracking changes behavior. Once you can see per-generation costs, you start making smarter choices about which model to use for which task. Gemini is cheap and versatile for most web assets. FLUX.2 is better for artistic work but costs more. Having the data makes the trade-off explicit.

What did not work

Film stock prompts are hit or miss. The reference files include film stock aesthetics (“Shot on Kodak Portra 400” for warm skin tones, “Shot on CineStill 800T” for cinematic tungsten tones). Some models respond well to these, others ignore them entirely. I keep them in the reference because when they work, the aesthetic shorthand saves a lot of descriptive text.

Text rendering still fails on long strings. Even with the seven-rule system (quotation marks, font style not name, explicit case, short text), anything beyond 5-6 words becomes unreliable depending on the model. Google Gemini 3.1 Image Flash / Google Nano Banana 2 is much better at text rendering though.

Google AI Studio free tier does not support image generation for Google Gemini 3.1 Image Flash / Google Nano Banana 2. The quota is zero for image generation unless you enable billing on the linked Google Cloud project. I documented this in the setup guide after debugging a cryptic 429 RESOURCE_EXHAUSTED error. OpenRouter’s pay-as-you-go model is simpler for most users.

How to use it

The skill is open source, bundled in my Claude Code starter template repository at .claude/skills/ai-image-creator/. To use it in your own Claude Code projects:

1. Copy the ai-image-creator/ folder to your project’s .claude/skills/ directory

2. Add permission entries to .claude/settings.local.json

3. Set your API keys. There are two ways depending on how you run the skill: Terminal / Claude Code CLI: Export variables in your shell profile (~/.zshrc or ~/.bashrc):

bash

   export AI_IMG_CREATOR_CF_ACCOUNT_ID="your-account-id"
   export AI_IMG_CREATOR_CF_GATEWAY_ID="your-gateway-name"
   export AI_IMG_CREATOR_CF_TOKEN="your-gateway-token"
   # Or for direct OpenRouter access without a gateway:
   export AI_IMG_CREATOR_OPENROUTER_KEY="sk-or-..."

Claude Cowork (desktop app): Cowork runs in a sandboxed shell that does not inherit your shell profile. Create a .env file at scripts/.env inside the skill folder:

   AI_IMG_CREATOR_CF_ACCOUNT_ID=your-account-id
   AI_IMG_CREATOR_CF_GATEWAY_ID=your-gateway-name
   AI_IMG_CREATOR_CF_TOKEN=your-gateway-token

Then zip the entire ai-image-creator/ folder (with the populated .env inside) and install it as a skill in Cowork. The script loads the .env automatically on startup. Shell exports take precedence over the .env if both are present.

Then Ask Claude Code to generate an image.

The setup guide in references/setup-guide.md walks through every step, including Cloudflare AI Gateway configuration and BYOK provider key setup.

An example of ai-image-creator skill in action within Claude Cowork desktop app for MacOS with a Claude Cowork project.

Claude Desktop MacOS app uploaded ai-image-creator skill:

What’s next

I am working on expanding model support as new image generation models land on OpenRouter. I am also exploring batch generation workflows where the skill generates all visual assets for a web project (favicon, OG image, social banners, app icons) from a single brand brief.

If you are building with Claude Code and want to see how custom skills extend what it can do, this is a concrete example.

If you’re interested in practical AI building for web apps, developer workflows, and infrastructure, subscribe for future posts. You can also follow my shorter updates on Threads (@george_sl_liu) and Bluesky (@georgesl.bsky.social) or subscribe and follow along.

Buy Me A Coffee

I do consulting work across Brisbane, the US, and Europe and it can be a challenge to find a time that works for all folks. So I built a tool with Claude Code (Anthropic’s AI coding agent that writes and runs code from natural language instructions) to handle it - with both a graphical user web interface as well as command line / API support. Then, out of curiosity, I gave 11 AI models the same timezone scheduling problem my tool solves. The best model scored 86 out of 100. My tool scored 100.

This is not about AI being bad at timezone math. It is about recognizing when a purpose-built tool outperforms general-purpose AI, and what builders can learn from that gap.

Timezones Scheduler web app interface at https://timezones.centminmod.com.

Same prompt, 11 models, one rubric

I gave every model the same prompt for March 23, 2026:

“Find the most optimal meeting time that works across Brisbane, New York, and London, ideally falling within business hours for all three cities, or as close to business hours as possible.”

Here is the constraint that makes this hard: Brisbane is 14 hours ahead of New York. When it is 9 AM Monday in New York, it is 11 PM Monday in Brisbane. Getting all three cities into standard business hours simultaneously is mathematically impossible. The best any solution can do is land two cities in core business hours and one outside, which I score as 6 out of a possible 9 points (more on the scoring system below).

I scored every response across five categories totalling 100 points: time optimization (25), DST accuracy (20), timezone math consistency (15), analysis quality (20), and practical value (20).

Only 2 out of 11 models found the optimal time slot.

Full benchmark with every model’s raw response: github.com/centminmod/timezone-scheduler

Why AI struggles with this

Three patterns stood out across the 11 models I tested:

Models contradict their own analysis. MiniMax M2.7 recommended 5:00 AM New York, then labeled it “too early” in the same response. Gemini 3.1 Pro found the optimal slot in its ranked list, then recommended a different, worse time in its summary paragraph. When models reason through trade-offs, they sometimes lose track of their own conclusions. You have probably seen this yourself: an AI gives you a great answer, then undermines it two paragraphs later.

Models do not check every option. My tool evaluates all 24 hours across every timezone combination. Models pick a “reasonable” slot based on reasoning, which usually means they settle for a good-enough answer instead of finding the best one. Only 2 out of 11 models found the optimal slot.

Daylight saving transitions are a trap. March 23, 2026 falls six days before London switches from GMT to British Summer Time. One model, ZAI GLM-5, assumed London was already in BST. That one-hour error cascaded through every time it calculated, dropping its score to 53. If you have ever shown up an hour early or late to a meeting after a clock change, you know the feeling. AI models make the same mistake.

What the tool does differently

The Timezone Scheduler takes a computational approach. It evaluates every hour of the day across all participant timezones. Business hours (9 AM to 5 PM) score 3 points per participant. Extended hours (7-9 AM or 5-9 PM) score 1 point. Off hours score zero.

When multiple slots tie on business-hours score, a comfort tie-breaker kicks in. The idea is simple: 3 AM is the worst possible meeting time for anyone. The tool measures how far the worst-off participant is from 3 AM. The farther from 3 AM, the better. This is why the tool picks 11 PM Brisbane over midnight Brisbane. Both score 6/9, but 11 PM is farther from “miserable o’clock” and therefore a more civil hour.

The tool evaluates every possible slot deterministically. It does not reason about trade-offs and drift toward a plausible answer. It scores them all and returns the best one.

How it is built

If you are not a developer, here is the short version: the tool runs entirely in the cloud on Cloudflare’s edge network, loads fast anywhere in the world, and uses the browser’s own built-in timezone data instead of relying on third-party libraries. The technical details follow for those who want them.

The architecture is deliberately simple. A Cloudflare Worker (a serverless function that runs at the network edge, close to users) handles all API logic in TypeScript. The frontend is vanilla JavaScript with no framework, styled with Tailwind CSS v4, and bundled by Vite. No React, no Vue, no Angular. For a tool this focused, a framework would add complexity without adding value.

Browser (Vanilla JS)              Cloudflare Worker (TypeScript)
--------------------              --------------------------------
app.js      (orchestrator)        GET      /api/timezone-data
timezone-data.js (Intl utils)     GET      /api/search
map.js      (SVG world map)       GET|POST /schedule/api  (schedule|suggest|search)
scheduler.js (meeting grid)       GET      /schedule/api/schema  (OpenAPI 3.1)
styles.css  (Tailwind v4)         GET|POST /schedule/api/mcp  (MCP server)

Zero external timezone libraries. The browser’s native Intl.DateTimeFormat API handles everything: offset calculations, daylight saving transitions, locale-aware formatting. This matters because the timezone data comes from the same database your operating system uses, so it is always up to date without needing to ship or maintain a separate library.

The meeting scheduler displays a 24-hour comparison grid, color-coded so you can see at a glance which hours are business hours, which are early/late but workable, and which are off hours. You can share a meeting link that preserves the full state (cities, date, time), generate a QR code, or export directly to Google Calendar, Outlook, or any calendar app. It also works offline as a PWA (Progressive Web App, meaning you can install it on your phone like a native app). Deployment is on Cloudflare Workers with automatic deploys through GitHub Actions.

Seven days, 117 commits

The Timezone Scheduler went from zero to production in seven days. The git history tells the real story of AI-assisted development, not a clean arc from idea to launch, but a messy, iterative process where features, fixes, and rethinks pile up fast.

Day 1 (March 21): From nothing to live, 19 commits. By end of day, the tool was deployed on a custom domain with a working world map, city search, 24-hour scheduler grid, light/dark theme, and responsive layout. A functional timezone tool, built and shipped in one day.

Day 2 (March 22): Making it shareable, 11 commits. I realized I needed to let people send each other meeting links, so shareable URLs landed. Then scope grew: support for comparing up to 6 cities at once, with an interface that lets you add and remove cities as tags. An accessibility audit made the tool usable for screen readers.

Day 3 (March 23): Teaching AI to use the tool, 15 commits. This was the pivotal day. One commit added 837 lines of code that turned the scheduler into an API that AI assistants can call directly (more on this in “The deeper angle” below). The same day, the comfort tie-breaker landed after the benchmark revealed the tool was picking midnight over 11 PM. I also spent several commits refining the instructions that teach AI models how to call the API correctly on their first try.

Day 4 (March 24): Locking it down, 40 commits. The single busiest day. I added code quality tools (automated formatting, pre-commit checks), a CI/CD pipeline (code gets tested and deployed automatically on every change), and automated dependency updates. Then I ran two rounds of security audits (OWASP methodology), finding and fixing injection vulnerabilities, rate limit bypasses, and cross-site scripting risks. I also built a demo video pipeline using Remotion (a React-based video framework) with custom Claude Code skills to guide the animations and sequencing.

Days 5-7 (March 25-27): Real-world bugs, 30 commits. Three more security audit rounds, each catching issues the previous round missed. Offline support so the tool works without an internet connection. An ai-image-creator skill for generating all project images through AI. An automated test suite of 38 tests against the live site. And two bugs that only surfaced when real users tried the tool: a share link that lost its data on load, and a single-character typo that showed wrong times for anyone outside my timezone.

Every one of those 117 commits was a conversation with Claude Code.

How Claude Code built it

The whole project was built through back-and-forth sessions with Claude Code. I described what I wanted in plain English, Claude Code wrote the code, and we iterated together. I used a “memory bank” system (a set of project files that Claude Code reads at the start of each session) to keep context persistent, so it remembered previous decisions instead of starting fresh every time.

The irony is not lost on me. The tool that scored 100/100 against 11 AI models was itself written by an AI. But Claude Code was not reasoning about timezone math the way those models were. It was writing deterministic code to evaluate every possibility. That is a fundamentally different task. When I asked Claude Code to implement the scoring algorithm, it produced code that loops through 24 hours, calculates each participant’s local time using the Intl API, and sums the scores. No reasoning shortcuts, no “this seems reasonable.” Just exhaustive evaluation.

The Day 3 API commit is the clearest example of what this workflow looks like at full speed. That single session produced the scheduling API with three actions (schedule, suggest, search), an OpenAPI spec (a machine-readable description of the API), an MCP server (Model Context Protocol, a standard that lets AI tools connect to external services), and an llms.txt file (plain-text instructions that teach AI models how to use the API). All 837 lines. Before implementation, I used my consult-codex skill to send Claude Code’s plan to OpenAI Codex CLI (running GPT-5.4) for a second opinion. The dual-AI review caught things neither would have caught alone. The resulting security hardening included encoding fixes for non-English city names, caching that cut redundant timezone calculations from ~3,500 to ~50, request size limits, and daylight saving gap detection.

Three parts of my Claude Code setup made this kind of velocity possible:

• Claude Code auto memory – Claude Code has a built-in memory system that accumulates knowledge across sessions automatically. As I worked, it saved notes for itself: build commands, debugging insights, architecture patterns, code style preferences. On top of that, my CLAUDE.md memory bank files give it explicit project instructions. Between the two, each session starts with full contextual awareness of what has been built and decided so far.

• Context7 MCP – Connects Claude Code to live library documentation. Instead of guessing how a browser API works based on its training data, Claude Code reads the current official docs.

• Cloudflare Docs MCP – Does the same for Cloudflare’s platform, pulling deployment rules and API behavior from Cloudflare’s own documentation rather than inferring.

Beyond these integrations, I built project-specific Claude Code skills that extended what Claude Code could do on its own. Each was built with Claude Code and stored in the repo’s .claude/skills/ directory, so any future session picks them up automatically:

• consult-codex – Sends Claude Code’s plan to a second AI (OpenAI’s Codex) for a second opinion before implementation starts. Where Codex flagged something differently, I had a real trade-off to evaluate rather than a single AI perspective to accept or reject. Read about my Claude Code /consult-codex and /consult-zai skills.

• ai-image-creator – Generates web app images and site graphics through multiple AI models (Gemini, FLUX.2, SeedDream, GPT-5 Image) via OpenRouter’s API, proxied through Cloudflare AI Gateway for monitoring and cost control. Supports transparent backgrounds, reference image editing, and per-project cost tracking. Every image on the site was generated this way. Read about my Claude Code ai-image-creator skill.

• create-demo-video and remotion-best-practices – Produces polished MP4 demo videos using Remotion, a React-based video framework. Automated Playwright screen captures are composed into desktop and mobile formats with transitions and animated cursors. You can see the results at timezones.centminmod.com/demo-videos.

• timezone-tests – Runs 29 CLI tests plus 9 Chrome DevTools visual tests against the live site, covering every API endpoint, security header, share link hydration, and PWA asset. This is the skill that caught the share link and sign error bugs described below.

• Claude Code starter template – The consult-codex skill and the memory bank system are part of my reusable Claude Code starter template, which I have shared publicly at github.com/centminmod/my-claude-code-setup. I will cover that setup in detail in a future post.

What did not work

The tie-breaker gap. The first version scored 98/100, not 100. When two slots tied on business hours, the tool picked midnight Brisbane over 11 PM Brisbane. Both score 6/9, but midnight is objectively worse. Two models (Gemini 3.1 Pro and Grok 4.1 Fast) had independently chosen 11 PM. I added a comfort scoring layer that measures how far the worst-off participant is from 3 AM on a circular scale. The tool improved because I benchmarked it against real alternatives and found a case it was not handling well.

The invisible sign error. Six days after launch, I found that meeting times displayed wrong when your browser timezone differed from the selected reference city. The fix was a single character: - to + in the offset correction. The bug was invisible during all my testing because my browser was set to Brisbane and I was testing with Brisbane as the reference. A one-character mistake that only surfaced when a real user in a different timezone tried it.

Share link loading order. When you open a shared meeting link, the tool needs to restore the saved cities and the saved time. The bug: the code restored the time first, then added the cities. But adding a city resets the page, which wiped the time that was just restored. The fix was doing it in the right order: cities first, then time. Obvious in retrospect, but it took tracing through the exact sequence of page updates to find.

Five rounds of security audits. I used Claude Code to run structured security audits (following OWASP methodology, the industry-standard checklist for web application security) across Days 4-7. Each round found issues the previous round missed. Round 1 caught ways an attacker could inject malicious input. Round 2 found a way to bypass rate limits on the API. Round 3 caught a timing issue in how the server tracked requests. Round 4 found that the Round 3 fix had accidentally broken how share links handle minutes. Round 5 hardened error messages and filtered special characters in calendar exports. The pattern was clear: each fix could introduce a new edge case, and no single audit pass was sufficient.

None of these bugs were caught during the initial Claude Code build sessions. They surfaced through adversarial testing, real-world usage in different timezones, and deliberate security audits. AI-assisted development is fast, but the testing and hardening phase is where quality actually gets built in.

The deeper angle: building tools that AI can call

Here is what makes this more than a scheduling story. The Timezone Scheduler is not just for humans. The API is designed so AI assistants can use it too:

• /llms.txt – A plain-text file that teaches AI models how to call the API on their first attempt. It front-loads parameter names (from/to, not source/destination), a GET URL template with placeholders, a city reference table with 33 entries, and GET vs POST syntax differences. I refined this across four commits after testing how models actually called the API. The biggest improvement was putting parameter names and the URL template above the examples, because models were copying example city names instead of substituting user input.

• /schedule/api/schema – An OpenAPI 3.1 spec that any tool-using AI can consume programmatically. It describes the three API actions (schedule, suggest, search), request/response shapes, and scoring fields. Tools like Copilot and Gemini CLI can auto-generate client calls from this spec without reading prose documentation.

• /schedule/api/mcp – A real MCP (Model Context Protocol) streamable-HTTP server implementing JSON-RPC 2.0 with zero external dependencies. It supports initialize, tools/list, tools/call, and ping. Claude Code, Codex, Gemini CLI, OpenCode, and Kilo CLI can all register it as a tool server. The llms.txt file includes ready-to-paste MCP config blocks for each of these AI coding tools.

When a user asks any of these tools “find the best meeting time for Brisbane, New York, and London,” the AI handles natural language understanding and the Timezone Scheduler handles the precision. The AI gets 100/100 because it calls the API instead of doing the computation itself.

This pattern applies beyond timezone scheduling. Tax calculations where rules vary by jurisdiction. Unit conversions where precision matters. Compliance checks where the criteria are enumerable. Any domain where “good enough reasoning” is not actually good enough is a candidate for a purpose-built tool that AI can call.

What I learned

1. Benchmark before you trust. AI models sound confident even when they pick suboptimal answers. Test them on tasks with verifiable correct answers. You might be surprised how often “good enough” reasoning misses the best solution.

2. Build tools for the precision layer. If your domain has clear scoring criteria and the solution space is enumerable, a dedicated algorithm will outperform general-purpose AI consistently. Keep the tool focused and let AI handle everything around it.

3. Make your tools AI-consumable. The biggest leverage is not choosing between AI and tools. It is building tools that AI can call. Add llms.txt, OpenAPI, or MCP support and your tool becomes part of every AI workflow that touches your domain.

What’s next

I am planning a follow-up that goes deeper on how the Timezone Scheduler was actually built: the architecture decisions, the Claude Code workflow, and the specific parts where the back-and-forth with AI made a real difference. If that is useful to you, subscribe so you do not miss it.

The tool is free at timezones.centminmod.com. The full benchmark is at github.com/centminmod/timezone-scheduler.

If you’re interested in practical AI building for web apps, developer workflows, and infrastructure, subscribe for future posts. You can also follow my shorter updates on Threads (@george_sl_liu) and Bluesky (@georgesl.bsky.social) or subscribe and follow along.

Buy Me A Coffee

That is why I started this Substack.

I want to document how I’m using AI to build useful web apps, improve developer workflows, and explore better tools and systems. Here I’ll share what I’m building, the workflows and tools I use, and an honest look at what works and what doesn’t.

I want to show more than finished results. I want to share the process too.

What I tried. What changed. What worked. What didn’t.

Less hype, more implementation.

I started my AI journey like most folks with the launch of OpenAI ChatGPT website - almost immediate jumping on ChatGPT Plus $20/month paid subscription when it came out. Then it was Claude Pro $20/month and Gemini AI Pro $20/month subscriptions.

Most of it was for coding first. I have a lot of ideas and devops tooling that was on the back burner and AI chat helped out. AI helped fill in knowledge gaps I had and gave me deeper insights as I asked more questions. I would always get each respectively LLM model response to evaluate each others’ responses to improve the final product. Unfortunately, running into token context limits back then for both input tokens and output tokens. LLM models around then were below 128K tokens with 4-8K max output tokens. This multi-AI consultation process would eventually lead me to creating my Claude Code /consult-codex and /consult-zai Skills.

I was still using my trusty Sublime Text editor I tried Visual Studio Code before, but never really took to it. But each time I tried Visual Studio Code, I would eventually return back to the Sublime Text editor as I was used to key mappings and shortcuts.

It would probably was several months until January-February 2024, that I decide to try Cline in Visual Studio Code. I paired Cline with OpenRouters API burning up tokens. If I recall correctly, the model most use on OpenRouters at that time, was the Google Gemini models. This was a game changer, as I no longer had to be stuck with the context limits within the web chat AI interface and that there was more context information that could provide the AI models.

From March 2024 to June 2025, I was using the Claude Pro $20/month plan. Up until this point, I was only using the Claude Plan within the web chat interface. Claude Code had been launched in February 2025, but I still haven’t used it yet.

One of my earlier AI coded projects using Cline and Gemini 2.0 models was my OpenRouter API python script, or-cli.py back in February 2025 when I discovered the wonderful OpenRouter AI API provided a lot of free LLM model usage. I took advantage of that Google Gemini LLM model usage a lot and dabbled for the first time into Cloudflare AI Gateways.

That changed in March 2025 when I decided to use Claude Code within Visual Studio Code. This would be the game-changing moment, as I decided to focus and go all in on learning Claude Code. My Claude Code usage grew, and by July 2025 I had upgraded to the Claude max $100/month plan and I have been on this plan ever since (~10 months).

It was around this time I created my Claude Code starter template GitHub repository to document and share my own Claude Code journey with others which includes custom CLAUDE.md memory bank system modeled after Cline’s memory bank system which I had gotten use to. Then I added my Claude Code skills, agents/commands and knowledge to the repo which has grown to nearly 2.2K GitHub stars and consistently averages 1,500 to 3,000 visitors per week!

I had gotten used to Visual Studio Code and no longer use the Sublime Text editor. This meant that I also got to play with other Visual Studio Code AI extensions, including Kilo Code, OpenAI Codex CLI, Google Gemini CLI, and OpenCode. Kilo Code clearly is one of my top favourites behind Claude Code and Codex CLI.

Also as an open source maintainer of my Centmin Mod LEMP stack that is GPLv3 licensed, I also got free access to GitHub Copilot Pro plan, which normally costs $10/month.

So right now my AI is spend includes:

• Claude AI Max US$100/month + 10% Australian GST

• OpenAI ChatGPT Plus US$20/month + 10% Australian GST

• Google Gemini AI Pro US$20 month + 10% Australian GST

• GitHub CoPilot Pro US$10/month + 10% Australian GST currently free

• ZAI GLM Coding plan US$129/year (64% discount) + 10% Australian GST

• t3.chat US$8/month + 10% Australian GST

Currently, my AI coding setup just migrated from multiple iTerm2/tmux terminals + Visual Studio Code to using warp.dev just as a multiple window/tab terminal without the AI bells and whistles. I also have Claude and multi-AI CLI VSC dev containers using Debian Docker images that I documented at https://claude-devcontainers.centminmod.com.

Just a few days ago revisited voice dictation as well, currently using Wispr Flow. Folks can get a free month of Wispr Flow Pro using my invitation link.

I hope this gives readers, a bit of background of my AI journey to date.

The next post is a concrete example: I tested 11 AI models on timezone scheduling, none of them got it right, so I built something that did.

If you’re interested in practical AI building for web apps, developer workflows, and infrastructure, subscribe for future posts. You can also follow my shorter updates on Threads (@george_sl_liu) and Bluesky (@georgesl.bsky.social) or subscribe and follow along.

Buy Me A Coffee