Tiles
Download
Skip to Content
Tilekit

Tilekit

Tilekit aims to be the app-server interface behind Tiles and future rich client experiences. Developers can embed it into their local clients by bundling or fetching a platform-specific App Server binary, running as a long-lived child process and communicating over bidirectional stdio JSON-RPC.

Use it when you want a deep integration inside your own product: identity, memory, sync, and agent templates. It is built with privacy-first engineering and uses open standards like Modelfile, DIDs, and UCANs, so user data, identity, and control stay on their device.

Modelfile Reference

Tiles supports a Modelfile format inspired by Ollama-style instructions, with runtime behavior tuned for the current local MLX pipeline.

The Modelfile parser is implemented in tilekit/src/modelfile.rs using the nom parser combinator library. It parses a text-based configuration format for defining model configurations, parameters, templates, and system prompts.

This page describes what is parsed, what is validated, and what is actually used at runtime today.

Quick Start

Minimal working Modelfile:

FROM mlx-community/gpt-oss-20b-MXFP4-Q4
SYSTEM You are a concise assistant.

FROM is required. Most other fields are optional.

Supported Instructions

Tiles currently parses these top-level instructions (case-insensitive):

  • FROM (required, exactly one)
  • PARAMETER (repeatable)
  • TEMPLATE (at most one)
  • SYSTEM (latest value wins)
  • ADAPTER (at most one)
  • LICENSE (at most one)
  • MESSAGE (repeatable)
  • # comments

If FROM is missing, parsing fails.

FROM

FROM is parsed as a string, but runtime behavior is intentionally narrower right now.

What works today
  • Hugging Face-style model repo identifiers, for example:
    • mlx-community/gpt-oss-20b-MXFP4-Q4
    • mlx-community/Qwen3.5-4B-MLX-4bit
Important nuance
  • Runtime cache resolution is currently implemented for model names that start with mlx-community/.
  • Values outside that pattern are currently not supported by the runtime path.
  • Local file paths are not wired into the model loading flow yet.
  • Arbitrary model files (for example .gguf) are not currently supported via FROM.

