DEV Community: lfzds4399-cpu

Automated domain investing with hard budget walls and an AI council that has to agree before any money moves

lfzds4399-cpu — Sat, 16 May 2026 11:27:13 +0000

Most "domain finders" on GitHub stop at stage one — they spit out a list of names someone might want to buy. The real work is everything after that: deciding which ones are worth money, not buying the obvious trademark traps, not blowing the monthly budget on a hype day, and actually settling a sale.

I built domain-harness because I wanted to test a small thesis — "AI-generated brandable domains + automated valuation can clear $X / month" — without giving a script direct keys to a registrar and praying.

This post is about the architecture, not the thesis. Specifically: how do you build something that touches money and registrar APIs without losing money the moment the LLM hallucinates?

The pipeline

discover  ─►  value  ─►  acquire  ─►  list  ─►  negotiate  ─►  settle
   │           │           │           │           │
   AI gen +    local +     multi-     Dan /        AI reply
   expired     AI Council  registrar   Afternic    + counter
   feeds       (Claude     fallback   Sedo
               + DeepSeek)

Six stages, all gateable individually, all dry_run by default. The thing that makes it safe is what's between the stages, not the stages themselves.

Defense layer 1: two-tier valuation

Calling an LLM to value every candidate domain is how you waste $50 of tokens on garbage by 11pm. Local heuristic gate first:

Length penalty over 12 chars
Hard-cap punctuation / digit counts
Dictionary-word boost
Brandable phonotactics scoring (CVC patterns score better than xqkz)
Hard reject on hyphens-and-numbers cocktails

Only candidates above min_local_score get billed against the AI Council. In practice this filters about 90% of the discovery output, and the surviving 10% is the only thing worth a token spend.

Defense layer 2: AI Council, not AI Oracle

Every survivor goes to two independent providers — Claude and DeepSeek — with the same prompt:

council = Council(
    [function_voter("claude",   claude_valuator,   weight=1.0),
     function_voter("deepseek", deepseek_valuator, weight=1.0)],
    threshold=2,  # both must clear per-provider threshold
)

Both must clear their threshold before the harness will spend a cent. One model alone is a hallucination machine; two independent models with the same hallucination at the same time is much rarer (and when it does happen, your loss is capped by layer 3 anyway).

Caveat I learned the hard way in a different project: LLM scores are not alpha. In a trading harness I weighted council confidence directly into position size and the high-confidence picks systematically lost money. So in domain-harness the council is a gate, not a size multiplier. It can say "yes / no, the domain is worth it" — it cannot say "buy 5x more of this one."

Defense layer 3: hard budget walls

This is the part that lets me sleep:

daily_cap_usd: $50
monthly_cap_usd: $1000
per_domain_cap_usd: $15

These aren't soft warnings. Every acquisition.buy() call goes through budget_guard.check() and an over-cap call raises BudgetExceeded. The buyer literally cannot exceed them. If any single wall trips, the discovery loop stops and the daemon goes idle until a human re-enables it.

I keep a state file data/budget_state.json with today's spend and this month's spend. The CI smoke test verifies every guard:

[5] 预算守卫硬刹车   ✓ 单域名超过返回拦截（$200 > $15）
                  ✓ 正常金额通过（$10）

Defense layer 4: trademark + WHOIS

A surprising fraction of "great brandable domain" suggestions from LLMs are subtle trademark violations. mygoogle.com is obvious; paypall.io is less obvious; openai-clone.ai is comically obvious but the council will still rank it because it scores "ai".

So:

Static blocklist (Fortune 500 + Anthropic / OpenAI / Stripe / etc).
User-extensible blocklist.
Substring match against the blocklist (so mygoogle.com and openai-clone.ai fail).
WHOIS check before any buy attempt (some "available" feeds lie).

(Edit-distance / typo-variant matching is on the roadmap — goggle.com currently slips past unless you add it explicitly.)

[3] 商标黑名单     ✓ mygoogle.com 拦截
                  ✓ openai-clone.ai 拦截
                  ✓ paywall.com 通过（非商标）
