# Creates a completion Source: https://docs.hicap.ai/api-reference/endpoints/openAI/creates-a-completion-for-the-chat-message post /chat/completions # Generates a batch of images from a text caption on a given DALLE model deployment Source: https://docs.hicap.ai/api-reference/endpoints/openAI/generates-a-batch-of-images-from-a-text-caption-on-a-given-dalle-model-deployment post /deployments/{deploymentId}/images/generations # Lists available models Source: https://docs.hicap.ai/api-reference/endpoints/openAI/lists-available-models get /models Returns the public model catalog available through the Hicap API. Use model IDs from this response in OpenAI-compatible endpoints such as /chat/completions. Use `GET /v1/models` to list public Hicap model IDs. This endpoint does not require authentication. Pass one of these IDs as the `model` value in OpenAI-compatible endpoints such as [chat completions](/api-reference/endpoints/openAI/creates-a-completion-for-the-chat-message). For the full public model catalog with pricing and context windows, see [All Models](https://hicap.ai/models). ```bash theme={null} curl https://api.hicap.ai/v1/models ``` The response follows the OpenAI-compatible list shape: ```json theme={null} { "object": "list", "data": [ { "id": "gpt-5.5", "object": "model", "owned_by": "openai" }, { "id": "gpt-5.5-pro", "object": "model", "owned_by": "openai" }, { "id": "gpt-5", "object": "model", "owned_by": "openai" } ] } ``` ## OpenAI model references The public model list can include these OpenAI models: | Model ID | Object | Reference | | ------------- | ------- | -------------------------------------------------------------------------------- | | `gpt-5.5` | `model` | [GPT-5.5 Model ↗](https://developers.openai.com/api/docs/models/gpt-5.5) | | `gpt-5.5-pro` | `model` | [GPT-5.5 pro Model ↗](https://developers.openai.com/api/docs/models/gpt-5.5-pro) | # API Overview Source: https://docs.hicap.ai/api-reference/introduction OpenAI-compatible REST API for accessing foundation models through Hicap The Hicap API is a RESTful API compatible with the [OpenAI API specification](https://github.com/openai/openai-openapi). Use it from any environment that supports HTTP requests, or through OpenAI's official SDKs for [Python](https://github.com/openai/openai-python), [JavaScript/TypeScript](https://github.com/openai/openai-node), [Go](https://github.com/openai/openai-go), and more. **Base URL:** `https://api.hicap.ai/v1` *** ## Authentication The Hicap API uses API keys for authentication. Create and manage your API keys in the [Hicap Platform ↗](https://platform.hicap.ai/). Your API key is a secret. Do not share it or expose it in client-side code (browsers, mobile apps). Load API keys from environment variables or a secrets manager on the server side. Provide your key via one of these headers: ```bash theme={null} # Bearer authentication (OpenAI SDK default) Authorization: Bearer YOUR-HICAP-API-KEY # api-key header (Azure-style, also supported) api-key: YOUR-HICAP-API-KEY ``` ### Example request ```bash theme={null} curl https://api.hicap.ai/v1/chat/completions \ -H "Authorization: Bearer $HICAP_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-5", "messages": [{"role": "user", "content": "Hello, world"}] }' ``` *** ## Endpoints All endpoints follow the [OpenAI OpenAPI specification](https://github.com/openai/openai-openapi). ### Production These endpoints are available on the production Hicap API (`api.hicap.ai`). #### Models | Endpoint | Method | Description | | ---------------------------------------------------------------------- | ------ | ---------------------------------------- | | [`/v1/models`](/api-reference/endpoints/openAI/lists-available-models) | `GET` | List model IDs available to your API key | #### Chat Completions | Endpoint | Method | Description | | --------------------------------------------------------------------------------------------------- | ------ | ----------------------------------------------------------- | | [`/v1/chat/completions`](/api-reference/endpoints/openAI/creates-a-completion-for-the-chat-message) | `POST` | Generate text, analyze images, call tools, stream responses | | `/v1/chat/completions/{completion_id}` | `GET` | Retrieve a stored chat completion by ID | | `/v1/chat/completions/{completion_id}/messages` | `GET` | List messages from a stored chat completion | #### Images | Endpoint | Method | Description | | --------------------------------------------------------------------------------------------------------------------------------------------- | ------ | --------------------------------- | | [`/v1/images/generations`](/api-reference/endpoints/openAI/generates-a-batch-of-images-from-a-text-caption-on-a-given-dalle-model-deployment) | `POST` | Generate images from text prompts | | `/v1/images/edits` | `POST` | Edit or extend existing images | | `/v1/images/variations` | `POST` | Generate variations of an image | ### Developer Preview These endpoints are available on the Hicap developer API and are not yet in production. Developer preview endpoints may change before general availability. Contact [support@hicap.ai](mailto:support@hicap.ai) for access. #### Responses | Endpoint | Method | Description | | ----------------------------------------- | -------------- | --------------------------------------- | | `/v1/responses` | `POST` | Create a model response (Responses API) | | `/v1/responses/{response_id}` | `GET` `DELETE` | Retrieve or delete a response | | `/v1/responses/{response_id}/cancel` | `POST` | Cancel an in-progress response | | `/v1/responses/{response_id}/input_items` | `GET` | List input items for a response | #### Realtime | Endpoint | Method | Description | | ------------------------------------- | ------ | ------------------------------ | | `/v1/realtime/sessions` | `POST` | Create a realtime session | | `/v1/realtime/transcription_sessions` | `POST` | Create a transcription session | *** ## Models Pass any [supported model ID](https://hicap.ai/models) in the `model` field. The Hicap API supports models across OpenAI, Anthropic, Google Gemini, Moonshot, Zhipu, and MiniMax — all through the same OpenAI-compatible interface. [View all models →](https://hicap.ai/models) *** ## Streaming Most text generation endpoints support server-sent events (SSE) for streaming responses. Set `"stream": true` in your request body to receive chunks as they are generated. ```bash theme={null} curl https://api.hicap.ai/v1/chat/completions \ -H "Authorization: Bearer $HICAP_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-5", "messages": [{"role": "user", "content": "Write a haiku"}], "stream": true }' ``` Each SSE event contains a JSON chunk with incremental content. The stream ends with a `[DONE]` sentinel. *** ## Rate limits Rate limits vary by plan and are applied per API key. When you exceed your limit, the API returns a `429` status code. Use exponential backoff to retry. The following rate limit headers are included in API responses: | Header | Description | | -------------------------------- | ------------------------------------------ | | `x-ratelimit-limit-requests` | Max requests allowed in the current window | | `x-ratelimit-limit-tokens` | Max tokens allowed in the current window | | `x-ratelimit-remaining-requests` | Requests remaining in the current window | | `x-ratelimit-remaining-tokens` | Tokens remaining in the current window | | `x-ratelimit-reset-requests` | Time until the request limit resets | | `x-ratelimit-reset-tokens` | Time until the token limit resets | For higher limits, contact [support@hicap.ai](mailto:support@hicap.ai) or upgrade your plan in the [Hicap Platform ↗](https://platform.hicap.ai/). *** ## Errors The Hicap API uses standard HTTP status codes and returns JSON error bodies. | Status | Type | Description | | ------ | ----------------------- | --------------------------------------------------------- | | `400` | `invalid_request_error` | Malformed request body or missing required fields | | `401` | `authentication_error` | Invalid or missing API key | | `403` | `permission_error` | API key lacks required permissions | | `404` | `not_found_error` | Requested resource does not exist | | `429` | `rate_limit_error` | Rate limit exceeded — back off and retry | | `500` | `api_error` | Internal server error — retry with exponential backoff | | `503` | `overloaded_error` | Server temporarily overloaded — retry after a short delay | Error responses include a JSON body: ```json theme={null} { "error": { "message": "Invalid API key provided", "type": "authentication_error", "code": "invalid_api_key" } } ``` *** ## Request IDs Every API response includes an `x-request-id` header with a unique identifier for that request. Log this value in production — it allows the Hicap support team to quickly locate and diagnose issues if you need help. *** ## Versioning The Hicap API follows the OpenAI v1 API specification. We are committed to maintaining backward compatibility within the v1 API and will avoid breaking changes whenever possible. # Organizations, Applications, Connections & Keys Source: https://docs.hicap.ai/concepts/applications-connections-keys How the Hicap AI Gateway organizes AI usage so spend and usage roll up automatically The Hicap AI Gateway organizes everything you build around a clear hierarchy: an **Organization** contains **Applications**, an Application has one or more **Connections**, and each Connection carries a pair of **Keys**. A Connection is a governance scope — it's where budgets, allowed models, and default routing live. Because Keys belong to a Connection and Connections belong to an Application, usage and spend roll up automatically — with nothing extra to send at call time. ## The hierarchy ```mermaid theme={null} graph TD O[Organization] --> A1[Application] O --> A2[Application] A1 --> C1[Connection] A1 --> C2[Connection] C1 --> K1[Primary key] C1 --> K2[Secondary key] ``` ### Organization An **Organization** is your company's account on the Hicap AI Gateway. It contains your **users** and the Applications they work on, and it is the top level that all usage and spend ultimately roll up to. Organizations are also where **teams** live. A team is a group of users inside your Organization — it describes who people are and what they can reach, not how a request is labeled. ### Application An **Application** is a product, service, or workload that consumes AI. Applications are the rollup point for Keys: every Key ultimately reports its usage into the Application it belongs to, which makes the Application the natural unit to plan, budget, and report on. Group your work into Applications the way you think about it internally, so reporting matches how you already plan. ### Connection A **Connection** is a governance scope within an Application, and it is what Keys are issued against. It's where you set the rules that requests made with its Keys must follow: * **Budgets** — spend limits for everything that runs under the Connection. * **Allowed models** — which models Keys on this Connection may call. * **Default routing** — the default model behavior applied when a request doesn't specify one. * **Reporting boundaries** — a scope you can slice usage and spend by on its own. An Application can have more than one Connection, so you can apply different budgets, model allowances, and routing to different parts of the same product — for example a tightly capped Connection for experiments alongside a production one, or falling back to a secondary model once a budget has been exhausted. ### Keys A **Key** is the credential your client actually sends. Every Connection carries two Keys — a **primary** and a **secondary** — and either one is equally valid for making requests. Two Keys exist so you can rotate without downtime. Your clients move from one Key to the other, and once nothing is using the old Key it can be regenerated safely. At no point do you need a maintenance window, and at no point does the Connection or the Application above it change. Because a Key is issued under a Connection, every request made with it already carries the Connection and the Application it belongs to. ## Why the hierarchy pays off Because the relationships are fixed when you provision them, attribution requires nothing at call time: * **Usage and spend roll up automatically.** Every request carries its Key, and the Key already knows its Connection, its Application, and your Organization. Reporting aggregates up the hierarchy with no extra work on each call. * **Changes stay contained.** Regenerating a Key does not disturb the Connection, and removing a Connection does not disturb the Application. You can rotate credentials or adjust a Connection's budget, allowed models, or routing without reorganizing anything above. ## When to add another one Add an Application when you're building a distinct product or workload you want to plan, budget, and report on separately. Because Applications are where Keys roll up, this is the boundary that shapes your reporting. Add a Connection when part of an Application needs its own governance — a different budget, a different set of allowed models, or different default routing. For example, a capped Connection for experimentation alongside a production one. Each Connection brings its own pair of Keys. Use the secondary Key to rotate credentials without downtime: move clients onto it, confirm nothing is still calling with the primary, then regenerate the primary. If you want separate credentials per environment, add a Connection per environment rather than splitting the two Keys across them. ## Structural vs. descriptive attribution Organizations, Applications, Connections, and Keys give you **structural** attribution: it comes from which Key you used, requires nothing at call time, and is fixed by how you provisioned things. For **descriptive** attribution — labels you choose per request and can reinterpret afterwards — see [Tags, Dimensions & Segments](/concepts/tags-dimensions-segments). Both roll up into the same spend reporting; they answer different questions. # Implement attribution with an agent Source: https://docs.hicap.ai/concepts/implement-attribution-with-an-agent A ready-to-use prompt that has a coding agent add Hicap setup and base attribution to your codebase This page gives you a prompt you can hand to a coding agent — GitHub Copilot, or any agent that can read and edit your repository — to add a working **base attribution** setup to your application. It wires up the Hicap client and starts tagging requests so usage and spend roll up the way the rest of the [Concepts](/concepts/organizations-and-users) pages describe. Start with the [master prompt](#master-prompt) for a complete pass, or use the [focused prompts](#focused-prompts) to do it one step at a time. These prompts describe the outcome, not a fixed set of edits. Review the agent's changes like any other pull request — where things land depends on how your codebase is structured. ## Before you start The agent will need a few things to be true. You can either set these up first or let the prompt ask you for them: * **A Hicap API key.** Create one in the [Hicap Platform dashboard ↗](https://platform.hicap.ai/) and make it available as the `HICAP_API_KEY` environment variable. The agent should never hard-code it. * **The base URL and auth header.** Requests go to `https://api.hicap.ai/v1`, and the key is sent as the `api-key` header. Any OpenAI-compatible SDK works — see the [Developer Quickstart](/quickstart). * **A sense of your dimensions.** Decide which labels you want to slice spend by. See [Tags, Dimensions & Segments](/concepts/tags-dimensions-segments) for the model; the prompt defaults to a sensible starter set. ## Master prompt Copy this into your agent. It covers Hicap setup and base attribution in one pass. ```text theme={null} You are adding Hicap AI Gateway support and base usage attribution to this codebase. Context — how Hicap attribution works: - Requests go through an OpenAI-compatible endpoint at https://api.hicap.ai/v1. Authentication is the API key sent as the `api-key` HTTP header. The key comes from the HICAP_API_KEY environment variable — never hard-code it. - "Structural" attribution (which Organization/Application/Key a request belongs to) rolls up automatically from the key, so I do NOT need to send anything for that at call time. - "Descriptive" attribution is what I DO send per request: a set of tags. Tags are sent in a single HTTP header called `x-hicap-tags` (plural). Its value is ONE JSON object mapping dimension keys to string values, e.g. {"feature": "checkout", "channel": "web", "env": "production"}. Send exactly one such header per request. Do not repeat the header or use comma-separated pairs. Do the following: 1. Find where this codebase calls language models today (search for the OpenAI SDK, HTTP calls to a model provider, or an existing AI client wrapper). If there is no such call yet, create a small client module in the idiomatic place for this project. 2. Point the client at Hicap: base URL https://api.hicap.ai/v1, and send the key as the `api-key` header, read from the HICAP_API_KEY environment variable. Keep any existing behavior working. Add HICAP_API_KEY to the project's example env file (e.g. .env.example) with a placeholder value and a short comment. 3. Add a single helper that builds the `x-hicap-tags` header from a plain map and attaches it to a request. It must JSON-encode the map and set exactly one header. Route model calls through this helper so tagging is consistent. 4. Establish base attribution. Set these service-level dimensions once, in one place, so every request carries them: - env (e.g. "production", "staging", "development" — derive from config) - system (a stable short name for this service/app) Then tag per call with: - feature (what the specific call is for — pass it in at each call site) Leave the map open so more dimensions can be added later. Use lowercase snake_case dimension keys and short, stable string values. 5. Update the 2–3 highest-traffic call sites to pass a real `feature` value so the result is demonstrable, and leave a clear pattern for the rest. 6. Add or update a short section in the project README explaining how attribution is wired: the env var, the tags helper, and how to add a dimension. Constraints: - Keep the diff surgical and idiomatic for this codebase. Match existing style, config, and dependency-management conventions. - Do not invent dimensions beyond env, system, and feature unless the codebase clearly needs one. It is better to leave the map extensible than to over-tag. - Do not log, print, or commit the API key. Do not add real secrets to any file. When you're done, show me: the client change, the tags helper, one tagged call site, and the README section. Then summarize what remains for me to roll out to the rest of the call sites. ``` ## Focused prompts Prefer smaller steps? Run these in order — each is safe to hand over on its own. ```text theme={null} Configure this codebase to call the Hicap AI Gateway. Requests use an OpenAI-compatible endpoint at https://api.hicap.ai/v1, and the API key is sent as the `api-key` HTTP header, read from the HICAP_API_KEY environment variable — never hard-coded. Find the existing model client (or create one in the idiomatic place), set the base URL and header, and keep current behavior working. Add HICAP_API_KEY to the example env file with a placeholder and a short comment. ``` ```text theme={null} Add one small helper to this codebase that attaches Hicap tags to a model request. Tags are sent in a single HTTP header named `x-hicap-tags` (plural) whose value is ONE JSON object mapping dimension keys to string values, e.g. {"feature": "checkout", "env": "production"}. The helper takes a plain map, JSON-encodes it, and sets exactly one `x-hicap-tags` header — never repeated and never comma-separated. Route model calls through this helper. ``` ```text theme={null} Establish base attribution using the tagging helper already in this codebase. Set `env` and `system` once, in one place, so every request carries them: `env` derives from config (production/staging/development) and `system` is a stable short name for this service. Keep the tag map extensible. Use lowercase snake_case keys and short, stable string values. ``` ```text theme={null} Add a per-call `feature` dimension at this codebase's model call sites, using the existing tagging helper and base dimensions. Each call site passes a short, stable `feature` value describing what that call is for (e.g. "product-recommendations", "summarize-ticket"). Update the 2–3 highest-traffic call sites now and leave a clear pattern for the rest. Don't change any other behavior. ``` ## After the agent runs * **Verify the header.** Confirm each request sends a single `x-hicap-tags` header whose value is one JSON object. See [How tags are sent](/concepts/tags-dimensions-segments#how-tags-are-sent). * **Check for untagged traffic.** Requests that arrive without your expected dimensions surface as **Unattributed Traffic** — a signal that a call site still needs the helper. See [Segments](/concepts/tags-dimensions-segments#segments). * **Grow into segments.** Once dimensions are flowing, define [segments](/concepts/tags-dimensions-segments#segments) to slice spend without touching code again. ## Related The minimal client setup the prompts build on. The attribution model these prompts implement. # Organizations & Users Source: https://docs.hicap.ai/concepts/organizations-and-users How accounts, users, and personal keys fit together on the Hicap AI Gateway Your account on the Hicap AI Gateway is an **Organization** — a company or team made up of **Users**. Applications, Connections, and Keys are owned by the Organization by default, so usage and spend roll up across everyone who works in it. Individual Users can also own **personal** keys, which appear in their own space and still roll up to the Organization. ## Organizations An **Organization** is the top-level account. It contains your Users and the Applications they build, and it is where billing and usage ultimately roll up. A User can belong to more than one Organization, but there is no standalone "personal account" that exists outside of an Organization — personal work still lives within one. Think of the Organization as the company, and each User as a seat within it. An Organization doesn't have to be a big team, though: a **solo user is simply an Organization of one**. You still get the same structure — billing, Applications, and usage roll up to your Organization — whether you're the only member or one of hundreds. ## Users A **User** is an individual person. A User can belong to one or more Organizations; within each one they sign in, build, operate, and govern Applications, and view the usage and spend they're allowed to see. Billing and usage always roll up to the Organization the work was done in. ## Who owns what Ownership sits at two levels. The Organization owns things by default; a User can additionally own personal work. The default. Applications — and therefore their Connections and Keys — belong to the **Organization**. Anyone with the right access in the Organization can see them, and their usage rolls up to the Organization. A User can own their **own** Applications and Keys for personal tooling — an IDE assistant, a local script, an API client, and the like. These live in the User's personal space and roll up to **both** the User and the Organization. Personal keys are ordinary Applications and Keys — they simply carry an ownership marker that says they belong to a User rather than to the Organization at large. Everything in the [Applications, Connections & Keys](/concepts/applications-connections-keys) hierarchy still applies. ## Access Access is intentionally simple today: * **Organization admins** manage Organization-owned Applications and can see and manage the Organization's keys — their names, status, and usage, not the secret values. * **Members** manage their own personal keys. Finer-grained roles beyond admin and member aren't part of the model yet. ## How this connects to attribution Organizations and Users describe *who* people are and *what they can reach* — this is different from how a request is labeled. For the structural hierarchy that spend rolls up through, see [Applications, Connections & Keys](/concepts/applications-connections-keys). For the labels you choose per request, see [Tags, Dimensions & Segments](/concepts/tags-dimensions-segments). # Tags, Dimensions & Segments Source: https://docs.hicap.ai/concepts/tags-dimensions-segments How the Hicap AI Gateway labels and groups traffic so you can slice usage and spend by what you send on each request Dimensions are tag keys attached to each request. Segments group requests using rules across one or more dimensions. ## Definitions * A **tag** is a `key:value` pair attached to a request. * A **dimension** is the key part of a tag, such as `agent`, `channel`, `env`, `feature`, or `system`. * A **dimension value** is the value assigned to that key. * A **segment** is a named, rule-defined subset of traffic created by combining tags across one or more dimensions with `AND`/`OR`. Tags are how you describe a request as you send it. Dimensions are the keys you tag along, and segments are named combinations of tags that select the requests you care about. Dimensions describe a *request*. They are not the same thing as **Organizations**, **Applications**, **Connections**, or **Keys**, which describe how you are provisioned and roll up on their own — see [Organizations, Applications, Connections & Keys](/concepts/applications-connections-keys). In particular, a **team** is a group of users inside your Organization, not a dimension you send on a request. ## How tags are sent Attach tags to any request with the `x-hicap-tags` header. Its value is a JSON object mapping dimension keys to their values. ```bash theme={null} curl https://api.hicap.ai/v1/chat/completions \ -H "api-key: $HICAP_API_KEY" \ -H "Content-Type: application/json" \ -H 'x-hicap-tags: {"feature": "product-recommendations", "channel": "web", "env": "production"}' \ -d '{ "model": "gpt-5.5", "messages": [ { "role": "user", "content": "Recommend a product" } ] }' ``` ```javascript example.mjs theme={null} import OpenAI from "openai"; const client = new OpenAI({ baseURL: "https://api.hicap.ai/v1", apiKey: process.env.HICAP_API_KEY, defaultHeaders: { "api-key": process.env.HICAP_API_KEY }, }); const tags = { feature: "product-recommendations", channel: "web", env: "production" }; const response = await client.chat.completions.create( { model: "gpt-5.5", messages: [{ role: "user", content: "Recommend a product" }], }, { headers: { "x-hicap-tags": JSON.stringify(tags) } }, ); console.log(response.choices[0].message.content); ``` ```python example.py theme={null} import json import os from openai import OpenAI client = OpenAI( base_url="https://api.hicap.ai/v1", api_key=os.environ["HICAP_API_KEY"], default_headers={"api-key": os.environ["HICAP_API_KEY"]}, ) tags = {"feature": "product-recommendations", "channel": "web", "env": "production"} response = client.chat.completions.create( model="gpt-5.5", messages=[{"role": "user", "content": "Recommend a product"}], extra_headers={"x-hicap-tags": json.dumps(tags)}, ) print(response.choices[0].message.content) ``` The header is `x-hicap-tags` (plural), and its value is a single JSON object. Send one header per request — don't repeat the header or use comma-separated pairs. ## Reserved and conventional dimensions Some dimensions are best set once per service so spend can be sliced consistently across every request it makes. Dimensions like `env`, `system`, and `channel` fall into this group — set them once in your client and they ride along on everything. Per-call dimensions like `feature` or `agent` then pinpoint what a specific request was doing inside that service. Note that you don't need a dimension for which Application a request came from — that already rolls up from the Key you called with. This is a convention and a good practice, not an enforced API restriction: enforcement is caller-side today, so it's up to your client to apply these consistently. ## Segments A segment is a named combination of tags. For example, a segment might select every request where the `env` dimension is `production` and the `locale` dimension starts with a European country code. You define the rule once, give it a name, and use it everywhere you report on traffic. ### Segments may overlap Segments are **not** mutually exclusive, and a request does not belong to exactly one segment. Any request can match several segment rules at the same time, and that's expected — segments are lenses you point at traffic, not bins you sort requests into. For example, consider these two segments: * **EMEA Locales** — requests whose `locale` dimension falls in Europe, the Middle East, or Africa. * **Non-English Traffic** — requests whose `locale` dimension is any non-English language. A request from a French-speaking user in Paris matches **both**: it's an EMEA locale *and* it's non-English. Neither segment excludes the other, and reporting on each will legitimately count that request. ### All traffic The unfiltered view of everything is called **All traffic**. All traffic is not itself a segment — it's simply the starting point you see before any segment rule is applied. ### Representative segments These are examples of the kinds of rule-defined segments teams build: | Segment | Selects | | --------------------------- | ---------------------------------------------------------------- | | Batch Workloads | Requests tagged as asynchronous or bulk processing | | Content Supply Chain | Requests that power content generation and enrichment | | EMEA Locales | Requests whose `locale` is in Europe, the Middle East, or Africa | | Non-English Traffic | Requests whose `locale` is any non-English language | | Non-Production Spend | Requests where `env` is anything other than production | | Unattributed Traffic | Requests that arrived without the tags you expect | | Voice Deflection Production | Production requests serving voice deflection | **Unattributed Traffic** is worth calling out: it's how untagged requests surface. If requests show up here, they arrived without the dimensions you rely on — which is the clearest signal that something upstream needs to start tagging. ## Structural vs. descriptive attribution Tags and segments give you **descriptive** attribution: it comes from what you send on the request, is chosen per call, and can be redefined after the fact by editing a segment rule. This complements the **structural** attribution described in [Organizations, Applications, Connections & Keys](/concepts/applications-connections-keys), which comes from which Key you used and is fixed by how you provisioned things. Both roll up into the same spend reporting; they answer different questions. Ready to wire this into your codebase? Hand a coding agent the prompt in [Implement attribution with an agent](/concepts/implement-attribution-with-an-agent). # FAQ Source: https://docs.hicap.ai/faq Frequently asked questions about Hicap ### General Everything you need to know about using Hicap on a day-to-day basis Hicap gives you fast, secure access to top AI models — like GPT-5.4, Claude Opus 4.6, and Gemini 3.1 Pro — at a fraction of the usual cost. We bulk-reserve compute from leading cloud providers and pass the savings to you, all through a simple API. Reserved throughput locks in your compute and pricing — no rate limits, no surprise overages. Think of it like storing water when it's cheap instead of paying full price from the tap during a drought. You commit to a volume up front and get a guaranteed rate, while pay-as-you-go charges you the spot price for every token. If your usage is predictable, reserved throughput saves you money and removes uncertainty. Yes. If you're not ready to commit to reserved capacity, you can use Hicap on a pay-per-use basis. You get the same API, the same models, and the same reliability — you just pay per token at standard rates. It's a great way to get started or handle unpredictable workloads before locking in a reservation. Typical savings are up to 25%. Your savings depend on your model usage blend, commitment length, and capacity needs. We support the latest models across OpenAI, Anthropic, Google Gemini, and more. Available in AWS, Azure, Google Cloud, and top Neo Clouds like Alibaba — we try to be as flexible as our customers are. More models and clouds are coming soon; let us know what you need! Start monthly! Scale up or down with your needs with no long-term lock-in. Want to pay even less? Sign up for a longer commitment for extra savings. No stress. You can burst above your reservation as needed — just contact us, and we'll help you scale up instantly. Your service stays smooth, even during traffic surges. Yes. Hicap works great as one provider in a multi-provider setup. If you use an AI gateway (like LiteLLM, Portkey, or a custom router), you can configure Hicap as the preferred provider for specific models while keeping your existing provider accounts for others. Note that Hicap itself is an inference API — it doesn't provide gateway or routing services. Your gateway handles the routing logic; Hicap handles the inference. ### Security Your trust and data security are our top priority Yes. We use bank-grade encryption (AES-256) and secure communication protocols (TLS 1.3) to protect all data in transit and at rest. Importantly, **Hicap does not store any customer messages or prompts sent to the LLM** — your requests are forwarded to the model provider and responses are returned to you without being logged or retained on our side. No. We never sell or share your data with third parties without your explicit consent. Your information is only used to provide our services. Hicap follows strict incident-response protocols. If a breach were ever to occur, users would be notified immediately per our notification timeline, and we would work with affected customers on remediation steps. For full details on our obligations and response procedures, see our [Terms of Service](https://hicap.ai/terms). Absolutely. You can request data deletion at any time, and we will securely remove your information from our systems in compliance with GDPR and other applicable privacy regulations. Yes. Hicap follows best practices such as encryption, role-based access control, and can be configured to meet compliance requirements like SOC 2 or GDPR. You decide. Hicap gives you full control over which applications you integrate, while keeping internal data and processing private. All traffic between your application and Hicap is encrypted with TLS 1.3. Hicap does not store your prompts or completions — requests are forwarded to the upstream model provider and responses are returned directly to you. Combined with encryption at rest for account and billing data, your sensitive information stays protected end-to-end. Yes. Hicap can be installed within your AWS environment, ensuring that all processing and data requests remain private and isolated. ### Architecture How Hicap fits into your stack Hicap sits between your application and the upstream model providers. Here's the typical flow: ``` Your App ──▶ Hicap API ──▶ Model Provider (OpenAI SDK) api.hicap.ai (OpenAI / Anthropic / Google / etc.) ``` 1. **Your application** calls `api.hicap.ai/v1` using any standard OpenAI SDK 2. **Hicap** authenticates the request, routes it to the optimal provider endpoint using your reserved capacity (or pay-as-you-go), and returns the response 3. **No prompts or completions are stored** by Hicap — only usage metadata for billing If you use an AI gateway, Hicap is configured as a provider upstream — the gateway routes to Hicap, and Hicap routes to the model provider. Two things: the base URL and the API key. If you're already using the OpenAI SDK, just set `base_url` to `https://api.hicap.ai/v1` and use your Hicap API key. No other code changes are needed — the API is fully OpenAI-compatible. # Anthropic Source: https://docs.hicap.ai/providers/anthropic Anthropic Claude models available through the Hicap API All Anthropic models below are accessible through the **Hicap API** using the standard [OpenAI API spec](https://platform.openai.com/docs/api-reference). Point your OpenAI SDK at `https://api.hicap.ai/v1` and use any model ID listed here. For pricing, see the [Model Catalog](https://hicap.ai/models). ## claude-opus-4.6 Claude Opus 4.6 is the latest and most capable Claude model, delivering state-of-the-art reasoning, coding, analysis, and creative output. It offers a 200K context window with efficient prompt caching for cost-effective processing of long inputs.
Best for:
Maximum-capability tasks: advanced agentic coding, deep research synthesis, complex multi-step reasoning, strategic analysis, and high-stakes content generation where quality and depth are paramount.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
This model offers
 ## claude-sonnet-4.6 Claude Sonnet 4.6 is the latest mid-tier Claude model, offering strong reasoning, coding, and instruction following at an excellent cost-to-performance ratio. It balances intelligence and speed with a 200K context window.
