When Self-Hosted AI Makes Sense for a Belizean Business

Several of the systems I run now have an AI feature somewhere in them. A chat assistant on a hotel website that answers questions about rooms and policies. A draft description written from a few bullet points. A tidy-up pass on messy text before a human reads it. The model doing that work does not live in a data centre in Virginia. It runs on a Linux server I own and maintain in Belize, and that arrangement has a name: self-hosted AI.

This post is about when that is a sensible choice for a Belizean organisation and when it is not. I will be honest about the trade-offs, because I pay for them myself.

What does self-hosted AI actually mean?

A language model is a large file of learned numbers that turns text you give it into text it predicts should follow. Normally you rent access to one. You send your text over the internet to OpenAI, Anthropic or Google, they run the model on their hardware, and they bill you per token, which is roughly a chunk of a word, in and out.

Self-hosted means the model file sits on a computer you control, and the text never leaves that computer. No per-token bill. No third party holding your prompts. The cost moves from a monthly invoice to hardware, electricity and somebody's time.

What I run, and why

I run a service I call colibrì. It is an API, an interface other programs call over the network, and it is OpenAI-compatible, meaning it speaks the same request format that most AI tools and libraries already expect. That compatibility matters more than it sounds. It means any application written against the common standard can be pointed at my server by changing one address, and pointed back again if I ever want to.

Behind that single door sit two very different models.

• A small fast model. Qwen 2.5 at 3 billion parameters, served with Ollama, a program that loads and runs models locally. It answers in seconds. This is what powers website chat assistants, classification work such as sorting messages into categories, and first drafts.
• A very large slow model. A GLM model with hundreds of billions of parameters, far more capable and far heavier. It takes minutes per answer on my hardware, so it is used asynchronously, meaning the job is queued and the answer collected later rather than waited on.

The caller chooses the model per request. An API key, a secret string that proves the caller is allowed in, guards the door. Applications running on the same box call it locally. Anything outside connects over TLS, the encryption that puts the padlock on a web address.

Is self-hosted AI cheaper than paying per token?

For routine, high-volume, low-stakes work, yes, and the saving is not really about the unit price. It is about predictability.

A website chat assistant that answers the same twenty questions all day, a classifier that reads every incoming enquiry, a nightly job that summarises records: these are tasks where usage grows with traffic, and a per-token bill grows with it. On my own hardware, the cost of the thousandth request in a day is the same as the first, which is nothing.

For a few dozen carefully written pages a month, self-hosting saves almost nothing and you should just pay for a hosted model. The hardware is the floor cost, and a light workload never climbs above it.

Three reasons that are not about money

1. Data stays in-country. Student records, payroll figures, loan files, guest details. For some organisations, and some boards, the sentence "that text never leaves our server" is the whole argument, and I can say it truthfully.
2. It works when the foreign API does not. Accounts get suspended, cards get declined, services change terms, regional availability shifts. A model sitting on a disk in Belmopan does not care.
3. No usage anxiety. When the marginal cost is zero, people experiment. Features get built that nobody would have authorised at a cent per call.

What are the real trade-offs?

I am not going to pretend this is free.

Hardware. A machine capable of serving a large model is a real purchase, and it is a capital cost up front rather than a small monthly one.

Speed and quality. The small local model is quick but it is a 3 billion parameter model, and it writes like one. It is fine for structured tasks and short answers, and it is not fine for a letter to your bank. The large local model is genuinely strong and genuinely slow, which rules it out for anything a person is sitting and waiting for.

Maintenance. Somebody has to patch the operating system, watch the disk, restart the service when a model update goes sideways, and keep the network sane. That is the same discipline as the rest of the infrastructure I run, which I have written about in a small office stack that survives Belize, and it does not maintain itself.

Hosted or self-hosted: a short comparison

| Task | What I use | | --- | --- | | Website chat assistant, high volume | Local small model | | Sorting or tagging incoming text | Local small model | | First drafts, rough summaries | Local small model | | Hard analysis, no deadline | Local large model, run asynchronously | | Public-facing writing where quality decides the outcome | Hosted frontier model | | Anything touching data that must not leave Belize | Local, always |

The honest answer in practice is hybrid. I use hosted frontier models, the best commercially available ones, when the quality of the words matters more than anything else. I use local models for everything else. Building against an OpenAI-compatible API is what makes that switch a configuration choice rather than a rewrite.

A checklist before you commission anything

Run through these five questions. If you answer yes to three or more, self-hosted AI is worth costing out.

• Does the work involve data your organisation is not comfortable sending to a foreign company?
• Is the AI task repetitive and high volume rather than occasional and bespoke?
• Would a good-enough answer in two seconds beat a perfect answer in twenty?
• Do you already run, or already need, a server for other reasons?
• Would an unexpected monthly bill be a genuine problem for your budget?

If you answered no to most of them, buy hosted access and spend the money you saved on getting the rest of the system right.

Where to start

1. Write down the actual task. Not "we want AI". Something like "answer the forty questions guests ask before booking" or "sort two hundred enquiries a week into four categories".
2. Decide what the data is. Public marketing text and confidential records lead to different answers, and that decision drives everything else.
3. Estimate volume. Ten requests a day or ten thousand. That number alone usually settles the hosted-versus-local question.
4. Pilot against a hosted model first. It is faster to prove the idea works when you are renting, and if it is built properly the move to your own server later is a change of address.
5. Budget for the boring part. Backups, monitoring, patching, and whoever is responsible when it stops. This is part of the services I provide, and it is also the part people forget to plan for.

If you are weighing this up for your own organisation and want a straight opinion on whether it is worth it, you are welcome to get in touch.