DEV Community: Thomas Hansen

My MCP server technically has 10 to the power of 1204 number of integrations! Try it for free here!

Thomas Hansen — Mon, 21 Sep 2026 09:17:25 +0000

Part of our MCP series — the overview lives at MCP Server, and the endpoint below is the one built in Let Strangers Run Code on Your Server.

Here is a number I can defend. A caller sends my endpoint at most 500 characters. Count the distinct inputs at one byte per character and you get 256 to the power of 500 - which is two to the power of four thousand, which is very close to ten to the power of 1204. That is a number with 1,205 digits. Writing it out at one digit a second takes twenty minutes. For scale: the observable universe holds perhaps 10^80 elementary particles, so 10^1204 is around 1,124 orders of magnitude more "integrations" than there are particles in existence. It is not a big number. It is a stupid number.

Every one of those inputs is a different thing you can tell the endpoint to do. So, technically, my MCP server ships with 10^1204 integrations. You may quote me, and you may put the word technically in italics when you do.

The joke has a serious spine

The industry builds agent integrations one at a time. A tool definition per operation. A wrapper per API. An import per specification. Want your agent to touch a new system? Write another adapter, describe it, test it, keep it in sync forever. N things means N hand-built integrations and N things to maintain.

A capability-scoped endpoint collapses that N to one. You do not enumerate operations any more; you declare a vocabulary - a list of the functions a caller's code is allowed to reach - and the model composes whatever operation it needs out of that vocabulary, at the moment it needs it. Reading five rows, joining three tables, formatting the result as Markdown, filtering by a date it computed on the fly - those are not four integrations you built. They are four sentences a model wrote against one endpoint, and the runtime checked each function against your list before it ran.

The combinatorial explosion that gives me my ridiculous headline number is the same explosion that means you never write an integration again. You stop maintaining a catalogue of operations and start maintaining a short list of capabilities. The operations take care of themselves.

One integration to rule them all

I am not going to resist it.

One integration to rule them all, one integration to find them,
one integration to bring them all, and in the vocabulary bind them.

One tool. One URL. One whitelist. Every operation the agent could ever compose lives inside it - and cannot escape it, because a function that is not on the list does not exist as far as the caller's code is concerned. The power is total within the boundary and exactly zero outside it. That is the good kind of ring.

Try it, free, right now

I left one running, connected to nothing more dangerous than the Chinook sample database, and I made you a login.

MCP URL: https://hyperlambda.dev/magic/modules/mcp/mcp
Username: guest
Password: guestguestguestguest (the word guest, four times)

Point any MCP client at that URL - Claude Code, Codex, Qoder, OpenCode, or anything else that speaks the protocol. When it connects, the cloudlet answers unauthenticated requests with a 401 that hands the client its OAuth metadata, so your tool will walk you through a normal sign-in; use the guest credentials above. The guest role is the one anyone who signs in through OIDC gets automatically, so it is completely harmless - here it grants exactly one thing: read the Chinook database.

In Claude Code, for example, add it as a remote MCP server pointing at the URL and sign in when prompted. The other clients differ only in which menu the "add MCP server" button hides behind.

Ask it one thing first: "Return server vocabulary"

Before you ask it to do anything, ask it what it can do. Tell your agent:

Return server vocabulary

The endpoint answers with the exact list of functions it will dispatch for you - its whole capability surface, and nothing it will pretend to have. Feed that back into your session and your model is now grounded: its next instructions land inside the vocabulary instead of guessing at it. This is the antidote to that 10^1204 headline. The model does not go wandering an input space with more members than the universe has atoms - it reads the finite list first, once, and composes against it.

{
  "state": "executed",
  "result": [
    "add", "and", "convert", "eq", "for-each", "get-value",
    "if", "return-nodes", "strings.concat", "math.add",
    "data.read", "data.connect"
  ]
}

That list (abridged) is the whole of the caller's power. data.read is on it. No writing function is. Which brings us to the fun part.

Now try to make it misbehave

Ask it, in plain English, to read the five first artists. It will. Ask it to delete them, or edit them, or insert a row, and it will happily write the code to do so - and the runtime will refuse to dispatch it, because data.delete, data.create and data.update are not in the vocabulary you just read. A guest can read Chinook and compose any read it likes; it cannot write a single byte, and it cannot reach anything else on the server.

If you do get a row to change, that is a verified sandbox escape, and I owe you $100. The full walkthrough of how this endpoint is built - and copy-paste cURL for all of it - is in Let Strangers Run Code on Your Server. On Purpose.

The honest edges

The headline is a joke wearing a tie. 10^1204 is the count of possible inputs, not distinct useful operations - the honest sentence is "one endpoint whose behaviour the caller composes, bounded by a fixed vocabulary." That is less fun and more true, and it is still the point.

Secure is not the same as omnicapable. This guest endpoint reads one database because that is all I granted it. A real deployment grants exactly the capabilities you choose, per role - your CEO's role reaches the finance database, your support agent's role reaches the tickets, and neither can compose its way into the other's. Capability, not catalogue. You still decide what the capabilities are; the runtime only guarantees nobody exceeds them.

And it does not make wrong logic right. A model that writes a bad query gets a bad answer, executed perfectly safely. The sandbox is a boundary, not a proofreader.

Run your own

One command runs the whole platform locally:

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

Open localhost:5555, point it at localhost:4444, log in with root / root, and build a Sandbox API endpoint of your own in the Endpoint Generator - granting the vocabulary you want, to the roles you choose. Install the mcp plugin and every endpoint in your cloudlet becomes a tool your agents can invoke.

Magic is MIT licensed and open source - the repository is at github.com/polterguy/magic, the documentation at docs.ainiro.io. If you would rather someone else kept it patched, a managed cloudlet runs the same code.

Ten to the power of 1204 integrations, none of which I wrote, none of which I maintain, and not one of which can do anything I did not allow.

And here is the punchline. Testing that many inputs one at a time would outlast the universe, many times over - so I did not test them one at a time. Every one of those 10^1204 inputs resolves to the same correct verdict at the same single check: the one loop that reads the whitelist before it dispatches. Which lets me say something no test suite on Earth can say about its own code. I have debugged all 10^1204 of my integrations, 100% perfectly - and it took one second. That second was the request you just watched get refused. Try to break it.

Frequently asked questions

How can one MCP endpoint replace many integrations?

Instead of a tool per operation, the endpoint accepts a plain-English instruction, has a model compose it into code, and runs that code inside a whitelist of allowed functions. The caller composes whatever operation it needs out of the granted vocabulary, so a single capability-scoped endpoint covers the combinatorial space of operations you would otherwise build one integration at a time.

How do I connect an AI agent to the free endpoint?

Point any MCP client - Claude Code, Codex, Qoder, OpenCode or another - at https://hyperlambda.dev/magic/modules/mcp/mcp. The cloudlet answers unauthenticated requests with a 401 carrying its OAuth metadata, so the client walks you through sign-in; log in with username guest and password guestguestguestguest. The guest role grants read-only access to the Chinook sample database.

What should I ask the endpoint first?

Ask it to "Return server vocabulary". It replies with the exact list of functions it will dispatch, which seeds your model's understanding of what the tool can and cannot do, so its later instructions stay inside the allowed vocabulary rather than guessing.

Is the free endpoint safe to let an agent loose on?

Yes. The guest role can only read the Chinook sample database. Any attempt to insert, update or delete is refused before it runs, because those functions are not in the granted vocabulary, and the endpoint cannot reach any other database, the file system, or configuration. There is a standing $100 bounty for a verified escape.

Our Integration Count Has 4,196,703,834 Digits

Thomas Hansen — Sun, 20 Sep 2026 14:36:20 +0000

Part of the honest comparison series — see also Magic vs n8n, Magic vs Directus, Magic vs PocketBase and Unqork Raised $365 Million to Reinvent the Config File.

Every integration platform on earth puts a number on its homepage. Nine thousand apps. Twelve hundred connectors. Seven hundred sources. The number is always followed by a plus sign, and it is always getting bigger, and it is always presented as though it settles something.

I went and collected them. All of them, from the vendors' own pages, on the same day.

What I found was not that my number is bigger. What I found is that nobody is counting the same thing, several of them cannot agree with themselves on a single page, and at least one of them is counting itself.

The numbers, as published

Every figure below is the vendor's own, taken from their own site on 20 September 2026, in their own words.

Platform	Published figure	What they call the unit
Zapier	9,000+	"apps"
Workato	1,200 — and 1000+	"pre-built connectors" — and "apps"
Airbyte	700+ — and 584	"connectors"
Tray	474+	"pre-built connectors"
n8n	400+	"integrations"
Supabase	114	"partners"
ToolJet	100+	"integrations"
Retool	none published	74 logos on the page
Make	could not read it	their site blocked me

Look at the right-hand column before the middle one. Apps. Connectors. Partners. Integrations. Logos. Five different words for five different things, stacked into a single league table that the entire industry then argues about.

An "app" at Zapier is a hosted OAuth integration with triggers and actions. A "connector" at Airbyte is an ELT source or destination with incremental sync. A "partner" at Supabase is a company that has a business relationship with Supabase. These are not comparable quantities. Putting them in one column is like ranking countries by a list that mixes population, area and number of airports.

Three things I found while counting

1. Workato publishes two different numbers on the same page. The page's own meta description says "Browse through more than 1,200 pre-built connectors." The popup that appears on that same page says "Connect to 1000+ apps instantly." Twelve hundred and one thousand, on one URL, in one visit.

2. Airbyte contradicts itself on a single screen. The hero says 700+ connectors. Scroll down four inches to the catalogue filter and it says "Showing 100 of 584." You do not need me to adjudicate this one. Their marketing number and their database number are both on your monitor at the same time, and they differ by a hundred and sixteen.

3. Retool counts itself seven times. Retool publishes no headline figure at all, which is more honest than most of this list. But their integrations page carries 74 logos, and when you actually read them: seven are Retool's own products — Retool AI, Retool API, Retool Database, Retool Email, Retool RPC, Retool Storage, Retool Vectors. Seven more are generic protocols — REST, GraphQL, gRPC, SOAP, OpenAPI, JDBC, SMTP.

That last group is the interesting one. "REST" is not an integration. REST is the ability to make an HTTP request, which is table stakes for anything with a network stack. If "we support REST" counts as an integration, then every programming language invented since 1995 ships with several thousand of them.

So roughly one in five Retool "integrations" is either Retool or a transport layer.

Make would not let me count

Three separate attempts to load Make's integrations page — twice from my laptop, once from a server in a different country — returned a Cloudflare bot challenge. HTTP 403, "Just a moment..."

I am not alleging anything. Bot protection is normal and Make did not put it there to stop me. But I am not going to publish a number I could not read, so Make gets an asterisk instead of a figure. That is the standard I am holding myself to in the table above, and it is worth noticing how rarely that standard gets applied to these numbers in the other direction.

So what is Magic's number?

If you want a catalogue-style figure from me, here are two honest ones: 27 plugins you can install into a cloudlet, exposing roughly 420 slots.

Notice that I just gave you two numbers that measure different things, in a section complaining about people giving you two numbers that measure different things. A plugin is a distributable package. A slot is a callable operation. Neither is an "integration" and I am not going to pretend either one belongs in that table.

