DEV Community: ai

Portfolio Stress Testing: Essential Black Swan Defense

Vladimir Lialine — Sat, 12 Sep 2026 13:40:22 +0000

A backtest can look exceptional until markets enter a regime that has never appeared in the training data. Portfolio stress testing addresses that blind spot by measuring how positions, leverage, liquidity, and hedges behave during extreme but plausible events. For hedge funds, the objective is not to predict the next crisis. It is to generate difficult scenarios before real markets expose hidden concentration and path-dependent risks.

How Portfolio Stress Testing Models Black Swans

A synthetic market crash simulation is a computer-generated sequence of market conditions designed to reproduce or extend the behavior of severe selloffs. Unlike a single historical replay, it can vary the order, speed, duration, and cross-asset transmission of shocks.

A robust simulation should model returns as interacting components:

Asset return = factor exposure × factor shock + idiosyncratic shock

Factor shocks may include equity drawdowns, volatility spikes, interest-rate jumps, currency dislocations, and widening credit spreads. Idiosyncratic shocks capture risks specific to individual securities or strategies.

Effective portfolio stress testing must also account for:

Correlation breakdown: Assets that appeared diversified may fall together.
Liquidity evaporation: Bid-ask spreads widen while market depth disappears.
Volatility feedback: Rising volatility can trigger deleveraging and further selling.
Margin pressure: Collateral requirements may increase during the drawdown.
Execution slippage: Model prices can differ substantially from tradable prices.
Path dependency: A gradual decline may produce different losses than a sudden gap.

These mechanics turn a static loss estimate into a realistic test of portfolio survival.

Building a Synthetic Market Crash Simulation

Historical crises remain useful calibration anchors, but copying them exactly creates false confidence. Markets evolve, and the next shock may combine features that have never occurred together. AI scenario generation can expand the test space by creating thousands of internally consistent paths.

Constrain AI With Financial Reality

Unconstrained generative models may produce dramatic yet economically impossible scenarios. Each generated path should therefore pass explicit rules for covariance, price continuity, volatility clustering, and balance-sheet constraints.

A practical workflow is:

Estimate normal regimes using clean, point-in-time market data.
Identify tail dependencies between factors, assets, and funding conditions.
Generate shock paths with different speeds, magnitudes, and recovery shapes.
Apply liquidity costs based on stressed volume and market depth.
Revalue positions dynamically, including options and leveraged exposures.
Measure failure points, such as margin breaches or concentration-limit violations.
Challenge the results with scenarios excluded from model training.

Platforms such as AI-QUANT quantitative trading technology can support systematic scenario research and help teams compare strategy behavior across generated market regimes.

Turning Stress Results Into Black Swan Hedging

A stress test is valuable only when it changes a decision. Risk teams should examine maximum drawdown, time to recovery, stressed liquidity, margin utilization, and conditional value at risk. Conditional value at risk estimates the average loss beyond a selected loss threshold.

The results can guide black swan hedging decisions, including reducing gross exposure, diversifying risk factors, adding convex protection, or holding more liquid collateral. However, protection must be evaluated after premiums, carry costs, slippage, and hedge decay. A hedge that works in one instantaneous shock may fail during a prolonged decline.

Governance is equally important. Models require version control, independent validation, documented assumptions, and checks for data leakage. Broader technology organizations such as HONEYPOTZ INC and DEEPBODY INC reinforce the value of disciplined data and AI oversight across technical applications.

Key Takeaways and FAQs

Can synthetic crashes predict the next crisis?

No. They reveal portfolio weaknesses across a wider range of plausible conditions rather than forecasting a specific event.

How often should hedge funds run stress tests?

Core scenarios should run daily or weekly, with deeper reviews after major allocation, leverage, liquidity, or market-regime changes.

What makes a scenario credible?

Credible scenarios combine severe shocks with realistic cross-asset relationships, trading constraints, funding costs, and transparent assumptions.

Portfolio resilience should be engineered before volatility arrives. Explore AI-QUANT for AI-driven scenario generation and quantitative risk research to start testing your strategies against the crashes history has not yet recorded.

[SMS] Stay Connected - SMS Alerts

Want exclusive offers, early access to Private EDGE OS, and AI longevity insights delivered straight to your phone?

Text EDGE10 to claim $10 off →

No spam. Reply STOP to unsubscribe anytime.

Before You Build: A Practical Diagnosis for Commercial Software Proposals

Natanael — Sat, 12 Sep 2026 13:37:26 +0000

When a software proposal starts with “we need an app,” the riskiest part is often not the code. It is the missing decision about what should be built first.

A short technical-commercial diagnosis can reduce that uncertainty before implementation begins.

A five-step diagnosis

1. Define the decision

Write the decision the project must enable. Examples:

Should we build a mobile app or start with a web workflow?
Is an integration technically feasible with the available API?
Which part of the process should be automated first?

If the decision is vague, the implementation will be vague too.

2. Separate requirements from preferences

Requirements are constraints that must be satisfied: users, inputs, outputs, compliance, latency, integrations and delivery format. Preferences are choices that can change: framework, visual style, hosting provider or optional features.

This distinction keeps a small first version from becoming an unbounded project.

3. Map dependencies and risks

List the external systems, data, credentials, policies and human decisions that the project needs. Mark each dependency as available, uncertain or missing. A risk is useful only when it includes a mitigation or a decision point.

4. Recommend the smallest credible next step

The output should be actionable: a prototype, an API spike, a requirements clarification, a short audit or a bounded implementation. Avoid promising a complete system before the unknowns are understood.

5. Define acceptance criteria

A diagnosis is complete when the buyer can check it. For example: requirements are listed, dependencies are identified, risks have mitigations, an architecture direction is recommended and the next implementation step is explicit.

A reusable workflow

I maintain a small downloadable HTML workflow called Pulse for diagnosing commercial proposals. It is intended for agencies, local businesses and sales teams. It provides a standalone file, quick-start material and a structured way to turn an unclear request into a focused next step.

You can review it here: https://moralesalerson.gumroad.com/l/pulse

The workflow is a starting point, not a guarantee of a business or technical outcome. Review its output against your own requirements before making decisions.

Building Streaming LLM Applications: Best Practices and Examples

shashank ms — Sat, 12 Sep 2026 13:34:04 +0000

We are going to build a streaming DevOps log triage agent that reads raw server logs and emits a structured markdown report token by token. This cuts perceived latency during incidents because operators see the severity and summary as soon as the model generates them, not after a full round-trip wait.

What you'll need

Python 3.10 or newer
The OpenAI SDK: pip install openai
An Oxlo.ai API key from https://portal.oxlo.ai

Step 1: Initialize the Oxlo.ai client and verify streaming

I start by importing the SDK and pointing it at Oxlo.ai. I also run a one-word sanity check to confirm streaming works.

from openai import OpenAI

client = OpenAI(base_url="https://api.oxlo.ai/v1", api_key="YOUR_OXLO_API_KEY")

response = client.chat.completions.create(
    model="llama-3.3-70b",
    messages=[
        {"role": "user", "content": "Say hello in one word."},
    ],
    stream=True,
)

for chunk in response:
    print(chunk.choices[0].delta.content or "", end="", flush=True)
print()

Step 2: Define the system prompt

The system prompt forces a consistent markdown structure so downstream tools can parse the report without extra formatting noise.

SYSTEM_PROMPT = """You are a DevOps triage agent. Analyze the provided server logs and produce a structured markdown report with exactly these sections:

## Severity
## Summary
## Likely Cause
## Remediation

Keep responses concise. Use bullet points where helpful. Do not ask clarifying questions."""

Step 3: Build the streaming consumer

Now I wrap the call in a function that prints each delta as it arrives. This keeps the terminal updating in real time instead of blocking until the full response is ready.

def triage_logs(log_text: str):
    response = client.chat.completions.create(
        model="llama-3.3-70b",
        messages=[
            {"role": "system", "content": SYSTEM_PROMPT},
            {"role": "user", "content": f"Analyze these logs:\n\n{log_text}"},
        ],
        stream=True,
        temperature=0.2,
    )

    print("=== TRIAGE REPORT ===")
    for chunk in response:
        token = chunk.choices[0].delta.content or ""
        print(token, end="", flush=True)
    print("\n=====================")

Step 4: Add timing and error handling

Measuring time to first token is essential for SLA monitoring. I also catch API errors so a network blip does not crash the whole pipeline.

import time
import sys
from openai import APIError

def triage_logs(log_text: str):
    start = time.time()
    first_token_time = None

    try:
        response = client.chat.completions.create(
            model="llama-3.3-70b",
            messages=[
                {"role": "system", "content": SYSTEM_PROMPT},
                {"role": "user", "content": f"Analyze these logs:\n\n{log_text}"},
            ],
            stream=True,
            temperature=0.2,
        )
    except APIError as e:
        print(f"Oxlo.ai API error: {e}", file=sys.stderr)
        sys.exit(1)

    print("Starting stream...")
    for chunk in response:
        if first_token_time is None:
            first_token_time = time.time() - start
            print(f"\n[Time to first token: {first_token_time:.2f}s]\n", flush=True)

        token = chunk.choices[0].delta.content or ""
        print(token, end="", flush=True)

    total = time.time() - start
    print(f"\n[Total elapsed: {total:.2f}s]")

Step 5: Wrap it in a CLI

Finally, I add a minimal argparse interface so the script can be dropped into a shell pipeline or called from a runbook.

import argparse

if __name__ == "__main__":
    parser = argparse.ArgumentParser(description="Stream a triage report from Oxlo.ai")
    parser.add_argument("--logs", required=True, help="Raw server logs to analyze")
    args = parser.parse_args()

    triage_logs(args.logs)

Run it

Save the complete script as triage.py, set your key, and pass a sample nginx timeout log.

export OXLO_API_KEY="YOUR_OXLO_API_KEY"
python triage.py --logs "2024-05-20T14:32:01Z nginx: upstream timed out (110: Connection timed out) while connecting to upstream, client: 10.0.1.42, server: api.example.com, request: \"POST /v1/batch HTTP/1.1\", upstream: \"http://10.0.2.15:8080/v1/batch\", host: \"api.example.com\""

Typical streamed output looks like this:

Starting stream...

[Time to first token: 0.38s]

## Severity
High

## Summary
- Repeated upstream timeout errors from nginx to the internal batch service at 10.0.2.15:8080.
- Issue isolated to the /v1/batch endpoint.

## Likely Cause
- The upstream application server is either overloaded, crashed, or unreachable due to a network partition.

## Remediation
- Check CPU and memory on 10.0.2.15.
- Verify the batch service process is running and listening on port 8080.
- Review recent deployments to the batch service.
- Consider scaling the backend or increasing the nginx proxy_connect_timeout if the service is slow but healthy.

[Total elapsed: 2.08s]

Wrap-up and next steps

Because Oxlo.ai uses request-based pricing, feeding long log dumps into this agent does not inflate cost the way token-based providers do. You can see exact plan details at https://oxlo.ai/pricing.

Two concrete ways to extend this: wire the script into an alerting webhook so it triggers on PagerDuty incidents, or switch to the async AsyncOpenAI client to triage multiple log files in parallel without blocking.

ULTIMATE NON-SERVER WORKSTATION

Cyber Code Master — Sat, 12 Sep 2026 13:32:43 +0000

🏆 ULTIMATE NON-SERVER WORKSTATION — MASTER SPECIFICATION

Fully merged • compatibility-corrected • performance-first • Cyber-Ice RGB edition 🔒

Design goal: Push a single-socket workstation to the highest practical workstation-class level without crossing into server architecture, while retaining extreme AI, rendering, simulation, professional video/photo editing, 4K gaming, and creator capability.

Rule: RGB is allowed only where it does not compromise compute, PCIe topology, storage, power delivery, cooling, reliability, or physical fit.

🔒 FINAL COMPONENT MASTER TABLE

#	Category	Final Component / Model	Qty	Key specification / role	Status
1	🧠 CPU	AMD Ryzen Threadripper PRO 9995WX	1	96C / 192T, Zen 5, up to 5.4 GHz, 384 MB L3, 350 W, sTR5	🔒
2	🏗️ Motherboard	ASUS Pro WS WRX90E-SAGE SE	1	WRX90, sTR5, EEB, 8-channel RDIMM, massive PCIe 5.0 expansion	🔒
3	🧠 System RAM	Samsung M321RBGA0B40-CWK 256 GB DDR5-4800 ECC RDIMM	8	2 TB total, 8-channel, high-density RDIMM	🔒
4	🎮 GPU	NVIDIA RTX PRO 6000 Blackwell Workstation Edition	4	96 GB GDDR7 ECC each, PCIe 5.0 ×16, 600 W each	🔒
5	⚡ PSU	Corsair WS3000 Workstation	2	3,000 W each, 6,000 W combined, ATX 3.1	🔒
6	🧊 CPU Water Block	Watercool HEATKILLER IV PRO for Threadripper ACRYL NICKEL-BLACK — 18027	1	sTR5-compatible, integrated RGB appearance	🔒
7	🎮 GPU Water Block	Alphacool ES RTX 6000 Pro Workstation	4	Exact RTX PRO 6000 Workstation Edition block, compact ~1.5-slot design	🔒
8	❄️ External Radiator	WATERCOOL MO-RA IV 600	2	One dedicated CPU loop, one dedicated GPU loop	🔒
9	🏠 Chassis	Phanteks Enthoo Pro II Tempered Glass — PH-ES620PTG_DBK01	1	SSI-EEB, 11 slots, 305×330 mm board support, large GPU/storage capacity	🔒
10	🔧 PSU Mounting	Custom dual-ATX PSU mounting plate	1	Mechanical solution for the 2× WS3000 installation	🔒
11	💾 NVMe	Samsung 9100 PRO 8 TB	4	PCIe 5.0 ×4, extreme-performance M.2 tier	🔒
12	🚀 Enterprise NVMe	Samsung PM1733a 30.72 TB	2	PCIe 4.0 ×4 U.2-class enterprise NVMe	🔒
13	🗄️ HDD	Seagate Exos 32 TB CMR	4	SATA 6 Gb/s, enterprise bulk storage	🔒
14	📡 Wi-Fi / Bluetooth	Intel Wi-Fi 7 BE200	1	M.2 Key-E, Wi-Fi 7 2×2, Bluetooth 5.4	🔒
15	🌐 Ethernet	ASUS onboard dual 10GbE	2 ports	High-speed wired networking	🔒
16	🎥 Internal PCIe video I/O	None	—	DeckLink removed to protect 4-GPU physical layout	🔒
17	🖥️ Main Display	ASUS ProArt Display OLED PA32UCDM	1	31.5", 4K, QD-OLED, 240 Hz	🔒
18	🎨 Pen Display	Wacom Cintiq Pro 27	1	27", 4K, 120 Hz professional pen display	🔒
19	⌨️ Keyboard	Keychron Q6 Max	1	Full-size mechanical, QMK/VIA	🔒
20	🖱️ Mouse	Logitech MX Master 4	1	Professional productivity/creative mouse	🔒
21	🎛️ Control Surface	Elgato Stream Deck+	1	8 keys + 4 dials + touch strip	🔒
22	⚡ PDU	Vertiv Geist monitored PDU	2	One distribution path per PSU	🔒
23	🛡️ UPS	Vertiv Liebert GXT5 10 kVA / 10 kW	1	Online double-conversion UPS	🔒

