Kiwire docs

Appearance

Keys, models and limits ​

Which key pays for a request, which model answers it, and how much a tenant can spend on Kiwire's.

How an AI call picks its key Three sources are tried in order and the first one found wins: the tenant's own key, stored encrypted with the tenant's own settings; then a platform key kept by Synchroweb; then the server-level fallback read from the server configuration. A tenant's own key goes straight to the provider because the tenant pays its own bill. A platform or server-level key is billed to Kiwire, so it first passes the monthly token cap, which is per tenant with a default set by the platform; over the cap the request is refused with HTTP 429. The provider is chosen per tenant on the A.I Model card, with minimax and MiniMax-M3 as the platform default. RESOLUTION ORDER — THE FIRST KEY FOUND WINS1 Tenant BYOKthe tenant's own keyper tenant, stored encryptedIF UNSET2 Platform keykept by Synchrowebset by SynchrowebIF UNSET3 Server fallbackthe server's own keybootstrap defaultOWN KEY, OWN BILL:THE CAP DOES NOT APPLYBILLED TO KIWIREMonthly token capper tenant; default set by the platformUNDER THE CAPover the cap: refused, HTTP 429Providerchosen per tenant on the A.I Model card; platform default minimax · MiniMax-M3
When the assistant says it has no credential, walk the top row left to right: is BYOK allowed and set for this tenant, is there a platform key for the tenant's provider, is the server-level key present. When it says the tenant is over its cap, the tenant is on a platform-billed key — check its own limit, then the platform default; a tenant on its own key is never capped.

Whose key is used ​

Every AI request in Kiwire — the reporting assistant, KAIA's chat, heartbeat narration and weekly review, marketing mode — resolves its credential through the same chain, highest priority first:

  1. The tenant's own key, if Synchroweb has allowed that tenant to bring one and the tenant has actually entered a key for the provider in use.
  2. A platform key, entered by Synchroweb and stored at platform level, outside any tenant's database.
  3. The server-level fallback — the key set for that provider in the platform's own environment configuration.

The tenant's key deliberately wins over the platform key: a tenant that went to the trouble of entering its own key expects it to be used, and should not be cut off mid-conversation because Kiwire's shared quota ran dry. Whichever key resolves is pushed into the AI SDK's runtime configuration just before the request is built, so the SDK itself never knows there was a choice. If nothing resolves, the feature renders its off-state rather than guessing.

Before any of that, AI has to be switched on for the tenant at all — a per-tenant flag Synchroweb sets. The admin UI shows the result of the chain directly: a provider is labelled "Kiwire: MiniMax" when Kiwire's own key is paying for it, and "MiniMax — your key" once the tenant's key takes over.

Bring your own key ​

A tenant can supply its own API key for any supported provider — Groq, Anthropic, OpenAI, Gemini, OpenRouter and MiniMax — from the A.I Model card on System › Settings. It is off by default and only takes effect once Synchroweb has switched on that tenant's allow BYOK policy; until then the field is refused at save time. A tenant's key is stored encrypted, one per provider, in the tenant's own database (kiwire_tenant_settings, group ai, never the landlord database), and is only ever shown back masked to its last four characters. Once a tenant's key is in use for a provider, requests run on the tenant's own account with that provider, are billed there directly, and are never counted against Kiwire's shared token cap.

Models ​

Kiwire talks to the six providers above. Each has a built-in default model — for MiniMax it is MiniMax-M3 — and Synchroweb can override that default per provider platform-wide. A tenant can name a different model on the A.I Model card; when the request is billed to Kiwire's key, that choice is checked against a per-provider allow-list Synchroweb maintains (OpenRouter alone lists hundreds of models, most priced well above what the shared cap was sized for), and a model that is not on the list falls back to the platform default. On a tenant's own key the allow-list does not apply.

Which provider a tenant is on is, in order: the tenant's own choice on the A.I Model card, otherwise the platform-wide provider setting, otherwise the built-in default. On this install the platform-wide setting is MiniMax, so a tenant that has never opened the A.I Model card runs on MiniMax-M3.

MiniMax is reached through the Groq driver. Its chat-completions API follows the OpenAI shape, the Groq driver is that shape with a configurable base URL, and the AI SDK Kiwire uses has no generic OpenAI-compatible driver yet — so the MiniMax provider reuses the Groq driver pointed at MiniMax's own global endpoint (api.minimax.io) rather than Groq's. Nothing Groq-specific is sent, and the model name always comes from the credential chain above, not the driver.

Response temperature and length are tenant-settable on the same card, defaulting to 0.2 and 2,048 tokens: reporting answers are factual lookups, so near-deterministic is the right starting point. The card's Test button probes the provider with the resolved key so a misconfigured provider fails there rather than in front of a user.

Monthly token caps ​

Usage on Kiwire's shared key is metered per tenant, per calendar month, broken down by provider, in a monthly ai_usage_YYYYMM setting in the tenant's database. Before a prompt runs it is checked against a monthly token cap: the tenant's own explicit limit if Synchroweb has set one, otherwise the platform-wide default. That default is a platform setting Synchroweb can change, currently 200,000 tokens per tenant per month on this install; if it were ever cleared the code falls back to a built-in 500,000. The cap is never absent — shared-service spend is billed to Kiwire, so it is always bounded.

A tenant that has reached its cap gets a clear "quota exceeded" reply until the month rolls over, or until Synchroweb resets its usage. KAIA's own detectors watch the same counter and raise a finding as a tenant approaches its cap. The cap applies only to requests on Kiwire's key: a tenant running on its own key is never measured against it. Beyond cost, the cap is also a safety limit — it bounds how much a runaway conversation, a misbehaving client or a prompt-injection attempt can consume before it is stopped, which is why Guardrails lists it too.

Where to set it ​

A.I Model card, System › Settings (tenant admin): the provider and model; temperature and maximum reply length; whether to verify the provider's TLS certificate; the tenant's own key per provider, if BYOK is allowed; and KAIA's switches — on or off, its heartbeat interval (6, 12 or 24 hours) and how often the daily review runs. Everything on this card is written to the tenant's own database.

Everything else is Synchroweb's: the platform keys, one per provider; the platform default monthly token cap; per provider, the default model and the allow-list for tenants on the shared key; and each tenant's AI policy — AI on or off, BYOK allowed, an explicit monthly cap or the platform default, whether MCP is available to it, whether KAIA is available to it — together with a usage reset. A tenant admin sees only the A.I Model card. These keys are Kiwire's own credentials, billed to Kiwire and shared by every tenant that has not brought its own, which is why deciding who may spend them is a platform decision rather than a tenant one; contact Synchroweb support to change any of them.

Last updated:

Kiwire platform documentation

Synchroweb