The Platform at a glance

The CLIKA Platform runs benchmarks on real devices and keeps those devices under management afterwards. You register the hardware you care about, point the platform at a model, and it measures the model on each device and brings the numbers back with the per-sample evidence behind them.

It is not a training system, not a model hub, and not a hosted inference service. Your devices stay yours, the deployment runs on your infrastructure, and model weights are fetched on the device that needs them.

The mental model

Five ideas carry the whole product, in the order you meet them.

1. Everything sits in an organization and a project. The organization is your tenant: users, roles, and the device fleet. A project is one piece of work, and it holds the models, benchmark runs, services and runtime credentials of that work. The switchers in the top bar decide which of each you are looking at. Devices are the deliberate exception, shared across every project of the organization, because a physical machine is shared hardware.

2. Devices come to you. A device runs the CLIKA agent, and the agent dials out to the platform and keeps one connection open. Nothing connects inward, so a device behind a home router or a corporate firewall works with no ports opened. Over that one connection the platform pushes files, runs jobs, opens a terminal, and reads a heartbeat every 15 seconds.

3. The platform issues the licenses your own code runs on. A ClikaRT runtime has to prove it is allowed to run, and the credential it presents is one your platform mints, per project, and can update or revoke afterwards. Managing those credentials is one of the platform's main purposes rather than a side feature: you issue one, ship it with your application, and keep control of what it permits and how long it lasts. Runtime licenses covers the entitlements a credential carries.

4. A benchmark is models times tests times devices, and the platform picks the runner. You choose models, quality tests and devices. The platform maps each combination to the job definition confirmed to work on that platform and architecture, dispatches one job per combination, and refuses honestly (DEVICE_NOT_RUNNABLE) where no confirmed mapping exists rather than substituting something unproven.

5. A result carries its evidence. Every completed job returns headline metrics, per-sample inputs and outputs, and metadata about what actually ran. That is what makes two numbers comparable: you can open the questions a model got wrong, not only its score.

What talks to what

   you                      the deployment                        your device
 ┌───────────┐            ┌────────────────────┐               ┌──────────────────┐
 │ web app   │            │  the platform API  │               │  CLIKA agent     │
 │ CLI       │ ─ HTTPS ─► │  job orchestration │ ── gRPC ────► │   pushes files   │
 │ Claude    │            │  artifact storage  │  (agent dials │   runs the job   │
 │ (over MCP)│ ◄── JSON ─ │  licensing         │   out, stays  │   reports health │
 └───────────┘            └────────────────────┘   connected)  │   returns output │
                                    │                          └──────────────────┘
                                    ▼
                          results, metrics, samples

The web application never talks to a device. Every terminal keystroke, file transfer and job dispatch goes through the platform, over the agent's own connection.

Three surfaces, one platform

Surface	Use it for
Web application	Everyday work: fleet, models, runs, results, members, licenses.
clika-rt CLI	Terminals and CI. Resource YAML (apply and export), transfers, watching runs.
Claude, over MCP	Asking for the work in plain language. The deployment serves its own operations as tools at /api/mcp, and the CLI can serve them locally over stdio.

Where to go next

• The tutorial turns these five ideas into a benchmark result.
• Concepts expands each of them, one page at a time.