Akamai Inference Puts 12 Open Models Behind One API in Beta: How to Request Access

Akamai, the company best known for running a huge content delivery network, launched two AI products on 27 October 2026: Akamai Inference and Akamai Agent Sandbox. Both are in beta on Akamai Cloud. The headline for builders is simple. Akamai Inference serves open weight and custom models through OpenAI compatible APIs, so an app that already talks to an OpenAI style endpoint can point at Akamai without rewriting its request code. The Agent Sandbox gives agent written code a separate, isolated place to run, with limits on compute, memory, and outbound connections. That combination matters because the two hardest parts of shipping an agent feature are usually model access and safe execution. Model access means hosting, scaling, and paying for a model without operating a serving stack yourself. Safe execution means stopping agent written code from doing something you did not approve, such as reaching an internal service, exfiltrating data, or running forever. Akamai is selling both layers together, on a network that already spans more than 4,350 edge locations, according to the launch coverage. Edge placement is the latency argument. If inference runs close to your users and your data, interactive workloads should respond faster than when every request travels to a single central region.

Which 12 models are included, and what do they cover?

Akamai says the launch catalog contains 12 open weight models spanning 8 billion to 2.8 trillion parameters, alongside embedding models for retrieval work. The named models in the launch coverage include NVIDIA Nemotron 3 Ultra, OpenAI gpt-oss-120b, and Google Gemma 4. That range is the point. A small 8 billion parameter model is for fast, cheap, high volume work such as classification, summarisation, and first pass drafting. A very large model at the top of the range is for harder reasoning, coding, and agentic work where quality matters more than speed. Embedding models matter for a different job: turning your own documents into searchable vectors so a model can pull in the right company material before it answers, which is the retrieval augmented generation pattern most business apps use. Do not read the model count as a promise that every model suits every job. Open weight means the weights are available to run, not that every model is free forever, unlimited, or equally good at your task. Some models are better at coding, some at long documents, some at tool use. The practical test is to run the same five tasks from your own product on two or three candidate models through the same API shape, and compare quality, latency, and cost per finished task. Akamai's OpenAI compatible API makes that comparison cheaper to run, because you change the model name and the endpoint, not your whole client. Custom models are also part of the pitch. Akamai says teams can bring their own or hosted open weight models, ground them in their own data, and serve them on the same platform. That is aimed at teams that have fine tuned a model for a specific domain, such as legal, medical, or support documents, and do not want to operate GPU servers to serve it. If you do not have a custom model, ignore that part for now. The immediate value is the managed catalog, not the custom path.

How does the OpenAI compatible API actually help you?

An OpenAI compatible API means the request and response shapes follow the conventions developers already use for chat completions and related endpoints. In practice, that means you can often reuse your existing SDK, your prompt templates, your retry logic, and your logging, and change only the base URL, the API key, and the model name. That is a much smaller migration than adopting a vendor specific SDK, and it makes it easier to switch back if the beta does not suit you. It does not mean every feature transfers perfectly. Tool calling behaviour, streaming details, rate limits, context limits per model, and error messages can differ between providers even when the API shape looks the same. Test tool calls, long prompts, and error handling on Akamai before you move production traffic, and keep your old provider configured as a fallback during the test. A compatible API reduces migration work. It does not remove testing work, and any post that tells you to switch production traffic on day one of a beta is skipping the step that protects your users. Serverless and dedicated deployments are the two serving choices Akamai describes. Serverless, pay per use inference suits a feature that needs to go live this quarter without operating a serving stack, and where traffic is variable. Dedicated deployments on GPU clusters suit teams that need control over model versions, deprecation timelines, and tenancy, and that have steady, high volume traffic. Akamai has added Nvidia Blackwell Ultra clusters to its GPU fleet, according to the launch coverage, which is aimed at that dedicated tier. Choose serverless first for a test, and only move to dedicated when you have steady traffic numbers to justify reserved capacity.

What is the Agent Sandbox, and what does it block?

