At some point the token consumption stopped matching my gut feeling of what I’d actually been doing that week. Nothing was broken. Nothing errored. Everything worked. It just cost more than it should have.

So I decided to take a deeper look at how Claude Code actually picks the model for a subagent. It turned out the pin I’d been trusting sits in the one layer you shouldn’t trust.

Disclaimer: This is what I run on my own machine, on my own projects. Hooks can block your own dispatches, that’s the whole point of this one, so if you wire it up wrong you’ll be staring at a blocked Task call and wondering why. Also, precedence behaviour in Claude Code changes between releases. Verify against the version you’re on.

Why you want subagents in the first place

Before the complaining starts, let me be clear about one thing: subagents are good. This post is not an argument against them, it’s an argument for pinning them properly.

The reason to use one isn’t that it’s a smaller model. It’s that it runs in its own context window. It goes off, does something loud and messy, and hands back a short answer. The noise never lands in your main session. You get the three lines that matter instead of the four megabytes they came from.

Which means the ideal subagent job looks like this: fetch a lot, filter, return a little. And that job needs a model that is obedient, not brilliant. Something like Sonnet does it all day. Running it on Fable or Opus 5 is paying frontier prices for grep with good manners.

My list of agents that should never touch a frontier model:

• AWS, especially CloudWatch Logs. A log query for one request ID returns an ocean. You want the stack trace and the timestamp. This one alone justifies the whole pattern.
• GitHub. Issues, PR diffs, CI status, “which commit touched this file”. Long output, small answer.
• Honeybadger. Error occurrences, backtraces, “is this the same bug as last Tuesday”. Structured input, structured output.
• Langfuse. Trace dumps are enormous and 95% of every trace is irrelevant to the question you’re asking about it.
• Static analysis: RubyCritic, RuboCop and friends. The report is a hundred pages, the actionable part is nine lines.
• Test runners. You do not need Fable to look at RSpec output and tell you which four specs are red. You need something that can read.

Pinning one looks like this, in .claude/agents/cloudwatch-digger.md:

---
name: cloudwatch-digger
description: Queries CloudWatch Logs and returns only the relevant lines
model: sonnet
tools: Bash, Read
---

One line. model: sonnet. That’s the whole pin, and that’s exactly why it hurts when it silently stops working. The agents you bother to pin are, by definition, the ones you dispatch most often and look at least.

The first uncomfortable thing

Claude Code resolves which model a subagent runs on in this order:

Four layers. And the one that everybody actually uses, the frontmatter pin, because it’s the one that’s documented, obvious and writable once, is rank 3 of 4.

That would be fine if rank 3 always held. It doesn’t. Across several releases the frontmatter layer has silently dropped out, and pinned agents fell straight through to rank 4: the session model. Which in my case is Fable.

So the cheap little agent you dispatch two hundred times a day quietly runs on the most expensive thing you have. And here’s the part I find genuinely annoying: there is no signal. No error, no warning, nothing in the transcript that looks different. The agent does its job. It just does it at a multiple of the price.

A crash is polite, it tells you. This doesn’t tell you anything. It shows up four weeks later as a number.

Recognising the pattern

I wasn’t the first one to run into this. There’s a whole class of upstream reports about frontmatter pins being ignored after an update, and the workaround people keep confirming is always the same: pass the model explicitly on the dispatch. That’s rank 2, one layer above frontmatter, and rank 2 has never been the layer that breaks.

Big shoutout to everyone who bothered to file those issues with reproductions. Silent cost regressions are exactly the kind of bug nobody files, because nobody notices.

Which leaves an obvious problem: “just always pass the model explicitly” means the orchestrator has to remember it, every single time, forever. An orchestrator that reliably remembers a thing forever is not something I’ve met.

So don’t remember. Enforce.

Phase 1: A PreToolUse hook

PreToolUse runs before a tool call goes through and can block it with exit code 2. So: if a subagent is pinned in its frontmatter, and the dispatch carries no explicit model, refuse the dispatch and say exactly what to re-send.

These few lines of code can save you a lot of tokens, because they remind Claude Code to use the model you actually chose for your subagents.

.claude/hooks/enforce-subagent-model.sh:

#!/bin/bash
{ read -r T; read -r S; read -r M; } < <(jq -r '.tool_name//"",.tool_input.subagent_type//"",.tool_input.model//""')
case $T in Task|Agent) ;; *) exit 0;; esac
[ -n "$S" ] && [ -z "$M" ] || exit 0
P=$(awk '{sub(/\r$/,"")} NR==1&&$0=="---"{f=1;next} f&&$0=="---"{exit} f&&/^model:[ \t]/{gsub(/["'"'"']/,"",$2);print $2;exit}' \
     "${CLAUDE_PROJECT_DIR:-.}/.claude/agents/$S.md" 2>/dev/null)
case $P in ""|inherit) exit 0;; esac
echo "BLOCKED: '$S' is pinned (model: $P) but this dispatch has no explicit 'model'. Re-dispatch with model: \"$P\". A deliberate different model also passes, but it must be explicit." >&2
exit 2

Nine lines. jq reads the hook payload from stdin, awk reads the pin out of the agent’s frontmatter, and the message on stderr goes back to Claude Code, which then re-dispatches correctly on its own.

Don’t forget:

chmod +x .claude/hooks/enforce-subagent-model.sh

Phase 2: Wiring it up

In .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Task",
        "hooks": [
          { "type": "command", "command": "$CLAUDE_PROJECT_DIR/.claude/hooks/enforce-subagent-model.sh" }
        ]
      }
    ]
  }
}

Test it by dispatching a pinned agent without a model. You should get the BLOCKED message, and the very next dispatch should carry the pin.

What it lets through, on purpose

The interesting part of a guardrail is its exceptions:

• Any dispatch that carries an explicit model, even a different one. What I’m guarding against is omission, not choice. If I deliberately send a small agent to a big model, that’s a decision, and decisions are allowed. Falling into a model by accident is not.
• Unpinned agents. model: inherit or no model key at all means inheritance is the intent. Fine, pass.
• Built-in types (Explore, Plan, general-purpose, …). No file in .claude/agents, nothing pinned, nothing to enforce.
• Anything unparseable. If jq can’t read the payload, all three variables come back empty and the hook exits 0.

