Friday, 10 July 2026

Automating Invoices with OpenClaw: Scripting vs. Autonomous Agents

 

Automating Invoices with OpenClaw: Scripting vs. Autonomous Agents

Automating your business invoices locally is the holy grail of saving time without handing your financial data over to a corporate cloud provider. But when you build an AI assistant to handle your billing, you have to make a foundational choice about its architecture.

Do you want a rigid, highly predictable machine, or do you want an autonomous, conversational agent?

Here is the exact breakdown of the two different paths you can take to automate your invoicing, how the software works in each scenario, and the brutal reality of the hardware required to run them.


Path 1: The Python Pipeline (The Rigid Machine)

In this approach, you use a traditional Python script as the "supervisor" and treat your local AI model (running via Ollama) strictly as a data-processing calculator.

How It Works: Instead of wrestling with messy Google Docs formatting, you set up a clean "Invoice Diary" in Google Sheets. Your workflow looks like this:

  1. The Trigger: A Python script (read_diary.py) uses a free Google Cloud Service Account to securely read your spreadsheet. It scans for a specific trigger, like a capital "X" in the status column.

  2. The AI Handoff: When it finds the "X", Python grabs the client name, service, and amount, and feeds it directly into your local AI model using a simple command-line subprocess call.

  3. The Output: The AI formats a professional, plain-text invoice draft. Python catches that text, saves it as a file, and can even dispatch it via the Gmail API.

The Hardware Requirements: Low & Lean

Because Python is doing all the heavy lifting and routing, the AI model doesn't need to be "smart" enough to use tools or hold a massive instruction manual in its head.

  • VRAM Needed: 4 GB to 6 GB.

  • Why: You can use a hyper-specialized, tiny model (like Qwen 2.5 1.5B or a quantized 8B model). When you only feed the AI a few lines of a spreadsheet and ask for an invoice, the Context Window (KV Cache) remains incredibly small. A cheap Nvidia GTX 1050 Ti (4GB) or GTX 1060 (6GB) will run this pipeline flawlessly at 15 to 25 tokens per second without ever crashing.

Path 2: The OpenClaw Agent (The Autonomous Assistant)

In this approach, you hand the keys over to the OpenClaw framework. Instead of Python hardcoding every step, OpenClaw acts as an intelligent traffic cop, and the AI itself decides when and how to generate the invoice.

How It Works: You give the AI a permanent "brain" by writing custom Skills in your OpenClaw workspace directory.

  1. The Manifest: You create a SKILL.md file. This is a text document injected straight into the AI's prompt that acts as its instruction manual. It tells the AI: "When the user asks to run invoices, use your Google Sheets tool to check the diary, extract the data, and format an email".

  2. The Permissions: A manifest.json file explicitly grants the AI permission to access the network and execute specific tools.

  3. The Execution: You simply type, "david, run the invoice check" into your chat interface. The AI autonomously pulls the spreadsheet data, realizes it needs to draft an invoice, and outputs the final text for your approval.

The Hardware Requirements: Heavy & Expensive

This is where many home builders hit a massive wall. OpenClaw is not a simple chatbot; it is a heavy agentic framework.

  • VRAM Needed: 12 GB to 16 GB (Absolute Minimum).

  • Why: To make the agent autonomous, OpenClaw secretly feeds the model a massive, hidden "System Prompt" filled with JSON schemas, tool definitions, and API instructions. Before you even type "hello", OpenClaw might consume 5,000 to 17,000 tokens of memory.

  • The Context Tax: When the agent scrapes the spreadsheet, that data is added to the pile. To prevent the model's KV Cache from overflowing and "spilling" into your slow system RAM (which crashes your generation speed down to a crawl), you need a massive context window of 32,000 to 64,000 tokens.

  • The Hardware: A 6GB card will instantly throw a "Context Overflow" error. You must upgrade to something like an Nvidia RTX 3060 (12GB) or RTX 4060 Ti (16GB) just to give an 8B model enough breathing room to hold OpenClaw's heavy instructions.

The Final Verdict

If you are on a strict budget and running older 6GB graphics cards, stick to the Python Pipeline. It is bulletproof, cheap, and highly efficient.

If you want the true "Iron Man" experience of chatting with a virtual assistant that can autonomously juggle tools, read spreadsheets, and write emails on command, you must use the OpenClaw Agent—but you must buy a 16GB graphics card to pay the framework's massive memory tax.

Lighting Assessment For Bats

Downwash Analysis

BRE 365 Soakaway