In short: while FROM accepts a free-form string at parse time, runtime support is currently aligned to Hugging Face repo IDs in the mlx-community/* namespace.

SYSTEM

SYSTEM sets the system/developer instruction prompt used in chat requests.

  • If multiple SYSTEM lines exist, the latest one replaces earlier ones.
  • If omitted, Tiles falls back to the default Modelfile prompt for the selected mode.

This is one of the two Modelfile fields that materially affects runtime behavior today (FROM and SYSTEM).

PARAMETER

PARAMETER is parsed and validated against an allowlist.

Supported keys:

  • num_ctx (int)
  • repeat_last_n (int)
  • repeat_penalty (float)
  • temperature (float)
  • seed (int)
  • stop (string)
  • num_predict (int)
  • top_k (int)
  • top_p (float)
  • min_p (float)

Notes:

  • Unknown parameter names fail validation.
  • Type mismatches fail validation.
  • Parameters are currently parsed/stored but not fully applied in the runtime request payload yet.

MESSAGE

MESSAGE supports role + content pairs.

Accepted roles:

  • system
  • user
  • assistant

Notes:

  • Messages are validated and stored.
  • Current runtime conversation assembly does not directly consume modelfile.messages yet.

TEMPLATE, ADAPTER, LICENSE

These instructions are parsed and validated with single-value semantics:

  • TEMPLATE: at most one
  • ADAPTER: at most one
  • LICENSE: at most one

Current status:

  • They are represented in the parsed Modelfile structure.
  • They are not currently wired into the main model execution path.

Comments

Lines beginning with # are accepted and preserved in serialized Modelfile output.

Current Runtime Behavior

In the current implementation, the Modelfile fields that directly influence execution are:

  1. FROM (model identifier, currently mlx-community/* in practice)
  2. SYSTEM (prompt override/fallback behavior)

Other parsed fields are available at parse/validation level and can be considered forward-compatible surface for future runtime expansion.

Example

FROM mlx-community/gpt-oss-20b-MXFP4-Q4
SYSTEM """
You are Tiles assistant.
Keep answers practical and concise.
"""
PARAMETER temperature 0.2
PARAMETER num_ctx 4096

The example above is valid. Today, FROM and SYSTEM drive behavior directly; parameter validation still applies.

MIR Extension

MIR

Based on the specifications defined by Darkshapes’ MIR (Machine Intelligence Resource), a naming schema for AIGC and ML work, and Ollama’s Modelfile, this blueprint aims to extend Modelfile’s capabilities to support intent-based model chaining driven by the prompt, with an implementation currently in progress.

# Base model (required)
FROM ./model.safetensors
 
# MIR identifier (custom extension)
# Format: mir:[domain].[architecture].[series]:[compatibility]
MIR "mir:model.art.gpt-oss:mlx-q4"
 
# License for this model
LICENSE """
Apache-2.0
"""
 
# System prompt
SYSTEM """
You are a lightweight technical model.
"""
 
# Prompt formatting
TEMPLATE "{{ .Prompt }}"
 
# Add adapters (optional LoRA layers)
ADAPTER ./adapter1.safetensors
 
# Runtime parameters
PARAMETER temperature 0.7
PARAMETER num_ctx 4096
 
# Initial message context
MESSAGE user "Hello."
MESSAGE assistant "Hi there!"

MIR Reference

Copied verbatim from: github.com/darkshapes/MIR:

MIR (Machine Intelligence Resource)

A naming schema for AIGC/ML work.

The MIR classification format seeks to standardize and complete a hyperlinked network of model information, improving accessibility and reproducibility across the AI community.

Example:

mir : model . transformer . clip-l : stable-diffusion-xl

 mir : model .    lora      .    hyper    :   flux-1
  ↑      ↑         ↑               ↑            ↑
 [URI]:[Domain].[Architecture].[Series]:[Compatibility]

Code for this project can be found at darkshapes/MIR on GitHub.

Definitions

Like other URI schema, the order of the identifiers roughly indicates their specificity from left (broad) to right (narrow).

DOMAINS

↑Most Specific/Decentralized

Dev

Pre-release or under evaluation items without an identifier in an expected format
Anything in in-training, pre-public release, and items under evaluation

Meant to be created by anyone, derived from code and file analysis

  • Contextual
  • Layers of neural networks
  • Dynamic

Model

Publicly released machine learning models with an identifier in the database
Model weight tensors with arbitrary locations and quantitative dimensions

Meant to be created by file hosts, derived from research pre-prints

  • Contextual
  • Layers of neural networks
  • Fixed

Ops

References to specific optimization or manipulation techniques
Algorithms, optimizations and procedures for models

Meant to be created by code libraries, derived from research pre-prints

  • Universal
  • Attributes of neural networks
  • Dynamic

Info

Metadata of layer names or settings with an identifier in the database
Information about the model and tensor specifications

Meant to be created by standards community, derived from code and file analysis

  • Universal
  • Attributes of neural networks
  • Fixed

↓Most General/Centralized

ARCHITECTURE

Broad and general terms for system architectures:

AbbreviationDescription
GRUGated recurrent unit
RBMRestricted Boltzmann machine
TAETiny Autoencoder
VAEVariable Autoencoder
LSTMLong Short-Term Memory
RESNETResidual Network
CNNConvolutional Neural Network
RCNNRegion-based Convolutional Neural Network
RNNRecurrent Neural Network
BRNNBi-directional Recurrent Neural Network
GANGenerative Adversarial Model
SSMState-Space Model
DETRDetection Transformer
VITVision Transformer
MOEMixture of Experts
AETAutoencoding Transformer
STSTSequence-to-Sequence Transformer
ARTAutoregressive Transformer
LORALow-Rank Adaptation
CONTROLNETControlnet
UNCLASSIFIEDUnknown
SERIES

Foundational network and technique types.

Rules

  • Lowercase, hyphen only
  • Remove parameter size, non-breaking semantic versioning, library names

Example: tencent-hunyuan/hunyuandiT-v1.2-diffusers
SERIES : hunyuandit-v1

Example: black-forest-labs/FLUX.1-dev
SERIES : flux1dev

In regex (roughly):

BREAKING*SUFFIX = r".*(?:-)(prior)$|.*(?:-)(diffusers)$|.\*[\*-](\d{3,4}px|-T2V$|-I2V$)"
PARAMETERS*SUFFIX = r"(\d{1,4}[KkMmBb]|[.*-]\d+[\._-]\d+[Bb][._-]).\*?$"
SEARCH*SUFFIX = r"\d+[.*-]?\d+[BbMmKk](it)?|[._-]\d+[BbMmKk](it)?"
COMPATIBILITY

Implementation details based on version-breaking changes, configuration inconsistencies, or other conflicting indicators that have practical application.

Rules

An additional SERIES label for identifying cross-compatibility

Notes

If you would like to regenerate or update the example file here, use nnll:

MIR is inspired by: