Keep what your product does separate from where its model requests go. Changing a request’s destination shouldn’t force you to untangle routing decisions from application logic.
If you’re shipping a product that calls models, start with a working agent loop, trace one request end to end, then add a production gateway. Here’s a short reading-and-building path through Kimss Forge, the MIT open-source agent harness from Kimss AI.
Start With The Loop, Not More Plumbing
Builders lose afternoons rebuilding the same agent execution loop before they get to the part that makes their product useful.
Kimss Forge runs locally, is free, and requires no Kimss account. Start with its open-source examples: a few lines plus your model endpoint, rather than a fresh execution loop.
pip install kimss-forge
Find the examples at kimss.ai/open-source. Pick one and follow a single model call before adding more moving parts.
Trace One Request
Read the example with three questions in mind:
- What is the application asking the agent to do?
- Where does the model request go?
- Which parts of the code describe product behavior, and which parts select infrastructure?
That distinction matters later. Application intent belongs in your product; routing policy should be replaceable without rewriting that intent.
Read The Benchmark Before Borrowing The Number
Read BENCHMARK.md alongside the examples. Use it to evaluate the about 80% less application code comparison, not as a blanket promise about your own project.
Check what the comparison includes, what it leaves out, and whether the setup resembles the work your application actually does. Less plumbing is useful when it removes code you would otherwise have to maintain.
Notice The Local Warning
When a sensitive tool fires without a production gateway, Forge emits a soft Authority Boundary warning in the terminal.
It does not block local execution. You can keep experimenting without an account, while getting a visible reminder that local execution and production enforcement are different things.
The warning is not the paid Authority Boundary control.
Attach The Gateway Without Replacing The Agent
The next step is the Forge gateway path: add gateway="kimss" to the same agent.
For traffic using that path, identity on model calls and Kill Switch are included on Developer, the free plan. The Kill Switch severs access at the Kimss gateway for routed traffic; it does not terminate customer processes that never call the gateway.
For an existing OpenAI-compatible client, the routing change is a one-line base_url swap:
base_url = "https://api.kimss.ai"
That line shows the destination change, not a complete authentication setup. Follow the documented gateway setup for credentials and your connected infrastructure.
Kimss is a model-agnostic API gateway, not a chat app or a model host. You bring your agents and infrastructure; Kimss governs requests routed through it.
Keep Later Controls On The Same Path
You don’t need to design around enterprise controls to get your first agent running.
When you do need Authority Boundary, SSO, or SCIM, read them as paid controls on the same gateway path, not a separate architecture. Free gateway identity should not be confused with free SSO or SCIM.
The sequence stays practical: run locally, understand the request path, then attach governance without rewriting what your application does.
Next step: run pip install kimss-forge and trace one example model call end to end.
Top comments (0)