Sizing Your AI: How to Choose the Right Local Model for Your VRAM

Sizing Your AI: How to Choose the Right Local Model for Your VRAM

Running your own AI models locally gives you unparalleled privacy and control, shielding your sensitive business data from corporate cloud filters and 30-day logging traps. However, when you bring AI in-house, your computer's graphics memory (VRAM) becomes the ultimate bottleneck.

Choosing the right model is a delicate balancing act. Here is how to correctly size your local AI to survive the massive memory demands of agent frameworks without bringing your system to a grinding halt. 

I set out to run openclaw on 6GB of VRAM (GTX1060) and although the AI model ran very well on the GTX1060, as soon as I started to use Openclaw the massive context window the agent needs to run became an immediate problem. So in my case openclaw worked (just about) "toolless" with Qwen 3B on 6GB VRAM, but as soon as tools were used, the context window became a big problem. 

Despite being very keen on running locally I actually ended up only getting this all to work with cloud model. . .and I really did try. You need 12GB or more for local openclaw.  This is becuase heavy skills like gog need a massive context window to work well. 

The Magic of 4-Bit Quantization

You might wonder how an 8-billion parameter (8B) model can possibly fit on a standard graphics card. The secret is a compression process called 4-bit quantization.

  • Software engines like Ollama automatically compress the precision of the model's weights to drastically lower the VRAM usage.

  • Through 4-bit quantization, a 7B or 8B model shrinks down to roughly 4.5 GB to 5 GB of storage space.

  • Massive 32B models, which normally require massive server farms, can be compressed down to roughly 20GB, fitting onto high-end consumer cards or older 32GB server cards.

The OpenClaw Context Window Tax

Fitting the compressed model into your graphics card is only half the battle. The most common mistake new builders make is underestimating the "Context Window."

OpenClaw is not a simple chatbot; it is an autonomous agent framework with serious context demands. The context window is the total memory space the AI uses to understand your current task—and OpenClaw fills it incredibly fast.

  • The System Prompt: OpenClaw's baseline system prompt alone can consume 17,000 tokens.

  • The Injections: This baseline context includes the agent's rules, your custom skill instructions (SKILL.md), runtime metadata, and injected workspace files.

  • The Tool Burden: When you use tools (like Google Maps scraping or browser automation), the JSON tool schemas, the tool execution results, and raw scraped web text are all injected directly into the model's current window.

Because of this massive baseline overhead, it is highly recommended to use a context window of at least 64k tokens when running local models to prevent the agent from failing mid-task.

The Overspill and "Amnesia" Problem

When you force a very small model (like an 8B model) to handle OpenClaw's massive context requirements on a budget graphics card, two distinct failures occur:

  1. VRAM Overspill (The Speed Killer): If the combined size of the AI model and its bloated context window exceeds your graphics card's physical VRAM limit, the system does not crash. Instead, it gracefully "spills over" the excess memory burden into your slower motherboard system RAM. When this happens, processing speed can plummet from a snappy 40 tokens per second down to an unusable 2 tokens per second. (On an old PC the system becomes unusable)

  2. Context Truncation (The Amnesia Bug): Small graphics cards often truncate the context window when they run out of room, leading to severe "amnesia" during multi-step tasks.

  3. Cognitive Overload: Even if an 3B model technically loads on a 16GB machine, asking it to process OpenClaw's complex system rules alongside massive tool data often overwhelms it. It will frequently hallucinate tool calls, produce malformed JSON, and loop endlessly on tasks that a larger model handles in a single pass.

Matching the Model to Your Hardware

To survive the OpenClaw context tax without overspilling, you must size your hardware and models realistically:

The 16GB RAM / 8GB VRAM Tier (The Budget Setup)

  • Best Models: Qwen3:8B or Gemma 4 8B.

  • The Reality: Well-suited for light tasks like simple email drafts or basic file management. However, expect occasional failures, JSON errors, and context drift on complex multi-step chains due to the framework's heavy context tax.

The 32GB RAM / 24GB+ VRAM Tier (The Production Sweet Spot)

  • Best Models: Devstral-Small-2-24B or Qwen3-Coder:32B.

  • The Reality: This is the community consensus for reliable production use. A 32GB VRAM setup provides ample room to house a smart 24B–32B model while leaving a massive, dedicated memory buffer (4–6GB) purely for the KV cache to handle a 65K context window.

When sizing your AI for agent frameworks, you aren't just making room for the model's brain—you must leave massive real estate open for its memory.