Best for:
Enterprise copilots, production coding assistants, document analysis, structured reasoning, and general-purpose AI applications where strong performance at moderate cost is ideal.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
This model offers
 ## claude-sonnet-4.5 Latest mid-to-high tier Claude model (successor to 3.5-Sonnet) that delivers near-Opus-level reasoning with much lower latency and cost. Strong in long-context comprehension (up to 200k+), precise writing, and multimodal analysis (text + image).
Best for:
Enterprise copilots, advanced coding and debugging, legal/financial document analysis, product and design QA, structured reasoning tasks. Ideal when you want high intelligence at practical scale.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
This model offers
 ## claude-haiku-4.5 Lightweight, fastest Claude 4.5 variant, designed for real-time inference and very low compute cost. Maintains solid understanding and summarization abilities, but not deep reasoning.
Best for:
High-throughput chatbots, customer support automation, RAG summarizers, quick document Q\&A, or embedded assistants where speed and affordability matter most.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
This model offers
 ## claude-sonnet-4 Extended version of Claude Sonnet 4V with ultra-long context support (beyond 200k tokens, up to \~1M depending on configuration). Maintains multimodal (text + images) while handling very large corpora.
Best for:
Deep document analysis (legal, technical, research) with embedded visuals, large-scale design system validation, long historical chat/session review, and knowledge-base copilots that need persistent memory across massive inputs.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
## claude-opus-4.5 Claude Opus 4.5 is a high-end reasoning and language model designed for deep analysis, nuanced understanding, and carefully structured responses. It excels at handling complex instructions, long-form content, and sensitive or high-context tasks with a strong emphasis on clarity, safety, and interpretability.
Best for:
Deep reasoning, complex analysis, long-form writing, policy-heavy workflows, and high-stakes tasks where precision, context awareness, and thoughtful responses are essential.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
This model offers
  • \* 200,000 context window
  • \* 64,000 max output tokens
  • \* May 2025 knowledge cutoff
 ## claude-opus-4.1 Claude Opus 4.1 is a drop-in replacement for Opus 4 that delivers superior performance and precision for real-world coding and agentic tasks. It handles complex, multi-step problems with more rigor and attention to detail.
