# Glossary # Glossary The words you meet building on AxForge, in plain language and explained the way AxForge uses them. If a term means something specific here — like _region pinning_ or _zero retention_ — this is where it is pinned down, with links to the page that goes deeper. API basics Capabilities Compatibility & tooling Regions & metering Trust & compliance ## API basics The request you send, the key that authorises it, and the units you are billed in. Everything speaks the OpenAI shape — see the Quickstart. API key # A secret token (prefixed `orx_live_`) that authenticates your requests. Send it as `Authorization: Bearer ` (or `x-api-key`). A key is created with your account and shown in the console; it belongs to one tenant, is pinned to one EU region, and can be revoked at any time. Treat it like a password — never ship it in client-side code. See also: Quickstart · Errors & limits Base URL # The address your SDK or tool points at instead of OpenAI: `https://api.axforge.ai/v1`. Because the API is OpenAI-compatible, pointing an existing client at this base URL — plus your key and a model name — is usually the entire integration. See also: Use with your stack Endpoint # A path under the base URL that does one job: `/chat/completions`, `/embeddings`, `/images/generations`, `/audio/speech`, and so on. Every endpoint takes and returns the same JSON shapes the OpenAI endpoints do. See also: Chat completions Model # The open-weight system that produces the answer. You choose one per request with the `model` field. Models can be named by a stable role (`chat`, `agentic` for tool-heavy work, `vision`, `embeddings`) or by their exact version (`qwen3.8-27b-nvfp4`) — both resolve to the same served model. Call `GET /v1/models` for the live list. See also: Models & pricing · Model catalogue Token # The unit a model reads and writes in — roughly ¾ of a word of English. Prompts are counted as _input_ tokens and answers as _output_ tokens; pricing and your usage balance are both in tokens. Every response carries a `usage` object with the exact counts. See also: Pricing · Usage Context window # The maximum number of tokens a model can consider at once — prompt plus answer. Exceed it and the oldest content is dropped or the request is rejected. Each model lists its window on the models page. See also: Models & pricing Streaming (SSE) # Set `stream: true` and the answer arrives token by token as server-sent events, ending with `data: [DONE]` — so a UI can show text as it is generated. AxForge streams include a final `usage` chunk so streamed answers are metered too. See also: Chat completions System / user / assistant message # The `messages` array carries the conversation. A _system_ message sets behaviour and rules, _user_ messages are the human's turns, and _assistant_ messages are the model's prior replies. Send the whole history each turn — the API is stateless. See also: Chat completions Temperature # A 0–2 dial on randomness. Low (0–0.3) is focused and repeatable — good for extraction and code; high (0.8+) is more varied — good for brainstorming. It does not change what the model knows, only how it samples. See also: Chat completions Usage # The token counts returned with every completion (`prompt_tokens`, `completion_tokens`, `total_tokens`). AxForge records these against your tenant's balance; prompts and answers themselves are never stored. See also: Metering · Regions & data Rate limit # The ceiling on requests per minute for a key. Cross it and you get an HTTP `429` with a `Retry-After` header — back off and retry. Limits protect shared capacity and can be raised for production traffic. See also: Errors & limits ## Capabilities What the one key unlocks — text, vectors, images, and audio — each on an OpenAI-shaped endpoint. Chat completion # The core text endpoint: send a list of messages, get a reply. Handles instructions, Q&A, extraction, code, and multi-turn conversation, with optional tools and image inputs. See also: Chat completions Tool calling (function calling) # You describe functions the model may call; when useful it returns a structured `tool_calls` request instead of prose, your code runs the function and feeds the result back. This is the mechanism agents and MCP tools are built on. See also: Chat completions · MCP Vision # Passing an image alongside text in a chat request so the model can read, describe, or reason about it — screenshots, documents, diagrams, photos. See also: Chat completions Embedding # A vector of numbers that captures the meaning of a piece of text, so that similar meanings sit close together. The building block of search, recommendation, and retrieval-augmented generation. AxForge returns 1024-dim vectors. See also: Embeddings · Semantic search Vector / semantic search # Finding results by meaning rather than exact keywords: embed your documents and the query, then compare vectors. The retrieval half of RAG (retrieval- augmented generation), where you fetch relevant text and pass it to the model as context. See also: Embeddings Reranking # A second pass that scores a shortlist of candidate documents against a query and reorders them by true relevance — sharper than vector similarity alone, and a common step between search and the model. See also: Embeddings Image generation # Creating a picture from a text prompt via `/v1/images/generations`. The response carries the image as base64 PNG in `data[].b64_json`. See also: Image generation & editing Image editing # Changing an existing image from an instruction — pass the source image plus a prompt to `/v1/images/edits` and get an edited PNG back. See also: Image generation & editing Transcription (speech to text) # Turning an uploaded audio file into text via `/v1/audio/transcriptions` — a multipart file upload, OpenAI Whisper shape. See also: Speech & music Speech synthesis (text to speech) # Turning text into spoken audio via `/v1/audio/speech`. See also: Speech & music Music generation # Composing an audio track from a prompt (and optional lyrics) via `/v1/audio/music`. See also: Speech & music ## Compatibility & tooling Why your existing tools work, and the few places the ecosystem has more than one API shape. The practical guides live in Use with your stack. OpenAI-compatible # AxForge implements the same HTTP endpoints, request bodies, and response shapes as OpenAI's API. Any client that can target a custom base URL — SDK, CLI, gateway, or app — works against AxForge by changing three things: the base URL, the key, and the model name. See also: OpenAI alternative in Europe · Use with your stack Chat Completions API # The widely-supported `/v1/chat/completions` surface — messages in, a choice out. The one nearly every tool speaks; AxForge serves it (alongside the Responses and Messages surfaces). See also: Chat completions Responses API # A newer OpenAI surface (`/v1/responses`) that some tools — notably OpenAI's Codex CLI and the default path of a few SDKs — now prefer. AxForge serves it natively at `api.axforge.ai/v1/responses`, alongside Chat Completions, so Responses-only clients point straight at us. See also: Codex & Claude Code Messages API (Anthropic) # Anthropic's `/v1/messages` surface, which Claude Code speaks. It is a different shape from OpenAI's, and AxForge serves it natively at `api.axforge.ai/v1/messages` — so a Claude-native tool points straight at us, no shim required. See also: Codex & Claude Code SDK # A library that wraps the HTTP API for a language — the official OpenAI SDKs (Python, Node) and the Vercel AI SDK are the common ones. All of them take a base-URL option, which is where you point them at AxForge. See also: OpenAI SDK · Vercel AI SDK Gateway # A service that sits in front of one or more model providers behind a single OpenAI-compatible endpoint — for routing, fallback, budgets, or key management. AxForge is a provider you can put behind a gateway; a gateway is not a substitute for a provider. See also: LiteLLM MCP (Model Context Protocol) # An open protocol that lets an AI app (the _host_, e.g. an IDE agent) connect to external tools and data through _MCP servers_. It is a client-side protocol, separate from how inference is served: MCP tools are driven by the model's tool calling in ordinary chat requests, so AxForge powers MCP-based agents without needing to "speak MCP" itself. See also: Use with your stack LiteLLM # An open-source proxy that fronts an OpenAI-compatible upstream like AxForge and re-exposes it on the Chat Completions, Anthropic Messages, and Responses surfaces at once. AxForge serves all three natively, so LiteLLM is optional — reach for it when you want a gateway (budgets, fan-out, many providers). See also: LiteLLM ## Regions & metering Where inference runs, how you keep it there, and what is kept afterwards. Region # A physical location where your workload runs: `eu-se-1` (Stockholm, Sweden) for serverless inference and `eu-es-1` (Málaga, Spain) for dedicated GPU rental. The console shows the region and machine your key runs on, and every response carries the model identity. See also: Regions & data · Data residency Data residency # The guarantee that your requests are processed and any metadata is kept within a chosen jurisdiction — for AxForge, the EU. The basis for GDPR and sovereignty commitments. See also: Data residency · GDPR EU-hosted / sovereign AI # Inference on infrastructure located and operated in the EU, on open-weight models, with no dependency on a non-EU cloud in the request path — so data does not leave the jurisdiction to be processed. See also: Sovereign AI cloud · EU AI API Region pinning # Binding a key to one region so inference only ever runs there. Every API key is pinned to `eu-se-1` (Stockholm); the console shows the region and machine, and every response carries the model identity. See also: Regions & data Zero retention # Prompts and completions are processed and discarded — never written to disk, logged, retained, or used for training. Only request metadata (token counts, timestamps, status) is kept, and only for billing. See also: Retention · Privacy In-memory processing # Handling a request entirely in RAM for the moment it is served, with nothing about its content persisted afterwards — how zero retention is achieved in practice. See also: Retention Tenant # Your isolated account boundary. Keys, usage, and any stored configuration belong to a tenant, and one tenant can never see another's data. Signing up creates your own tenant. See also: Regions & data Workspace # A named project inside a tenant — a place to group an agent or deployment, its knowledge, and its settings in the console. Optional for raw API use. See also: Console Deployment # A configured, addressable instance of an agent or endpoint you have published — with its own public slug and access controls — as opposed to a raw model call. See also: Console Usage record / metering # The billing event AxForge writes after a token-priced call, recording the model and token counts against your tenant's balance. It captures counts and metadata only — never the prompt or the answer. See also: Usage · Pricing ## Trust & compliance The vocabulary that shows up in procurement, DPAs, and audits — defined as they apply to AxForge. This is orientation, not legal advice. GDPR # The EU General Data Protection Regulation, governing how personal data is processed. EU-hosted, zero-retention inference is what makes AxForge straightforward to use under it. See also: GDPR & AI · Trust centre DPA (Data Processing Agreement) # The contract that sets out how a processor handles personal data on a controller's behalf. AxForge offers one for customers who send personal data through the API. See also: DPA Sub-processor # A third party a processor uses to help deliver the service. AxForge's EU-hosted design keeps this list short and in-jurisdiction; it is published for transparency. See also: Trust centre · DPA Data controller / processor # Under GDPR, the _controller_ decides why and how personal data is processed (you), and the _processor_ acts on the controller's instructions (AxForge, for the data you send). See also: DPA EU AI Act # EU regulation classifying AI systems by risk and setting obligations accordingly. Your obligations depend on what you build; AxForge provides the transparency inputs (model provenance, region, retention) you need to document it. See also: EU AI API · Model transparency Model transparency # Publishing which open-weight models serve each capability, and where, so you can record provenance for your own compliance. AxForge's models are open-weight and named per capability. See also: Model transparency · Models & pricing No-training commitment # AxForge does not train on customer prompts or completions. Combined with zero retention, your content is used to serve your request and nothing else. See also: Retention · Privacy PII (personal data) # Information that identifies a person. You remain the controller for any PII you send; AxForge's zero-retention processing means it is not persisted, but handling it responsibly — minimising and having a lawful basis — is your call. See also: Rules & responsibilities · GDPR ← Quickstart Models & pricing → Source: https://axforge.ai/docs/glossary/