[4] WHOIS 检查    ✓ 注册过的域名识别（google.com）

Defense layer 5: multi-registrar fallback

When the harness decides to buy, it doesn't fail-stop on a single registrar's API hiccup. Priority chain: Porkbun → Cloudflare. If Porkbun returns "unavailable" or 5xx, Cloudflare tries. If both fail, the candidate goes to a re-try queue, not a buy.

Each registrar is a thin adapter — same register(domain, contact) interface, different SDK underneath. The adapter shape is deliberately simple so adding Namecheap or GoDaddy later is a single new file, not a refactor.

Defense layer 6: dry_run by default, opt-in spend

The default mode in .env.example is MODE=dry_run. Every stage knows the mode and short-circuits actual money calls when it's dry_run. The full pipeline runs end-to-end in dry_run so I can backtest discovery → valuation → would-have-bought against a real registrar SDK without paying. To flip to live: change one line, re-read the smoke test results, then change it.

CI runs the 25-case smoke on every push:

汇总：25 PASS / 0 FAIL/ERROR / 共 25

That suite covers every gate — discovery → valuation → trademark → WHOIS → budget guard → duplicate guard → registration → portfolio write → listing → AI negotiation → settle. Failing any one of them blocks merge.

What I'd build differently if starting over

Faster registrar latency profiling. Currently the fallback is static priority. A version 2 should A/B by recent success rate and latency.
Per-vertical AI prompts. The council right now is generic; "this is a fintech domain" vs "this is a SaaS domain" probably wants different valuation framing.
Negotiation memory. The reply bot is stateless per inquiry; same buyer asking three times gets three independent counters.

When this is the wrong tool

You want to register vanity domains for personal projects. This is overkill.
You're already buying via a managed broker. They handle the registrar / settle layers.
You don't want any LLM cost. The council is the heart of the value layer.

When this is the right tool

You want a budget-walled testbed for a domain investing thesis.
You're tired of "I clicked buy and it took $50 because the dropdown defaulted to 5 years."
You want a CI-gated pipeline where every buy decision is auditable and reversible (well — except for the buy, but the decision is).

Get started

git clone https://github.com/lfzds4399-cpu/domain-harness.git
cd domain-harness
pip install -r requirements.txt
cp .env.example .env       # fill in only what you use
python tests/e2e_smoke.py   # 25 PASS in dry_run, no spend

Repo: github.com/lfzds4399-cpu/domain-harness. MIT.

If you're building anything that touches money + LLMs, I'd love to compare notes on which guards you ended up needing vs which ones you removed because they fired too often. Issues / PRs welcome.

Stop reinventing 'ask GPT-4 and Claude and a regex, then count the votes'

lfzds4399-cpu — Sat, 16 May 2026 11:27:12 +0000

If you've ever wired up "ask GPT-4 and Claude and a regex, then count the votes" inside a moderation pipeline, an agent router, or a code-review bot — you've written this code before:

gpt_ok = call_gpt(prompt)
claude_ok = call_claude(prompt)
regex_ok = not contains_blocklist(prompt)

if (gpt_ok and claude_ok) or (gpt_ok and regex_ok):
    return APPROVE
else:
    return REJECT

Then someone asks "what about weighting the senior model 2x?" and the if-tree doubles. Then "what if regex sees a hard policy violation — that should veto everything?" and you bolt on another branch. Then the audit log is a print() you forgot to wire to a file.

I built ai-council because I've written this glue four times across four projects (trading bot, moderation layer, code-review CI, agent router) and the fifth time I gave up and made it a primitive.

The whole API in 10 lines

from ai_council import Council, Vote, function_voter

def gpt4_voter(p, ctx, peers):   return Vote("gpt4",   approve=p["safe_gpt4"],   score=90)
def claude_voter(p, ctx, peers): return Vote("claude", approve=p["safe_claude"], score=85)
def regex_voter(p, ctx, peers):
    bad = "kill" in p["text"].lower()
    return Vote("regex", approve=not bad, score=0 if bad else 100, veto=bad)