Best for:
Strategic decision-making, in-depth research, advanced coding and debugging, legal/financial/technical analysis, high-stakes content generation (contracts, reports, product strategy docs). Best when quality > cost/latency.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
This model offers
  • \* 200,000 context window
  • \* 32,000 max output tokens
  • \* March 1, 2025 knowledge cutoff
 ## claude-opus-4 Excels in deep reasoning, logical coherence, and creative writing. Handles complex instructions, long documents, and multimodal text+image analysis with high factual reliability. Slightly slower and more expensive than Sonnet models but provides top-tier accuracy.
Best for:
Strategic and analytical tasks where precision, reasoning depth, and interpretability matter most — e.g., legal or financial analysis, multi-step research, technical documentation, and advanced coding/debugging workflows.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
This model offers
  • \* 200,000 context window
  • \* 32,000 max output tokens
  • \* March 1, 2025 knowledge cutoff
 ## claude-3.7-sonnet Claude 3.7 Sonnet shows particularly strong improvements in coding and front-end web development. Along with the model, we’re also introducing a command line tool for agentic coding, Claude Code. Claude Code is available as a limited research preview, and enables developers to delegate substantial engineering tasks to Claude directly from their terminal.
Best for:
Agents with tools and deep reasoning with “extended thinking” and efficient tool use in tokens.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
This model offers
  • \* 200,000 context window
  • \* 64,000 max output tokens
  • \* October 1, 2024 knowledge cutoff
 ## claude-3.5-sonnet Mid-tier Claude 3.5 model offering strong reasoning, coding, and writing quality at a good cost-to-performance ratio. Supports image input (vision) and long context (200k tokens).