🧠 CPU + PLATFORM

Specification	Final
CPU	Threadripper PRO 9995WX
Cores / threads	96 / 192
Socket	sTR5
Platform	WRX90
Memory architecture	8-channel DDR5 ECC RDIMM
PCIe architecture	Up to 128 PCIe 5.0 lanes
Motherboard	ASUS Pro WS WRX90E-SAGE SE
Motherboard form factor	EEB
Workstation boundary	Single-socket / non-server

Role

This is the central compute platform for:

AI • CPU rendering • simulation • compilation • virtualization • scientific workloads • professional applications

🧠 SYSTEM MEMORY

8× Samsung 256 GB ECC RDIMM

Parameter	Final
Modules	8
Capacity/module	256 GB
Total	2 TB
Type	DDR5 ECC RDIMM
Speed	4800 MT/s
Organization	8Rx4
Channels populated	8
Voltage	1.1 V

Theoretical aggregate bandwidth

≈307.2 GB/s

Design philosophy

We deliberately prioritize:

2 TB capacity + ECC + 8-channel operation + high-density workstation stability

over chasing a higher DIMM frequency at reduced capacity.

🎮 GPU SUBSYSTEM

4× NVIDIA RTX PRO 6000 Blackwell Workstation Edition

Per GPU

Specification	Value
VRAM	96 GB GDDR7 ECC
Memory bandwidth	1,792 GB/s
FP32	125 TFLOPS
Interface	PCIe 5.0 ×16
Board power	600 W
Physical class	Dual-slot

Four-GPU total

Metric	Total
GPUs	4
GPU memory	384 GB ECC
GPU board-power budget	2,400 W
Aggregate theoretical bandwidth	7,168 GB/s

PCIe topology

PCIe Slot 1 → RTX PRO 6000 #1
PCIe Slot 3 → RTX PRO 6000 #2
PCIe Slot 5 → RTX PRO 6000 #3
PCIe Slot 7 → RTX PRO 6000 #4

Important

The four GPUs are four independent GPU memory spaces, not automatically one unified 384 GB GPU. Software must support multi-GPU operation to exploit them together.

⚡ POWER SYSTEM

2× Corsair WS3000

Parameter	Final
PSU count	2
Capacity/PSU	3,000 W
Combined	6,000 W
Standard	ATX 3.1
Input	220–240 V
GPU connectors	4× 12V-2x6 per PSU
GPU connector capability	600 W class

Approximate locked CPU + GPU power

350 W CPU

2,400 W GPUs

~2,750 W

before the rest of the workstation.

Important distinction

6,000 W PSU capacity is not 6,000 W actual consumption.

It is our massive electrical headroom.

❄️ COOLING SYSTEM

Dual independent liquid loops

CPU loop

9995WX

→ HEATKILLER IV PRO ACRYL NICKEL-BLACK

→ redundant pumps

→ MO-RA IV 600 #1

→ reservoir/manifold

→ CPU

GPU loop

4× RTX PRO 6000

→ 4× Alphacool ES blocks

→ redundant pumps

→ MO-RA IV 600 #2

→ reservoir/manifold

→ GPU array

🧊 Cooling hardware

Component	Final
CPU block	HEATKILLER IV PRO Threadripper ACRYL NICKEL-BLACK 18027
GPU blocks	4× Alphacool ES RTX 6000 Pro Workstation
Radiators	2× MO-RA IV 600
Pumps	Redundant pumps per loop
Reservoirs/manifolds	Dedicated per loop
Temperature monitoring	✅
Flow monitoring	✅
Leak detection	✅
Emergency shutdown	✅

Thermal design target

~2.75 kW CPU + GPU heat

with the cooling system engineered for sustained workload rather than merely short benchmark bursts.

🏠 CHASSIS

Phanteks Enthoo Pro II Tempered Glass

PH-ES620PTG_DBK01

Feature	Final
Motherboard	SSI-EEB / EEB
Maximum motherboard	305 × 330 mm
PCI expansion	11 slots
GPU clearance	~503 mm
3.5" storage support	Up to 12 positions
Tempered glass	✅
Integrated D-RGB	✅
Dual PSU architecture	✅

Why TG instead of closed panel?

Because our workstation isn't changing internally.

We're simply giving the monster a glass showcase window so the four water-cooled professional GPUs, illuminated power cables and internal lighting are actually visible.

💾 COMPLETE STORAGE SYSTEM

Native motherboard connections

Interface	Quantity	Locked device
M.2 PCIe 5.0 ×4	4	4× Samsung 9100 PRO 8 TB
SlimSAS PCIe 4.0 ×4	2	2× Samsung PM1733a 30.72 TB
SATA 6 Gb/s	4	4× Seagate Exos 32 TB
M.2 Key-E	1	Intel BE200 — networking, not storage

Capacity

32 TB Samsung 9100 PRO

61.44 TB PM1733a

128 TB Exos

💾 221.44 TB RAW

📡 NETWORKING

Built-in

2× 10GbE

Wireless

Intel Wi-Fi 7 BE200

Bluetooth

Bluetooth 5.4

Deliberately omitted

100/200/400 GbE server/data-center NIC

because it would consume valuable expansion resources without being automatically useful for our workstation workloads.

🎥 PCIe EXPANSION

Final internal PCIe expansion card count: 0

The previously selected:

~~Blackmagic DeckLink 8K Pro G2~~

is removed.

Why?

It has a physical multi-slot requirement that creates unnecessary uncertainty around the four-GPU arrangement.

Our rule is:

Protect the four-GPU architecture before adding auxiliary PCIe hardware.

Professional video I/O can instead be handled through an external solution when needed.

🖥️ DISPLAY SYSTEM

Main

ASUS ProArt PA32UCDM

31.5"

3840×2160

QD-OLED

240 Hz

HDR

professional wide-gamut

This is the central:

gaming + editing + professional workstation display

Creative display

Wacom Cintiq Pro 27

27"

120 Hz

professional color

pen input

This is for:

retouching • drawing • compositing • digital art • 3D

🎛️ WORKSTATION CONTROLS

Device	Model	Purpose
Keyboard	Keychron Q6 Max	Programming, editing, gaming
Mouse	Logitech MX Master 4	Precision productivity
Control surface	Elgato Stream Deck+	Resolve/Premiere/Photoshop/Blender/OBS automation

⚡ POWER DISTRIBUTION + PROTECTION

Layer	Final hardware
PSU #1	Corsair WS3000
PSU #2	Corsair WS3000
PDU #1	Vertiv Geist monitored PDU
PDU #2	Vertiv Geist monitored PDU
UPS	Vertiv Liebert GXT5 10 kW
Input architecture	Dedicated properly engineered 230 V circuits
Monitoring	PDU + UPS monitoring
PSU wiring	Genuine Corsair modular cables only

Important

This is a high-current 230 V installation. The actual circuits, breakers, conductors, grounding and isolation must be designed/installed according to local electrical requirements by a qualified professional.

🌌 CYBER-ICE RGB SYSTEM

Now the workstation gets the gaming-PC visual treatment without becoming a gaming-platform compromise.

🌀 Case fans

Position	Final
Front	3× Phanteks D30-140 Reverse D-RGB
Top	3× Phanteks D30-140 D-RGB Regular

Total

6× D30-140

This respects the Enthoo Pro II's 140 mm fan capacity.

✨ Architectural RGB

Phanteks NEON

Model	Quantity
NEON M1 1000 mm — PH-NELEDKT_M1	1
NEON M5 500 mm — PH-NELEDKT_M5	2

Use them for:

long motherboard perimeter

lower GPU zone

rear/cable-channel accent

💎 Geometric lighting

Corsair iCUE LC100

Product	Qty
LC100 9-panel Starter — CL-9011114-WW	1
LC100 9-panel Expansion — CL-9011115-WW	1

Total

18 RGB panels

Placed behind/beside the GPU bank as an AI-core geometric pattern.

🔌 GPU POWER LIGHTING

Lian Li Strimer Wireless 16-12

PW16-121W

Quantity

4

One illuminated 12V-2×6 path per GPU.

Controllers

2× L-Wireless Controller RF-T-B

because four Strimers exceed the documented three-Strimer-per-controller arrangement.

Electrical rule

The Corsair WS3000 PSU-side wiring remains genuine Corsair wiring.

No unverified third-party modular PSU cable is introduced.

🧠 CPU RGB

HEATKILLER IV PRO Threadripper ACRYL NICKEL-BLACK

18027

This replaces the earlier pure-copper visual choice while retaining an sTR5-specific CPU block.

❄️ MO-RA RGB

For each MO-RA IV 600:

RGB component	Qty per radiator	Total
MO-RA IV 600 Ambient Light aRGB	1	2
MO-RA IV 600 Front Logo aRGB	1	2
MO-RA IV Tank aRGB Module 600	1	2
MO-RA IV Passive Control 600	1	2

🌀 MO-RA COOLING FANS

Noctua NF-A20 HS-PWM chromax.black

9 per MO-RA

18 total

These remain performance fans rather than decorative RGB fans.

The RGB comes from the MO-RA lighting system itself, keeping radiator performance as the priority.

🧩 RGB CONTROL ARCHITECTURE

RGB ecosystem	Hardware controlled
ASUS Aura Sync	Motherboard + compatible 5 V aRGB
Phanteks D-RGB	D30 fans + NEON + case lighting
Corsair iCUE	LC100
Lian Li Wireless	4× Strimer
Watercool aRGB	Both MO-RA systems
RGB software layer	Optional synchronization/visual profiles

Critical rule

RGB software never becomes the cooling controller.

Fan speed, pump speed, coolant temperature and protection remain under the dedicated thermal-control architecture.

🌈 CYBER-ICE LIGHTING PROFILES

Mode	Visual
💤 Idle	Deep blue / ice blue, very low brightness
🧠 CPU Workload	Blue → violet
🤖 AI / GPU Load	Cyan → purple
🎬 Video Editing	Neutral white + subtle blue
🎮 Gaming	Cyan → blue → violet → magenta
❄️ Cooling Showcase	Ice blue / white
⚠️ Thermal Warning	Amber → red

So although the machine is fundamentally a professional workstation, the visual identity is unmistakably:

Modern flagship gaming-PC aesthetic 🌌🎮

📊 MASTER PERFORMANCE SUMMARY

Metric	Final configuration
CPU	Threadripper PRO 9995WX
CPU cores	96
CPU threads	192
System RAM	2 TB ECC RDIMM
Memory channels	8
GPU count	4
GPU VRAM	96 GB × 4 = 384 GB ECC
GPU board-power budget	2,400 W
CPU power rating	350 W
Approx. CPU + GPU load	~2.75 kW
PSU capacity	6,000 W
Native Gen5 NVMe	4×
Native Gen4 SlimSAS NVMe	2×
SATA ports	4×
Raw local storage	221.44 TB
Wired networking	2× 10GbE
Wireless	Wi-Fi 7
Bluetooth	5.4
Main display	4K 240 Hz QD-OLED
Pen display	4K 120 Hz
Case	Phanteks Enthoo Pro II Tempered Glass
GPU cooling	4× full-cover water blocks
Radiators	2× MO-RA IV 600
MO-RA fans	18× Noctua NF-A20
Case RGB fans	6× D30-140
LC100 panels	18
NEON strips	3
Illuminated GPU cables	4
Workstation platform	Single-socket / non-server

🔒 FINAL STATUS

🟢 PERFORMANCE HARDWARE

✅ CPU locked
✅ Motherboard locked
✅ 2 TB ECC RAM locked
✅ 4-GPU RTX PRO 6000 configuration locked
✅ 6,000 W PSU architecture locked
✅ Dual-loop cooling locked
✅ Dual MO-RA IV 600 locked
✅ 221.44 TB storage architecture locked

🟢 VISUAL HARDWARE

✅ Tempered-glass chassis
✅ 6× D30 RGB fans
✅ 3× NEON lighting sections
✅ 18× LC100 panels
✅ 4× Strimer GPU power paths
✅ RGB CPU block
✅ 2× illuminated MO-RA systems

❌ DELIBERATELY EXCLUDED

❌ DeckLink 8K Pro G2

❌ Server-class networking card

❌ Separate gaming GPU

❌ RGB hardware that requires weakening the cooling system

❌ Extra PCIe cards merely to fill empty slots

🏆 FINAL IDENTITY

ULTIMATE NON-SERVER WORKSTATION — CYBER-ICE

96-core / 192-thread Threadripper PRO

2 TB ECC memory

4× 96 GB RTX PRO 6000 Blackwell

384 GB total GPU memory

6,000 W PSU capacity

2× MO-RA IV 600 liquid cooling

221.44 TB raw local storage

4K 240 Hz QD-OLED

Wi-Fi 7 + dual 10GbE

full modern RGB architecture

Professional workstation on the inside. Flagship gaming-PC aesthetic on the outside. ❄️⚡🎮🌌

Build Your Own Agent Control Plane: Ceilings and Quotas

AI Tech Connect — Sat, 12 Sep 2026 13:32:30 +0000

Originally published on AI Tech Connect.

What a control plane is, and what it is not The State of FinOps 2026 report, published by the FinOps Foundation in February 2026 on responses from 1,192 practitioners representing more than $83 billion in annual cloud spend, contains one number that reframes the whole discipline: 98% of respondents now manage AI spend, up from 31% two years earlier. That is not gradual adoption, it is a category appearing from nothing. The same survey reports that 73% of AI projects still overrun their budget, and that the single most-requested capability among practitioners is granular monitoring of AI spend broken down by tokens, LLM requests and GPU utilisation. Read those three findings together and the picture is unambiguous: almost everyone is now responsible for this cost, most of them cannot hold…

Read the full article on AI Tech Connect →

Deploying LLMs On-Premise: A Comprehensive Guide

shashank ms — Sat, 12 Sep 2026 13:32:23 +0000

Deploying large language models on-premise gives you full control over data, latency, and model weights. For organizations with strict compliance requirements or predictable inference volumes, running LLMs inside your own data center can be a sound long-term strategy. However, on-premise deployment introduces significant complexity in hardware procurement, cluster management, and continuous model serving. This guide walks through the practical decisions involved in building an on-premise LLM stack, and where hosted alternatives fit into the picture.

Why On-Premise Still Matters

The primary drivers for on-premise LLM deployment remain data sovereignty and control. Highly regulated industries, such as finance and healthcare, often require that sensitive data never leave the corporate network. Air-gapped environments and private data centers satisfy these constraints in ways that public cloud APIs cannot without extensive legal and architectural review. Additionally, organizations that have already invested in GPU clusters for training can repurpose that hardware for inference, improving overall asset utilization.