The Agent Sandbox runs on Akamai Functions and confines agent generated JavaScript or Python inside an additional restricted runtime built around WebAssembly isolation. Akamai's senior vice president of cloud technology, Jon Alexander, put the reason plainly in the launch release: every team running agents needs a boundary around the code those agents write. That boundary is the product. The sandbox sets limits on compute, memory, outbound connections, and system capabilities, and its default network policy blocks outbound access from agent generated code, so that code can reach only the services a team explicitly permits. That default block is the feature to test first. Many agent failures are not model failures. They are execution failures: an agent writes code that calls an unexpected endpoint, reads a credential, or loops until a bill explodes. A sandbox that blocks outbound access by default forces you to list the services an agent may reach, which is exactly the allow list discipline that production agents need. It also limits the blast radius if a prompt injection attack tricks an agent into running hostile instructions, because the injected code still runs inside the restricted runtime, not on your production server. There are limits to be honest about. The sandbox preview currently supports intermittent execution steps of roughly a minute, according to the beta coverage, and continuously running, stateful agents are a future capability, not a current one. That means the sandbox today fits agents that work in steps, such as drafting, checking, transforming, and calling an approved tool, and then stopping. It does not yet fit an agent that must run all day, hold state across hours, and react continuously. Akamai also describes the sandbox as an open source component of the Spin framework, so teams can evaluate the Spin foundation locally while requesting access to the managed preview. If your agent needs long running state, test that path locally first, and do not promise a customer an always on agent on a preview that only supports short steps.

How do you request beta access, and what does it cost?

Access is by request, and the details differ between the two products in the coverage checked. Akamai Inference is described as a closed beta in its documentation, while the Agent Sandbox is offered as a request access tech preview. That means you cannot assume instant signup, instant keys, and unlimited use on day one. Request access through Akamai's product pages, describe your workload honestly, and plan for a wait or a limited allocation. If you need model access today for a shipping product, keep your current provider running while you wait for beta access, and treat Akamai as a second option to test, not as a replacement you depend on yet. Pricing needs the same honesty. One secondary writeup of the beta reports no charge during the inference beta, with future serverless billing by input and output tokens and dedicated GPU capacity billed for provisioned time. Other launch coverage states plainly that the release does not state pricing. Both can be true at once: a beta may carry no charge for admitted testers, while no public price card has been published for what comes after. This article therefore does not publish a per token price for Akamai Inference, because no official price card was verified in the sources checked for this article. Do not budget a production product on an assumed free tier. Budget on your current provider's prices, and treat any beta period as a test window that will end. When Akamai publishes official rates, compare them on your own token mix, not on a headline rate.

Who should try it first, and who should wait?

Try it first if you build agent features, if you already use OpenAI compatible APIs, or if you run open weight models and want a managed endpoint without operating GPUs. The fastest useful test is small: move one non critical feature, such as document summarisation or a support draft generator, to one Akamai model through the compatible API, run it behind the sandbox allow list for any generated code, and measure latency, quality, and cost per finished task against your current setup for two weeks. That test gives you a real comparison, not a benchmark claim. Wait, or test only in a sandbox account, if your agent needs continuous long running state, if you need guaranteed pricing for a customer contract, or if you cannot tolerate a beta service changing limits, models, or terms. Betas change. Model catalogs change. Rate limits change. A beta is the right place to learn, and the wrong place to host a promise you have already sold. The Akamai launch is still worth watching closely, because a CDN operator with 4,350 edge locations and more than $14 billion in multiyear Akamai Cloud contracts, as reported at launch, is not a hobby project. It is a serious attempt to make inference and agent execution a normal cloud service, close to users, with security built into the execution layer. Request access now, test honestly, and decide on your own numbers. Key takeaways:

• Akamai launched Akamai Inference and Akamai Agent Sandbox in beta on 27 October 2026 on Akamai Cloud.
• Inference offers 12 open weight models from 8 billion to 2.8 trillion parameters, plus embedding models, through OpenAI compatible APIs, with serverless and dedicated options.
• Named launch models include NVIDIA Nemotron 3 Ultra, OpenAI gpt-oss-120b, and Google Gemma 4.
• Agent Sandbox isolates agent written JavaScript and Python with WebAssembly isolation, blocks outbound access by default, and currently fits short, intermittent steps of roughly a minute, not always on agents.
• Beta access is by request, described as closed beta for Inference and request access preview for the Sandbox, and no official public price card was verified, so do not budget production work on an assumed free tier. Sources: Akamai press release, Akamai Launches AI Inference Service and Agent Execution Environment, 27 October 2026, via GlobeNewswire and The Manila Times; SiliconANGLE launch coverage, 27 October 2026, as reported by AI Affairs; AiCybr, Akamai Inference and Agent Sandbox beta access and pricing, 28 October 2026; 650 Group, Akamai Adds AI Inference and Agent Sandbox, 27 October 2026. Related links: Top Use AI Blog, Open-source LLM API pricing, Ollama vs LM Studio free AI tools Affiliate disclosure: No affiliate link is used in this article. Links to Akamai and to TopUseAI posts earn no commission.