Lighting Assessment For Bats

Downwash Analysis

BRE 365 Soakaway

Retrofitting Vintage Workstations for Local AI: The Hidden Traps

Retrofitting Vintage Workstations for Local AI: The Hidden Traps

This was research collected in the early days of trying to build a local AI model. You can run some decent models locally:

  • Qwen 3b
  • Ministral 8b 
  • Ministral 3b 
These all worked well in direct chats. BUT using any of the above models with Openclaw. . . well that was problematic because of the "context window" and the amount of VRAM that requires. 

So purley from local AI (without openclaw) the below holds true: 

Repurposing a vintage enterprise server—like the classic HP xw6600—to run local AI models feels like the ultimate budget hack. With open-source tools like Ollama and OpenClaw making local AI highly accessible, slotting a cheap, high-VRAM graphics card into an old workstation seems like a no-brainer.

However, blending 2008 motherboard architecture with modern artificial intelligence hardware is a minefield. If you are building a home AI lab, here are the hidden traps you need to avoid so you do not accidentally fry your hardware—or your patience.

Trap 1: The PCIe Power Supply Bottleneck

Vintage enterprise workstations were built with highly specific, fixed power supplies. For example, the HP xw6600’s 650W power supply often ships with only a single 6-pin PCIe power cable.

  • The Overload Risk: Modern consumer GPUs and heavy server cards often require 8-pin connectors and draw well over 150 Watts. Using a cheap "6-pin to 8-pin" adapter forces a wire legally rated for 75W to carry double its limit, creating a  short-circuit and fire risk.

  • The Tesla Server Card Quirk: Enterprise cards like the Nvidia Tesla M10 (which boasts 32GB of VRAM) are incredibly tempting for AI builders. However, the 8-pin socket on a Tesla card is actually wired internally as a CPU (EPS) socket. The 12-volt and ground wires are reversed compared to consumer graphics cards. Plugging a standard PCIe power cable into a Tesla M10 will instantly short-circuit and permanently destroy the GPU.. . . ALSO cooling these sever cards (which dont have fans) is a real pain in the neck. 

Trap 2: The Firmware  (Legacy BIOS vs. UEFI)

When faced with power cable limitations, a logical pivot is to buy a highly efficient modern card—like the Nvidia RTX 3050 6GB—which draws only 70 Watts and requires absolutely zero power cables.

Unfortunately, this triggers a massive low-level software conflict.

  • The Language Barrier: Vintage motherboards from the 2008 era operate on a "Legacy BIOS" system. Modern graphics cards (like the RTX 30-series) completely dropped support for legacy systems and strictly require a modern "UEFI BIOS" to initialize.

  • The Result: If you slot a modern UEFI card into a Legacy motherboard, the computer will simply beep a hardware error code and give you a permanent black screen. The 2008 motherboard literally does not know how to speak to the 2024 graphics card firmware.

The Safe Hardware Solution

To successfully retrofit a vintage PC for local AI, you need a graphics card that speaks the old "Legacy BIOS" language while respecting your physical power constraints. The Nvidia GTX 10-series (built on the Pascal architecture) is the ultimate sweet spot.

Here is how to safely power them based on your workstation's wiring:

Power Cables AvailableRecommended GPUSafe Adapter Strategy
One 6-pin cableNvidia GTX 1060 (6GB)

Plug directly in (no adapters needed).

Two 6-pin cablesNvidia GTX 1070 or 1080

Use a "Dual 6-pin to 8-pin" adapter to safely combine two 75W loads.

A Pro-Tip for HP Owners: Enterprise machines are tightly packed. Even if you only see one 6-pin cable, check behind your hard drive cages or zip-tied to the main wiring harness. The xw6600 was often manufactured with two 6-pin cables tucked away.

Building a local AI server out of vintage parts is entirely possible, but success relies on respecting the electrical and firmware limits of the era. Stick to legacy-compatible cards, never overload your wiring, and you will have a stable, offline AI assistant running in no time.

Disclaimer: Don't do any of this. 

Lighting Assessment For Bats

Downwash Analysis

BRE 365 Soakaway

Wednesday, 11 March 2026

Buying a Car with Cinch - Not So Great . . .

 

Cinch: Slick Interface, Shady Service? My 30-Year Auto Trader Streak Ends in a "Faff"

For nearly 30 years, I’ve used Auto Trader to buy my cars. It’s always been a reasonably straightforward process, even if the quality of the cars has varied dramatically. There’s something grounded about supporting a local small business—even if it means turning up to a scrap of industrial land on the outskirts of town to drink instant coffee while poring over old service records.