That control comes with tradeoffs. You become responsible for every layer of the stack, from driver compatibility to model security patching. The decision to go on-premise should therefore be driven by concrete compliance or latency requirements, not by a generic assumption that self-hosting is always cheaper.

Hardware Requirements and Sizing

GPU memory is the single most constrained resource in LLM serving. A 70B parameter model loaded in FP16 precision requires approximately 140 GB of VRAM, which means at least two NVIDIA A100 80GB GPUs or three H100 80GB GPUs if you reserve headroom for the KV cache and activation buffers. Quantization reduces this footprint. AWQ or GPTQ 4-bit quantization can cut VRAM usage by roughly half, though at the cost of some accuracy and serving throughput.

For smaller models or CPU fallback scenarios, RAM capacity and memory bandwidth become the bottlenecks. A rule of thumb is to allocate at least 1.2x the model size in system memory when using CPU offloading frameworks. Networking also matters for distributed setups. Multi-node inference demands InfiniBand or high-bandwidth Ethernet between nodes to prevent tensor parallelism from bottlenecking on inter-GPU communication.

The Software Stack

Several open-source serving engines dominate production on-premise deployments. vLLM remains the throughput leader for GPU clusters thanks to PagedAttention and continuous batching. Hugging Face Text Generation Inference (TGI) provides a robust alternative with strong support for safetensors and quantization adapters. For CPU-centric or hybrid environments, llama.cpp offers broad hardware compatibility, from AVX2 servers to Apple Silicon. Ollama is useful for local development, but its lack of production observability and multi-replica orchestration makes it a poor fit for data center scale.

Container orchestration is typically handled by Kubernetes. Operators like KServe or custom Helm charts manage model artifacts, GPU scheduling, and autoscaling. The following example launches a vLLM server in a Docker container with tensor parallelism across two GPUs:

docker run --gpus all \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --tensor-parallel-size 2 \
  --dtype half \
  --max-model-len 8192

This exposes an OpenAI-compatible HTTP interface on port 8000, which simplifies client integration but still leaves networking, TLS termination, and load balancing as exercises for the operator.

Deployment Patterns

Single-node deployments are the simplest to reason about. All GPUs reside in one server, NVLink or NVSwitch handles communication, and you only need to manage one operating system image. The limitation is scale. Once model size or request volume exceeds what a single node can provide, you must move to multi-node tensor or pipeline parallelism.

Multi-node setups introduce failure modes that single-node systems avoid. A network partition between pipeline stages stalls the entire request batch. Kubernetes can reschedule pods, but LLM inference pods are stateful and expensive to relocate because they must reload multi-gigabyte weights into GPU memory. Most teams therefore over-provision rather than attempt aggressive autoscaling, which increases idle hardware costs.

Operating at Scale

Production on-premise clusters require standard observability stacks. Prometheus and Grafana should track GPU utilization, memory consumption, PCIe bandwidth, and temperature. Model serving engines expose metrics, but you must also monitor queue depths and time-to-first-token (TTFT) to catch degradation before users notice it.

Security is another operational layer. Model weights are valuable intellectual property. Encrypt them at rest, restrict network access to serving endpoints, and rotate API keys through a secrets manager. Finally, plan for model updates. The open-source release cycle moves quickly. A process for downloading, validating, and hot-swapping weights without dropping active connections is essential for keeping pace.

Cost Realities and Hosted Alternatives

The total cost of ownership for on-premise LLMs extends far beyond the initial hardware invoice. Power, cooling, rack space, and the engineering hours required to maintain drivers, containers, and model artifacts accumulate quickly. For variable or exploratory workloads, idle GPUs represent wasted capital.

Token-based cloud providers tie cost directly to prompt and completion length. This pricing model penalizes long-context retrieval pipelines, multi-turn agentic workflows, and large document analysis because every input token incurs a charge. Teams often investigate on-premise specifically to escape that linear cost curve.

Oxlo.ai offers a different structure. As a developer-first inference platform, Oxlo.ai charges one flat cost per API request regardless of prompt length. For long-context and agentic workloads, this request-based model avoids the runaway costs associated with token-based billing and removes the infrastructure overhead of self-hosting. With 45+ open-source and proprietary models across seven categories, full OpenAI SDK compatibility, and no cold starts, Oxlo.ai functions as a drop-in replacement for an on-premise serving layer. Teams that require on-premise for compliance can still route non-sensitive or burst workloads to Oxlo.ai to reduce cluster size and operational load. See https://oxlo.ai/pricing for current plan details.

Decision Framework

Choose on-premise deployment when you operate in an air-gapped environment, have strict data residency requirements that cannot be met by contractual means, or already own depreciated GPU hardware that can be repurposed. On-premise also makes sense when request patterns are extremely stable and you can keep utilization above 80 percent.

Choose a hosted API when your workloads are variable, your team lacks dedicated ML infrastructure engineers, or your primary cost driver is long-context inference. In these scenarios, the

The Drink You Know vs. The Pill You Don't

fast2future — Sat, 12 Sep 2026 13:30:25 +0000

The short version

Two things you swallow. Two stories that look similar and are actually opposites.

Alcohol is the fundamental where the evidence genuinely moved over the last decade — the old "a glass of red is good for your heart" finding has been substantially undermined — and where the official guidance is now openly, unresolvedly contested. The science moved; the labels are still arguing about it.

NMN (a NAD⁺ precursor sold as an anti-aging supplement) is the frontier product where the legal status flipped in the last ten months — from "FDA says this isn't a supplement" to "FDA says it is" — while the human efficacy evidence didn't move at all. The label moved; the science stayed exactly where it was.

That difference is the whole point of this piece. A change in what a regulator calls something is not a change in whether it works. And a genuine shift in evidence is not the same as a settled verdict.

🌿 STREAM ONE — Alcohol: the fundamental where the evidence really did move

What the old story was

For roughly thirty years, the dominant finding was the "J-curve": people who drank a little appeared to live longer than both heavy drinkers and non-drinkers. It came out of large observational cohorts and got popularized as the "French Paradox." The proposed mechanism was plausible — light drinking raises HDL cholesterol and has some antithrombotic effect.