Best for:
General enterprise copilots, technical writing, product documentation, Figma/UI reviews, code explanation and debugging. Ideal when you need smart but affordable reasoning.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
This model offers
  • \* 200,000 context window
  • \* 8,192 max output tokens
  • \* April 1, 2024 knowledge cutoff
 ## claude-3.5-haiku Lightweight, fastest and cheapest Claude 3.5 variant. Lower reasoning depth but very low latency. Still capable of handling moderate context sizes and structured reasoning.
Best for:
Real-time assistants, chatbots, RAG queries, customer support, lightweight summarization, or any latency-sensitive app.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
This model offers
  • \* 200,000 context window
  • \* 8,192 max output tokens
  • \* July 1, 2024 knowledge cutoff
 # ElevenLabs Source: https://docs.hicap.ai/providers/elevenlabs ElevenLabs voice AI models available through the Hicap API All ElevenLabs models below are accessible through the **Hicap API**. ElevenLabs provides industry-leading text-to-speech (TTS) and speech-to-text (STT) capabilities. For pricing, see the [Model Catalog](https://hicap.ai/models). ## Text-to-Speech Models ### eleven\_multilingual\_v2 Eleven Multilingual v2 is ElevenLabs' flagship multilingual text-to-speech model, supporting 29 languages with natural-sounding, expressive voice synthesis. It delivers high-quality speech with nuanced prosody and emotional range.
