<p>Playwright MCP gives Claude Code a real browser to drive. Coding agents are kind of
awful at doing the right thing unless they can verify their work. If you want to do any
front-end work and not be the human in the loop every step along the way, it's gotta be
able to operate Chromium and review the photos. Opus 4.6 is multi modal and any later
models will just be better, so it can consume the photos itself.</p>
<h1 id="setup">Setup</h1>
<pre><code class="language-bash">claude mcp add playwright -- npx @playwright/mcp@latest --browser chromium
</code></pre>
<p>Or add it to <code>.mcp.json</code> at the project root to share it with the team:</p>
<pre><code class="language-json">{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@playwright/mcp@latest", "--browser", "chromium"]
    }
  }
}
</code></pre>
<p>Restart Claude Code. Run <code>/mcp</code> to confirm it's listed. If you've got a session
already, tell it to store its memory first and to load it back after, works well.</p>
<h1 id="what-playwright-does">What Playwright Does</h1>
<p>At work we migrated from Selenium/WebDriver to this to address flakiness long before
the MCP was out, but at this point my interest in playwright is more about the AI
integration.</p>
<p>Playwright MCP exposes the browser as individual tools Claude can call. This post demos
the main ones, with examples against my dev blog server at <code>http://localhost:3000</code>.</p>
<p>I'm pretty sure I'll be able to post agents at this post even to tell it how I want
them to work, and ask them to write a claude.md about it.</p>
<h2 id="browser_navigate">browser_navigate</h2>
<pre><code>browser_navigate: { url: "http://localhost:3000" }
</code></pre>
<p>Loads a URL. Returns the final URL (catches redirects) and a console
error/warning count alongside the snapshot.</p>
<h2 id="browser_snapshot">browser_snapshot</h2>
<pre><code>browser_snapshot: {}
</code></pre>
<p>Returns an accessibility tree of the current page. This is the main tool for
reading page state: what's visible, what's interactive, what the structure is.
Faster and more structured than HTML, and the <code>ref</code> values it returns are what
<code>browser_click</code> and <code>browser_type</code> use to target elements.</p>
<h2 id="browser_take_screenshot">browser_take_screenshot</h2>
<pre><code>browser_take_screenshot: {}
</code></pre>
<p>Returns a PNG of the current viewport. This is the tool Claude uses to judge
look and feel. It's multimodal, so it actually reads the image and can catch
layout problems, broken images, or rendering bugs that don't show up in the
accessibility tree. It can't extract <code>ref</code> values from a screenshot though, so
use <code>browser_snapshot</code> when you need to drive further actions.</p>
<h2 id="browser_click">browser_click</h2>
<pre><code>browser_click: { element: "Posts", ref: "..." }
</code></pre>
<p>Clicks by visible label or element reference. Drives navigation and interactive
components.</p>
<h2 id="browser_type">browser_type</h2>
<pre><code>browser_type: { element: "search input", ref: "...", text: "Playwright" }
</code></pre>
<p>Types into an input. The <code>ref</code> comes from <code>browser_snapshot</code>.</p>
<h2 id="browser_evaluate">browser_evaluate</h2>
<pre><code>browser_evaluate: { function: "() => document.title" }
</code></pre>
<p>Runs JavaScript in the page context. For reading state that isn't in the DOM.</p>
<h2 id="browser_wait_for">browser_wait_for</h2>
<pre><code>browser_wait_for: { text: "Playwright MCP" }
browser_wait_for: { textGone: "Loading..." }
browser_wait_for: { time: 2 }
</code></pre>
<p>Three modes: wait for text to appear, wait for text to disappear, or sleep for
N seconds. No explicit timeout parameter. It uses Playwright's default (30s).
Needed for anything that renders async.</p>
<h2 id="browser_console_messages">browser_console_messages</h2>
<pre><code>browser_console_messages: {}
browser_console_messages: { level: "error" }
</code></pre>
<p>Returns the full console output: message text, level, and source location.
The <code>level</code> filter works like log levels: <code>error</code> gives you errors only, <code>info</code>
gives you everything. The navigate and snapshot tools show a count
(<code>1 errors, 0 warnings</code>), but this is where you get the actual content.</p>
<p>Claude can read and interpret it. Errors include full stack traces and, for
things like React hydration mismatches, the actual HTML diff showing which
component diverged between server and client. Ask Claude to look at the console
and it'll summarize the errors and suggest fixes rather than dumping the raw
text at you.</p>
<p>First thing to check when something looks wrong but the DOM appears fine.</p>
<p>Also worth having in every test suite: a test that loads each key page and
asserts no console errors. It catches a lot of regressions for free.</p>
<pre><code class="language-typescript">test('no console errors on homepage', async ({ page }) => {
  const errors: string[] = [];
  page.on('console', msg => {
    if (msg.type() === 'error') errors.push(msg.text());
  });
  await page.goto('/');
  expect(errors).toHaveLength(0);
});
</code></pre>
<h2 id="browser_network_requests">browser_network_requests</h2>
<pre><code>browser_network_requests: {}
browser_network_requests: { includeStatic: true }
</code></pre>
<p>The network log since the last navigation. Returns method, URL, and status code
for each request. Good for catching 404s on assets or confirming a request
fired. Excludes static resources by default. Pass <code>includeStatic: true</code> to see
everything.</p>
<p>No timing data. If you need to assert on response duration, use Playwright's
<code>page.on('response', ...)</code> in a test instead:</p>
<pre><code class="language-typescript">test('API calls complete within 500ms', async ({ page }) => {
  const timings: number[] = [];
  page.on('response', async response => {
    if (response.url().includes('/api/')) {
      const timing = response.timing();
      timings.push(timing.responseEnd - timing.requestStart);
    }
  });
  await page.goto('/');
  expect(Math.max(...timings)).toBeLessThan(500);
});
</code></pre>
<p><code>page.on('response', ...)</code> fires for every network response. Filter by URL
pattern to target whatever you care about: API calls, a specific domain,
a file type. Same pattern works for asserting no 404s:</p>
<pre><code class="language-typescript">test('no broken asset requests', async ({ page }) => {
  const failures: string[] = [];
  page.on('response', response => {
    if (response.status() >= 400) failures.push(`${response.status()} ${response.url()}`);
  });
  await page.goto('/');
  expect(failures).toHaveLength(0);
});
</code></pre>
<h2 id="browser_resize">browser_resize</h2>
<pre><code>browser_resize: { width: 375, height: 812 }
</code></pre>
<p>Resizes the viewport. Triggers CSS media queries based on width, so layout
reflows and responsive breakpoints work as expected. Good for a quick visual
check. Pair it with <code>browser_take_screenshot</code> to see what changed.</p>
<p>It doesn't change the user agent, device pixel ratio, or pointer type. That
means UA-sniffing code still thinks it's a desktop browser, <code>srcset</code> serves
desktop-resolution images, and <code>hover: none</code> / <code>pointer: coarse</code> media queries
don't fire. For proper mobile regression coverage, use Playwright's device
emulation in the test config instead:</p>
<pre><code class="language-typescript">import { devices } from '@playwright/test';

// playwright.config.ts
export default defineConfig({
  projects: [
    { name: 'desktop', use: { viewport: { width: 1280, height: 720 } } },
    { name: 'mobile',  use: { ...devices['iPhone 13'] } },
  ],
});
</code></pre>
<p><code>devices['iPhone 13']</code> sets viewport, user agent, device scale factor, and
touch support together. Your tests run against both profiles automatically.</p>
<hr>
<h1 id="gherkin-specs-as-source-of-truth">Gherkin Specs as Source of Truth</h1>
<p>AI-generated test code has a maintenance problem. The agent writes tests, they
drift from what the UI actually does, someone edits them directly, and now you
have no reliable source of truth.</p>
<p>What I'm experimenting with here is to keep specs in Gherkin, generate tests from
them, and treat the generated code as a build artifact. Claude rewrites the tests from
spec whenever they go stale. Nobody edits the generated files.</p>
<pre><code>tests/
  spec/
    index.feature
    post.feature
    navigation.feature
  playwright/
    index.spec.ts      # generated, do not edit
    post.spec.ts       # generated, do not edit
    navigation.spec.ts # generated, do not edit
  playwright.config.ts
</code></pre>
<p>The actual specs for this blog live in
<a href="https://github.com/kylep/multi/tree/main/apps/blog/blog/tests/spec/"><code>tests/spec/</code></a>.
Here's the index one:</p>
<pre><code class="language-gherkin"># tests/spec/index.feature

Feature: Blog index page

  Scenario: Page loads with post list
    Given I navigate to the blog homepage
    Then I see a list of posts
    And each post has a title, date, and summary

  Scenario: Posts link to their detail page
    Given I navigate to the blog homepage
    When I click the first post title
    Then I am on a post detail page
    And the post has a title and content

  Scenario: Pagination controls are present
    Given I navigate to the blog homepage
    Then I see pagination controls
</code></pre>
<p>The instruction to Claude is: read the <code>.feature</code> file, generate a matching
<code>spec.ts</code>. If something breaks, fix the spec first, then regenerate. The feature
file is what documents how the UI is supposed to behave.</p>
<p>A <code>CLAUDE.md</code> in <code>tests/</code> gives Claude guidance when generating tests, things
like keeping the suite under a minute, no sleeps, one assertion per scenario.
If you're using <a href="/ruler-cross-tool-ai-rules.html">Ruler</a> to share rules across tools,
put that content in <code>tests/.ruler/</code> instead and let Ruler generate the
<code>CLAUDE.md</code> alongside your <code>AGENTS.md</code>.</p>
<h1 id="claude-verifying-its-own-changes">Claude Verifying Its Own Changes</h1>
<p>This is the part I wanted to try. Claude makes a change, then uses the MCP
browser to check whether it worked, before handing back.</p>
<pre class="mermaid">
graph TD
    A[Claude makes a change] --> B[Build blog]
    B --> C[Start dev server]
    C --> D[Navigate to affected page]
    D --> E[Screenshot + read DOM]
    E --> F{Looks right?}
    F -->|No| H[Investigate and fix]
    H --> B
    F -->|Yes| I{Add a test?}
    I -->|No| G[Done]
    I -->|Yes| J[Write Gherkin scenario]
    J --> K[Generate Playwright spec]
    K --> L[Run test to verify]
    L --> G
</pre>
<p>It's nondeterministic. That's the strength and the problem. Claude
isn't following a checklist. It navigates to what it changed, reads what's
there, and decides whether it matches intent. That catches a class of dumb
mistakes a checklist wouldn't, but it also means "looks right" depends on the
agent's judgment, which isn't always reliable.</p>
<p>The multimodal part matters here. When Claude calls <code>browser_take_screenshot</code>,
it doesn't get back an opaque file path. It sees the rendered page. It can tell
if an image failed to load, if a layout broke, if text is overlapping. That's
more than a DOM inspection gives you. It's also not a substitute for explicit
assertions, because "looks right" is still a judgment call.</p>
<pre class="mermaid">
graph TD
    A[Claude ready to commit] --> B[Start dev server]
    B --> C[Run Playwright tests]
    C --> D{Tests pass?}
    D -->|Yes| E[Commit]
    D -->|No| F[Investigate and fix]
    F --> C
</pre>
<p>This part is deterministic as reasonably quick in headless mode.
Screenshots are for the stuff that's hard to assert: visual regressions, style
issues, anything where you'd want a human to glance at it.</p>
<h2 id="playwright-config-for-the-blog">Playwright Config for the Blog</h2>
<pre><code class="language-bash">cd apps/blog
npm init playwright@latest
</code></pre>
<pre><code class="language-typescript">// playwright.config.ts
import { defineConfig } from '@playwright/test';

