Kimss AI Developer Tier: 25,000 Governed Requests/Month, No Credit Card, No Trial

Most AI platform rollouts start with a simple assumption: teams will register their agents before shipping them.

That assumption usually breaks on contact with reality.

Count the agents your teams are running. Now count the rows in your agent inventory.

The gap between those two numbers is the shadow agent problem.

Kimss AI approaches this from the gateway layer instead of from model hosting or endpoint scanning. Kimss is a Secure Enterprise Agent Control Plane: a model-agnostic API gateway where customers bring their own agents and infrastructure. The gateway provides agent registry, SSO identity mapping, gateway kill switch controls, and gateway-verified audit for routed traffic.

The Developer tier exists so platform teams can test that control plane quickly, without procurement friction:

• 25,000 governed requests/month
• No credit card
• No trial expiration
• Up to 5 workspace members
• 14-day retention
• Hard HTTP 429 at cap (error=governed_requests_exhausted)

This article walks through what you can actually do with the free tier and how to integrate it into an existing OpenAI-compatible stack.

Why the gateway layer matters

Most enterprises already have model providers, cloud accounts, and orchestration frameworks. The operational problem is usually governance consistency across them.

Kimss sits in front of those providers as an OpenAI-compatible inbound gateway at:

https://api.kimss.ai

That means existing applications can often route through the gateway with a base_url change instead of a full SDK rewrite.

For platform engineers, that creates a practical path to:

• Inventory routed agents
• Map agents to SSO identities
• Apply gateway controls
• Centralize gateway-verified audit logs
• Add kill switch enforcement for routed traffic

Importantly, Kimss does not host models or resell compute. Your infrastructure and providers remain yours.

A minimal integration

If your application already uses the OpenAI SDK, the smallest possible integration is typically replacing the base URL.

Example using Python:

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["KIMSS_API_KEY"],
    base_url="https://api.kimss.ai/v1"
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {
            "role": "user",
            "content": "Summarize the last deployment incident."
        }
    ]
)

print(response.choices[0].message.content)

Environment variables:

export OPENAI_BASE_URL=https://api.kimss.ai/v1
export KIMSS_API_KEY=your_kimss_key

That routing path is where the governance layer becomes visible.

When traffic flows through the gateway, Kimss can inventory routed agents automatically. Unattributed calls are labeled by model, such as:

Discovered · gpt-4o

If you want explicit naming, applications can send:

X-Kimss-Agent-Id

That turns discovery into a structured inventory process without requiring annotation across every codebase on day one.

What “governed requests” actually means

Kimss meters usage using governed requests rather than compute credits.

That distinction matters because Kimss is not the model provider. The governed request is the policy and control event happening at the gateway layer.

For developers, this usually maps more cleanly to operational governance questions:

• Which agent made this request?
• Which identity was associated with it?
• Which provider path was used?
• Was the request routed through approved infrastructure?
• Did it exceed policy caps?
• Can it be disabled centrally?

The free Developer tier includes 25,000 governed requests per month before the hard cap returns HTTP 429 responses.

Example:

{
  "error": "governed_requests_exhausted"
}

That behavior makes the free tier predictable for internal testing and CI environments.

Zero-annotation discovery in practice

A common problem with AI governance projects is rollout friction.

If adoption requires every team to migrate SDKs, annotate code, or redesign orchestration flows, the inventory never catches up with reality.

Kimss focuses on zero-annotation discovery for routed traffic.

In practice:

1. Route existing OpenAI-compatible traffic through the gateway
2. The gateway observes distinct agent traffic
3. Inventory rows are created automatically
4. Teams can later formalize naming and policy assignment

This is intentionally operational rather than aspirational.

The gateway only inventories traffic routed through Kimss. It does not scan networks, endpoints, DNS, or SaaS estates. Existing security tooling still handles those domains.

That scope boundary matters for compliance conversations because gateway-verified audit only applies to routed traffic.

Where the free tier fits

The Developer plan is useful for three common workflows.

1. Platform evaluation

A platform team can route a staging environment through the gateway and evaluate:

• Existing agent sprawl
• Identity mapping
• Governance enforcement
• Audit visibility
• Kill switch operations

without introducing billing overhead immediately.

2. Internal AI tooling

Smaller internal tools often never receive centralized governance because onboarding friction is too high.

The free tier is enough for:

• Engineering copilots
• Deployment assistants
• Internal support agents
• CI/CD automation helpers
• Lightweight RAG services

especially when usage is intermittent.

3. Gateway migration testing

Because the inbound interface is OpenAI-compatible, teams can test migration risk incrementally.

You can validate:

• SDK compatibility
• Latency impact
• Logging behavior
• Policy enforcement
• Request accounting

before rolling traffic into broader environments.

BYOI instead of provider lock-in

Kimss uses a bring-your-own infrastructure approach.

Customers bring their own providers and infrastructure, including OpenAI-compatible systems and cloud-hosted deployments.

One operational detail worth noting is the BYOI Provider Vault model:

• Customer keys stay in Azure Key Vault
• Kimss governs the request path
• The customer retains provider ownership

That separation is useful for organizations trying to standardize governance without centralizing all compute procurement.

Operational controls developers actually notice

A lot of AI governance products focus on executive reporting first.

Developers usually care about whether the system interferes with shipping velocity.

The controls that tend to matter most at implementation time are simpler:

• OpenAI-compatible inbound
• Minimal application changes
• Observable request flow
• Predictable rate behavior
• Clear audit boundaries
• Centralized shutdown capability for routed agents

Kimss also supports per-endpoint token caps on connected infrastructure. Those are customer guardrails at the infrastructure edge, not Kimss overage billing controls.

For teams running orchestrated workflows, Kimss also supports Hermis multi-step agent orchestration on the gateway layer.

Pricing snapshot

Current plans:

• Developer — Free

  • 25,000 governed requests/month
  • No credit card
  • Up to 5 workspace members
  • 14-day retention

• Production — $49/month

  • 100,000 included
  • $16/100k overage
  • 30-day retention
  • Unlimited workspace members

• Scale — $199/month

  • 1,000,000 included
  • $8/100k overage
  • 90-day retention
  • Unlimited workspace members

• Enterprise — custom

Kimss meters governed requests, not compute credits.

Getting started

The shortest path to testing the Developer tier is:

1. Create a workspace
2. Generate an API key
3. Point your OpenAI-compatible client at:

   https://api.kimss.ai/v1

1. Route a staging workload through the gateway
2. Observe inventory and governance behavior

Get Free API Key at https://kimss.ai

FAQ

Does Kimss AI host models?

No. Kimss AI is a Secure Enterprise Agent Control Plane and model-agnostic API gateway. Customers bring their own providers and infrastructure.

What happens after the 25,000 free governed requests are exhausted?

The Developer tier returns HTTP 429 responses with error=governed_requests_exhausted after the monthly limit is reached.

Can I use existing OpenAI SDKs with Kimss AI?

Yes. Kimss provides OpenAI-compatible inbound routing at https://api.kimss.ai/v1, so many applications only need a base_url change to route traffic through the gateway.