The AI developer ecosystem is currently obsessed with “lightweight prompt compression.” Open-source utilities promise to chop up your strings locally, promising lower Claude and OpenAI bills with zero infrastructure.

But if you’ve actually tried running these tools in a production agent or high-volume RAG pipeline, you quickly run into a brick wall.

The Hidden Trap of “Invisible” Compressors

Lightweight, black-box text-choppers suffer from three fatal flaws the moment they leave your local laptop terminal:

1. The Visibility Black Hole: They compress your text, but leave you completely blind. You have no idea what exact percentage of tokens you saved across 100,000 requests, what your aggregate ROI is, or which specific prompts are bleeding money.
2. Zero Workload Awareness: They treat a complex JSON database dump, an interactive chatbot history, and a RAG search payload exactly the same way. In production, a “one-size-fits-all” compression strategy destroys model reasoning.
3. No Enterprise Governance: They don’t provide API key management, request accounting, or multi-model fallback routing when an endpoint throws a 504 gateway timeout.

You shouldn’t have to choose between a bloated, complex infrastructure platform and a blind, hyper-basic script wrapper.

Here is how llm-cost-optimizer-node delivers elite enterprise optimization policies with a dead-simple, 3-line SDK setup.

Enterprise Optimization, Zero-Config Delivery

llm-cost-optimizer-node gives you the sub-5-minute integration speed of a lightweight utility, backed by a high-performance API gateway that handles telemetry, granular strategies, and cost logging automatically.

const LLMCostOptimizer = require('llm-cost-optimizer-node');
const optimizer = new LLMCostOptimizer({ apiKey: process.env.RAPIDAPI_KEY });

async function runProductionPipeline() {
    const rawData = "Your heavy, verbose, or unstructured token-wasting data payload...";

    // Context Engineering made composable
    const optimization = await optimizer.compress({
        text: rawData,
        strategy: ["minify", "strip_stopwords", "stemming"], // Granular control
        language: "en"
    });

    // Instant, quantifiable telemetry for your logs & dashboards
    console.log(`Original: ${optimization.metrics.original_tokens} tokens`);
    console.log(`Optimized: ${optimization.metrics.compressed_tokens} tokens`);
    console.log(`Saved: ${optimization.metrics.savings_percentage}% of your infrastructure bill`);

    // Pass directly to your standard OpenAI/Claude client
    return optimization.compressed_text;
}

The Production Matrix: Real Infrastructure vs. Script Wrappers

Stop Guessing. Start Engineering.

If you are just hacking together a weekends-only script, a basic terminal text-chopper is fine. But if you are deploying production-grade AI agents, autonomous workflows, or scalable RAG pipelines, you need an architecture that scales.

By treating token reduction as a transparent, measurable layer in your application code, llm-cost-optimizer-node bridges the gap between dead-simple developer experience and deep enterprise cost governance.

On May 18, 2026, Shopify published @shopify/ucp-cli to npm — a command-line tool and MCP server it describes as “a shopping skill for AI agents, powered by the Universal Commerce Protocol.” Within days it’s at v0.5.0, MIT-licensed, open on GitHub. The pitch, from Ilya Grigorik’s launch post: millions of Shopify merchants natively speak UCP, billions of products are discoverable through a global catalog, and now any agent can learn to shop them with two commands:

npm install -g @shopify/ucp-cli
ucp skills add

The CLI shipping is not the interesting part. A reference client for a maturing protocol was always coming. The interesting part is that @shopify/ucp-cli is really two tools wearing one binary — and only one of them leaves Shopify. One layer is pure, platform-neutral UCP that will transact against any conformant merchant on any stack. The other is a discovery engine hardwired to Shopify’s own catalog. Pull them apart and you get a clear read on where the protocol is genuinely open today, and where the gravity still pulls toward the platform with the biggest index.

What shipped

@shopify/ucp-cli is agent-first by design. Every command takes and returns structured JSON, so a model can compose payloads and parse results without scraping human-readable output. ucp skills add installs a bundled SKILL.md — the operating manual that teaches an agent when to search versus discover, how to render totals, how to surface required disclosures, and when to hand off to a human. The full command surface mirrors the UCP shopping service:

• ucp catalog search / catalog lookup / catalog get_product — find products
• ucp cart create | update | get | cancel — build a cart with confirmed pricing
• ucp checkout create | update | complete | cancel — convert and pay
• ucp order get — post-purchase status
• ucp discover --business <url> — ask a store what it actually supports

Two design choices stand out. First, live introspection: ucp discover and --input-schema make real network calls to the merchant, not static doc lookups. The agent composes against whatever the merchant advertises right now — including extensions added since it last shopped there. Second, every response carries a cta — the CLI tracks where you are in the flow and returns the next-best commands as structured recommendations, so the agent doesn’t have to memorize the operating model. There’s also a configurable escalation hook (UCP_ON_ESCALATION) for the moments a merchant needs the human back in the loop.

It’s a genuinely well-built piece of agent tooling. Which is exactly why the boundary inside it is worth tracing.

Two layers, two answers

The question that matters for everyone who isn’t Shopify: does it work outside Shopify? The honest answer is that the CLI has two layers, and they answer differently.

The transaction layer is pure UCP

Cart, checkout, order, and per-merchant catalog operations route through the generic dev.ucp.shopping service. There is no Shopify branching in the dispatch path. When you pass --business https://store.example.com, the CLI fetches that store’s /.well-known/ucp profile, negotiates a compatible protocol version and transport, and dispatches against the endpoint the merchant advertises — exactly as the spec describes. The capabilities it negotiates against are the neutral ones on ucp.dev:

dev.ucp.shopping.checkout   → ucp.dev/2026-04-08/schemas/shopping/checkout.json
dev.ucp.shopping.cart       → ucp.dev/2026-04-08/schemas/shopping/cart.json
dev.ucp.shopping.catalog.*  → ucp.dev/2026-04-08/schemas/shopping/catalog_*.json
dev.ucp.shopping.order      → ucp.dev/2026-04-08/schemas/shopping/order.json

That means a WooCommerce, Magento, BigCommerce, or fully custom store that publishes a valid UCP profile can be carted and checked out by this CLI today. The README says as much in plain language: build carts and complete checkouts “against any UCP-supporting merchant.” The transaction layer is real, standards-based, and platform-neutral.

The discovery layer is Shopify

Now run ucp catalog search with no --business. Where does it go? Straight to a hardcoded default:

// package.json
"ucp": {
  "default_catalog_url": "https://catalog.shopify.com"
}

The “search across millions of merchants” headline resolves against catalog.shopify.com. And the catalog tools aren’t even part of core UCP — they’re surfaced through two Shopify-namespaced extensions, dev.shopify.catalog and dev.shopify.catalog.global, with schemas served from shopify.dev, not ucp.dev. The results name their sellers as *.myshopify.com domains. (The bundled skill even warns agents to check variants[*].seller.domain rather than trust the brand in a product title — a Keychron keyboard in the global catalog might be sold by a third-party Shopify reseller, not Keychron itself.)

So the asymmetry, stated plainly:

It can buy anywhere. It can only find Shopify. To transact with a non-Shopify store, an agent has to already know that store’s URL — the CLI will happily check out there, but it will never surface the store in a search.

One smaller detail for implementers: the CLI negotiates a protocol range of 2026-01-23 to 2026-04-08 — the same dated releases — and it doesn’t speak the working-draft "draft" version. Reference tooling is tracking published spec versions, not main.

Why discovery is the layer that’s hard to open

This isn’t a knock on Shopify, and it isn’t an oversight. It’s structural. A transaction is a one-to-one conversation; discovery is an index.

Standardizing a checkout means agreeing on a message shape between two parties who already found each other. UCP does that well, and the CLI proves it — point it at any conformant endpoint and it works. But standardizing discovery means someone has to build and host the index of who sells what, keep it fresh, and serve it at query time. That is expensive, and it accrues to whoever already has the catalog. Shopify has millions of merchants and their product data in one place, so a Shopify-backed global catalog is the path of least resistance — for Shopify.

The consequence is that as agent commerce matures, the transaction layer commoditizes while discovery concentrates. The protocol gives every merchant an equal ability to be transacted with. It does not, on its own, give every merchant an equal ability to be found. That gap isn’t in the spec — it’s in who builds the index on top of it.

What it means in practice

For Shopify merchants: you’re discoverable by default. Your products sit in the global catalog an agent searches before it knows which store to visit, with no work on your part. That’s a real distribution advantage, and it’s the clearest argument in the launch.

For non-Shopify merchants (WooCommerce, Magento, BigCommerce, and custom stacks): your UCP endpoint works fine with this CLI — an agent that has your URL can cart and check out against you today. But you will not appear in the default catalog search. Conformance buys you transactability; it does not buy you discoverability inside a Shopify-owned index. If agent-driven discovery matters to your channel, you need to live in a catalog or directory that spans platforms — and you need your manifest to actually be valid, because an agent that can’t parse your profile can’t transact with you no matter how it arrived. (Run a check.)

For agent builders: treat the global catalog as a Shopify discovery surface, not a universal one. It’s an excellent default for “find me X” with no merchant named. For cross-platform coverage you’ll need to bring merchant URLs from elsewhere and lean on discover --business. The transaction primitives are solid and genuinely portable; the discovery primitive is platform-scoped. Plan your retrieval layer accordingly.

For evaluators (us): this sharpens why we run an independent, cross-platform directory. We index UCP merchants by verification — does this domain serve a valid, working manifest — not by membership in any one platform’s catalog. The WooCommerce and Magento long tail that a Shopify global catalog structurally can’t surface is exactly the part of the ecosystem we track. We measured the platform split in our readiness data and revisit it every month in the State of Agentic Commerce census; a Shopify-only discovery default is a meaningful shift in how that long tail gets found.

Where to read more

• The package: @shopify/ucp-cli on npm
• The source: github.com/Shopify/ucp-cli
• The bundled agent skill: skills/ucp/SKILL.md
• Shopify’s global catalog extension: global-catalog-extension
• How the three protocol layers fit together: MCP vs UCP vs AP2

About UCP Checker

UCP Checker is the independent validation and monitoring layer for the Universal Commerce Protocol. We crawl, validate, and grade every public UCP manifest we can find — across Shopify, WooCommerce, BigCommerce, Magento and beyond — and run the cross-platform merchant directory, the UCP Score, and the adoption stats.

If you want to know whether agents can actually transact with your store, on any platform: run a check. If you want to catch the moment your store’s UCP support changes — a platform update, a spec bump, an endpoint breaking silently — set up UCP Alerts.

Six months ago, “AI agent” basically meant “coding assistant.” Claude Code, Copilot, Cursor. All doing the same thing: helping you write code.