Best for:
Multilingual voice applications, audiobook narration, content localization, accessibility features, and customer-facing voice experiences where natural speech quality is essential.
| Input | | Output | | ------ | - | ------- | | `Text` | | `Audio` |
This model offers
  • \* 10,000 character context window
  • \* 29 language support
 ### eleven\_v3 Eleven v3 is the latest generation ElevenLabs TTS model, delivering improved voice quality, faster generation, and enhanced expressiveness in a compact context window.
Best for:
Real-time voice assistants, interactive applications, short-form content, and latency-sensitive voice experiences where fast generation matters.
| Input | | Output | | ------ | - | ------- | | `Text` | | `Audio` |
This model offers
  • \* 5,000 character context window
 ## Speech-to-Text Models ### scribe\_v1 Scribe v1 is ElevenLabs' speech-to-text transcription model, supporting 90+ languages with accurate transcription of spoken audio into text.
Best for:
Audio transcription, meeting notes, podcast indexing, subtitle generation, and voice-to-text workflows across multiple languages.
| Input | | Output | | ------- | - | ------ | | `Audio` | | `Text` |
This model offers
  • \* 90+ language support
 ### scribe\_v2 Scribe v2 is the latest generation of ElevenLabs' transcription model, offering improved accuracy and language coverage over Scribe v1.
Best for:
High-accuracy transcription, professional media workflows, real-time captioning, and enterprise audio processing where transcription quality is critical.
| Input | | Output | | ------- | - | ------ | | `Audio` | | `Text` |
This model offers
  • \* 90+ language support
 # Google Source: https://docs.hicap.ai/providers/google Google Gemini models available through the Hicap API All Google Gemini models below are accessible through the **Hicap API** using the standard [OpenAI API spec](https://platform.openai.com/docs/api-reference). Point your OpenAI SDK at `https://api.hicap.ai/v1` and use any model ID listed here. For pricing, see the [Model Catalog](https://hicap.ai/models). ## gemini-3.1-pro Gemini 3.1 Pro is Google's latest flagship reasoning model with a 1M token context window, advanced analytical capabilities, and support for long-context tiers. It excels at complex multi-step reasoning and large-scale document analysis.
Best for:
Advanced reasoning, complex multi-step analysis, large-scale document processing, codebase understanding, and enterprise workflows requiring the highest Google Gemini capability.
| Input | | Output | | -------------------------------- | - | ------ | | `Text, Image, Audio, Video, PDF` | | `Text` |
This model offers
  • \* 1,000,000 context window
  • \* Long-context tier above 200,000 tokens
 ## gemini-3.1-pro-preview Gemini 3.1 Pro Preview is the preview channel of Gemini 3.1 Pro with identical capabilities, providing early access to the latest improvements.
