Skip to main content
This page is for anyone building a system that calls Prem API without a human watching each call: agent loops, batch jobs, evaluation harnesses, or any tool that fires many requests unattended. Unattended callers hit different failure modes than an interactive app — a truncated response, a burned rate-limit budget, or a duplicated retry does not get noticed until it has already happened many times.
If you want an AI coding agent (Claude Code, Cursor, Windsurf) to help you write this integration, see Use LLMs — it loads the Prem API docs into your coding agent’s context. This page is about the system you build calling Prem API, not the coding agent that helps you build it.

​
Pick your integration

See Developer Experience for both, in detail. For an agent that runs continuously, run the Confidential Proxy as a background daemon rather than in the foreground:
See Confidential Proxy for the full daemon lifecycle (start / stop / status, PID and log files, graceful shutdown).

​
Required configuration

Both integration paths need the same four values. Set them once, in the environment the agent runs in — not per call: Get the current PROXY_URL / ENCLAVE_URL values from dashboard.prem.io/endpoints.json at deploy time rather than hardcoding them.

​
Gotchas that only show up at automation scale

These are easy to miss in a one-off script and expensive to miss in a loop that runs thousands of times.
Reasoning models generate a chain-of-thought before every answer unless you turn it off. Those tokens are billed, count against your rate limit, and share the same inference’s token budget as the visible answer — a tight max_completion_tokens can be consumed entirely by reasoning, leaving message.content: null.Default to reasoning_effort: "none" in automated pipelines unless you explicitly consume the reasoning trace.
The encrypted /rvenc/chat/completions endpoint (used by the TypeScript SDK) always responds over text/event-stream, even when you don’t set stream: true in your request. If a second call comes in on the same API key while one is still in flight, it can return 429 with:
This is separate from the per-tier concurrent-request limits in Rate limits. If your agent parallelizes work on the same key, serialize calls per key or use a distinct API key per concurrent worker.
Some 429s come with a structured body and a Retry-After header. Others — for example, throttling applied upstream of the gateway — return a generic body with no Retry-After header at all. Branch on the HTTP status code, not the body shape, and fall back to your own exponential backoff when the header is missing. See Rate limits.
An agent that retries blindly after a timeout or a 5xx can duplicate the underlying action (a file upload, a resource creation). Send an Idempotency-Key header so a retried request has the same effect as the original. See Idempotency.
A null or empty message.content is not necessarily a failed call. If finish_reason is "length", the token budget ran out — from reasoning, from a long answer, or both. Treat it as truncation and retry with a larger max_completion_tokens or a lower reasoning_effort, not as an empty result to discard.

​
A request shaped for unattended use

​
Before you deploy

  • reasoning_effort set deliberately (none by default, or a value you’ve budgeted max_completion_tokens for)
  • Retries use exponential backoff and don’t assume Retry-After is present
  • Idempotency keys on any retried write
  • Concurrent calls on the same API key are serialized, or spread across multiple keys
  • Every response checks finish_reason before treating content as final
  • support_id is logged on every error for support escalation
This checklist is agent-specific. For the full production checklist (key management, tiers, attestation), see Production Checklist.

Rate limits

Limits by tier, retry code, and non-standard 429 bodies.

Idempotency

Make retries safe with the Idempotency-Key header.

Confidential Proxy

Daemon mode, config, and connecting any language.