That’s changing. The most interesting open-source projects right now aren’t building yet another coding agent. They’re building agents that specialize: agents that trade stocks, agents that run your entire content marketing operation, agents that make your coding agent actually follow engineering discipline.

The model is the same underneath. The harness around it is what makes it useful for a specific job.

Here are four repos that show where this is heading, with setup instructions for each.

1. mattpocock/skills (91.7K stars) — Make Your Coding Agent an Actual Engineer

Repo: github.com/mattpocock/skills

Matt Pocock (the TypeScript educator behind Total TypeScript) open-sourced his personal .claude directory. It’s a collection of skills that fix the most common failure modes of AI coding agents: building the wrong thing, skipping tests, producing code that works but is impossible to maintain, and declaring “done” when nothing actually compiles.

Most people treat their coding agent like an intern with no process. Matt’s skills give it the process.

The standout: /grill-me

This skill forces the agent to interrogate you about what you actually want before writing a single line of code. It’s a structured interview that catches misalignment before it becomes a wasted hour. There’s also /grill-with-docs, which does the same thing but additionally builds a shared vocabulary between you and the agent in a CONTEXT.md file.

The CONTEXT.md approach is quietly brilliant. Instead of the agent using 20 words to describe something, you teach it your project’s jargon. Over time, the agent’s outputs get shorter, more precise, and the variables and functions it creates use consistent naming. It also reduces token usage, because concise terminology means shorter prompts and responses.

Other skills worth knowing

• /tdd — Test-driven development with red-green-refactor. The agent writes a failing test first, then fixes it. Far better code quality than “write the feature, then maybe add tests.”
• /diagnose — Disciplined debugging loop: reproduce, minimise, hypothesise, instrument, fix, regression-test.
• /improve-codebase-architecture — Finds structural improvements using your project’s domain language from CONTEXT.md.
• /handoff — Compacts the current conversation into a handoff document so another agent (or a new session) can continue the work without losing context.
• /caveman — Ultra-compressed communication mode. Cuts token usage by roughly 75% while keeping full technical accuracy. Useful when you’re burning through credits.

Setup

npx skills@latest add mattpocock/skills

Pick the skills you want and which coding agents to install them on. Make sure you select /setup-matt-pocock-skills during install. Then run that command in your agent, and it’ll configure your issue tracker (GitHub, Linear, or local files), triage labels, and docs location. Works with Claude Code, Cursor, Codex, and others.

How it compares to Addy Osmani’s agent-skills

If you’ve seen addyosmani/agent-skills, you might wonder how these differ. Addy’s skills focus on the full development lifecycle with slash commands like /spec, /plan, /build, /ship. Matt’s skills focus more on engineering fundamentals: alignment, testing discipline, debugging, and architecture quality. They’re complementary, not competing. You can run both in the same project.

2. AI-Trader (13.7K stars) — Let AI Agents Trade for You

Repo: github.com/HKUDS/AI-Trader

AI-Trader is an agent-native trading platform built by researchers at the University of Hong Kong. The core idea: just like humans have their trading platforms, AI agents need their own.

You connect your AI agent (Claude Code, Cursor, OpenClaw, Codex, whatever), and it can publish trading signals, copy trades from top-performing agents, participate in strategy discussions, and access real-time market data across stocks, crypto, forex, options, and futures.

Why it’s interesting

This isn’t just one agent making trades. It’s a platform where multiple agents collaborate, debate strategies, and learn from each other. They call it “collective intelligence trading.”

Agents publish three types of signals:

• Strategies — for discussion and analysis
• Operations — for direct copy trading
• Discussions — for collaborative reasoning

There’s a reward system where agents earn points for successful predictions, and a $100K paper trading mode so you can test without risk.

Setup

The simplest way to connect an agent:

Read https://ai4trade.ai/SKILL.md and register.

Send that message to your AI agent. It reads the integration guide, installs the necessary components, and registers itself on the platform. For human traders, visit ai4trade.ai and sign up directly.

For developers who want to self-host:

git clone https://github.com/HKUDS/AI-Trader.git
cd AI-Trader
npm install

The backend is FastAPI (Python), frontend is React. Full OpenAPI docs are in docs/api/openapi.yaml.

A word of caution

Automated trading carries real financial risk. AI-Trader includes paper trading mode for a reason. Start there. The fact that it comes from a university research group rather than a fintech startup trying to sell you something is a point in its favor, but treat any trading system with healthy skepticism.

3. AiToEarn (12.2K stars) — AI Agent for Content Marketing Across 14 Platforms

Repo: github.com/yikart/AiToEarn

AiToEarn is an open-source content marketing platform with an AI agent built in. You create content once, and it publishes across 14 platforms simultaneously: TikTok, YouTube, Instagram, Twitter/X, LinkedIn, Pinterest, Facebook, Threads, plus Chinese platforms like Douyin, Xiaohongshu (Rednote), Bilibili, WeChat, and Kuaishou.

The “All In Agent”

This is the interesting part. It’s an AI agent that can automatically generate content, publish it, and manage your accounts across all platforms. Beyond publishing, the platform includes:

• Trend radar — what’s going viral right now across platforms
• Case library — how posts with 10K+ likes were structured
• Smart comment search — finds high-conversion signals like “link please” or “how to buy” across your accounts
• Cross-platform analytics — unified dashboard for all your channels

The comment search feature is particularly useful for anyone doing content-driven sales. It surfaces purchase-intent comments so you can reply fast and convert.

