AI · A product we built, and models that run in your building

Two ways to buy AI from us, and they are not the same thing.

One is a finished product you can use this afternoon: an AI video service we built, charged per clip with no subscription. The other is an engagement: open-weight models on hardware in your own building, doing retrieval over your own documents, with nothing leaving the premises and no per-token bill.

In short

What AI does ZYNTEIRO provide?

Two distinct things. OpenReel Studio is ZYNTEIRO's own AI video generation service at openreel.studio — describe a shot or bring reference images, clips and audio, and get a finished video back in minutes, charged per clip from prepaid credits with no subscription. On-premise AI is the opposite arrangement: open-weight models on hardware inside your own building, running retrieval over your internal documents, with no data sent to a third party and a cost per question of electricity rather than tokens.

A product we built · Paid by the clip

Generate the video you are picturing.

Our own AI video generation service, live and paid. Describe the shot, or hand it reference images, clips and audio, and it returns a finished video. The price of a generation is shown before it runs.

01

Pay per clip, not per month

Prepaid credits, one credit to one US dollar, no subscription and no monthly minimum. You see what a generation costs before you commit to it, so the bill is never a surprise at the end of a month you were experimenting in.

  • 1 credit = 1 US dollar
  • No subscription, no minimum
  • Cost shown before generation
02

Bring your own subject

Up to nine reference images, three reference clips of fifteen seconds each, and three reference audio tracks per generation. A subject you use often is saved as a character and reused, so a set of clips looks like it belongs together.

  • 9 reference images
  • 3 clips, up to 15s each
  • 3 audio tracks
  • Saved characters, reused
03

The output is yours

You own what you generate, OpenReel claims no ownership of it, and it is not used to train models. Commercial use is included. What you still have to get right is the rights to whatever reference material you bring.

  • You own the output
  • Not used for training
  • Commercial use included

AI that runs in your building

Open weights, real hardware, honest limits.

The reason to run a model on your own hardware is almost never that it is better. It is that the data cannot leave, the cost per question is zero, and nobody can deprecate it out from under you.

None
Data leaving the building
The weights and the documents are both on your machine. There is no outbound call to switch off. Three honest reasons
Electricity
Cost per question
No API key, no per-token meter, no bill that grows with adoption. The capital is the hardware and it is knowable up front. What it costs
One GPU
Entry hardware
A single workstation-class card serves retrieval over your own documents for a team. Scaling is where the curve turns. Sizing it properly
Retrieval
Best first use case
Search over your own documents, not chat and not "replace a person". The bad first use cases are named in the guide. Where it is oversold

What we actually deploy

Four things, in the order they are worth doing.

Every one of these is normal engineering rather than research. The interesting judgement is the sequencing, and the guide argues the case for each in full.

The server, specified against measured load

A machine sized to what your team will actually ask of it, with the serving stack — vLLM, Ollama or llama.cpp depending on the shape of the workload — installed, monitored and backed up like any other production system. It is a server, and it needs an owner.

  • Sized against a measured workload
  • Monitoring that pages somebody
  • A planned quarterly model refresh

Retrieval over your own documents

The first thing worth building and the one that pays for the hardware: search that answers a question out of your own contracts, manuals, specifications and correspondence, with the source shown so an answer can be checked rather than trusted.

  • Your documents, indexed
  • Answers that cite the source
  • Tested against real questions first
Why retrieval before chat

Agents that act inside your systems

Once retrieval is honest, the next step is letting a model do the mechanical work — extract, classify, stage, draft — inside your own applications. The rule we hold to is that a write is prepared, and a person releases it.

  • Extraction and classification
  • Staged, never auto-committed
  • A named human on every release
Agents, and the GUI agent question

The limits, written down before you buy

Where running it yourself is genuinely worse, which tasks it should not be given, and the honest comparison against simply paying for a hosted one. If the answer for your case is "buy the subscription", we would rather say it before the hardware arrives.

  • A named list of what it is bad at
  • The hosted-model comparison, fairly
  • Permission to conclude no
What you give up by running it yourself

AI inside the ERP

An Odoo assistant that costs nothing per token.

The assistant we run inside zynAIR tenants works against an existing Claude Code or Codex subscription rather than metered API keys. That is the whole design: the cost does not scale with how much the team uses it, which is what quietly kills most ERP AI pilots in month three.

01

It does the mechanical half

Drafting, cross-referencing, staging an import, finding the record somebody described badly. The work that is obviously work and obviously nobody’s favourite part of the day.

02

A person releases every write

Every change it makes is prepared rather than committed. Posting, sending and confirming stay with your own staff inside Odoo, because those are the actions with a consequence attached.

03

The bill does not follow adoption

A subscription rather than a meter means the finance conversation happens once. Teams use a tool they are not being charged by the question to use.

Questions

Before you call.

They solve opposite problems and it is worth being blunt about it. OpenReel Studio is a product we built and run: you sign up, buy credits and generate video on our infrastructure, and nothing about your company needs to change. On-premise AI is an engagement: we specify and install hardware in your building, deploy open-weight models onto it, and connect them to your own documents and systems, so that nothing you feed it ever leaves the premises. One is a subscription-free service you can use this afternoon. The other is a project with a server in it. If your constraint is "we need video", the first. If your constraint is "this data cannot go to a third party", the second.

Yes, and for a good number of Malaysian companies that is the only version worth having. Open-weight models are files: once the weights are on the machine, inference runs against a local GPU with no outbound call, no API key and no per-token meter. The practical consequences are that your cost per question is electricity rather than a bill that scales with use, that nobody can deprecate the model out from under you, and that a network outage does not take the system with it. What you give up is the frontier — the very largest hosted models remain better at hard multi-step reasoning, and we say so rather than pretending otherwise.

Less than most people expect for the first useful thing, and more than most people expect for the ambitious one. A single workstation-class GPU is enough to serve retrieval over your own documents for a team, which is the use case we recommend starting with. Scaling to many concurrent users, long context or larger models is where the cost curve turns. The on-premise guide has the sizing discussion in full, including the part about what the machine will not do.

No, in both directions. On an on-premise deployment the question is close to meaningless — the weights and the documents are on your hardware and we have no copy. On OpenReel Studio the product states it plainly: you own the output you generate, we claim no ownership of it, and we do not use it to train models.

Yes, and the difference is commercial rather than technical. The assistant we run inside zynAIR tenants works against an existing Claude Code or Codex subscription rather than metered API keys, so the cost does not scale with how much your team uses it — which is the thing that quietly kills most ERP AI pilots. It takes the mechanical work: drafting, cross-referencing, staging an import. Every write it makes is prepared for a person to release, and posting, sending and confirming stay with your own staff inside Odoo. The engineering note explains the arrangement and its limits.

For the tasks most companies actually have — retrieval over internal documents, extraction from invoices and delivery orders, classification, summarisation, drafting — current open-weight models are comfortably good enough. The honest test is not a leaderboard: it is a hundred of your own real documents, scored by somebody who already knows the correct answers. We run that test before quoting anything, because it is also the only way to find out early that the answer is no.

Tell us the constraint, not the technology.

Whether the answer is a server in your building, a hosted product, or nothing at all, we will tell you which. The conversation that concludes "you do not need this" costs us nothing and saves you a purchase.