export default defineConfig({
  testDir: './tests/playwright',
  use: {
    baseURL: 'http://localhost:3000',
  },
  webServer: {
    command: 'npm run dev',
    url: 'http://localhost:3000',
    reuseExistingServer: true,
  },
});
</code></pre>
<p>The generated specs live in
<a href="https://github.com/kylep/multi/tree/main/apps/blog/blog/tests/playwright/"><code>tests/playwright/</code></a>.
Run them with:</p>
<pre><code class="language-bash">cd apps/blog/blog
npx playwright test
</code></pre>
<p>Claude gets pass/fail output with assertion details. Unambiguous, scriptable,
no judgment required.</p>
<p>Note: <code>npx playwright test</code> runs headless by default. No browser window appears.
Pass <code>--headed</code> to watch it run, or set <code>headless: false</code> in the config.</p>
<h1 id="where-this-is-going-agent-teams">Where This Is Going: Agent Teams</h1>
<p>Claude Code has a multi-agent feature in preview. The setup that makes sense
here is a builder agent making changes and a separate verifier agent running
tests and reporting back. They work in parallel. Failures come back as tasks.</p>
<p>Not wired up yet. But the spec files, generated tests, and MCP config are what
make it possible to hand verification to a different agent without losing the
context of what the tests mean. I ended up wiring this into a <a href="/agent-org-chart.html">QA subagent in
the agent team</a>.</p>


<p>I use Cursor and Claude Code, sometimes Codex, and I'm about to try OpenCode.
Each tool has its own rules format, and I've been maintaining them separately.
<a href="https://github.com/intellectronica/ruler">Ruler</a> generates each tool's native
config from a single source. Worth setting up.</p>
<h1 id="tool-agnosticism-with-common-rules">Tool agnosticism with common rules</h1>
<p>I'm trying to keep up. There are too many tools. I don't want to migrate things around.
We're using this at work too, since different devs use different tools. Here's how I
set up Ruler to consolidate my Cursor and Claude rules together.</p>
<p>I had this rule in Cursor:</p>
<pre><code class="language-markdown"># Monorepo rules

This git repo is a monorepo. It contains multiple sub-projects.
Do not look for context or cross-reference calls between sub-projects.
Each directory within apps/ and games/ is a sub-project. They shouldn't
share code.
</code></pre>
<p>Claude Code has CLAUDE.md files scattered through the tree:</p>
<table>
<thead>
<tr>
<th>File</th>
<th>Contents</th>
</tr>
</thead>
<tbody>
<tr>
<td><code>CLAUDE.md</code> (root)</td>
<td>Branching: never commit to main, always PR</td>
</tr>
<tr>
<td><code>apps/games/sillyapp/CLAUDE.md</code></td>
<td>iOS build and test commands, simulator lifecycle</td>
</tr>
<tr>
<td><code>apps/blog/.../posts/CLAUDE.md</code></td>
<td>Blog writing voice, formatting rules, structure</td>
</tr>
<tr>
<td><code>apps/games/kid-bot-battle-sim/features/CLAUDE.md</code></td>
<td>Interface details for that feature set</td>
</tr>
</tbody>
</table>
<h1 id="ruler-setup">Ruler Setup</h1>
<pre><code class="language-bash">npm install -g @intellectronica/ruler
</code></pre>
<p>Initialize at the repo root:</p>
<pre><code class="language-bash">ruler init
</code></pre>
<p>This creates a <code>.ruler/</code> directory and a <code>ruler.toml</code> config. Drop your
instructions as Markdown files inside <code>.ruler/</code>, then:</p>
<pre><code class="language-bash">ruler apply
</code></pre>
<h2 id="what-happens-when-you-run-it">What happens when you run it</h2>
<p>Claude Code gets <code>CLAUDE.md</code>. Everything else (Cursor, OpenCode, Codex,
Copilot, 30+ others) gets <code>AGENTS.md</code>. Generated files go into <code>.gitignore</code>
automatically, so only the <code>.ruler/</code> source is committed.</p>
<p>Ruler supports nested directories. A <code>.ruler/</code> at the repo root applies
globally. A <code>.ruler/</code> inside a sub-project applies when an agent is working
there. That matches how Claude Code already loads CLAUDE.md files walking up
the directory tree.</p>
<pre class="mermaid">
graph TD
    A[".ruler/ at repo root\nbranching, monorepo"] --> B[Claude Code]
    A --> C[Everyone Else\nCursor, OpenCode, Codex...]
    E[".ruler/ in sillyapp/\nbuild, test"] --> B
    E --> C
    F[".ruler/ in posts/\nblog style"] --> B
    F --> C
    B --> G[CLAUDE.md]
    C --> H[AGENTS.md]
</pre>
<p>You can symlink ~/.ruler to your dir too if you want global Claude rules.</p>
<h1 id="note-consider-just-using-agentsmd">Note: Consider just using AGENTS.md</h1>
<p>Most tools read <code>AGENTS.md</code>: Cursor, OpenCode, Codex, <del>others</del>. If all you have is
rules, it's not a bad idea to skip all of this and just use that format. I think it
might win. That doesn't help with Skills, though.</p>
<h2 id="skills">Skills</h2>
<p>Rules are basically just fancy prompt context that are always loaded.
Skills are just fancy prompt context loaded on-demand, maybe with some extra files
sometimes. Different tools implement them in different ways:</p>
<ul>
<li>Claude Code: <code>.claude/skills/</code></li>
<li>Cursor: <code>.cursor/skills/</code></li>
<li>Other tools follow the same pattern under their own config directories</li>
</ul>
<p>Ruler figures it out and distributes them for you. Could this all just be a bash
script? Yes. Does it do a bunch of stuff I don't understand too? Also, probably, yes.</p>
<p>Enabled by default. Pass <code>--no-skills</code> to skip it:</p>
<pre><code class="language-bash">ruler apply           # distributes rules + skills
ruler apply --no-skills  # rules only
</code></pre>
<hr>
<h1 id="consolidating-rules-migration-steps">Consolidating rules: Migration steps</h1>
<p>The <code>ruler.toml</code> at the root lists the agents to target:</p>
<pre><code class="language-toml">default_agents = ["claude", "cursor"]
</code></pre>
<p>Content moves from existing config files into <code>.ruler/</code> source files:</p>
<pre><code>.ruler/
  branching.md        # from root CLAUDE.md
  monorepo.md         # from .cursor/rules/monorepo.md (Claude never saw this)
apps/games/sillyapp/
  .ruler/
    build.md          # from sillyapp/CLAUDE.md
apps/blog/blog/markdown/posts/
  .ruler/
    style.md          # from posts/CLAUDE.md
apps/games/kid-bot-battle-sim/features/
  .ruler/
    interfaces.md     # from features/CLAUDE.md
</code></pre>
<p>Root <code>.ruler/branching.md</code> (was only in Claude Code):</p>
<pre><code class="language-markdown"># Branching

Never commit directly to `main`. Always create a branch and open a PR
against main for review.
</code></pre>
<p>Root <code>.ruler/monorepo.md</code> (was only in Cursor):</p>
<pre><code class="language-markdown"># Monorepo

This repo contains multiple independent sub-projects under `apps/` and
`games/`. Do not cross-reference or import code between sub-projects.
Each directory in those folders is its own isolated project.
</code></pre>
<p>The project-specific files (sillyapp build commands, blog style guide)
move into <code>.ruler/</code> inside their directories unchanged. Content stays the
same, location shifts.</p>
<p>Note: the existing hand-written CLAUDE.md files get replaced by generated
versions after <code>ruler apply</code>. Edit the <code>.ruler/</code> source, not the output.</p>


<p>I'm building a tabletop RPG game that generates images on the fly: character portraits,
enemy illustrations, scene art. Cloud APIs work but get expensive when every combat
encounter wants several images. More importantly, I need character consistency. If I
generate a portrait of "Aria the rogue" in session one, future images of her should
look like the same character, not a random new person.</p>
<p>ComfyUI solves both. It runs locally on Apple Silicon, exposes a REST API, and
supports IP-Adapter for using an existing portrait as a visual reference for new
generations.</p>
<h1 id="hardware-reality">Hardware Reality</h1>
<p>MacBook Air M2, 16GB unified memory. The Air throttles under sustained load since
it has no active cooling. Fine for a game that generates at natural breaks (between
scenes, at combat start) rather than continuously.</p>
<p>16GB comfortably fits:</p>
<ul>
<li><strong>SDXL</strong> (fp16, ~6.5GB): mature IP-Adapter ecosystem, good portrait quality</li>
<li><strong>FLUX.2-klein-4B</strong> (fp8, ~8-9GB): Apache 2.0, released November 2025, 4-step
distilled generation, supersedes FLUX.1-schnell. IP-Adapter support less
mature than SDXL.</li>
<li><strong>FLUX.1-dev</strong> (fp8, ~8GB): previous generation but still the best quality
option that fits 16GB. FLUX.2-dev exists but won't fit.</li>
</ul>
<p>For this post I'm using SDXL. Its IP-Adapter tools are battle-tested for exactly
this use case, and 6.5GB leaves plenty of headroom for additional models.</p>
<h1 id="install-comfyui">Install ComfyUI</h1>
<p>ComfyUI has a <a href="https://github.com/Comfy-Org/desktop">Desktop app</a> that handles
everything automatically. Use that if you just want the UI. For API access and
full control, manual install is cleaner.</p>
<pre><code class="language-bash">git clone https://github.com/comfyanonymous/ComfyUI
cd ComfyUI
python3.13 -m venv venv
source venv/bin/activate
python --version  # must say 3.13 — if it says 3.9 you have an old venv, rm -rf venv and redo
pip install -r requirements.txt
</code></pre>
<p>On Apple Silicon, the requirements file pulls a PyTorch build with MPS support
automatically. No CUDA, no special flags.</p>
<p>Start it:</p>
<pre><code class="language-bash">source venv/bin/activate
python main.py --listen 0.0.0.0 --port 8188
</code></pre>
<p><code>--listen 0.0.0.0</code> binds to all interfaces instead of localhost only. Needed for
the API to be reachable from other processes or devices on your network.</p>
<p>I keep a <code>start-comfyui.sh</code> in <code>~/models/</code> next to the model README so there's
one place for everything model-related:</p>
<pre><code class="language-bash">#!/bin/bash
source /path/to/ComfyUI/venv/bin/activate
cd /path/to/ComfyUI
python main.py --listen 0.0.0.0 --port 8188
</code></pre>
<p>Open <code>http://localhost:8188</code>. You should see the node graph UI with a default
workflow loaded. No models needed for the server to start — the UI comes up
regardless.</p>
<h1 id="model-storage">Model Storage</h1>
<p>Models don't need to live inside the repo. ComfyUI will look in additional
directories if you tell it to via <code>extra_model_paths.yaml</code>:</p>
<pre><code class="language-bash">cp extra_model_paths.yaml.example extra_model_paths.yaml
</code></pre>
<p>Then add an entry pointing at wherever you keep models. For example, if you
store them under <code>~/models/</code>:</p>
<pre><code class="language-yaml">my_models:
  base_path: ~/models/
  checkpoints: sdxl/
  ipadapter: ipadapter/
  clip_vision: clip_vision/
