Model as a Service — using our models in your own tools

Who this page is for

This page is for people who write software and want to use your organisation's models from a coding tool on their own computer — opencode, or any other tool built for the OpenAI interface.

If that is not you, skip this page. Nothing on it is needed to use zGentic in the browser, and nothing here changes how chat works. The rest of this site covers everything else.

From here on the page assumes you are comfortable editing a configuration file and running a command in a terminal.

MaaS stands for Model as a Service: your organisation's models, offered as a service you can call from elsewhere. You create a personal key, point your tool at zGentic, and your tool talks to the same models you already use in chat.

Nothing about permissions changes. The key is you. It reaches exactly the models you can already pick in chat, it can do nothing your role does not allow, and every call is measured and billed the same way as your usage inside the application.

Create a key

Go to Settings and find the section MaaS — Model as a Service, then choose Create key.

• Give it a name that says where it will live — opencode — laptop, desktop, CI. You can hold several keys at once, one per machine or tool, so that retiring one later does not disturb the others.
• Optionally choose an expiry: 30 days, 90 days, a year, or none. An expired key stops working on its own, so nobody has to remember to clean it up.

The key is shown once. Only a hash of it is stored, so it cannot be shown again — copy it now. If you lose it, retire it and create another.

Alongside the key you get the base URL to use and a ready-made opencode.json.

Set up opencode

opencode does not ask the server which models exist, so the model names have to be written into its configuration. The panel produces exactly that file for you. Use Copy opencode.json and save it as opencode.json in your project, or as ~/.config/opencode/opencode.json to use it in every project:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "zgentic": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Zgentic",
      "options": {
        "baseURL": "https://<your-instance>/api/v1",
        "apiKey": "zg_…"
      },
      "models": {
        "openrouter::z-ai/glm-5.2": { "name": "glm-5.2 (openrouter)" }
      }
    }
  }
}

Then run opencode and choose a model with /models.

Keep the key out of the file

Prefer "apiKey": "{env:ZGENTIC_API_KEY}" and set ZGENTIC_API_KEY in your shell, so the secret is not sitting in a file you might commit to a repository. You can regenerate the configuration in that form at any time:

curl -H "Authorization: Bearer $ZGENTIC_API_KEY" \
  https://<your-instance>/api/v1/opencode-config

Other tools that speak the OpenAI interface

Point any OpenAI-compatible client at the same base URL, with your key as the bearer token in the Authorization header:

curl https://<your-instance>/api/v1/models \
  -H "Authorization: Bearer $ZGENTIC_API_KEY"

curl https://<your-instance>/api/v1/chat/completions \
  -H "Authorization: Bearer $ZGENTIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "auto", "messages": [{"role": "user", "content": "Hello"}]}'

• GET /v1/models lists the models you may use. Each entry states how much text the model can hold at once (its context window) and whether it can call tools and read images. Models your organisation has not enabled are not listed, and neither are models your supplier no longer serves or that only produce images — they would fail if you called them.
• POST /v1/chat/completions supports streaming (the reply arriving in pieces as it is written) and non-streaming, tool calling, and images passed as data: URLs. Send "model": "auto" for your default model, or one of the identifiers from the listing.

Which model identifier to send

Send the identifier exactly as the listing gives it — for example openrouter::z-ai/glm-5.2.

The part before the :: names the supplier. It matters when your organisation has more than one supplier configured and both offer a model of the same name. A short name works when it is unambiguous, and auto always means your default model.

Watching a key, and retiring it

Each key in the list shows its status (active, expired or revoked), the first few characters of the key so you can recognise it, when it was last used, and how many requests it has made.

Activity opens the recent requests for that key — which endpoint, which model, how it ended and how long it took — together with what it has spent.

Check that before you remove anything. A key that has not been used for months is safe to retire.

Retire takes effect immediately: the very next request from that client fails. A retired key stays in the list, with the date and who retired it, so you can confirm you removed the right one. It can never be switched back on.

Worth knowing

• What you send is not logged. The activity record keeps which model was called and how the call went. It never keeps your messages or the replies.
• A refused request tells you why. If your organisation's balance or your own monthly limit is used up, the call fails with a clear error rather than hanging or returning nothing, and the activity list shows it as refused.
• Rate limits apply per key, so a busy automated job cannot slow down the key on your laptop.
• Deleting your account deletes your keys along with everything else of yours.