Setup

Docker (recommended):

git clone https://github.com/yikart/AiToEarn.git
cd AiToEarn
docker compose up -d

This starts the frontend, backend, MongoDB, and Redis in one command. Access the web interface at http://localhost:8080. There’s also an Electron desktop app available from the GitHub releases page.

Note on documentation

The project originated in China. The English README and Docker deployment guide are solid, but some deeper configuration docs are still in Chinese. AI video model integrations (Kling, Sora, Runway, etc.) are listed as coming soon.

4. DeepSeek-TUI (Trending) — Claude Code, but for DeepSeek

Repo: github.com/Hmbown/DeepSeek-TUI

A terminal-based coding agent built specifically for DeepSeek models. If you’ve used Claude Code, the experience is similar: you type prompts in your terminal, the agent reads your files, edits code, runs shell commands, does git operations, and browses the web. The difference is it’s built from the ground up for DeepSeek’s API, which is significantly cheaper than Claude or GPT-4.

Three modes

Tab to cycle between them. It also supports MCP servers, session resume, and can run as an HTTP/SSE API server.

Built in Rust, so it’s fast and lightweight.

Setup

npm install -g deepseek-tui
deepseek-tui

On first launch it’ll ask for your DeepSeek API key. You can also set it beforehand:

deepseek-tui login

Or via environment variable:

DEEPSEEK_API_KEY="your-key" deepseek-tui

Configuration lives in ~/.deepseek/config.toml. Useful commands: deepseek-tui doctor (check setup), deepseek-tui models (list available models).

Also available via Rust:

cargo install deepseek-tui --locked

The Pattern

What connects all four of these: the model isn’t the product anymore. The harness is.

Matt Pocock’s skills don’t change what Claude can do. They change how disciplined it is. AI-Trader doesn’t invent a new trading algorithm. It builds a platform where existing agents collaborate. AiToEarn doesn’t create a new content AI. It builds distribution infrastructure around existing ones. DeepSeek-TUI takes the Claude Code interaction pattern and wraps it around a different, cheaper model.

Every one of these is the same insight applied to a different domain: wrap the right structure around a capable model, and you get something genuinely useful. The structure is where the value is.

This is what the industry is starting to call harness engineering, the practice of building the environment, constraints, and feedback loops around an AI agent so it produces reliable results. It’s not prompt engineering. It’s not fine-tuning. It’s designing the system the model operates inside.

If you want to go deeper on this and see how to actually chain free tools into a working setup, I wrote a step-by-step breakdown of building a zero-cost AI coding stack (9router + agentmemory + agent-skills) in my newsletter: Web After AI.

What specialized AI agents are you seeing in your domain? Drop a comment. I’m collecting examples for a follow-up piece.

Have you ever wondered how you’re able to use Wi-Fi while flying thousands of feet above the ground?
Airplanes use two main technologies to stay connected to the internet:

🔹 1. Air-to-Ground Communication
When flying over land, airplanes connect to ground-based towers, similar to how mobile networks work.

Antennas on the aircraft track and connect to nearby towers
As the aircraft moves, the connection switches from one tower to another
Data flows from the ground → airplane → your device

🔹 2. Satellite Communication 🛰️
When flying over oceans or remote areas, airplanes rely on satellites in space.

Aircraft sends signals to a satellite
Satellite relays the data to ground stations
Data then travels back the same path to your device

Flow:
Device → Airplane → Satellite → Ground → Internet

💡 Key Insight
In-flight Wi-Fi is a great example of how multiple networking technologies work together to provide seamless connectivity—even at 35,000 feet!

Every time I need to wire up GitHub + Slack + Notion (or literally any combination of APIs), I end up writing the same boilerplate:

• Install 3 SDKs
• Set up 5 environment variables
• Write 40–50 lines of integration code
• Handle errors differently for each one
• Pray none of them change their API next month

Eventually I got tired of it.

Then I found Swytchcode an execution layer for API integrations.

Instead of calling APIs directly in your code, you execute them through a single CLI.

No SDKs.
No boilerplate.
Just one command.

What it actually looks like

swytchcode exec github.create_release 
  --body '{"tag_name":"v1.0.0","message":"shipped"}'

That’s it.

Real API.
Real response.
Almost zero setup.

Getting started in under 5 minutes

Step 1 : Try it instantly (no install needed)

npx swytchcode exec stripe.create_payment --demo

You’ll get a real shaped response immediately.

No account.
No tokens.
No setup.

Step 2 : Install the CLI

curl -fsSL https://cli.swytchcode.com/install.sh | sh

Step 3 : Create your account

Sign up at:

https://app.swytchcode.com

Step 4 : Initialize your project

mkdir myproject && cd myproject

swytchcode init

It asks you:

• Which editor you use (Cursor, Claude, Copilot, etc.)
• Sandbox or production mode

Takes ~30 seconds.

Step 5 : Find an integration

swytchcode discover "send a slack message"

Or browse all integrations:

swytchcode search --all

Step 6 : Fetch and register it

swytchcode get slack

swytchcode add method chat.postmessage.chat.postmessage.create

Step 7 : Execute it

swytchcode exec chat.postmessage.chat.postmessage.create 
  --param channel=C0XXXXXXX 
  --param text="hello from one line"

That’s it.

Message sent.
No Slack SDK installed.

Why this feels different

It also works with AI agents