This time, with my current car broken and my travel options limited, I needed something local. I set my criteria to a 50-mile radius and found what looked like a great deal: a car advertised just 16 miles away. The purchase started through a company called Cinch using a "slick and easy" online interface. You fill out the paperwork in the comfort of your own home instead of a dingy porter cabin.


The 240-Mile "Local" Car

The "slick" process hit a wall the moment the paperwork was done. Suddenly, I discovered the car wasn't 16 miles away in Taunton; it was actually in Corby, 240 miles away. To make matters worse, they wanted to charge an extra £300 to pick it up from where they said it was in the first place.

"This is all starting to sound a bit fishy... but you can't really pull out because if you're buying with finance, you've already run your credit check and you can't run lots of those and expect to keep getting approvals."

I spoke to a representative who admitted the 16-mile advertisement was "a bit misleading" and suggested I just buy the car and they would refund the transfer fee. Spoiler alert: they eventually refused to refund that money, which I believe is a breach of consumer law and advertising guidelines.



A "Luxury" Dacia and a Missing History

I eventually went to Avonmouth to pick up the car. Despite receiving numerous emails saying it was ready, it was actually locked in a compound they didn't have control over. I had to wait around for quite a while just to get my hands on it. This wasn't the staff's fault at Avonmouth they worked really hard to correct cinch's mistake. 

The car itself—a Dacia—actually feels like "absolute luxury" compared to my old Skoda. It’s smooth as butter, but it came with zero service history. For the most expensive car I've ever bought, I was miffed to find nothing but a vague piece of paper from a BAC fleet solution company with unchecked boxes for oil levels and tire torque.

When I challenged customer service, the representative constantly talked over me, claiming their status as an "online retailer" meant they couldn't possibly put accurate locations on Auto Trader because they use regional hubs. It’s warped logic.


The Verdict: Would I recommend Cinch?

No. While I think I got lucky with a decent car, their quality checks feel "mythical" or creative at best, and their sales practices are deceptive. I feel like I’ve betrayed the genuine local sellers who actually provide information when asked. Next time, I’m going back to the local guys.

It not just me that has had this experience. Check out there google maps listing at their head office. 

Friday, 13 February 2026

Can You Solder a Network Cable?

 

Can You Solder a Network Cable? 

Every DIY tech project starts with a simple goal. Mine was a 100-metre run of Cat6 cable to connect my office to the router. On paper, it’s a standard job. In reality, it became a week-long masterclass in why "the right way" isn't always the best way for your specific setup.

The "Illegal" Win: Soldering Ethernet

When the open reach team chopped the factory fitted ned off of my cable, I didn't reach for a crimping tool. I reached for a soldering iron. To any network engineer, soldering a twisted-pair data cable is heresy. They’ll tell you about signal reflections, impedance mismatches, and cross-talk. An AI query informed me that the solder was a "brick wall" to the signal. 

But here is the fact: It worked. With a steady hand and some insulation tape, that soldered "bodge" delivered a stable 300 Mbps. For my needs, it was a total victory. I had a working solution that respected my existing skills and got the job done.

The Perfection Trap

Then came the trap we all fall into: The "Proper" Fix. The internet (and helpful AI assistants) will tell you that you are "leaving performance on the table" if you don't use standard RJ45 crimps. So, I cut my beautiful solder joints. I spent hours wrestling with stiff, solid-core copper wire, lining up microscopic strands into clear plastic plugs.

The result? The tester showed all green lights, but the actual performance collapsed. The connection became slower and less reliable than the solder joint it replaced.

Lesson learned: Value doesn't come from hitting a theoretical maximum; it comes from utility. If a 300 Mbps "bodge" does everything you need, chasing 900 Mbps at the cost of your sanity is a bad trade.

The Final Verdict: For a 100m run on solid-core cable, save yourself the hours of crimping. If you want a "proper" fix that actually works for novices, use a Punch-Down Junction Box. It’s the middle ground between the "shunned" solder and the "fiddly" crimp.

Sometimes, the best solution isn't the one that's "best" on a datasheet—it's the one that lets you get back to work.

Flood Risk Assessment London 

AI Queries Causing System to Hang

 

AI Queries Causing System to Hang: How I Tamed My Workstation's Audio Pops