That last one is deliberate: this is a cost guardrail, not a security boundary. A hook that fails closed on a payload it doesn’t understand will eventually wedge a session at the worst possible moment, and then I’ll disable it, and then I’ll be back where I started.

An empty or null model, by the way, is not treated as a choice. It falls straight through to frontmatter, the exact layer under suspicion, so it gets gated like an absent one.

One thing to know

Workflow-tool internal agent() spawns don’t go through PreToolUse. The hook covers Task and Agent dispatches only. Anything spawned inside a workflow tool sails right past it. I cover those with prose in my reference docs instead, which is a nice way of saying they’re not covered. Know where your gate ends.

That’s it

If you’re running Claude Code on Fable or Opus 5 and your token graph looks steeper than your week felt, check your pinned agents before you check anything else. Everything that’s supposed to be cheap is worth verifying, because the failure mode here doesn’t announce itself. It just quietly bills you.

And if you’re not using subagents at all yet, that’s a whole other topic, and honestly a bigger one than this post. Let me know if you’d like to read it and I’ll write it up.

If you find a cleaner way to close the workflow-tool gap, let me know as well!

So when my dentist celebrates on LinkedIn that Fable 5 got re-enabled and can’t wait to burn tokens again, I have to ask myself: is this a warning of how much broken software we will have to debug over the next decade? History is repeating itself here.

There is an old saying: if you give a fool a faster tool, all you get is a faster fool.

I see this pattern all the time. It’s not just the dentist who wants to get rid of his old patient management software. It’s CEOs of well-funded late-stage startups and private equity fund managers who suddenly decide that building a CRM is their core business. Marketing agencies start building iOS apps.

The main problem here is IMHO the false advertising by the frontier model providers. The perceived message is: “Everyone can code”.

Sure, if you have decades of experience in building software, Claude Code and Codex are massively powerful tools which can give you that 10x boost. I can confirm this for myself in my daily work.

But after years at the forefront of AI development, trying basically every new tool and model and testing them as thoroughly as possible, my personal conclusion is: we are not there.

Yes, AI can easily build over 90% of your code. That’s exactly what we are doing at Vendis.ai while building our AI-first CRM. BUT: the amount of internal tooling needed to steer these models in the right direction (Rules, Subagents, Skills, Configuration, Orchestration, etc.), plus the amount of manual review required to stop the coding agent from producing simply terrible software, is still remarkable. And that’s despite using a very well-organized, opinionated framework: Ruby on Rails. Every developer at Vendis has 25+ years of coding experience, and right now, that experience is simply not replaceable.

Will we get there at some point, through AGI or simply incrementally improved models? Very likely. As usual, people tend to overestimate the short-term effects of technology and underestimate the long-term effects.

The problem isn’t just the terribly unmaintainable, untested code (my prediction: software agencies and service providers will have a blast cleaning up this mess over the next years). It’s also security. Under EU law at least, you have to report data breaches and hacking attacks to the authorities. Let’s see what happens when these builders have to do that for the first time, because some Russian or North Korea ransomware group knew better how to turn frontier models into money.

At least it’s maybe just a question of time when your patient records will be available on the internet, because access controls have been only implemented client-side (FIFA, anyone?)

The even bigger problem is Day 2: operations. Ask these people how they actually run their software, and they just follow whatever Claude tells them. “Here is your deployment to Vercel.” Done.

Obviously, this results in a nightmare, from simple things like database backups all the way to security bugs. If you are lucky, Claude MIGHT tell you when to upgrade that CVE’d npm package. Or not. Or there is a privilege escalation hiding in the code. Or there are simply no tests.

Can a frontier model find these issues? Likely. But if you don’t ask the right questions, it won’t.

Interestingly, all of this reminds me of how I started my life in software, with my first company, founded in the late 90s, doing B2B software. Every potential customer we visited had proprietary Lotus Notes apps. Lotus Notes was the n8n/Lovable of the 80s and 90s. Most people today won’t remember, but I do, vividly. Lotus Notes was revolutionary. It combined databases, forms, workflows, replication, and email in one product. Business users could build applications with surprisingly little programming. It was a low-code dream that slowly but surely turned into an IT nightmare.

Those NSF databases were completely proprietary and mixed Formula language, LotusScript, and Java. Business logic often lived inside forms. Nothing was tested. There was very little architectural separation. And developers frequently left without documentation.

Employees with almost no coding experience created these apps, and the apps became centerpieces of the business. But they were usually totally unmaintainable, had a completely proprietary data model, were compatible only with themselves, and were very, very hard to modernize. Many Fortune 500 companies still run Notes applications written 20 to 30 years ago because replacing them is too risky.

While companies realized their legacy problem and paid literally millions of dollars to get rid of that Lotus Notes nonsense, the next hail-mary options were already appearing on the horizon: Visual Basic, PowerBuilder (still popular in many banks), ActiveX, Java applets, Silverlight, and Flash. Anyone? Or MS Access, Oracle Forms, Delphi, and the like.

Those technologies made sure that software consultants didn’t run out of work for the next 15 years, cleaning up this mess. If Steve Jobs hadn’t rejected Flash for iOS, I am sure we would still have to deal with that nonsense today (the price: thousands of applications required complete rewrites). Same for ActiveX: many corporate intranets depended entirely on it until browsers killed support, even Microsoft themselves.

And while they were still cleaning up, the next wave was already rolling. This time, everything would be so much easier: SharePoint customizations were the rising stars, with custom Web Parts, workflows, and InfoPath forms. XML everywhere, with hidden business rules. What can go wrong? The result: yet another unmaintainable data silo, and each SharePoint upgrade became a migration project. Organizations still struggle to migrate legacy InfoPath forms today.

These technologies often shared the same traits:

• They optimized for rapid initial delivery rather than long-term evolution.
• They blurred the boundaries between UI, business logic, data access, and workflow.
• They made automated testing and continuous integration difficult.
• They encouraged drag-and-drop development or code generation, producing artifacts that were hard to review and refactor.
• They embedded business rules in visual designers, event handlers, or metadata instead of explicit, version-controlled code.

Today, we see those patterns resurface with exactly the same problems. Those 800-node n8n workflows, putting the whole company to autopilot, built by the company champion “who really gets AI”. Wait until that person leaves.

AI-generated code without review takes this to another level. Same pattern: fast initial velocity, but inconsistent logic and architecture, and gigantic maintenance costs.

Small businesses celebrate what they can build with a $200 Claude subscription, only to amass legacy software that will cost tens or hundreds of thousands of dollars to clean up.

And the startup CEO who dedicates two developers to building a CRM (see what happens when they leave) is basically betting at least $300k in developer salaries against a $100k CRM subscription.

That’s why I think BTW that SaaS standard software isn’t dead, as long as you are a system of record. Or in AI word: System of action as we call it at Vendis.ai.

While I can totally understand the fascination, but if you decide to build a core system (CRM, CMS, ERP, HR software, etc.) yourself, in 99.9% of all cases you are making a terrible mistake.

The underlying lesson has remained consistent for decades: the technologies that produce the most technical debt are rarely the ones that are “bad”. They are usually the ones that make it exceptionally easy to create software before there is enough discipline around architecture, testing, modularity, and ownership. Their productivity gains are real, but they often defer complexity rather than eliminate it.

Building a prototype to show your developers or consultants how it should feel like? Customizing standard software to your needs through new interfaces like MCP? Building a quick internal integration for a data migration between two legacy systems? Sure thing, that’s where Claude really shines.

But building, deploying, and maintaining a secure and stable core application without any clue about software development and architecture? I am not so sure, at least for the next few years.

Better to ask somebody who knows how to do that. Or just pay that SaaS company.

Just like I don’t ask ChatGPT how to drill and repair my teeth.

Instead, the ISP (in my case, Cyta) hands you a box you never asked for. In my case a Huawei OptiXStar HG8245X6-10 GPON terminal, but they’re all the same idea: a mandatory middleman wedged between the fiber and your network. It burns power around the clock, needs configuring, is a closed box you don’t control and its only real job is to bridge packets. And it’s now your single point of failure - when that box dies, your whole internet goes down with it, no matter how many shadow modes or power backups you’ve installed.

The good news: you can throw it out entirely. A ~60 EUR GPON SFP stick plugs straight into the UDM’s SFP+ WAN port, registers on the GPON network pretending to be your old ONT, and lets the UDM run the PPPoE session itself. One box instead of two, full control, and one less thing blinking in the rack.

This took me a while to get right, and I owe the breakthrough to two people on Reddit - @Dm3Ch and @JopoSran4ik_01 posting on this thread.

Below is the complete walkthrough. I run a UDM Beast myself, but it’s the same on a UDM Pro - or any UDM with an SFP WAN cage. The exact values I show - VLAN 42, the serial format, the PPPoE login - are from my own ISP configuration; yours will likely differ, but the procedure in general is identical for any GPON ISP.

Disclaimer: This is what I did with my own line and my own hardware. Cloning your ONT’s identity onto a third-party stick is squarely your responsibility - check that it’s allowed under your contract, and if you brick something or knock yourself offline, that’s on you. Keep the Huawei around until everything works.

What you’ll need

• A UniFi gateway with a free SFP/SFP+ WAN port and SSH access - that SFP port is the only hard requirement; the exact model doesn’t matter
• The FS.com GPON SFP stick - exact model below
• Your Huawei’s GPON serial number (off the sticker on the back)
• Your fiber line switched to bridge mode (in my case, a quick call to your ISP)
• A few minutes of comfort on the command line

Before you start: get your line into bridge mode

You need bridged PPPoE on the right VLAN (it’s 42 on my line), meaning your router runs the PPPoE session, not the ISP’s box. So call your ISP (or use their chat) and ask them to switch your line to bridge mode.

If your terminal already runs in bridge/passthrough, you’re ready. If it currently works as a normal router doing PPPoE itself, you need that change before any of the following will work.

Step 1: Find your Huawei’s GPON serial number

Read the sticker on the Huawei - you need its GPON/ONT serial. This is the single most important value in the whole process, because the stick has to present exactly this identity to the network.

A little background, because it explains why the serial can look like two completely different strings:

Background: A GPON serial is 8 bytes total - a 4-byte vendor ID in ASCII, followed by a 4-byte device part in hex. Huawei’s vendor ID is HWTC, which in hex is 48 57 54 43. So a Huawei GPON SN always shows up in one of two encodings:

a) HWTC + 8 hex chars, e.g. HWTCxxxxxxxx b) the exact same value fully in hex: 48575443 + 8 hex chars, e.g. 48575443xxxxxxxx

Depending on the manufacturer, it might be printed one of those two ways:

• If it already reads HWTCxxxxxxxx, that is your GPON SN - use it as-is.
• If it reads 48575443xxxxxxxx, the leading 48575443 is just ASCII for HWTC. Mentally swap it back: 48575443 → HWTC, keep the remaining 8 hex chars, and you have your HWTCxxxxxxxx serial.

From here on I’ll refer to it as HWTCxxxxxxxx.

Step 2: Buy the right SFP stick

Buy exactly this stick from FS.com - not a generic lookalike, this specific one with the web GUI:

• GPON-SFP-ONT-MAC-I, SKU 351553, ~60 EUR
• Generic Compatible GPON ONU SFP Class B+ Ind Web GUI
• https://www.fs.com/products/351553.html

The “MAC-I” / Web GUI variant matters: it lets you set the ONT serial, MAC and vendor ID, both over SSH and through a small web console. That’s the whole trick.

Step 3: Find the stick on your UDM

Plug the FS stick into the SFP port of your UDM’s WAN. It should show up in the Port Manager with its MAC - but you need the interface name the UDM uses internally, so SSH is the reliable way.

SSH into the UDM (you may need to enable SSH first in the UniFi settings), then list the links and look for the matching MAC:

ip -br link

