What is Gigatoken?
Gigatoken connects provider-owned hardware running local models with inference consumers who want OpenAI-compatible access across active provider devices.
Gigatoken
Docs
Overview
Gigatoken connects provider-owned hardware running local models with inference consumers who use OpenAI-compatible access across active provider devices.
Providers run the Gigatoken CLI and daemon on supported machines. The daemon connects to the coordinator, keeps the local device in sync, and applies model intent chosen from the Provider console.
From the console, providers choose catalog-managed models to download, keep present, and make active. Those GGUF models are served locally from the provider device. When a model fits with less than 4 GiB of VRAM headroom, the console warns that the GPU must be effectively dedicated and idle before Download, Retry, or Set active proceeds.
Inference consumers create inference API keys and send requests to OpenAI-compatible endpoints. Gigatoken routes eligible requests to active devices in the provider pool that can serve the selected model.
Short answers for readers who are new to Gigatoken.
Gigatoken connects provider-owned hardware running local models with inference consumers who want OpenAI-compatible access across active provider devices.
It is for providers who want to connect real hardware and manage local model availability, and for inference consumers who need API keys that route requests through the provider pool.
Yes. Inference consumers use OpenAI-compatible endpoints and inference API keys, while Gigatoken routes eligible requests to active provider devices.
Gigatoken is built around supported provider machines running catalog-managed GGUF models served locally. Each catalog model has a minimum usable VRAM requirement; devices with unknown VRAM fail closed until the provider sets GIGATOKEN_VRAM_GB and reconnects. Eligible models close to the minimum VRAM floor can show a dedicated-fit confirmation before provider actions.
No. The docs are public and sign-in-free. Signing in is required for console workflows such as managing provider devices, models, and inference keys.