Best for:
Same use cases as gemini-3.1-pro — advanced reasoning, document analysis, and enterprise workflows. Use the preview for early access to latest refinements.
| Input | | Output | | -------------------------------- | - | ------ | | `Text, Image, Audio, Video, PDF` | | `Text` |
This model offers
  • \* 1,000,000 context window
  • \* Long-context tier above 200,000 tokens
 ## gemini-3.1-flash-image-preview Gemini 3.1 Flash Image Preview is a fast, cost-efficient model specialized for text-to-image generation and visual content creation. Built on the Flash architecture for low-latency responses.
Best for:
Fast text-to-image generation, iterative image editing, visual asset creation, and design prototyping where speed and cost efficiency are priorities.
| Input | | Output | | ------------- | - | ------- | | `Text, Image` | | `Image` |
## gemini-3-pro-image-preview Gemini 3 Pro Image Preview is a high-capability model for image generation and multimodal visual workflows. It delivers higher quality image outputs compared to Flash variants.
Best for:
High-quality image generation, creative visual content, marketing asset creation, and premium visual workflows where output quality matters more than speed.
| Input | | Output | | ------------- | - | ------- | | `Text, Image` | | `Image` |
This model offers
  • \* 1,000,000 context window
 ## gemini-3-pro-preview Gemini 3 Pro Preview is a next-generation, high-capability model focused on advanced reasoning, deep multimodal understanding, and long-context performance. As a preview release, it showcases cutting-edge improvements in analytical depth, instruction comprehension, and complex problem solving across text and multimodal inputs.
Best for:
Advanced reasoning, complex multimodal workflows, research-oriented tasks, and early adoption scenarios where maximum capability and depth are prioritized over cost or latency.
| Input | | Output | | -------------------------------- | - | ------ | | `Text, Image, Audio, Video, PDF` | | `Text` |
This model offers
  • \* 1,000,000 context window
  • \* 64,000 max output tokens
 ## gemini-3-flash-preview Gemini 3 Flash is a fast and cost-efficient multimodal model designed for responsive interactions and scalable workloads. It balances solid reasoning and multimodal understanding with low latency, making it well suited for high-throughput applications.
Best for:
Low-latency, high-throughput chat, summarization, and multimodal extraction in production environments where speed and cost efficiency are critical.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
## gemini-2.5-pro Extended version of Gemini 2.5 Pro with ultra-long context support (beyond 200k tokens, reaching into the millions depending on setup). Designed to handle large documents, full repositories, or extensive datasets in a single session.
Best for:
Long-context processing: legal contracts spanning thousands of pages, large codebases, academic research, reviewing historical chat/log data. Ideal for copilots that need to “remember” or reason over very large corpora.
| Input | | Output | | --------------------------------- | - | ------ | | `Text, Image, Audio, Video, Code` | | `Text` |
## gemini-2.5-flash Gemini 2.5 Flash is a fast and cost-effective model that balances performance with a wide range of capabilities. It is the first Flash model to feature thinking capabilities, which lets you see the model's thinking process as it generates a response.
Best for:
Low latency/high throughput for chat, summarization, and multimodal extraction at a lower cost.
| Input | | Output | | --------------------------------- | - | --------------------------------- | | `Text, Image, Audio, Video, Code` | | `Text, Image, Audio, Video, Code` |
This model offers
  • \* 1,048,576 context window
  • \* 65,536 max output tokens
  • \* January 1, 2025 knowledge cutoff
 ## gemini-2.5-flash-preview Gemini 2.5 Flash Preview provides early access to the latest Gemini 2.5 Flash improvements. Same fast, cost-effective architecture with thinking capabilities and multimodal support.
Best for:
Same use cases as gemini-2.5-flash — low latency chat, summarization, and multimodal extraction. Use the preview for early access to the latest refinements.
| Input | | Output | | --------------------------------- | - | --------------------------------- | | `Text, Image, Audio, Video, Code` | | `Text, Image, Audio, Video, Code` |
This model offers
  • \* 1,048,576 context window
 ## gemini-2.5-flash-lite Lightweight, optimized version of Gemini Flash, designed for speed and low cost. Trades off some reasoning depth and output quality for efficiency. Maintains multimodal capabilities (text + image input) but focuses on ultra-fast responses.
Best for:
High-throughput, latency-sensitive tasks: chatbots with large user volumes, quick autocomplete, real-time customer support, fast retrieval-augmented generation (RAG), and mobile/embedded use cases where cost and speed matter more than depth.
| Input | | Output | | -------------------- | - | ------------- | | `Text, Image, Audio` | | `Text, Audio` |
This model offers
  • \* 1,000,000 context window
  • \* 64,000 max output tokens
  • \* January 1, 2025 knowledge cutoff
 ## gemini-2.0-flash A Google model that performs like a Pro model with the speed of a Flash model. Multi-modal inputs and outputs, native tool use, great for agentic workflows.
Best for:
High-volume workflows: customer interaction, summarization, data extraction, and fast-response agents. Good when you need speed with decent reasoning.
| Input | | Output | | --------------------------------- | - | -------------------- | | `Text, Image, Audio, Video, Code` | | `Text, Image, Audio` |
This model offers
  • \* 1,000,000 context window
  • \* 8,000 max output tokens
  • \* August 1, 2024 knowledge cutoff
 ## gemini-2.0-flash-lite Ultra-light, lowest-latency Gemini variant. Optimized for efficiency rather than depth, while maintaining multimodal support.
Best for:
Mobile or embedded copilots, lightweight RAG, chatbots, autocomplete, and fast contextual lookups where cost and response time are more critical than complex reasoning.
| Input | | Output | | -------------------- | - | ------ | | `Text, Image, Audio` | | `Text` |
This model offers
  • \* 1,000,000 context window
  • \* 8,000 max output tokens
  • \* February 5, 2025 knowledge cutoff
 # MiniMax Source: https://docs.hicap.ai/providers/minimax MiniMax models available through the Hicap API All MiniMax models below are accessible through the **Hicap API** using the standard [OpenAI API spec](https://platform.openai.com/docs/api-reference). Point your OpenAI SDK at `https://api.hicap.ai/v1` and use any model ID listed here. For pricing, see the [Model Catalog](https://hicap.ai/models). ## minimax-m2.5 MiniMax M2.5 is MiniMax's latest large language model, offering strong reasoning, creative generation, and multilingual support with a 200K context window at competitive rates.
Best for:
Creative content generation, multilingual chat, customer-facing AI applications, and general-purpose workloads where cost-effective performance is needed.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
This model offers
  • \* 200,000 context window
 # Moonshot Source: https://docs.hicap.ai/providers/moonshot Moonshot models available through the Hicap API All Moonshot models below are accessible through the **Hicap API** using the standard [OpenAI API spec](https://platform.openai.com/docs/api-reference). Point your OpenAI SDK at `https://api.hicap.ai/v1` and use any model ID listed here. For pricing, see the [Model Catalog](https://hicap.ai/models). ## kimi-k2.5 Kimi K2.5 is Moonshot's latest frontier model, offering strong reasoning, coding, and multilingual capabilities with a 128K context window. It delivers competitive performance at accessible rates.
Best for:
Multilingual chat, coding assistance, reasoning tasks, and general-purpose AI workloads where cost-effective performance is important.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
This model offers
  • \* 128,000 context window
 # OpenAI Source: https://docs.hicap.ai/providers/openai OpenAI models available through the Hicap API All OpenAI models below are accessible through the **Hicap API** using the standard [OpenAI API spec](https://platform.openai.com/docs/api-reference). Point your OpenAI SDK at `https://api.hicap.ai/v1` and use any model ID listed here. For pricing, see the [Model Catalog](https://hicap.ai/models). ## gpt-5.5 GPT-5.5 is OpenAI's latest flagship model available through the Hicap API. Use the `gpt-5.5` model ID in OpenAI-compatible endpoints for top-tier general-purpose reasoning, coding, analysis, and multimodal workloads.
