Introduction

i2 puts leading open-weight models behind one API that any OpenAI client already speaks. You point your existing SDK at a new base URL, use an i2 key, and pick a model from the catalogue. Prices are per million tokens in PKR, drawn from a prepaid balance, so there is no foreign card and no exchange-rate surprise at the end of the month.

What you get

• One endpoint, every model. POST /v1/chat/completions in the OpenAI request and response shape, streaming or synchronous. Change the model string, not your code.
• Keys with real limits. Every API key can carry an expiry, a rupee credit cap and a list of allowed models, and the gateway enforces all three on the request path.
• Rupee billing. Per-million-token prices in PKR, a prepaid balance, and the exact cost of each request reported back to you.
• Visibility. Requests, latency, time to first token, tokens and cost per key, per project and per model, plus a request-by-request log, in the dashboard and over the API.
• Residency. The gateway, its telemetry, the audit log and the billing records run in Pakistan. The PK NPU-native model pool is opening shortly; global pass-through routes serve today.

The two halves of the platform

Most integrations only ever touch the data plane. The control plane is what the dashboard uses; it is documented here so you can script key rotation, read your spend, or pull the request log into your own systems.

Where to start

1. Quickstart: a key and a first request in a few minutes.
2. Models: the catalogue, route ids and prices.
3. Chat completions: the request contract in full, including streaming.
4. Errors and retries: every status the gateway returns and what to do about it.

Note These docs describe the platform as it runs today. Where something is not yet available (a /v1/models listing, per-key rate-limit configuration, the PK NPU pool) the page says so rather than describing a roadmap.