If you're like me, running a beloved, powerful, but aging workstation – in my case, an HP xw8400 with dual Intel Xeon E5345 CPUs and dual NVIDIA NVS 300 graphics cards on Windows 7 – you know the struggle. This machine is a beast for certain tasks, but it has its quirks, especially when it comes to real-time audio.

Recently, I hit a wall: every time I performed an AI query in my browser (Supermium, in this case), my audio would suffer from frustrating clicks and pops. It felt like the system was "hanging" for a split second, causing those dreaded buffer underruns. This wasn't just annoying; it was crippling my ability to work efficiently.

The Problem: LatencyMon Revealed the Culprit

My first step was to fire up LatencyMon, the go-to tool for diagnosing audio dropouts. The results were stark:

  • Massive DPC Latency Spikes: nvlddmkm.sys (the NVIDIA Windows Kernel Mode Driver) was consistently hitting peaks of 30,000 microseconds (µs) during AI queries. Anything over 1,000-2,000 µs is problematic for audio, so 30,000 µs was a red flag the size of a billboard.

  • Hard Pagefaults: My system was also drowning in 22,000 hard pagefaults, indicating that the system was constantly scrambling for data on the slow hard drive. This was primarily caused by psanhost.exe (Panda Antivirus), which I quickly realised was simply too heavy for my setup.

The Journey: Initial Tweaks (and Why They Didn't Fully Work)

I started with the usual suspects, guided by some excellent advice:

  1. NVIDIA Control Panel - Usage Mode: Graphics Only: This was a good first step, preventing the GPUs from trying to act as compute devices. It helped, but the massive spikes remained.

  2. Disabled Hardware Acceleration in Browser: Ensured Supermium wasn't trying to offload too much to the GPU. Again, helpful, but not the silver bullet.

  3. Power Options: High Performance: Kept my Xeons running at full speed.

  4. Task Scheduler & Services Cleanup: Removed any lurking NVIDIA background tasks.

  5. Disabled NVIDIA HD Audio: Prevented audio conflicts.

  6. Texture Filtering - Negative LOD Bias: Clamp: Reduced unnecessary GPU sharpening.

  7. Multi-display/mixed-GPU acceleration: Single Display Performance Mode: Simplified how the driver handled my four monitors.

  8. Threaded Optimisation: Off: Stopped the driver from scattering work across my 8 CPU cores.

While these steps collectively improved the system's responsiveness and reduced some background noise, the crucial nvlddmkm.sys DPC spikes during those AI queries persisted. The 30,000 µs monster was still there.

The Breakthrough: Maximum Pre-rendered Frames to "1"

After all those tweaks, the final, most impactful change came down to a single setting in the NVIDIA Control Panel:

Maximum Pre-rendered Frames: Set to 1

This seemingly small adjustment was the key to unlocking real-time performance on my vintage workstation.

Why "Maximum Pre-rendered Frames = 1" Fixed It:

  • Stopping the CPU from "Looking Ahead": By default, the NVIDIA driver tries to prepare multiple frames (often 3 or more) in advance to ensure smooth visuals. On a modern system, this is fine. On my xw8400, feeding two NVS 300 cards from a Front Side Bus (FSB), this "pre-rendering" was causing the CPU to get utterly swamped with graphics tasks. It was constantly buffering frames, delaying critical audio data.

  • Clearing the System Bus: When an AI query rapidly streams text and updates the screen, it demands a continuous flow of new frames. With a buffer of 3, the CPU was frantically trying to keep up, creating a massive traffic jam on the system bus. Setting it to 1 forces the CPU to prepare just one frame at a time, send it, and immediately move on. This dramatically reduces the amount of time nvlddmkm.sys holds onto the CPU, allowing the audio stream to flow uninterrupted.

  • The AI Query Trigger: The dynamic, text-streaming nature of AI interfaces specifically exposed this bottleneck. Each word appearing on screen triggered the intensive frame pre-rendering, leading directly to the clicks.

The Result: Silence at Last

After applying this change, the difference was immediate and profound. AI queries now run smoothly, the text streams without a hitch, and most importantly, the audio clicks and pops are gone! LatencyMon now shows nvlddmkm.sys behaving itself, with peak DPC times well within acceptable limits.

It turns out, for legacy hardware like the HP xw8400, the less "smart" your graphics driver tries to be with buffering and multi-threading, the better for real-time audio. Sometimes, the simplest solution is the most effective.

If you're battling similar audio latency issues on your older workstation, especially with NVIDIA cards, give that Maximum Pre-rendered Frames = 1 setting a try. It might just save your sanity!

Flood Risk Reports