</code></pre>
<p>Adjust the subdirectory names to match your layout. ComfyUI merges these with
its own paths and shows everything in the UI dropdowns.</p>
<h1 id="models">Models</h1>
<p>Download SDXL (~6.5GB):</p>
<pre><code class="language-bash">hf download stabilityai/stable-diffusion-xl-base-1.0 \
  sd_xl_base_1.0.safetensors \
  --local-dir ~/models/sdxl/
</code></pre>
<p>For IP-Adapter, clone the custom node into ComfyUI's <code>custom_nodes/</code> directory:</p>
<pre><code class="language-bash">cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/cubiq/ComfyUI_IPAdapter_plus
</code></pre>
<p>No pip install needed — it has no extra dependencies beyond what ComfyUI
already installs. ComfyUI picks it up automatically on next startup.</p>
<p>Then download the IP-Adapter weights:</p>
<pre><code class="language-bash"># IP-Adapter for SDXL
hf download h94/IP-Adapter \
  sdxl_models/ip-adapter_sdxl.bin \
  --local-dir ~/models/ipadapter/

# CLIP vision encoder (required by IP-Adapter — must be ViT-bigG, not ViT-L)
hf download laion/CLIP-ViT-bigG-14-laion2B-39B-b160k \
  --local-dir ~/models/clip_vision/CLIP-ViT-bigG-14-laion2B-39B-b160k/
</code></pre>
<p>Restart ComfyUI after installing custom nodes. It rescans the nodes directory on
startup.</p>
<h1 id="quick-test">Quick Test</h1>
<p>Before touching the API, confirm generation works at all.</p>
<p>The built-in Templates target newer models and won't work with SDXL. ComfyUI
ships a test workflow in the repo — open it with <strong>File > Open</strong>:</p>
<pre><code>/path/to/ComfyUI/tests/inference/graphs/default_graph_sdxl1_0.json
</code></pre>
<p><img src="/images/comfyui-web-interface.png" alt="ComfyUI web interface"></p>
<p>It's a base+refiner workflow with two Load Checkpoint nodes. The top one
should already show <code>sd_xl_base_1.0.safetensors</code>. The bottom one defaults to
<code>sd_xl_refiner_1.0.safetensors</code> — change it to <code>sd_xl_base_1.0.safetensors</code>
too. We're not doing base+refiner, just running base twice.</p>
<p>Drop a prompt into one of the CLIP Text Encode nodes and hit <strong>Run</strong>:</p>
<pre><code>a knight in plate armor holding a mace and shield, fantasy RPG portrait,
detailed face, dramatic lighting, painterly style, 4k, highly detailed
</code></pre>
<p>First run is slow while the model loads. On M2 Air, SDXL at 20 steps takes
90-120 seconds. Subsequent runs with the model cached are faster but still
in that range — the Air throttles under sustained load with no active cooling.</p>
<p><img src="/images/oss-img-gen-knight.png" alt="Knight portrait generated with SDXL"></p>
<h1 id="img2img-post-battle">Img2Img: Post-Battle</h1>
<p>Txt2img generates from noise. Img2img starts from an existing image and
nudges it toward a new prompt. Good way to stay close to a character while
changing context or condition.</p>
<p>Add two nodes to the current workflow. Right-click empty canvas space (not
on a node) to get the picker:</p>
<ul>
<li><strong>image → Load Image</strong> — then select your knight from <code>ComfyUI/output/</code>
using the dropdown in the node, or upload it from there</li>
<li><strong>latent → VAE Encode</strong> — converts a pixel image into the latent space
the sampler works in, replacing the EmptyLatentImage</li>
</ul>
<p>Then make three connections. To draw a wire: click and drag from an output
dot (right side of a node) to an input dot (left side of another node).
The dots are color-coded by type and will only connect to compatible ports.</p>
<ol>
<li>Drag from the <strong>IMAGE</strong> dot (blue, right side of Load Image) to the
<strong>pixels</strong> dot on VAE Encode</li>
<li>Drag from either <strong>Load Checkpoint VAE</strong> dot → <strong>VAE Encode vae</strong> dot</li>
<li>Drag from <strong>VAE Encode LATENT</strong> dot → <strong>KSampler latent_image</strong> dot
(disconnects EmptyLatentImage automatically)</li>
</ol>
<p>The test workflow uses <strong>KSampler Advanced</strong>, which has no <code>denoise</code> slider.
Instead set <strong>start_at_step</strong> to <code>6</code>. With 20 total steps that runs the last
14, equivalent to about 70% denoise. Lower start_at_step = more faithful to
original, higher = more change.</p>
<p>Update the positive prompt — that's the CLIP Text Encode node wired to the
KSampler's <strong>positive</strong> input, as opposed to the negative one (which holds
your "ugly, blurry..." text):</p>
<pre><code>a knight in plate armor, damaged armor, battle-worn, dented helmet,
scratches and dents, mud-stained, exhausted, fantasy RPG portrait,
detailed face, dramatic lighting, painterly style, 4k, highly detailed
</code></pre>
<p>Hit <strong>Run</strong>. If it's changing too much, drop start_at_step to 4. If the
damage isn't reading, push to 8.</p>
<p><img src="/images/img2image-knight.png" alt="Knight after img2img battle damage pass"></p>
<p>Img2img works, but it's coarse. Fine details like face structure get lost
as you increase denoise, and at low denoise the prompt has limited
influence. Good for "same scene, different state." Not what you want for
generating the same character across completely different scenes.</p>
<p>That's what IP-Adapter is for. Instead of perturbing the reference image,
it encodes it through CLIP vision into an embedding that gets injected
alongside the text conditioning during generation. The sampler still starts
from pure noise, but the attention layers are nudged toward the character's
appearance at every step. Face and body survive across very different
scenes because the conditioning runs throughout, not just at the start.</p>
<h1 id="the-api">The API</h1>
<p>ComfyUI's API accepts a workflow as JSON and queues the generation. The workflow
you build in the UI can be exported in API format: go to Settings, enable Dev
Mode Options, then use the "Save (API Format)" button on the workflow.</p>
<p>The API format represents each node as a dict entry keyed by node ID. Here's a
minimal SDXL workflow:</p>
<pre><code class="language-json">{
  "4": {
    "class_type": "CheckpointLoaderSimple",
    "inputs": { "ckpt_name": "sd_xl_base_1.0.safetensors" }
  },
  "5": {
    "class_type": "EmptyLatentImage",
    "inputs": { "batch_size": 1, "height": 1024, "width": 768 }
  },
  "6": {
    "class_type": "CLIPTextEncode",
    "inputs": {
      "clip": ["4", 1],
      "text": "a fantasy rogue in a dark alley, RPG portrait, detailed"
    }
  },
  "7": {
    "class_type": "CLIPTextEncode",
    "inputs": {
      "clip": ["4", 1],
      "text": "ugly, blurry, watermark, text, bad anatomy"
    }
  },
  "3": {
    "class_type": "KSampler",
    "inputs": {
      "model": ["4", 0],
      "positive": ["6", 0],
      "negative": ["7", 0],
      "latent_image": ["5", 0],
      "seed": 42,
      "steps": 20,
      "cfg": 7,
      "sampler_name": "dpmpp_2m",
      "scheduler": "karras",
      "denoise": 1
    }
  },
  "8": {
    "class_type": "VAEDecode",
    "inputs": { "samples": ["3", 0], "vae": ["4", 2] }
  },
  "9": {
    "class_type": "SaveImage",
    "inputs": { "filename_prefix": "rpg", "images": ["8", 0] }
  }
}
</code></pre>
<p>Submit it:</p>
<pre><code class="language-bash">curl -X POST http://localhost:8188/prompt \
  -H "Content-Type: application/json" \
  -d '{"prompt": &#x3C;workflow_json>}'
# Returns: {"prompt_id": "abc123...", "number": 1, "node_errors": {}}
</code></pre>
<p>Poll for completion:</p>
<pre><code class="language-bash">curl http://localhost:8188/history/abc123
# When done: history[prompt_id]["status"]["completed"] == true
</code></pre>
<p>Fetch the image:</p>
<pre><code class="language-bash">curl "http://localhost:8188/view?filename=rpg_00001_.png" \
  --output character.png
</code></pre>
<p>Images also land in <code>ComfyUI/output/</code> on disk if you'd rather read them
directly.</p>
<h1 id="image-consistency-with-ip-adapter">Image Consistency with IP-Adapter</h1>
<p>IP-Adapter encodes a reference image using CLIP vision and injects that embedding
alongside the text prompt during generation. The result is a new image that
respects the prompt but is visually pulled toward the reference: same hair, same
armor, similar face structure.</p>
<p>It's not a perfect clone. Think of it as a strong nudge. Consistent text prompts
help too. If every prompt for Aria includes "tall elf rogue, purple hair, leather
armor," you're conditioning from both directions.</p>
<p>Add these nodes to the workflow above:</p>
<pre><code class="language-json">"10": {
  "class_type": "IPAdapterModelLoader",
  "inputs": { "ipadapter_file": "ip-adapter_sdxl.bin" }
},
"11": {
  "class_type": "CLIPVisionLoader",
  "inputs": { "clip_name": "CLIP-ViT-bigG-14-laion2B-39B-b160k/open_clip_model.safetensors" }
},
"12": {
  "class_type": "LoadImage",
  "inputs": { "image": "aria_portrait.png" }
},
"13": {
  "class_type": "IPAdapterAdvanced",
  "inputs": {
    "model": ["4", 0],
    "ipadapter": ["10", 0],
    "image": ["12", 0],
    "clip_vision": ["11", 0],
    "weight": 0.6,
    "weight_type": "linear",
    "combine_embeds": "concat",
    "start_at": 0.0,
    "end_at": 1.0,
    "embeds_scaling": "V only"
  }
}
</code></pre>
<p>Then change node <code>"3"</code>'s <code>model</code> input from <code>["4", 0]</code> to <code>["13", 0]</code>.</p>
<p>The prompt here asks for the same knight in a tavern — completely different
scene, same character used as reference.</p>
<p><img src="/images/oss-img-gen-ipadapter.png" alt="Knight in a tavern, generated with IP-Adapter using the portrait as reference"></p>
<p><code>weight</code> is the main knob. At 0.5 you get style and general appearance influence.
At 0.8 it starts fighting the text prompt. For character identity, 0.6-0.7 is
the range to start with.</p>
<p>The <code>image</code> input in node <code>"12"</code> is a filename relative to <code>ComfyUI/input/</code>.
Copy your reference images there, or upload them via the API:</p>
<pre><code class="language-bash">curl -X POST http://localhost:8188/upload/image \
  -F "image=@aria_portrait.png"
# Returns: {"name": "aria_portrait.png", "subfolder": "", "type": "input"}
</code></pre>
<h2 id="face-consistency">Face Consistency</h2>
<p>Standard IP-Adapter works well for overall style and body type. Faces drift more
than you'd like, especially across very different scenes. IP-Adapter FaceID handles
this by extracting face embeddings specifically rather than encoding the whole image.</p>
<p>Download:</p>
<pre><code class="language-bash">hf download h94/IP-Adapter-FaceID \
  ip-adapter-faceid-plusv2_sdxl.bin \
  --local-dir ~/models/ipadapter/
