Learn · Start here
Start here
New to AI infrastructure? These 10 short steps explain the ideas behind Gatewayz in plain language, in the order they build on each other. Reading all of them takes about ten minutes; each step links to a full guide.
Step 1 of 10
What Gatewayz is
Gatewayz is a single place to call AI models made by different companies. Instead of opening an account, managing a key and learning a slightly different API with each model provider, you get one API key, one prepaid balance and one address to send requests to. Your code can ask for a model from OpenAI, Anthropic, xAI, Moonshot or Meta by name, and the request goes to that exact model. Gatewayz has no model of its own and does not decide which model you should use. It passes your request to the provider you named, bills the tokens at the provider's list price plus a routing fee, and returns errors in a consistent, machine-readable shape so software can react correctly. It matters to you if you use more than one model, want one bill and one set of spending limits, or run software agents that need predictable behavior when something goes wrong. It also adds a dependency, so the trade-offs are worth understanding before you switch.
Takeaway: Gatewayz gives you one key, one balance and one consistent contract for models from several providers, without choosing or swapping the model you asked for.
Read the full guide →Step 2 of 10
Inference
Inference is what happens every time you use an AI model: you send it some input, and it produces an output. It is different from training, the one-time, very expensive process of building the model in the first place. A useful comparison is a textbook. Writing it takes years, but every reader who opens it afterwards is a separate event. With AI, every question, every chat message and every step an agent takes is a new inference request, and each one runs on real hardware. That is why inference is the ongoing cost of AI, billed per use in units called tokens. Language models also produce their answer one token at a time, so longer answers take longer and cost more. Understanding inference helps you read an AI bill, estimate what a feature will cost at scale, and see why the choice of model and the length of prompts and answers matter more than the number of users alone.
Takeaway: Training builds a model once, inference runs it on every request, and because each request uses compute and produces output token by token, inference is the recurring cost of AI.
Read the full guide →Step 3 of 10
Compute
AI compute is the hardware that does the arithmetic behind every model response: processors, the memory attached to them, and the data centers that power and cool them. Modern language models run on accelerators such as the GPU rather than on a general purpose CPU, because a model is mostly enormous grids of numbers multiplied together, and GPUs do thousands of those multiplications at once. The model's weights also have to fit in the accelerator's own memory, which is why the hardware is scarce and expensive. A small number of groups own most of it: the companies that build models, the large cloud platforms, and a growing set of independent GPU owners. Whoever owns the hardware sets the price of running a model on it, and that price reaches you as a per-token charge. Knowing this helps you read AI pricing, understand why some requests cost more than others, and ask sensible questions about where your prompts actually run.
Takeaway: Every AI response is arithmetic on specialized hardware someone owns, and the cost of that hardware is what you ultimately pay for per token.
Read the full guide →Step 4 of 10
Tokens and pricing
A token is the unit a language model reads and writes: a short chunk of text, often a whole common word, part of a longer word, a punctuation mark or a space. Before a model sees your prompt, a tokenizer splits it into tokens, and the model's answer comes back as tokens too. Almost all language model APIs charge by counting them, usually quoting a price per million tokens, with separate rates for the tokens you send and the tokens the model generates. The context window caps how many tokens a single request can hold. This matters to you because tokens, not requests, drive your bill: a long document, a growing chat history or an agent that loops many times can cost far more than a quick question. Once you know how tokens are counted, you can predict costs, compare prices on equal terms, and cut spend by limiting output, trimming context, reusing cached prefixes and setting request caps.
Takeaway: You pay for tokens in and tokens out, so cost control means sending less, generating less, reusing cached prefixes and capping how many requests can run.
Read the full guide →Step 5 of 10
Models and providers
An AI model is a trained set of numbers, called weights, plus the software that runs them. A model provider is the company that trains or hosts a model, sets its list price, and decides when versions are released and retired. Every request you send names a model with a short text id, and that id is more consequential than it looks. Some ids are dated snapshots that always mean the same model. Others are aliases that can move to a newer version without you changing a line of code. This guide explains the difference, why production systems should pin exact versions, which providers are in the Gatewayz catalog today, and how to read the live catalog yourself so the ids in your code are ones that actually exist.
Takeaway: Treat a model id as a version number: pin a dated snapshot in production, check it against the live catalog, and expect an unknown id to be refused rather than replaced.
Read the full guide →Step 6 of 10
APIs, endpoints and keys
An API is the agreed way one program asks another program to do something. For AI models, that means your code sends a request over the internet describing which model to use and what to say, and gets the model's reply back as structured data. An endpoint is the specific web address that accepts one kind of request, such as a chat request. An API key is the secret string that proves the request comes from your account, so usage can be authorized and billed. This guide walks through what a real request looks like, the two request formats most AI tools use, why having one key for many models simplifies your setup, how to protect that key like a password, and how to read the status codes that tell you whether a failed request is worth retrying.
Takeaway: Every AI request is a method, a URL, a few headers and a JSON body, and the status code on the reply tells your code whether to fix the request, fix the account, or wait and try again.
Read the full guide →Step 7 of 10
Agents
An AI agent is a program that uses a language model to decide what to do next, calls tools to act on that decision, and repeats until a task is done. The difference from a chat assistant is who is in the loop. When you chat, you send a few prompts and read every answer. An agent may send dozens or hundreds of requests to a model with nobody watching, and it keeps going until something tells it to stop. That changes what matters about the API underneath. Error messages written for people go unread, so the status code and a stable error code become the agent's only way to tell a typo from an outage. A loop that retries the wrong errors can spend a budget in an afternoon, so a request cap per key is a safety device, not an accounting detail. If you build, fund or operate agents, this guide explains what they are and how they should react when a request fails.
Takeaway: An agent is a model plus tools plus a loop that runs unattended, so its errors must be readable by code and its spend must be capped before it starts.
Read the full guide →Step 8 of 10
Routing
An AI gateway sits between your application and the companies that serve AI models. You integrate with it once, using one API key and one request format, and it forwards each request to the provider that serves the model you named. Switching from one provider's model to another's becomes a change to a single string instead of a new integration. A gateway can also send a request to a different route serving the same model when one route is degraded. What a trustworthy gateway should not do is quietly run a different model than the one you asked for, because your costs, test results and product behavior all depend on that model. Gatewayz works this way: it resolves an alias to one exact dated snapshot, refuses an unknown id with a clear error, and leaves the choice of model to you. If you are deciding whether to call providers directly or through a gateway, this guide explains the trade-offs in plain terms.
Takeaway: A gateway gives you one integration and one-string model switching, but the model you name should be the model that runs, every time.
Read the full guide →Step 9 of 10
Security
An API key is a password for spending money on AI models, so the questions that matter are simple: how is the key protected, what happens to the text you send, and what can you do if a key leaks. Gatewayz checks every API key on every request against its status, expiration date and request cap, records security events in an audit log, and lets you deactivate, expire or delete a key at any time. On ordinary API calls it keeps billing metadata such as token counts, model, status and timing, not your prompts or completions. It cannot hide your prompt from the model provider that runs it, and a few opt-in features do store or expose content. Security is shared: Gatewayz protects the key once it has it, and you decide where the key lives, how much it can spend and how fast you replace it when something goes wrong.
Takeaway: Gatewayz enforces limits on every key and keeps no prompt content on ordinary calls, but the provider still sees your prompt and only you control where your key lives.
Read the full guide →Step 10 of 10
First request
This guide takes you from nothing to a working AI model call through Gatewayz. You create an API key, check which model ids exist in the public catalog, then send one request with curl and the same request with the OpenAI Python SDK. Because Gatewayz exposes an OpenAI-compatible endpoint, code already written for the OpenAI SDK usually needs only a new base URL, a new key and a provider-namespaced model id. Switching between an Anthropic model and an OpenAI model is a one-line change to the model string. The guide also explains what the common error responses mean, which ones are worth retrying and which ones need you to change something, and ends with a short checklist for common setup mistakes, such as a doubled /v1 in the URL or a missing Bearer prefix.
Takeaway: One key, one base URL and a provider-namespaced model id are all you need, and the status code tells you whether to retry or fix the request.
Read the full guide →
Ready to try it?
The quickstart gets you from a key to a working request. Unfamiliar terms are defined in the glossary.