Cloudflare recently opened the beta for Email Sending. @lumenize/auth has switched its default email transport to use it.

You've been writing the same types four times.

Once as a TypeScript interface. Once as a Zod schema for validation (or the other way around — Zod's z.infer can derive the type, but you're still writing Zod's DSL). Once as a Prisma model for your ORM. Once as SQL for your database. Multiple representations of the same thing, each in a different language.

Here's what that looks like for a simple Todo with an assignedTo relationship:

Cloudflare's Code Mode team made a striking discovery: when they converted JSON Schema to TypeScript for MCP tool definitions, LLMs performed dramatically better. The follow-up showed 32-81% token reduction with improved accuracy. And today, their Dynamic Workers platform doubles down — TypeScript interfaces are the way agents understand APIs. As they put it: "Agents know TypeScript... with very few tokens, you can give your agent a precise understanding of your API."

That got me thinking. If TypeScript is the best way to describe types — for both humans and LLMs — why are we still maintaining parallel schemas in Zod or JSON Schema to validate them? You already write TypeScript interfaces. What if those interfaces were the runtime validation schema?

Cloudflare Durable Objects with SQLite storage charge $1.00 per million rows written and $0.001 per million rows read. Writes are 1,000x more expensive than reads. The docs tell you that "every row update of an index counts as an additional row written" — but that's where the guidance ends.

How much does a compound index cost? Does WITHOUT ROWID actually save money? If I update a column that isn't indexed, do I still pay for the indexes? Does UNIQUE have an impact? Questions like these come up regularly on the #durable-objects Discord, and I've never seen an experimentally-validated publication that answers them. So I wrote 36 tests and measured everything.

If you're building on Cloudflare Workers and Durable Objects, you've probably wired up auth at least once — JWT validation, token refresh, key rotation, permission checking. It's not glamorous work, and bolting on an external auth service (Auth0, Clerk, Supabase Auth) means another dependency, another bill, another point of failure, and latency from round-trips to someone else's infrastructure.

@lumenize/auth is a different approach: passwordless authentication that runs entirely inside your Cloudflare Worker. No external service. No SDK. Just a Durable Object that handles magic-link login, JWT signing, refresh token rotation, and access control — all at the edge.

Lumenize Nebula is an agentic software engineering platform built on Lumenize Mesh. Define your business ontology declaratively. Nebula handles the rest.

Alongside the Lumenize Mesh beta announcement, we're making several package changes. Here's what moved, what's new, and what to update.

Today we're releasing Lumenize Mesh in beta — a de✨light✨fully radical new way to build on Cloudflare Workers and Durable Objects, where DOs, Workers, and browser clients are all equal peers in one mesh.

I was today years old when I learned how WebSockets and CORS really work. And: how CORS can be implemented in a non‑standard (but arguably better) way.

One of the "Larry-isms" that my family and coworkers are tired of hearing is, "You can't be better unless you are different." It's not an endorsement for being different just to be different but rather, to look for opportunities to deviate from the norm when you think you have found a better way to do something. I always follow it with a statement that just because you think you have a better way doesn't mean that you actually do — and that may very well be the case with what I did today.

I implemented a non-standard way of handling Cross-Origin Resource Sharing (CORS) in Lumenize. You be the judge of whether or not it's better.

Remember that childhood game called "broken telephone" where we lined up in a circle with our friends. Then, one person would whisper something into their neighbor's ear, and they would in turn whisper it into the next friend's ear until you completed the circle? If you were lucky, you might land beside the person you secretly liked—the tiny thrill of whispering anything into their ear. The lesson was that every translation from brain to words and back again was just a little bit lossy. Cumulatively, what came out the other end was nothing like the original message.

Software systems, and APIs in particular, are no different. Every layer of translation risks just a little bit of loss in fidelity. This is nowhere more true than in the realm of types, schemas, validation, and code generation — the same patch of cognitive quicksand occupied by TypeScript, JSON Schema, Ajv, Zod, and friends.

MCP is all about context portability: moving structured data democratically across agents, runtimes, and languages. The type/schema has to remain the same throughout the journey around the circle of friends. Tooling decisions have very real consequences for portability and correctness. So imagine my surprise when I discovered the Babel of type/schema translations running in MCP stacks today.

Somewhere between recess and real life, we all learned the difference between a childhood crush and a partner you can build with. Flash is fun on the playground; fidelity gets you into adulthood. With Lumenize, I wasn’t looking for puppy love. I was looking for a commitment that would survive different runtimes, languages, and teams.