Find the line whose MAC matches the stick. If you’re not sure which one it is, run ip monitor link and plug/unplug the stick a couple of times - the interface that appears and disappears is the one.

In my case the stick sat in port 13, which the UDM exposes as eth12 - so port 13 = dev eth12. Yours may differ; substitute your interface name wherever I write eth12 below.

Step 4: Reach and log into the stick

The has a default IP: 192.168.101.1. To connect to it, give your UDM an address on that subnet, pointed at the stick’s interface:

ip addr add 192.168.101.2/24 dev eth12

Now check you can reach it:

ping -c 3 -I 192.168.101.2 192.168.101.1

If the pings come back, SSH onto the stick (password: root):

ssh root@192.168.101.1

If that works - congrats, you’re on the stick. Check its current identity and GPON status:

gccli sys sn; gccli sys mac; gccli sys vendorid; gccli gpon state; gccli gpon status

Heads up: Whenever you reboot the stick or re-edit its settings in the web console (next step), the 192.168.101.2 address on the UDM drops off - just re-run the ip addr add line above to get back in. After your internet is up and running, you most likely don’t need to log onto it ever again

Step 5: Open a tunnel for the web console

The stick also has a web UI on port 80, but it’s only reachable from the UDM. So log out of both the stick and the UDM, then log back into the UDM with an SSH tunnel that forwards your local port 8888 to the stick’s web server:

ssh <udm> -L 8888:192.168.101.1:80

In that same shell, hop back onto the stick:

ssh root@192.168.101.1

Now open the stick’s admin console in your browser (login admin / admin):

http://localhost:8888

Step 6: Set PON Mode and the ONT identity

Two things happen here - one in the web UI, one over SSH.

In the web console, first switch the PON Mode from Auto to GPON, per FS.com’s official configuration guide:

WAN Configuration → PON Mode → GPON

Let it reboot.

Log back into the web console and go to ONT Authentication:

• Set the SN to your HWTCxxxxxxxx value from Step 1.
• Leave the password field empty.
• Leave the LOID field empty - my ISP doesn’t use it. (If you want to be safe, you can also put the SN in the LOID field, still with no password.) Your mileage may vary here.

Then, over SSH on the stick, set the same identity and persist it. Use your real HWTCxxxxxxxx serial, and the MAC you want the stick to present (the AA:BB:CC:DD:EE:FF below is a placeholder):

gccli sys sn HWTCxxxxxxxx; gccli sys mac AA:BB:CC:DD:EE:FF; gccli sys vendorid HWTC; gccli sys save; sync; reboot

After it comes back, open the stick’s status page in the web console and confirm the MAC and ONT authentication are set correctly. Get this right before you touch the fiber - almost every failure later traces back to a wrong value here.

Step 7: Configure the UDM Pro for PPPoE

Over in the UDM Pro console, set up the WAN:

• Internet connection type: PPPoE
• Credentials: on my line none are actually checked - I just use a dummy
• VLAN: 42 (whatever your ISP told you)

Then, in the UDM Pro’s Console Settings, set MSS Clamping to Custom: 1452. (PPPoE eats 8 bytes of MTU overhead - 1500 → 1492 - and clamping the TCP MSS to 1452 avoids the classic “some sites load, some hang forever” PPPoE MTU mess.) This is also highly provider dependent, so make sure to check that.

Step 8: Swap the fiber and watch it register

This is the moment of truth. Unplug the optical cable from the Huawei and plug it into the UDM’s stick.

Watch the stick walk up the GPON state machine from O1 (no optical signal) to O5 (registered). Confirm with:

gccli gpon status

Once you’re at O5 and the UDM’s PPPoE session comes up, you’re online - directly, with the Huawei sitting in a drawer.

Troubleshooting: always check the GPON state first

The golden rule: check the GPON state before you debug anything else. PPPoE and VLAN settings are irrelevant if the stick never registers on the fiber.

On the FS stick:

gccli gpon state; gccli gpon status

You want O5. If you’re not there, don’t waste a second on PPPoE or VLAN yet - work the optical/auth layer first:

• O1 after connecting the fiber → the stick doesn’t see an optical signal. Check the fiber connector (and that you actually moved the cable over from the Huawei).
• O2 / O3 / O4 but never O5 → GPON authentication issue. Recheck the SN, MAC and vendor ID, and whether your line needs any other ONT fields.
• O5 but no Internet → GPON is working, the hard part is done. Now debug the UDM: PPPoE, VLAN 42 (vs. “Automatic”), and MTU/MSS clamping.

That’s it. The Huawei is gone, the UDM Pro terminates fiber and PPPoE on its own, and you’ve got one fewer black box between you and the internet.

I hope this saves the next person a few evenings.