council = Council([function_voter("gpt4", gpt4_voter),
                   function_voter("claude", claude_voter),
                   function_voter("regex", regex_voter)], threshold=2)
decision = council.deliberate({"text": "...", "safe_gpt4": True, "safe_claude": True})
print(decision.approved, decision.final_score)

That's it. No subclassing, no orchestrator process, no config files. Each Voter is just an object with a name, a weight, and a vote(proposal, context, peers) method. Inside, the voter can call an LLM, run a regex, hit a database — the framework only cares about the Vote it returns.

What the framework actually owns

Four things stay tangled inside every hand-rolled implementation:

What is being decided (proposal shape)
Who votes (the voter set)
How votes combine (threshold, weights, veto)
Where the audit log lives

ai-council separates them. You bring 1 and 2. The framework owns 3 and 4.

Without ai-council	With ai-council
80 lines of `if a and b and not c:` per project	1 `Council(...)` line + N small voter functions
Threshold logic re-invented (and bugged) every time	`threshold=2` (absolute) or `threshold=0.6` (ratio)
Veto / hard-policy bolted on with extra ifs	`Vote(..., veto=True)` from any voter blocks approval
Weighting senior voters means rewriting the aggregator	`function_voter("senior", fn, weight=2.0)`
Audit log is a `print()`	`JsonMeetingStore("meetings.jsonl")` persists every decision
One flaky LLM call crashes the pipeline	Exceptions captured as `approve=False, score=0` (or `strict=True` to re-raise)

A real-shape example: order approval

Pricing, reviews, stock — three independent signals, one decision:

def cheap_voter(p, ctx, peers):
    cheap = p["price_usd"] < 100
    return Vote("cheap", approve=cheap, score=80 if cheap else 20)

def reviewed_voter(p, ctx, peers):
    rated = p.get("rating", 0) >= 4.5
    return Vote("reviewed", approve=rated, score=85 if rated else 30)

def stocked_voter(p, ctx, peers):
    in_stock = p.get("stock", 0) > 0
    return Vote("stocked", approve=in_stock,
                score=90 if in_stock else 0,
                veto=not in_stock)  # out of stock → hard veto

council = Council(
    [function_voter("cheap", cheap_voter),
     function_voter("reviewed", reviewed_voter),
     function_voter("stocked", stocked_voter)],
    threshold=2,
)
decision = council.deliberate({"price_usd": 79, "rating": 4.7, "stock": 12})

Out-of-stock vetoes the order regardless of price and rating. 2-of-3 must approve otherwise. No nested ifs.

What I learned wiring LLMs as voters

One painful lesson from production: LLM scores are not alpha. In one of my projects (an automated trading harness) I made the council's average score gate the trade size. Two months later the audit showed high-confidence council picks were systematically worse than low-confidence ones. The model "knew" which trades were obvious, and obvious had no edge left.

So: in ai-council you can use LLM voters for veto — "this looks like a scam, block" — but I'd argue against using LLM score as a weighted input to a financial or safety-critical aggregate. The framework lets you do either; the choice is yours, but the bias is real.

When this is the wrong tool

You only have one voter. Just call it.
You need streaming partial votes (e.g., multi-round Socratic deliberation). ai-council is single-round; for streaming agent debate you want something like AutoGen or CrewAI.
You need a UI for human voters in real time. This is a Python library, not a service.

When this is the right tool

Moderation gates ("approve if 2 of {gpt4, claude, regex} agree, but any single one can veto").
Agent routing decisions ("which sub-agent handles this — let three rankers vote").
Code-review bots ("approve if linter, model, and security scanner all agree").
Trading or financial guard rails (use as veto layer, not scoring layer).
Anywhere "ask multiple independent signals, combine, log" is the shape.

Get started

pip install git+https://github.com/lfzds4399-cpu/ai-council.git

Requires Python 3.11+. Zero runtime dependencies (the Optional[LLM voter examples] pull in whatever LLM SDK you want). MIT.

Repo: github.com/lfzds4399-cpu/ai-council

If you've been writing this glue too, I'd love feedback on the API and edge cases that bit you in production. Issues / PRs welcome.