(We're deliberately not quoting a specific relative-risk figure from the flagship 2006 meta-analysis. Two different numbers circulate in secondary sources for it, and we could not confirm which is correct against the original paper. The shape of the finding is well established; a specific decimal we can't verify is not something we'll put in your hands.)

What undermined it

The comparison group was contaminated. The "zero drinks" reference group in many old cohorts included people who had quit drinking because they got sick, plus people who never drank because they were already unwell. That makes abstainers look unhealthy for reasons that have nothing to do with abstaining — and makes light drinkers look protected by comparison. This is the "sick-quitter" or abstainer-bias critique.

Zhao J, et al., JAMA Network Open, 2023. 107 cohort studies, 4,838,825 participants, 425,564 deaths. When the authors adjusted for study quality — critically, whether the study used a clean lifetime-abstainer reference group (only 21 of 107 did) — the apparent protection largely evaporated:

Low-volume drinking (1.3–24.0 g/day), unadjusted: RR 0.85 (95% CI 0.81–0.88)
Low-volume drinking, fully adjusted: RR 0.93 (95% CI 0.85–1.01), p = .08 — not statistically significant

"In this updated systematic review and meta-analysis, daily low or moderate alcohol intake was not significantly associated with all-cause mortality risk, while increased risk was evident at higher consumption levels, starting at lower levels for women than men."
— Zhao et al., JAMA Netw Open 2023 (abstract conclusion, verbatim)

Read that carefully, because it's easy to get wrong in both directions. A confidence interval crossing 1.0 means no significant association found — not "drinking a little is protective" (the old claim) and not "drinking a little is proven harmful" (the overcorrection). It means the effect the old studies saw does not survive better methodology.

Harm at higher intakes is clearer, and starts lower for women: men at 45–64 g/day RR 1.15 (1.03–1.28); women at 25–44 g/day RR 1.21 (1.08–1.36), rising to RR 1.61 (1.44–1.80) at ≥65 g/day.

Biddinger KJ, et al., JAMA Network Open, 2022 — the causal check. Mendelian randomization uses genetic variants that influence alcohol consumption as a natural experiment, which sidesteps the reverse-causation and lifestyle-confounding problems that plague observational cohorts. In 371,463 UK Biobank participants, per 1-SD increase in genetically predicted alcohol consumption: hypertension OR 1.28 (95% CI 1.18–1.39), coronary artery disease OR 1.38 (95% CI 1.10–1.74). No protective inflection point at any intake level.

"In this cohort study, coincident, favorable lifestyle factors attenuated the observational benefits of modest alcohol intake. Genetic epidemiology suggested that alcohol consumption of all amounts was associated with increased cardiovascular risk, but marked risk differences exist across levels of intake, including those accepted by current national guidelines."
— Biddinger et al., JAMA Netw Open 2022 (conclusion, verbatim)

That last clause matters: marked risk differences exist across levels of intake. Light and heavy are not the same thing, even in the study that found no safe floor.

The part that is genuinely settled: cancer

This is the least disputed piece of the whole picture. The International Agency for Research on Cancer classified alcoholic beverages as a Group 1 carcinogen (carcinogenic to humans) in 1988, and IARC Monograph Volume 96 (2010) reaffirmed the original sites — oral cavity, pharynx, larynx, esophagus, liver — and added colorectal cancer and female breast cancer as causally related.

In January 2023, WHO stated the position plainly:

"We cannot talk about a so-called safe level of alcohol use. It doesn't matter how much you drink — the risk to the drinker's health starts from the first drop of any alcoholic beverage."
— Dr Carina Ferreira-Borges, WHO/Europe, published on who.int, 4 January 2023

(Source-honesty note: we're quoting WHO's own published statement directly. The underlying journal piece — Anderson BO, et al., Lancet Public Health 2023;8:e6–e7 — was not accessible to us in full. So we quote WHO quoting itself, which is what we can actually stand behind, rather than a journal sentence we haven't read.)

The part that is NOT settled — and almost nobody tells you this

Here is where most health coverage of alcohol, in both directions, is dishonest by omission.

Two US federal evidence reviews looked at alcohol and all-cause mortality — landing about a month apart, as parallel inputs to the same 2025–2030 Dietary Guidelines process — and reached opposite headline conclusions.

The National Academies (NASEM) review, briefed to Congress in December 2024, concluded: "Based on data from the eight eligible studies from 2019 to 2023, the committee concludes that compared with never consuming alcohol, moderate alcohol consumption is associated with lower all-cause mortality (moderate certainty)" — RR 0.84 (95% CI 0.81–0.87). (We verified this directly against the primary source.)
The ICCPUD (an HHS interagency committee) review, drafted January 2025, reportedly found no age group with a net mortality benefit, with risk rising progressively from low average intake.

Note the timing: these were not a debate where one side answered the other. They were two commissioned reviews running in parallel, published within weeks, feeding the same guidelines process, and disagreeing. They disagree largely because they included different studies. NASEM used a deliberately narrow set of eight it judged highest-quality; critics say that filter is what produced the protective result. NASEM's own committee graded its finding "moderate certainty" and noted the underlying studies mostly captured the lower end of the moderate range.

We are not going to resolve that for you, because it is not resolved. Anyone telling you the science has definitively concluded that moderate drinking is beneficial is ignoring Zhao and the Mendelian randomization work. Anyone telling you the science has definitively concluded there is no benefit at any level is ignoring a serious congressionally-mandated federal review that found the opposite. On cancer, the evidence is clear and one-directional. On all-cause mortality at low intake, it is a live methodological dispute among competent people.

Where the guidance landed

Different countries with access to the same literature drew strikingly different lines, which is itself informative:

Canada (CCSA, 2023) — a continuum-of-risk framing, and by far the most conservative in the English-speaking world:

Standard drinks per week	CCSA risk tier
0	Benefits (better health, better sleep)
≤2	Low risk
3–6	Moderate risk (increased risk of several cancers, incl. breast and colon)
≥7	Increasingly high risk (significantly increased heart disease/stroke risk)

Plus: no more than 2 drinks on any single occasion. (We are not quoting a gram figure for a Canadian standard drink — the primary source didn't state one, and "standard drink" is not internationally uniform. A US standard drink is 14 g of ethanol; do not apply that number to a non-US guideline.)

United States — the 2020–2025 guidelines defined moderate drinking as ≤2 drinks/day for men and ≤1 for women.

⚠️ A live item we could not fully verify. Multiple secondary sources report that the 2025–2030 Dietary Guidelines, published January 2026, dropped the specific numeric daily limits in favor of vaguer language, and reduced explicit cancer-risk wording relative to earlier drafts. We were unable to access the primary government guidance pages directly to confirm this ourselves. We're surfacing this as reported and unconfirmed rather than either asserting it or hiding it — because if true, it's a meaningful change to the guidance most Americans encounter, and because the two contradictory federal reviews above are the obvious context for why the language got vaguer. Check the current guidance yourself before relying on any number in this section.

A US Surgeon General advisory on alcohol and cancer was issued in January 2025, calling for updated cancer-warning labels. We are deliberately citing no figures from it — we could not access the primary document directly, and the numbers circulating in secondary coverage disagree with each other by a wide margin (three different case counts, two different death counts). We would rather give you no number than the wrong one.

🚩 Three framing traps in alcohol coverage — spot them and you can read any headline

Reporting a non-significant result as an effect. Zhao's adjusted low-volume RR of 0.93 has a CI touching 1.01. Writing "7% lower mortality" from that is wrong. It's a null.
Collapsing population fractions into personal risk. "X% of cancers are attributable to alcohol" is a population-attributable fraction. It tells you almost nothing about how much your risk changes from your intake.
Relative risk without the baseline. A large-sounding percentage increase on a small absolute risk is still a small absolute change. Any honest source gives you both.

And we owe you that third one about our own numbers. Every figure in this section — Zhao's RRs, Biddinger's ORs, NASEM's RR — is a relative risk or odds ratio measured across large populations. None of them tell you your personal absolute risk, and none of them were sourced with the individual-level baseline data that would let us convert them for you. Treat them as what the direction of the evidence is, not as what will happen to you. The person who can put a number on your situation is a clinician with your history in front of them.

🔬 STREAM TWO — NMN vs NR: the label moved, the science didn't

NAD⁺ is a coenzyme central to cellular energy metabolism. Its levels decline with age. The longevity-supplement thesis: take a precursor, raise NAD⁺, slow aging. The two commercial precursors are NR (nicotinamide riboside) and NMN (nicotinamide mononucleotide).

What the human trials actually found

This is the honest core, and it is not what the marketing implies. Every flagship NR trial that tested a hard metabolic primary endpoint missed it.

Trial	n	Design	Primary endpoint	Result
Dollerup et al., AJCN 2018	40 obese, insulin-resistant men	12 wk, 2000 mg/d NR	Insulin sensitivity (clamp)	MISSED
Elhassan et al., Cell Reports 2019	12 aged men (median 75 y)	21 d crossover, 1000 mg/d NR	Muscle NAD⁺ metabolome + mitochondrial bioenergetics	PARTIAL — blood NAD⁺ >2-fold (p<0.001), but muscle NAD⁺ did not rise (p=0.22) and mitochondrial respiratory capacity was unchanged
Remie et al., AJCN 2020	13 completers, overweight/obese	6 wk crossover, 1000 mg/d NR	Insulin sensitivity + muscle mitochondrial function	BOTH MISSED (glucose disposal p=0.98)

"Insulin sensitivity, endogenous glucose production, and glucose disposal and oxidation were not improved by NR supplementation."
— Dollerup et al., AJCN 2018 (verbatim)

Remie's authors put their own result just as plainly: skeletal muscle mitochondrial function was not elevated by NR supplementation.

The Elhassan result is the one worth sitting with. NR raised NAD⁺ in blood — the biomarker the marketing sells — while failing to raise it in the muscle tissue that was the actual point, and producing no change in mitochondrial function. A moving biomarker is not a moving outcome.

NMN's trials are smaller and mixed. Yoshino et al., Science 2021 (n=25, postmenopausal prediabetic overweight/obese women, 250 mg/d) met its primary endpoint — muscle insulin sensitivity improved; muscle glucose disposal was 25±7% greater after 10 weeks of NMN than before it (p<0.01). Single-site, women-only, one narrow clinical population. (Primary-verified: trial registration, sample size and sponsor on ClinicalTrials.gov NCT03151239; the effect size read directly from the NIH public-access full text, PMC8550608.) Yi et al., GeroScience 2023 (n=80) showed dose-dependent NAD⁺ increases. Katayoshi et al., Sci Rep 2023 (n=36) found serum nicotinamide rose but arterial stiffness only "tended to" improve — i.e. did not clearly reach significance.

The meta-analyses are where it gets decisive. Both of these we verified directly against the primary text:

"This systematic review on 8 small-scale RCTs involving mainly relatively healthy adults did not find short-term NMN supplementation improved markers of glucose control and lipid profile... Our findings do not support the use of NMN supplementation among general population to improve glucose and lipid metabolism."
— NMN meta-analysis, 8 RCTs, n=342 (PMC11557618)

"Current evidence does not support NMN and NR supplementation for preserving muscle mass and function in adults with mean age of over 60 years."
— NMN + NR skeletal muscle meta-analysis, 10 RCTs (PMC12022230)

No significant effect on skeletal muscle index, grip strength, gait speed, or chair-stand performance.

🛑 The claim that does not exist

There is no human trial — none — showing that NMN or NR extends lifespan, extends healthspan, or reduces the incidence of any disease or death.

Every human trial is a surrogate endpoint (NAD⁺ blood levels, insulin sensitivity, arterial stiffness, muscle mass) over 3 weeks to 12 weeks, in samples of 12 to 80 people. The lifespan and healthspan data exist in mice only. When you see longevity marketing, this is the gap it is stepping across.

The regulatory flip — and why it proves nothing about efficacy

Here is the timely part, and the reason this piece pairs with alcohol.

In November 2022, FDA took the position that NMN was excluded from the legal definition of a dietary supplement under FD&C Act §201(ff)(3)(B)(ii) — the "drug preclusion" or "race to market" clause, which excludes an ingredient that was authorized for investigation as a new drug before it was marketed as a supplement. A pharmaceutical company had an active NMN investigational new drug application. Amazon delisted NMN supplements in March 2023.

Then, reportedly on September 29, 2025, FDA reversed itself in response to a trade-association citizen petition, concluding NMN had been marketed as a supplement before the drug authorization, and therefore is not excluded. Follow-up letters to ingredient suppliers in December 2025 formalized it. NMN is back on the shelves.

Three things to hold onto:

"Excluded from the supplement definition" was never a ban, and the reversal is not an approval. Both the 2022 exclusion and the 2025 reversal are rulings about a definitional/timing question — when was this thing first marketed versus first investigated as a drug. FDA said nothing about whether NMN works, in either direction, at any point. Any product copy reading "FDA-approved NMN" or "FDA confirms NMN" would be false.
NR was never subject to this at all. ChromaDex's NR cleared the New Dietary Ingredient notification pathway and holds a GRAS determination. The NR/NMN legal asymmetry was always about drug-preclusion timing — never about one being better evidenced than the other. As the trials above show, neither has hard-outcome human evidence.
A regulatory event generates marketing. A legal status change is a news hook, and news hooks sell product. The evidence base for NMN in July 2026 is the same evidence base it was in 2022.

⚠️ Source-honesty note, and it's a significant one. We were unable to access the primary FDA and federal register documents directly. The regulatory timeline above is therefore assembled from legal and trade press that quotes those FDA documents (Venable LLP, Natural Products Association, NutraIngredients, Nutritional Outlook) — not from the FDA documents themselves. Multiple independent outlets converge on the same dates, which raises confidence, but this section is reported, not primary-verified, and we're labeling it rather than letting it wear an authority it hasn't earned.

Safety — short answer, honest answer

Across the trials above, NR and NMN were well tolerated with no serious adverse events at doses up to 2000 mg/d (NR) and 900 mg/d (NMN). That is genuinely reassuring as far as it goes.

How far it goes: no trial cited here ran longer than about 12 weeks. There is no long-term human safety dataset.

There is also an unresolved theoretical concern worth naming without inflating: NAD⁺ supports cell proliferation broadly, including in malignant cells, and some preclinical models raise the question of whether NAD⁺ precursors could support tumor growth. No human trial has been designed or powered to detect a cancer signal, so the human literature has neither confirmed nor ruled this out. It is a mechanistic open question, not a demonstrated harm. It is also exactly the kind of question that belongs to a physician who knows your history — particularly if you have an active cancer diagnosis or significant personal risk.

One more thing worth knowing before you buy

A 2021 analysis of 22 top-selling Amazon NMN brands reported that only about 14% met their label claim, roughly 64% contained under 1% of the claimed NMN, and 14% contained none at all.

That analysis was commissioned by ChromaDex — which sells NR and directly competes with NMN. We're giving you the finding and the conflict of interest, because you need both to weigh it. Independent reporting has separately flagged label-claim failures across NMN products, which is consistent, but a competitor-funded study is not neutral third-party testing and shouldn't be presented as such.

🪒 The which-is-which razor

	🍷 Alcohol	💊 NMN / NR
What actually changed	The evidence (J-curve substantially undermined)	The legal status only (FDA exclusion, then reversal)
Human hard-outcome data	Extensive — cohorts of millions, plus Mendelian randomization	None. Zero trials on lifespan, healthspan, disease, or death
Longest human evidence	Decades of follow-up	~12 weeks
What's genuinely settled	Group 1 carcinogen; harm rises with intake	Raises blood NAD⁺; short-term tolerability
What's genuinely disputed	All-cause mortality at low intake — two federal reviews disagree	Whether raising NAD⁺ does anything you'd notice
What the marketing implies	(Legacy) "a glass is good for your heart"	"FDA-cleared longevity" — a definitional ruling sold as an efficacy signal
Honest label	🌿 A real fundamental where the evidence moved — and the cancer half is settled while the mortality half is not	🔬 Frontier. Biomarker moves; outcomes untested. Legal ≠ effective
Cost	Varies	~$40–90/month, indefinitely

The one-sentence version: with alcohol, less is better-supported than it used to be and the cancer link is not in serious dispute; with NAD⁺ precursors, a regulator changed a definition and nothing about your body changed at all.

🛑 We are not doctors, and this is not medical advice

We say this every time, and this piece is one where it carries real weight.

On alcohol — please read this part.

If you drink heavily or daily, do not simply stop on your own. Abrupt alcohol withdrawal in a physically dependent person can cause seizures and delirium tremens, and it can be fatal. Medically supervised withdrawal exists precisely because this is dangerous. Talk to a doctor before changing a heavy or daily drinking pattern. This is the single most important sentence in this article.
If you are pregnant or trying to become pregnant, this article is not your source — your clinician is.
If you take medications (many interact with alcohol), have liver disease, a personal or family history of the cancers named above, a history of alcohol use disorder, or a mental health condition, your personal calculus is different from any population average and needs a professional who knows your history.
If you're worried about your own drinking, that concern deserves a real conversation with a real clinician, not an internet article. It is a completely ordinary thing to ask a doctor about, and asking early is easier than asking late.
Nothing here is a reason to feel ashamed. People drink for reasons — social, cultural, celebratory, and sometimes for pain. The evidence changing does not make anyone a bad person, and this piece is not an accusation.

On NMN and NR.

We are not telling you to take these, and we are not telling you to stop if you already do. We're telling you what the trials found so you can decide with accurate information.
If you have an active cancer diagnosis or significant cancer risk, the unresolved proliferation question above is a real conversation to have with your oncologist before starting a NAD⁺ precursor. Do not resolve that one from an article.
If you take prescription medication or have a chronic condition, run any new supplement past your doctor or pharmacist. Supplements are not inert just because they're sold without a prescription.
If you have persistent fatigue, weakness, or symptoms you're hoping a longevity supplement will fix, please get them diagnosed. Symptoms deserve a diagnosis, not a workaround.

Anything touching an actual medical decision belongs with a professional who knows your body, your history, and your medications. We can tell you what the studies say. We cannot tell you what you should do — and we won't pretend otherwise.

🌱 The hopeful close

There's something genuinely freeing in this pairing once you see it.

The frontier product costs money every month, has no human outcome data, and its biggest news in three years was a paperwork reversal. The fundamental costs nothing to act on and the honest guidance is mostly subtractive — a little less, and the decision is yours to make with your own doctor.

And underneath both of them, the things with the strongest evidence for a long, good life are still the same unglamorous ones: sleep, real food, movement and strength, sunlight, water, managed stress, and people who love you. None of them are for sale. None of them need a regulatory ruling. None of them need you to resolve an argument between two federal committees before you can start.

That's not a consolation prize. That's the actual finding — the best-evidenced things remain free, available today, and nobody's advertising budget depends on you believing in them. Which is exactly why they're so quiet.

Be well. Be honest with yourself. And talk to your doctor. 💪

Sources

Alcohol

Zhao J, Stockwell T, Naimi T, et al. Association Between Daily Alcohol Intake and Risk of All-Cause Mortality: A Systematic Review and Meta-analyses. JAMA Netw Open. 2023;6(3):e236185. doi:10.1001/jamanetworkopen.2023.6185 (PMC10066463) — primary source verified
Biddinger KJ, Emdin CA, Haas ME, et al. Association of Habitual Alcohol Intake With Risk of Cardiovascular Disease. JAMA Netw Open. 2022;5(3):e223849 (PMC8956974) — primary source verified
IARC Monographs Volume 96 (2010), Alcohol Consumption and Ethyl Carbamate (NCBI Bookshelf NBK326557) — primary source verified; Volume 44 (1988) original Group 1 classification — secondary-sourced
WHO/Europe, "No level of alcohol consumption is safe for our health," 4 January 2023, who.int — primary statement verified. Underlying journal piece: Anderson BO, et al. Lancet Public Health. 2023;8:e6–e7 — not independently verified
Canada's Guidance on Alcohol and Health, CCSA, 2023, ccsa.ca — primary source verified
National Academies of Sciences, Engineering, and Medicine, Review of Evidence on Alcohol and Health, Ch. 3 (NCBI Bookshelf NBK614690; congressionally briefed December 2024, volume catalogued 2025) — primary source verified
ICCPUD Alcohol Intake and Health Study (draft, Jan 2025), SAMHSA — secondary-sourced
2025–2030 Dietary Guidelines for Americans — reported only; primary guidance pages not accessible to us at time of writing
US Surgeon General Advisory on Alcohol and Cancer Risk (Jan 2025) — primary document not accessible to us; no figures cited from it here by deliberate choice
Di Castelnuovo A, et al. Arch Intern Med. 2006;166(22):2437–2445 — not independently verified; no figures cited from it here by deliberate choice
Rumgay H, et al. Lancet Oncol. 2021 — primary document not accessible to us; no figures cited from it here by deliberate choice

NAD⁺ precursors

Dollerup OL, et al. A randomized placebo-controlled clinical trial of nicotinamide riboside in obese men. Am J Clin Nutr. 2018 — primary verified via PubMed
Elhassan YS, et al. Nicotinamide Riboside Augments the Aged Human Skeletal Muscle NAD+ Metabolome. Cell Rep. 2019 — primary verified via PMC
Remie CME, et al. Nicotinamide riboside supplementation alters body composition and skeletal muscle acetylcarnitine concentrations in healthy obese humans. Am J Clin Nutr. 2020 (PMID 32320006) — primary verified
Martens CR, et al. Nat Commun. 2018 — not independently verified; described here only in general terms
Yoshino M, et al. Science. 2021 — primary verified via NIH public-access full text (PMC8550608) and ClinicalTrials.gov NCT03151239
Yi L, et al. GeroScience. 2023 — secondary-sourced
Katayoshi T, et al. Sci Rep. 2023 — secondary-sourced
NMN glucose/lipid meta-analysis, 8 RCTs, n=342 (PMC11557618) — primary source verified
NMN/NR skeletal muscle meta-analysis, 10 RCTs (PMC12022230) — primary source verified
FDA regulatory timeline (Nov 2022 exclusion → Sept 29, 2025 citizen-petition reversal → Dec 2, 2025 supplier letters) — primary FDA documents not accessible to us; assembled from Venable LLP, Natural Products Association, NutraIngredients, Nutritional Outlook. Reported, not primary-verified. Independent corroborating paper trail: NPA v. FDA, D.D.C. No. 1:24-cv-02479 (filed Aug 28, 2024; stayed Oct 24, 2024 pending the citizen-petition response; voluntarily dismissed after the Sept 2025 reversal) — the docket chronology matches every date above.
22-brand NMN label-claim analysis (2021) — ChromaDex-commissioned; conflict of interest disclosed in-text; secondary-sourced

Originally published at fast2future.com.

Engineering Certainty into Income: What 273 Days of Agent Engineering Taught Me About AI Monetization

weiwuji — Sat, 12 Sep 2026 13:30:12 +0000

The Pain: You can read nine tested paths to earn with AI and still land in the same spot — this month there was work, next month there is none. The hard part is almost never "can I earn". It is "can I earn again, the same way". One job arrives by luck; the next one uses the identical method and the method does nothing. Income behaves like weather instead of behaving like engineering.
What You'll Learn: A three-level mechanism for engineering certainty into income — entry convergence, physical gate, audit loop — and why unstable income is, at bottom, a missing feedback loop. You will also see which of your existing engineering habits transfer straight over, the names we gave the three income incidents that keep the loop broken, and a start you can finish in one evening.

⚡ 10-minute fast read: section 3 (the three levels) and section 5 (where to start), plus the closing one-liner.

🎯 Read by need: if your income swings, read section 2. If you want the mechanism itself, read sections 3 and 4.

📖 Full read: about 9 minutes — the complete method for moving engineering certainty onto the income side.

1. Unstable income is a missing feedback loop

The claim first: income behaves like weather because it has no loop. A single order ends and the chain ends with it — nothing settles, nothing is reused, nothing becomes the starting point of the next round.

I have been running an agent engineering system for 273 days. The biggest thing I got out of it was not the number of tools. It was one understanding: a system is reliable not because it never fails, but because every failure gets written down and turned into a rule that is never broken twice.

I call that certainty engineering — turning the accidental into the necessary, and luck into mechanism.

Now look at where most AI monetization actually stops. It stops in the same place: the order ends, and the loop ends with it.

A job comes in, delivery is done, the client leaves — and the experience of that job never becomes an asset for the next one.
This month earned, next month nobody knows where the clients are — acquisition never became a process.
Once in a while something spikes and nobody can say why — the success was not recorded, so it cannot be reused.

My error ledger holds more than 60 rules. Every one of them came from a real incident. Apply the same thinking to income and the incidents are: a client lost, an experience never reused, a success nobody can explain.

Where this goes wrong

Do not treat "revenue was high this month" as proof of ability. Ask first: how much of this month's revenue is repeatable?
Do not rush to learn a new tool. Pin down what the last job taught you first, or every job starts from zero again.

2. Moving engineering thinking to the income side

The claim: the income side and the delivery side run on the same mechanism. Entry convergence answers "where does it come from", the physical gate answers "does it hold", and the audit loop answers "can it compound".

The three levels I use inside the agent system move straight across. This is not a metaphor — it is the same structure:

Level	In the agent system	On the income side
Entry convergence	a task that is not registered may not run	clients and opportunities enter through fixed channels, sources stay traceable
Physical gate	no gate pass, no output is produced	delivery has a standard, and what misses the standard does not ship
Audit loop	incidents go into the ledger, rules flow back into the gate	every job is reviewed into the ledger, experience becomes the next starting point

Before the mechanism, the names. The three income incidents we kept hitting needed names before they could be managed:

Blank-Slip Syndrome. One job, one close-out, nothing left behind. The method, the client's feedback, the whole approach disappear when the order ends. The next time a similar request arrives, you start from zero.

Amnesiac Acquisition. Every search for a client starts from scratch — posts, DMs, ads — but which channel brought which client is never recorded. The result is always the same sentence: "this time the luck was good".

Unexplainable Success. Once in a while something spikes and you cannot say why. With no record, the success cannot be repeated; you can only wait for luck to visit again.

Once the incidents have names, the treatment is obvious. Blank slips have to become filed orders. Amnesiac acquisition has to become traceable channels. Unexplainable success has to become a reviewable sample.

In the same system, the content pipeline runs 17 gates before anything is pushed, and a nightly 21:00 job pours the day's errors back into the ledger. None of that came from discipline. It came from making the loop a scheduled mechanism instead of a memory.

Where this goes wrong

A mechanism cannot live on memory. A rule written in a document gets forgotten; a rule built into a process gets executed.
The three levels are one thing. Entry convergence alone brings clients in but delivery stays shaky; a gate alone stabilises delivery but you never learn where clients come from.

3. Three levels, one at a time: from entry to compounding

The claim: systematising income is not a single step. You build in order — entry, then gate, then loop — and each level you add raises the certainty of income by one notch.

Level 1: entry convergence — make every opportunity traceable

The agent system has one iron rule: a task that is not registered is not allowed to run. On the income side it becomes: every client, every opportunity, carries a record of where it came from.

The implementation is one table:

Field	What it is for
Source channel	which platform or which piece of content brought this
Requirement keywords	the problem in the client's own words
Quote and deal price	did the price drift, and why
Delivery cycle	how long it actually took

Keep it going for three months and you get a conclusion that runs against intuition: 80% of revenue comes from 20% of the channels, and most people have never done this arithmetic.

Level 2: physical gate — delivery has a standard

The content system has a "gate zero": an article that does not pass quality control is not allowed to be pushed. The income-side counterpart is a delivery standard — what counts as complete is defined in advance, not decided on the day.

The value here is not "guaranteeing quality". It is moving delivery from "how I feel today" to "what the standard says". Clients renew, as a rule, not because you were the best they ever saw, but because every delivery landed at the same level as the last one.

Level 3: audit loop — make every job the starting point of the next

This is the level that gets skipped most often, and it is the one worth the most.

The error ledger has one rule: an incident has to be recorded, and a recorded rule has to flow back into a gate. The income-side loop works the same way:

job delivered
  -> review and log it (what went right / where it stalled / what the client cared about)
  -> extract the rule (how to handle this kind of request next time)
  -> flow it back (it becomes a standard action or a quote template)

One example. A review turned up that the client cared less about the price than about response speed. The next rule was therefore "write response speed into the service commitment" — and that rule went to work on the very next job.

Where this goes wrong

The order cannot be reversed. Without entry records, a review has no raw material; without a delivery standard, the conclusions of a review cannot land anywhere.
Do not try to build all three at once. Run one level until it is boring, then add the next.

4. What the mechanism looks like in practice: three files

The claim: the mechanism does not need heavy tooling. One register, one delivery checklist and one review document are enough to run it.

I cut the mechanism out of a 273-day agent system into three files on the income side:

File one: the opportunity register (entry convergence). It records every contact — source, requirement, quote, outcome. The point is not the recording. The point is that three months later you can answer "where do my clients come from" with data instead of with a feeling.

File two: the delivery checklist (physical gate). It defines "complete" precisely enough that you tick items off before handing over. With a checklist, delivery quality stops depending on the state you happen to be in that day.

File three: the review ledger (audit loop). Three lines at the end of every job: what went right, where it stalled, what to change next time. Three lines is enough; the hard part is continuity — 50 jobs a year is 50 experience rules that belong to nobody else.

In code, the whole thing is smaller than it sounds. Two of the three levels fit into the close-out step of a job:

# The income mechanism, reduced to the two checks that must not be skipped
from dataclasses import dataclass


@dataclass
class Job:
    source: str        # which channel brought this client
    keywords: str      # the requirement in the client's own words
    quote: float       # what was quoted
    deal: float        # what was finally agreed
    days: int          # how long delivery really took
    reviewed: bool = False
    rule: str = ""     # the lesson, if this job produced one


def close_out(job: Job) -> str:
    """Level 1 + level 3 in one place: no source, no close-out; no rule, no close-out."""
    if not job.source:
        raise ValueError("no source recorded - this job has no traceable origin")
    if not job.reviewed or not job.rule:
        raise ValueError("no review line - this job will teach you nothing")
    return f"{job.source}: {job.rule} ({job.days}d, quote {job.quote} vs deal {job.deal})"

The cost of this structure is close to zero. What it changes is the nature of the income: from "every job is a new beginning" to "every job is the continuation of the last one".

One of my own numbers, for scale: this system runs in the cloud for about CNY 2,500 a year. Low cost is not something you save, it is something you calculate — only when you know where every unit of spend goes can you see which one can go.

Where this goes wrong

Keep the tools light. Start with a spreadsheet; do not open with a database.
Keep the records short. Three review lines per job; anything longer will not survive contact with a busy week.

5. Where to start: three things you can do this week

The claim: getting in does not take three months. This week is enough to finish the first action of level one — build the table, log the first job, write the first review line.

Step one: build an opportunity register. No tooling needed. One spreadsheet file, five columns. Put your last three jobs into it today, and you will find that some of the information you can no longer remember. That "I cannot remember" is the problem itself.

Step two: write your first delivery checklist. Think back to the last job and list the points that had to be true for it to count as delivered. That list is the gate for your next job.

Step three: write three review lines tonight. No need to wait for the next job. Recall the most recent one you finished: what went right, where it stalled, what to change next time.

The three together take under an hour, but they start a loop. Once the loop turns, every job makes the next one easier — that is where compounding begins.

Where this goes wrong

Do not wait until you are "ready". A mechanism is raised from the first job, not installed before it.
Do not record only the wins. A lost job and a failed delivery carry more information than a good month.

6. Advanced: why engineering metrics, not money tricks

The claim: a trick solves one instance; a mechanism solves the long run. Managing income as an engineering metric is what turns it from a luck problem into a system problem.

The global research on AI monetization contains two very different ways of earning:

The first is the trick type: learn one prompt, copy one playbook, chase one trend. It works fast and decays fast — the trick is public, so supply and demand flatten it quickly.

The second is the mechanism type: build channels, define standards, run the loop. It starts slowly, but every delivery reinforces the system — like the operator in that research who runs 35 AI agents on her own. Her monthly clients are not paying for "a service". They are paying for a system that keeps running at a stable level.

The deepest thing I learned in agent engineering is this: an accidental success is not worth celebrating; a repeatable method is worth keeping. That sentence holds on the income side too.

Engineering certainty into income is not about earning one fast payment. It is about every unit of effort leaving something behind, and every delivery laying the road for the next one.

7. You, right now

Read it in one line: the root cause of unstable income is a missing feedback loop — and a loop does not care about your industry, so you can move the engineering mechanism you already know straight onto the income side.

Three realisations

Income behaves like weather because there is no loop: a single delivery ends the chain and the experience, the client and the method all drain away. Build the loop and the randomness drops immediately.
The order of the three levels cannot be reversed: entry convergence (traceable) → physical gate (stable) → audit loop (compounding). Skip one and you stall.
Tricks expire, mechanisms appreciate. A trick is public and gets flattened; a mechanism is private and hardens with time.

💎 What you should actually take away

Value one: a usable income mechanism template. Scenario — you want to systematise but do not know where to start. Solution — three files (opportunity register, delivery checklist, review ledger). Reusable value — you can build it today, at zero cost, depending on no tool.

Value two: a lens for judging the quality of your income. Scenario — assessing your own income structure. Solution — ask three questions: is the source traceable? does delivery have a standard? is every job reviewed? Reusable value — it locates the weak level in your income system within a minute.

Value three: a certainty mindset migrated from agent engineering. Scenario — anything that needs "make the accidental necessary". Solution — the three elements of a loop (record → standard → flow back). Reusable value — the same thinking applies to content production, client management and personal growth.

Three actions

Step	Action	How you know it worked
1	Build the opportunity register with your last three jobs (source / requirement / quote / cycle)	at least one pattern shows up that you had not noticed
2	Write a delivery checklist from the last job	the next job ships against the list with nothing missed
3	Write three review lines tonight (what went right / where it stalled / what to change)	the review becomes your next personal rule

One-liner: a trick solves "this time"; a mechanism solves "every time" — managing income as an engineering metric is the first step out of luck and into a system.

📖 Further reading from the Practitioner's series

About the author: Guanlan (观澜) — AI / Agent / digital transformation practitioner. Practical, hands-on writing — follow along and it just works.

The Four Rungs of AI Monetization: Are You Selling Your Time or a System?

weiwuji — Sat, 12 Sep 2026 13:29:23 +0000

The Pain: Same AI tools, same eight hours a day. One person makes $300 a month and another makes $30,000. Most people put the gap down to "not enough skill" or "not enough traffic", so they go back to working twice as hard inside the lowest rung — selling time. But no amount of time sold at the bottom ever buys you a higher price.
What You'll Learn:

A four-rung ladder from selling time to selling systems, with the barrier, the ramp-up period and the real income range for each rung

Why every business that can charge a monthly fee ends up shaped like "setup fee + monthly fee" — and what each half is actually paid for

Three counterintuitive findings from the data, and a test for deciding which rung you should move to next

⚡ Speed read (10 minutes): section 1 "Four rungs", section 6 "Three counterintuitive findings", plus the closing one-liner.

🎯 Read by need: taking client work → sections 2 and 3. Building a product → section 4. How the machine actually runs → section 5.

📖 Full read: about 10 minutes, with barrier, ramp and ceiling for all four rungs plus the upgrade test.

1. Four rungs: there is a mapping table between capability and income

Here is the core claim: monetization is not one continuous road. It is a four-layer structure, and before you start work you should know whether you are selling time, a service, a product, or a system.

In that global round of research, one table made this very clear. 47 interviews with independent operators earning over $5K a month, plus the revenue statistics of 8,000+ micro-SaaS projects, converged into four rungs:

Rung	What you sell	Barrier	Income ceiling	Typical ramp
L1 Sell time	Prompt packs, one-off gigs	Lowest	$300–$5K/mo	1–3 weeks
L2 Sell services	Managed operations, agency work	Needs industry know-how	$3K–$30K/mo	2–8 weeks
L3 Sell products	Micro-SaaS, digital products	Needs product ability	$500–$15K MRR (only 6.1% break $10K)	8–16 weeks
L4 Sell systems	One-person company + AI agent team	Needs engineering discipline	$20K–$30K+/mo	Requires engineering built first

Four rungs, four different things being sold — the barrier rises with the ceiling.

Remember three dividing lines first; they are more useful than the income ranges.

First, the line between L1 and L2 is not "can you use AI". It is: is the client buying one delivery, or a result that keeps existing?

Second, the line between L2 and L3 is whether delivery still requires you to show up in person. If you disappear and delivery stops, you are still in L2.

Third, the line between L3 and L4 is whether the system keeps running without you.

Two pitfalls worth naming here:

Do not read the four rungs as a staircase you must climb in order. The value of L1 is fast validation of willingness to pay — it is not a required gate on the way to L4.
Do not use effort from one rung to solve the pricing problem of the rung above. Push L1 to its absolute limit and the ceiling is still $5K.

2. L1, selling time: fastest to start, fastest to hit the ceiling

Here is the core claim: L1 is the only rung where you can prove within two weeks that somebody will pay you. It also has a structural defect — every time a job ends, revenue resets to zero.

The typical shape of this rung is prompt packs, scattered gig work, and small pay-per-delivery tasks. The barrier is the lowest, so it runs the fastest: 1–3 weeks to your first payment, and a tool stack costing under $100 a month.

A low barrier is an advantage, and it is also the pricing mechanism. Among those 47 operators there is a line that travelled a long way: of the $9 prompt packs on TikTok, 90% do not survive a single weekend. The reason is not complicated — the lower the barrier, the more supply there is, and price is set by supply, not by value.

I gave this income structure a name: time debt. The definition is that revenue is strictly bound to your hours and cannot accumulate — deliver this job, then the next one starts from zero again, and past deliveries generate no future cash flow.

Time debt has three symptoms, and they are easy to recognise:

Stop working and income stops: a week off is a week at zero
Nothing is reusable: the method you used for the last job has to be explained and rebuilt for the next one
Working harder does not raise your price: double the deliveries, same unit price — you just made the debt bigger

L1 is not useless. Among those 47 operators, almost everyone spent time on this rung, to confirm that willingness to pay is real. The problem is how long you stay: treat the validation period as a business model, and time debt starts charging interest.

Pitfalls for this chapter:

Do not pour more money into L1 by buying courses and tool packs — the bottleneck at this rung is the revenue structure, not technique
Do not treat a prompt pack as a product. It is closer to a flyer: it makes people aware of you, it does not make them pay you for years

3. L2, selling services: $3K–$30K, priced by industry know-how

Here is the core claim: at L2 the price is not set by your tools, it is set by whether you understand the client's industry. The same AI workflow sells for $3K to a client who knows their business and $300 to one who does not.

The shape of this rung is ongoing service — managed operations, content agency work, scraper-based lead generation, outbound calling. The ramp stretches to 2–8 weeks, and the barrier is industry know-how: someone who understands real estate brokerage builds an inbox triage service that no outsider can match on speed or quality, and the same goes for someone who understands e-commerce building store metadata.

The real deal structures published by the research can be read as templates:

Service	Sold to	Pricing structure
AI inbox triage	Independent realtors	$800 setup + $199/mo
Store SEO metadata + auto-generated image descriptions	E-commerce sellers	$1,200 setup + $99/mo per store
Form leads → CRM enrichment + AI personalised replies	Small teams	$1,500 setup + $299/mo

Setup fee makes deal one profitable; the monthly fee is paid for staying available.

Each half of the two-part structure has a clear job.

The setup fee covers your learning cost and implementation cost, so that the very first deal is profitable on its own — you are not waiting for future monthly fees to break even.

The monthly fee sells availability. Models get updated, APIs change, requirements drift, and maintenance is value in itself. A business with no monthly fee takes a net loss every time a platform changes.

There is an engineering meaning here too: monthly clients keep giving feedback, and feedback makes your delivery more accurate, which compounds. A one-off buyer tells you nothing afterwards.

The most common L2 mistake is treating capability mismatch as a problem of diligence. Capability mismatch means answering a higher-rung problem with lower-rung ability. The client is asking for a system; you deliver a demonstration of technique; your quote gets pushed to the bottom of the range. The correct order is the reverse — catch the client's problem with the professional ability you already have, and only then decide which tool solves it.

The second mistake is pricing distortion: the moment you charge and the moment value is created have come apart. The client's value keeps being produced while your billing has already finished — the tutorial is sold and done, the consulting session is answered and done, the delivery is handed over and dispersed. The fix is not to raise the price, it is to move the charging point later so that a monthly fee carries the part of the value that keeps existing.

Pitfalls for this chapter:

Do not start with a fully automated SaaS. Deliver a few deals by hand with AI tools, verify the demand, then productise
Pricing must include maintenance cost: APIs change and models get swapped, so a delivery with no monthly fee is a net loss on every change
Deal size decides the quality of the path: one client at $299/mo beats ten buyers of a $9 prompt pack

4. L3, selling products: $500–$15K MRR, median $145

Here is the core claim: revenue at the product rung is long-tailed. Across 8,000+ projects the average MRR is $4,298 and the median is $145; only 6.1% break $10K.

This is the set of numbers most worth remembering from the whole study:

Metric	Value
Average MRR of revenue-generating projects	$4,298
Median MRR	$145
Share breaking $10K MRR	6.1%
Projects in the $1K–$50K band	about 850
Ceiling sample	Rezi (AI resume tool) at roughly $200K MRR

The distance between an average of $4,298 and a median of $145 is nearly 30x. I call that gap long-tail bias: the average is dragged up by a handful of hits, so the industry looks busy, while the median is the actual situation of most products. Any project that tells you its "average revenue" — ask for the median first.

Long-tail bias gets misread as "products do not work". They do. It is evidence of a distribution problem: building the product is only half the job, and the other half is getting the people who need it to find it. Distribution ability is exactly what the service rung (L2) accumulates over long deliveries — you know where clients are, which words they use to describe the problem, and why they pay.

So the right posture at L3 is not "I want to build a product". It is: is the same class of problem I have already solved for clients something I can turn into a thing that runs by itself? The cycle is 8–16 weeks, and the first target should be $1K–$5K MRR — a band that already holds about 850 projects — not $200K.

Pitfalls for this chapter:

Answer one question before you build: what is my distribution channel? Without an answer, launch puts you straight into the median bucket
Do not drop service revenue in order to "build a product". Fund the cash flow with services while the product catches repeated demand — that is the small-step way through this rung

5. L4, selling systems: $20K–$30K+/mo, and how one person runs 35 AI agents

Here is the core claim: L4 does not sell any particular delivery. It sells a system that keeps running — the client pays monthly for "this is one thing I no longer have to think about".

The research includes a case reported by Forbes: a former senior analyst at a large tech company founded a marketing agency in May 2024 with no team, running 35 specialised AI agents with divided labour — marketing, customer service, content and data analysis each doing their own job. Monthly fees run $20,000–$30,000, and the business was profitable on its first day.

The capability barrier at this rung is very concrete, and it is called engineering: how tasks are divided, how deliveries are accepted, how errors are reviewed, how rules are fed back in. Without those four things, more agents just means more chaos; with them, more agents means more capacity.

The underlying reason one-person companies exploded in the past two years sits in the same place:

AI broke "company capability" into modules that can be assigned to agents: marketing, customer service, content, data analysis
Startup cost fell from hundreds of thousands to a few thousand: cloud tools plus subscriptions
Distribution cost headed toward zero: platform recommendation replaced ad buying

One more finding from the layered study at 500k.io: top operators publish their MRR and metrics openly and build trust through transparency, while median operators do not. And the layer is not only about revenue — the same $100K ARR at 30 hours a week and at 60 hours a week are two different tiers.

In my own production environment I have run an agent system for 273 days, and what settled out are four things: entry convergence (a task that was never registered is not allowed to execute), physical gates (output that fails the check is never produced), an error ledger (every incident becomes one rule), and rule re-injection (rules go into the next execution). None of those four things belong to any single industry — they are general-purpose parts of engineering, and they decide whether you can move from "I do it" to "the system does it".

Pitfalls for this chapter:

Do not buy a pile of agent tools before L4. Without acceptance mechanisms and an error ledger, the extra agents only add confusion
Do not read L4 as "hire AI employees to save money". It requires you to first write your own delivery process down clearly; a process you cannot describe will not become clearer when you hand it to an agent

6. Three counterintuitive findings, and one upgrade test

Here is the core claim: the mainstream story talks about "AI making money", while the data talks about "AI leverage × human professional ability". The distance between those two sentences is the reason the four-rung ladder exists.

Time invested correlates with the ceiling — but the curve is not straight.

Counterintuitive finding one: the mainstream "AI makes money" narrative is wrong. Supply of sold tricks is unlimited, so the price gets flattened almost instantly. All 47 operators were doing concrete delivery; not one was simply "type a prompt and collect money". AI is leverage on professional ability, not a replacement for it.

Counterintuitive finding two: the median is brutal. Median micro-SaaS MRR is $145. It is not that products fail — it is that most people never solved distribution. That is also why the ceiling of the fourth rung is usually blocked by distribution ability rather than development ability.

Counterintuitive finding three: the fastest route to revenue is not a product. Digital products take 1–3 weeks to start, services 2–8 weeks, SaaS 8–16 weeks. Time invested and ceiling are positively correlated: if you want the higher ceiling, accept the longer sedimentation period first.

Put those three together and the upgrade path becomes clear:

From	To	Capability you are missing	Test
L1 Sell time	L2 Sell services	Industry know-how	You can name three real pain points of the client's industry
L2 Sell services	L3 Sell products	Product ability + distribution	At least three different clients raised the same need, and you have a channel to reach them
L3 Sell products	L4 Sell systems	Engineering discipline	Your delivery process fits on a checklist, and an error can become a rule

Time invested and ceiling are positively correlated, but the curve is not a straight line: the product rung (L3) sits low because it is constrained by distribution, and only 6.1% of projects break $10K. Seeing that clearly is what stops you from treating "build a product" as a shortcut.

Pitfalls for this chapter:

Do not skip validation and jump a rung. Moving up does not require more tools; it requires the one capability the rung above has and yours does not
Do not explain the income gap with "AI is powerful". The tools are the same set for everyone — the gap lives in the delivery structure

7. Where you stand right now

One line to read it: the monetization gap is not in your tools, it is in your delivery structure — whether you sell a slice of time, a stretch of service, a product, or a system that runs on its own.

Three things to hold on to:

The dividing line across all four rungs is whether delivery can happen without you: L1 depends on you showing up, L2 on you knowing the industry, L3 on the product running itself, L4 on the system turning over by itself
Time debt, capability mismatch, pricing distortion and long-tail bias are the most common traps of each rung — give a trap a name first, then you can manage it
Time invested correlates with the ceiling, but the curve is not flat: the product rung is constrained by distribution, with a median of only $145, and there is no shortcut

💎 What you should actually take away

Value one: a self-check map of the rungs. Scenario = working out which rung your current income sits on. Solution = locate yourself with the four columns of what you sell / barrier / ceiling / ramp. Reusable value = you can immediately judge which capability to add, instead of doubling down on hours inside the rung you are already in.

Value two: a pricing structure you can copy directly. Scenario = quoting a client for a delivery. Solution = a setup fee (covering implementation cost, so the first deal is profitable) plus a monthly fee (selling availability and maintenance). Reusable value = the three real deal structures ($800 + $199/mo, $1,200 + $99/mo per store, $1,500 + $299/mo) can be adapted to your industry by changing the numbers.

Value three: an upgrade order. Scenario = climbing from your current rung to the one above. Solution = close the gap in the order of industry know-how → product ability + distribution → engineering discipline. Reusable value = every step has a test (you can name three pain points / three clients raised the same need / the process fits on a checklist), and if the test does not pass, you do not upgrade — which is how you avoid skipping a rung.

Three-step action table:

Step	Action	Verification
1	Write down how you deliver today and locate yourself against the four rungs	You can say which rung from L1 to L4 you are on, with one sentence of reasoning
2	Find the most typical trap of that rung (time debt / capability mismatch / pricing distortion / long-tail bias)	You list at least one trap you are currently in, with the concrete symptoms written out
3	Convert one price into a two-part structure, or close the missing capability for the rung above	Your next quote has two parts, setup fee plus monthly fee — or you complete one capability exercise

One-liner: what decides your rung is not your tools, it is whether delivery can happen without you. The ceiling of selling time is set by your calendar; the ceiling of selling systems is set by the mechanism.

📖 Further reading from the Practitioner's series

About the author: Guanlan (观澜) — AI / Agent / digital transformation practitioner. Practical, hands-on writing — follow along and it just works.

One Python Agent Core, Four Ways to Run It: Nova on Server, Web, TUI, and Desktop

bigrivi — Sat, 12 Sep 2026 13:29:11 +0000

Nova is an open-source personal AI agent runtime for developers. One Python core is available through terminal, web, desktop, and API, so you get a single local workspace for model providers, tools, sessions, memory, MCP, and sub-agents.

The practical problem it addresses is familiar: you start an agent in the terminal to fix a bug, then you want the same setup for a longer task you check from a browser, then you want an API you can script against, then something clickable on the desktop. Without a shared runtime, that becomes four tools, four configs, and four ways for behavior to drift.

Nova's answer, in its README's words, is "Your open source AI agent on desktop, terminal, web, and API." The same agent core in nova/ drives the TUI, server, frontend, and desktop. What changes is the surface. What stays the same is the agent loop, the tool registry, and the SQLite store.

One shared runtime

All four surfaces use the same pieces:

The same agent loop decides what to do next, calls tools, and streams back text, reasoning blocks, tool calls, and tool results.
The same tool registry provides 21 built-in tools, plus whatever your connected MCP servers add at runtime.
The same SQLite store keeps sessions, messages, agents, and memories under ~/.nova/nova.db.

The runtime home lives at ~/.nova/, with config.json, nova.db, logs/nova.log, skills/, workspace/, and agents/ alongside it. You can point it elsewhere with NOVA_HOME if you keep dotfiles or checkouts isolated.

That shared store is what makes switching surfaces uneventful. A session you start in the terminal is stored in the same SQLite file the web UI and desktop read from. Pick a model with /models in the TUI or with the model selector in the web UI. Add persona files like IDENTITY.md, SOUL.md, USER.md, or MEMORY.md and they land in the system prompt no matter which surface you open.

Four interfaces, same agent

Nova exposes the core in four ways:

nova serve                      # HTTP server on http://127.0.0.1:8765
nova web                        # built web UI in the browser
nova tui                        # OpenTUI terminal client from any directory
./nova-tui                      # equivalent source-checkout launcher
nova desktop                    # desktop window

nova serve runs a FastAPI backend with an SSE stream at POST /api/chat/stream. nova web serves the built frontend from the same backend address and opens your browser. nova tui is a Bun plus React plus OpenTUI client that streams text, reasoning, tool calls, and inline diffs for edit and write. nova desktop hosts the built frontend in a PyWebView window with the backend on a background thread. Use nova desktop --dev when working against the Vite dev server.

Nova's web interface starts with a focused chat composer, a Workspace selector, and a model picker.

For frontend work with live reload, run the two halves separately:

nova serve
cd frontend && npm install && npm run dev

Vite proxies /api/* to the backend, overridable with NOVA_FRONTEND_PROXY_TARGET or VITE_NOVA_API_BASE_URL. The quickstart has the full mapping.

Pick the surface that fits the moment and keep the same agent underneath. Short fix in the TUI, long-running task in the web UI, scripted call over the API, casual use on desktop.

What stays shared when you switch surfaces

It helps to be precise about what "same agent" means here, because the four surfaces do not look or feel the same, and that is intentional.

What stays shared is the state and the loop. Sessions, messages, agents, and memories live in the same SQLite file, under the same runtime home with its config, logs, skills, workspace, and agents folders. The agent loop, the tool registry including whatever MCP servers you connected, the per-session workspace semantics, and the persona files injected into the system prompt all behave the same no matter where you open Nova. That is why stopping a task in one place and continuing it in another needs no export step. The history is already there.

What stays different is everything about interaction. The TUI is keyboard-driven with slash commands, Escape to interrupt, inline diffs for file changes, and tree-sitter highlighting. The web UI leans on a thread list, composer, workspace folder picker, memory manager, approval dialog, and language switcher. The desktop hosts that same built frontend in a PyWebView window with the backend on a background thread. The API has no UI at all and instead streams text, reasoning blocks, tool calls, and tool results over SSE for you to render however you like.

The tradeoff is straightforward. You get continuity of state without uniformity of interface. Each surface keeps the controls that make sense for its setting, so there is still a small adjustment when you move. The benefit is that the adjustment is only about controls, not about reconfiguring providers, tools, or memory from scratch.

Bring your own model, including local models

Model access lives in ~/.nova/config.json. Only providers and optionally mcp_servers sit at the top level. Aliases under providers are yours to name.

Nova supports four provider type values: ollama, openai-compatible, openai-response, and anthropic. Ollama runs locally with no API key, openai-response targets the Responses API, and Anthropic supports extended thinking.

At the current checkout, openai-response is configured through the config file or API rather than the frontend provider dropdown.

If you already run Ollama locally, this minimal config from the documented quickstart is enough to start:

{
  "providers": {
    "ollama": {
      "type": "ollama",
      "options": { "base_url": "http://localhost:11434" },
      "models": { "qwen2.5:7b": { "name": "qwen2.5:7b", "tools": true } }
    }
  }
}

Swap in whatever model you have pulled. The key part is "tools": true so the agent can actually call tools.

Tools, MCP, and a workspace you control

The built-in set is fixed and documented: read, write, edit, shell, code_run, glob, grep, web_search, web_fetch, browser_use, read_image, todo_write, ask_user, memory tools (save_memory, search_memory, list_memories, delete_memory), delegate_to_agent, and skill tools (list_skills, load_skill, install_skill).

Any MCP server you connect over stdio or SSE/HTTP shows up as extra tools too. code_run executes inline Python with dependencies auto-installed to ~/.nova/site-packages/. Web fetch returns Markdown with a 5MB cap, alongside web search. browser_use registers when Playwright imports. Image and document attachments ride on POST /api/chat, with read_image returning base64 plus extracted text.

Set a per-session workspace folder and shell, code_run, glob, and grep respect it. Shell commands pass a three-tier approval gate of blocked, needs approval, and auto-run, with dangerous ones asking over SSE and an optional allowlist. For longer sessions, two-layer compaction trims old tool output to disk and summarizes older turns.

The web interface keeps multi-step work visible rather than collapsing it into a single loading state. In the example below, Nova searches for recent open-source agent developments, opens first-party sources, cross-checks claims, and reports progress between rounds. It also catches a misdated OpenHands item before producing the final briefing.

Nova reports progress between research rounds, tracks tool calls, and surfaces corrections made during source verification.

Three workflow patterns that show the architecture

The shared runtime matters most once you see how different tasks pull on it.

Terminal code work with reviewable diffs. Set a per-session workspace folder so file search and shell execution start from the checkout you mean, then work through reading, searching, and editing from the TUI. Successful file changes render as inline diffs you can read before moving on, and Escape interrupts a run that heads the wrong way. The workspace keeps everyday commands scoped to the task, while an explicit working directory still wins when you pass one, so treat it as a scoping aid that reduces mistakes rather than a boundary. This pattern fits tight fix loops where you stay in one repo and want quick review cycles.

The TUI takes an instruction, reads a file, applies an edit shown as an inline diff, with model and context status visible.

Multi-round web research with visible progress. In the web UI, a research task becomes a series of search and fetch rounds with progress reported between them instead of one long silent wait. Fetched pages arrive as Markdown, the thread keeps tool-call counts and intermediate findings, and corrections surface in the open when a source does not check out. The implication is that verification work stays inspectable. You can follow which sources were opened, what was cross-checked, and where the final briefing diverged from an early lead.

Scripted use through the HTTP and SSE endpoint. The same loop is available over HTTP for scripts, with chat streaming text, reasoning, tool calls, and results over SSE and attachments accepted alongside chat requests. Approval prompts for sensitive commands arrive over that stream and are answered through a dedicated approval endpoint, with an allowlist to remember routine approvals. The tradeoff here is control versus convenience. A script gets the full agent behavior including tools and memory, but it also takes on rendering progress, handling approvals, and deciding when to stop and retry.

Sessions, memory, skills, and sub-agents

Persistent sessions are the default. Threads, messages, agents, and memories live in SQLite, so you can stop a task in one surface and pick it up in another without exporting state.

Memory covers fact, preference, decision, and context types across user, project, and session scopes, with search and optional AI reranking. The frontend includes a memory manager next to the thread list, composer, model selector, workspace folder picker, and approval dialog. The TUI covers /new, /sessions, /clear, /models, /install-skill, and /quit, with Escape to interrupt and inline diffs for edit and write.

Skills live as ~/.nova/skills/<name>/SKILL.md files, scanned at startup and loaded on demand through list_skills and load_skill. install_skill pulls from ClawHub only when you ask.

When a task splits cleanly, delegate_to_agent spawns a sub-agent with the hierarchy persisted in SQLite and surfaced over the API. Sub-agents run without MCP tools or further delegation, which keeps delegated work bounded.

Where to extend it without forking it

Nova leaves a few deliberate seams where your own setup slots in, and each one answers a different kind of change.

Provider aliases are the first. The top-level config holds only providers and optionally MCP servers, and the names under providers are yours to choose. That means pointing Nova at a new account, endpoint, or local model is a config edit rather than a code change, and you can keep several named setups side by side for different tasks.

The database layer is another extension seam. Nova's agent, session, memory, and configuration services depend on the NovaRepository protocol instead of directly depending on SQLite. The current provider factory ships with aiosqlite and in-memory implementations, but it can register another provider by name. A MySQL-backed deployment would implement the repository protocol, create it through a DataSourceProvider, and register that provider with the factory. That is still real adapter work—the protocol covers sessions, messages, agents, compaction, and memory—but it keeps database-specific code behind one boundary instead of spreading SQL changes through the agent runtime.

MCP servers are the second. Any server reachable over stdio or SSE and HTTP becomes extra tools at runtime, initialized in parallel with a per-server timeout. The practical effect is that new capabilities arrive as processes Nova talks to, not patches to the agent itself. If a server is slow or missing, only its tools are affected.

Local skills are the third. A skill is a folder with a SKILL.md file under the runtime skills directory, scanned at startup and loaded only when the task calls for it. Fetching from ClawHub happens only when you ask for it. This suits repeatable procedures you want written down once and reused, like a review checklist or a repo-specific workflow, without baking them into every prompt.

Persona files are the lightest touch. Short markdown files describing identity, background, user context, and retained notes are injected into the system prompt on every surface. They shape tone and defaults without touching tool wiring.

Sub-agents are the most structured seam, and also the most bounded. Delegation persists the parent-child relationship and exposes it over the API, but the child runs without MCP tools and cannot delegate further. That bound is worth understanding before you lean on it. It keeps delegated work predictable and easy to trace, at the cost of ruling out recursive fan-out. Use it for cleanly separable chunks, not for open-ended chains.

What keeps longer runs manageable

Longer tasks fail in familiar ways. They stall waiting on a risky command, loop on the same call, outgrow context, or forget a decision from an earlier session. Nova addresses each with a separate mechanism, and each asks something of you.

Approval tiers handle the risky-command case. Shell input falls into blocked, needs approval, or auto-run by pattern, with sensitive prompts delivered over the stream and answered through an approval endpoint. A rememberable allowlist smooths repeated runs of commands you trust. The tradeoff is interruption. Tighter patterns mean more pauses, while a generous allowlist means fewer pauses and more responsibility for what you pre-approved.

Repeated-call guardrails handle loops. The run halts after several identical calls or identical failures in a row, and warns after a run of read-only calls. This catches the agent re-reading the same files or retrying the same failing command instead of reconsidering. When you hit one, the fix is usually in the task framing rather than the limit.

Two-layer compaction handles context growth. Older tool output is snipped to per-session files on disk while older turns are summarized, with tuning available for how aggressive each layer is. Snipped output stays retrievable rather than vanishing, which matters when you need to audit what the agent actually saw three rounds back.

Persistent memory handles cross-session recall. Stored items carry a type like fact, preference, decision, or context, and a scope of user, project, or session, with search and optional reranking when you look something up. There is no per-turn prefetch, so memory does not silently steer every reply. The implication is direct. What you explicitly save and search for carries forward, and what you never write down does not. For longer projects that means building a small habit of saving decisions and preferences as they settle.

A starting point you can shape

If building an agent from scratch sounds like too much plumbing, and taking a ready-made product as-is feels too rigid, Nova sits in the middle. The shared runtime, provider wiring, tool registry, SQLite persistence, four interfaces, MCP loading, skills, and sub-agent handling are already wired together, so you start from working code rather than an empty repo. As Apache-2.0 open source, you can inspect each part in nova/, modify or replace what you need, and build your own setup on top while keeping the rest.

Local quickstart

Nova needs Python 3.12 or newer:

git clone https://github.com/bigrivi/nova.git && cd nova
pip install -e .                # Python 3.12+
playwright install chromium     # only if you want the browser tools

If nova is not found afterward, add your environment's bin/ directory to PATH. The full walkthrough is in the installation guide.

Then add a provider to ~/.nova/config.json as shown above, and start where you want to work:

nova serve                      # HTTP server on http://127.0.0.1:8765
nova web                        # built web UI in the browser
nova tui                        # OpenTUI terminal client from any directory
nova desktop                    # desktop window

Pick a model via /models in the TUI or the model selector in the web UI, and you are running the same core everywhere.

One practical note: shell and code_run execute locally as your user and are not sandboxed, so point Nova at repos and machines you can afford to change.

How the source tree is organized

The shared runtime lives in nova/, with the terminal client in tui/, the web UI in frontend/, tests in tests/, and guides in docs/. Inside nova/, each package owns one concern:

agent/ runs the agent loop that plans the next step, calls tools, and streams results.
app/ wires the runtime pieces together at startup.
config/ handles runtime configuration under ~/.nova/.
db/ implements persistence behind the repository protocol, backed by SQLite.
desktop/ hosts the desktop window around the built frontend.
llm/ holds the model provider implementations.
mcp/ loads connected MCP servers as extra tools.
memory/ stores and searches memory records across scopes.
prompt/ assembles the system prompt, including persona files.
server/ serves the HTTP backend and the chat stream.
session/ manages session and thread state.
skills/ scans and loads local skills on demand.
tools/ registers the built-in tool set.
utils/ holds shared helpers.
__main__.py is the nova console entry point for serve, web, tui, and desktop.
settings.py parses ~/.nova/config.json.

As a rough map: models go in llm/, persistence in db/, streaming and API behavior in server/, prompt assembly in prompt/, tools in tools/, the terminal client in tui/, and the web frontend in frontend/.

If you want to contribute

Setup follows the contributing guide. Install the Python package with dev tooling:

pip install -e ".[dev]"

Frontend and TUI dependencies are separate:

cd frontend && npm ci

cd tui && bun install

Run the suite from the repo root. No PYTHONPATH setup is needed:

pytest

Run a subset while iterating:

pytest tests/test_server.py -q

The contributing guide currently reports 392 passing and 6 skipped. The skipped tests are the live Ollama end-to-end suite, which is opt-in:

RUN_LIVE_OLLAMA_SERVER_E2E=1 pytest tests/e2e -q

Tests use an internal faker provider, so CI runs without real API keys. Browser tooling is optional: playwright install chromium adds it, and no test requires it.

For bigger changes, open an issue first to discuss the approach. Report vulnerabilities through the repo Security tab, not a public issue.

Who this is for

Nova fits developers who want a local-first agent they can read end to end, who want to start with Ollama and no API key, who like sessions kept in one inspectable SQLite file, and who want to move between terminal, browser, desktop, and HTTP without switching agent implementations.

Clone it and run it

Nova is Apache-2.0 licensed, and the code, docs, and issue tracker all live at bigrivi/nova.

If a single local runtime for providers, tools, sessions, memory, MCP, and sub-agents sounds useful, start with the README, clone the repo, run it locally with Ollama or your own key, and star it if it proves useful.

The Five-Bucket Model of AI Monetization: Distribution First, Cash Second, Equity Last

weiwuji — Sat, 12 Sep 2026 13:28:27 +0000

The Pain: Most people talking about AI monetization get stuck on the same move — build the product first, then go find someone to buy it. The product ships and the customers are not there. You buy one batch of traffic, and next month you have to buy the next batch all over again. Greg Isenberg runs the order backwards: distribution first, services second, and only then do products and investing collect the upside.
What You'll Learn: What actually keeps each of Greg's five buckets alive (services, exits, advisory, media, investing), why a content flywheel keeps pushing customer acquisition cost down instead of up, the six directions he gives for making money with GPT-6 Astra, and a simple framework for judging how many buckets you are already holding today.

⚡ 10-minute fast read: jump to "2. How the flywheel turns", "5. Single-bucketing and distribution debt", and the one-liner at the end.

🎯 Read by need: for the business model, read sections 1 and 2; for concrete moves, read sections 3 and 4; to check yourself against it, read sections 5 and 6.

📖 Full read: about 10 minutes, and you come away with Greg Isenberg's revenue structure plus a flywheel lens you can move onto your own business.

1. Greg Isenberg's five buckets: five cash-flow entries for one person

The core claim: Greg's income is not one business. It is five cash-flow buckets stacked on top of each other — services, exits, advisory, media, investing — and each bucket has a different cash-flow personality.

First, who this person is. Greg Isenberg has been a head of product and a founder: 5by was acquired by StumbleUpon (2013), and Islands was acquired by WeWork. Those two exits are public, checkable facts, and they are the credibility floor under every advisory and investment opportunity he has had since. Today he runs a more complicated revenue structure, which I have organized into five buckets:

Bucket	Contents	Cash-flow character
① Late Checkout (holding company)	Agency (services) + Studio (own products) + Fund (investing)	Services = cash today; products/investing = upside tomorrow
② Company exits	5by → StumbleUpon (2013), Islands → WeWork	One-time lump sum + credibility
③ Advisory	Reddit, TikTok	Cash / equity
④ Media	YouTube / podcast / newsletter / courses	Builds distribution, lowers acquisition cost for everything else
⑤ Angel investing	Consumer + developer-tool early-stage projects	Asymmetric upside

Stare at that table for a moment and the first counter-intuitive point falls out: of the five buckets, only media does not collect money directly. Yet ordered by cash flow, it is the foundation of the whole structure.

The second counter-intuitive point: the five buckets do not carry risk on the same line. The services bucket has delivery pressure, but the money lands today. The exits bucket is a one-time event, monetizing credibility accumulated over years, and it is not repeatable. The media bucket is expensive up front and slow to pay back, and it pushes the acquisition cost of every bucket behind it down at the same time.

Pitfalls in this section:

Do not read the five buckets as "five jobs" — what he is actually running is one portfolio of cash flows, where buckets feed each other, not a list of parallel side hustles
Do not skip the bucket that does not charge money — media is the lever in this table that lowers acquisition cost for the other four; cut it and every remaining bucket has to be fed with paid traffic

2. How the flywheel turns: content in front, services in the middle, equity at the back

The core claim: the real job of the five buckets is to string themselves into a flywheel — content builds distribution → acquisition cost drops → services collect cash flow → products and investing collect equity → case studies feed the content back in.

Line the five buckets up along a timeline and the shape of the flywheel appears:

Content builds distribution: YouTube, podcast, newsletter, courses — turning strangers into readers, continuously
Acquisition cost drops: readers become leads, and clients for services and products walk in from the content instead of being bought one by one
Services collect cash flow: the Agency delivers first, money lands today, and it feeds the products and the investments
Products and investing collect equity: Studio's own products and the Fund's investments earn tomorrow's upside
Case studies feed content: real cases that come out of service delivery become the raw material for the next round of content

The key to this flywheel is not that there are five buckets. It is whether step 5 really gets back to step 1.

A lot of people run a broken model: produce one round of content, close one batch of service clients, and then nothing — the next batch of clients needs a fresh round of content and a fresh batch of ads. In Greg's model, the case study is the content: on the day a delivery finishes, the next round of material is already collected.

Greg put the underlying problem plainly on his podcast: capability has gone up, but people's willingness to try new things has not. The flywheel sells exactly one thing — a lower threshold for trying. A reader who has seen several real cases is willing to pay for the first time, and every one of those cases came out of the previous delivery.

Pitfalls in this section:

Do not read the flywheel as "build an audience first, monetize later" — every step of the flywheel produces cash flow, only in a different order; it is not "grind for free for a few years"
Design the return path on purpose: write the delivery process up as content right after the delivery, instead of waiting for inspiration to arrive

3. Greg's six ways to make money with AI: from service-software to mini-games as a lead magnet

The core claim: of the six directions Greg lays out, exactly one is described as the highest-value one — turning a service into software. The other five all answer the same question: which slice of the work does AI actually take over?

In his "GPT-6 Astra: how I will make money with it" piece, he gives six concrete directions:

Service → software: start from a service clients already pay for, break down the delivery process, let an AI product take the first-pass delivery, and charge a $500–5000/month subscription
Optimize existing products: work on performance, security and UI — he gives one measured case where an application's response time went from 800ms to 20–30ms
Company operating dashboard: pull docs, Stripe, analytics and call records together, ask once a week "what makes money, what wastes time, what should we stop", then commit to three things for the coming week
Browser agent automation: let an agent walk real websites and fill real forms, and turn the process into a reusable SOP
Cost-of-living optimization: bill negotiation and low-price monitoring on second-hand marketplaces
Mini-games as a lead magnet: the game has to bring in clients, give people a reason to share it, and include a way to capture leads

Direction 1 and direction 6 are connected: one goes up, turning a service into a subscription product; one goes down, using a mini-game to pull leads in at the bottom. The four in the middle all answer the same question — which piece of work AI actually does.

The judgment underneath is plain: AI can do a great many things, but only one class of them can be charged for — the things somebody was already paying for.

Pitfalls in this section:

Do not pick a direction by asking "what can AI do"; work backwards from "who has already paid for this"
Service-software is not the same as building a SaaS: the core move is breaking the process into fine steps, keeping human judgment points with humans, and handing over only the rest

4. The starting point is not technology — it is a service clients already pay for

The core claim: Greg's starting point for product ideas is not a technology trend. It is the service clients are already willing to pay for — payment first, product second.

His own words are that services clients are already willing to pay for are where he starts looking for product ideas.

That sentence locks the order in place. Most people go: learn a tool → build a thing → find a buyer. Greg goes: see who is paying for what → take the delivery process apart → rebuild one slice of it with AI.

He is explicit about what "taking the process apart" means in practice: break it into steps, tools, inputs, outputs, and the points where a human has to make a judgment.

The most valuable half of that sentence is the end — the points where a human has to make a judgment. A lot of AI products fail because the parts that should stay with a person get handed to the model too, and delivery quality falls off a cliff. Keep the human. What AI takes over is the repetitive labor, not the right to decide.

There is outside confirmation for this direction, too. Anthropic's Building Effective Agents keeps coming back to one point: solve the problem the simplest way first, and if a fixed workflow can do it, do not rush into a more autonomous agent — define the steps, the inputs and the outputs clearly first. That points at the same thing as Greg's "break it down": define the process before you talk about automating it.

Pitfalls in this section:

Do not swap payment validation for technical validation — a working piece of technology does not prove anyone will buy it; a paid transaction does
When you break the process down, do not hand the human judgment points to AI as well; that line is where delivery quality lives

5. Single-bucketing and distribution debt: the two most expensive traps

The core claim: most people who stall on AI monetization are not blocked by ability. They are blocked by two structural mistakes — single-bucketing and distribution debt.

Single-bucketing first. It means reading AI monetization as "run one bucket": either build products with no distribution, or take orders without ever accumulating case studies — either way the income hangs off a single source.

It has two typical shapes.

The first: products with no distribution. You build something and nobody knows it exists. The micro-SaaS numbers from an earlier post in this series are what that road produces: among projects with revenue, the average is $4,298 MRR and the median is $145. Shipping the product is only half the job; the other half is letting the people who need it find it.

The second: taking orders without accumulating case studies. Every job starts from zero, client flow depends entirely on platform dispatch and your own ad spend, and when the job is done no asset is left behind.

Then distribution debt. It means running no content asset at all and buying traffic again for every new batch of clients, so the acquisition cost rolls up into a debt you have to keep servicing.

It compounds like this: no content asset → every client has to be bought → traffic gets more expensive → margin gets eaten → even less capacity to build content. Two or three turns of that, and you never get back to step 1.

Greg's fix is exactly to invert the order: build the media bucket first, let readers walk in on their own, and the acquisition cost of the other buckets falls together.

Pitfalls in this section:

Do not use "accumulate first, monetize later" to justify single-bucketing — every step of the flywheel needs a cash-flow exit
The expensive part of distribution debt is not the money spent on traffic; it is the absence of a content asset. Money spent gets spent again; an asset you build keeps working

6. The OPC interface: how many buckets are you already holding

The core claim: treat the five buckets as a self-check sheet — most one-person companies already hold two or three of them, they just have not noticed those buckets can be strung together.

Of the five, the lowest-barrier and most easily ignored is media. It needs no product and no inventory. It only needs you to keep writing about what you are already doing.

Ask yourself three questions against it: do you have a service capability (your day job is the services bucket)? Do you have case studies worth accumulating (the deliveries that bucket has already shipped)? Do you have a content outlet (a blog, a newsletter, a public account)?

The order I set for myself is: build distribution with the media bucket first, collect cash flow with the services bucket second, and only then think about products and investing — which is precisely Greg's ordering.

For most people the first action is not "build an AI product". It is "take the service you are already delivering, break it into steps, tools, inputs, outputs and the points that need human judgment", and then write it down. The writing is the distribution. The breakdown is the starting point of the product.

Pitfalls in this section:

Do not wait until you feel "ready" to start writing — the media bucket earns its value from accumulated time, and starting earlier is cheaper
Do not spread effort evenly across five buckets: close the loop on one bucket first, then stack the next

7. You, right now

One sentence: Greg's five-bucket model is not five roads to money, it is one cash-flow structure — media builds distribution, services collect cash, products and investing collect upside, and case studies feed the content back into step one.

Three things to take away

Order matters more than effort: distribution first, cash second, upside last is the core of this structure. Run it backwards and you are paying the most expensive acquisition cost to sell the least certain product
The starting point is a service someone already pays for: "services clients are already willing to pay for" is where product ideas begin — payment first, product second
The flywheel closes on case studies: in a model where cases never return, every new batch of clients needs a fresh batch of bought traffic — that is where distribution debt starts

💎 The real value you should leave with

Value one: a five-bucket self-check sheet. Scenario: evaluating your own revenue structure. Method: walk the services / exits / advisory / media / investing buckets one by one and see which produce cash flow and which lower cost. Reusable value: you can tell at a glance whether your income hangs off a single source.

Value two: a process breakdown. Scenario: turning a service you deliver into an AI product. Method: break it into steps, tools, inputs, outputs and the human judgment points, and let AI take only the standardizable slice. Reusable value: you do not need to learn a tool first — get the process clear and you can already tell whether the thing can become a product.

Value three: a flywheel test. Scenario: deciding whether to keep investing in content. Method: use "can cases feed the content back" to test whether the content investment is worth it. Reusable value: it turns content from extra work into a required part of the structure.

Three steps to run this week

Step	Action	Check
1	List every service you have been paid for (salary included)	For each one you can say who paid and how much
2	Pick one and break it into steps / tools / inputs / outputs / human judgment points	When you are done you can point at the slice that can go to AI
3	Write the breakdown up as one piece of content and publish it	Within 30 days you get your first real inquiry that came from content

One-liner: the five-bucket model does not start from "what AI capabilities do I have", it starts from "who has already paid for what" — the first is a tool, the second is a business.

📖 Further reading from the Practitioner's series

About the author: Guanlan (观澜) — AI / Agent / digital transformation practitioner. Practical, hands-on writing — follow along and it just works.

From Reactive to Proactive: How Cisco Meraki's AI Is Building the Self-Managing Network

Novbox — Sat, 12 Sep 2026 13:28:08 +0000

For most IT teams, network management is a firefighting exercise. An alert fires, a user complains, a dashboard turns red — and someone scrambles to diagnose the problem, trace the source, and push a fix. It works, but barely. And in a world where a 10-minute outage can cost thousands in lost productivity, "reactive" is no longer a viable strategy.

Cisco Meraki is changing this dynamic fundamentally. By embedding machine learning, predictive analytics, and intelligent automation directly into the Meraki Dashboard, businesses can now operate networks that identify problems before they happen — and in many cases, fix them automatically without human intervention.

"The network is no longer just infrastructure — it's an intelligent system that can think, predict, and act on your behalf. That's the vision Cisco Meraki is delivering today."

— Cisco Meraki Network Intelligence Report

What Does a "Self-Managing Network" Actually Mean?

The phrase "self-managing network" sounds futuristic, but Cisco Meraki is making it a practical reality for businesses of all sizes today. At its core, a self-managing network uses three capabilities working in concert:

Continuous monitoring — Every device, client, and application is tracked in real time across your entire network, from the data center to the edge.
AI-driven analysis — Machine learning models process millions of data points per second to identify patterns, anomalies, and degradation trends that no human team could spot manually.
Automated remediation — When the system detects an issue — or predicts one is coming — it takes corrective action automatically, from rerouting traffic to rebalancing wireless channels to alerting IT with a specific diagnosis and fix.

Together, these capabilities shift your IT team from spending 80% of their time reacting to problems to spending that energy on strategic projects that actually grow the business. Learn more about how this all comes together on the Why Meraki page.

Meraki Insight: Seeing the Network Through the Application's Eyes

One of the most powerful AI tools in the Meraki platform is Meraki Insight — an application performance monitoring layer that correlates network behavior with the applications your users depend on most.

Traditional network monitoring tells you when a switch port goes down or a WAN link hits capacity. Meraki Insight goes further: it shows you when Microsoft Teams calls are degrading, when Salesforce is loading slowly, or when a branch office's connection to your ERP is underperforming — and it tells you why.

Web Application Health — Monitors over 500 popular SaaS applications and scores their performance across every site in your network.
WAN Health scoring — Assigns a health score to every WAN link based on latency, jitter, packet loss, and capacity — giving IT a single number to track and report on.
Baseline deviation alerts — The AI establishes a performance baseline for each application and location, then fires alerts the moment behavior deviates — often before users even notice.
Root cause isolation — Instead of telling you "something is slow," Insight tells you whether the problem is in your LAN, your WAN, your ISP, or the application's own servers.

This level of visibility transforms troubleshooting from a multi-hour investigation into a two-minute fix. Pair Insight with Meraki MX security appliances for end-to-end application-aware intelligence across every site.

Intelligent RF: When Your Wi-Fi Manages Itself

Wireless networks are the most dynamic and difficult-to-manage part of any business environment. Channel interference, client density, competing signals, and device proliferation create a constantly shifting landscape that static configurations can never keep up with.

Cisco Meraki's Auto RF (Radio Resource Management) uses machine learning to continuously optimize your wireless environment — adjusting channel assignments, transmit power levels, and band steering settings across every access point in real time.

Dynamic channel assignment — APs scan the RF environment and automatically move to the least-congested channels without manual intervention.
Transmit power optimization — Power levels adjust dynamically to maintain optimal coverage without creating interference between adjacent APs.
Client load balancing — The system distributes clients intelligently across APs and frequency bands to prevent any single radio from becoming a bottleneck.
Air Marshal security — A dedicated scanning radio on every AP continuously monitors for rogue devices, evil twin attacks, and unauthorized network access.

The result is a wireless network that consistently delivers high performance without requiring a wireless engineer on-site or on-call. Explore Cisco Meraki wireless access points built on this intelligent platform.

Predictive Alerts and Generative AI: The Future Is Already Here

Cisco Meraki's AI capabilities extend beyond monitoring and optimization — they now include predictive failure detection and a generative AI assistant embedded directly in the dashboard.

Predictive alerts analyze historical device behavior to identify when hardware is trending toward failure — whether it's a switch showing abnormal error rates, an AP whose performance is degrading, or a WAN link with increasing packet loss patterns. IT teams get a heads-up days before a failure occurs, turning a critical outage into a planned maintenance window.

The generative AI assistant takes this further by letting IT administrators ask plain-language questions about their network: "Why is building B's Wi-Fi slow this morning?" or "Which clients connected to the main office in the last 48 hours?" The assistant synthesizes data from across the Meraki platform and returns a clear, actionable answer — no dashboards to dig through, no CLI commands to remember.

Anomaly detection — ML models flag unusual traffic patterns, unexpected device behavior, and potential security incidents automatically.
Hardware lifecycle prediction — Identifies devices approaching end-of-life based on performance degradation trends, not just calendar dates.
Natural language queries — Ask the dashboard anything in plain English and get a precise, data-backed answer instantly.
Automated firmware management — Scheduled and tested firmware updates roll out automatically across your fleet during maintenance windows, with rollback protection built in.

This isn't AI as a marketing buzzword — it's AI doing real operational work that previously required experienced engineers. For businesses managing cloud-managed switching, wireless infrastructure, and security appliances from a single pane of glass, this is a transformational capability.

The Business Case: What AI Networking Actually Saves

The ROI of an AI-managed network isn't theoretical. It shows up in measurable ways across every department that touches IT:

Fewer unplanned outages — Predictive detection catches issues before they become failures, reducing downtime incidents by an industry-estimated 40–60%.
Faster mean time to resolution — Root cause analysis that used to take hours now takes minutes, because the AI has already done the diagnostic legwork.
Reduced IT headcount pressure — One IT generalist with Meraki can manage what used to require a specialized network engineer and a help desk team.
Better user experience — When performance issues are caught proactively, employees never experience the degradation — it's resolved in the background while they stay productive.

For growing businesses that can't afford a large IT staff but can't afford downtime either, Cisco Meraki's AI platform bridges that gap — delivering enterprise-grade intelligence at small-business price points. See how this applies to remote and distributed workforces that depend on consistent connectivity everywhere.

Getting Started with AI-Driven Networking

The best part of Cisco Meraki's approach to AI is that there's nothing to configure. The intelligence is built into the platform from day one — every device you deploy immediately begins contributing to and benefiting from the AI models running in the cloud. There are no separate AI modules to license, no data science teams to hire, and no complex integrations to manage.

You deploy a Meraki device. It connects to the dashboard. The AI goes to work.

Whether you're managing a single office or 500 locations, the Meraki platform scales the intelligence with you. Start with a single wireless access point or build out a complete network with MX security appliances, MS switches, and cellular gateways — the AI layer becomes more powerful the more of your network it can see.

The reactive IT era is ending. The self-managing network is here. The only question is how long your business will wait before making the shift.

Browse All Meraki Products

Originally published at meraki.deal