Because the honest answer is that the question is wrong.

A catalogue is a list of things somebody already built for you

That is what all of these numbers actually measure: how much work a vendor has done in advance, on your behalf, guessing what you would need.

It is a real thing to measure! If the vendor guessed right, you save days. Zapier has guessed right nine thousand times and that is a genuine, enormous achievement that I could not replicate and will not belittle.

But a catalogue has a hard edge. The day you need the thing that is not on the list, the number on the homepage does nothing for you. It does not matter whether it said 400 or 9,000. You are off the map, and what happens next depends entirely on what the platform lets you do when the catalogue runs out.

Hyperlambda is not a catalogue. It is a language. And the set of integrations a language can express is not a list somebody maintains — it is bounded only by what you can write in it.

Funny math, with the working shown

So let us do the same trick they do, except I will show you every step, because the entire point of this article is that they don't.

A Hyperlambda integration is a text file. A $100 cloudlet — the actual product, the one on the pricing page — ships with 2 GB of disk. That is exactly 2,147,483,648 bytes, and Hyperlambda source is printable ASCII, one character per byte, call it 90 usable characters.

So here is the question, and notice that it is a question about a real machine rather than about infinity: how many distinct Hyperlambda files can you persist on the cloudlet you are renting from me for a hundred dollars a month?

90 ^ 2,147,483,648

That number has 4,196,703,834 digits.

Some scale for that, because "four billion digits" does not land on its own:

Counting Zapier's 9,000 apps at one per second takes two and a half hours.
Reading out my number — not the quantity, just its digits — at one digit per second takes 133 years.
Add up every published figure in the table above. All of them, every vendor, one grand total: 11,988. Dividing my number by that removes five digits. It leaves 4,196,703,829.

You cannot draw that on a chart. There is no chart.

It is larger than every particle in the universe, and that is not a figure of speech

The observable universe contains roughly 10^80 atoms. Counting every elementary particle rather than every atom — throwing in photons and neutrinos, taking the most generous estimate anyone publishes — gets you to about 10^97.

My integration count is approximately 10^4,196,703,833.

So it exceeds the total number of elementary particles in the observable universe by a factor of 10^4,196,703,736. To cross that gap starting from the atoms, you would multiply a trillion by itself 349,725,312 times.

Try to make the universe big enough to catch up. You can't, and the way it fails is instructive:

Suppose every elementary particle in the universe were itself an entire universe, with its own 10^97 particles. Then suppose every particle in each of those was another universe. You would need to keep nesting roughly 43 million levels deep before the particle count caught my file count.
Or go wide instead. The string-theory landscape — the most extravagant number of universes physics has ever seriously written down — is about 10^500. Give every one of them 10^97 particles. Total: 10^597. That is every particle in every universe in the largest multiverse anyone has ever proposed, and it removes 597 digits from a 4,196,703,834-digit number.

Every catalogue in that table, plus every particle in every universe in the multiverse, and the number is still essentially unchanged.

And it fits on a 2 GB disk that costs a hundred dollars a month.

Now the honest part, which is the part they always leave out. That number counts every possible string, and the overwhelming majority of those strings are not valid Hyperlambda, let alone useful integrations. It is a preposterous figure. It is supposed to be a preposterous figure.

That is the joke. My number is absurd, and I have just shown you precisely how I manufactured it, which means you can check it and reject it. Their numbers are also a construction — a choice about what to count, made by the people who benefit from the answer — and they have shown you nothing. Airbyte's own catalogue disagrees with Airbyte's own hero by 116. Nobody publishes the working.

The difference between funny math and marketing math is whether the author admits which one they are doing.

The part that is not funny math

Underneath the gag there is a real claim, and it does not need a single exponent.

Any API with an OpenAPI specification is already an integration. Point Magic at the spec and it generates endpoints and secured MCP tools in seconds. Not "we support REST" in a logo grid — the actual typed operations, wired up and callable.

Any database is already an integration. Point it at a schema and CRUD endpoints come out the other side, MySQL, PostgreSQL, SQL Server, SQLite, including the twenty-five-year-old one nobody wants to touch.

Any sentence is already an integration. This is the one that actually retires the catalogue, and it is the next section.

And if the language genuinely is not enough, there is C#, Python and the terminal underneath it, compiled and loaded into the running process, instantly available to your frontends and over MCP. The escape hatch that Unqork's users ask for and do not get is just... there.

English, Swedish, or Urdu

Here is the thing the number is actually standing in for.

I asked Magic's Hyperlambda generator for an integration. Not by dragging a box onto a canvas. Not by writing code. By typing a sentence — in Norwegian:

Lag et HTTP endepunkt som henter en tilfeldig vits fra Chuck Norris API-et og returnerer vitsen. Kun brukere med rollen 'admin' skal ha tilgang.

Three seconds later:

.arguments
auth.ticket.verify:admin
http.get:"https://api.chucknorris.io/jokes/random"
   convert:true
yield
   joke:x:@http.get/*/content/*/value

It caught "kun brukere med rollen 'admin'" and emitted the authorisation check. That endpoint is now live, role-secured, and exposed to any AI agent over MCP.

Then I asked for the same thing in Urdu:

ایک HTTP اینڈ پوائنٹ بنائیں جو Chuck Norris API سے ایک بے ترتیب لطیفہ حاصل کرے اور اسے واپس کرے۔ صرف 'admin' کردار والے صارفین کو رسائی حاصل ہونی چاہیے۔

1.3 seconds. Same endpoint. Same auth.ticket.verify:admin. And — I enjoyed this more than I should have — the Urdu run picked the correct Chuck Norris URL, where the Norwegian run got it slightly wrong.

That integration did not exist in anybody's catalogue. It exists now, because somebody described it in Urdu.

So when a platform's answer to "the catalogue doesn't have it" is "no problem, just write the custom connector yourself" — in JavaScript, in their SDK, against their component model, with their build step — understand what has happened. The number on the homepage was the marketing. The hand-written code is the product.

Magic's answer to the same question is a sentence. In whatever language you happen to think in.

I am not going to pretend the generator is infallible; it is a fine-tuned model and it gets things wrong, which is exactly why the output is constrained to a vocabulary it cannot escape and why you can read every line of what it produced above. It is eight lines. You just read it. Try that with a serialised component graph.

Where these platforms genuinely win

The rule of this series is that this section contains no rebuttals. They do not come afterwards either.

Zapier's 9,000 is real and I cannot match it. Nine thousand maintained OAuth integrations, credential rotation handled, API changes absorbed by somebody else, usable by a person who has never heard the word "endpoint". If your need is on that list, use Zapier. You will be finished this afternoon and I would be wasting your time.

Airbyte does something I do not do. ELT with incremental sync, schema drift handling, normalisation, state management across runs. "Move this table into that warehouse, hourly, forever, and cope when the source changes shape" is a genuinely hard problem and a data.read does not solve it.

n8n's canvas is a real product for a real audience. When an operations team needs to see a flow — where it forked, where it died, what the payload looked like at step six — a visual graph beats a text file. I make the argument for the other side elsewhere, and it does not win every time.

Workato and Tray sell governance, not connectors. Approval workflows, environment promotion, audit, role separation, the compliance paperwork. Enterprises are buying the process, and the connector count is a proxy for "we have been doing this long enough to have built a lot".

Supabase's 114 are honestly labelled. They call them partners, which is what they are. Of everyone in that table, Supabase is the only one whose noun exactly matches the thing being counted — and they have the smallest number. Those two facts are related, and it is to their credit.

The decision rule

Use a catalogue platform if the thing you need to connect is on the catalogue. Genuinely. Check the list first. If Zapier has it, the argument is over and you should go and use Zapier.

Use Magic if what you need is not on anybody's list — the internal system, the legacy database, the partner's undocumented API, the thing your own company built in 2004 — or if you need the integration to run on your own hardware, or to be readable by the person who inherits it, or to be generated on demand by an AI agent that is constrained by a runtime rather than a system prompt.

The single question that decides it: what happens on the day the catalogue does not have it? Every platform in that table has an answer, and for most of them the answer is "write the connector by hand, in our framework, and maintain it forever". Mine is "describe it in a sentence."

The fine print

Every competitor figure in this article was read from the vendor's own public page on 20 September 2026 and is quoted in the vendor's own unit word. Where a vendor published two conflicting figures, both appear. Where I could not load a page, no figure appears.

Specifically: Zapier's 9,000+ from their apps directory; Workato's 1,200 from their integration library's meta description and their 1000+ from the popup on that same page; Airbyte's 700+ from their connectors hero and 584 from that page's own catalogue filter; Tray's 474+ from their connectors page; n8n's 400+ from their integrations page; Supabase's 114 from their partners listing; ToolJet's 100+ from their homepage. Retool publishes no aggregate figure; the 74 is my own count of the logos on their integrations page, and the seven-Retool-products and seven-protocols breakdowns are from reading those logos. Make's integrations page returned HTTP 403 Cloudflare challenges to three attempts from two countries.

These numbers move. If you are reading this months later, check them yourself — and notice whether the unit word changed along with the figure.

The 4,196,703,834 is floor(2147483648 × log10(90)) + 1, where 2,147,483,648 is the 2 GB of disk on a $100 cloudlet expressed in bytes, at one printable-ASCII character per byte. The premise is stated in full in that section, and the premise is where all the mischief lives, which is the entire point of including it. The Norwegian and Urdu generations are real, unedited, and were run through the live generator while writing this article; the timings are what the API reported.

The physics comparisons use the standard order-of-magnitude figures: ~10^80 atoms in the observable universe, ~10^97 elementary particles on the most generous published estimates, and ~10^500 for the string-theory landscape. These are order-of-magnitude estimates and not precise measurements, which does not matter here — moving any of them by ten orders of magnitude changes the conclusion by ten digits out of four billion.

Magic's own figures: 27 installable plugins and roughly 420 slots, both of which I have just argued are the wrong unit.

And the obvious disclosure: I wrote Hyperlambda, I sell Magic hosting, and I chose which numbers to put in a table. I have made every one of them checkable precisely because I am not a neutral party. If I have been unfair to a vendor, their page is public and so is my method — go and check, and tell me if I got something wrong.

For whatever it is worth as a credential: I have been writing software since I was eight years old, that is forty-four years now, and I am cited on microsoft.com.

Frequently asked questions

How many integrations does Magic have?

Magic does not have an integration catalogue, so the number does not exist in the form the question expects. It ships 27 installable plugins exposing roughly 420 slots, it turns any OpenAPI specification into secured endpoints and MCP tools, it generates CRUD APIs from any supported database schema, and it generates new integrations from a natural-language sentence. The constraint is what you can describe, not what a vendor built in advance.

Which platform publishes the most integrations?

Zapier, at 9,000+ "apps" as published in September 2026, ahead of Workato at 1,200 "pre-built connectors", Airbyte at 700+ "connectors", Tray at 474+, n8n at 400+, Supabase at 114 "partners" and ToolJet at 100+. Retool publishes no aggregate figure. These units are not equivalent to each other.

Why do Airbyte's and Workato's integration counts contradict themselves?