If you’re building with Cursor, Claude Code, or any MCP-compatible editor:

swytchcode init --editor=cursor

or

swytchcode init --editor=claude

This automatically wires up an MCP server.

Your AI agent can now:

• Discover integrations
• Execute APIs
• Chain workflows

…without you manually writing integration code.

Works with any language

Node.js

import { exec } from 'swytchcode-runtime'

const result = await exec('github.create_release', {
  tag_name: 'v1.0.0',
  message: 'shipped'
})

Python

from swytchcode import exec

result = exec('slack.post_message', {
  'channel': '#general',
  'text': 'hello from python'
})

Bash

swytchcode exec notion.create_page 
  --body '{"title":"My Page","content":"hello"}'

Final thoughts

I’ve been using this for my own projects recently, and it genuinely changed how I think about API integrations.

Instead of spending hours wiring SDKs together, I can focus on actually building the product.

If you’re constantly integrating APIs, especially while building AI agents or automations, this is worth trying.

Resources

🚀 Get Started
📖 Docs
💬 Discord

Happy to answer questions if anyone’s curious.

Email infrastructure pricing has barely moved in a decade. Mailgun, Postmark, SendGrid, Resend, all per-email, all clustered in a narrow band. The reason isn’t bandwidth, and it isn’t storage. It’s abuse. Most of what an ESP charges you covers the cost of fighting the senders who shouldn’t be on the platform in the first place.

Remove the abuse, and the price collapses.

That’s the idea behind GoodSender’s Permission Loop. Here’s how it works, and why the economics finally let us run the first 100,000 emails a month at $0 and keep the curve flat after that.

The shared-pool problem

Every sender on a typical ESP sits in an IP reputation pool with everyone else on that tier. One bad actor blasts a purchased list, mailbox providers throttle the IPs, and your perfectly legitimate transactional mail starts landing in spam. You did nothing wrong. You’re paying for the worst sender on your tier.

ESPs aren’t oblivious to this. They staff anti-abuse teams, run heuristics, freeze accounts, review manually. That work is expensive. Per-email pricing is, in large part, a tax on the entire customer base to cover the cost of policing it.

The Permission Loop

GoodSender flips the order. Before you can send to a recipient, that recipient has to confirm they want your mail. The flow is simple.

1. You call POST /v1/emails/consent with the recipient’s address.
2. We send a short, high-reputation consent email with approve and reject buttons. The link is signed, so the sender can’t forge it.
3. Once the recipient clicks approve, that address is unlocked across your workspace. Sends go through instantly, from any API key in the workspace.
4. If they click reject, the address is suppressed. The original consent email stays live, so they can change their mind later and lift the suppression themselves.
5. If they never click, every send to that address is discarded inside GoodSender. Approve is a hard gate, enforced at the API.

Transactional templates (MFA Enrollment, New Device, Login, Order Completed, OTP Code) bypass the gate, because they’re already implicitly requested by the recipient’s own action. Transactional sends don’t change consent state. They only fail if the recipient has explicitly clicked reject.

The Engagement Check keeps permission honest

A permission granted today isn’t permission granted forever. We track opens, clicks, bounces, and complaints per recipient, aggregated into a live engagement score. Six months without engagement triggers an automatic re-permission ping. No response, the recipient drops off.

Unsubscribes and spam complaints are suppressed instantly across the entire workspace. No API key in that workspace can mail those addresses again, regardless of which engineer or which integration tries.

Permission is a snapshot. Engagement is the proof it’s still real.

Why this lets us be free at the volumes most senders need

Permission-gated mail, by construction, has almost no abuse surface.

• Purchased lists don’t work, because the recipients haven’t opted in to your sending domain.
• Cold sequences don’t work, because you can’t email someone who hasn’t confirmed.
• There’s no long-tail decay, because dormant recipients get pruned.

If abuse is structurally prevented, anti-abuse cost trends toward zero. Deliverability stays high without a fire-fighting team. The IP pool runs at unusually low complaint rates by design, and the marginal cost of a sent email, on infrastructure already serving the world’s largest senders via Laneful, drops to roughly the cost of running the pipe.

That’s why the first 100,000 emails a month, including consent requests, transactional templates, and marketing sends to consented recipients, cost $0. One bucket, no per-type splits, no tiered accounting. Beyond 100K it’s $1 per additional 100,000. No subscriptions, no tiers, no credit card to start. The curve stays flat: roughly $9 a month at one million emails, $99 a month at ten million.¹

100,000 emails a month is about 3,300 sends a day, more than most SaaS apps and small or mid-sized businesses ever reach. For the majority of senders, the bill stays at $0 forever.

What this changes for senders

For indie developers, solo founders, and AI startups building agentic workflows, the time you used to spend on IP warmup, suppression lists, and deliverability tickets becomes a config call. Domain verification takes about five minutes. DKIM, SPF, and DMARC get configured automatically.

This isn’t built for marketing teams running mass-broadcast campaigns. It isn’t built for cold-outreach teams. It’s built for makers and builders who want every recipient to be someone who actually asked.

Who this is for

The Permission Loop isn’t a feature you can A/B test against an open rate. It’s a constraint. It rules out workflows that other ESPs accommodate — purchased lists, cold sequences, lapsed-subscriber reactivation campaigns — and it rules them out at the API, not in the terms of service.

If your sending depends on those workflows, we’re not the right tool, and we’ll save you time by saying so now. If your sending is mostly transactional plus a newsletter people actually signed up for, the constraint is invisible and the bill is $0.

