TibiOS Remote Gateway

Your AI infrastructure. Anywhere.

TibiOS Remote Gateway: control agents, jobs and infrastructure remotely via WhatsApp and Telegram

Control and use your AI infrastructure remotely from your phone, through everyday channels like WhatsApp and Telegram: send prompts, run agents, check job status, analyze code or documents, launch processes and get results directly on your phone. The Gateway sits as a secure layer between those channels and TibiOS Core — handling authentication, sessions, commands, jobs and notifications — while intelligence and execution stay on your own TibiOS infrastructure, whether that's GPUs, CPUs, servers, edge devices or a distributed network of resources.

More than prompts: run agents and workflows, inspect and control running jobs, analyze repositories, code and Pull Requests, run tests and dev processes, analyze documents and data, get real-time results and notifications, and keep sessions and context across devices. Security first — authentication, authorization and granular permissions protect every operation, and sensitive actions can require explicit approval before running. WhatsApp and Telegram are just the channel; the intelligence, agents and compute stay under TibiOS's control.

Your AI. Your infrastructure. Anywhere.

A Community of Owners

A Community of Owners: device contributes compute, network creates value, contributor earns, community owns

What is Mixture of Experts?

Why aggregate throughput — not single-request latency — is where distributed GPUs win when scaling MoE inference.

It depends on what you want to optimize — but for the case we care about, MoE + TibiOS, the answer is: to scale MoE inference, aggregate throughput usually matters more than network latency, as long as the network has enough bandwidth. There are two different things to separate.

1. Network latency affects a single request. Each token may need to travel Router → Network → Expert → Network → Next layer. Every added network hop increases end-to-end latency. This matters most for interactive chat, agents and tool calling, small-batch requests, and anything sensitive to TTFT/TPOT.

2. Aggregate throughput affects how many requests or tokens you can process. With many GPUs, each hosting a different subset of experts, a huge number of expert operations can run in parallel — and that is exactly where TibiOS's advantage shows up.

TibiOS MoE: distributed VRAM vs a single large GPU, expert parallelism architecture and comparison table
TibiOS MoE — distributed VRAM, scalable compute: one large GPU vs. many small ones with expert parallelism.

A simple example: a single 128 GB GPU can serve one request in ~100 ms — about 10 requests/second. With TibiOS on 16 × 8 GB GPUs, if the network adds 10 ms of overhead, a single request takes ~110 ms — individually slower. But with all 16 GPUs working in parallel, aggregate capacity could hypothetically reach ~80–120 requests/second, depending on the model, routing, batch size, and network. That capacity depends on a critical condition: the network. 16 GPUs over 1 GbE and the network becomes the bottleneck; 10/25 GbE already changes things significantly; 40/100 GbE or InfiniBand/RDMA makes the cost of all-to-all communication far less dominant.

TibiOS MoE: individual latency vs aggregate throughput, full breakdown of metrics, network flow, comparative example and scalability
TibiOS MoE — individual latency vs. aggregate throughput.

For TibiOS, individual latency depends on network + compute; aggregate throughput depends on GPU count + bandwidth + routing + network — and that second one is where the real opportunity lies. A distributed architecture of 8 GB GPUs will probably never beat a single 128 GB GPU on individual latency. What it can do is deliver far more aggregate compute per dollar, and let the system grow from 8 → 16 → 32 → 64 → 128 GPUs without ever changing the model architecture. That is the story: not "latency vs. throughput," but individual latency vs. the capacity and throughput of the whole cluster.

Data Privacy & Sovereignty

A common objection to local AI: on a single machine, sensitive chat data never leaves it — but TibiOS distributes the model across many GPUs, so where does that data end up? The key distinction is that distributing the model does not mean distributing or persisting the user's data. Tokens travel between TibiOS nodes only in RAM/VRAM during inference and are released immediately after use; by default there is zero persistence — no logs, no database, no cloud backup.

This works because TibiOS separates Control Plane (routing, orchestration) from Data Plane (the actual tokens/weights), and offers two distinct deployment models: TibiOS Private Cluster, where every GPU node sits inside infrastructure the user owns and controls, and TibiOS Distributed Community, an optional shared-compute network across independent, third-party nodes. Sensitive data should stay on a Private Cluster; the Community network is for workloads that don't require that guarantee.

The design principle: "Compute can be distributed. Data sovereignty does not have to be." A stricter mode is also on the roadmap — tibios --privacy=strict — enforcing no cloud inference, no conversation persistence, no prompt logging, no telemetry with user data, and encrypted node-to-node traffic. That is a stronger claim than plain "local AI": TibiOS can distribute the model across many GPUs without distributing ownership of the user's data.