Best for:
Advanced reasoning, agentic coding, complex analysis, multimodal applications, and production assistants that need the strongest general-purpose OpenAI model available through Hicap.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
  • \* OpenAI-compatible model ID: `gpt-5.5`
  • \* Reference: GPT-5.5 Model
 ## gpt-5.5-pro GPT-5.5 Pro is the pro-tier GPT-5.5 model available through the Hicap API. Use the `gpt-5.5-pro` model ID when your workload needs the highest capability option in the GPT-5.5 family.
Best for:
Deep research, demanding enterprise analysis, high-stakes coding and review workflows, and complex reasoning tasks where quality matters more than speed.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
 ## gpt-5.4 GPT-5.4 is OpenAI's most advanced model, offering a massive 1.05M token context window with state-of-the-art reasoning, coding, and multimodal capabilities. It features long-context tiers above 272K tokens for cost-efficient processing of very large inputs.
Best for:
Ultra-long-context analysis, full-codebase reasoning, massive document processing, and demanding enterprise workflows that require the highest intelligence with extended context.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
  • \* 1,050,000 context window
  • \* Long-context tier above 272,000 tokens
 ## gpt-5.3-chat-latest GPT-5.3 Chat Latest is a conversationally optimized model from the GPT-5.3 family, designed for responsive dialogue and instruction fidelity. It supports a 200K token context window and delivers strong performance across chat-based applications.
Best for:
Interactive chat applications, conversational assistants, customer support, and real-time dialogue where responsiveness and instruction following are critical.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
  • \* 200,000 context window
 ## gpt-5.3-codex GPT-5.3 Codex is a code-optimized variant from the GPT-5.3 family, purpose-built for software development workflows. It excels at code generation, editing, debugging, and agentic coding tasks with a 200K token context window.
Best for:
Agentic coding, code generation, debugging, refactoring, automated development workflows, and IDE integrations that require deep code understanding.
| Input | | Output | | ------------ | - | ------------ | | `Text, Code` | | `Text, Code` |
This model offers
  • \* 200,000 context window
 ## gpt-5.2 GPT-5.2 is a highly capable general-purpose language model designed for advanced reasoning, long-context understanding, and instruction fidelity. It delivers stable, coherent outputs across complex tasks and extended conversations, while supporting multimodal inputs for richer and more contextual responses.
Best for:
Complex reasoning, long-form generation, decision support, and multimodal chat experiences where accuracy, consistency, and instruction adherence are critical.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
  • \* 400,000 context window
  • \* 128,000 max output tokens
  • \* August 31, 2025 knowledge cutoff
 ## gpt-5.2-chat-latest GPT-5.2 Chat is a conversationally optimized variant of GPT-5.2, designed to deliver natural, responsive, and context-aware dialogue. It emphasizes turn-by-turn coherence, low-latency interactions, and strong instruction following in chat-based environments, while retaining advanced reasoning and multimodal understanding.
Best for:
Interactive chat applications, assistants, customer support, and real-time conversational experiences where responsiveness, conversational flow, and contextual continuity are essential.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
  • \* 128,000 context window
  • \* 16,384 max output tokens
  • \* August 31, 2025 knowledge cutoff
 ## gpt-5.1 GPT-5.1 is a reliable and efficient language model that offers strong general-purpose capabilities with balanced reasoning, instruction following, and text generation. It provides consistent performance across common NLP tasks while prioritizing stability and cost efficiency.
Best for:
General-purpose text generation, summarization, content drafting, and standard chat or assistant workloads where reliability and efficiency are more important than maximum reasoning depth.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
  • \* 400,000 context window
  • \* 128,000 max output tokens
  • \* September 30, 2024 knowledge cutoff
 ## gpt-5.1-chat-latest GPT-5.1 Chat is a conversationally tuned language model optimized for responsive, natural dialogue and consistent instruction following. It builds on GPT-5.1’s stable core capabilities while prioritizing low-latency interactions and smooth conversational flow in chat-based applications.
Best for:
Everyday chat assistants, customer support, guided interactions, and conversational interfaces where speed, clarity, and reliability are the primary requirements.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
  • \* 128,000 context window
  • \* 16,384 max output tokens
  • \* September 30, 2024 knowledge cutoff
 ## gpt-5 Full-scale flagship OpenAI model. Delivers state-of-the-art reasoning, creativity, coding, and multimodal support. Handles long contexts (hundreds of thousands of tokens) and complex workflows.
Best for:
Enterprise-grade copilots, advanced software development, strategic research, product/financial/legal analysis, high-quality multimodal content generation. Best when you need maximum depth and reliability.
| Input | | Output | | ------------- | - | ------ | | `Text, image` | | `Text` |
This model offers
  • \* 400,000 context window
  • \* 128,000 max output tokens
  • \* September 30, 2024 knowledge cutoff
 ## gpt-5-chat This use case employs OpenAI's foundational GPT-5 model (which is the default model in the ChatGPT interface). It is a general-purpose multimodal reasoning engine designed to understand, generate, and synthesize complex information in a coherent and contextually relevant manner, simulating a fluid human conversation without requiring a specific “chat” model.
Best for:
General conversational interaction and multimodal reasoning. Ideal for answering questions, generating creative and explanatory content, summarizing documents, translating languages, analyzing images, and serving as a versatile virtual assistant across a wide range of non-specialized tasks.
| Input | | Output | | ------------- | - | ------------------- | | `Text, image` | | `Text, Image, Code` |
This model offers
  • \* 400,000 context window
  • \* 128,000 max output tokens
  • \* September 30, 2024 knowledge cutoff
 ## gpt-5-mini A lighter and faster variant of GPT-5. Preserves strong reasoning and coding ability, but optimized for lower latency and cost. Good balance between performance and efficiency.
Best for:
A lighter and faster variant of GPT-5. Preserves strong reasoning and coding ability, but optimized for lower latency and cost. Good balance between performance and efficiency.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
This model offers
  • \* 400,000 context window
  • \* 128,000 max output tokens
  • \* May 30, 2024 knowledge cutoff
 ## gpt-5-nano Ultra-light, low-latency model. Prioritizes speed and efficiency over advanced reasoning. Best for lightweight tasks where response time and throughput matter more than nuance.
Best for:
Real-time assistants, mobile/edge use cases, autocomplete, customer service chat, high-volume RAG queries. Best when cost + speed > deep reasoning.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
This model offers
  • \* 400,000 context window
  • \* 128,000 max output tokens
  • \* May 30, 2024 knowledge cutoff
 ## gpt-4o OpenAI's high-intelligence flagship model for complex, multi-step tasks. GPT-4o is cheaper and faster than GPT-4 Turbo
Best for:
Multimodal copilots (voice, image, video), real-time assistants, design/code reviews, customer-facing apps, and enterprise agents that require both contextual reasoning + speed.
| Input | | Output | | --------------------------------- | - | ------------------------------ | | `Text, Image, Audio, Video, Code` | | `Text, Audio, Image (limited)` |
This model offers
  • \* 128,000 context window
  • \* 16,384 max output tokens
  • \* October 1, 2023 knowledge cutoff
 ## gpt-4o-mini OpenAI's affordable and intelligent small model for fast, lightweight tasks. GPT-4o mini is cheaper and more capable than GPT-3.5 Turbo
Best for:
Scalable chatbots, QA systems, RAG pipelines, lightweight coding assistants, and UX/product copilots where cost efficiency + responsiveness matter.
| Input | | Output | | ------------------- | - | ------ | | `Text, Image, Code` | | `Text` |
This model offers
  • \* 128,000 context window
  • \* 16,384 max output tokens
  • \* October 1, 2023 knowledge cutoff
 ## gpt-4.1 GPT-4.1 is the flagship model of the new 4.1 family, excelling in coding, following complex instructions, and managing long contexts (up to 1 million tokens), making it the powerful go-to choice for demanding applications.