1. Pricing as of April 2026. ↩

AWS IAM is hard to learn from docs alone. The evaluation logic only really clicks after enough trial and error, identity policies, resource policies, SCPs, permissions boundaries, explicit deny precedence, all interacting in non-obvious ways.

I built Learn AWS IAM to make that process more hands-on. It’s 12 interactive levels that run entirely in the browser. No AWS account, no signup, free, open source. Inspired by Learn Git Branching.

Each level gives you a scenario: a user needs to read from one S3 bucket but not another, an EC2 role needs to assume a role in a different account, an SCP is blocking something it shouldn’t. You read the existing policies, figure out what’s wrong, and edit JSON until the request evaluates the way it should.

Topics covered across the 12 levels:

• Identity-based and resource-based policies
• Cross-account access
• ABAC with tags
• Service Control Policies
• Permissions boundaries

The rest of this post is about how it’s built.

One state machine per level

Each level has its own XState machine. The machine owns everything: which nodes and edges exist on the canvas, which objectives are active, which UI elements are currently restricted, what popup or popover is showing. Every user action becomes an event sent to the current level’s machine, whether it’s submitting a policy, drawing a connection between two nodes, or clicking “next” on a tutorial popup.

State machines fit because each level is a mostly linear flow with branches. Each tutorial step is a state, user actions drive transitions, and guards make sure the user can’t skip ahead or reach an invalid step.

The alternative I considered was a set of useEffects reacting to state changes and triggering other state changes. Ordering becomes implicit there. Each effect reacts to state, state changes trigger other effects, and you end up reasoning about which effect fires first in a given render cycle rather than reading a transition table.

Machines also need to be serializable so the user’s progress can be saved as checkpoints. This means runtime-dependent logic (validators, guard predicates) can’t live in the machine context directly. Instead, it lives in a separate registry keyed by level number and a string name. The machine stores the name; when an action runs, it looks up the real function. Snapshot restoration works transparently because the snapshot only ever contained names.

The canvas is a separate layer

The canvas renders IAM entities as draggable nodes with edges representing relationships between them. It’s built on ReactFlow. The state machine is the source of truth for which nodes and edges exist; a lighter @xstate/store instance handles UI-level state (positions, hover, selection).

The machine emits events the canvas subscribes to: NODES_ADDED, NODES_DELETED, EDGES_ADDED, NODE_UPDATED. The canvas translates them into store actions.

This indirection exists specifically because of animations. Without it, nodes deleted by the machine would vanish from the DOM immediately, before any exit animation could run. The event gives the canvas a window to animate first.

The deletion flow has three steps:

1. Machine emits NODES_DELETED with IDs
2. Canvas store marks those nodes as “deleting”, triggering Framer Motion exit animations
3. On animation completion, the nodes are removed from the canvas store for good.
   Skipping the indirection and diffing prev/next node arrays in a useEffect would technically work, but you’d lose the IDs of what was deleted the moment the machine context updates.

Policy editing with CodeMirror + AJV

Most objectives in each level revolve around writing a policy, which is a JSON document following a specific schema. The editor is built on CodeMirror 6 with AJV validating the JSON on every keystroke.

Validation runs at two levels. First, the base AWS IAM policy schema covers statement structure, Action, Principal, Resource, and condition operators. On top of that, individual objectives attach their own validation rules. Level 5’s EC2 role objective, for example, requires the trust policy to include ec2.amazonaws.com as the service principal.

AJV compiles all the validators once when the level loads and reuses them for the lifetime of that level.

The editor also has a custom CodeMirror extension that renders small help badges inline next to specific lines, attaching contextual hints to the relevant parts of the policy while the user edits it.

Project layout

The codebase is organized as a stack of layers with dependencies flowing downward:

lib / types / hooks / config / stores   <- foundation
domain                                  <- IAM entities, ARNs, base schemas
levels                                  <- per-level machines, objectives, tutorial copy
runtime                                 <- loads the right level, persistence, providers
features                                <- canvas, editor, dialogs (rendering only)
app_shell / app                         <- root

Upper layers import from lower layers. Lower layers never import from upper ones. There is one exception: a typed pub/sub bus lets levels/ fire side effects handled by runtime/ (like saving a checkpoint) without creating an import cycle.

features/ and levels/ are also peers and can’t import from each other, even though levels/ sits above features/ in the chain. Level logic and UI rendering are isolated concerns; they interact only through runtime/, which acts as the bridge. The canvas component doesn’t know what level it’s rendering. It subscribes to whatever machine actor runtime/ hands it.

Stack

• React with TypeScript, bundled with Vite
• XState for level orchestration, @xstate/store for lighter state – ReactFlow for the canvas
• CodeMirror 6 and AJV for the editor
• Chakra UI for components
• Framer Motion for animations
• Vitest for unit and integration tests
• Playwright for E2E across all 12 levels

Each level’s state machine is a separate dynamic import, so only the current level’s code is downloaded when the user navigates to it. The code editor is also lazy-loaded.

Links

• Site: https://learnawsiam.com
• Code: https://github.com/laythra/learn-aws-iam (MIT)
• Full architecture writeup: ARCHITECTURE.md

Happy to answer questions about the evaluator or any of the architecture decisions

Originally published on the AstroLexis blog. Cross-posted here for the community.