</code></pre>
<p>FaceID also requires InsightFace, which isn't on HuggingFace. Download the
<code>antelopev2</code> model package from the
<a href="https://github.com/deepinsight/insightface/tree/master/model_zoo">InsightFace model zoo</a>
and place it under <code>~/models/insightface/models/antelopev2/</code> (or wherever your
<code>extra_model_paths.yaml</code> maps <code>insightface</code>).</p>
<p>Install the Python package into the ComfyUI venv:</p>
<pre><code class="language-bash">source /path/to/ComfyUI/venv/bin/activate
pip install insightface onnxruntime
</code></pre>
<p>With FaceID installed, use <code>IPAdapterFaceIDAdvanced</code> instead of <code>IPAdapterAdvanced</code>.
It takes the same inputs but runs the face embedding extraction automatically.
Faces stay recognizable across very different scenes much more reliably than with
the standard adapter.</p>
<p>You can combine both: use <code>IPAdapterAdvanced</code> for overall character appearance
and <code>IPAdapterFaceIDAdvanced</code> for face locking, chaining them in sequence.</p>
<h1 id="game-integration">Game Integration</h1>
<p>The pattern for a TTRPG character system:</p>
<pre class="mermaid">
graph TD
    A[Player describes character] --> B[Generate initial portrait\nno reference image]
    B --> C[Store portrait in character record]
    C --> D[Game event triggers image]
    D --> E[Build scene + character prompt]
    E --> F[Upload portrait, generate\nwith IP-Adapter]
    F --> G[Display in game]
    G --> D
</pre>


<p>CodeRabbit is an AI code review tool. It can review your PRs on GitHub / MRs on GitLab
after you push. You can also hook it into Claude Code to get the review and fix up the
nits with your agent prior to opening the PR.</p>
<h1 id="install-the-cli">Install the CLI</h1>
<pre><code class="language-bash">curl -fsSL https://cli.coderabbit.ai/install.sh | sh
</code></pre>
<p>Then authenticate:</p>
<pre><code class="language-bash">coderabbit auth login
</code></pre>
<p>This opens a browser. Log in with GitHub, copy the token, paste it in the
terminal. The token lasts 90 days.</p>
<p>Verify it worked:</p>
<pre><code class="language-bash">coderabbit --version
</code></pre>
<h1 id="install-the-claude-code-plugin">Install the Claude Code Plugin</h1>
<p>From any terminal:</p>
<pre><code class="language-bash">claude plugin install coderabbit
</code></pre>
<p>Or from inside a Claude Code session:</p>
<pre><code class="language-text">/plugin install coderabbit
</code></pre>
<p>The plugin wraps the CLI and exposes review commands you can run directly in
your Claude Code session. It also lets you trigger a review with plain English,
which Claude Code routes to the plugin automatically.</p>
<h1 id="the-workflow">The Workflow</h1>
<p>With both the CLI and plugin installed, the loop before any PR looks like this:</p>
<pre class="mermaid">
graph TD
    A[Make changes with Claude Code] --> B[Run coderabbit review]
    B --> C{Issues?}
    C -->|Yes| D[Ask Claude Code to fix them]
    D --> A
    C -->|No| E[Create PR]