Best for:
Advanced data analysis, high-fidelity content creation, software architecture design, and analytical copilots requiring maximum reliability and depth.
| Input | | Output | | ------------ | - | ------ | | `Text, Code` | | `Text` |
This model offers
  • \* 1,000,000 context window
  • \* 32,000 max output tokens
  • \* June 1, 2024 knowledge cutoff
 ## gpt-4.1-mini GPT-4.1 mini is optimized for speed and efficiency, being 40% faster then GPT-4o. GPT-4.1 mini offers a balanced approach with robust performance for simpler or time-sensitive tasks, providing faster response times compared to its more feature-rich counterpart.
Best for:
Mid-complexity workflows: documentation QA, data summarization, low-latency coding copilots, or iterative product feedback systems.
| Input | | Output | | ------------ | - | ------ | | `Text, Code` | | `Text` |
This model offers
  • \* 1,000,000 context window
  • \* 32,000 max output tokens
  • \* June 1, 2024 knowledge cutoff
 ## gpt-4.1-nano GPT-4.1 nano is the smallest, fastest, and most cost-effective option of the GPT-4.1 family. GPT-4.1 nano is ideal for high-volume applications such as autocomplete, classification, and extracting details from lengthy documents while maintaining a strong performance profile.
Best for:
Autocomplete, message classification, semantic search ranking, basic natural-language logic tasks, and embedded AI tools. Ideal for speed-critical micro-agents.
| Input | | Output | | ------ | - | ------ | | `Text` | | `Text` |
This model offers
  • \* 1,000,000 context window
  • \* 32,000 max output tokens
  • \* June 1, 2024 knowledge cutoff
 # Zhipu Source: https://docs.hicap.ai/providers/zhipu Zhipu models available through the Hicap API All Zhipu models below are accessible through the **Hicap API** using the standard [OpenAI API spec](https://platform.openai.com/docs/api-reference). Point your OpenAI SDK at `https://api.hicap.ai/v1` and use any model ID listed here. For pricing, see the [Model Catalog](https://hicap.ai/models). ## glm-5 GLM-5 is Zhipu's latest large language model, offering strong bilingual (Chinese–English) capabilities with advanced reasoning and instruction following. It features a 128K context window at competitive rates.
Best for:
Chinese–English bilingual applications, reasoning tasks, content generation, and enterprise workflows in Chinese-language markets.
| Input | | Output | | ------------- | - | ------ | | `Text, Image` | | `Text` |
This model offers
  • \* 128,000 context window
 # Developer Quickstart Source: https://docs.hicap.ai/quickstart Make your first Hicap API request in minutes The Hicap API gives you access to foundation models from OpenAI, Anthropic, Google Gemini, and more — through a single OpenAI-compatible endpoint. Use any standard OpenAI SDK and start building in under 5 minutes. ## 1. Get your API key **Opens the Hicap Platform** — You'll create an account and generate an API key in the [Hicap Platform dashboard ↗](https://platform.hicap.ai/). Then come back here to use it. Export it as an environment variable: ```bash theme={null} export HICAP_API_KEY="your_api_key_here" ``` ## 2. Install an SDK and make your first request ```bash theme={null} npm install openai ``` ```javascript example.mjs theme={null} import OpenAI from "openai"; const client = new OpenAI({ baseURL: "https://api.hicap.ai/v1", apiKey: process.env.HICAP_API_KEY, defaultHeaders: { "api-key": process.env.HICAP_API_KEY }, }); const response = await client.chat.completions.create({ model: "gpt-5", messages: [{ role: "user", content: "Write a one-sentence bedtime story about a unicorn." }], }); console.log(response.choices[0].message.content); ``` Run with `node example.mjs`. ```bash theme={null} pip install openai ``` ```python example.py theme={null} import os from openai import OpenAI client = OpenAI( base_url="https://api.hicap.ai/v1", api_key=os.environ["HICAP_API_KEY"], default_headers={"api-key": os.environ["HICAP_API_KEY"]}, ) response = client.chat.completions.create( model="gpt-5", messages=[{"role": "user", "content": "Write a one-sentence bedtime story about a unicorn."}], ) print(response.choices[0].message.content) ``` Run with `python example.py`. ```bash theme={null} curl -s https://api.hicap.ai/v1/chat/completions \ -H "Content-Type: application/json" \ -H "api-key: $HICAP_API_KEY" \ -d '{ "model": "gpt-5", "messages": [{"role": "user", "content": "Write a one-sentence bedtime story about a unicorn."}] }' ``` That's it — you just called the Hicap API. The same code works with any [supported model](https://hicap.ai/models); just change the `model` parameter. *** ## Switch between models and providers One API, any model. Use OpenAI, Anthropic, or Gemini models through the same endpoint and SDK — no separate integrations needed. ```python theme={null} # OpenAI client.chat.completions.create(model="gpt-5", messages=[...]) # Anthropic Claude client.chat.completions.create(model="claude-sonnet-4.5", messages=[...]) # Google Gemini client.chat.completions.create(model="gemini-2.5-pro", messages=[...]) # Moonshot Kimi client.chat.completions.create(model="kimi-k2.5", messages=[...]) ``` See all available models, context windows, and pricing → [All Models](https://hicap.ai/models) or [models.json](https://hicap.ai/models.json) *** ## Analyze images Send image URLs directly to vision-capable models: ```javascript theme={null} const response = await client.chat.completions.create({ model: "gpt-5", messages: [{ role: "user", content: [ { type: "text", text: "What is in this image?" }, { type: "image_url", image_url: { url: "https://example.com/photo.jpg" } }, ], }], }); console.log(response.choices[0].message.content); ``` *** ## Stream responses Use server-sent events to show results as they're generated: ```javascript theme={null} const stream = await client.chat.completions.create({ model: "gpt-5", messages: [{ role: "user", content: "Explain quantum computing in simple terms." }], stream: true, }); for await (const chunk of stream) { process.stdout.write(chunk.choices[0]?.delta?.content || ""); } ``` *** ## Popular endpoints These are the most commonly used Hicap API endpoints. All follow the [OpenAI API spec](/api-reference/introduction) — if you've used the OpenAI API before, you already know how to use these. | Endpoint | Description | Docs | | ------------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------------------- | | `POST /v1/chat/completions` | Generate text, analyze images, use tools | [Reference →](/api-reference/endpoints/openAI/creates-a-completion-for-the-chat-message) | | `POST /v1/embeddings` | Create text embeddings for search and RAG | [Reference →](/api-reference/introduction#supported-endpoints) | | `POST /v1/images/generations` | Generate images with DALL·E | [Reference →](/api-reference/introduction#supported-endpoints) | | `POST /v1/audio/transcriptions` | Transcribe audio with Whisper | [Reference →](/api-reference/introduction#supported-endpoints) | | `POST /v1/audio/speech` | Generate speech from text | [Reference →](/api-reference/introduction#supported-endpoints) | [Full API Reference →](/api-reference/introduction) *** ## Models Start with `gpt-5` for strong general-purpose performance, or pick a model optimized for your use case. OpenAI's latest flagship model for top-tier reasoning, coding, and multimodal work. Anthropic's flagship. Deep reasoning, coding, and analysis. Google's latest. 1M context, strong multimodal and reasoning. Fast and affordable. Great balance of performance and cost. Ultra-fast. Ideal for high-volume, latency-sensitive workloads. Cost-efficient with thinking capabilities. Great for real-time apps. [View all models →](https://hicap.ai/models) *** ## Why Hicap? We bulk-reserve compute from leading cloud providers and pass the savings to you. OpenAI, Anthropic, Gemini, Moonshot, Zhipu, MiniMax — all through one OpenAI-compatible endpoint. Use the standard OpenAI SDK. Change the base URL. You're done. Start monthly, scale anytime. Switch models with a single parameter change. *** ## Next steps Full endpoint docs, authentication, and request/response schemas. Compare all models by provider, tier, context window, and pricing. Common questions about pricing, security, architecture, and data handling.