DEV Community: Jim L

How I built a LOF arbitrage monitor for HK/CN ETFs (and what I learned about 'free' alpha)

Jim L — Tue, 14 Apr 2026 01:22:05 +0000

I keep seeing the same question in HK/SG investor chats: "the S&P 500 QDII ETF is trading 5% above NAV again — is this free money?"

Short answer: not really. But the idea — that on-exchange ETF prices can drift from their net asset value — is real enough that I wanted a dashboard that just told me, every 15 minutes, which Chinese LOF/QDII ETFs were trading most disconnected from the underlying. So I built one.

This is the boring-but-useful write-up: what a LOF is, why premiums happen, what the pipeline looks like, and the three things I got wrong on the first try.

What's a LOF, quickly

LOF = Listed Open-Ended Fund. It's a mutual fund wrapper that also trades on-exchange. QDII LOFs are the ones that hold offshore assets — S&P 500, Nasdaq, HK tech, gold miners, etc.

The premium/discount mechanic:

NAV is published once a day (T+1 for offshore QDII — you get yesterday's value tomorrow morning).
On-exchange price moves live during the trading day.
When retail piles into, say, 华夏纳斯达克 after a big US overnight rally, the price can float well above the last-known NAV. That gap is the premium.
In theory, the fund house can issue new units to arb it down. In practice, QDII quotas are capped, so premiums can persist for days.

So: premium ≠ free profit. It's mostly "the market is front-running tomorrow's NAV update." But unusual premiums are worth watching, because that's where forced-selling and fat-finger trades show up.

The pipeline

Stack ended up boringly simple. Four moving parts:

Eastmoney REST  ─┐
                 ├─► Python collector (every 15 min, cron)
Tencent REST  ──┘          │
                           ▼
                     SQLite (append-only)
                           │
                           ▼
                Next.js /tools/lof-premium (ISR 15min)

No Kafka, no Redis, no Airflow. It's a 200-line Python script and a static-ish Next.js page.

Collector

The collector is two functions:

def fetch_realtime(code: str) -> dict:
    # 东财 push2 API, returns last price + bid/ask
    url = f"https://push2.eastmoney.com/api/qt/stock/get?secid={secid(code)}&fields=f43,f60,f169,f170"
    ...

def fetch_nav(code: str) -> dict:
    # 天天基金 fundgz API, returns "估值" (intra-day NAV estimate)
    url = f"https://fundgz.1234567.com.cn/js/{code}.js"
    # returns JSONP; strip the wrapper, json.loads the middle

One gotcha that cost me an afternoon: fundgz returns HTML on weekends and holidays (a friendly "市场休市" page) instead of the usual JSONP. First version crashed on every Saturday at 09:15 until I added a content-type check.

Why not just use one source?

East Money gives you price but not intra-day NAV estimate. Tiantian gives you NAV estimate but not L2 price. So you have to join them on the fund code. Cross-check also catches the case where one API starts returning stale data, which happens more than you'd think.

Storage

Single SQLite file, one row per (code, timestamp). Append-only. ~300 funds × 26 snapshots/day × 365 days = ~3M rows/year. SQLite eats that for breakfast.

I briefly tried Postgres. Moved back to SQLite after two weeks because the entire deploy is a file copy and backups are cp lof.db lof.db.bak.

Frontend

Next.js 15, ISR with revalidate: 900. The page is essentially a table sorted by absolute premium, with a tiny sparkline of the last 48 hours per fund.

The sparkline was the part I over-engineered. First I pulled in a charting library (120KB), then I swapped it for a 40-line inline SVG component. Same visual, 3% of the bundle size.

Three things I got wrong on the first try

1. I trusted the "premium" column on 东财

The portal shows a premium column. It's computed off yesterday's official NAV, not the intra-day estimate. For a QDII holding US stocks that rallied 2% overnight, "yesterday's NAV" understates the fund by 2% before the market even opens, so the premium column is systematically inflated on up days and depressed on down days.

Using the estimated NAV instead (the one Tiantian publishes intra-day) cut the noise dramatically. The high-premium list used to be "whatever went up last night in the US." Now it's actually unusual positioning.

2. I assumed 15-minute cadence was fine

It mostly is. But around 09:30 and 14:57 (CN market open / close auction) the price moves 0.5–2% in a single minute. A 15-minute snapshot misses those.

Compromise: 15-min during the day, 1-min windows around open/close auctions. cron with two schedules.

3. I forgot time zones, twice

Tiantian returns Beijing time with no tz marker.
East Money returns Unix timestamps in ms.
My server runs UTC.
My browser renders in Sydney time.

First bug: charts were off by 8 hours. Second bug: I "fixed" it by hard-coding +8, then flew to Sydney, and everything shifted again.

Final rule: store UTC in SQLite, tag Beijing explicitly at the API boundary, format to the browser's locale in the client. Boring, but it's the only approach that survives moving.

Does the data actually give you alpha?

Honestly — mostly no. Here's what a month of logs looks like in practice:

80% of the top-premium funds on any given day are just "US market gapped up overnight, retail is buying the reopen." By the time you see it, the arb is gone.
15% are chronic premium funds — usually QDII with exhausted quota. You can't subscribe at NAV even if you wanted to. The premium is a structural access-fee, not mispricing.
Maybe 5% are genuinely odd: a small-cap sector LOF that jumped on news nobody else was tracking, or a fund where the manager announced something that moved NAV estimate but not price yet.

That 5% is the reason the dashboard exists. Not as a trading signal on its own, but as a "huh, why is this one weird?" attention filter.

What I'd do differently if I rebuilt it today

Push notifications instead of pull. I still refresh the page. A Telegram bot that pings me when premium > 2σ would be 10x more useful.
Historical NAV backfill. My DB starts from the day I deployed. If I'd backfilled 2 years from Tiantian's archive, regime comparisons ("is this premium unusual for this fund?") would actually work.
Skip the live sparkline. Nobody looks at it. A single "premium now vs 7-day avg" number would convey more.

Summary for the impatient

LOF premium = on-exchange price minus intra-day estimated NAV. Don't use the portal's published premium column; it's anchored on T-1 NAV.
Two APIs, join on fund code, cross-check. SQLite is enough. 15-min cadence + 1-min around auctions.
Most "premiums" are just timezone artifacts or quota constraints. The signal you want is the ~5% of funds that are genuinely priced weird today.
Store UTC, tag at the boundary, format at render. Every time.

If you end up building something similar and hit a case I didn't cover — especially around holiday calendars for A-shares vs HK vs US simultaneously — I'd love to compare notes in the comments.

Karpathy's LLM Knowledge Base SEO: I applied the pattern for 12 months and here's what I learned

Jim L — Mon, 13 Apr 2026 02:48:41 +0000

Karpathy's LLM Knowledge Base × SEO: I applied the pattern for 12 months and here's what I learned

On April 3, 2026, Andrej Karpathy posted a short but influential note about using LLMs to build personal knowledge bases. The premise: instead of RAG pipelines and vector databases, you manually clip raw sources into a raw/ folder, let an LLM distill them into structured wiki pages, and query the graph later with your LLM CLI of choice.

No SaaS lock-in. No embeddings. No subscription. Just markdown and an LLM that knows the schema.

I'd been drowning in scattered SEO research for a year — running openaitoolshub.org, an AI tools directory that's gone from DR 0 to DR 30 in 12 months, 126 articles, 130+ earned backlinks. My notes were spread across Notion, Kagi Assistant, local markdown files, a neglected Readwise Reader queue, and a thousand unread tabs. Karpathy's pattern gave me the discipline to consolidate everything into a single Obsidian vault that an LLM could maintain.

This article walks through what I built, the key design decisions, and the one contradiction-preservation trick that changed how I think about personal knowledge bases entirely.

The five-step pattern

Karpathy's original framing was simple:

Set up raw/ — every source you encounter, unedited
Set up wiki/ — structured concept pages the LLM maintains
Distill with an LLM — run a pass where Claude/Codex/etc reads raw sources and updates wiki pages
Cross-link with [[wikilinks]] — let the LLM suggest relationships between concepts
Query the graph with your CLI — ask questions months later, get synthesized answers from the vault

The genius is in step 3 — the LLM does the hard work of synthesis, contradiction detection, and cross-referencing. You do the reading and judgment calls.

How I adapted it for SEO

SEO is a moving target. What worked in Q4 2024 is wrong by Q2 2025. Google's March 2026 Core Update just rewrote half the playbook. I needed a system that could absorb new evidence and propagate updates without me manually re-reading every page.

My vault structure:

seo-obsidian/
├── Home.md                    # glassmorphism dashboard
├── CLAUDE.md                  # LLM operations guide
├── wiki/
│   ├── schema.md              # the concept-page template rulebook
│   ├── concepts/              # 12 SEO concept pages
│   ├── tools/                 # 3 tool profiles
│   ├── people/                # 1 person profile (Karpathy)
│   └── indexes/               # alphabetical catalogs
├── raw/
│   ├── README.md              # explains the three-layer architecture
│   ├── articles/              # long-form sources
│   └── practitioner-notes/    # curated short-form observations
└── maps/
    └── SEO-Domain-Map.canvas  # 21-node mind map

Every concept page follows a strict schema: ## TLDR, ## Key Points, ## Details, ## Applied Example, ## Related Concepts, ## Sources. The rigidity felt annoying at first, but it pays off at query time because Claude knows exactly where to look for each piece.

Three design decisions worth discussing

1. Preserve contradictions instead of resolving them

On April 10, Zhang Kai published a 602-prompt study claiming structured content (H2/bullets/tables) correlates with AI citation. On April 11, a Japanese SEO practitioner published experiments claiming structured data does NOT help AI understanding.

In a traditional wiki I'd have to pick one. In the Karpathy pattern, both claims live in the vault. The Zhang Kai finding is in the main section of geo-generative-engine-optimization.md. The Suzuki counter-evidence is in a ⚠️ Counter-Evidence callout right below it. When I query the vault with Claude, I get both cited.

This is the single most important insight I took from applying the pattern: honest knowledge > confident answers. The vault is a snapshot of the field's current state of confusion, not an attempt to pretend the confusion doesn't exist.

2. The ripple effect as the compounding mechanism

When I add a new raw source, I don't manually update related concept pages. I tell Claude:

$ claude
> Ingest raw/practitioner-notes/zhang-kai-602-prompt-geo-study.md 
> following wiki/schema.md. Update all related concepts with the new 
> evidence and flag any contradictions.

Claude then:

Reads the new source
Decides which of the 12 existing concept pages it affects
Updates each one with the new evidence
Flags contradictions against existing claims
Updates the concept index
Writes a log entry

One source → 5-15 pages updated → all in 45 seconds.

This is what makes it compound. Most note-taking systems are linear (you add, you rarely re-read). This one is multiplicative — every new source makes the whole wiki incrementally smarter.

3. Strict concept-page schema > flexible notes

I experimented with both. Flexible concept pages were easier to write but hell to query. Strict ones were slightly annoying to fill out but let Claude parse them reliably.

The schema:

aliases: []
tags: []
sources: []
cssclasses: [seo-brain-concept]

# Concept Title

## TLDR
One paragraph, 200-250 words. This is what AI engines cite.

## Key Points
5-8 bullet points.

## Details
The main content, 800-1500 words. Can have sub-sections.

## Applied Example
A concrete worked scenario.

## Related Concepts
- [[concept-a]] — why it's related
- [[concept-b]] — why it's related

## Sources
- External URLs
- raw/... paths

Every single concept page follows this. It's like a database schema — restrictive, but queryable.

Three concrete SEO insights that came out of the exercise

Insight 1 — Mean AI-cited content length is 1,375 characters

Zhang Kai's study measured the length of every fragment cited by ChatGPT, Perplexity, and Google AI Overview across 602 prompts. The mean was 1,375 characters — roughly 200-250 words, or about 10 sentences.

Practical implication: write TL;DR blocks of 200-250 words near the top of every article. Break the body into H2-bounded sections of 1,000-1,500 characters. That's the GEO sweet spot for citation.

Insight 2 — Google's March 2026 Core Update targets 7 specific AI writing patterns

Kill these and your content survives:

"Not just X, but Y" constructions
Em-dash overuse
Triad lists ("powerful, elegant, and fast")
Formulaic openers ("In today's fast-paced world...")
Breathless enthusiasm ("game-changing")
False-authority hedging ("It's worth noting that...")
Broad-to-narrow openings

I went through every article on openaitoolshub.org and stripped these patterns. Traffic stabilized. Articles that failed the update all shared these tells.

Insight 3 — Free dofollow directories above DR 55 exist

Conventional wisdom says free directories are DR 0-10 and useless. Actual: I found at least 12 free dofollow directories above DR 55. A field study in early April showed that adding 50 such backlinks moved a DR 46 site to DR 50 in one week.

The misconception comes from the early 2010s when directory submission was spammed to death. Post-2024, curated directories (Navs Site, Acid Tools, Ben's Bites, ShowMySites, NextGen Tools) are legitimate editorial sources.

What tools I used (and didn't use)

Used:

Obsidian (free) for the vault UI
Claude Code for the distillation + query layer
Ahrefs (~$99/month, but sem.3ue.com mirror for specific lookups)
Google Search Console (free) — the most important SEO tool for indie devs

Explicitly NOT used:

No SEO course (they go stale)
No paid link-building service (PBNs are a DMCA landmine)
No vector database (the whole point of the Karpathy pattern is avoiding this)
No subscription SaaS tools beyond Ahrefs

The goal was to keep the tool budget under $100/month and replace expensive tools with LLM-assisted workflows. Mostly worked.

What's next

I packaged the vault as "SEO Brain" for other indie devs. Free 5-concept starter kit is at openaitoolshub.org/en/seo-brain (canonical source, no Medium paywall). Full 12-concept Starter Edition is on Gumroad, $19 launch week, $29 regular.

More importantly — if you're doing personal research in any domain, I think Karpathy's LLM KB pattern is the right structure for 2026. Try it with your own domain (investing research, game dev, climate science, whatever) and let me know what you learn.

The compounding is real. The contradictions-preserved discipline is the trick.

About the author

Jim runs openaitoolshub.org (DR 30, 126 articles, solo) and four sister sites covering trading, SaaS, AI tools, and game directories. He writes about applying indie dev patterns to SEO at his main site.

This article's canonical version lives at openaitoolshub.org/en/seo-brain. Dev.to is a syndication copy.

I Tried Microsoft Agent Framework 1.0 — Three Days In, Here Is What I Think

Jim L — Fri, 10 Apr 2026 03:39:54 +0000

The Merge Nobody Asked For But Everyone Needed

Microsoft released Agent Framework 1.0 on April 7. The pitch: one SDK that fuses Semantic Kernel (enterprise middleware, telemetry, type safety) with AutoGen (multi-agent chat orchestration). No more stitching two libraries together with duct tape.

I spent three days testing it on real work instead of toy examples. Here is what I found.

What Actually Works

The graph-based workflow engine is the star. You define agent relationships as a directed graph — orchestrator hands off to researcher, researcher passes to coder, coder sends to reviewer. Each agent keeps its own session state.

I built a four-agent pipeline that parsed GitHub issues, drafted code, ran tests, and generated PR descriptions. Total setup: around 120 lines of Python. The DevUI debugger runs locally and shows real-time message flows between agents. I caught two infinite-loop bugs through it that would have burned through my API budget otherwise.

MCP support landed on day one. My agents could call external tools through the Model Context Protocol without custom wrappers. I connected a filesystem server and a web search tool in maybe 15 minutes.

Where It Falls Short

Python support feels rushed. The .NET SDK is polished — types, middleware hooks, proper async. The Python package works but documentation has gaps, and some features like the evaluation framework are .NET-only for now. If you are a Python shop, expect to read source code more than docs.

A2A (Agent-to-Agent protocol) is version 1.0 but the ecosystem is basically Microsoft talking to Microsoft right now. Cross-framework interop with LangChain or CrewAI agents is not there yet. Give it six months.

Boilerplate is real. Setting up a simple two-agent chat requires more ceremony than LangGraph or Claude Agent SDK. Fine for enterprise teams with dedicated infra — overkill for a weekend prototype.

How It Stacks Up

I wrote a full breakdown comparing Microsoft Agent Framework against Claude Agent SDK, LangGraph, and CrewAI on my site with actual code examples and benchmark numbers.

Short version: Agent Framework wins on enterprise features, Claude SDK wins on simplicity, LangGraph wins on flexibility. Pick based on where you are running production workloads.

Who Should Care

If your company already runs on Azure and uses Semantic Kernel, this is the obvious next step. The migration path from SK plugins to Agent Framework tools is nearly 1:1.

If you are an indie developer testing the waters, I would start with Claude Agent SDK or LangGraph first. Lower friction, faster prototyping. Come back to Microsoft Agent Framework when you need enterprise observability or graph-based multi-agent workflows.

My Setup

I tested on Python 3.12, WSL2 Ubuntu, with GPT-4.1 and Claude Opus as backend models. Cost for three days of experimentation: roughly $14 in API calls. The DevUI runs locally on port 5000 and uses about 200MB of RAM.

One thing I appreciated: the framework does not force you into Azure. You can use any OpenAI-compatible endpoint, local models through Ollama, or Anthropic directly. The Azure AI Foundry integration is optional, not required.

Bottom Line

Microsoft Agent Framework fills a gap that has existed since enterprises started asking "how do I put AutoGen in production?" The answer: merge it with your enterprise middleware, add proper observability, ship it.

Not revolutionary. But solid engineering that solves a real problem for a specific audience. Which is probably the more valuable outcome anyway.

Google Just Showed Us What Happens When You Throw Out the Token-by-Token Playbook

Jim L — Thu, 09 Apr 2026 03:35:06 +0000

Every LLM you have used works the same way. It predicts the next token, then the next, then the next. One at a time. Autoregressive generation. That is how GPT-4o works, how Claude works, how Gemini 2.5 Pro works.

Google just said: what if we stop doing that?

Gemini Diffusion generates text the way image models generate images. Instead of building a sentence left to right, it starts with noise and refines the entire output simultaneously. The claimed speedup is 5x over comparable autoregressive models.

I have been thinking about what this actually means for the way I build things.

The speed problem nobody talks about

When you are making a single API call, the difference between 2 seconds and 0.4 seconds does not matter much. But when you are running batch jobs — processing 500 documents, generating test cases for an entire codebase, summarizing a week of customer support tickets — that 5x adds up fast.

I run a lot of batch processing through Claude and GPT-4o. A typical overnight job hits the API maybe 2,000 times. At current speeds that takes roughly 3 hours. If diffusion models actually deliver on the 5x claim, that same job finishes in 36 minutes. That changes whether I can run it during lunch instead of overnight.

Why I am skeptical

The 5x number comes from controlled benchmarks. Real-world performance depends on context length, output complexity, and how the model handles edge cases. I have seen plenty of impressive benchmark numbers that fall apart when you throw messy real data at them.

Also, diffusion models for text are genuinely new territory. Image diffusion had years of iteration before it got reliable. Text diffusion is maybe six months into serious research. The failure modes are different — you can get away with a slightly wrong pixel in an image, but a slightly wrong word in code breaks everything.

What I am actually going to do

Nothing yet. I am not rewriting any pipelines around a model that is still in research preview. But I am watching two things mainly: whether the speed holds on long outputs (2000+ tokens), and whether Google actually ships a usable API at a reasonable price. The code quality question is secondary if the pricing is wrong.

If all three check out, I will probably move my batch processing over first and keep interactive coding on Claude. Speed matters less when you are pair programming. It matters a lot when you are processing data at scale.

What got my attention is not this specific model. Someone proved the approach works at all. If Google can do it, Anthropic and OpenAI are probably working on their own versions. In a year we might look back at autoregressive-only models the way we look back at RNNs — technically functional but obviously not the final answer.

Or the whole thing might hit a wall at 1000 tokens and we are back to business as usual. Could go either way.

I Replaced Claude with Gemma 4 for a Weekend — Here's What Broke

Jim L — Wed, 08 Apr 2026 05:05:55 +0000

I run five websites from Sydney and use AI models daily — for blog drafts, code fixes, SEO analysis, quick research. Most of my workflow runs on Claude Sonnet because it's consistent and doesn't need babysitting. So when Google dropped Gemma 4 on April 2, 2026 under Apache 2.0, I figured I'd stress-test it over a weekend before forming any opinions.

Short version: it's genuinely impressive in places, mildly annoying in others, and the license alone changes a lot of the math.

What Gemma 4 Actually Is

Gemma 4 is Google's latest open-weight model family. Released April 2, 2026. Apache 2.0 license, which means you can use it commercially, modify it, redistribute it — no royalties, no restrictions on derivative works. That's meaningful.

The family ships in several sizes: 4B, 12B, 27B, and a new 96B variant. The 27B is the one most people will actually run locally (needs roughly 20GB VRAM in full precision, or 12GB quantized to Q4).

It's multimodal — image understanding built in, not bolted on. And there's genuine agentic scaffolding baked into the instruction-tuned variants, meaning it handles multi-step tool use more coherently than Gemma 3 did.

What I Actually Tested

Test 1: Code generation for a Next.js component

I gave it a prompt I regularly use with Claude: build me a React component that fetches data from a Supabase table, handles loading/error states, and renders a responsive table.

Gemma 4 27B (via Ollama, quantized) produced working code on the second attempt. First attempt had a minor type error in TypeScript. Second attempt fixed it without me explaining what was wrong.

Claude Sonnet would have nailed this on the first try. But Claude costs money per token. Gemma 4 running locally costs electricity.

Test 2: Document analysis (multimodal)

I threw a screenshot of a GA4 analytics dashboard at it and asked it to summarize traffic trends. Gemma 4 read the numbers correctly but its interpretation was generic. It told me sessions were down 14% without offering any hypothesis about why. Claude tends to make inferences. Gemma 4 reports rather than reasons.

Test 3: SEO content editing

I fed it a 1,200-word blog post and asked it to identify thin sections. This went better than expected. It flagged two genuinely weak paragraphs, suggested adding a comparison table, and offered three alternative headline options that were actually good.

The Surprise (Good and Bad)

Good surprise: The 12B model is more capable than it has any right to be. I ran it on a machine with 8GB VRAM and it handled most single-turn tasks at a quality level I'd compare to GPT-3.5 era.

Bad surprise: Agentic tasks with multi-step tool use hit context length issues faster than expected. Around step four of a five-step workflow, it started losing track of earlier context.

Also: it's verbose by default. Ask it a yes/no question with nuance, it writes three paragraphs.

How It Compares

	Gemma 4 27B	Claude Sonnet 4.5	GPT-4o
Cost	Free (local) or ~$0.10/M via API	~$3/$15 per M tokens	~$2.5/$10 per M tokens
Context	128K	200K	128K
Code quality	Good, 2nd attempt	Excellent, 1st attempt	Very good
License	Apache 2.0 (fully open)	Proprietary	Proprietary

The license column is doing more work than it looks. If you need AI costs that don't scale with usage, or on-prem deployment for compliance, Gemma 4 is now a serious option.

Who Should Use This

Worth it if: self-hosting, compliance requirements, fine-tuning experiments, or budget-conscious.

Stick with Claude/GPT if: you need top-tier multi-step reasoning, heavy document inference, or don't want to manage infrastructure.

I'm not switching my main workflow off Claude. But I've moved quick classification tasks and a couple of internal scripts to a local Gemma 4 12B instance. That's probably $30-40/month in API calls I won't be making.

Not a revolution, but a genuine shift in what's viable to run without a credit card.

I Built 6 Free SEO Tools in One Day — Here's What I Learned

Jim L — Mon, 06 Apr 2026 01:38:48 +0000

SEO tools are everywhere, but most are locked behind signups, API limits, or subscription walls. I wanted something I could actually use without friction — so I built 6 tools over a weekend and open-sourced the approach.

The Tools

All run in-browser (4 client-side) or via lightweight server fetch (2 API routes). Zero external API costs.

1. Schema Markup Generator

Visual form → valid JSON-LD for FAQPage, Article, HowTo, Product, Organization, BreadcrumbList. Click "Copy HTML" and paste into your <head>. One-click link to Google Rich Results Test.

Why I built it: I was manually typing JSON-LD for every blog post. Now it takes 30 seconds.

2. LLMs.txt Generator

Input any URL, get llms.txt + llms-full.txt following the llmstxt.org standard. Fetches your sitemap, extracts titles/descriptions, formats everything.

Why it matters: AI assistants like ChatGPT and Claude check this file when users reference your site. No llms.txt = missed citations.

3. Hreflang Tag Generator

Add language/URL pairs, get self-referential hreflang HTML with x-default. Validates duplicates and missing tags.

Tiny tool, but saves me 10 minutes every time I add a new language to a site.

4. Meta Title & Description Analyzer

Pixel-accurate truncation check (Google measures in pixels, not characters). Live SERP preview, keyword density analysis, power word detection. Also flags "Best"/"Top" in titles per Google's Feb 2026 Core Update rules.

5. Robots.txt Tester

Paste your robots.txt, test any URL path against 15+ user agents — including GPTBot, ClaudeBot, PerplexityBot, and Google-Extended. Shows exactly which rule matched and whether it's Allow or Disallow.

Built this because blocking AI crawlers is becoming the default, but most people have no idea if their rules actually work.

6. OG Image Preview

Fetch any URL and see how it renders on Twitter, LinkedIn, Slack, and Discord. Each platform crops differently — this shows all four at once plus detects missing/broken tags.

Technical Decisions

Client-side first: 4 of 6 tools run entirely in the browser. No server, no API, no data retention.
Server fetch only when needed: LLMs.txt and OG Preview need to fetch external URLs (CORS), so they use Next.js API routes.
Zero API cost: No OpenAI, no paid APIs. Just fetch() + regex parsing.
Dynamic routing: One [tool]/page.tsx handles stubs for unreleased tools; specific routes override when ready.

What I'd Do Differently

Schema Generator could use client-side validation against Schema.org spec (currently just generates, doesn't validate fields). Meta Analyzer's pixel width estimation is approximate — a Canvas-based measurement would be more accurate.

Try Them

All 6 tools are live at openaitoolshub.org/seo-tools. No signup, no API key. Feedback welcome.

What free SEO tools do you actually use daily? Curious what's missing from the landscape.

I Tested Cursor 3 Glass for a Week — The Agent-First IDE Is Real, But Not for Everyone

Jim L — Sun, 05 Apr 2026 00:07:33 +0000

Cursor dropped version 3 on April 2 with a codename — Glass — and a rebuilt interface that moves the code editor into the passenger seat.

The pitch: you describe tasks in natural language, AI agents write the code, and you orchestrate. It sounds like marketing copy until you actually open the Agents Window and see three parallel tasks running across different repos simultaneously.

What Actually Changed

The old Cursor was a VS Code fork with an AI sidebar. Version 3 is something else entirely. The Agents Window is a separate workspace where each task gets its own context, its own file access, and its own execution thread. You can run local agents or cloud agents — the cloud ones persist even when you close your laptop.

Design Mode is the other big addition. You can point at a UI element and describe what you want changed. It generates the code, previews the result, and you approve or reject. For React and Next.js projects, this worked surprisingly well in my testing. For anything with complex state management, it struggled.

The Good Parts

Parallel execution is genuine. I ran a test where Agent 1 was refactoring a data layer while Agent 2 was building a new API endpoint. They didn't conflict. The context isolation means each agent sees a consistent snapshot of the codebase, and Cursor handles merging the changes.

Multi-repo support. You can open multiple repositories in a single workspace and run agents across them. For monorepo-heavy teams, this matters.

The prompt box as primary interface. Instead of navigating menus and panels, you describe what you want. "Add error handling to all API routes in /src/api" — and an agent spins up, creates a plan, and starts executing. This felt natural after about 20 minutes.

The Honest Problems

Context window limits hit fast. Large codebases — anything over roughly 50K lines — caused agents to lose track of earlier instructions. I had to break tasks into smaller chunks manually, which somewhat defeats the purpose.

Cloud agents are slow. Local agents respond in seconds. Cloud agents take 30-90 seconds to start, and they run on Cursor's infrastructure. If their servers are loaded (which happened twice during my week of testing), everything stalls.

Price jumped. Pro is still $20/month, but the Business tier at $40/month is where you get unlimited cloud agent hours. The free tier is now almost unusable for real work — you get 5 agent sessions per day.

It is no longer a code editor. If you want fine-grained control over your code, Cursor 3 fights you. The interface prioritizes agent delegation over manual editing. Some developers will hate this.

Who Should Care

If you manage a team shipping features on tight timelines, Cursor 3's parallel agents could save real hours. If you are a solo developer who enjoys writing code, this might feel like a solution to a problem you don't have.

The $2 billion ARR number tells you Cursor found its market. Whether that market includes you depends on how much of your coding you are willing to hand off to agents that are good — but not perfect.

I test AI coding tools as part of my workflow. Previously covered Claude Code, Windsurf, and OpenCode. All opinions are from actual project use, not benchmark screenshots.

For my full review of Cursor 3 Glass and how it compares to other AI coding tools, see this detailed comparison.

My 3-Month Startup Directory Submission Journey — What Actually Moved the Needle

Jim L — Fri, 03 Apr 2026 23:10:02 +0000

Over the last few months I submitted five websites to every free startup directory I could find. Not as a theoretical exercise — I needed backlinks. My domain rating was stuck at 20 and organic traffic was flat.

Here is what actually happened.

Month 1: The Naive Phase

I found a few GitHub repos listing 300+ directories and started submitting to everything. No filtering, no strategy. Just fill form, click submit, next.

Success rate: roughly 40%.

The other 60% was a mix of dead sites (404, parked domains, expired Bubble.io plans), paid-only directories pretending to be free, and forms that silently failed. I spent about 15 hours that first month and submitted to maybe 80 directories. Of those, about 30 actually listed my sites.

The worst time wasters were directories running on Bubble.io with expired plans. They look legit until you hit submit and get a deployment error. I counted 12 of these in one week.

Month 2: Getting Strategic

I started sorting directories by Ahrefs DR before submitting. Anything below DR 20 went to the bottom of the list. DR 50+ got done first.

Three discoveries changed my approach:

Blog comments work. I found a WordPress blog with DR 63 that gives dofollow links through the URL field in blog comments. One genuine comment with my website URL in the website field. No review process, no waiting. This single discovery was worth more than 20 low-DR directory submissions combined.

I eventually compiled the full list of verified directories into a startup directory submission guide with DR ratings and submission notes for each one.

Profile backlinks are underrated. Crunchbase (DR 91), Disqus (DR 91), StackShare (DR 89) — creating a profile on each of these takes under 10 minutes and gives you a link from a domain most people would pay good money for. Nobody talks about this because it is not exciting. But it works.

Badge exchange is worth it. Some directories like twelve.tools (DR 80) and wired.business (DR 73) require you to put a small badge in your site footer. In exchange you get a dofollow link from a high-DR domain. The math works out heavily in your favor.

Month 3: The Numbers

After three months of systematic directory work across five websites:

Domain rating: 20 to 29 (Ahrefs)
Referring domains: 15 to 72
Directories submitted: 200+
Actually listed: roughly 110
Dead or fake: 60+
Paid-only (despite claiming free): 30+
Dofollow confirmed: about 70

The directories that consistently showed up fastest in Ahrefs backlink reports: SaaSHub, ExactSeek, sitelike.org, twelve.tools, and Crunchbase profiles. Most others took 2-4 weeks to get crawled.

What I Would Tell Someone Starting Today

Start with DR 50+ directories. The ROI on low-DR directories is almost zero for SEO purposes.

Batch your submissions to 5-10 per day. Some directories share IP tracking and will flag rapid submissions.

Keep a spreadsheet. Track: directory name, DR, submit URL, whether you need to log in, CAPTCHA type, and submission date. You will forget what you already submitted otherwise.

Do not pay for directory submissions. Every directory worth submitting to has a free tier. The paid-only directories at $29-149 per listing are not worth it when free alternatives with similar or higher DR exist.

My Shortlist: Start With These 10

If I had to pick just 10 directories to submit to first:

Crunchbase (DR 91) — profile with website link
twelve.tools (DR 80) — badge exchange, dofollow
ExactSeek (DR 73) — simple form, dofollow, 1/day limit
wired.business (DR 73) — badge exchange, dofollow
sitelike.org (DR 71) — text CAPTCHA, dofollow
Future Tools (DR 69) — AI tools focus
SaaSHub (DR 55) — URL-only form, auto-detect
SubmissionWebDirectory (DR 61) — image CAPTCHA
Startup Inspire (DR 48) — multi-category
Mamavation (DR 63) — blog comment, instant dofollow

I documented over 200 directories with DR scores, submit URLs, link types, and specific notes about CAPTCHAs and gotchas. That resource covers everything in detail if you want to go deeper.

The honest truth is that directory submissions alone will not get you to DR 50. But they are the foundation. Combined with profile backlinks, blog comment links, and content that naturally attracts links, the compound effect adds up faster than most people expect.

I Tested the Fastest-Growing GitHub Repo Ever — Here Is What Claw Code Actually Does

Jim L — Fri, 03 Apr 2026 01:42:18 +0000

Last week, a packaging mistake at Anthropic leaked 512,000 lines of Claude Code's source. Within 48 hours, someone rebuilt the entire agent harness from scratch. That project — Claw Code — just crossed 100,000 GitHub stars.

I installed it, pointed it at three of my projects, and ran it alongside Claude Code to see what holds up.

What Claw Code Actually Is

Claw Code is a Python/Rust rewrite of the agent architecture behind Claude Code. It reads your codebase, plans edits, runs terminal commands, and iterates until the task is done. The key difference: it works with any LLM — GPT-4.1, Claude via API, Gemini, even local models through Ollama.

The project calls itself a "clean-room reimplementation," meaning the developers studied the leaked architecture and rebuilt without copying Anthropic's proprietary code. Whether that distinction matters legally is still an open question.

How It Performed

Simple bug fix (missing null check in a Prisma query): Claw Code found and fixed it in 47 seconds. Claude Code did it in 30. Close enough for a v0.3 project.

Multi-file feature (adding a user preference toggle across 5 files): Claw Code got 4 out of 5 right on the first pass. It missed the test file. Claude Code nailed all 5.

Major refactoring (extracting a payment service from a 2,000-line monolith): This is where things broke down. Claw Code got stuck in a loop trying to import a module it hadn't created yet. After three restarts, it worked — but took roughly 8x longer than Claude Code.

Where It Falls Short

Multi-agent orchestration crashes on complex tasks
No rollback mechanism — bad edits mean manual git revert
Windows support is flaky (path handling bugs)
Memory management is primitive — it truncates rather than compresses context, so it "forgets" earlier parts of long sessions

The Model-Agnostic Advantage

The one area where Claw Code clearly wins: LLM flexibility. I ran it with GPT-4.1, Claude Sonnet 4.6 (via API), and a local Qwen3 30B through Ollama. Each worked, though quality varied dramatically. For teams locked into a specific LLM provider or running sensitive code that can't leave their network, this matters.

Should You Try It?

If you want to understand how AI coding agents work under the hood — absolutely. The codebase is readable, well-structured, and teaches you more about agent architecture than any blog post.

If you need a reliable daily driver — stick with Claude Code, Cursor, or Codex. Claw Code is a fascinating experiment, not a production tool.

For a detailed comparison with benchmarks and methodology, I wrote a full review here.

The Free AI Coding Tool Landscape Just Changed and Here Is What I Switched To

Jim L — Thu, 02 Apr 2026 04:15:35 +0000

I've been bouncing between free AI coding tools for about eight months now. Not because I enjoy the constant context-switching — I don't — but because the free tiers keep changing. One month Copilot's generous, the next they throttle completions. So you adapt.

Last week I finally settled on a setup I'm actually happy with, and the catalyst was Gemini Code Assist dropping its paid wall entirely.

My old setup (and why it fell apart)

For most of late March I was running Copilot's free tier inside VS Code. It worked. The completions were decent for boilerplate — React components, SQL queries, that sort of thing. But I kept hitting the monthly suggestion cap at the worst possible moments. Always mid-sprint, always on a Friday afternoon.

I tried supplementing with Codeium. Fine for autocomplete, weak on multi-file reasoning. If I asked it to refactor a service layer that touched three files, it'd confidently edit two and hallucinate imports from a package that didn't exist.

Gemini Code Assist going free changed everything

Google quietly made Gemini Code Assist free for individual developers in their March update. No waitlist, no credit card, just install the extension.

I was skeptical. Google's track record with developer tools is... uneven. But after two weeks of daily use, here's where I've landed:

What actually works well:

Multi-file context. It handles monorepo navigation better than anything else I've tried at this price point (free). I pointed it at a Next.js app with 40+ route files and it correctly traced a bug through three layers of middleware.
The chat interface is fast. Sub-second responses for most questions. Copilot's chat feels sluggish by comparison.
Gemini 2.5 Pro under the hood means the reasoning quality on architecture questions is genuinely solid.

What doesn't:

Inline completions are hit-or-miss. Sometimes brilliant, sometimes it autocompletes a function signature that doesn't match the types I defined six lines up. Copilot still edges it out for pure autocomplete speed and accuracy.
No terminal integration. I can't ask it to run tests or explain error output without copy-pasting. Minor, but it adds up.
Extension conflicts. If you're running both Copilot and Gemini Code Assist, VS Code occasionally freezes for 2-3 seconds while they fight over who gets to suggest first.

I wrote a detailed breakdown of Gemini Code Assist's free tier after my first week with it, if you want the full picture.

Where cloud agents fit in (and where they don't)

The other big shift I've been watching is cloud-based coding agents — tools like OpenAI's Codex and Anthropic's Claude Code that run in sandboxed environments and execute code autonomously.

I tested both for a side project: migrating a Flask API to FastAPI. The kind of tedious, well-defined task that should be perfect for an autonomous agent.

Codex handled the route conversion cleanly but choked on the async database layer. It kept generating synchronous SQLAlchemy calls wrapped in asyncio.to_thread(), which technically works but defeats the purpose. Claude Code got further — it actually rewrote the DB layer properly — but burned through my free credits in about 40 minutes of back-and-forth.

The fundamental tradeoff: cloud agents are powerful but expensive, and the free tiers are thin. Local tools like Gemini Code Assist give you unlimited usage but less autonomy. For my workflow, I use the cloud agents for one-off complex refactors and keep Gemini running for daily coding.

I found a solid comparison of cloud vs local coding agents that maps out these tradeoffs in more detail than I can here.

My current stack (April setup)

After all the experimentation, this is what I'm running daily:

Primary: Gemini Code Assist (VS Code extension) — unlimited completions, good multi-file reasoning, free chat
Backup autocomplete: Copilot free tier — I keep it installed but disabled by default, toggle it on when Gemini's suggestions feel off
Heavy lifting: Claude Code via terminal — reserved for large refactors, maybe twice a week

Total monthly cost: $0.

Is it as good as paying $19/month for Copilot Pro or Claude Pro? No. The completions are slower, the context windows are smaller, the autonomy is limited. But for solo projects and learning, it's more than enough.

What I'd tell someone starting fresh

Skip the paid tiers until you've actually hit a wall with the free ones. I spent three months paying for Copilot Pro before realizing I used maybe 30% of its features. The free tools have gotten genuinely capable — not because any single one is perfect, but because you can layer them.

The one thing I'd watch out for: don't install five AI extensions simultaneously and expect VS Code to behave. Pick two, max. Your RAM will thank you.

I write about developer tools and the weird economics of AI pricing. If you found this useful, I'm @jimliu_dev on Dev.to.

I Tracked Every Hidden Fee on My Streaming Subscriptions for 6 Months — Here's What I Found

Jim L — Thu, 02 Apr 2026 02:26:11 +0000

I Tracked Every Hidden Fee on My Streaming Subscriptions for 6 Months — Here's What I Found

I cut the cord in 2022. Cancelled cable, returned the box, felt great about saving around $180 a month. Fast forward to last October, when I finally sat down and added up what I was actually paying for streaming. The number was... not what I expected.

So I started tracking every charge. Not just the subscription prices — every tax, surcharge, price bump, and sneaky renewal. Six months of obsessive spreadsheet work. Here's what fell out of it.

The Spreadsheet That Ruined My Day

When I started, I thought I was paying roughly $65 a month for streaming. I had Netflix, Hulu, Disney+, and a YouTube TV subscription for live sports. Manageable.

The actual number for October? $94.37.

Where was the other $29 hiding?

Fee #1: Streaming Taxes Are Real and They Vary Wildly

This was the biggest surprise. Depending on your state, streaming services get taxed as "digital goods" or "amusement services." I'm in Pennsylvania, which charges a 6% sales tax on streaming.

But here's the thing — not every service displays the tax the same way. Netflix shows it on your bank statement but not in the app. Hulu shows it in the billing section if you dig. YouTube TV buries it in a PDF invoice you have to specifically request.

Over six months, I paid roughly $34 in streaming taxes across four services. Not catastrophic, but it's money I wasn't accounting for.

If you're in Chicago, it's worse. They have an additional 9% "amusement tax" on top of state tax. A friend there is paying almost $8/month just in streaming taxes.

Fee #2: The Price Increases That Happened Without Me Noticing

This is the one that genuinely annoyed me. Between October and March, three of my four services raised prices:

Netflix Standard went from $15.49 to $17.99 (I got the email but ignored it)
Hulu no-ads bumped from $17.99 to $18.99
Disney+ no-ads went from $13.99 to $16.99

YouTube TV stayed at $72.99, which felt like a relief until I remembered that it was $65 when I signed up.

Combined, those three increases added about $7.50/month to my bill. Over a year, that's $90 I didn't budget for.

The real problem is that these happen gradually. A dollar here, three dollars there. Each individual email is easy to dismiss. But they compound.

The Full Damage — Month by Month

Month	Netflix	Hulu	Disney+	YouTube TV	Taxes/Fees	Total
Oct	$15.49	$17.99	$13.99	$72.99	~$5.70	$126.16
Nov	$15.49	$17.99	$13.99	$72.99	~$5.70	$126.16
Dec	$17.99	$17.99	$13.99	$72.99	~$5.80	$128.76
Jan	$17.99	$18.99	$16.99	$72.99	~$6.00	$132.96
Feb	$17.99	$18.99	$16.99	$72.99	~$6.00	$132.96
Mar	$17.99	$18.99	$16.99	$72.99	~$6.00	$132.96

Six-month total: $779.96

I started tracking all my subscriptions in a spreadsheet, but eventually found tools like SubSaver that make comparing shared plan prices much easier -- especially for services that offer family or group discounts.

That's roughly $130/month. Remember when I thought it was $65?

And yes — I realize I was also paying for YouTube TV, which I'd somehow mentally categorized as "TV" rather than "streaming" when I did my original estimate. That's its own kind of denial.

Fee #3: The Auto-Renewal Trap (My Disney+ Story)

In January, I decided to cancel Disney+ because I hadn't watched anything on it in three weeks. I opened the app, poked around the settings, found the cancellation page, and it hit me with "Your subscription renews tomorrow — cancel now and lose access immediately."

I hesitated. Closed the app. Forgot about it for two months.

That moment of friction cost me about $34. Disney+ knows exactly what it's doing with that cancellation flow.

I eventually cancelled in March, but the lesson stuck: the gap between "I should cancel this" and actually doing it is where streaming companies make their money. They don't need you to watch. They need you to not cancel.

What I Actually Changed

After six months of data, I made some moves:

Dropped to fewer simultaneous subscriptions. I now keep two at a time and rotate quarterly. Netflix and Hulu for three months, then swap one for Disney+ or Max. I watch what I want to watch, then move on. Monthly cost dropped to around $40 plus taxes.

Switched to ad-supported tiers where I could tolerate it. Hulu with ads is $10 instead of $19. The ads are annoying but not unbearable. Netflix basic with ads is $7.99. Together that saves me roughly $20/month.

Set calendar reminders for renewal dates. Not the "your subscription renews tomorrow" email from the service — my own reminder a week before, so I have time to decide if I actually used it.

Checked for bundle overlap. I was paying for Hulu separately while also being eligible for the Disney Bundle through my phone plan. That was just wasted money for four months.

Started using free tiers I'd forgotten existed. Tubi, Pluto TV, and The Roku Channel have more watchable content than I expected. Not everything, but enough to fill gaps between paid subscriptions.

The Math After Changes

Current monthly spend: around $47 with taxes (two services, one ad-supported).

Before tracking: around $130/month.

Annual savings: roughly $1,000.

A thousand dollars a year. For sitting down and looking at my bank statements for an hour.

The Uncomfortable Truth About Cord-Cutting

Cord-cutting saved me money compared to cable, but only because I was disciplined about it in the first year. After that, subscription creep kicked in. Each service was "only" $10-18 a month. Each price increase was "only" a dollar or two. Each tax was "only" a few percent.

Stacked up, I was paying 72% of what my old cable bill was. And I didn't even have live news or local channels.

The streaming companies are counting on you not adding it up. The whole model works because the payments are small, automatic, and spread across multiple apps so you never see a single bill.

Track your spending. Even for a single month. The number will probably surprise you.

I Subscribed to Hong Kong IPOs for 8 Months — What Actually Made Money

Jim L — Thu, 02 Apr 2026 00:27:31 +0000

I started subscribing to Hong Kong IPOs last August with HKD 50,000 in a brokerage account and a spreadsheet. Eight months and 12 IPO applications later, I've made a net profit of about HKD 8,200 — roughly 16.4% return.

That sounds decent until you realize three of those twelve lost money, four broke roughly even, and all the profit came from just two deals.

How HK IPO Subscription Actually Works

For anyone unfamiliar with the mechanics: when a company lists on the Hong Kong Stock Exchange, retail investors can apply for shares at the IPO price during a subscription window (usually 4-5 business days). You put up cash or margin financing, get allocated some shares (or none), and then sell on listing day or hold.

The key concept is the "one-lot strategy" — you apply for the minimum lot size, usually 100-500 shares depending on the stock price. This maximizes your allocation probability because HK IPOs use a clawback mechanism that favors small retail applicants when demand is high.

One lot typically costs between HKD 2,000 and HKD 20,000 depending on the share price. Your capital is locked for roughly 5-7 business days from application to listing.

The Two That Paid for Everything

Huayan Intelligence (华燕智能, 2月上市): This was the robotics company that got something like 5,000x oversubscribed in the retail tranche. I applied for one lot (500 shares at HKD 10.28 each, so about HKD 5,140 committed). Got my one lot — the allocation rate was brutal but the one-lot guarantee kicked in.

It opened at HKD 18.60 on listing day. I sold at HKD 17.80 after it dipped from the open. Net profit after fees: roughly HKD 3,700.

A chipmaker IPO in November (I won't name it because I still hold a small position): Applied for one lot at HKD 42 per share, 200 shares. Listing price jumped to HKD 58. Sold half on day one, kept the rest. That half-sale netted about HKD 3,200.

Those two deals alone account for HKD 6,900 of my total HKD 8,200 profit.

The Losers

A biotech company in October: Classic mistake. Applied because the company had a cool pipeline, ignored that biotech IPOs in HK have a terrible track record for retail investors. It dropped 12% on listing day. I ate an HKD 800 loss on one lot and learned my lesson about sector patterns.

An EV component supplier in January: Priced at what seemed reasonable, but the grey market (暗盘) was already trading below IPO price the night before listing. I should have sold in the grey market when I saw that signal. Instead I held to listing, watched it open down 8%, and took about HKD 600 in losses.

A logistics tech company in December: Tiny loss, maybe HKD 200. Just a nothing IPO with no momentum.

What I Learned About Which IPOs to Apply For

After 12 attempts, my rough filter:

Apply when: Subscription multiple above 100x (check real-time subscription data from brokers), company is in AI/robotics/chips (the market has a clear appetite), sponsor is a tier-1 bank (Goldman, Morgan Stanley, CICC), and the grey market price on 富途/moomoo the evening before listing is above IPO price.

Skip when: Biotech pre-revenue, subscription under 20x, mainland property developers (the market is done with these), or when more than 3 IPOs are listing in the same week (capital gets diluted).

The grey market signal is probably the single most useful indicator. If 暗盘 is trading below IPO price, you're almost certainly going to lose money on listing day. I now check this religiously and have avoided two bad deals because of it.

The Capital Lock-Up Problem Nobody Talks About

Here's the thing that bothered me most. When you apply for a hot IPO, your capital — or your margin limit — is locked for nearly a week. During that time, you can't use that money for anything else.

For my HKD 50,000 account, applying for 2-3 IPOs in the same period could tie up 60-80% of my capital. There were weeks in Q1 where Hong Kong had 4-5 IPOs launching simultaneously and I had to pick which ones to allocate to.

The opportunity cost is real. That HKD 50,000 sitting in a savings account would earn maybe HKD 150/month in interest. If my capital is locked in IPO applications 40% of the time and I'm picking wrong half the time... the math gets questionable fast.

Q1 2026: Hong Kong's Moment

To be fair, this has been an unusually good period for HK IPOs. The exchange raised over HKD 300 billion in Q1 alone, briefly overtaking both NYSE and Nasdaq for global IPO volume. The pipeline is packed with Chinese tech and AI companies that either can't or won't list in the US due to regulatory uncertainty.

That tailwind won't last forever. The subscription multiples I'm seeing now — 500x, 1000x, even 5000x for Huayan — are not normal. A year ago, most HK IPOs were struggling to get 10x subscribed.

I'm adjusting my expectations downward for the rest of the year.

Broker Comparison: Moomoo vs IBKR

I use moomoo (富途) as my primary IPO broker and IBKR as backup. Quick comparison:

Moomoo: Better for HK IPOs specifically. Real-time subscription data, grey market trading access, 0 commission on IPO shares sold within 30 days (they run this promo frequently), and the interface is designed around the HK retail investor experience. IPO margin financing at about 3.8% annualized. The app is in Chinese, which is fine for me but might not work for everyone.

IBKR: More IPO markets (US, EU, HK, Singapore), but the HK IPO experience is clunky. No grey market access, subscription data is delayed, and the application process has more steps. Lower margin rates overall, but for the 5-7 day IPO lock-up period, the rate difference is negligible.

If you're only doing HK IPOs, moomoo wins. If you want flexibility across multiple markets, IBKR is the safer long-term choice.

The Spreadsheet Tells the Truth

Here's my 8-month summary:

Metric	Value
Total applications	12
Allocated	10 (83%)
Profitable on listing day	5
Loss on listing day	3
Roughly break-even	4
Net profit	~HKD 8,200
Capital deployed	HKD 50,000
Return	~16.4% (8 months)
Annualized	~24.6%

That 24.6% annualized looks great on paper. But it requires active monitoring (I check subscription data daily during IPO windows), occasional grey market trades at odd hours, and the emotional discipline to skip deals when the signals aren't there.

Most months I spent about 3-4 hours total on research and execution. Not passive income by any stretch.

Would I Recommend It?

With caveats.

If you have idle capital in a HK brokerage account anyway — money that's just sitting in a settlement account earning nothing — then applying for high-conviction IPOs with the one-lot strategy is a reasonable use of that capital. The downside per application is small (you lose a few hundred HKD if it drops 5-10% and you sell immediately), and the upside on a hot deal can be meaningful.

If you'd need to wire money specifically for IPO subscriptions, the friction and fees probably aren't worth it unless you're committing at least HKD 100,000+.

And if you're expecting consistent returns — don't. My 16.4% came from exactly two good deals out of twelve. That's not a strategy, that's a sample size problem. Ask me again after 50 applications and I'll have more confidence in whether this actually works long-term or whether I just got lucky during a bull window.

The honest answer is probably somewhere in between.