</pre>
<p>Inside a Claude Code session, after you've made changes:</p>
<pre><code class="language-text">/coderabbit:review uncommitted
</code></pre>
<p>This reviews everything not yet committed. You can also review committed-but-
not-pushed changes:</p>
<pre><code class="language-text">/coderabbit:review committed
</code></pre>
<p>Or compare against a specific branch:</p>
<pre><code class="language-text">/coderabbit:review --base main
</code></pre>
<p>The review comes back as inline comments. You can ask Claude Code to fix specific
issues, re-run the review, and iterate until it's clean. Then push and open the
PR knowing CodeRabbit's automated review will be quiet.</p>
<p>It's kind of slow, but so is the PR review.</p>
<h1 id="claudemd-integration">CLAUDE.md integration</h1>
<p>CodeRabbit reads your <code>CLAUDE.md</code> files automatically. It treats them as code
guidelines and applies them during review.</p>
<p>That means that because my <code>CLAUDE.md</code> says "no em-dashes" and "never commit directly to
main",  CodeRabbit enforces those same rules when it reviews your PR. You don't need to
configure anything extra.</p>
<h1 id="config-with-coderabbityaml">Config with <code>.coderabbit.yaml</code></h1>
<p><code>.coderabbit.yaml</code> at the root gives control over what gets reviewed, how aggressively,
and with what focus per directory.</p>
<p>Notably:</p>
<ul>
<li><code>path_filters</code>: glob patterns for files to skip entirely (lock files, build
artifacts, node_modules, etc)</li>
<li><code>path_instructions</code>: per-path AI instructions</li>
</ul>
<p>Don't put <code>CLAUDE.md</code> in <code>path_instructions</code>. That makes CodeRabbit try
to review the file rather than use it as guidelines. The auto-detection handles
it correctly without any config.</p>
<h2 id="setup-for-this-repo">Setup for this repo</h2>
<p>Here's <a href="https://github.com/kylep/multi/blob/main/.coderabbit.yaml">the <code>.coderabbit.yaml</code> for this repo</a>.</p>
<p><strong><code>profile: chill</code></strong> is the most significant setting. CodeRabbit's default
profile generates a lot of comments. I'm actually on the fence still about this though,
once I can get the AI agents to run the code review and fix up in a ralf-style-loop I
may go back to aggressive.</p>
<p><strong><code>poem: false</code></strong> turns off CodeRabbit's cute poems, I'm not reading them like this.</p>
<p><strong>Path filters</strong> drop lock files, build artifacts, and generated directories.
There's no value in reviewing a <code>package-lock.json</code> diff.</p>
<p><strong><code>infra/</code> and <code>apps/kytrade/</code></strong> get security-focused instructions with
everything else deprioritized. Terraform style is not worth a comment.
A misconfigured IAM policy is.</p>
<p><strong><code>apps/blog/blog/markdown/posts/</code></strong> gets a specific instruction to ignore
grammar, phrasing, and tone entirely. I'm specifically spending effort to not write
like a robot, I can't stand the writing style. CodeRabbit shouldn't fight it.</p>
<p><strong><code>samples/</code></strong> is tutorial code I used to save examples of projects along the way.</p>
<p><strong><code>**/tests/**</code></strong> is told to focus on whether tests actually assert something,
not on style. A test that always passes is a real problem. Variable naming is
not.</p>
<h2 id="update-teaching-it-about-false-positives-2026-03-11">Update: teaching it about false positives (2026-03-11)</h2>
<p>CodeRabbit kept flagging my blog frontmatter tags as needing YAML
list format. The blog parser handles comma-separated tags on one
line, so this was a false positive on every post.</p>
<p>The fix is <code>path_instructions</code> in <code>.coderabbit.yaml</code>. I added a
note to the blog posts path telling it not to suggest converting
frontmatter tags to list format. CodeRabbit applies these
instructions on every review, so the false positive should stop
recurring.</p>
<p>You can also reply <code>@coderabbitai</code> on a PR comment to teach it
inline. It stores those as "learnings" and applies them to future
reviews. The <code>.coderabbit.yaml</code> approach is more durable since
it's checked into the repo.</p>


<p>No API costs, no data leaving the machine, works offline. The catch is you're
limited to models that fit in RAM. At 16GB, you can run most 7-8B models at
good quality, or push into 12B at a lower quant.</p>
<p>This runs three models locally and compares them:</p>
<table>
<thead>
<tr>
<th>Model</th>
<th>Params</th>
<th>Style</th>
<th>Quant</th>
<th>Size</th>
</tr>
</thead>
<tbody>
<tr>
<td>Qwen3 8B</td>
<td>8B</td>
<td>Instruction</td>
<td>Q4_K_L</td>
<td>5.49 GB</td>
</tr>
<tr>
<td>DeepSeek-R1-Distill-Qwen-7B</td>
<td>7B</td>
<td>Reasoning</td>
<td>Q4_K_L</td>
<td>5.09 GB</td>
</tr>
<tr>
<td>Mistral Nemo Instruct 2407</td>
<td>12B</td>
<td>Instruction</td>
<td>Q4_K_L</td>
<td>7.98 GB</td>
</tr>
<tr>
<td>Mistral Small 3.1 24B</td>
<td>24B</td>
<td>Instruction</td>
<td>Q4_K_S</td>
<td>13.5 GB</td>
</tr>
</tbody>
</table>
<p>The first three fit comfortably in 16GB with room for context. Mistral Small
3.1 at 13.5 GB leaves very little headroom on a 16GB machine. To browse other models,
<a href="https://huggingface.co/bartowski">bartowski's HuggingFace page</a> is a good
starting point for well-tested GGUF quantizations.</p>
<p><strong>Params</strong> (parameters) are the learned weights that make up the model. More
parameters generally means more capable, but also more RAM and slower inference.
7-8B is a practical sweet spot for 16GB machines.</p>
<p><strong>Quantization</strong> is how a full-precision model gets compressed to fit on
consumer hardware. The original weights are 16 or 32-bit floats; quantization
rounds them down to fewer bits, trading a small amount of accuracy for a large
reduction in size and RAM usage. <strong>Q4_K_L</strong> uses 4-bit weights with the
embedding and output layers kept at higher precision (8-bit) to preserve
quality. <strong>Q4_K_S</strong> is the smaller sibling: same 4-bit compression throughout,
including the embedding layers, shaving off a bit of quality for a smaller
file. For Mistral Small 3.1 that's the difference between 13.5 GB (K_S) and
14.8 GB (K_L). On a 16GB machine, that 1.3 GB matters, so K_S is the right
pick there.</p>
<p><strong>Instruction</strong> models are trained to follow directions and answer questions
directly. You ask, they answer. <strong>Reasoning</strong> models think out loud first,
working through the problem step by step before giving a final answer. Slower,
but more reliable on anything involving logic, math, or code.</p>
<h1 id="hardware">Hardware</h1>
<ul>
<li>MacBook Air M2, 16GB unified memory</li>
<li>macOS 26 (Tahoe)</li>
</ul>
<p>No active cooling on the Air, so it'll throttle during long runs. Fine for
interactive use.</p>
<h1 id="setup">Setup</h1>
<p>These steps are shared across all three models.</p>
<h2 id="1-install-llamacpp">1. Install llama.cpp</h2>
<p><a href="https://github.com/ggerganov/llama.cpp">llama.cpp</a> is the runtime that loads
and runs GGUF model files. It handles the actual inference: tokenizing your
input, running it through the model weights, and streaming tokens back to you.
Think of it as the engine; the GGUF file is the model it runs. It also handles
Metal GPU offloading on Apple Silicon, which is what makes local inference fast
enough to be usable.</p>
<pre><code class="language-bash">brew install llama.cpp
</code></pre>
<p>Gives you <code>llama-cli</code> for interactive chat and <code>llama-server</code> for an
OpenAI-compatible HTTP API.</p>
<h2 id="2-install-the-hugging-face-cli">2. Install the Hugging Face CLI</h2>
<p>Installing Python tools with plain <code>pip</code> can stomp on system Python or conflict
with other packages. <code>pipx</code> puts each CLI tool in its own isolated environment
and adds it to your PATH. No venv to activate.</p>
<pre><code class="language-bash">brew install pipx
pipx ensurepath
pipx install "huggingface_hub[cli]"
</code></pre>
<p><code>pipx ensurepath</code> adds pipx's bin dir to your PATH. Restart your terminal after
running it.</p>
<p>Note: the installed command is <code>hf</code>, not <code>huggingface-cli</code>. The name changed in
v1.x.</p>
<h1 id="the-models">The Models</h1>
<h2 id="qwen3-8b">Qwen3 8B</h2>
<p>Alibaba's Qwen3 8B (released April 2025) is a dense instruction-tuned model
that also supports a thinking mode. By default it answers directly. You can
enable step-by-step reasoning with <code>/think</code> in the chat, or disable it with
<code>/no_think</code>.</p>
<pre><code class="language-bash">hf download bartowski/Qwen_Qwen3-8B-GGUF Qwen_Qwen3-8B-Q4_K_L.gguf \
  --local-dir ~/models/qwen3-8b/
</code></pre>
<h2 id="deepseek-r1-distill-qwen-7b">DeepSeek-R1-Distill-Qwen-7B</h2>
<p>Note: despite the name, there is no 8B Qwen-based DeepSeek distill. The 8B
distill uses Llama architecture. This one is 7B on Qwen architecture, released
January 2025.</p>
<p>DeepSeek distilled the chain-of-thought behaviour from their R1 reasoning model
into this smaller base. It always shows its thinking inside <code>&#x3C;think>...&#x3C;/think></code>
tags before the final answer. Verbose for simple questions, but useful for
anything involving logic or code.</p>
<pre><code class="language-bash">hf download bartowski/DeepSeek-R1-Distill-Qwen-7B-GGUF \
  DeepSeek-R1-Distill-Qwen-7B-Q4_K_L.gguf \
  --local-dir ~/models/deepseek-r1-qwen-7b/
</code></pre>
<h2 id="mistral-small-31-24b">Mistral Small 3.1 24B</h2>
<p>Released March 17, 2025. Mistral's most capable small model at the time.
24B parameters, multimodal (supports image input), 128k context window,
Apache 2.0. Mistral officially recommends 32GB RAM for this one, so running
it on a 16GB M2 Air is pushing it. It loads and runs, but context has to stay
small.</p>
<p>Note: bartowski's repo for this model has a <code>mistralai_</code> prefix in the name,
unlike the others.</p>
<pre><code class="language-bash">hf download bartowski/mistralai_Mistral-Small-3.1-24B-Instruct-2503-GGUF \
  Mistral-Small-3.1-24B-Instruct-2503-Q4_K_S.gguf \
  --local-dir ~/models/mistral-small-3.1-24b/
</code></pre>
<p>K_S over K_L here because at 13.5 GB vs 14.8 GB, the difference determines
whether you have any RAM left for context and the OS.</p>
<h2 id="mistral-nemo-instruct-12b">Mistral Nemo Instruct 12B</h2>
<p>Mistral's 12B model (released July 2024, jointly with NVIDIA). Bigger than the
other two, which shows in the quality of longer-form responses. At Q4_K_L it's
7.98 GB, leaving ~6GB free for macOS and context.</p>
<pre><code class="language-bash">hf download bartowski/Mistral-Nemo-Instruct-2407-GGUF \
  Mistral-Nemo-Instruct-2407-Q4_K_L.gguf \
  --local-dir ~/models/mistral-nemo-12b/
</code></pre>
<h1 id="running-them">Running Them</h1>
<p>The flags are the same for all three. Swap the <code>-m</code> path.</p>
<h2 id="interactive-chat">Interactive chat</h2>
<pre><code class="language-bash"># Qwen3 8B
llama-cli \
  -m ~/models/qwen3-8b/Qwen_Qwen3-8B-Q4_K_L.gguf \
  -ngl 99 -c 8192

# DeepSeek-R1-Distill-Qwen-7B
llama-cli \
  -m ~/models/deepseek-r1-qwen-7b/DeepSeek-R1-Distill-Qwen-7B-Q4_K_L.gguf \
  -ngl 99 -c 8192

# Mistral Nemo 12B
llama-cli \
  -m ~/models/mistral-nemo-12b/Mistral-Nemo-Instruct-2407-Q4_K_L.gguf \
  -ngl 99 -c 8192

# Mistral Small 3.1 24B — tight on RAM, keep context small
llama-cli \
  -m ~/models/mistral-small-3.1-24b/Mistral-Small-3.1-24B-Instruct-2503-Q4_K_S.gguf \
  -ngl 99 -c 2048
</code></pre>
<p>Flags:</p>
<ul>
<li><code>-ngl 99</code>: offload all layers to Metal. Without this you're CPU-only and it's
very slow. <code>--fit on</code> instead might be better, not sure.</li>
<li><code>-c 8192</code>: context window. Comfortable with 16GB for the smaller two. Fine
for Mistral Nemo too given the headroom.</li>
</ul>
<p>Interactive mode is auto-enabled when the model has a chat template, which all
three do. The old <code>--interactive-first</code> flag was removed in newer llama.cpp.</p>
<h2 id="openai-compatible-server">OpenAI-compatible server</h2>
<pre><code class="language-bash">llama-server \
  -m ~/models/qwen3-8b/Qwen_Qwen3-8B-Q4_K_L.gguf \
  -ngl 99 -c 8192 --port 8080
</code></pre>
<p>Exposes <code>http://localhost:8080/v1/chat/completions</code>. Swap the model path for
whichever you want to serve.</p>
<h1 id="conclusion">Conclusion</h1>
<h2 id="notes-on-each">Notes on Each</h2>
<p><strong>Qwen3 8B</strong>: Pretty fast. The thinking thing was a bit slow but not bad. It mostly
stuck to the instructions I gave it, like "max 3 paragraphs", and was reasonably
creative. It was also kind of bland and generic, for better or worse.</p>
<p><strong>DeepSeek-R1-Distill-Qwen-7B</strong>: Also ok speed. It had a hard time following
instructions and sticking to the constraints that I'd tried to put in place, like that
same 3 paragraph limit. Overall I was pretty dissapointed given its reputation.</p>
<p><strong>Mistral Nemo 12B</strong> The direct responses felt fast even though it ran at about half
the tokens per second, due to it not working in Reasoning mode. The writing style of
Nemo was by far the best, and it adhered much better to the prompts.</p>
<p><strong>Mistral Nemo 24B</strong> Not enough RAM. I'd figured I could close things and make it work
but it's not worth it. Maybe on a better computer.</p>
<h2 id="not-enough-tokens">Not enough tokens</h2>
<p>The <code>8192</code> tokens they all use got to feeling pretty small, pretty fast. I tried to
push the continuity with a "Choose your own adventure" style conversation and it did
well until it just kind of stopped. I think I've seen claude crushing context down when
it gets near the limit, I wonder if there's a way to do that with this too, or get it
to do some sort of context shifting where it restarts with just the later context when
it runs low. Maybe I can run it in server mode and have a better client manage that,
but that seems like its own post. If you want to run models through an API
rather than locally, <a href="/openrouter-ai-tools.html">OpenRouter</a> is worth a look.</p>
<h2 id="winner">Winner</h2>
<p>Nemo was the pretty clear winner. I'm not sure if that's because of the size of the
model or something else, but it was a significant step up in its ability to stick to
the prompt's instructions, and the writing style was better too.</p>


<p>I wrote about this blog's <a href="/ai-generate-blog-images.html">automated image generation</a> previously. The short version: <code>generate-images.mjs</code> runs before each build, finds posts with missing images, builds a prompt from the <code>imgprompt</code> front matter field (or has <code>gpt-4o-mini</code> summarize the post), then calls DALL-E 3 to produce a 1024x1024 image.</p>
<p>It works, but DALL-E 3 is frustrating. It ignores prompt details, can't make a white background to save its life, and the results look more "AI art" than "clean icon." Time to see what else is out there.</p>
<p><em>Lesson Learned</em>: Don't let Cursor/Claude look online to find the most recent model versions. It got it wrong twice. I had to manually go back and update it after noticing that Gemini's 2.0-flash was not the newer Nano Banana (2.5, 3).</p>
<h1 id="top-models-today">Top Models Today</h1>
<p>This space moves fast. As of February 2026, these are the top 3 image generation models on the <a href="https://arena.ai/leaderboard/text-to-image">LM Arena text-to-image leaderboard</a> that have public APIs. These rankings are based on blind human preference voting and will almost certainly be different by the time you read this.</p>
<p><strong>ELO Scores:</strong> ELO is a rating system where users are shown two AI-generated images side by side (without knowing which model made which) and pick the one they prefer. Wins and losses shift each model's score, so a higher ELO means the model's images are consistently preferred by real people.</p>
<table>
<thead>
<tr>
<th>Model</th>
<th>Provider</th>
<th>Released</th>
<th>ELO</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td><strong>GPT Image 1.5</strong></td>
<td>OpenAI</td>
<td>December 2025</td>
<td>1248</td>
<td>4x faster than GPT Image 1. Token-based pricing, 20% cheaper than its predecessor.</td>
</tr>
<tr>
<td><strong>Nano Banana Pro</strong></td>
<td>Google (Gemini 3 Pro Image)</td>
<td>November 2025</td>
<td>1237</td>
<td>Native Gemini image gen. Strong multimodal integration.</td>
</tr>
<tr>
<td><strong>Flux 2 Max</strong></td>
<td>Black Forest Labs</td>
<td>November 2025</td>
<td>1169</td>
<td>32B parameter model. Megapixel-based pricing. BFL's highest quality tier.</td>
</tr>
</tbody>
</table>
<p>GPT Image 1.5 and Nano Banana Pro are close in quality. Flux 2 Max sits ~80 ELO points behind them but is the strongest non-Google non-OpenAI option available.</p>
<p><strong>What about open source?</strong> Flux 2 Dev is open-weight and Stable Diffusion 3.5 is fully open source, but neither is practical for this use case. Running them on a MacBook Air M2 (8GB unified memory, passive cooling) means throttling after ~90 seconds, a max practical resolution of 512x512, and needing to close basically every other app first. The quality gap vs. the API models is real too. For a build-time script that needs to reliably produce clean images, cloud APIs win.</p>
<h1 id="setup-gpt-image-15">Setup: GPT Image 1.5</h1>
<p>This is the easiest since the blog already uses OpenAI.</p>
<ol>
<li><strong>API Key</strong>: Already set up. Same <code>OPENAI_API_KEY</code> used for DALL-E 3.</li>
<li><strong>Model change</strong>: Update the <code>model</code> parameter from <code>dall-e-3</code> to <code>gpt-image-1.5</code> in the images API call.</li>
<li><strong>API differences</strong>: GPT Image 1.5 supports both the Images API (<code>/v1/images/generations</code>) and the newer Responses API. The Images API is the closest drop-in replacement. Quality can be set to <code>low</code>, <code>medium</code>, <code>high</code>, or <code>auto</code>. It also supports streaming partial renders and up to 16 reference images for editing.</li>
</ol>
<pre><code class="language-bash">export OPENAI_API_KEY="sk-..."
</code></pre>
<p>If you don't already have a key, create one at <a href="https://platform.openai.com/api-keys">platform.openai.com/api-keys</a>.</p>
<h1 id="setup-nano-banana">Setup: Nano Banana</h1>
<p>Nano Banana is Google's image generation feature built on Gemini. You can access it through the official Google Gemini API.</p>
<ol>
<li><strong>Get an API key</strong>: Go to <a href="https://aistudio.google.com/app/apikey">Google AI Studio</a> and create a new API key.</li>
<li><strong>Install the SDK</strong>:
<pre><code class="language-bash">npm install @google/genai
</code></pre>
</li>
<li><strong>Set the environment variable</strong>:
<pre><code class="language-bash">export GEMINI_API_KEY="your-key-here"
</code></pre>
</li>
<li><strong>API usage</strong>: Nano Banana image gen uses the Gemini API with <code>responseModalities: ["TEXT", "IMAGE"]</code>. The model name for the standard tier is <code>gemini-2.5-flash-preview-image</code> and for Pro it's <code>gemini-3-pro-image</code>.</li>
</ol>
<p>Note: the API flow is different from OpenAI. You send a chat completion-style request with image output enabled, and the response includes inline image data.</p>
<h1 id="setup-flux-2-max">Setup: Flux 2 Max</h1>
<p>Black Forest Labs runs their own API platform.</p>
<ol>
<li><strong>Create an account</strong>: Register at <a href="https://dashboard.bfl.ai">dashboard.bfl.ai</a> and confirm your email.</li>
<li><strong>Add credits</strong>: Navigate to API → Credits and add funds via Stripe. Pricing is simple: 1 credit = $0.01 USD.</li>
<li><strong>Create an API key</strong>: Go to API → Keys, click "Add Key", and copy it immediately (it's only shown once).</li>
<li><strong>Set the environment variable</strong>:
<pre><code class="language-bash">export BFL_API_KEY="your-key-here"
</code></pre>
</li>
<li><strong>API usage</strong>: POST to <code>https://api.bfl.ai/v1/flux-2-max</code> with your prompt, width, and height. The API is async — you submit a task and poll for the result using the returned task ID.</li>
</ol>
<h1 id="setup-verification">Setup Verification</h1>
<p>Once you've configured your API keys, you can verify everything is wired up correctly by running:</p>
<pre><code class="language-bash">node apps/blog/blog/scripts/generate-images.mjs --verify
</code></pre>
<p>This will check that each configured API key is valid and can reach its respective service without actually generating any images. We'll implement this flag in a follow-up change.</p>
<h1 id="cost">Cost</h1>
<p>All prices are USD per image at 1024x1024.</p>
<table>
<thead>
<tr>
<th>Model</th>
<th>Cost</th>
<th>Pricing Model</th>
<th>Notes</th>
</tr>
</thead>
<tbody>
<tr>
<td>DALL-E 3 (prior)</td>
<td>~$0.04</td>
<td>Per image</td>
<td>Fixed price, single quality tier</td>
</tr>
<tr>
<td>GPT Image 1.5</td>
<td>$0.009–$0.14</td>
<td>Per token (output)</td>
<td>Varies by quality: low ~$0.009, medium ~$0.03, high ~$0.14. ~20% cheaper than GPT Image 1</td>
</tr>
<tr>
<td>Nano Banana</td>
<td>~$0.02</td>
<td>Per image</td>
<td>Standard tier (Gemini 2.5 Flash). Pro tier is ~$0.10/image</td>
</tr>
<tr>
<td>Flux 2 Max</td>
<td>~$0.07</td>
<td>Per megapixel</td>
<td>Scales with resolution. 1024x1024 ≈ 1MP ≈ 7 credits</td>
</tr>
</tbody>
</table>
<p>The ambiguity here is mostly around GPT Image 1.5 — the token-based pricing means cost depends heavily on the quality setting and prompt length. For a fair comparison we'll use "medium" quality, which lands close to what we're paying for DALL-E 3 today. Flux 2 Max's megapixel pricing is predictable but gets more expensive at higher resolutions.</p>
<h1 id="results">Results</h1>
<p>Each model was given the same prompt, built from <code>imgprompt: "A cute robot wearing a short chefs hat and holding a paint brush"</code>:</p>
<pre><code class="language-text">Subject: "A cute robot wearing a short chefs hat and holding a paint brush".
Style: minimalist flat vector icon, clean lines, crisp edges, simplified geometric shapes.
Colors: black, white, and one primary accent color only. No gradients.
Composition: centered subject, generous negative space, wide landscape 16:9 aspect ratio.
Background: pure solid white (#FFFFFF), filling the entire image.
No text, no shadows, no textures, no transparency, no background elements.
</code></pre>
<p>All images were center-cropped to 533x300 (16:9) after generation.</p>
<h2 id="gpt-image-15-openai">GPT Image 1.5 (OpenAI)</h2>
<p>Model: <code>gpt-image-1.5</code>, size: 1024x1024, quality: medium. Estimated cost: ~$0.03.</p>
<p><img src="/images/ai-image-gen-bakeoff-openai.png" alt="GPT Image 1.5 result"></p>
<h2 id="gemini-20-flash-google">Gemini 2.0 Flash (Google)</h2>
<p>Model: <code>gemini-2.0-flash-exp-image-generation</code>. Estimated cost: ~$0.02 (free tier may apply).</p>
<p><img src="/images/ai-image-gen-bakeoff-gemini-2.0.png" alt="Nano Banana 2.0 result"></p>
<h2 id="nano-banana-gemini-25-flash">Nano Banana (Gemini 2.5 Flash)</h2>
<p>Model: <code>gemini-2.5-flash-image</code>. Estimated cost: ~$0.02.</p>
<p><img src="/images/ai-image-gen-bakeoff-gemini-2.5.png" alt="Nano Banana 2.5 Flash result"></p>
<h2 id="nano-banana-pro-gemini-3-pro">Nano Banana Pro (Gemini 3 Pro)</h2>
<p>Model: <code>gemini-3-pro-image-preview</code>. Estimated cost: ~$0.10.</p>
<p><img src="/images/ai-image-gen-bakeoff-gemini-3-pro.png" alt="Nano Banana 3 Pro result"></p>
<h2 id="flux-2-max-bfl">Flux 2 Max (BFL)</h2>
<p>Model: <code>flux-2-max</code>, size: 1024x576. Estimated cost: ~$0.04 (~0.6MP at $0.07/MP).</p>
<p><img src="/images/ai-image-gen-bakeoff-flux.png" alt="Flux 2 Max result"></p>
<h1 id="conclusion">Conclusion</h1>
<p>It's pretty close between OpenAI and Nano Banana 2.5. I'll likely switch back and forth between the two, but to pick a flat winner as default I'm going with OpenAI for now.</p>
<p>OpenAI has that annoying same-y generic feel that lets you know it's AI art, and I don't love that, but it's also definitely more cute.</p>
<p>Nano Banana's ones are pretty original. I like 3-pro the most but not the price. 2.5-flash is fun, a bit cleaner than OpenAI's art, just kind of <em>busy</em>. I'll probably pick it when I'm aiming for cleaner images than cute ones.</p>
<p>Flux's was more artsy. It's just kind of... weird? It kept drawing unique stuff but just sort of unsettling.</p>


<p>Making blog thumbnails and images is tedious. I don't want to fight with Gimp or whatever and I don't think anyone cares what the image really is.</p>
<p>To make publishing easier, this site now checks for the image in each markdown post during the build to see if it already exists. If not, a prompt is built from the post title and content and sent to OpenAI's image API. The returned art is saved alongside the post and a 70×70 thumbnail is produced using Sharp.</p>
<p>To make the image for this post it cost me about $0.12 CAD in OpenAI credits. Entertainingly that's probably more than what hosting this site will cost for like a week due to the setup I'm using to host this.</p>
<p>This automation was initially coded with Codex, but it didn't work quite right. I fixed it up with Cursor, then a bit manually to get it across the finish line. This was as much about playing with the AI dev tools as building the feature.</p>
<p>Check it out here <a href="https://github.com/kylep/multi/blob/main/apps/blog/blog/scripts/generate-images.mjs">generate-images.mjs</a>.</p>
<h1 id="how-it-works">How It Works</h1>
<p>The image generation system is integrated into the build pipeline through the <code>package.json</code> build script:</p>
<pre><code class="language-json">"build": "node scripts/generate-images.mjs &#x26;&#x26; next build"
</code></pre>
<p>Before Next.js builds the static site, the <code>generate-images.mjs</code> script runs and:</p>
<ol>
<li><strong>Scans all markdown files</strong> in <code>markdown/posts/</code> for front matter</li>
<li><strong>Checks for missing images</strong> referenced in the <code>image</code> and <code>thumbnail</code> fields</li>
<li><strong>Generates missing images</strong> using OpenAI's DALL·E API if <code>OPENAI_API_KEY</code> is set</li>
<li><strong>Creates thumbnails</strong> by resizing generated images to 70×70 pixels using Sharp</li>
</ol>
<h2 id="the-generation-process">The Generation Process</h2>
<p>It's all pretty straightforward:</p>
<p>High level script logic:</p>
<ol>
<li>If there's no image defined, do nothing</li>
<li>If the image is defined in the front matter but doesn't exist, generate it.</li>
<li>If the image does exist but thumbnail doesn't, resize it and save that too.</li>
</ol>
<p>Generating the image is also simple:</p>
<ol>
<li>If the front matter has <code>imgprompt</code> in it, use that as the <code>summary</code> of the post.</li>
<li>If <code>imgprompt</code> is not present get <code>gpt-4o-mini'</code> to write a <code>summary</code> of the post.</li>
<li>Use <code>dall-e-3</code> to create the image.</li>
<li>Complain that it didn't look right, tweak the prompt, repeat until sufficiently frustrated, move on.</li>
</ol>
<h3 id="prompts">Prompts</h3>
<p>At time of writing (I won't keep this updated, check the code), I used these for the prompts:</p>
<p>Making the summary:</p>
<pre><code class="language-javascript">async function summarizeBlogContent(data, content) {
  const openai = new OpenAI({ apiKey: process.env.OPENAI_API_KEY });
  const prompt = await openai.chat.completions.create({
    model: 'gpt-4o-mini',
    messages: [{ role: 'user', content: `In max 20 words, describe a simple logo image that would represent this blog post: ${content}` }],
  });
  const summary = prompt.choices[0].message.content;
  console.log(`✨📝 Created summary of "${data.title}" → ${summary}`);
  return summary;
}
</code></pre>
<p>Making the image</p>
<pre><code class="language-javascript">async function getPromptFromContent(data, content) {
  const subject = data.imgprompt
    ? data.imgprompt
    : await summarizeBlogContent(data, content);
  const prompt = [
    "Simple minimalist flat vector icon.",
    `Subject: "${subject}".`,
    "Style: clean flat SVG-style vector, crisp edges, no gradients, no shadows, no textures, no lighting effects.",
    "Colors: limited palette, high contrast, modern minimal. Black, white, and primary colors only.",
    "Composition: centered subject with generous whitespace, 1:1 icon framing.",
    "Background: pure solid white (#FFFFFF) and completely filled. Nothing around the logo.",
    "No transparency. No checkerboard. No grid. No background elements.",
    "No text. No words. Just a simple image centered in white space."
  ].join("\n");
  return prompt;
}
</code></pre>
<h3 id="environment-setup">Environment Setup</h3>
<p>Set your OpenAI API key</p>
<pre><code class="language-bash">export OPENAI_API_KEY="your-api-key-here"
</code></pre>
<p>Without this key the build just skips image generation with a warning.</p>
<hr>
<h1 id="outstanding-problem">Outstanding Problem</h1>
<p>Dalle-3 is super frustrating when it comes to just making a white background. I spent a couple hours trying different prompts and it just refuses. Here's what the code came up with as a prompt for this page:</p>
<pre><code class="language-text">Simple minimalist flat vector icon.
Subject: "A simple logo featuring a stylized laptop and a paintbrush, symbolizing effortless content creation and automated design.".                     
Style: clean flat SVG-style vector, crisp edges, no gradients, no shadows, no textures, no lighting effects.                                                                                                
Colors: limited palette, high contrast, modern minimal. Black, white, and primary colors only.   
Composition: centered subject with generous whitespace, 1:1 icon framing.                             
Background: pure solid white (#FFFFFF) and completely filled. Nothing around the logo.                
No transparency. No checkerboard. No grid. No background elements.                                    
No text. No words. Just a simple image centered in white space. 
</code></pre>
<p>It does not seem to care for my preference. If anyone has any tricks for this I'd love to hear about it.</p>


<h1 id="aside-leveraging-ai-for-blog-content">(Aside) Leveraging AI for Blog Content</h1>
<p>Most of this change was written by Codex, and finished up by Cursor. Cursor did a much better job actually running and fixing the errors in the build. When I joined Super.com, my current employer, I rewrote this entire SSG blog engine from Pelican into React + Next as a learning exercise. I'd been writing production code in Angular for years so it wasn't a big jump. I've picked at this blog over the years, but purely as an engine to keep my skills sharp since I'm a senior leader now and spend most of my days in meetings or planning technical and organizational strategy. This is the first blog post in a long time.</p>
<p>AI wrote the first draft. It was bad. For the code, that was ok. It took some iterating but AI codes well enough now if you hold its hand.</p>
<p>The mermaid chart syntax example in this post is all AI. The actual writing style of AI makes my eyes glaze over and I don't want to subject other people to it, so I rewrote basically all of the actual text. No sense contributing too much towards a dead internet, right?</p>
<p>Have feelings about the idea of AI being used for this sort of thing? I'd love to hear your thoughts. You can find my socials on the about page.</p>
<hr>
<h1 id="how-the-rendering-works">How the rendering works</h1>
<p>Take a look at the <a href="https://github.com/mermaid-js/mermaid">official GitHUb page for Mermaid-JS</a> for more details about mermaid in general. It's really neat and I'm convinced it'll be considered the standard for flow charts for the next while.</p>
<p>The markdown loader still starts by parsing front matter with <a href="https://github.com/jonschlinkert/gray-matter"><code>gray-matter</code></a>, but the Remark pipeline now detects any fenced code block labeled <code>mermaid</code> and rewrites it into HTML with the <code>mermaid</code> class.</p>
<p>It's all pretty simple from there. You can see <code>remarkMermaidToHtml</code> (from <a href="https://github.com/kylep/multi/blob/main/apps/blog/blog/utils/remarkMermaid.js">remarkMermaidToHtml in remarkMermaid.js</a>) is new here:</p>
<pre><code class="language-javascript">	static async getRenderedMarkdownAndProps(rawMarkdown){
		// contentHtml is the rendered markdown, metaData is the front matter as a flat object
		const { data: metaData, content: markdown } = matter(rawMarkdown);
		MarkdownService.#serializeDates(metaData); 
                const result = await remark()
                        .use(remarkGfm)
                        .use(remarkToc, {heading: 'Table of contents'})
                        .use(remarkMermaidToHtml)
                        .use(remarkHtml, { sanitize: false })
                        .process(markdown);
		const contentHtml = result.toString();
		const props = {props: {contentHtml, metaData},};
		return props;
	 };
</code></pre>
<hr>
<h1 id="mermaid-syntax-reference">Mermaid Syntax Reference</h1>
<p>Here's a trivial reference of how to use Mermaid syntax.</p>
<p>I plan to use this reference myself for future content, and may update it with more useful examples in time.</p>
<h2 id="flowchart">Flowchart</h2>
<pre><code class="language-text">graph TD;
  Source[Markdown] --> Remark;
  Remark --> |HTML| Browser;
  Browser --> MermaidRuntime;
  MermaidRuntime --> |SVG| PublishedPost;
</code></pre>
<pre class="mermaid">
graph TD;
  Source[Markdown] --> Remark;
  Remark --> |HTML| Browser;
  Browser --> MermaidRuntime;
  MermaidRuntime --> |SVG| PublishedPost;
</pre>
<h2 id="sequence-diagram">Sequence diagram</h2>
<pre><code class="language-text">sequenceDiagram
  participant Author
  participant Blog
  participant Mermaid
  Author->>Blog: Write markdown with mermaid fences
  Blog->>Mermaid: Request runtime initialization
  Mermaid-->>Blog: Render SVG
  Blog-->>Author: Display diagram
</code></pre>
<pre class="mermaid">
sequenceDiagram
  participant Author
  participant Blog
  participant Mermaid
  Author->>Blog: Write markdown with mermaid fences
  Blog->>Mermaid: Request runtime initialization
  Mermaid-->>Blog: Render SVG
  Blog-->>Author: Display diagram
</pre>
<h2 id="state-diagram">State diagram</h2>
<pre><code class="language-text">stateDiagram-v2
  [*] --> Draft
  Draft --> Review: lint &#x26; build
  Review --> Published: merge
  Published --> Archived
</code></pre>
<pre class="mermaid">
stateDiagram-v2
  [*] --> Draft
  Draft --> Review: lint & build
  Review --> Published: merge
  Published --> Archived
</pre>
<h2 id="class-diagram">Class diagram</h2>
<pre><code class="language-text">classDiagram
  class MarkdownService {
    +getRenderedMarkdownAndProps()
  }
  class BlogPostContentPage {
    +useEffect mermaid bootstrap
  }
  MarkdownService --> BlogPostContentPage : HTML
</code></pre>
<pre class="mermaid">
classDiagram
  class MarkdownService {
    +getRenderedMarkdownAndProps()
  }
  class BlogPostContentPage {
    +useEffect mermaid bootstrap
  }
  MarkdownService --> BlogPostContentPage : HTML
</pre>


<p>When you import a RedHat VM, say from VMWare, to a KVM environment like OpenStack it probably won't boot and instead goes straight to the dracut prompt.</p>
<p>This happens because the ramdisk doesn't have virtio drivers. You need to inject them. Import the volume and attach it to a running Linux server.
Personally I use Ubuntu, but it doesn't matter since you'll <code>chroot</code> in.</p>
<h1 id="steps">Steps</h1>
<h2 id="mount-the-volume">Mount the volume</h2>
<ol>
<li>In your cloud environment, mount the RedHat boot volume to your working Ubuntu (or whatever) machine.</li>
<li>Find the boot and data volumes, and mount them too.</li>
<li>bind-mount your system paths into the root volume's mount point</li>
</ol>
<pre><code class="language-bash">mkdir /mnt/boot /mnt/root
mount &#x3C;boot device> /mnt/boot
mount &#x3C;root device> /mnt/root

for x in sys proc run dev tmp; do mount --bind /$x /mnt/root/$x; done
</code></pre>
<h2 id="use-dracut-to-update-the-initrd-file">Use Dracut to update the initrd file</h2>
<ol>
<li>chroot into the volume</li>
<li>Check <code>/etc/grub/grub.conf</code> to see which initrd file is being used. Something like <code>3.10.0-1062.1.2.el7.x86_64</code>.</li>
<li>check if the drivers are present</li>
<li>install the drivers</li>
<li>confirm they're present</li>
</ol>
<pre><code class="language-bash"># chroot in
cd /mnt
chroot root bash

# set the version
cat /etc/grub/grub.cnf
version=
# example: version=3.10.0-1062.1.2.el7.x86_64

# check for virtio drivers
lsinitrd /boot/initramfs-$version.img | grep virtio

# if not found, add them
cd /boot
dracut -f \
  /boot/initramfs-$version.img \
  $version \
  --add-drivers "virtio virtio_pci virtio_blk virtio_net"

# prove it worked
lsinitrd /boot/initramfs-$version.img | grep virtio

# leave the chroot
exit
</code></pre>
<p>This is a good time to do any other modifications you like, such as installing cloud-init or enabling DHCP.</p>
<h2 id="clean-up">Clean up</h2>
<p>Remove the mounts</p>
<pre><code class="language-bash">for x in sys proc run dev tmp; do umount /mnt/root/$x; done
umount /mnt/root
umount /mnt/boot
</code></pre>
<h2 id="validate">Validate</h2>
<p>Now you should be able to boot your RedHat VM without dracut coming up.</p>


<p>Normally when I need to make a CSR, I would use <code>openssl</code> to generate one like you'll see all over the internet:</p>
<pre><code class="language-bash">openssl req -new -key example.com.key -out example.com.csr
</code></pre>
<p>This generates a CSR and asks you to provide the Common Name (URL) of your site.</p>
<p>Recently I've noticed that certs from the above CSR don't work.
From some research, Chrome's version 58 (2017) is when it changed, so I guess it took me a while to catch on.</p>
<p>Using the CommonName (CN) instead of SubjectAltName (SAN) in your cert was deprecated in RFC 2818 (forever ago).
For a long time for browsers didn't enforce that requirement and could fall back to CN, but it seems like that allows homograph attacks
(fake "a" in apple.com, for instance), where the SAN field somehow does not.</p>
<p>Even if you add and trust the issuing and root CA certs, Chrome will still throw <code>ERR_CERT_COMMON_NAME_INVALID</code>.</p>
<p>Generating a CSR with a SAN is not intuitive. Unless you want to use heredoc, you need to create a file first.</p>
<ul>
<li>The <code>req_distinguished_name</code> values set the prompts during the CSR questionairre.</li>
<li>The DNS.x values are the SAN entries. If you have one URL, then commonName and DNS.1 will match, and you'll have no others (no DNS.2, ect).</li>
</ul>
<p><code>vi san.ini</code></p>
<pre><code>[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext

[ req_distinguished_name ]
C = Country Name (2 letter code)
ST = State or Province Name (full name)
L = Locality Name (eg, city)
O = Organization Name (eg, company)
OU = Organization Unit (eg, IT)
CN = Common Name (server FQDN)

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS.1 =
DNS.2 =
DNS.3 =
</code></pre>
<p>Now with this file and your private key in hand, you can create your CSR:</p>
<pre><code class="language-bash"># Set the name of your domain
domain=
# Generate the private key and CSR
openssl req -new -newkey rsa:2048 -nodes -keyout $domain.key -out $domain.csr -config san.ini
</code></pre>
<p>Check your work:</p>
<pre><code class="language-bash">openssl req -in $domain.csr -noout -text
</code></pre>
<p>That's it. Send the CSR off to the CA admin or whoever carves out your certificates.</p>


<p>Sometimes you want to test a switch's trunk port without having to carve our an access port to plug your MacBook into.</p>
<p>Here's how:</p>
<ol>
<li>Open System Preferences</li>
<li>Click Network</li>
<li>Select your Thunderbolt Ethernet adapter</li>
<li>Click the gear below the sidebar listing the interfaces</li>
<li>Click Manage Virtual Interfaces</li>
<li>Click the + button</li>
<li>New VLAN</li>
<li>Enter a name, such as "VLAN-200"</li>
<li>Enter a VLAN ID in the Tag field, such as 200</li>
<li>Choose Tunderbolt Ethernet for your Interface</li>
<li>Click Create</li>
<li>On the sidebar, your new vlan ("VLAN-200") is now an option. Click it.</li>
<li>Configure as needed.</li>
</ol>


<h1 id="tldr">TL;DR</h1>
<pre><code># replace "import queue" with:
from multiprocessing import Queue as queue
</code></pre>
<hr>
<h1 id="steps-to-fix">Steps to fix</h1>
<p>In Ubuntu 18.04 you'd typically install the openstack CLI client like this:</p>
<pre><code class="language-bash">pip install python-openstackclient
</code></pre>
<p>Sadly, this installs a broken version of the client. If you try and run any command you get a stack trace:</p>
<pre><code class="language-bash">Traceback (most recent call last):
  File "/usr/local/bin/openstack", line 6, in &#x3C;module>
    from openstackclient.shell import main
  File "/usr/local/lib/python2.7/dist-packages/openstackclient/shell.py", line 24, in &#x3C;module>
    from osc_lib import shell
  File "/usr/local/lib/python2.7/dist-packages/osc_lib/shell.py", line 33, in &#x3C;module>
    from osc_lib.cli import client_config as cloud_config
  File "/usr/local/lib/python2.7/dist-packages/osc_lib/cli/client_config.py", line 18, in &#x3C;module>
    from openstack.config import exceptions as sdk_exceptions
  File "/usr/local/lib/python2.7/dist-packages/openstack/__init__.py", line 16, in &#x3C;module>
    import openstack.config
  File "/usr/local/lib/python2.7/dist-packages/openstack/config/__init__.py", line 17, in &#x3C;module>
    from openstack.config.loader import OpenStackConfig  # noqa
  File "/usr/local/lib/python2.7/dist-packages/openstack/config/loader.py", line 33, in &#x3C;module>
    from openstack.config import cloud_region
  File "/usr/local/lib/python2.7/dist-packages/openstack/config/cloud_region.py", line 44, in &#x3C;module>
    from openstack import proxy
  File "/usr/local/lib/python2.7/dist-packages/openstack/proxy.py", line 24, in &#x3C;module>
    from openstack import resource
  File "/usr/local/lib/python2.7/dist-packages/openstack/resource.py", line 49, in &#x3C;module>
    from openstack import utils
  File "/usr/local/lib/python2.7/dist-packages/openstack/utils.py", line 13, in &#x3C;module>
    import queue
ImportError: No module named queue
</code></pre>
<p>To fix it, replace <code>import queue</code> with <code>from multiprocessing import Queue as queue</code> everywhere that it's called.</p>
<p>In my case:</p>
<ul>
<li><code>usr/local/lib/python2.7/dist-packages/openstack/utils.py</code> - line 13</li>
<li><code>/usr/local/lib/python2.7/dist-packages/openstack/cloud/openstackcloud.py</code> - line 14</li>
</ul>


<h1 id="install-kvm">Install KVM</h1>
<p>Install the packages</p>
<pre><code class="language-bash">apt-get install -y qemu-kvm libvirt-bin bridge-utils
</code></pre>
<p>Package notes from <a href="https://help.ubuntu.com/community/KVM/Installation">ubuntu.com</a>:</p>
<ul>
<li>libvirt-bin provides libvirtd which you need to administer qemu and kvm instances using libvirt</li>
<li>qemu-kvm (kvm in Karmic and earlier) is the backend</li>
<li>ubuntu-vm-builder powerful command line tool for building virtual machines</li>
<li>bridge-utils provides a bridge from your network to the virtual machines</li>
</ul>
<p>Add users to groups</p>
<pre><code class="language-bash">adduser `id -un` libvirt
adduser `id -un` kvm
</code></pre>
<p>Verify install</p>
<pre><code class="language-bash">virsh list --all
</code></pre>
<hr>
<h1 id="networking">Networking</h1>
<h2 id="configure-network-bridge">Configure network bridge</h2>
<p>Your network interfaces should be configured with NetPlan right now.
Since bridge-utils is installed, you can use NetPlan to do the rest.</p>
<p>Before doing this, it's a good idea to double-check your IPMI/IDRAC/ILO is working.</p>
<pre><code class="language-yaml"># Example netplan config defining bridge
network:
  version: 2
  renderer: networkd
  ethernets:
    eno1:
      dhcp4: no
    eno2:
      dhcp4: no
  bridges:
    br0:
      interfaces: [eno2]
      addresses: ["10.1.0.14/24"]
      gateway4: 10.1.0.1
      mtu: 1500
      nameservers:
        addresses: ["10.1.0.154"]
      parameters:
        stp: true
        forward-delay: 4
      dhcp4: no
      dhcp6: no
</code></pre>
<hr>
<h1 id="defining-the-vm-using-virt-install">Defining the VM using virt-install</h1>
<p>Install virt-install - it's kind of big, about 160MB</p>
<pre><code class="language-bash">apt-get install -y virtinst
</code></pre>
<h2 id="optional---list-os-variant-options">Optional - list os-variant options</h2>
<pre><code class="language-bash">apt-get install -y libosinfo-bin

osinfo-query os
</code></pre>
<h2 id="create-the-vm">Create the VM</h2>
<ul>
<li><code>--disk bus=</code>: 'ide', 'scsi', 'usb', 'virtio' or 'xen'.</li>
</ul>
<h3 id="booting-from-an-existing-qcow2-image">Booting from an existing qcow2 image</h3>
<pre><code class="language-bash">virt-install \
  --name MyImportedVM \
  --description "Imported virtual machine" \
  --graphics vnc,listen=0.0.0.0 \
  --noautoconsole \  
  --os-type=linux \
  --memory 8192 \
  --vcpus=4 \
  --disk path=/var/lib/libvirt/images/importedVM.qcow2,bus=virtio\
  --boot hd \
  --network bridge:br0,model=virtio
</code></pre>
<h3 id="building-a-new-windows-vm">Building a new Windows VM</h3>
<p>Windows can be difficult on KVM because it doesn't ship with Virtio drivers. Using the non-virtio
disk and network emulation is comparatively slow. Things are made harder because <code>virt-install</code>
doesn't let you use --cdrom twice. To mount two iso files at once (so virtio drivers can be installed),
use the --disk argument with device=cdrom. Also be sure to use bus=ide so Windows can read it before
installing the virtio drivers.</p>
<p>The virtio drivers can be downloaded <a href="https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso">here</a></p>
<pre><code class="language-bash">virt-install \
  --name Server2019 \
  --description "Windows Server 2019 Template" \
  --os-type=windows \
  --memory 8192 \
  --vcpus=4 \
  --disk path=/var/lib/libvirt/images/windows2019.qcow2,bus=virtio,size=30 \
  --disk /var/lib/libvirt/isos/WindowsServer2019StandardCore_1909.iso,device=cdrom,bus=ide \
  --disk /var/lib/libvirt/isos/virtio-win.iso,device=cdrom,bus=ide \
  --graphics vnc,listen=0.0.0.0 \
  --noautoconsole \
  --network bridge=br0,model=virtio
</code></pre>
<ul>
<li>When installing the OS through your VNC viewer, no drives will show up.</li>
<li>Click the "Load Driver" button, and browse to the virtio iso that was mounted.</li>
<li>Expand the <code>viostor</code> folder and choose your OS. Click the <code>amd64</code> subdirectory. Click OK.</li>
<li>RedHat VirtIO SCSI Controller should show up, click Next</li>
<li>Finish the install</li>
</ul>
<p>Once the install finishes the server will turn off.</p>
<p>Edit the server using <code>virsh edit</code> to remove the disk:</p>
<pre><code class="language-bash">virsh edit Server2019
</code></pre>
<p>Choose your editor of choice (vim, obviously), and remove the boot <code>cdrom</code> disk.
Leave the virtio one, you stil need it. It looks like this:</p>
<pre><code class="language-xml">    &#x3C;disk type='file' device='cdrom'>
      &#x3C;driver name='qemu' type='raw'/>
      &#x3C;source file='/var/lib/libvirt/isos/WindowsServer2019StandardCore_1909.iso'/>
      &#x3C;target dev='hda' bus='ide'/>
      &#x3C;readonly/>
      &#x3C;address type='drive' controller='0' bus='0' target='0' unit='0'/>
    &#x3C;/disk>
</code></pre>
<p>Turn it back on using <code>virsh start</code>:</p>
<pre><code class="language-bash">virsh start Server2019
</code></pre>
<h4 id="fix-the-other-drivers">Fix the other drivers</h4>
<p>The storage driver is now installed, but the network driver isn't there.
Since the VM was launched with <code>--network bridge=br0,model=virtio</code>, the VirtIO
driver is required. Not using the virtio NIC leads to some pretty terrible performance.</p>
<p>Log into the server and open up the device manager.
Navigate to "other devices". Right click the question marked network driver
and update the driver. Select your virtio disk and allow searching subdirectories,
it should find the driver and install it for you.</p>
<p>Do the same for the unidentified PCI device, that will install the VirtIO Baloon driver.</p>
<p>The server is now ready to use, or be made into a template. If you intend to use this server
with OpenStack later, consider installing cloud-init from <a href="https://cloudbase.it/cloudbase-init/">cloudbase-init</a>.</p>
<hr>
<h1 id="accessing-the-vm-through-the-console">Accessing the VM through the console</h1>
<p>When defining the VM, <code>--graphics vnc,listen=0.0.0.0</code> was used. This enabled a VNC server underneath the
VM which can be used to connect in. To find the connection details, run <code>virsh vncdisplay</code>, which will show
the port offset of that VM's VNC console.</p>
<pre><code class="language-bash">virsh vncdisplay Server2019
</code></pre>
<p>The output will be something like <code>:0</code> or <code>:1</code>. Add 5900 to that, and that's your listen port.
If you needed to use a different port, <code>--graphics</code> supports a <code>,port=</code> argument.</p>
<hr>
<h1 id="exporting-to-glance">Exporting to Glance</h1>
<p>If you want to use this file in OpenStack Glance next, you need to convert it. It's not intuitive, but the file looks like it's basically a thick-provisioned qcow2 (somehow). Use qemu-img:</p>
<pre><code class="language-bash"># thin provision the volume
qemu-img convert -f qcow2 -O qcow2 &#x3C;boot-vol> &#x3C;new-file.qcow2>
# upload it as an image
openstack image create --container-format bare --disk-format qcow2 --public --file &#x3C;new-file.qcow2> "&#x3C;image name>"
</code></pre>


<h1 id="regular-tcpdump">Regular TCPDUMP</h1>
<p>Since tcpdump is installed by default, it's the first thing to use</p>
<pre><code class="language-bash"># Only listen on one interface
tcpdump -i &#x3C;interface/any>

# Filter to a host
tcpdump 'host &#x3C;ip address/fqdn>'

# filter to a port
tcpdump 'tcp port 5000'

# combine filters
tcpdump '(tcp port 5000 or tcp port 35357) and host 192.168.0.100'

# print packets in ascii (basically always want this)
tcpdump -A

</code></pre>
<h1 id="using-tshark">Using tshark</h1>
<p>Another option is wireshark's command line, tshark:</p>
<pre><code class="language-bash">apt-get install tshark
</code></pre>
<p>Note that tshark is really slow to get started compared to tcpdump, you need to wait a good while
until it says something like "Capturing on 'eno1'"</p>
<pre><code class="language-bash"># show interfaces
tshark -D

# Capture everything from a given source and interface
tshark -i eno1 -Y "ip.src == 10.1.0.76"

# Capture HTTP to and from a given source
tshark -i eno1 -Y "ip.addr == 10.1.0.76 and http"
</code></pre>


<h1 id="install--configure-nfs-server">Install &#x26; Configure NFS Server</h1>
<p>These steps were tested on Ubuntu 18.04.</p>
<pre><code class="language-bash"># Install the NFS server package
apt-get install nfs-kernel-server

# Make a directory to publish
mkdir /nfs

# Set permissions
chown nobody:nogroup /nfs
chmod 777 /nfs
</code></pre>
<p>Configure NFS by writing <code>/etc/exports</code>. In this example I'm allowing access
from anyone on the <code>10.10.0.0/16</code> subnet. This is only secure if you trust that
entire subnet and any systems which might be routed to it.</p>
<pre><code class="language-text">/nfs 10.10.0.0/16(rw,sync,no_subtree_check)
</code></pre>
<p>Apply the changes</p>
<pre><code class="language-bash">exportfs -a
systemctl restart nfs-kernel-server
</code></pre>
<h1 id="nfs-client-setup">NFS client setup</h1>
<pre><code class="language-bash"># Install client software
apt-get install nfs-common

# Create mount point
mkdir /nfs

# Mount the NFS share manually
mount 10.10.10.9:/nfs /nfs
</code></pre>


Kyle Pericak

"It works in my environment"

Categories

Tags