QK Gatewai — the Community Edition for AI developers

QK Gatewai — one API key for every model — has a Community Edition aimed at a specific reader: an AI developer who wants the full gateway running locally, wants to test against it without a single provider credential, and wants the free tiers they already have behind one endpoint.

What Gatewai is

Gatewai aggregates networked provider adaptors — OpenAI, Anthropic, Google, Qwen, DeepSeek, Cohere, Jina, Voyage, fal.ai, Jimeng, Vertex, ComfyUI, Seedance, Kling, Hailuo, MiniMax, Suno, IndexTTS — behind a byte-exact OpenAI-compatible API. Quota-aware billing, channel load-balancing with failover, governance enforcement, request logs and usage surfaces, margin reporting, and a full operator console sit on top. The project overview covers the implementation story.

What the Community Edition gives AI developers

Free-tier aggregation behind one endpoint. Point Gatewai at the free tiers you already have — and the paid providers you graduate to — and call one API. Your application ships against /v1/* with no vendor SDKs embedded, and adding or swapping a provider is a configuration change rather than a code change. Retries, failover, and rate behavior live in the gateway instead of being reimplemented in every app you build.

A stub for testing that runs anywhere. CE ships an offline stub provider alongside the networked adaptors. It answers requests deterministically, so the full request → response → usage → log loop runs on a laptop with no provider account, no API key, and no spend. Agent loops, retry logic, and tool pipelines get tested against the same API surface your production calls use — not a mock you built yourself.

Zero-credential local runs. The default database is SQLite — the config describes it as “zero-config sqlite so the quickstart needs no services.” A fresh install comes with seeded dev accounts and a channel already enabled, so the path from first boot to a request you can explain is minutes, not a setup day.

Inspect why, not just what. Every response is traceable through the request log, usage, and quota surfaces: send a request through the stub, open the console, and see how routing, guards, and billing treated it. That is the whole reason the testing surfaces are first-class rather than something bolted on later.

The rest of the workbench

CE keeps the developer-facing set complete:

• Tokens and quota controls — per-app keys with usage tracking, so rate and spend behavior is visible from the first day.
• Governance and guard checks — enforced in local runs too, so fail-closed behavior is exercised in development rather than discovered in production.
• Webhooks and an inbox — react to delivery events without a polling loop.
• Background workers and tasks — the same task pipeline the gateway uses for bulk work.
• n8n integration — planned: metered inference from no-code workflows.

Under all of it is the same OpenAPI-compatible relay your applications talk to, so what you learn while evaluating carries straight into what you ship.

Where to start

The QK Gatewai project overview covers the architecture and the current surfaces, and the evaluation guide walks the zero-credential golden path: boot the stack, send a request through the stub, and read the request log, usage, and quota surfaces that explain the response.