Skip to main content

Overview

The NanoGPT API offers multiple ways to generate text, including OpenAI-compatible endpoints and our legacy options. This guide covers all available text generation methods. If you are using a TEE-backed model (e.g., prefixed with TEE/), you can also verify the enclave attestation and signatures for your chat completions. See the TEE Model Verification guide for more details. For authenticated API-key requests, you can opt in to a paid input safety preflight by sending the moderation header. See Inline Moderation for supported text routes, model selection, billing behavior, and error codes.

Provider Selection

Provider selection is available for supported open-source models. X-Provider explicitly selects a provider for the request and is always billed pay-as-you-go at the selected provider’s price, including provider-selection markup. For subscription users, sending X-Provider bypasses subscription coverage for that request; X-Billing-Mode: paygo is only needed when forcing pay-as-you-go without an explicit provider or when saved provider preferences should apply to subscription-included traffic. See Provider Selection and Pay-As-You-Go Billing Override. For one-off routing preferences, append a suffix to eligible model IDs:
  • :fast / :speed for fastest estimated completion
  • :cheap / :price / :floor for cheapest provider
  • :throughput for highest TPS
  • :latency for lowest TTFT
  • :tools for tools-capable routing
See Model Suffixes for the complete suffix list and conflict rules.

OpenAI Compatible Endpoints

Chat Completions (v1/chat/completions)

This endpoint mimics OpenAI’s chat completions API: For high-volume offline workloads where latency is not important, use the Batch API to upload JSONL chat completion requests and process them asynchronously.

Responses (v1/responses)

Use the OpenAI Responses-compatible endpoint for stateful threading (previous_response_id), background processing, and Responses-style streaming events. See the dedicated docs at /api-reference/endpoint/responses.

Direct Web Search (api/web)

Use POST /api/web when you need direct search control instead of chat orchestration:
  • Explicit query payload control
  • Linkup output types: searchResults, sourcedAnswer, structured
  • Date and domain filters (fromDate, toDate, includeDomains, excludeDomains)
See Direct Web Search API for request/response schema, pricing, and error codes.

Text Completions (v1/completions)

This endpoint mimics OpenAI’s legacy text completions API:
POST /api/v1/completions is best effort. Performance and compatibility may be less consistent than POST /api/v1/chat/completions because not all providers we route to support the legacy completions API.

Legacy Text Completions

For the older, non-OpenAI compatible endpoint:

Caching (Implicit and Explicit Controls)

For the full guide (supported models, thresholds, pricing, and usage fields), see Prompt Caching. NanoGPT automatically applies implicit caching on providers/models that support it (including OpenAI, Gemini, and many open-source provider/model routes), so most requests do not need caching flags. Set top-level caching: true or append :caching / :cache / :cached to the model when you want NanoGPT to route the request to any available provider that supports prompt/input caching. This is capability-based routing: you do not need to choose a provider. If no cache-capable provider is available for the model, the request fails rather than silently using a non-caching provider. Use explicit prompt-caching controls (prompt_caching, promptCaching, and body-level cache_control alias, plus inline cache_control) when you need Claude-specific cache boundaries, TTL selection, or prompt_caching.stickyProvider consistency control. Top-level caching: true does not add Anthropic-style cache_control markers or configure cache TTLs.

Cache-Capable Provider Routing

By default, caching: true enables sticky provider routing. After the first successful matching request, NanoGPT will try to use the same provider for later matching requests from the same API key or session, improving the chance of provider-side cache hits. This does not guarantee that a request will be served from cache. To require a cache-capable provider without sticky routing, set stickyprovider: false:
Top-level stickyProvider is also accepted as a camelCase alias for stickyprovider. Equivalent model suffix:
For caching: true, NanoGPT filters to available, non-excluded, prompt-caching-capable providers; prefers the recorded sticky provider when enabled and still usable; otherwise chooses the cheapest cache-capable provider by base input + output price. Cache write/read pricing is used only as a tie-breaker. The prompt_caching / promptCaching helper accepts these options:

Explicit cache_control markers

  • cache_control belongs to individual content blocks (system, user, tool definitions, etc.). Each marker caches the entire prefix up to and including that block.
  • Supported explicit TTLs are 5m and 1h (Claude flows). Omit ttl to use the default 5m window.
  • anthropic-beta: prompt-caching-2024-07-31 is supported for compatibility and required for Anthropic-native Claude caching flows.
  • For implicit-caching providers, no explicit cache_control markers are required.
  • Check usage.prompt_tokens_details.cached_tokens in NanoGPT’s response to confirm what was billed at the discounted rate.

Using the prompt_caching helper

If you prefer not to duplicate cache_control entries manually, NanoGPT accepts a helper object that tags the leading prefix for you.
cut_after_message_index is zero-based and points at the last message in the static prefix. NanoGPT will attach a cache_control block with your TTL to each message up to that index before forwarding the request upstream. If you omit cut_after_message_index, NanoGPT will select a cache boundary automatically; set it explicitly if you need full control. If you need different cache durations or non-contiguous breakpoints, fall back to explicit cache_control markers in your messages array.

Explicit Prompt Cache Consistency

NanoGPT automatically fails over to backup services when the primary service is temporarily unavailable. While this ensures high availability, it can break your prompt cache because each backend service maintains its own separate cache. If cache consistency is more important than availability for your use case, you can enable the stickyProvider option:
Behavior:
  • stickyProvider: false (default) — If the primary service fails, NanoGPT automatically retries with a backup service. Your request succeeds, but the cache may be lost (you’ll pay full price for that request and need to rebuild the cache).
  • stickyProvider: true — If the primary service fails, NanoGPT returns a 503 error instead of failing over. Your cache remains intact for when the service recovers.
When to use stickyProvider: true:
  • You have very large cached contexts where cache misses are expensive
  • You prefer to retry failed requests yourself rather than pay for cache rebuilds
  • Cost predictability is more important than request success rate
When to use stickyProvider: false (default):
  • You prefer requests to always succeed when possible
  • Occasional cache misses are acceptable
  • You’re using shorter contexts where cache rebuilds are inexpensive
Error response when stickyProvider blocks a failover:
Enable real-time web access for any model by appending special suffixes:

Web Search Options

  • :online - Standard search with 10 results ($0.006 per request)
  • :online/linkup-deep - Deep iterative search ($0.06 per request)
For the full provider-specific suffix list, including :online/exa-instant, :online/exa-deep-reasoning, :online/brave, and :online/valyu-web-deep, see Model Suffixes. Web search dramatically improves factuality - Gemini 3 Flash Preview with web access shows a 10x improvement in accuracy, making it twice as accurate as non-web baselines. For direct /api/web usage with structured output, domain/date filters, and explicit query control, see Direct Web Search API.