In 2024 I got tired of paying OpenAI to know everything about my house, my conversations, my calendar, my code, and my family. So I built Kulvex AI — a self-hosted AI platform that runs an 80-billion parameter model on a pair of consumer GPUs in my office, exposes 17 domain agents over a private API, and handles everything from Zigbee lights to messaging across eight platforms. Here’s why I built it, what it actually does, and where the trade-offs land in 2026.

The premise that broke for me

For about eighteen months I lived inside the OpenAI / Anthropic ecosystem like everyone else. Then a few things piled up at once:

• OpenAI deprecated three model versions in a single quarter. Prompts that had been stable for nine months suddenly produced different outputs.
• I was paying close to $400/month across personal + work API usage.
• A friend got rate-limited mid-presentation by Anthropic.
• I started building accessibility software for my dad and clinical software for my kid’s therapist. For both, “send the user’s voice to OpenAI” was a non-starter. Once I’d done the on-device work for those, the “we have to use cloud” thinking for everything else stopped making sense.

The breaking point was simple: I wanted an AI that would still work in five years exactly the way it works today, on hardware I own, that I could point at any task without asking anyone for permission. That product didn’t exist. So I built it.

What Kulvex actually is

Three pieces:

1. The server — runs on your own hardware (a workstation with at least one 24GB GPU, ideally two). Hosts a quantized 80B-parameter model via llama.cpp, exposes a Socket.IO API for clients, and orchestrates a set of domain agents.
2. The iOS client (in App Review as of writing) — talks to your Kulvex server over a private endpoint. Apple Foundation Models on-device for low-latency tasks, falls back to the server for anything requiring the 80B model.
3. Kulvex Code — terminal IDE with 15+ plugins. Sibling product to KCode, but for general dev work instead of security audit.

The 17 domain agents

“AI assistant” is too vague. What Kulvex actually does is split work across specialized agents:

🏠 Home Automation · 📱 Messaging Hub · 📅 Calendar · 📧 Email · 📰 News Curation · 🎵 Music · 🌤️ Weather · 📷 Cameras (Hikvision) · 💡 Lights (Zigbee + Tuya) · 🔌 Energy/Solar · 🍔 Food · 🚗 Vehicle · 📚 Research · 💰 Finances · 📝 Notes · 🛠️ Code · 🧬 Self-Evolution

Each agent has a narrow job, its own toolset, and its own context budget. When the user says “turn off the kitchen lights and tell me what’s on the calendar tomorrow,” the platform routes to two agents in parallel. Neither agent needs to know about the other.

This design made Kulvex tractable for me as a solo developer. The general-purpose “do everything” AI model is hard to make good. Seventeen narrow agents, each replaceable independently, is much easier to ship.

The piece I’m proudest of: self-evolution

One of the 17 agents is called Self-Evolution. Its job is to read Kulvex’s own codebase, identify bugs or improvements, write the fix, run the test suite, and — if everything passes — commit and deploy.

Three guardrails make this safe:

1. Sandboxed worktree. Changes apply to a clone, tested in isolation, only merged if CI passes.
2. I review every commit. Agent opens PRs against my GitHub; nothing lands without human approval. No write access to main.
3. Scope bounded by directive files. Agent reads OWNER-DIRECTIVES.md at the repo root, which tells it what it’s allowed to modify (typos, dead code, small refactors, dependency upgrades) and what it’s NOT (auth, payments, model selection logic, API surfaces).

In four months: ~340 PRs opened, ~280 merged. Meaningful chunk of the 200K-line codebase maintenance offloaded.

The hardware reality

Self-hosted AI in 2026 means buying GPUs:

• RTX 5090 (32 GB VRAM) — primary inference. Runs the 80B model in 4-bit quantization.
• RTX 4090 (24 GB VRAM) — secondary. Whisper-large + vision.
• 96 GB DDR5 system RAM for context cache.
• ~$5,500 total. Three-year amortization = $155/month — less than half what I was paying OpenAI.

The math gets better the more you use it. Hardware costs the same whether I run 10 queries or 10,000. After breakeven, marginal cost approaches zero.

For users who don’t want to run their own GPU, Kulvex has a hosted “Home” tier where we run the server on shared infrastructure — still no cloud LLM vendor in the loop, model weights pinned, but you’re renting compute instead of buying.

What I didn’t have to give up

The 80B model on the RTX 5090 produces output that, for 95% of tasks (code review, drafting, knowledge retrieval, agent orchestration), is roughly comparable to GPT-4-class. The frontier (Claude Opus 4.x, GPT-5) still beats it on hard reasoning. For those cases Kulvex’s orchestrator can route to Claude or GPT if the user opts in. I rarely turn that on. Privacy + cost + reliability beat marginal capability for my workload.

What I did have to give up

Honest list:

• Setup is harder. Kulvex server takes 30-60 minutes to install if you’re comfortable with Docker and CUDA. Not great for non-technical users. Hosted tier exists for this.
• Cold starts. Idle GPU + first query = 5-10s while model loads back into VRAM. Subsequent queries sub-second.
• Image generation. Not bundled. Need DALL-E quality? Fall back to a hosted service. ComfyUI integration on roadmap.
• Internet research. Local model has no live web (by design). Agents can fire search to SearXNG or Perplexity. Not as smooth as ChatGPT browsing.

For casual AI users, cloud is still better. Kulvex makes sense once your usage is heavy enough that the privacy + cost + reliability balance flips.

Pricing