As icing on the cake: Their iOS app “Pool panel” by the developer “Guangzhou Wo Jie Information Technology Co., Ltd” is unmaintained since 2019, the contact link leads to a broken link (https://www.axen-heatpump.com/contactus.html), nobody responded via email. Very trustworthy.

This is the story of how I got control back, learned a few uncomfortable things along the way, and ended up with a small Docker container that exposes my pool pump as a clean local REST API.

tl;dr: Show me the code!

Disclaimer: if you try any of this at home, you’re on your own. I’m describing what I did with my own device on my own network. If you break your device, that’s on you. Also: Don’t poke at devices that aren’t yours.

The first uncomfortable thing

Before doing anything clever, I sniffed the pump’s network traffic with tcpdump. The pump has a Wi-Fi module (a Hi-Flying HF-LPB130 - keep that part in mind, we’ll come back to that later) and dials out to the internet on its own. What I saw:

• TCP, port 502. That’s the standard Modbus port.
• Plain text, no TLS. Everything in the clear, unencrypted.
• Destination: 47.254.152.109 - an Alibaba Cloud IP in mainland China. Reverse-DNS: fzdbiology.com.

So that means, if you can sniff the communication between the pump or the mobile in any way, you can remote control any pump. Set it to 40 degrees on boost most in the middle of the winter for example. So, not good.

There’s also an HTTP API at fzdbiology.com:8080 (also unencrypted, plain HTTP - not HTTPS) that the iOS app uses for login and “give me the current state of my pump”. When I pointed a browser there, I got a Java-style admin panel where I could see my own device, my email address, and a couple of numbers I half-recognized. In Chinese only. :-/

It also seemed to me that the device-side protocol on :502 is identified by MAC address only. There’s no token, no certificate, no per-device shared secret that I could see. If you know a device’s MAC, the cloud appears to forward control commands to whoever’s currently connected as that MAC. I didn’t actually try connecting as someone else’s pump, but clearly security hasn’t been any concern when designing this.

I’m sure with more time you could connect as someone else’s pump and watch what their iOS app sends — set their pool to 40 °C, flip them into boost mode at 03:00. I didn’t try, but the surface area is right there.

Additionally, I wanted to gain more control - for example that the pump shouldn’t heat overnight and only start heating if it makes sense in terms of outside temperature.

So I decided to cut the cord to this unencrypted, weird Chinese server, which was constantly chatting with the heat pump.

Recognising a white-label

I expected to be on my own with this. AcquaSource sells under several brand names (just google “47.254.152.109”, you’ll find brands like “Mundoclima”, “Thermway”, “Powerpool”, Proteam”, “AES” and more all around the world); the manuals are translations of translations.

When you try to connect the pump, it starts a wifi called HF-LPB130. This seems to be a common SOC module when it comes to heat pumps of any kind. Fortunately, some other people already did some research on that already:

• s10l/deye-logger-at-cmd - solar inverter loggers using the same module, with documented AT+ commands for changing the cloud server.
• Hypfer/deye-microinverter-cloud-free - exactly the same idea I was about to attempt, but for solar inverters: redirect the module from the vendor cloud to your own server.
• davidrapan/ha-solarman - a Home Assistant integration for the same family of devices.

Big shoutout to those repo owners and the work they put into reverse-engineering!

The HF-LPB130 turns out to be a generic Wi-Fi-to-Modbus bridge. The vendors all use it the same way: the device speaks Modbus over a serial UART; the module re-frames it as Modbus-TCP-style MBAP packets and dials a hard-coded server. Anyone who buys this module in volume gets the same primitive: a serial-to-cloud pipe that you can re-target with a few AT+ commands over UDP/48899.

That meant two things: (1) I could get the module to talk to my server instead of fzdbiology.com, and (2) once it did, I’d be receiving Modbus-TCP-shaped frames - a known protocol with widely available parsers, plus a vendor-specific extension for heartbeats.

What I didn’t have was the pump-vendor-specific bit: which Modbus register holds the on/off bit, which one holds the setpoint, what the function codes mean.

Phase 1: cheating with mitmproxy

Before doing the hard reverse-engineering work, I did the easy reverse-engineering work. I pointed my iPhone at a mitmproxy instance on my laptop, opened the iOS app, and watched it log into fzdbiology.com:8080.

The HTTP API is verbose: getRtuRealTime returns a JSON document with about 100 named fields per device - model, function, heattemp, cooltemp, pa10, pa15, ap2, ap3, pb11. Some are obviously meaningful; some are just opaque registers. I wrote a small Ruby tool (tools/cloud_probe.rb in the repo) that wraps loginUser + getRtuRealTime and dumps a snapshot to disk. Two snapshots, taken on either side of pressing a button on the pump’s physical panel, told me what each field represented:

$ ruby tools/cloud_probe.rb diff before.json after.json
model: 4 → 2          # ← I pressed "heat mode"
heattemp: 27 → 28     # ← I bumped the setpoint

That gave me the vocabulary. It did not give me the protocol - the cloud was translating between the iOS app’s verbs and the device’s Modbus registers, and I needed to know how that translation worked if I was going to replace the cloud.

I then also decompiled the Android app, which basically gave me the same findings I already had from sniffing with mitmproxy.

Phase 2: I/O digging

I had two options: keep poking at the device passively, or impersonate the cloud and let the device tell me what it wanted to hear. I did both.

Passive sniffer. A small Ruby script that listens on TCP/502, parses Modbus-TCP framing, ACKs every push the device makes, and logs the bytes with timestamps. Nothing the device sends gets dropped, and once you ACK its first vendor heartbeat, it sends a full register sweep every couple of seconds.

Active cloud-impersonator. Another small script that does the opposite: opens a TCP connection to fzdbiology.com:502, sends the heartbeat the real device would send (using my own pump’s MAC, since the cloud only auths by MAC), and waits for what comes back. With the iOS app running, it turned out that every button I pressed in the app turned into a 12-byte frame on my impersonator’s socket. I could line up “I just pressed boost” against fc=0x06 addr=0x07d2 value=0x0400 and conclude that register 0x07d2 is the function selector and 0x0400 means “boost”.

Forty minutes of button-pressing later, I had the user-facing control surface decoded:

Modes and functions are bit-encoded - 0x04 for heat is bit 2; silent (0x0010) is bit 4 and boost (0x0400) is bit 10 in the same word, with smart represented by no bits set at all. The earlier hypothesized mapping I’d seen in other projects (auto=0, silent=1, boost=3) was an enum guess; the device actually wants flag bits.

I did the second phase with Claude Code as a pair, which kept the test suite green while I stress-tested protocol theories at the keyboard - which was extraordinarily helpful, especially when it came to observing bits and registers.

Phase 3: a Docker container that speaks pool

The end product is small: a single Ruby process that listens on two ports inside a Docker container plus a couple of scripts which help to set up the initial configuration to point the pump to my local network.

• Port 502 - the real pump dials in here. The container parses Modbus-TCP pushes, maintains an in-memory register snapshot, and sends Modbus writes back when something on the local network asks for a control change.
• Port 8090 - a flat REST API for everyone else.

$ curl http://homeserver.example.com:8090/
{
  "SWITCHED_ON": 1,
  "TEMP_TARGET": 28,
  "TEMP_AMBIENT": 17,
  "TEMP_OUTLET": 18,
  "BOOST": 1,
  "SILENCE": 0,
  "STATUS_MODE": 2,
  "STATUS_MALFUNC": "none",
  ...
}

$ curl -X POST -d "settemp 28" http://homeserver.example.com:8090/
{ "result": "ok", "verb": "settemp 28", "snapshot": { ... } }

End-to-end latency from curl to physical pump is well under a second. The container sends the Modbus write, the pump echoes the same frame back over TCP within ~150 ms, and the HTTP request resolves at that moment. The full register-block sweep runs every ~17 s in the background and updates the snapshot, but commands don’t have to wait for it.

One thing I noticed is that the HF-LPB130 only accepts hostnames, not IP addresses. So you need to have some public domain which resolves into your 192.168.x.x address

Phase 4: Deploying it

The whole thing runs on a Raspberry Pi 4. The Pi has a stable LAN IP, an A-record at homeserver.example.com pointing at it, and docker compose up -d --build brings the container up at boot. The pump’s Wi-Fi module is configured (one-time, via the OEM AT+ command set) to dial homeserver.example.com:502 instead of the Chinese cloud. If I ever move the container to a different host, I just flip the DNS A-record - the module re-resolves on its next reconnect and lands on the new server. No more touching the pump.

Integrating it into smart home systems

Within Homey Pro I created a virtual device that represents the pump, plus a HomeyScript that runs every five minutes (or whenever the virtual device’s state changes). The script implements a soft-intent model: turning on the virtual device doesn’t directly turn on the pump — it only fires up if the outside temperature (measured by a Netatmo sensor) is above a sensible threshold and we’re inside a daytime heating window.

Reading the manual carefully, I also learned that the pump’s “silent” mode isn’t just acoustically quieter — it’s actually the most energy-efficient setting. So the script pins the pump to silent by default and only flips to “boost” when I explicitly ask for fast heating via a separate Boost button on the virtual device.

If you have the same pump, the same module, or just the same general “I want my IoT thing to stop calling home” problem, the code is on GitHub.

I hope it’s useful for somebody with the same problem.

Bloomberg ran the headline: “Anthropic AI Tool Sparks Selloff From Software to Broader Market.”

So I went and read what Anthropic actually shipped.

What Anthropic Actually Released

On January 30, Anthropic open-sourced eleven plugins for Claude Cowork, their agentic desktop app. One of those plugins was for legal work — six subdirectories of plain text files: contract-review, nda-triage, compliance, legal-risk-assessment, meeting-briefing, and canned-responses.

No new model. No API. No product launch. A GitHub repo with ~2,500 lines of structured prompt instructions. The kind of thing thousands of developers write every day when building on top of LLMs.

Here’s the core of the contract review methodology, quoted directly from the repo:

1. Identify the contract type: SaaS agreement, professional services, license, partnership, procurement, etc.
2. Determine the user’s side: Vendor, customer, licensor, licensee, partner.
3. Read the entire contract before flagging issues. Clauses interact with each other.
4. Analyze each material clause against the playbook position.
5. Consider the contract holistically: Are the overall risk allocation and commercial terms balanced?

That’s the review process. The entire methodology. Identify, determine sides, read, analyze, consider holistically. This is what a law school student probably learns on day one.

First-Year Law School Material

The NDA triage skill is a 10-point checklist: agreement structure, definition scope, obligations, standard carveouts, permitted disclosures, term, return/destruction, remedies, problematic provisions, governing law. Every in-house legal team has this document pinned somewhere. The green/yellow/red classification system is a standard risk matrix — the same framework taught in corporate legal training.

Don’t get me wrong: The prompts are well-crafted. But: They’re not magic. They’re structured instructions for tasks that legal professionals have been doing for decades. And they’re open source — anyone can read them, copy them, modify them. You can run them in OpenAI. Or an Open Source Model like DeepSeek.

There is no competitive advantage here that couldn’t be replicated by a competent developer in an afternoon.

The Information Asymmetry Is the Story

The repo is public. Anyone could have read it in 10 minutes. The market priced in fear of something that’s fully auditable on GitHub. That gap between perception and reality is the actual story.

So $285 bn lost — not because of a product launch, but because of a markdown file in a GitHub repo. Investors didn’t click through. They didn’t read the prompts. They didn’t ask a single engineer what a “skill plugin” actually is. They saw “Anthropic” and “legal” in the same sentence and hit sell.

This isn’t an AI disruption story. This is a market literacy story. The selloff tells us nothing about AI’s impact on the legal profession and everything about how poorly the market understands what AI companies actually ship.

What This Actually Tells Builders

Anthropic published these prompts freely because the prompts aren’t the product.

The “moat” for vertical AI isn’t prompt engineering — it’s execution, trust, integration, compliance, and liability acceptance. Anthropic just demonstrated that by giving the prompts away. What does that tell you about every “AI wrapper” startup whose entire value prop is a system prompt?

The Real Question

AI will reshape law firms, consultancies, and half the NASDAQ. That’s not controversial. The “software eating software” thesis has been in every VC deck since 2023. Claude Code, Cursor, Codex — they all exist. Nobody disputes the direction.

So why did a GitHub commit containing first-year law school content trigger a $285 billion repricing? Either the market hadn’t priced in something that’s been “obvious to everyone” — meaning it wasn’t actually obvious to investment professionals — or they overreacted to a headline without reading the repo. Both are equally frightening.

And here’s the kicker: this repo is public. If the people managing your money can’t do due diligence on something freely auditable on GitHub, what are they diligencing behind closed doors?

If your investment thesis can be wrecked by a README file, maybe the thesis was never there to begin with.

Because DynamoDB access is essentially all network I/O over HTTPS, it is a good playground to tinker with Ruby fibers before bringing the same approach into other production systems.

Airfield Directory runs on Falcon because I want fiber-based concurrency without the memory overhead of thread-per-request. It should feel fast and smooth under load.

Then the dynamic map happened.

The map view fans out a lot of DynamoDB queries across H3 hexagonal grid cells (a system invented by Uber). Under Falcon, I expected those requests to overlap in fibers. Instead, the reactor stalled and the app behaved like it was single-threaded again: latency spikes, janky scrolling, that “it’s fast until it isn’t” feel.

My first instinct was to do what I do elsewhere (e.g. ruby_llm): wrap the hot path in Async { ... } and trust the scheduler. It didn’t help. The AWS SDK was still blocking the reactor.

Trying to explain why the AWS SDK for Ruby fights Falcon

The AWS SDK’s default HTTP transport uses Net::HTTP wrapped in a connection pool. Contrary to what you might expect, Net::HTTP itself is fiber-friendly in Ruby 3.0+—the fiber scheduler hooks into blocking I/O and yields to other fibers automatically.

But in practice, those implicit hooks don’t yield reliably, so the single reactor thread gets blocked often enough that all fibers serialize.

What I actually saw in production:

barrier = Async::Barrier.new(parent: parent_task)
batch_cells.each { |id| barrier.async { dynamodb.query(...) } }
barrier.wait

-> Observed: serialized request time

threads = batch_cells.map { |id| Thread.new { dynamodb.query(...) } }
threads.each(&:join)

-> Observed: 1× single request time (concurrent)

So my current observation/explanation is:

• The SDK’s Net::HTTP transport is synchronous end‑to‑end and relies on implicit scheduler hooks in Net::HTTP/OpenSSL/DNS.
• In our workload, that path blocked the reactor often enough that the Async::Barrier output serialized.
• Threads still overlapped because each call ran in its own OS thread. Swapping the transport to async‑http fixed it because async‑http is fiber‑native end‑to‑end (pool + I/O), so the reactor can actually interleave requests.

I can’t tell you in detail whether it’s gaps in hook coverage, OpenSSL handshakes, DNS resolutions, whatever … In the end, async-http seems to me to be by far the best solution in the whole Async ecosystem. Of course, there might be other side effects I have overlooked, but in the end was/is my real-life observation reproducable.

I eventually fell back to threads just to keep the UI responsive. It worked, but it felt wrong.

I dug through the SDK internals and landed on the same conclusion captured in this issue: https://github.com/aws/aws-sdk-ruby/issues/2621 and an abandoned experimental repo.

So, in a nutshell:

• Threads overlapped because each call ran in its own OS thread.
• Fibers with Async::Barrier serialized under Falcon.
• Swapping the transport to async-http fixed it—because async-http is fiber-native end-to-end (pool + I/O), most likely because the reactor can actually interleave requests.

The solution: aws-sdk-http-async

I built a new HTTP handler as a gem plugin for aws-sdk-core using async-http called aws-sdk-http-async. It aims to preserve the SDK’s semantics (retries, error handling, telemetry, content-length validation), but make the transport fiber-friendly under Falcon.

Key goals:

• Async transport when a reactor exists (Falcon).
• Automatic fallback to Net::HTTP when no reactor exists (rake/console/tests).
• No patches required to make CLI tasks work.
• Safe defaults, explicit config, and clear failure modes for event streams.

Usage (zero-config)

Add it to your Gemfile:

gem 'aws-sdk-http-async'

More information in the repo on Github

AI Promises vs. Reality

Pitch decks are dazzling, promising AI marvels and tales of wonderlands. But when our team of CTOs at Expedite peeks under the hood, we often find the AI is more “artificial” than “intelligent.” When it comes to the moment of truth and we check the code, it’s often just a fancy facade for simple algorithms. It’s like expecting a Tesla but finding a remote controlled toy car instead.

Together with my fellow co-investor, Sebastian, a machine learning wizard for years, we’ve seen a lot in 2023: Take some recent pitches we examined, promising groundbreaking AI for data extraction. Spoiler alert: behind the AI mask was just basic coding without a whiff of AI insight. We’ve looked at code and models and yet, all we found was a straightforward hardcoded approach, without a hint of AI or ML.

We’re noticing a pattern: startups are in love with the AI label (sometimes rightly so when you look at the insane valuations paid for often lousy tech), and even when they incorporate some AI components, their data sets are often as thin as air. Even more often we’re just seeing a wrapper for the ChatGPT/OpenAI API. While there’s nothing wrong with that in a prototyping phase, it helps to point that out from the beginning. Also, we’ve noticed that the mindset of ‘just quickly using the API, we’ll change that later’ can hinder the accumulation of know-how in building, training, and operating customized models (which should be the goal if you’re an ‘AI Startup’, right?). Intriguingly, this approach often leads to a rapid burn rate — a hint: sometimes even unnecessary in the era of LLAMA.

While we definitely don’t claim to have all the answers or see every AI startup on the planet, the hundreds of pitches we reviewed in 2023 revealed a distinct pattern we can’t ignore.

In short: Big AI dreams, sure, but the tech isn’t walking the talk. If we had received a chocolate bar for every time we’ve seen a rules engine sold as AI, we would have had to skip Christmas this year.

A Call to Startups

Dear startups, let’s keep it real. If your AI is more of a future plan than a here-and-now reality: just say so. It’s cool to be a work in progress. Pretending otherwise? Not so much.

Investor Colleagues - look beyond the AI Sparkle

Fellow investors, don’t get lost in the AI fairy dust. Dive deep, ask hard questions. Look beyond the shiny surface of pitch decks brandishing the ‘AI’ label (means, about 95% of all pitch decks we get these days). At Expedite Ventures, we’re all about finding the genuine tech gems hidden in the AI noise. And we’re more than happy to lend a magnifying glass.

Final Thoughts

Innovation is more than a buzzword. It’s about bringing real, groundbreaking tech to the table. In the end, it’s about genuine innovation, not AI fantasies. We’re on a mission to find startups that truly push tech boundaries, not just play dress-up with buzzwords. Many AI startups lose their shine under a tech-savvy gaze. Remember, it’s not just about joining the AI parade; it’s about leading it with substance.

Let’s champion the real tech heroes — the ones who are honest about their journey and potential. Here’s to investing in solid ground, not just AI castles in the cloud.

P.S.:This isn’t just about critique; it’s about building a stronger, more genuine tech ecosystem. And hey, at Expedite Ventures, we’re always on the lookout for the real tech magicians. Got an honest, groundbreaking idea? We’re all ears!

The Wise API documentation is adequate, though occasionally lacking in detail. Also, at least in the EU, downloading balance statements requires two-factor authentication, not just a simple API call. This process involves making an API call, receiving a challenge, signing it with an RSA certificate, and then reissuing the request. Although it’s not complex, it took some time to perfect.

I created a user-friendly script that prompts for your Wise personal API token, account selection, statement year, and currency.

Setting this up requires a few steps. I recommend a trial run with a sandbox account at https://sandbox.transferwise.tech/. You’ll need to create an API token with read-only access and back it up securely. Additionally, generate a public key using the following commands in a cloned GitHub repository.

Step-by-Step Guide to Creating a Wise API Token and 2FA Public Key

To set up your API keys, first go to “Settings” and then to “API tokens”:

• Create a personal API token in Wise
• Click “Add new token”:

• Add a new token in Wise.com
• Read Only Access for the new token is sufficient:

• Read Only Token for wise.com API

In addition to backing up the token in a password manager, you will also need to generate a public key. The most convenient way to do this is by cloning my GitHub repository containing the script and creating the key directly within that environment:

git clone https://github.com/thomaswitt/wise-statement-downloader.git
cd wise-statement-downloader
mkdir certs
openssl genrsa -out certs/wise-private.pem 2048
openssl rsa -pubout -in certs/wise-private.pem -out certs/wise-public.pemMake sure you’ll also backup the newly created RSA key.

That’s essentially all there is to it. After completing these steps, you can run the script to easily obtain your first account statement:

thomas@mac:~/Dev/wise-statement-downloader(main) $ ./wise.bash test
*** Using Sandbox API Environment
WISE Personal API Token: [CONCEALED]
Choose account:
1: Esmeralda Beasley (2023) (17012841)
Your choice: 1

Choose year for the statement:
1: 2023
Your choice: 1

Choose currency:
1: AUD (1000000.00 AUD) (179137)
2: EUR (1000000.00 EUR) (179096)
3: GBP (1000000.00 GBP) (179136)
4: USD (1000000.00 USD) (179097)
Your choice: 2
Chosen currency: EUR

*** Writing PDF file to output/Wise-17012841-Esmeralda\_Beasley-EUR-2023.pdf

The script currently supports downloading annual statements, but it can be easily modified for monthly intervals by adjusting the $STATEMENT_DETAILS variable.

Now just repeat these steps in your main production account — and you’re good to go.

Enjoy the convenience!

I created a script for my .bash_profile or .zshrc (works both via bash and zsh) to track new, unwanted additions. It doesn’t automatically delete these items but provides removal commands every time I open a shell, which is frequently. Of course, you could also automatically remove them if you don’t want to manually double-check.

Notice: This script does not affect Login Items (accessible through System Preferences > Users & Groups > Login Items), where applications can be set to launch at startup and also install background daemons (often for AppStore-based Apps). Additionally, I created an alias to monitor these via the command line as well (show_background_tasks).

Enjoy!

#!/usr/bin/env bash

# Remove unwanted helpers
process_agents() {
  local directory=$1
  shift
  local agents=("$@")
  local pattern=$(
    IFS=\|
    echo "${agents[*]}"
  )
  shopt -s nullglob
  for plist in "$directory"/{LaunchAgents,LaunchDaemons,PrivilegedHelperTools}/*; do
    if [ ! -s "$plist" ]; then continue; fi
    if ! echo "$plist" | egrep -q "^.*Library.*/($pattern)"; then
      local plist_name=$(basename "$plist" .plist)
      if [[ $directory = /Library* ]]; then
        echo "sudo bash -c 'launchctl disable system/$plist_name && true > \"$plist\" && chmod a-wx \"$plist\"'"
      else
        echo "bash -c 'launchctl disable gui/$(id -u)/$plist_name && true > \"$plist\" && chmod a-wx \"$plist\"'"
      fi
    fi
  done
}

# Define global and local agents to manage
global_agents=(
  at.obdev.littlesnitch         # Little Snitch
  com.docker                    # Docker
)
process_agents "/Library" "${global_agents[@]}"

local_agents=(
  homebrew.mxcl.ollama        # ollama
  jp.plentycom.boa.SteerMouse # SteerMouse
)
process_agents "$HOME/Library" "${local_agents[@]}"

# vim: filetype=bash:

And this is exactly what our portfolio company Supernova does — in this case it’s bridging the gap between designers and developers. The connection between those two is an extremely important one in the world of ever-more important UX — and still, the disconnect sometimes couldn’t be bigger, particularly in larger organizations. And that leads to broken, inconsistent user experiences — because it’s simply hard to manage and update a consistent design over its complete lifecycle.

Supernova actually helps designers and developers to work better together in the context of a so-called design system. Those have become the hot topic in the recent years. A design system is a shared language, a set of standards to create beautiful visual experiences, based on reusable components and patterns. It’s the final source of through about the design language of a company. At scale.

Supernova helps managing and documenting the entire lifecycle of a Design System centralized in one place without changing workflows or tools like Figma.

For a developer that means if a refinement of a design is to be rolled out, you’ll get an automated export delivery of tokens, styles, assets and code to handover to the developers. So your flutter-based mobile apps will get the same updates like your website, and developers get everything served on a silver plate in form of a GitHub pull request. Cool, eh?

And that kind of cooperation doesn’t only make the designers and developers happy, but also the management of a company. Because they get not only higher quality through visual consistency across multiple products and channels, they’ll also save a ton of money. That’s why they keep on convincing more and more large name brands. And with their latest announcement of their design token manager with support for Figma Tokens plugin and themes, they’ll continue to lead the space for Design Systems.

That’s why we are incredibly excited and honored to partner with the Supernova in their $4.8m seed round. Congratulations to Jiri, the Founder and the whole team. We are looking forward to the journey ahead!

Of course, we at Expedite will continue to keep investing in great DevTools to make developers and companies more productive and successful.

Further Reading:

• Supernova.io Homepage
• Blog post by Jiri, Founder of Supernova
• TechCrunch: Supernova wants to make it easy to move design elements to code bases