Why we built freeport

There is a moment, early in every project that touches a language model, where the thing just works. You send a few messages to an API, you get something coherent back, and it feels like magic. That moment is real, and it is also a trap. Because the moment is the easy part. The hard part is everything that has to be true for that call to keep working at 3am, for the hundredth team, under a budget, inside a company that has rules.

freeport exists for the hard part.

The call is not the system

When people say they are “using an LLM,” they usually mean they are making an HTTP request to a provider. But a request is not a system. A system has to answer questions the request never asks:

• What happens when the provider returns a 529 in the middle of a deploy?
• Who is allowed to spend how much, and what stops a runaway loop from burning a month of budget in an afternoon?
• When a prompt contains a social security number, does it leave the building?
• Six months from now, when someone asks what the model was told and what it said, is there a record?

None of these are interesting problems in the way that prompting is interesting. They are load-bearing problems. They are the difference between a demo and something you can put your name on. And they are remarkably similar across every team that hits them, which is exactly the property that makes them worth solving once, in the open, instead of a thousand times in private.

Boring on purpose

freeport is a self-hosted, OpenAI-compatible gateway. You point your existing SDK at it, change the base URL, and keep your code. Behind that unchanged interface it does the unglamorous work: multi-provider routing with fallback and a circuit breaker, a semantic cache that runs on local embeddings so similar prompts do not pay twice, hard budget caps with a kill switch, PII detection, audit logging, and provider keys encrypted at rest.

We deliberately did not build a hosted product first. A hosted gateway is another company in the path of your prompts — another vendor who sees your traffic, another per-request tax, another trust relationship to manage. The teams who feel these problems most acutely — the ones under GDPR, HIPAA, the EU AI Act — are precisely the teams who cannot route their data through a stranger’s cloud to solve them. So freeport is a single container you deploy where your data already lives. Your prompts never leave your infrastructure. That is not a feature; it is the whole point.

”Artificial” means made

The name of this org is a small joke with a serious center. Artificial does not mean fake. It means made — built with intent, by hand, on purpose. The generation step gets all the attention because it looks like the system thinking. But the part that actually decides whether you can trust the thing is the part nobody demos: the routing table, the retry logic, the redaction pass, the line in the audit log.

We would rather build that part. It is less photogenic and more useful, and useful compounds.

Where it stands

freeport is published, MIT licensed, and real. You can read every line, run it on your laptop, and disagree with our choices in a pull request. There are no usage numbers on this page because we have not earned the right to quote any yet, and we would rather show up with a working container than a fabricated chart.

$ npm i -g @reallyartificial/freeport

Or clone the repo and docker compose up. The gateway and its admin UI come up together. Point an OpenAI SDK at it and the demo moment still happens — but now there is a system underneath it.

That was always the goal: keep the magic, and make it safe to depend on.