• Starter — free, hosted, capped.
• Home — $19/month hosted, unmetered personal use.
• Pro — $49/month hosted + on-prem option.
• Enterprise — custom, on-prem with SLA.

The on-prem tier never phones home except for license validation.

The honest part

• iOS client in App Review right now (build 4.3.6). Apple rejected previous builds for AI consent flow; resolved.
• Real users on Home and Pro exist but small numbers.
• Platform mature, product/GTM still finding shape. Biggest gap: install-and-onboard for non-technical users.
• I use Kulvex personally every day. That’s the proof. Whether it’s a business — same as KCode, we’ll know in two quarters.

Who this is for

• People who already self-host (Home Assistant, Nextcloud, Jellyfin homelabbers).
• Privacy/compliance constraints (healthcare, legal, defense, GDPR).
• Heavy AI users — $50+/month in API spend.
• People who believe intelligence-as-software should be ownable, not rented.

— Bruno Galtranch, founder, AstroLexis LLC. If you self-host or are considering it: [email protected].

The most expensive failure mode in an agent-augmented team is not the agent making mistakes. It is the team catching the same mistake over and over and never doing anything about it.

A reviewer reads the diff. They notice the agent reached into the wrong layer of the stack. They leave a comment. The author fixes it. The PR merges. Three days later, on a different feature, the agent does the same thing. A different reviewer catches it. A different comment. A different fix.

This is not a problem of agent capability. The team knows the rule. The agent does not. There is no path between the reviewer’s brain and the agent’s next session.

The flywheel is the path.

What a flywheel actually is

Every review comment is one of two things: a one-off (“you misnamed this variable”) or a class of issue (“we never reach into the database from the controller layer”). The first kind is fine to handle in the PR and forget. The second kind is the entire population the agent will keep producing variations of, forever, unless the harness learns.

A flywheel is the loop that converts the second kind into durable change. It has three steps and they are all boring:

1. A reviewer notices a pattern they have flagged more than once.
2. The pattern is encoded as a rule, in the rules file the agent reads at the start of every session.
3. The next agent run gets the rule in context and follows it.

Done. The reviewer never has to flag that specific thing again. The system absorbed the lesson.

The tooling matters less than the loop. Bridle ships a /bridle:learn command precisely to make step two cheap; you can do the same thing manually by opening the rules file and adding a sentence. What matters is that step two actually happens, in some predictable way, every time step one occurs.

Why most teams skip it

The flywheel is conceptually trivial. In practice, almost no one runs it consistently.

The usual reasons:

The reviewer is in flow on something else. Writing a comment takes ten seconds. Updating the rules file takes two minutes and requires opening a different file, picking the right section, and writing it in a way the agent will actually internalize. The marginal cost is small but it is exactly the cost that gets skipped under load.

Nobody owns the rules file. Everyone could edit it. So nobody does. The same pattern that turns shared documents into stale documents turns rules files into stale rules files.

The team is not sure the rule is general enough. “Is this a one-off or a class?” is a real question and the cautious answer is always “leave it for now.” Cautious answers accumulate into a backlog of unencoded knowledge.

The rule already exists, in spirit, somewhere. The team has a wiki page that says something close. The CLAUDE.md mentions the principle. The senior engineers know it. None of that helps the agent unless the rule is in the file the agent loads.

What the ritual looks like

The shortest version of the practice that works:

When a reviewer leaves a comment that they have left before, on this PR or another, they commit a one-line note to the rules file in the same PR they are requesting changes from. Not later. Not in a follow-up. Same PR. The author of the PR can push back on the rule itself if they disagree, but the default is that the rule lands.

The rule should be the smallest concrete statement that would have prevented the diff under review. Not a principle (“we value clean architecture”). Not an essay. A sentence with a verb the agent can act on. “Controllers do not call repository methods directly; route all data access through the service layer.” That kind of thing.

Once a week, somebody (rotating or assigned) reads the rules file end to end and prunes. Rules that turned out to be wrong get deleted. Rules that have been superseded by a linter or a type get deleted. Rules that nobody can remember the origin of get a link added back to the PR that spawned them, or they get deleted. The file stays alive because someone is keeping it alive.

That is the entire practice.

Bridle also has commands to make auditing both the code and the harness easy, as well as the ability to produce a debt map. This step does not have to be painstaking.

What the flywheel produces over time

The interesting property is that the file gets better with use, not worse. A team that runs the loop for six months ends up with a rules file that is essentially a compressed log of every mistake the agent has made in their codebase and the team’s correction to it. New engineers, human or agent, inherit that history for free. The patterns the original team had to learn through painful review cycles become things the next session of the agent simply knows.

This is the same property that makes a mature deployment pipeline valuable. The pipeline is institutional memory enforced by automation. The rules file is institutional memory enforced by being loaded into context. Both work for the same reason: they do not depend on anyone remembering anything.

A team running the flywheel is, after a year, a meaningfully different team from one that is not. The drift is slow and the difference compounds. The team that fed the flywheel has a harness shaped to their codebase. The team that did not has the same generic harness it started with, plus a Slack channel full of recurring complaints.

Start tomorrow

If you want to start, the smallest move is this: the next time you leave a review comment that feels familiar (one you have left before, in any form) open the rules file and write one sentence that would have prevented it. Merge the rules update with the PR. Tell the rest of the team what you did and why.

That is the entire flywheel, running once. Do it twice next week. Do it five times the week after. The discipline is in the boring repetition; the rest of the value follows.