TibiOS: distributed compute, private by design — where data exists, inference flow, privacy mode, private cluster vs cloud AI, and the two TibiOS deployment models
TibiOS — distributed compute, private by design: data sovereignty stays with the user even when compute is distributed.

Hardware Trust: Jetson Orin vs. Confidential Computing GPUs

Not every GPU offers the same hardware trust guarantees, and this matters for where TibiOS can run untrusted nodes. NVIDIA Jetson AGX Orin ships real hardware security — a Hardware Root of Trust, Secure Boot, an OP-TEE Trusted Execution Environment (ARM TrustZone), secure storage, AES-XTS 128-bit DRAM encryption, and crypto acceleration. That is a solid foundation for trusted edge/private nodes, but it is not the same model as NVIDIA's Confidential Computing.

NVIDIA's H100/H200/B200 GPUs add a specific Confidential Computing solution: they can run alongside a Confidential VM, protect the workload from the infrastructure operator itself, support attestation, and protect data crossing PCIe — including documented Confidential Containers support across H100, H200, B200 and select multi-GPU configurations. That is the difference that matters for TibiOS: Orin proves the node is secure-booted and its memory is encrypted, but H100/H200/B200-class Confidential Computing can prove a workload is protected even from the operator of hardware TibiOS does not own.

This maps cleanly onto TibiOS's two deployment models: Orin for private/edge nodes — the machines are ours, so full Confidential Computing isn't required — and H100/H200/B200 for confidential nodes on infrastructure TibiOS does not fully control, where the operator provides GPU, power and connectivity, and Confidential Computing is what prevents them from accessing the workload's contents. The honest framing: Orin provides hardware-backed security and encrypted memory for trusted edge deployments; Hopper/Blackwell GPUs add full NVIDIA Confidential Computing for higher-assurance, multi-tenant, untrusted-node deployments.

TibiOS Sauron

TibiOS Sauron announcement

TibiOS Sauron will be our first proprietary AI model, built on top of TibiOS's distributed infrastructure. The goal isn't to compete on size with the large Frontier models from day one, but to demonstrate that a network of small machines can be used to train and later run a large model in a distributed way. Our first trained model is already on Hugging Face: fgparamio/sauron-lora-qwen3-4b.

Sauron will be oriented primarily toward professional code generation. Its goal goes beyond writing code from scratch: we want it to have especially strong knowledge of existing code, libraries, frameworks, and available solutions, mostly coming from the open source ecosystem.

The model's philosophy will be:

Reuse → Compose → Create

That is, faced with a development problem, Sauron should first try to reuse an existing solution, then combine already-available components and libraries, and only as a last resort implement new code.

The end goal is for it to produce the correct solution with the least amount of new code possible, while maintaining quality, security, tests, and maintainability.

Training

We won't start from scratch. We'll use an existing code model as a base and run a progressive fine-tuning process.

The first phase will be experimental, using a relatively small model to validate the methodology:

base model → SFT → preference tuning → test-based evaluation → RL

The dataset will be built from real ecosystem code and knowledge:

  • GitHub repositories;
  • libraries and frameworks;
  • documentation;
  • usage examples;
  • issues and pull requests;
  • code paired with tests;
  • programming problems and their solutions;
  • examples where reusing a library beats implementing a custom solution.

Examples that teach the model what NOT to do will be especially important: reinventing functionality that already exists, introducing unnecessary dependencies, or generating hundreds of lines when a mature library solves the problem in a handful.

From a small model to Sauron

The strategy will be incremental:

small model → demonstrate Code-Reuse → larger model → Sauron

We'll first validate that the learned behavior actually improves over the base model. Once proven, we'll carry the methodology over to much larger models, reaching the goal of Tibi Sauron, envisioned as a Frontier-scale MoE model.

In our current theoretical estimates, Sauron is planned around 671B parameters, taking architectures like DeepSeek-V3 and Kimi-K3 as references. Training isn't planned on a single machine, but over a distributed network of TibiBoxes. TibiOS would need to dynamically solve placement, memory, communication, Expert locality, node performance, and fault tolerance.

That's why our current work on:

  • GPU/VRAM-aware scheduling;
  • node performance signals;
  • capacity degradation;
  • placement reasoning;
  • network/locality;
  • network-cost-aware scheduling;
  • Expert locality;

is all part of the same architecture.

The final vision

Sauron represents the first demonstration that the ability to create advanced AI doesn't have to depend exclusively on large, centralized data centers.

A sufficiently large network of small machines can collectively contribute:

memory + compute + network + storage + inference + training.

The hypothesis we want to demonstrate is simple:

A community can build and run its own AI model using a distributed infrastructure of small machines coordinated by TibiOS.

And Sauron would be the first big experiment testing that hypothesis: a proprietary model, specialized in software engineering, trained and later run on a distributed infrastructure designed by us.

What if AI capability didn't depend on a handful of data centers, but on a distributed network of millions of accelerators?

Starting from NIST's CAISI results, we have an interesting reference point: GPT-5.5 scores 1,260 Elo, Anthropic Opus 4.6 999, GPT-5.4 mini 749, and DeepSeek V4 Pro 800. NIST also notes that the US frontier holds roughly an 8-month lead over the PRC frontier. See the original evaluation: NIST — CAISI Evaluation of DeepSeek V4 Pro.

NIST CAISI — Overall AI Capability: comparison of aggregate capabilities over time of the most capable publicly released U.S. and PRC models
Original NIST CAISI chart — comparison of aggregate capabilities over time of the most capable publicly released U.S. and PRC models. Source: NIST.
Overall AI Capability (CAISI Elo Scale): Commercial/US frontier vs PRC/open-weight frontier vs TibiOS Sauron distributed deployment milestones, Sep 2026 to Dec 2029
TibiOS scenario — CAISI Elo scale, Commercial/US and PRC/open-weight frontiers vs TibiOS Sauron deployment milestones.

From that data we built a hypothetical scenario for TibiOS Sauron: a distributed AI architecture running over a network of NVIDIA Orins.

The working hypothesis is simple: each doubling of the Orin network → +200 Elo. This is not a NIST claim — it's our planning scenario.

🟢 M1

Balanced

0.5M Orins (Jun-2027) → 16M Orins (Dec-2029)

🟠 M2

High capacity

1M Orins (Jun-2027) → 32M Orins (Dec-2029)

🟣 M3

Conservative

0.25M Orins (Sep-2027) → 4M Orins (Dec-2029)

Growth hypothesis: reference points, line definitions, TibiOS deployment milestones and frontier-crossing dates for the CAISI Elo projection
Growth hypothesis behind the projection: reference points, milestones and crossing dates (NIST CAISI, May 2026, + scenario extrapolation).

The crossings are especially interesting:

  • M2 crosses the PRC/Open-Weight frontier around May-2027 (~946 Elo) and the US commercial frontier around Apr-2029 (~1,907 Elo).
  • M1 crosses Open-Weight in Jun-2027 (~953 Elo) and reaches the commercial frontier around Dec-2029 (~1,988 Elo).
  • M3 crosses Open-Weight in Aug-2028 (~1,115 Elo), but doesn't reach the commercial frontier before Dec-2029.

The point isn't to read this as a prediction. It's to explore a different question: what happens to AI capability if we can efficiently coordinate millions of distributed accelerators? In that scenario, the question stops being just "which model will we have?" and becomes "how many nodes can we coordinate and turn into useful capacity?"

Source: NIST CAISI + TibiOS scenario extrapolation. Values beyond NIST's measured points are planning hypotheses. — NIST, "CAISI Evaluation of DeepSeek V4 Pro".

TibiOS Console Nodes — turning GPUs into distributed AI nodes

What if your gaming console could become part of a decentralized AI network? This video explores how TibiOS Sauron could transform devices such as Xbox, PlayStation, and Steam Deck into distributed AI compute nodes, turning unused GPU capacity into part of a larger intelligent infrastructure — alongside PCs, NVIDIA GPUs, edge devices, and dedicated AI hardware.

AI Without a Single Point of Failure

What happens when you depend entirely on a centralized AI service and it goes down? A Claude outage is a good reminder that even the most powerful AI platforms can become a single point of failure for the applications, agents, and workflows built on top of them. This is where TibiOS takes a different approach: bringing intelligence closer to the user through a local, distributed, and decentralized AI architecture.

Components

tibios-core

Rust

The Runtime itself: the complete architectural model, a Cargo workspace, and the Composition Root that wires domains and Worker adapters.

ai-runtime

Python / Ray

Heavy AI execution Worker — one of the two interchangeable implementations of the Worker Contract.

proto/

Protocol Buffers

The shared, language-neutral gRPC contract between the Runtime and its Workers.

Everything is a Worker

The application never changes. The same contract (Worker) covers CoreML, TensorRT, ONNX, OpenVINO, llama.cpp and more — the Runtime decides which implementation executes each Workload.

Worker trait diagram: same contract, multiple AI execution implementations