Both publish two different figures on a single page. Airbyte's hero says 700+ connectors while that page's own catalogue filter says "Showing 100 of 584". Workato's page meta description says more than 1,200 pre-built connectors while a popup on the same page says 1000+ apps. Both were observed on 20 September 2026.

Does Supabase have integrations?

Supabase publishes 114 entries that it explicitly calls partners, not integrations — companies with a business relationship with Supabase. It is the only figure in this comparison whose unit word accurately describes what is being counted.

Can you create an integration without writing code?

Yes. Magic's Hyperlambda generator turns a natural-language description into a working, role-secured endpoint. This was verified for this article in Norwegian (3.0 seconds) and Urdu (1.3 seconds), both producing a correct authorisation check. The generated Hyperlambda is readable text you can review before it goes live.

Is Magic's integration count really bigger than the number of particles in the universe?

Yes, on the stated premise, and the premise is the arithmetic in the article rather than a claim about physics. A 2 GB cloudlet holds 2,147,483,648 bytes; at 90 printable ASCII characters per byte that is 90^2,147,483,648 distinct files, a number with 4,196,703,834 digits, or roughly 10^4,196,703,833. The observable universe holds about 10^80 atoms and at most about 10^97 elementary particles. Even every particle in every universe of the 10^500 string-theory landscape removes only 597 digits from the total. This is deliberately absurd arithmetic, presented with its working shown.

What happens when an integration is not in the catalogue?

On a catalogue platform you write a custom connector by hand in that vendor's framework and maintain it yourself. On Magic you describe the integration in a sentence, or import its OpenAPI specification, and if the language genuinely cannot express it there is C#, Python and terminal access underneath, compiled into the running process and immediately available to frontends and over MCP.

Masturbation Is 100 Times More Dangerous Than AI

Thomas Hansen — Mon, 14 Sep 2026 13:01:38 +0000

This headline is intentionally provocative.

It is also based on a simple comparison between two uncertain figures.

The comparison

An old estimate suggested that between 250 and 1,000 people die each year in the United States from autoerotic asphyxia.

Autoerotic asphyxia means sexual activity involving strangulation or oxygen restriction. It is not ordinary masturbation.

Separately, a small number of suicides involving ChatGPT, Claude and other conversational AI systems have been publicly reported or alleged through lawsuits, family statements and investigations.

A reasonable working estimate for these publicly reported AI-associated suicides is approximately 2 to 10 cases.

Using midpoint figures:

500 autoerotic deaths ÷ 5 AI-associated suicides = 100

Therefore:

Masturbation is approximately 100 times more dangerous than AI.

The calculation is not a medical conclusion. It is a statistical punchline.

The limitations

The estimate of 250 to 1,000 autoerotic deaths per year is old and uncertain.

A recent systematic review identified 101 published autoerotic death cases across 44 years. This is not a complete national or global registry. It only counts cases documented in the forensic literature.

AI-associated deaths have similar classification problems.

A death may involve:

A chatbot conversation
Existing mental illness
Social isolation
Family conflict
Drug use
Financial or relationship problems
Other online communities
Several simultaneous causes

The presence of an AI conversation does not, by itself, establish causation.

There is currently no standard death-certificate category called “death caused by ChatGPT” or “death caused by Claude.”

Historical autoerotic-death estimate

Recent systematic review of autoerotic deaths

Database of reported AI-associated fatalities

Other unusual causes of death

The following figures are mostly from the United States.

Cause	Approximate figure
Bee, wasp and hornet stings	72 deaths per year
Cattle-related incidents	Approximately 20–22 deaths per year in older estimates
Lightning	Approximately 20 deaths per year
Furniture and television tip-overs	217 reported deaths from 2013 to July 2023
Vending machines	37 reported deaths from 1978 to 1995
Shark attacks	Usually 5–10 deaths worldwide per year
Falling coconuts	Unknown
Garden rakes	Unknown

Bee, wasp and hornet stings

The CDC recorded 788 deaths from hornet, wasp and bee stings between 2011 and 2021.

That equals an average of 72 deaths per year.

The annual figure ranged from 59 to 89. Eighty-four percent of the victims were male.

CDC data

Cattle

Cattle can kill people by trampling, kicking, crushing or striking them.

Older CDC agricultural estimates placed cattle-related deaths at approximately 20–22 per year in the United States.

The victims were mainly agricultural workers handling cattle in pens, chutes and loading areas.

CDC agricultural safety material

Lightning

Lightning kills approximately 20 people per year in the United States.

The rate has declined substantially over the last several decades because of improved warnings, public education, emergency care and changes in outdoor work.

CDC-hosted lightning mortality study

Furniture and televisions

Unsecured furniture, televisions and appliances can tip over onto people.

The Consumer Product Safety Commission reported 217 fatalities from January 2013 through July 2023. Of those victims, 155 were children.

The same report estimated approximately 17,800 emergency-department-treated injuries per year from these incidents.

CPSC tip-over report

Vending machines

The vending-machine statistic is often exaggerated.

The CPSC reported at least 37 deaths between 1978 and 1995 after people rocked or tilted vending machines.

That equals approximately two deaths per year during that period.

The machines fell onto the victims. They did not kill people by dispensing drinks incorrectly.

CPSC vending-machine warning

Falling coconuts

Falling coconuts can cause fatal head injuries.

However, the popular claim that coconuts kill 150 people per year is unsupported.

The figure appears to have developed from a medical report about coconut injuries in Papua New Guinea and was later repeated as a global estimate.

Actual coconut deaths occur, but the annual global number is unknown.

Original medical paper

Why the comparison is useful

The headline does not prove that AI is harmless.

A handful of reported suicides involving AI systems is still serious, particularly where a system may reinforce delusions, dependency or suicidal thinking.

The comparison demonstrates something else:

Humans have been dying from bizarre, mundane and poorly tracked activities for a very long time.

Masturbation-related deaths have an old and uncertain estimate.

AI-associated suicides have a new and uncertain estimate.

The exact ratio cannot be proven.

But “Masturbation Is 100 Times More Dangerous Than AI” remains a mathematically plausible thing you can quote me on in the public space, and easily be within 2 order of magnitudes correct ...

NOW let's talk about AI regulations ...

Your sitemap is an API — a whole website as one JSON document in 35 lines

Thomas Hansen — Mon, 14 Sep 2026 07:56:19 +0000

Every time I want to give a model a site rather than a page, I end up writing the same throwaway script. Fetch the sitemap. Loop the URLs. Pull the title, the H1, the meta description. Strip the HTML down to something readable. Glue it into one file. Delete the script. Write it again three weeks later.

So I made it a URL instead:

https://hyperlambda.dev/website-to-json — paste a domain, get one JSON document back. Free, no signup, no key.

What comes back

One array, one object per page:

[
  {
    "url": "https://example.com/pricing",
    "h1": "Pricing",
    "title": "Pricing | Example",
    "description": "One flat price, no surprises.",
    "markdown": "# Pricing\n\nOne flat price…"
  }
]

That shape is the whole point. markdown is the part you feed a model; url, h1, title and description are the parts you filter, dedupe and cite with. A folder of 50 Markdown files makes you rebuild that metadata yourself. One JSON document doesn't.

Useful immediately for: seeding a RAG index, diffing a site before and after a migration, auditing which pages are missing a meta description, or handing a competitor's docs to a model without writing a crawler.

The entire backend

Not a snippet of it. This is the deployed file:

.arguments
   url:string

// Throttling to maximum 5 requests per IP per minute!
execution.throttle.create:website-to-json
   limit:int:5
   window:int:60
   per:ip
execution.throttle:website-to-json

strings.concat
   get-value:x:@.arguments/*/url
   .:/sitemap.xml
http.get:x:-
xml2lambda:x:-/*/content
.result
for-each:x:@xml2lambda/*/urlset/*/url/*/loc/*/#text/[0,50]
   http.get:x:@.dp/#
   html2lambda:x:-/*/content
   .h1
   strings.join:x:@html2lambda/*/html/*/body/**/h1/[0,1]/**/#text
      .:" "
   set-value:x:@.h1
      strings.trim:x:@strings.join
   .title
   set-value:x:@.title
      get-value:x:@html2lambda/*/html/*/head/*/title/*/#text
   .description
   set-value:x:@.description
      get-value:x:"@html2lambda/*/html/*/head/*/meta/*/\\@name/=description/./*/\\@content"
   lambda2html:x:@html2lambda/*/html/*/body
   html2markdown:x:@lambda2html
      url:x:@.arguments/*/url
   unwrap:x:+/*/*/*
   add:x:@.result
      .
         .
            url:x:@.dp/#
            h1:x:@.h1
            title:x:@.title
            description:x:@.description
            markdown:x:@html2markdown
return-nodes:x:@.result/*

No dependencies, no build step, no project scaffold. That file is the deployment — saving it publishes the endpoint.

The parts worth stealing

This is Hyperlambda, where code is a tree rather than text, and the interesting bits are the expressions that walk it.

The sitemap is parsed, not regexed. xml2lambda turns the XML into nodes, and then the loop selects every URL in one expression:

for-each:x:@xml2lambda/*/urlset/*/url/*/loc/*/#text/[0,50]

Read it right to left: every #text under every loc under every url in the urlset — then [0,50] slices the first fifty. The page limit isn't an if with a counter; it's part of the address of the data.

Attribute matching without a DOM library. Pulling <meta name="description" content="…"> is one expression:

@html2lambda/*/html/*/head/*/meta/*/\@name/=description/./*/\@content

Find the @name attribute whose value equals description, step back up to its element with ., then take that element's @content. Attributes are \@-prefixed nodes, so they're addressable the same way elements are.

H1 text is joined, not assumed. An <h1> containing a <span> and a stray <br> has several text nodes. **/#text collects all of them under the first H1 and strings.join puts them back together with a space — so <h1>Build <span>fast</span></h1> yields Build fast, not Build.

Relative links survive. The body is serialized back to HTML and converted with the original domain passed in:

html2markdown:x:@lambda2html
   url:x:@.arguments/*/url

Without that, every /pricing in the output would be a dead relative link the moment the JSON left the site it came from.

What it will not do

Worth stating plainly, because a crawler that pretends otherwise wastes your afternoon:

It needs a sitemap. The URL you pass gets /sitemap.xml appended, so pass the origin with no trailing slash (https://example.com). No sitemap, no output. Sites that keep a sitemap index rather than a flat urlset won't enumerate either.
It does not run JavaScript. Server-rendered HTML only. A client-rendered app returns its shell, exactly like curl would.
Fifty pages, hard. Fine for a docs section or a marketing site; not a crawler for your 40,000-page store.
Five requests per minute per IP. It's a free shared endpoint doing 50 HTTP fetches per call. Hammer it and you'll just get throttled — the source is above, run your own.

It also costs the target site 50 requests, so point it at your own property or something that welcomes it.

The part I actually find interesting

The file above was written from a plain-English description by a code generator, and every function in it was verified against the functions that actually exist on the server before it was saved. Not "the model probably got the API right" — checked, then deployed, with no restart.

That inverts the usual trade-off with generated backend code. The risk isn't that the model writes ugly code, it's that it writes code that references something imaginary and fails at 3am. If the runtime refuses to save anything that invokes a function it doesn't have, the failure happens at generation time instead.

Same property makes it an agent tool rather than a web page: on this stack every HTTP endpoint is also an MCP tool, role-filtered, so an agent can call website-to-json and get the same array without a browser in the loop.

Try it

The tool: https://hyperlambda.dev/website-to-json
More free ones — page to JSON, dead link checker, link preview checker, llms.txt generator: https://hyperlambda.dev/tools
Run the whole platform yourself, MIT-licensed:

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

If you build something with the output, I'd like to hear what you pointed it at.

I built 9 free web tools and printed the entire backend on every page. What should number 10 be?

Thomas Hansen — Sun, 13 Sep 2026 05:47:20 +0000

Over the last couple of weeks I've built nine small web tools. No signup, no API key, no "start your free trial". You paste a URL, you get a result.

There's a catch, and it's the interesting part: every tool prints the complete source code of its own backend, right there on the page. Not a snippet. Not pseudocode. The actual file that ran when you clicked the button.

I did that because I wanted the tools to be an argument, not a brochure. If I claim a backend is small, you shouldn't have to take my word for it.

Now I've run out of good ideas for number ten, which is why I'm writing this. Skip to the bottom if you just want to tell me what to build.

The nine

URL to Markdown — paste a link, get clean Markdown for an LLM prompt, plus the token count before and after so you can see what the HTML was costing you.
Page to JSON — one page as structured JSON: title, H1, description, text, every link with its anchor text, every image with its alt. Missing anchor and alt text get flagged rather than silently returned as empty strings.
Website to JSON — same idea, but walks the sitemap instead of one page.
URL to YAML — a page's metadata as YAML.
llms.txt generator — builds an llms.txt from your sitemap.
AI Crawler Check — which AI crawlers your robots.txt actually allows or blocks, citing the exact rule that decided each one. Also checks whether your content survives without JavaScript, because most AI crawlers don't render it.
Link Preview Checker — what your Open Graph and Twitter cards really look like to a scraper.
Website Image Gallery — every image across your site with its alt text, so you can find the ones missing it.
Dead Link Checker — crawls your sitemap and reports links that don't answer 200.

All nine are here: hyperlambda.dev/tools

What "the whole backend" actually looks like

Here's URL to Markdown, in full. This is not an excerpt:

.arguments
   url:string
validators.mandatory:x:@.arguments/*/url
validators.url:x:@.arguments/*/url
http.get:x:@.arguments/*/url
html2markdown:x:-/*/content
   url:x:@.arguments/*/url
openai.tokenize:x:@http.get/*/content
openai.tokenize:x:@html2markdown
yield
   markdown:x:@html2markdown
   html_tokens:x:@openai.tokenize/@openai.tokenize
   markdown_tokens:x:@openai.tokenize

Fetch it, convert it, count the tokens twice, return three fields. The language is Hyperlambda, which is my own thing, so take the language advocacy with as much salt as you like — the point I care about is that a working tool can be this small, and that you can check.

Not all nine are that short. The dead link checker is about seventy lines, because deduplicating links and surviving hosts that refuse connections is genuinely more work. That page says so and prints all seventy.

They're also MCP tools

Every HTTP endpoint on this platform is automatically exposed as an MCP tool, filtered by role. So these aren't just web pages — an agent can call the same endpoints directly, and "build a tool" and "build an agent tool" stopped being two separate tasks.

That turned out to be the thing I use most. Half of these exist because I wanted Claude to be able to read a page properly.

The honest limits

Things I'd rather you hear from me than discover:

No JavaScript rendering. Everything fetches server-rendered HTML. A client-side-rendered SPA comes back nearly empty — which is also exactly what most AI crawlers see, so arguably that's the useful answer.
The dead link checker crawls 10 sitemap pages max, though it checks every link it finds on them.
The image gallery caps out at 50 results.
Some sites return 403/999 to anything that isn't a browser. That's a bot refusal, not a broken link, and the dead link checker separates those into their own bucket instead of calling them dead.
These are free and shared. Please don't point a load test at them.

So — what should number 10 be?

This is the actual reason for the post. I'm better at building these than at thinking of them.

What I'm after is the thing you currently do by hand, or with a browser extension you don't trust, or by pasting into three different sites in sequence. Ideas I've had and rejected as too boring: another JSON formatter, another minifier, another base64 thing.

Some prompts, if it helps:

What's the last web-related task where you thought "surely something does this for me" and nothing did?
Is there a tool you use that's fine except for one missing feature?
What would you want an AI agent to be able to do to a web page, that it currently can't?

Reply with whatever comes to mind. If I build yours I'll say so in the thread, and it'll be free and no-signup like the rest.

And if one of the nine is broken or wrong for your site, I'd genuinely rather know — tell me the URL you tried.

Magic vs Directus: An Honest Feature Matrix

Thomas Hansen — Tue, 01 Sep 2026 06:28:11 +0000

The n8n matrix was easy mode. The PocketBase one was hard mode, because PocketBase is Magic's closest architectural sibling.

This one is different again. Directus is not Magic's closest sibling — it is Magic's closest competitor. If you are evaluating a platform that wraps a database you already have, in whatever engine it happens to live in, without migrating anything, then Directus and Magic are pitching you the same sentence. It is a genuinely excellent product with a decade of polish on it, and on several rows below it beats Magic outright.

One sentence of thesis before the table, because every row descends from it:

Directus computes your API at runtime. Magic writes it to disk.

Directus introspects your schema, holds permissions as configuration, and resolves each request against both. Nothing is written down — the effective API exists only as the result of that computation. Magic's generator emits actual endpoint files you can open, read, diff, edit and commit. Watch how far that one difference propagates.

The matrix

Feature	Directus	Magic Cloud
Licence	Monospace Sustainable Core License — source-available, non-compete, with licence-key enforcement you may not circumvent; converts to GPL-3.0 four years after each release	MIT, all of it, no thresholds and no conversion date
Free tier	Core: 3 user seats, 25 collections, 5 flows, no SSO	Self-host everything, uncapped, forever
Small-company escape hatch	Open Innovation Grant — fully permissive and free under $5M revenue and under 50 employees	Not needed; MIT has no revenue test
Paid tier	Team at $499/mo annual, $599 monthly — 10 SSO seats, 50 collections, 20 flows	$100/mo per cloudlet, $300 for double the machine
Per-user cost	$50 per extra seat per month	None — unlimited users, never counted
Table cap	A collection maps to a database table: 25 on Core, 50 on Team, $100 per extra 25	None
Managed hosting	$99/mo add-on, on top of the plan	Included in the cloudlet price
SSO	Team plan and up; unavailable on Core at any price	Eight OIDC providers built in — Google, Microsoft, GitHub, LinkedIn, Slack, Okta, Auth0, Keycloak
The API	Computed at runtime from schema and config	Generated Hyperlambda files — real, readable, versionable
Schema changes	Reflected instantly, nothing to regenerate	Re-run the generator
Database engines	PostgreSQL, MySQL, MariaDB, SQLite, SQL Server, OracleDB, CockroachDB	SQLite built in, plus MySQL, PostgreSQL and SQL Server
Access control	Granular: field-level and item-level rules as filter expressions	Endpoint-level role gating, plus runtime slot whitelisting
Custom logic	Extensions in TypeScript, with a build step; Flows with sandboxed JS operations	Hyperlambda files, hot — no compile, no restart, generated from a prompt if you like
Content features	Revisions, drafts, translations, activity log — a decade of CMS heritage	None of it; not a CMS
Assets	File library with on-the-fly image transformation	File system, upload tickets, image resize and convert
Realtime	WebSockets and GraphQL subscriptions	SignalR — programmable events
Frontend hosting	Not the story	First-class static and SPA hosting per cloudlet
AI and RAG	AI Assistant, AI Translations on higher tiers	ML types, crawling, vectorisation, deployable chatbots
Agent story	MCP server over the API	Native MCP with OAuth; agents generate new tools for themselves at runtime inside RBAC
Non-developers	Genuinely usable by editors and ops people	A developer tool, and honest about it
Community	Large, funded, SOC 2, partner programme	Small

Where Directus wins, stated plainly

Per the rules of this series: no rebuttals in this section. They live below.

Permissions granularity. Field-level and item-level rules, expressed as filter conditions, evaluated per request. Magic gates by role at the endpoint. If your requirement is "this role sees every column except salary, and only rows in their own region", Directus expresses that as configuration and Magic expects you to write it. That is the widest genuine capability gap in the table.

Instant schema reflection. Add a column, and Directus's API has it. No regeneration step, no stale endpoints, no forgetting to re-run anything. This is the direct upside of the runtime model, and on a schema that changes daily it is a real ergonomic win.

Content management. Revisions, drafts, translations, an activity log people actually audit. Directus descends from headless CMS and it shows in a hundred small places Magic has never attempted.

Non-developer usability. You can hand Directus Studio to a marketing team. You cannot hand Hyper IDE to a marketing team, and I would not suggest trying.

Database engines. Oracle, MariaDB and CockroachDB are supported there and not here.

Ecosystem and assurance. A funded company, a partner programme, SOC 2 Type II, an extension marketplace, a large forum, and people you can hire who already know it. Every one of those is a cost I carry on my side of this table.

Where the bets diverge

The runtime model versus the generated one. Directus's API is a computation; Magic's is a file. That means Directus wins on schema churn and loses on inspection. There is no artefact to review, diff, or hand to a code reviewer — your effective API and permission surface live as rows in a config database, and the only way to know what they do is to ask the running system. Magic's endpoints are text on disk. You can read them, put them under git, and — the part that matters most here — hand them to an AI agent that can read them too.

Which is why the agent stories are not comparable. Both have MCP. But an agent pointed at Directus can call the API; an agent pointed at Magic can read what the API is, and then write more of it. Magic's generator emits Hyperlambda that executes as an AST where every node must bind to a whitelisted slot, so generated code cannot exceed its permissions no matter what the prompt said. That is the difference between an agent that queries your backend and an agent that builds it. There is a standing $100 bounty on proving that boundary wrong.

The extension model, again. This series keeps landing here because it keeps being the fork in the road. Directus extensions are TypeScript with a build step; Flows give you sandboxed JS for the smaller cases. Magic's custom logic is a Hyperlambda file that is live the moment it is saved — no compiler, no restart, no deploy — and can be written from a sentence.

Pricing shape, which is a licensing argument wearing a costume. Directus meters the two things that grow when your project succeeds: people and tables. Core stops at 3 seats and 25 collections. Team is $499/mo for 10 seats and 50 collections, with extra seats at $50/mo and extra collections at $100 per 25. Managed hosting is another $99. Magic charges per cloudlet — $100 or $300 — and counts neither users nor tables, ever.

Work an example. A team of six developers wrapping a 70-table legacy database, hosted: on Directus that is Team, plus one 25-collection pack, plus cloud — call it $698/mo before anyone else logs in. On Magic it is $100, and the seventh developer changes nothing.

Two honest caveats on that comparison, because it flatters me. If you are under $5M revenue and under 50 employees, the Open Innovation Grant makes Directus free and fully permissive, and this entire paragraph is moot for you — take the grant. And Directus is grandfathering existing customers, so anyone already on an older plan is not living in the table above.

The licence, which is the row I would read twice. Directus is source-available, not open source: the Monospace Sustainable Core License forbids Competing Use, forbids circumventing the licence-key functionality, and grants GPL-3.0 only on the fourth anniversary of each release. That is a defensible way to run a company, and I say that without snark — it is a real answer to a real sustainability problem. But it is not the same deal as MIT, and the difference shows up on the day your revenue crosses a threshold, or your lawyer asks what "Competing Use" means for the product you are building on top of it. Magic is MIT with nothing held back, no key, no threshold, no clock.

The decision rule

Choose Directus if: non-developers will use the admin UI daily; you need field- and row-level permissions as configuration rather than code; your content needs revisions, drafts or translations; your schema changes constantly; you are on Oracle or CockroachDB; or you qualify for the Open Innovation Grant, in which case a mature, funded, SOC 2 platform costs you nothing and that is very hard to argue with.

Choose Magic if: you are above the grant's thresholds and do not want per-seat and per-table metering; you want the API as reviewable source rather than runtime configuration; you need the platform to host the frontend as well as the data; or — the structural one — you expect AI agents to be building the backend rather than querying it.

The test that decides it in one question: does your backend need to be read by anything other than the server that runs it? If yes — by a reviewer, by git, by an agent — you want files. If no, a runtime model is less work.

The fine print

Every number above about Directus was verified on their own pricing and licence pages the day this was published: the MSCL-1.0-GPL terms, the $0 / $499 / custom tiers, the 3-seat and 25-collection Core caps, $50 per extra seat, $100 per 25-collection pack, the $99 cloud add-on, and the under-$5M-and-under-50-employees grant. Pricing pages move. If you are reading this months later, re-verify before quoting me — and I would rather you checked than trusted me.

The database engine list for Directus is from documentation rather than from my own testing, and Magic's own comparison rows are, obviously, written by the person who wrote Magic. Read the table with that in mind.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic. Testing any of this yourself takes one copy-paste on a $6 DigitalOcean droplet, or a managed cloudlet if you would rather not.

FAQ

Is Magic Cloud a Directus alternative?

For the developer case, yes — both wrap an existing database in a secured API without migrating it, both ship an admin UI, both self-host, both offer managed hosting. For the editorial case, no: Directus is a headless CMS with revisions, drafts and translations, and Magic is not trying to be one.

Is Directus open source?

Not in the OSI sense any more. It is source-available under the Monospace Sustainable Core License, which prohibits Competing Use and licence-key circumvention, and converts each release to GPL-3.0 after four years. Magic is MIT.

Is Directus free?

Free at the Core tier within hard caps — 3 seats, 25 collections, 5 flows, no SSO — and genuinely free and fully permissive under the Open Innovation Grant if your organisation is under $5M in revenue and under 50 employees. Above those lines it is $499/mo and up, with per-seat and per-collection metering.

Which handles a large legacy schema better?

Directus reflects the whole schema instantly with nothing to generate, which is the better ergonomic. But collections are capped by plan, and a 200-table system lands you in Enterprise pricing. Magic makes you run the generator and gives you files afterwards, with no table count anywhere in the pricing.

Can AI agents use both?

Both expose MCP. The difference is what the agent can do once connected: with Directus it calls your API; with Magic it can read the generated code and write more of it, inside a runtime that constrains what generated code is even able to express.

From Prompt to MCP Tool in 5 Seconds

Thomas Hansen — Tue, 18 Aug 2026 10:39:46 +0000

Building an MCP tool, as the industry currently understands the job: install an SDK, write a server, hand-author a tool schema, wire the handler, host the process, deploy it, restart it, reconnect the client.

Here is the same job on Magic, the MIT-licensed backend platform I work on.

You write a sentence.

That is the whole procedure, and this article is about why — because the interesting part is not that it is fast. It is that there is no second step to be fast at.

The measured run

I did this on the cloudlet serving my website while writing the article. The generator reports its own execution time, so these numbers are server-measured, not my stopwatch.

I wanted a tool that did not exist: a daily trend over the anonymous submissions to our carbon calculator — how many people submitted each day, and how heavy their average footprint was.

Attempt	Seconds (measured)	Outcome
First generation	2.88	Saved, then threw a 500 on invocation
Regenerated	1.83	Live and correct
Regenerated for a better description	3.03	Live, correct, properly documented

Three generations, 7.74 seconds of compute, one live tool. It is public and read-only, so you can call it yourself right now:

curl "https://hyperlambda.dev/magic/modules/mcp-demo/footprint-trend?days=365"

[{"day":"2026-08-09","submissions":2,"average_total_kg":16188.0},
 {"day":"2026-08-03","submissions":1,"average_total_kg":8772.0}]

I will come back to that failed first attempt, because the honest part of this story is more useful than the fast part.

There is no second step

The file the generator saved is this. The comment is abbreviated here; everything else is verbatim.

// Returns the daily trend of anonymous carbon footprint submissions, one entry per day [...]
.arguments
   days:int
validators.default:x:@.arguments
   days:int:7
data.connect:billionair
   data.select:"select date(created) as day, count(*) as submissions, avg(total_kg) as average_total_kg from footprints where created >= date('now', '-' || @days || ' day') and total_kg > 0 group by day order by day desc"
      days:x:@.arguments/*/days
   return-nodes:x:@data.select/*

Saving that file is the last thing that happens. There is no build, no restart, no registration, no export.

The reason is that Magic's MCP server has no tool registry. It does not keep a list of tools that somebody has to remember to update. When a client asks what tools exist, the server enumerates the endpoints that exist, right then, and describes them. The catalogue is not a copy of reality that can drift out of date — it is a query against reality.

Which means a tool cannot be added to the tool list. It can only be created, after which the list already contains it.

The same is true in the other direction, and this is the part I find quietly elegant: calling a tool runs the endpoint. Not a copy of the endpoint, not a proxy in front of it — the endpoint, through the same invocation path an HTTP request takes, carrying the caller's own identity. So the role check that guards it from a browser is the role check that guards it from an agent, because it is the same check. There was never a second one to keep in sync.

Your prompt is the tool description

Now the mechanic that makes one sentence sufficient.

A language model deciding whether to call a tool reads two things: the tool's description, and a description of each argument. In every other stack, those are a third artifact — written by hand, next to the code and the schema, and stale within a month.

Magic publishes an endpoint's file comment as the tool description, and the comment above each argument as that argument's description. And the generator writes the file comment from your prompt.

So the sentence you typed is not merely instructions to a code generator that get thrown away afterwards. It survives, in the file, as the documentation your agent reads. Here is what came back out the other end, from this cloudlet's live specification:

"/magic/modules/mcp-demo/footprint-trend": {
  "get": {
    "operationId": "get_mcp-demo_footprint-trend",
    "description": "Returns the daily trend of anonymous carbon footprint submissions, one entry per day, so a caller can see how many people submitted and how heavy their average footprint was [...]",
    "parameters": [{ "name": "days", "in": "query", "schema": { "type": "integer" } }]
  }
}

I never wrote a schema. I wrote days in a sentence, said it was an integer, and the type came along for the ride.

The mapping from Hyperlambda's types to JSON Schema is boring on purpose:

Hyperlambda	JSON Schema
`short`, `int`, `long`	`integer`
`decimal`, `double`, `float`	`number`
`bool`	`boolean`
`date`	`string`, format `date-time`
`guid`	`string`, format `uuid`
everything else	`string`

So write the prompt like a docstring

Here is a mistake I made in front of you, and it is the most useful paragraph in this article.

My second attempt worked perfectly, and its description read:

"Use a single SQL statement that does all date arithmetic inside the database itself: group rows by the date part of the 'created' column [...] Do not perform any date arithmetic outside of SQL."

Every word of that is true, and every word of it is useless to the model that has to decide whether to call the tool. I had written a work order for a compiler and published it as documentation. An agent reading that learns nothing about when this tool is the right answer — it learns how I wanted the SQL written.

So I regenerated a third time, with the same requirements in a different order: what the tool returns first, who would want it, what the argument controls, and the implementation constraint last. That is the 3.03-second run in the table, and it is the version now serving.

The rule that falls out of this is short. The prompt becomes the docstring, so write it as one. Lead with what the tool does and when to use it. Name every argument and its type. Put implementation notes at the end, where they belong — after the sentence a model actually needs.

Nobody writes tool definitions on this platform. But somebody still has to write the first sentence well, and that somebody is you.

The honest edges

The first generation was wrong. It compiled, it verified, it saved, and it threw a 500 the moment I called it — it had tried to subtract dates in a way the runtime found ambiguous. The verifier proves that every instruction in generated code exists and is real; it does not prove the code does what you meant. That still requires running it, which is why I ran it.

Note the fix, though: I did not open the file. I changed one clause in the prompt and regenerated, 1.83 seconds. When the build path is that short, it is also the repair path — hand-editing generated code is not the workflow here, and does not need to be.

Your client may not notice immediately. The server's catalogue is current the instant the file lands, but most MCP clients fetch the tool list once, when they connect, and cache it. The tool is live, callable, and in the catalogue — your agent just will not see it until you reconnect the connector. This trips people up regularly, and it is a client behaviour, not a server one.

Two smaller ones. Some clients enforce a 64-character limit on tool names; Magic does not truncate, so a very deeply nested module path could produce a name a strict client dislikes. And the transport is plain request/response JSON — a spec-compliant subset, with no SSE stream and no server-initiated messages.

One cloudlet, several servers

A last detail worth knowing. The MCP endpoint takes an optional path, which narrows the catalogue to one module subtree — point a client at ?path=/modules/crm/ and it sees the CRM tools and nothing else. The narrowing is confined inside modules/ and normalised at both ends, so /modules/crm cannot leak into a sibling like /modules/crm-archive.

Combine that with the catalogue being assembled per caller — Magic reads the roles on the authenticated ticket and lists only endpoints that caller may execute — and one backend serves as many different, differently-scoped MCP servers as you have audiences for. I made that argument properly in the OpenAPI article, so I will not repeat it here.

Try it

One command:

curl -fsSL https://hyperlambda.dev/docker-compose.yaml | docker compose -f - up

Open localhost:5555, point it at localhost:4444, log in with root / root, and describe a tool you wish you had. Then connect an agent and look for it.

Magic is MIT-licensed and open source. The repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

The five seconds in the title is the round number. The measured ones were 2.88, 1.83 and 3.03 — and honestly, the seconds are the least interesting thing about it. What matters is that when they elapsed, there was nothing left to do.

From Module to GitHub Repository in One Click

Thomas Hansen — Sat, 08 Aug 2026 06:06:44 +0000

Yesterday one of my modules became a GitHub repository. The whole ceremony: hover the folder, click the branch icon, write a commit message, click Publish.

Behind that one click, Magic created a private repository on GitHub, added it as the module's origin remote, pushed the commit, and configured upstream tracking. Four git operations, zero terminal.

You know the manual version of this dance. Create the repository in GitHub's UI or with gh repo create, copy the URL, git remote add origin, git push -u origin master, and somewhere in the middle a context switch that costs more than all the commands combined. That dance is now a button — because Hyper IDE has Git built in, and this article is the tour.

Where Git lives

Every top level folder inside /modules/ and /etc/ is treated as a repository root. Hover one in Hyper IDE's file tree, and a branch icon appears among its actions — that is the whole discovery story. One repo per module, deliberately: the module is already the unit of install, the unit of deployment, and the unit of meaning in Magic. Now it is the unit of versioning too.

The panel

Click the icon and you get the state of that repository: which branch you are on, whether you are ahead of or behind your remote, and every modified and untracked file. Commit everything with a message, push, pull, fetch, switch branches, create new ones.

The detail I care most about is what you cannot click. Push is greyed out until you actually have commits your remote does not. Clone demands an empty folder, because git demands an empty folder. A freshly initialized repository disables everything that requires a commit to exist. The panel teaches you git's rules by construction, instead of relaying git's error messages after the fact.

One token, no keychain

Setup is a single dialog: open Configuration, click the hamburger menu, choose Git…, and give it your GitHub username and a fine-grained personal access token with Contents read and write access.

The architecture behind that dialog matters more than the dialog. Credentials are injected per git invocation, over HTTPS, as a header — nothing is ever written to the server's global git configuration, no credential helper, no SSH keys sitting on disk. And commits are authored as you: the author name and email are resolved from the signed-in user's profile, so your history on GitHub shows your name, not some shared server identity. The token authenticates transport; people author commits.

The one click

Back to the headline. Take any module — say one you have been building all week — and open its Git panel. Not a repository yet? Click Initialize repository. Write a commit message, click Commit. Then click Publish to GitHub…, and give the repository a name — it defaults to the module's folder name, which is almost always the right answer.

That click creates the repository on GitHub — private by default, flip it to public over there if that is what you want — wires it up as origin, pushes your commit, and sets upstream tracking. Your module has a home, a history, and a URL.

Notice, creating repositories needs one more permission than reading and writing them: the account level repository creation permission on your access token, in addition to Contents. If your token lacks it, the panel will tell you so in plain text, because errors here are never swallowed.

The door swings both ways

Publishing is half the story. The other half: create a new empty folder inside /modules/, open its Git panel, and you get the mirror options — initialize, or clone.

Click Clone into folder, paste the repository's HTTPS URL, and the module lands on your cloudlet with its entire history attached. It checks out whatever the remote's default branch happens to be called — the panel has no opinions in the main-versus-master wars, and after debugging that assumption out of an earlier iteration, neither do I.

Modules travel now

Here is why this is more than a convenience feature.

Magic has always let you move modules between cloudlets as zip files — download here, install there. A zip is a snapshot. Git is a history: branches, rollback, blame, and a remote that two cloudlets can both talk to. Develop a module on your dev cloudlet, publish it, clone it into production, and from then on promotion is a pull. The zip workflow did not go anywhere — but the module you care about, the one that grows for months, wants version control, and now the platform it lives on speaks it natively.

And because everything in Magic is reachable by agents, the same is true over MCP — the git workflow tools have been callable by AI agents for a while. What is new is that humans got the good UI too.

The fine print

Big claims, precise edges — as always.

This is not a full git client, and it does not want to be. Commit stages everything the change list shows — there is no per-file staging in v1. There is no diff viewer and no merge-conflict UI; if a pull lands you in conflict territory, clone the repository locally and resolve it with real tooling, then push. The panel covers the module lifecycle — initialize, commit, branch, publish, clone, pull, push — not interactive rebases.

One deliberate sharp edge worth knowing: paths must be repository roots. Git's normal upward discovery is disabled on the server, so a folder that is not itself a repo throws instead of silently operating on some enclosing repository it happened to find above itself. That rule exists because during development, the panel on a repo-less folder cheerfully offered to commit the entire Magic source tree it found two levels up. Loud beats silent, every single time.

The whole feature was built in a day, driving Claude against the running dashboard — including three separate ambushes by a hardcoded main branch assumption and the discovery bug above. That story, bug ledger and all, is its own article.

The keys

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io. If you want a cloudlet of your own to publish modules from, it is one copy-paste on a $6 DigitalOcean droplet.

Why Claude Is 10x Cheaper When It Builds on Magic Cloud

Thomas Hansen — Thu, 06 Aug 2026 07:05:32 +0000

Everyone optimizes the wrong variable.

Cheaper models.
Shorter prompts.
Compressed context.

That all helps a little.

But look at Anthropic's rate card instead, and one asymmetry jumps out: output tokens cost 5x input tokens on every current model. Claude Fable 5 is $10 per million tokens in, and $50 per million tokens out.

Which means the most expensive thing your AI agent does is write code as output.

Magic is architected so it doesn't.

And rather than argue this in the abstract, we let Claude build a complete full-stack app on our hyperlambda.dev cloudlet — while measuring everything.

The rate card, straight from Anthropic

These are Anthropic's official API prices, per million tokens, fetched from their pricing documentation on August 6, 2026:

Model	Input	Output
Claude Fable 5	$10	$50
Claude Opus 5 / 4.8	$5	$25
Claude Sonnet 5 (intro, through Aug 31)	$2	$10
Claude Sonnet 4.6 / Sonnet 5 (from Sep 1)	$3	$15
Claude Haiku 4.5	$1	$5

Two things are worth staring at.

First, the output multiple is universal. Every tier charges 5x more for what the model writes than for what it reads.

Second, Anthropic's newer tokenizer — used by Claude 4.7 and later — produces roughly 30% more tokens for the same text. Round-tripping source code through a model's context literally got more expensive this year.

Prompt caching and the Batch API can discount those rates. But a discount on waste is still waste. The interesting question is why the tokens are being spent at all.

Where a coding agent's tokens actually go

A conventional coding agent building a backend runs a loop.

Read files. That is input.
Write code. That is output, at 5x.
Read the error. Input again.
Rewrite. Output again.
Re-read to verify. Input again.

Every debug iteration compounds, and the compounding happens at the most expensive rate on the card. The model is not reasoning in most of those moments. It is acting as a very costly transport layer for source code.

I have written before about how Hyperlambda changes these economics and measured roughly 80 percent savings on a Fable-priced build. This article is about the mechanism underneath those numbers — and a fresh build with its own receipts.

What we built to prove it

We asked Claude to build Token Ledger: an LLM spend tracker.

Yes, that is deliberately meta. Claude built a token-cost dashboard while its own token cost was being metered.

The deliverable: a SQLite database with three linked tables — providers, models, and a usage log — seeded with Anthropic's actual rate card from the table above. Fifteen HTTP endpoints, every one of them role-secured. Two aggregation endpoints feeding charts. And a designed, dark, authenticated dashboard.

Look at the dashboard's own numbers for a moment. The second KPI card reads "output share of spend: 37%" — on a realistic mixed workload, over a third of the bill is output tokens. And the spend-by-model chart shows Fable 5 dwarfing everything else, because at $50 per million output tokens, it does.

The app is arguing the article's thesis from inside the screenshot.

The build ledger

Wall-clock time was measured with timestamps, not estimated.

What	Number
Live secured backend — database, schema, seed data, 15 endpoints	222 seconds
Complete working app, including the hand-written frontend	431 seconds
Backend lines of code generated	669
Backend lines of code hand-written	0
Claude output tokens spent on backend code	0

The last row is the entire article.

The backend was produced by twelve calls to Magic's CRUD generator and three calls to its SQL endpoint generator. Each call is a compact declarative argument — a table name, a column list, a role restriction, an SQL statement. Around a hundred tokens each, roughly 1,500 tokens of arguments in total.

Not one of the 669 generated lines passed through Claude's output stream at $50 per million tokens. The platform wrote them, server-side, using the same battle-tested generators the Magic dashboard uses.

Honest scope on the numbers: the 222 seconds include reading the platform's guides and setting up the design tokens. Screenshots and end-to-end verification came after the 431-second mark and included two pauses waiting for human tool approval, so they are excluded from the build figures.

That login screen is not decoration. Every endpoint behind it is gated by Magic's built-in RBAC — no hand-rolled JWT handling anywhere, because there is no hand-written backend anywhere.

The five mechanisms

Why does this architecture starve the token meter? Five reasons, each visible in the build above.

1. Declarative calls replace emitted code

One CRUD-generator call is roughly a hundred output tokens of arguments. It produces a complete endpoint — paging, sorting, filtering, validation, auth — of sixty to a hundred and twenty lines. Streaming the equivalent as source code is thousands of output tokens, usually across multiple attempts. In this build, 1,500 tokens of arguments bought 669 lines of backend.

2. Code generation happens server-side

When something bespoke is needed, Magic's Hyperlambda Generator takes a plain-English prompt and writes the file on the server. The code never enters Claude's output stream or its input stream. Claude pays for a sentence, not a source file. And here is the stronger version of that point: this particular build needed zero generator calls. The declarative tools covered the entire backend.

3. Code never round-trips through context

Magic's operating rules forbid the agent from reading generated Hyperlambda back. Verification goes through live HTTP invocation and the OpenAPI spec. A conventional coding agent re-reads its files constantly — every read is input tokens, every edit is output tokens. On Magic, that loop is not discouraged. It is structurally impossible.

4. No debug spirals

The generators are deterministic. There is no generate, error, paste-the-stacktrace, regenerate cycle — the invisible multiplier on every agent bill. This build's complete bug ledger: one entry, a headless-browser viewport quirk while taking screenshots. Zero bugs in 669 generated backend lines.

5. One-call grounding

At session start, one call returns who the agent is, what backend it is on, and its full operating instructions. One more call returns the exact list of capabilities that exist on the instance. Compare that with an agent grepping directories and reading files to discover what a codebase can do — all of it billed as input, none of it producing anything.

The accounting: same app, two architectures

Take the same deliverable — the Token Ledger backend, fifteen secured endpoints — and price both paths at Anthropic's current rates.

The Magic column is this build. The coding-agent column is a calibrated estimate for the same result via a conventional file-editing agent — scaffold, routes, auth, validation, and the customary debug loops — consistent with the roughly 140,000-versus-25,000-token gap measured in the July benchmark, with the backend-code share broken out.

	Claude on Magic (measured shape)	Claude with generic tooling (estimate)
Output tokens spent on backend code	0	~30,000
Total output tokens, backend slice	~2,000	~35,000
Total input tokens, backend slice	~30,000	~180,000
Cost at Fable 5 ($10 / $50)	≈ $0.40	≈ $3.55
Cost at Opus 5 ($5 / $25)	≈ $0.20	≈ $1.78
Cost at Sonnet 4.6 ($3 / $15)	≈ $0.12	≈ $1.07

Call it roughly 9x on this app, and the estimate columns are labeled as exactly that — estimates. The ratio is not a constant of nature. It is a consequence of one design decision: source code, the most expensive thing a model can emit, never enters the token stream.

And notice what happens as the app grows. A CRUD-generator argument is about a hundred tokens whether the table has three columns or thirty. Hand-written code is not. The gap widens with size.

Where 10x holds — and where it is 5x

Now the honest fine print.

The July benchmark measured roughly 80 percent — 5x — across a full session, because a real session also contains reasoning, planning, schema decisions, and verification, and those do not compress. The frontend in this build was hand-written by the agent, at normal output rates, and took as long as the entire backend.

The 10x figure belongs to the code-emission slice of the work: the backend, the endpoints, the auth, the data layer. On backend-heavy agentic workloads that slice dominates, and the blended number climbs toward it. On reasoning-heavy work, expect the 5x, not the 10x.

Both numbers are worth having. Neither requires exaggeration.

Conclusion

The standard advice for cutting Claude costs is to pick a smaller model, cache your prompts, and batch your jobs. All fine. All discounts on the same architecture.

Magic changes the architecture. The agent stops being a code emitter paying $50 per million tokens for the privilege, and becomes an operator of a platform that already knows how to build backends — declaratively, server-side, with security enforced by the runtime instead of regenerated per project.

We measured it: a live, role-secured, fifteen-endpoint backend in 222 seconds, 669 lines generated, zero lines through the token meter.

Claude is a great engineer. Stop paying it by the line.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

Originally published at hyperlambda.dev.

Break my AI Sandbox and make $100 - Psst, nobody's done it yet!

Thomas Hansen — Sat, 01 Aug 2026 10:10:45 +0000

I have a standing offer: find a verified security bug in Magic's backend — the C# code or the Hyperlambda runtime — and I'll pay you $100.

Nobody has collected.

$100 is obviously not the point. Companies pay 100 times that for bounties on software with a fraction of the attack surface. The point is that I'm willing to put money on the architecture, publicly, permanently — because the architecture is the product.

The runtime is the security boundary

Most AI coding tools work like this: the model generates free-form code, and you hope it generated something safe. The model is the security boundary. Which means every prompt injection, every hallucination, every "ignore previous instructions" is a potential breach.

Hyperlambda inverts this. The AI generates code, but the runtime decides what executes:

Hyperlambda is not free-form code. It's a declarative structure that parses into an AST, and the runtime validates that AST before anything runs.
Slots are whitelisted. If a slot isn't on the whitelist for the current context, it doesn't execute. Period. The AI can hallucinate whatever it wants — the runtime says no.
RBAC is enforced at execution time, not generation time. It doesn't matter what code was generated or by whom. If your JWT doesn't carry the role, the invocation is refused.

If the AI writes something it shouldn't run, the runtime says no. That single sentence is the difference between a demo and something a regulated company can ship.

Receipts

I don't expect you to take my word for it. In April I let Claude Code — one of the strongest code-analysis agents available — loose on the entire Magic codebase with explicit instructions to break it.

It found real issues. All hardening, none sandbox escapes:

No cap on request body size, allowing a memory-exhaustion DoS. Fixed.
Missing timeouts that left the server exposed to Slowloris-style slow-drip attacks. Fixed.
An edge case in path resolution that needed an explicit traversal guard. Fixed.
A debug statement leaking information to the console. Removed.

And here's what it couldn't do, after crawling roughly 9,000 commits accumulated over some 7 years:

No SQL injection. Every database access goes through parameterized ADO.NET.
No password extraction. BCrypt with per-user salts.
No secrets leakage. AES-GCM for storage.
No auth bypass. Standard JWT, correctly implemented.
No sandbox escape. Every attempt to execute something outside the whitelisted slots was refused by the runtime.

The full write-up is here: Claude Code tried to break Magic Cloud, and mostly ended up confirming its security.

Why free-form codegen can't make this offer

Think about what it would take for an AI agent platform built on free-form code generation to make the same offer.

They'd be paying out daily. When the model is the boundary, one clever prompt is a breach. The industry's answer so far has been layers of prompt-level guardrails — instructions asking the model to please behave. That's not security. That's etiquette.

When the runtime is the boundary, the model's behavior becomes almost irrelevant to your security posture. The model can be jailbroken, poisoned, or just plain wrong — and the blast radius is a refused invocation and a log entry.

This is why I can put a standing bounty on it. The security claim isn't "our AI is well-behaved." The claim is "the runtime refuses everything that isn't explicitly allowed." That's a falsifiable, testable claim — so go test it.

How to collect

Go to playground.hyperlambda.dev and hammer it. Or self-host — the whole thing is MIT licensed, so you can read every line of the code you're attacking.
Find a verified bug in the backend C# or Hyperlambda code. Sandbox escape, RBAC bypass, executing a non-whitelisted slot — anything that breaks the security model.
Send it to me. I verify it, I fix it, I pay you $100, and I'll publicly credit you for the find.

Prompt-level shenanigans against the AI itself don't count — making a chatbot say something silly is not a runtime breach. The claim under test is the runtime.

If you're evaluating AI agent platforms

Ask every vendor you're talking to one question: what happens when the AI generates something it shouldn't?

If the answer involves the words "the model is trained to" or "our system prompt instructs" — you're buying etiquette, not security. If the answer is a deterministic runtime mechanism you can read the source code of, you're buying engineering.

Magic has been running in production since 2020. It's MIT licensed. The code is at github.com/polterguy/magic, and the docs are at docs.ainiro.io.

Break it and make $100. Psst — nobody's done it yet.

Originally published at hyperlambda.dev.

Turn Your Legacy SQL Server Database into a Modern Full Stack App in Minutes

Thomas Hansen — Fri, 31 Jul 2026 20:42:35 +0000

The app in the screenshots below took 7 minutes to build.

Not a mockup. A login screen backed by JWT authentication, a client manager reading and writing through a role-secured CRUD API, and an Emails tab that dispatches real messages over SMTP. The backend was produced by wrapping a database in generated CRUD endpoints, plus one English sentence handed to the Hyperlambda Generator for the send-email endpoint.

I have published the receipts for builds like this before, so this article is not another ledger.

It is about the part of those 7 minutes that usually gets lost.

The database was the boring part

Nothing in the build depended on the database being new.

The CRUD generator does not care where a schema came from. It reads metadata — tables, columns, types, keys — and every Microsoft SQL Server database on earth exposes exactly that. The database in this demo was created seconds before the endpoints were. Yours carries twenty years of history, three generations of developers, and foreign keys that encode how your business actually works.

Same metadata. Same generator. Same 7 minutes.

That is the entire point. The demos always run on fresh databases because demos need reproducibility — but the machinery only ever sees the schema, and your ERP on SQL Server has a better schema than any demo. The hard part of a full stack app — modelling the business correctly — is the part you finished years ago.

What got built

The front door. JWT authentication against the platform's built-in auth — no auth library, no password hashing code, no session plumbing anywhere in the app.

The client manager. Search, add, edit, delete, and per-client notes — every operation travelling through generated CRUD endpoints, each one gated on a role before any logic runs.

And the one endpoint that is not a table projection: composing an email to a client, dispatched through the platform's SMTP integration. That endpoint was described in a single English sentence and generated in seconds — the application never saw a mail-provider credential, because there is none in the application.

The recipe

Four moves.

Connect the database. Magic speaks to SQL Server through the standard .NET data provider — it is one more client, nothing installed inside the database, no schema changes.

Wrap the tables. The CRUD generator reads the schema and emits endpoints — read, create, update, delete, count — with authentication and role-based access control already wired in.

Describe what CRUD cannot do. "Look up this client's email address and send them a message" is one sentence, and the Hyperlambda Generator turns it into a working, role-gated endpoint.

Serve the frontend. The same system that serves the API serves static files, so the app's HTML, CSS and JavaScript went live the moment they were written. One host, no CORS, no separate deployment.

The full walkthrough — scoped database users, read-only starts, connecting an agent over MCP — is its own article: Create an AI Agent From Your SQL Server or MySQL Database, Step by Step.

No agent required

This build ran through an AI agent over MCP, but the CRUD wrap does not need one. The dashboard's Backend Generator does the same thing point-and-click: pick the database, tick the tables, choose which roles may call what, and click Generate.

Same generated endpoints, same enforcement, no conversation required. The agent is a convenience, not a dependency.

"But my database is legacy"

Legacy means load-bearing, not obsolete — I have made that argument at length in Supabase for SQL Server and MySQL, so here is the short version.

You connect through a scoped database user, so the platform can never do more than the credentials the DBA granted. You can start read-only, which turns "what if something writes the wrong thing" into a non-question for day one. And the whole stack runs in two containers you place yourself — same rack, same VLAN, same firewall the auditors already approved. The database does not change, and the data does not leave.

The fine print

Seven minutes was measured for this schema, at this size. Your 200-table ERP will take longer — but the added time goes into decisions, not code: which tables deserve exposure, which operations each table gets, which roles may call them. Those are judgment calls a DBA is already equipped to make, and they were never the expensive part.

The frontend is where human taste still spends its time. Generated backends are uniform; good interfaces are not.

And writes deserve the same respect they have always deserved. Start read-only, prove the surface, then grant writes table by table. The speed changes nothing about the discipline.

The question worth asking

The question is no longer whether your organisation can afford to modernise the systems built on SQL Server. It is whether wrapping one of them in a secured API and a working app is still a project at all — or just an afternoon.

Magic is MIT-licensed and open source at github.com/polterguy/magic, with documentation at docs.ainiro.io.

46,000 Lines of Angular, Gone in a Weekend

Thomas Hansen — Mon, 27 Jul 2026 07:14:31 +0000

I replaced the entire Magic Cloud dashboard this week. Forty-six thousand lines of Angular — HTML, TypeScript and CSS — gone, and in its place a React application of fifteen and a half thousand lines that does more than the thing it replaced.

Twenty hours of coding. Thirty hours in total, counting my own reviewing, testing and swearing.

I know exactly what that job costs when you do it by hand, because I have already done it by hand. In 2021 I rewrote this same dashboard the traditional way. A senior developer worked on it for a month and a half. Then I picked it up and worked on it for months more. Call it a three-month job for two experienced developers who knew the domain cold.

That comparison is the only reason this article is worth writing. Anyone can claim an AI wrote a lot of code quickly. Very few people have the same application, built twice, by the same author, with the same requirements — where the only variable that changed is the tooling.

The ledger

	Then	Now
Framework	Angular	React 18 + Vite + TypeScript
Lines of code	~46,000	15,497
Files	many hundreds	47
Runtime dependencies	the Angular universe	7
Production build	tens of MB	856 KB
Build time	minutes	~1 second
Time to write	~3 months, two people	30 hours, one person supervising

A word on that line-count comparison, because it is the kind of number people rightly poke at. Angular splits a single component across a .ts file, an .html template and an .scss stylesheet. React folds all three into one .tsx. Counting the old TypeScript against the new TypeScript would flatter me dishonestly, so both sides count everything: markup, logic and styling. Forty-six thousand against fifteen and a half.

The dependency line matters more than it looks. The whole application runs on React, React-DOM, React Router, CodeMirror, SignalR, marked and DOMPurify. That is the entire third-party surface. There is no state management library, no component library, no CSS framework, no build plugin zoo. When your dependency list fits in one sentence, upgrades stop being events.

How it actually ran

I drove Claude — Fable for the bulk of the work, Opus for the parts that needed more thinking. The model wrote essentially all of the code. My job was to babysit: sanity-check what came back, test it in a browser, catch the things that were confidently wrong, and decide what to build next.

The loop that made it work was not "describe the feature and hope." It was: screenshot the old Angular screen, build the new one, screenshot the new one, compare them, fix the gap. Verification happened against rendered pages, not against source code. That distinction matters, because a model reading old Angular source will faithfully reproduce old Angular mistakes. A model looking at what the screen actually does will build what the screen actually does.

Below is what came out of that loop, screen by screen — because the interesting claim is not that thirty hours produced code, it is that thirty hours produced this much working software.

Login

The dashboard talks to any Magic backend, so the first thing it needs is which one. The backend selector remembers every cloudlet you have ever signed into and keeps a separate JWT for each, so switching between them does not mean signing in again.

Underneath the password field are two things the Angular version never had. Magnetic link sends a temporary sign-in link to your email — it doubles as passwordless login, and it only appears if the backend actually has SMTP configured, because offering it otherwise is a dead end. Continue with Google signs you in over OIDC against whatever providers the backend has registered. Both were built during this port, not ported into it.

Dashboard

The landing screen answers "what is this cloudlet, and is anything wrong with it" in one glance: version, endpoint count, users, tasks, log items.

Two panels below that are new. The first announces that your cloudlet is an AI agent — with the MCP plugin installed, the URL shown there hands any MCP-capable agent your endpoints as callable tools. Claude, or anything else speaking the protocol, can discover and invoke them directly.

The second is the Chatbot Wizard, which runs the other direction: give it a website, pick a model and a persona, and the backend crawls the site, turns what it finds into training data, and gives you an embeddable chatbot grounded in your own content. The crawl takes minutes and reports progress over a SignalR channel, so the feedback window opens before the job starts — a socket that connects late misses the first messages. You can close the window; the crawl carries on.

Hyper IDE

The file manager and code editor for everything on your server, and the component that absorbed the most work.

The tree browses the whole backend file system. Files open as tabs, several at once, and each tab tracks whether it is dirty — a dot appears on the tab and beside the path in the header the moment you change something, and navigating away asks before discarding it. The editor runs a Hyperlambda mode ported from the old dashboard, so slot invocations are coloured correctly, and Ctrl+Space completes against the backend's actual vocabulary — the list of slots is fetched from the server you are connected to, and cached per backend, because two cloudlets with different plugins know different slots. That is the popup in the screenshot above, listing the log.* slots this particular cloudlet knows about.

Executing a file is smarter than it was. If the file is a real HTTP endpoint — it ends in .get.hl, .post.hl and friends, and lives under /modules/ or /system/ — the IDE invokes it as an endpoint, with arguments, and shows you the status code and response headers. Only files that are not endpoints get evaluated directly. You can upload and download files, preview HTML, XML, images, JavaScript and CSS straight from /etc/www/, and press F1 on any selection to ask the AI what it does.

Playground

Hyperlambda, executed on your server, without saving anything first. Input on the left, result on the right, F5 to run. It is the scratchpad you reach for when you want to know what a slot actually returns, and it saves snippets when the scratch turns out to be worth keeping.

SQL Studio

Two tabs over the same three selectors: database type, connection string, database.

The SQL tab is a query editor with syntax colouring, Ctrl+Space completion over your real tables and columns, saved snippets, .sql import, CSV export of results, and a Safe mode toggle that caps what a careless query can do. Selecting part of the text executes only the selection.

The Designer tab is the one I am quietest about and proudest of. It renders every table in the database as a card — primary keys, column types, nullability, and the foreign keys spelled out underneath — and lets you add tables, add columns and wire up relations without writing DDL. It will also hand you the DDL for a single table or the whole database if you would rather write it yourself.

Databases

Create SQLite databases, back them up, restore them from an uploaded backup, delete the ones you no longer need — and, on the second tab, connect to external MySQL, PostgreSQL and SQL Server instances. Everything else in the dashboard then treats those exactly like a local database.

Generator

Point it at a database, tick the tables, and it writes you a complete CRUD backend: POST, GET, PUT and DELETE per table, with paging, sorting, aggregates, distinct and search endpoints if you want them. You choose which roles may call what, whether writes are logged, how long GET responses may be cached, and whether existing files may be overwritten. The second tab wraps a custom SQL statement in an endpoint of its own.

This is the part that turns a schema into a secured API in seconds, and it is why the backend is rarely where the time goes.

Endpoints

Every endpoint on the backend, grouped by module, with its HTTP verb. Open one and you get a form built from its actual arguments — fill them in, invoke it, and see the status code, the response headers and the body rendered according to its content type.

It handles files in both directions now, which it did not before: endpoints that accept multipart/form-data get a proper file picker with image thumbnails inline, and endpoints that return files offer them as downloads. Each module will also hand you its OpenAPI specification, which is how you point an external tool — or an agent — at a subset of your API.

Users and roles

Who may reach your backend, and what they may do. Create users, assign roles, change passwords, lock accounts. Roles are the same objects the Generator gates endpoints with and the same ones inside the JWT, so this screen is the authorisation surface for the entire platform in one table.

Task Manager

Hyperlambda that runs on a schedule or on demand — backups, cleanup jobs, crawls, alerts. Tasks can repeat on an interval, fire once at a fixed date, or follow a custom repetition pattern, and you can execute any of them immediately to see what happens. Executing asks first, because a task named delete-old-log-items means it.

Machine Learning

The largest single screen in the application, at two thousand lines. Models define which LLM answers, at what temperature, with what system message and what threshold. Training data is the content those models answer from — crawled from a site, uploaded as files, or written by hand. Vectorising turns it into embeddings; embedding hands you the snippet that drops the finished chatbot onto a web page. A history tab shows what people actually asked it.

Plugins

The Bazar: MCP, OAuth, OpenAI, Ollama, HuggingFace, Shopify, HubSpot, NetSuite, scraping, charts, and a couple of dozen more. One click installs a module into your cloudlet, endpoints and all. You can also install your own from a ZIP file.

Profile

Your name, your email, your password — and access tokens, which is the part that matters operationally. Generate a long-lived JWT for a service account, a CI pipeline or an integration, scoped to the roles you pick and expiring on a date you choose.

Log

What your backend has been doing, newest first, filterable, with severity on every row. It is where you go when something did not work, and the generated CRUD endpoints write to it automatically when you ask them to log writes.

What got better, not just moved

If this had been a straight translation I would not have bothered writing about it. The features that did not exist in the Angular version, all built inside those same thirty hours:

OIDC login — sign in with Google or any registered provider
File upload and download through the Endpoints screen, with inline image previews
Dirty-file tracking across Hyper IDE, SQL Studio and the Playground
Multiple files open at once, as tabs
Multi-backend support with a separate JWT per cloudlet and shareable ?backend= links
Magnetic-link login for passwordless sign-in
The MCP agent banner and the Chatbot Wizard
Previewing HTML, XML, images, JavaScript and CSS from /etc/www/
An AI support agent on F1, answering from the Hyperlambda and Magic documentation

The bug ledger

Two rules make this kind of build survivable: the model writes, and a human reviews everything before it lands. Here is what the review caught.

React's StrictMode caused three separate bugs. It deliberately runs effects twice in development, which broke an image preview (the object URL was revoked before the image loaded), killed a SignalR connection (started and stopped in the same tick), and made two stacked dialogs land on the same z-index. All three were the same root cause wearing different hats, and all three were found by looking at the screen, not the code.

The model invented a slot that does not exist. It used date.add for date arithmetic. There is no such slot. The fix was math.add with a time node — the pattern already used elsewhere in the codebase.

It invented a role, too. It gated the dashboard on an admin role. The backend has 159 endpoints and every one of them checks root. Caught during review, renamed everywhere.

A mail endpoint was built with the wrong node shape, which produced a runtime error rather than an email. A magnetic link took three attempts to redirect correctly, because the token was being stripped from the URL before a second render could read it. An expired token walked straight into the dashboard, because expiry was being checked without asking the server whether the token was still valid.

And two mistakes the model made about its own work, which I include because they are the most instructive of the lot. It told me one screen had no confirmation dialog before running a destructive task — it had searched the code in a way that could not have found the guard, which was sitting six lines above what it read. And it told me a screenshot I had pushed did not exist, when the file was recoverable the whole time. Both were confidently wrong, and both were wrong in the same direction: reporting an absence after looking in the wrong place.

Nothing on this list shipped. But the list is the honest cost of the method, and anyone telling you their AI build had no such list is not counting.

What this actually demonstrates

It would be easy to read this as "AI writes code fast." That is not the finding, and it is not what changed.

The expensive part of the 2021 rewrite was never typing. It was reading the old implementation to work out what a screen did in the edge cases, holding forty-odd screens' worth of behaviour in your head, and checking parity one control at a time. That is the part that compressed. The model does not get bored on screen thirty-one, and it does not skip the tedious parts of the Machine Learning page because the Dashboard was more fun.

What did not change is who is responsible. I reviewed everything. I found the invented slot, the invented role, and the token that should not have been trusted. The ratio moved; the accountability did not. Thirty hours with a competent reviewer is not the same thing as thirty hours unattended, and I would not claim otherwise.

Three months to thirty hours, on the same application, by the same person. That is the number I would want to see from someone else before I believed any of this, so it is the number I am publishing.

Magic is MIT-licensed and open source — the repository is at github.com/polterguy/magic, with documentation at docs.ainiro.io.

DEV Community: Thomas Hansen

My MCP server technically has 10 to the power of 1204 number of integrations! Try it for free here!

The joke has a serious spine

One integration to rule them all

Try it, free, right now

Ask it one thing first: "Return server vocabulary"

Now try to make it misbehave

The honest edges

Run your own

Frequently asked questions

How can one MCP endpoint replace many integrations?

How do I connect an AI agent to the free endpoint?

What should I ask the endpoint first?

Is the free endpoint safe to let an agent loose on?

Related reading

Our Integration Count Has 4,196,703,834 Digits

The numbers, as published

Three things I found while counting

Make would not let me count

So what is Magic's number?

A catalogue is a list of things somebody already built for you

Funny math, with the working shown

It is larger than every particle in the universe, and that is not a figure of speech

The part that is not funny math

English, Swedish, or Urdu

Where these platforms genuinely win

The decision rule

The fine print

Frequently asked questions

How many integrations does Magic have?

Which platform publishes the most integrations?

Why do Airbyte's and Workato's integration counts contradict themselves?

Does Supabase have integrations?

Can you create an integration without writing code?

Is Magic's integration count really bigger than the number of particles in the universe?

What happens when an integration is not in the catalogue?

Related reading

Masturbation Is 100 Times More Dangerous Than AI

The comparison

The limitations

Other unusual causes of death

Bee, wasp and hornet stings

Cattle

Lightning

Furniture and televisions

Vending machines

Falling coconuts

Why the comparison is useful

Your sitemap is an API — a whole website as one JSON document in 35 lines

What comes back

The entire backend

The parts worth stealing

What it will not do

The part I actually find interesting

Try it

I built 9 free web tools and printed the entire backend on every page. What should number 10 be?

The nine

What "the whole backend" actually looks like

They're also MCP tools

The honest limits

So — what should number 10 be?

Magic vs Directus: An Honest Feature Matrix

The matrix

Where Directus wins, stated plainly

Where the bets diverge

The decision rule

The fine print

FAQ

Is Magic Cloud a Directus alternative?

Is Directus open source?

Is Directus free?

Which handles a large legacy schema better?

Can AI agents use both?

Related reading

From Prompt to MCP Tool in 5 Seconds

The measured run

There is no second step

Your prompt is the tool description

So write the prompt like a docstring

The honest edges