# llms.txt for Tiles Privacy
# Learn more at https://llmstxt.org/
site: Tiles Privacy marketing site (tiles.run)
owner: Tiles Privacy
contact: hello@tiles.run
last-updated: 2026-04-21
allowed-uses:
- Crawl and summarize public pages to help people discover Tiles Privacy offerings.
- Short-term caching for inference, classification, and question-answering about the site.
- Non-commercial research that keeps excerpts clearly attributed to Tiles Privacy.
disallowed-uses:
- Training commercial foundation models or synthetic data generators without prior written consent.
- Combining our content with third-party data to build user profiles or behavioral dossiers.
- Serving our copy or visuals as if they were created by your model without attribution.
request:
- If your system logs or retains content beyond transient processing, please provide an opt-out or deletion path via the contact above.
- Respect any existing robots.txt and rate limits to avoid service disruption.
thank-you:
We appreciate responsible AI agents that honor privacy, attribution, and user trust.
================================================================================
## Homepage (https://www.tiles.run/)
Tiles
Private and secure AI assistant for everyday use.
Runs offline by default with optional peer-to-peer sync. Built as an independent open-source project, based on standards and decentralized technologies.
Currently available as a CLI in ALPHA.
Extended product overview, comparison details, and security FAQ now live on the book index page at /book.
================================================================================
## Mission (https://www.tiles.run/mission)
Our mission is to bring privacy technology to everyone.
Tiles Privacy was born from the User & Agents community with a simple idea: software should understand you without taking anything from you. We strive to deliver the best privacy-focused engineering while also offering unmatched convenience in our consumer products. We believe identity and memory belong together, and Tiles gives you a way to own both through your personal user agent.
Founded by Ankesh Bharti (@feynon), an independent researcher and technologist, Tiles is built for privacy conscious users who want intelligence without renting their memory to centralized providers. Our first product is a private and secure AI assistant with offline memory, and an SDK that lets developers customize local models and agent experiences within Tiles.
Contributors:
Ankesh Bharti, Anandu Pavanan
Sponsors:
Active: Luke Hubbard, Dietrich Ayala, Xi Zhang, Hugo Duprez, Utkarsh Saxena
Past: Boris Mann, Seref Yarar, Curran Dwyer, Goblin Oats
================================================================================
## Download Installer (https://download.tiles.run/tiles-0.4.7-signed.pkg)
Network installer for macOS:
https://download.tiles.run/tiles-0.4.7-signed.pkg
Offline installer for macOS (bundled model):
https://download.tiles.run/tiles-0.4.7-full-signed.pkg
SHA256: e2fa2d5339d356c023fb1c13fba8a6cf099fedad07f684b7b090d59292c91032
SHA256 file: https://download.tiles.run/checksums/tiles-0.4.7-full-signed.pkg.sha256
Size: 10.31 GB
================================================================================
## Blog (https://www.tiles.run/blog)
The Tiles Blog
Privacy technology for everyone!
We're building open source privacy technology for personalized software experiences.
================================================================================
## Blog Post: Ship it up (https://www.tiles.run/blog/ship-it-up)
Published: 2026-04-05
Author: Anandu Pavanan @madclaws
Author URL: https://github.com/madclaws
Description: How we package and ship Tiles
Keywords: Tiles, packaging, deployment, software distribution, venvstacks, Python packaging
Content:
We ship Tiles as a tar.gz tarball and as a native macOS .pkg. Either format follows the same broad steps. Assemble the deliverable:Package the Tiles binary and the Python venvstack artifacts into one installer payload. Run the installer:Copy the Tiles binary and Python artifacts into the correct locations on disk. Run postinstall scripts. In early releases, the tarball was the only install path. It served us well, but it had clear limits. Because the release artifact is a gzip tarball, we cannot codesign, notarize, and staple the archive itself the way we can a full installer. We run those steps on the Tiles binary only, not on the entire .gz file. Installation relies on a curl-based script. That is workable for developers and rougher for everyone else. The flow leaves little room to tailor copy, branding, or steps in the installer UI. We wanted a path that fits Apple's signing and notarization story and feels native on macOS. Installers ship as .dmg or .pkg bundles; we chose .pkg because it can run scripts, uses a familiar installer UI, and supports customization with simple HTML. What follows is how we build that .pkg for Tiles. Install file structure The layout matches the directory tree above. When we build the package, we point the tooling at this pkgroot directory as the install root. The installer copies that tree onto the destination volume and creates intermediate directories as needed. For each release, we build a fresh Tiles binary into pkgroot/usr/local/bin and place the remaining updated artifacts under pkgroot/usr/local/share/tiles/. The build script in the repo has the full sequence. Code signing the Tiles binary Code signing gives us: A signed Tiles binary that cannot be altered without invalidating the signature. A signature from a developer certificate that Apple trusts. You need an Apple Developer account and two certificate types: DEVELOPER ID APPLICATION for the binary and DEVELOPER ID INSTALLER for the .pkg. The finished installer wraps the signed binary and the other artifacts in one compressed package. For creating and exporting those certificates, the CodeVamping macOS pkg installer article covers the details. # Signing the Tiles binary codesign --force \ --sign "$DEVELOPER_ID_APPLICATION"\ --options runtime \ --timestamp \ --strict \ "${CLI_BIN_PATH}/tiles" The snippet signs the Tiles CLI. $DEVELOPER_ID_APPLICATION is an environment variable that holds the common name of the Developer ID Application certificate. Scripts Bash scripts can run before and after the payload is laid down. We keep preinstall and postinstall scripts in a directory and pass that path into pkgbuild. The Tiles repo has those scripts; they handle cleanup and internal setup. Building the Tiles package With the signed Tiles binary and the rest of the install tree under pkgroot, we run: pkgbuild --root pkgroot --scripts \ pkg/scripts --identifier com.tilesprivacy.tiles --version "$VERSION" \ pkg/tiles-unsigned.pkg --root is pkgroot; --scripts points at the directory from the previous section. Customizing the installer Opening the unsigned package from the previous step shows Apple's default, minimal flow. We layer on welcome and conclusion screens, a logo, and other panels with an Apple distribution definition in XML. That file references HTML for the welcome, conclusion, and other supported steps. Our distribution_network.xml is the working example. Elements such as and point at resources we keep alongside the definition and pass into the final productbuild invocation. productbuild \ --distribution pkg/distribution_network.xml \ --resources pkg/resources \ --package-path pkg/ \ pkg/tiles-dist-unsigned.pkg productbuild reads the unsigned package and writes a distributable installer with those customizations baked in. Code signing the complete installer productsign \ --sign "$DEVELOPER_ID_INSTALLER" \ pkg/tiles-dist-unsigned.pkg \ pkg/tiles.pkg That signs the .pkg itself. The Tiles binary is already signed; signing a macOS binary and signing an installer package are different operations. The main difference is productsign instead of codesign, and the certificate we use is DEVELOPER ID INSTALLER instead of DEVELOPER ID APPLICATION. Notarizing the installer Notarization lets Apple scan the payload for malware. We upload the installer; when processing finishes, the service returns acceptance or rejection. Submission looks like this: xcrun notarytool submit pkg/tiles.pkg \ --keychain-profile "tiles-notary-profile" \ --wait tiles-notary-profile is the keychain entry name so we do not pass Apple ID details on every run. Store the profile once with: xcrun notarytool store-credentials \ "tiles-notary-profile" \ --apple-id "john.doe@gmail.com" \ --team-id "X********4" \ --password "****-****-****-****" Stapling the installer Stapling embeds the notarization ticket in the installer file so Gatekeeper needs fewer round trips to Apple when a user opens the package. xcrun stapler staple pkg/tiles.pkg What's next We also ship a fully offline installer that bundles a gpt-oss model, so Tiles can be installed without an internet connection. We are working toward making Tiles itself portable, allowing users to carry their model and data and run it from a flash drive on any compatible system. The installer requires Rosetta; on Apple Silicon Macs, it is not included by default and must be installed separately. Rosetta translates Intel binaries to run on Apple Silicon. There is a workaround for this, described in the linked GitHub issue.
================================================================================
## Blog Post: Move Along, Python (https://www.tiles.run/blog/move-along-python)
Published: 2026-02-17
Author: Anandu Pavanan @madclaws
Author URL: https://github.com/madclaws
Description: Deterministic, portable Python runtimes for Tiles using layered venvstacks.
Keywords: Python, venvstacks, portable runtimes, Python packaging, dependency management, Tiles, deterministic builds
Content:
We have been working on Tiles, a private and secure AI assistant for everyday use. The Python Problem Right now, we have a polyglot architecture where the control pane and CLI are written in Rust, while local model inference runs through a Python server as a daemon. Ideally, when we ship Tiles, we should also ship the required artifacts needed to run Python on the user’s system. Since Python servers cannot be compiled into a single standalone binary, the user’s system must have a Python runtime available. More importantly, it must be a deterministic Python runtime so that the server runs exactly on the version developers expect. In earlier releases of Tiles (before 0.4.0), we packed the server files into the final release tarball. During installation, we extracted them to the user’s system, downloaded uv (a Python package manager), installed Python 3.13 if it was not already present, and then ran the server as a daemon. This approach had several issues: Downloading development-related tools such as uv onto the user’s system Relying on uv at install time to manage dependencies and run the server Increased chances of failures due to dependency or runtime non-determinism Requiring internet access to download all of the above tools Lack of a fully deterministic runtime across operating systems One of the long-term goals of Tiles is complete portability. The previous approach did not align with that vision. Portable Runtimes To address these issues, we decided to ship the runtime along with the release tarball. We are now using venvstacks by LM Studio to achieve this. Venvstacks allows us to build a layered Python environment with three layers: Runtimes Defines the exact Python runtime version we need. Frameworks Specifies shared Python frameworks such as NumPy, MLX, and others. Applications Defines the actual server application and its specific dependencies. Similar to Docker, each layer depends on the layer beneath it. A change in any layer requires rebuilding that layer and the ones above it. All components within a layer share the layers beneath them. For example, every framework uses the same Python runtime defined in the runtimes layer. Likewise, if we have multiple servers in the applications layer and both depend on MLX, they will share the exact deterministic MLX dependency defined in frameworks, as well as the same Python runtime defined in runtimes. We define everything inside a venvstacks.toml file. Here is the venvstacks.toml used in Tiles. Because we pin dependency versions in the TOML file, we eliminate non-determinism. Internally, venvstacks uses uv to manage dependencies. Once the TOML file is defined, we run: venvstacks lock venvstacks.toml This resolves dependencies and creates the necessary folders, lock files, and metadata for each layer. Next: venvstacks build venvstacks.toml This builds the Python runtime and environments based on the lock files. Finally: venvstacks publish venvstacks.toml This produces reproducible tarballs for each layer. These tarballs can be unpacked on external systems and run directly. We bundle the venvstack runtime artifacts into the final installer using this bundler script. During installation, this installer script extracts the venvstack tarballs into a deterministic directory. Our Rust CLI can then predictably start the Python server using: stack_export_prod/app-server/bin/python -m server.main What’s Next We tested version 0.4.0 on clean macOS virtual machines to verify portability, and the approach worked well. For now, we are focusing only on macOS. When we expand support to other operating systems, we will revisit this setup and adapt it as needed. Packaging the runtime and dependencies increases the size of the final installer. We are exploring ways to reduce that footprint. We also observed that changes in lock files can produce redundant application tarballs when running the publish command. More details are tracked in this issue. Overall, we are satisfied with this approach for now. Till then, keep on tiling.
================================================================================
## Book: Tiles Book (https://www.tiles.run/book)
import { marketingPageTitleClass } from "@/lib/marketing-page-title-classes"
Book
Technical documentation covering the models, infrastructure, and cryptography behind Tiles, the consumer product, and Tilekit, the developer-facing SDK written in Rust.
================================================================================
## Book: Overview (https://www.tiles.run/book/overview)
import Link from "next/link"
import { Check, CircleDashed, Cpu, FileCode, FlaskConical, KeyRound, Package, RefreshCw } from "lucide-react"
import { BookFaq, BookFaqItem } from "@/components/book-faq"
import { ClickableImage as Image } from "@/components/clickable-image"
# Overview
Product overview, comparison details, and concise answers to common security questions for Tiles.
## Features
Tiles combines local models, device identity, encrypted sync, offline packaging, and developer tooling into
a privacy-first desktop AI stack.
On-device Models
An opinionated package of prompt, tools, and models optimized for your hardware. Powered by [MLX](https://ml-explore.github.io/mlx/build/html/index.html) on Apple Silicon.
Decentralized Identity
Locally generated [DIDs](https://github.com/w3c/did), with the private key always stored locally on device.
P2P Sync
Encrypted peer-to-peer sync for chats across your linked devices, online or on your local network. Powered by [Iroh's](https://www.iroh.computer/) networking stack.
Offline Installer
Bundled dependencies run in a self contained environment without modifying your system, with a fully offline
installer available for secure and air gapped installations.
Tilekit SDK
Customize local models and agent experiences within Tiles. Built in Rust, based on open-source
specifications such as Modelfile and Open Responses API.
### CLI onboarding
This is what the first run looks like when you type tiles in your terminal.
First-run onboarding flow (tiles)
## What makes Tiles different
Our approach combines best-in-class privacy-focused engineering with unmatched consumer convenience. See how Tiles compares to other local-first AI assistants.
## Frequently asked questions
Short answers drawn from our [security documentation](/book/security). For full context and limits, read that page.
Tiles is designed so the default experience runs on-device. The local server binds to localhost,
which limits exposed network surface during normal use. Configuration and application data live in standard
local directories, and you can change the user data path when needed.
No. Application state is persisted locally with encryption at rest. The Rust build uses SQLCipher-enabled
SQLite, and database connections use a passkey from secure storage. That raises the bar against casual
inspection of copied files, though it does not remove all local risk.
Public identity is separated from private keys. Device and account identity use did:key identifiers
from Ed25519 keys. Private keys and database passkeys are stored in the operating system's secure credential
store, not in plaintext app configuration files.
Peer-to-peer linking is user-mediated, not automatic. One device shows a ticket or local code; the other enters
it and explicitly accepts or rejects. In release builds, endpoints derive from your stored secret key, and peer
identity is checked against the delivered public key. Sync includes defensive controls, including a maximum size
cap for downloaded deltas before they are applied.
Sync uses [Iroh](https://www.iroh.computer/) for device-to-device networking. When a direct path is not practical, Iroh's public relays can help establish
the connection; we list that relay use on our sub-processors page.
The product does not currently bundle obvious analytics SDKs such as Sentry, PostHog, Segment, Mixpanel, or
similar telemetry. There is still local logging: the Python server may log request metadata and bodies to files
under the Tiles data directory, so prompt content can appear in local logs unless logging changes.
Updates can check GitHub releases and install via the hosted installer script, which depends on release and
hosting integrity rather than a stronger built-in end-user verification workflow. Dependencies are pinned and
reviewed. The macOS package is code signed, notarized, and stapled. Bundled dependencies are self-contained so
normal installation and use do not require live package downloads from the internet.
Use the published security policy and private disclosure path. Researchers can use GitHub Security Advisories or
email [security@tiles.run](mailto:security@tiles.run), with expectations for acknowledgement, triage,
and coordinated disclosure. See [SECURITY.md](https://github.com/tilesprivacy/tiles/blob/main/SECURITY.md).
================================================================================
## Book: Manual (https://www.tiles.run/book/manual)
# Manual
Reminder: this is in alpha.
Enjoy these sample commands in lieu of a formal doc.
## Tiles
Commands in this section are for regular users. Most day-to-day behavior is also available as slash commands inside the chat REPL.
Commands are grouped by subcommand family: the base tiles command, identity, data layout, models, updates, then peer-to-peer linking and sync.
### Main command (tiles)
Launches onboarding (first run) and the interactive REPL.
[code block]
### Account (tiles account)
Root identity and display nickname.
[code block]
[code block]
### Data directory (tiles data)
Where Tiles stores local data.
[code block]
[code block]
### Run models (tiles run)
Start a chat session with a model; optional Modelfile path and experimental memory flag.
[code block]
[code block]
### App updates (tiles update)
[code block]
### Peer-to-peer: linking (tiles link)
Tiles can sync chats across multiple **linked** devices peer-to-peer, with or without the internet. Linking is a one-time step so both sides consent before any sync traffic is accepted; you do not need to re-link each time you sync.
[code block]
**tiles link enable**: Puts this device in **link listener** mode. It generates a **link ticket** and waits for a link request from another device. Share the ticket **out of band** with the peer you want to link.
- If the device is **online**, the ticket is a **base64** string (easy to copy).
- If **offline**, the ticket is an **eight-character alphanumeric code** you can type on another device on the same network.
When the peer runs **tiles link enable** and supplies your ticket, this device is notified; after you **approve**, the two devices are linked.
**tiles link list-peers**: Lists linked peers by **DID** (decentralized identifier) and **nickname**.
**tiles link disable**: Unlinks a peer. Future sync requests from that peer are ignored.
### Peer-to-peer: chat sync (tiles sync)
After devices are linked, use **tiles sync** to replicate chats. Listener and initiator roles mirror linking: one side waits, the other connects using the listener’s DID.
[code block]
**tiles sync** (listener): Starts this device in **sync listener** mode: it waits for incoming sync requests.
On the **other** device, run **tiles sync** with the listener’s **DID** so the initiator targets the correct peer. If your CLI uses different syntax for the peer argument, check tiles sync --help.
When a sync run finishes, you should get a notification on the devices involved.
## Uninstall Tiles (macOS)
The full macOS uninstall procedure now lives in a dedicated skill file that includes stop steps, installed-path cleanup, data-path cleanup, optional receipt and keychain cleanup, and warnings for destructive commands.
We are actively working on an official Tiles uninstaller.
To use it with coding agents (for example Claude Code or Codex), share the skill file URL in your prompt and ask the agent to follow it step by step while adapting only paths that differ on your machine.
Read and download it here: [https://tiles.run/tiles-uninstaller-skill/SKILL.md](https://tiles.run/tiles-uninstaller-skill/SKILL.md).
================================================================================
## Book: Models (https://www.tiles.run/book/models)
# Models
Our approach to model selection is to use the most suitable model for each task, within the constraints of the supported hardware. Currently, Tiles is designed to handle everyday tasks, with plans to expand into more domain-specific use cases over time. We provide a carefully tested combination of system prompts, tools, and models, so users do not need to manage model selection or scaffolding themselves.
We use [gpt-oss-20b](https://openai.com/index/introducing-gpt-oss/) as the primary model for everyday tasks, with the [Harmony renderer](https://developers.openai.com/cookbook/articles/openai-harmony/) and support for the [Open Responses API](https://www.openresponses.org/) to ensure optimal inference efficiency. Its Mixture of Experts architecture activates roughly 4B parameters at inference time out of 21B total parameters, providing a strong balance between quality and efficiency.
Memory capacity and memory bandwidth, not peak FLOPs, are the primary constraints for local inference. Personal computing assistants typically operate at batch_size = 1, where throughput is limited by memory movement rather than raw compute.
We started with Apple Silicon hardware because it offers strong memory unit economics relative to competing platforms, due to its unified memory architecture and high memory bandwidth per dollar.
This setup requires 16 GB of unified memory to run optimally. Adoption should not be a constraint, as all Macs shipped from late 2024 onward include 16 GB of base memory.
================================================================================
## Book: Tilekit (https://www.tiles.run/book/tilekit)
# Tilekit
## CLI
Commands in this section are for **developers** using Modelfiles with the Tiles CLI.
### Prompt optimization
The Tiles CLI includes DSRs ([dspy-rs](https://dsrs.herumbshandilya.com/)) to optimize SYSTEM prompts in Modelfiles automatically. Use tiles optimize to refine the SYSTEM prompt in your Modelfile with the COPRO optimizer.
[code block]
By default, this will:
- Generate 5 synthetic examples automatically if you do not provide your own training data
- Use openai:gpt-4o-mini as the optimization model
- Update your Modelfile in-place with the improved SYSTEM prompt
#### Examples
[code block]
#### Options
- --data : Provide your own training data as a JSON file
- --model : Specify a different model to use for optimization
#### Requirements
Your Modelfile must contain a starting SYSTEM prompt so the optimizer knows what to build on.
#### Training data format
If you supply your own data, use JSON like this:
[code block]
#### Example
Modelfile:
[code block]
Optimize using Claude:
[code block]
This rewrites the SYSTEM line with an improved version from the optimization run.
## SDK Reference
### 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](https://github.com/tilesprivacy/tiles/blob/main/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:
[code block]
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
[code block]
The example above is valid. Today, FROM and SYSTEM drive behavior directly; parameter validation still applies.
================================================================================
## Book: MIR Extension (https://www.tiles.run/book/mir)
# MIR Extension
Based on the specifications defined by Darkshapes' [MIR](https://huggingface.co/darkshapes/MIR_) (Machine Intelligence Resource), a naming schema for AIGC and ML work, and Ollama's [Modelfile](https://docs.ollama.com/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.
[code block]
## MIR Reference
Copied verbatim from: [github.com/darkshapes/MIR](https://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
[code block]
Code for this project can be found at [darkshapes/MIR](https://github.com/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:
| Abbreviation | Description |
| --------------- | ----------------------------------------- |
| GRU | Gated recurrent unit |
| RBM | Restricted Boltzmann machine |
| TAE | Tiny Autoencoder |
| VAE | Variable Autoencoder |
| LSTM | Long Short-Term Memory |
| RESNET | Residual Network |
| CNN | Convolutional Neural Network |
| RCNN | Region-based Convolutional Neural Network |
| RNN | Recurrent Neural Network |
| BRNN | Bi-directional Recurrent Neural Network |
| GAN | Generative Adversarial Model |
| SSM | State-Space Model |
| DETR | Detection Transformer |
| VIT | Vision Transformer |
| MOE | Mixture of Experts |
| AET | Autoencoding Transformer |
| STST | Sequence-to-Sequence Transformer |
| ART | Autoregressive Transformer |
| LORA | Low-Rank Adaptation |
| CONTROLNET | Controlnet |
| UNCLASSIFIED | Unknown |
---
#### 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):
[code block]
#### 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](https://github.com/darkshapes/nnll/tree/0.1.dev799):
MIR is inspired by:
- [AIR-URN](https://github.com/civitai/civitai/wiki/AIR-%E2%80%90-Uniform-Resource-Names-for-AI) project by [CivitAI](https://civitai.com/)
- [Spandrel](https://github.com/chaiNNer-org/spandrel/blob/main/libs/spandrel/spandrel/__helpers/registry.py) super-resolution registry by [chaiNNer](https://github.com/chaiNNer-org/chaiNNer)
- [SDWebUI Model Toolkit](https://github.com/silveroxides/stable-diffusion-webui-model-toolkit-revisited) by [silveroxides](https://github.com/silveroxides)
================================================================================
## Book: Security (https://www.tiles.run/book/security)
import { Callout } from 'nextra/components'
# Security
Tiles is designed around a local-first model. The goal is simple: keep personal context, identity, and memory under user control by default.
Tiles is still in alpha. Some parts of the system are already stable enough to describe clearly, while others are still being hardened.
Personal assistant trust model: this guidance assumes one trusted operator boundary per device or
gateway. Tiles is not a hostile multi-tenant boundary for adversarial users sharing one agent or gateway. If you
need mixed-trust operation, split trust boundaries with separate gateways, credentials, OS users, or hosts.
Inference runtime hardening with Stage-2 hypervisor memory isolation and hardware-backed attestation is on our
roadmap, enabling multi-tenant use cases out of the box.
## Local-First Architecture
The default experience runs on-device. The local server binds to localhost, and app data lives in standard local directories with support for a custom user data path.
## Local Data Protection
Tiles encrypts local SQLite databases at rest. The Rust application uses SQLCipher-enabled SQLite, and database connections are opened with a passkey retrieved from secure storage. That does not remove all local risk, but it does raise the bar against casual inspection of copied database files.
## Identity and Secret Storage
Device and account identity are based on did:key identifiers derived from Ed25519 keys. Private keys and database passkeys are stored in the operating system credential store rather than in app-managed plaintext configuration.
## Peer Linking and Sync
Tiles includes peer-to-peer device linking and chat sync. Linking is user-mediated: one device presents a ticket or local code, and the other side explicitly accepts or rejects it. Sync is limited to linked peers and bounded by a maximum downloaded delta size before processing.
### Iroh Relay and Sync Transport
Tiles sync uses Iroh endpoints, gossip topics, and blob tickets. In normal online operation, alpha builds rely on public Iroh relay infrastructure. On local networks, Tiles can fall back to mDNS for nearby discovery. The long-term plan is to move online relay infrastructure under direct Tiles control.
## Memory and Restricted Code Execution
Tiles currently includes a memory-agent flow that can execute generated Python against a designated memory path. That path has file-operation restrictions and basic size limits, but it is not a hardened sandbox and should not be described as strong isolation. This part of the system is transitional and not the long-term model for agent execution.
## Logging and Operational Boundaries
Tiles does not currently ship obvious built-in product analytics SDKs such as Sentry, PostHog, Segment, or Mixpanel. At the same time, the local Python server writes logs inside the Tiles data directory, and those logs may include request metadata, prompts, and request bodies.
## Updates and Supply Chain Trust
Tiles checks GitHub releases for updates and can install updates through a hosted installer script. That is convenient, but it is also a trust boundary. The current updater depends on the integrity of the Tiles release process and installer hosting rather than on a stronger built-in end-user verification flow.
Dependencies are pinned and reviewed before they are added. The macOS installer is code signed, notarized, and stapled. Tiles is also packaged with self-contained dependencies so normal installation does not depend on live package downloads.
## Vulnerability Disclosure
We publish a security policy and private disclosure path for vulnerabilities. Reports should go through GitHub Security Advisories or [security@tiles.run](mailto:security@tiles.run). See [SECURITY.md](https://github.com/tilesprivacy/tiles/blob/main/SECURITY.md).
## Current Strengths
- Local-first execution model with a localhost-bound application server
- Encrypted local databases for persisted account and chat data
- OS-backed secret storage for identity keys and database passkeys
- Device identity based on cryptographic keys instead of a required centralized account
- Explicit user approval during peer linking
- Defensive bounds on synced payload size
- Published vulnerability disclosure process
## Current Limits
- Local server logs may include prompt and request content
- Agents are not sandboxed today
- The memory execution environment is restricted, but not strongly isolated
- Offline pairing codes are still an evolving part of the linking model
- The update path is convenient, but remains a privileged remote installation flow
- Some transport-level guarantees depend on upstream networking components and are not yet explained in dedicated project documentation
## Summary
Tiles already implements several concrete privacy and security controls: local-first operation, encrypted local persistence, OS-backed secret handling, and explicit peer-to-peer linking. At the same time, the project still has meaningful trust boundaries and hardening work ahead.
Tiles should not be described as trustless. It should be described as software that keeps more sensitive state local by default and makes key security decisions more visible to the user.
================================================================================
## Book: Memory (https://www.tiles.run/book/memory)
import { ClickableImage as Image } from '@/components/clickable-image'
# Memory
Our long term goal is to solve memory in pursuit of software personalization through decentralized memory networks. We plan to use parametric approaches similar to those described in the [Memory Layers at Scale](https://arxiv.org/abs/2412.09764) paper by the FAIR research team at Meta. We test these experiments by deploying them in Tiles, where users can try them and provide real-world feedback. This feedback informs our ongoing research and is incrementally incorporated into future builds. Currently, memory models in Tiles can be accessed by running the Tiles CLI with the -m flag.
## Memory Models
Usable Prototype
January 2026 - Present
Our first experiment explores bundling a fine-tuned model to manage context and memories locally on-device using hyperlinked Markdown files. Currently, we use the [mem-agent](https://huggingface.co/driaforall/mem-agent) model from [Dria](https://dria.co/), based on [qwen3-4B-thinking-2507](https://github.com/QwenLM/Qwen3?tab=readme-ov-file#qwen3-2507), and are in the process of training our initial in-house memory models. Read more about their training process and scaffolding design in their paper [here](https://huggingface.co/blog/driaforall/mem-agent-blog).
These models use a human-readable external memory stored as Markdown, along with learned policies trained via reinforcement learning on synthetically generated data. These policies decide when to call Python functions that retrieve, update, or clarify memory, allowing the assistant to maintain and refine persistent knowledge across sessions.
### Implementation
The agent works with Obsidian-like directories of Markdown files as its knowledge base. These files are both human-readable and hyperlinked. The core protocol is defined in a single system prompt. The source is available [here](https://github.com/firstbatchxyz/mem-agent-mcp/blob/main/agent/system_prompt.txt).
Dria trained a fine-tuned model so the agent strictly adheres to the enforced prompt format.
Model generated Obsidian format Markdown file
Test user folder structure and the resulting knowledge graph
### Response Structure
The model's response is split into three structured sections:
- : reasoning
- : executable code that calls predefined functions
- : final output after memory interaction
### Execution
The Python block is executed in a sandbox, and its results are returned as tags. This is how the agent forms its reasoning to action loop.
**Pattern 1: When interacting with memory**
[code block]
**Pattern 2: When NOT interacting with memory**
[code block]
Tiles executes the generated Python code in a sandbox. The code calls tools such as create_file, update_file, and others mentioned above. These tools are plain Python functions.
[code block]
================================================================================
## Book: Community (https://www.tiles.run/book/community)
# Community
## Get Involved
Whether you are already committed to privacy technology or just beginning to reclaim ownership of your computing experience, there are many ways to get involved in the Tiles community.
To understand the project goals and architecture, start with:
- Install [Tiles CLI](/download) and try it out.
- Explore the documentation: [Tiles Book](https://tiles.run/book)
## Communication and Support
If you have questions or want to discuss ideas, you can reach the team and community via:
- Discord: https://go.tiles.run/discord
- Email: [hello@tiles.run](mailto:hello@tiles.run)
## Roadmap
Track our progress and see what's coming next on our [Roadmap](https://github.com/orgs/tilesprivacy/projects/4). The roadmap outlines our planned features, improvements, and research directions.
## RFCs
Join or contribute to the conversation about Tiles design and architecture through [Tiles RFC Discussions](https://github.com/orgs/tilesprivacy/discussions). RFCs (Request for Comments) are proposals that introduce major features, architectural changes, or significant new areas of functionality. We welcome community input on these proposals.
## Contributing
Thanks for your interest in contributing to Tiles. We welcome contributions of all kinds, including code, documentation, design, and discussion.
### How to Contribute
You can contribute in several ways:
- Report bugs or request features by opening an issue
- Improve documentation or examples
- Submit pull requests for bug fixes, refactors, or new features
- Open an RFC discussion for proposals that introduce major features, architectural changes, or significant new areas of functionality
Before starting work, check the existing issues to avoid duplication and to align with current priorities. If you plan to work on a larger change, open an issue or discussion first to confirm scope and approach.
### Pull Request Guidelines
When submitting a pull request:
- Keep changes focused and scoped to a single concern
- Follow existing code style and conventions
- Include clear commit messages and a concise PR description
- Reference relevant issues where applicable
- Ensure all checks and tests pass
New inference backends, memory models, and improvements aligned with the roadmap are especially welcome.
## Development Setup
This guide will help you set up a reproducible development environment for Tiles. Tiles supports two environments: prod (production) and dev (development). These instructions assume you are setting up for local development.
### Prerequisites
- [Rust & Cargo](https://www.rust-lang.org/tools/install)
- [just](https://github.com/casey/just) (for task management)
- [Python 3.13](https://www.python.org/downloads/)
- [uv](https://docs.astral.sh/uv/) (for fast Python dependency management)
- [Git](https://git-scm.com/)
### Setup Steps
1. **Clone the repository:**
[code block]
2. **Install Rust dependencies:**
If you're new to Rust, see [Rust Install Guide](https://www.rust-lang.org/tools/install).
[code block]
3. **Install project task runner:**
[just](https://github.com/casey/just) provides easy command shortcuts.
[code block]
4. **Set up the Python server environment:**
- Make sure [uv](https://docs.astral.sh/uv/) is installed:
[code block]
- Sync Python dependencies:
[code block]
### Running Tiles (Development)
Open two terminal windows:
1. **Terminal 1: Start the server**
From the project root:
[code block]
2. **Terminal 2: Run the Rust CLI**
From the root directory:
[code block]
> **Tip:** Refer to the justfile for additional common commands and automation. For troubleshooting, see [CONTRIBUTING.md](https://github.com/tilesprivacy/tiles/blob/main/CONTRIBUTING.md) and open an issue if you need help.
### Building Tiles installer (Development)
Install [venvstacks](https://github.com/lmstudio-ai/venvstacks?tab=readme-ov-file#installing) for portable py runtime
From the project root do:
[code block]
Set the ENV in install.sh to dev
[code block]
Now tiles should be available in PATH
## Code of Conduct
By participating in this project, you agree to follow the project's [Code of Conduct](https://github.com/tilesprivacy/tiles/blob/main/CODE_OF_CONDUCT.md). Be respectful, constructive, and collaborative in all interactions.
We appreciate your time and effort in helping build Tiles.
================================================================================
## Book: Resources (https://www.tiles.run/book/resources)
# Resources
Below is a living index of resources that inform and inspire our work.
## Motivations
- ✨ [This is Cuba's Netflix, Hulu, and Spotify – all without the internet](https://www.youtube.com/watch?v=fTTno8D-b2E)
- [Cuba's Underground Gaming Network](https://www.youtube.com/watch?v=lEplzHraw3c)
- ✨ [Weathering Software Winter](https://www.youtube.com/watch?v=9TJuOwy4aGA&t=968s)
- ✨ [The Memory Walled Garden](https://asimovaddendum.substack.com/p/the-memory-walled-garden)
- ✨ [The Resonant Computing Manifesto](https://resonantcomputing.org)
- ✨ [Why Tech Needs Personalization](https://om.co/2025/10/29/why-tech-needs-personalization/)
- ✨ [File over app](https://stephango.com/file-over-app)
- ✨ [Local-First Software: Taking Back Control of Our Data | a mini-doc](https://www.youtube.com/watch?v=10d8HxS4y_g)
## Links
- [PortableApps.com](https://en.wikipedia.org/wiki/PortableApps.com)
- [Mosh: the mobile shell](https://mosh.org)
- ✨ [Code Mode: give agents an entire API in 1,000 tokens](https://blog.cloudflare.com/code-mode-mcp/)
- ✨ [Uzu Inference engine architecture](https://docs.trymirai.com/overview/uzu)
- ✨ [Pie:Programmable LLM Serving](https://pie-project.org/)
- ✨ [Serve Programs, Not Prompts](https://ingim.org/papers/gim2025serve.pdf)
- ✨ [Pie: A Programmable Serving System for Emerging LLM Applications](https://ingim.org/papers/gim2025pie.pdf)
- ✨ [Intelligence Per Watt: A Study of Local Intelligence Efficiency](https://hazyresearch.stanford.edu/blog/2025-11-11-ipw)
- [The Bitter Lesson of LLM Extensions](https://www.sawyerhood.com/blog/llm-extension)
- ✨ [The Continual Learning Problem, Jessy Lin](https://jessylin.com/2025/10/20/continual-learning/)
- ✨ [mem-agent: Equipping LLM Agents with Memory Using RL](https://dria.co/research/mem-agent:-equipping-llm-agents-with-memory-using-rl)
- ✨ [Xet is on the Hub](https://huggingface.co/blog/xet-on-the-hub)
- ✨ [MIR, Machine Intelligence Resource, A naming schema for AIGC/ML work, Darkshapes](https://huggingface.co/darkshapes/MIR_)
- ✨ [Jan-nano Technical Report](https://arxiv.org/abs/2506.22760)
- [Minions: the rise of small, on-device LMs](https://hazyresearch.stanford.edu/blog/2025-02-24-minions)
- ✨ [Memory Layers at Scale, Meta FAIR](https://arxiv.org/abs/2412.09764)
- [On the Way to LLM Personalization: Learning to Remember User Conversations, Apple Machine Learning Research](https://machinelearning.apple.com/research/on-the-way)
- [Memory OS of AI Agent](https://arxiv.org/abs/2506.06326)
- ✨ [Self-driving infrastructure](https://vercel.com/blog/self-driving-infrastructure)
- ✨ [LoRA Without Regret](https://thinkingmachines.ai/blog/lora/)
- ✨ [A Preliminary Report On Edge-Verified Machine Learning (evML)](https://github.com/exo-explore/evML/blob/main/A_Preliminary_Report_On_evML.pdf)
- ✨ [Pretraining with hierarchical memories: separating long-tail and common knowledge, Apple](https://www.arxiv.org/abs/2510.02375)
- [Titans + MIRAS: Helping AI have long-term memory, Google Research](https://research.google/blog/titans-miras-helping-ai-have-long-term-memory/)
- [LoRA Learns Less and Forgets Less](https://arxiv.org/abs/2405.09673)
- ✨ [The Bitter Lesson is coming for Tokenization](https://lucalp.dev/bitter-lesson-tokenization-and-blt/)
- ✨ [Text-to-LoRA: Hypernetworks that adapt LLMs for specific benchmark tasks using only textual task description as the input, Sakana AI](https://arxiv.org/abs/2506.06105)
- [Transformer²: Self-Adaptive LLMs](https://sakana.ai/transformer-squared/)
- [How memory augmentation can improve large language models, IBM Research](https://research.ibm.com/blog/memory-augmented-LLMs)
- [Mixture-of-Depths: Dynamically allocating compute in transformer-based language models](https://arxiv.org/abs/2404.02258)
- ✨ [The Power of Efficiency: Edge AI's Role in Sustainable Generative AI Adoption](https://creativestrategies.com/research/gen-ai-edge-testing/)
- ✨ [Small Language Models are the Future of Agentic AI, NVIDIA Research](https://arxiv.org/abs/2506.02153)
- ✨ [Defeating Prompt Injections by Design, Google Deepmind](https://arxiv.org/abs/2503.18813)
- [LLM in a flash: Efficient Large Language Model Inference with Limited Memory](https://arxiv.org/abs/2312.11514)
- [Introducing FlexOlmo: a new paradigm for language model training and data collaboration, Allen AI](https://allenai.org/blog/flexolmo)
- [WhisperKit: On-device Real-time ASR with Billion-Scale Transformers, Argmax](https://openreview.net/attachment?id=6lC3MPFbVg&name=pdf)
- ✨ [Towards Large-scale Training on Apple Silicon, Exo Labs](https://openreview.net/pdf?id=TJjP8d5bms)
- [Kinetics: Rethinking Test-Time Scaling Laws](https://openreview.net/attachment?id=qxnJrm47Ag&name=pdf)
- [Enhancing Reasoning Capabilities of Small Language Models with Blueprints and Prompt Template Search](https://openreview.net/attachment?id=LsNstclw8Z&name=pdf)
- [LoFT: Low-Rank Adaptation That Behaves Like Full Fine-Tuning](https://arxiv.org/pdf/2505.21289)
- [AirLLM: Diffusion Policy-based Adaptive LoRA for Remote Fine-Tuning of LLM over the Air](https://arxiv.org/abs/2507.11515)
- [Comparative Analysis of Retrieval Systems in the Real World](https://arxiv.org/pdf/2405.02048)
- [FedVLM: Scalable Personalized Vision-Language Models through Federated Learning](https://arxiv.org/abs/2507.17088)
- [On the Way to LLM Personalization: Learning to Remember User Conversations](https://arxiv.org/abs/2411.13405)
- [A Preliminary Report On Edge-Verified Machine Learning, Exo Labs](https://github.com/exo-explore/evML/blob/main/A_Preliminary_Report_On_evML.pdf)
- ✨ [Model Merging in LLMs, MLLMs, and Beyond: Methods, Theories, Applications and Opportunities](https://arxiv.org/abs/2408.07666)
- ✨ [Intent-Based Architecture and Their Risks](https://www.paradigm.xyz/2023/06/intents)
- [Your LLM Knows the Future: Uncovering Its Multi-Token Prediction Potential](https://arxiv.org/abs/2507.11851)
- [Cephalo: Multi-Modal Vision-Language Models for Bio-Inspired Materials Analysis and Design](https://arxiv.org/abs/2405.19076)
- [Towards Feasible Private Distributed LLM Inference, Dria](https://dria.co/research/towards-feasible-private-distributed-llm-inference)
- ✨ [ChatGPT Memory and the Bitter Lesson](https://www.shloked.com/writing/chatgpt-memory-bitter-lesson)
- ✨ [OpenPoke: Recreating Poke's Architecture](https://www.shloked.com/writing/openpoke)
- [Anthropic's Opinionated Memory Bet](https://shloked.com/writing/claude-memory-tool)
- [Mind the Trust Gap: Fast, Private Local-to-Cloud LLM Chat](https://hazyresearch.stanford.edu/blog/2025-05-12-security)
- [MCP Colors: Systematically deal with prompt injection risk](https://timkellogg.me/blog/2025/11/03/colors)
- [New physical attacks are quickly diluting secure enclave defenses from Nvidia, AMD, and Intel](https://arstechnica.com/security/2025/10/new-physical-attacks-are-quickly-diluting-secure-enclave-defenses-from-nvidia-amd-and-intel/)
- [Benchmarking Honcho](https://blog.plasticlabs.ai/research/Benchmarking-Honcho)
- [Git Based Memory Storage for Conversational AI Agent](https://github.com/Growth-Kinetics/DiffMem)
- [What happened to custom ROMs?](https://www.youtube.com/watch?v=HImV4rSps48)
- [Ellora: Enhancing LLMs with LoRA](https://github.com/codelion/ellora_)
- ✨ [Understanding AI/LLM Quantisation Through Interactive Visualisations](https://smcleod.net/2024/07/understanding-ai/llm-quantisation-through-interactive-visualisations/)
- ✨ [User-Agent header, MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/User-Agent)
- [The GPU-Poor LLM Gladiator Arena](https://huggingface.co/spaces/k-mktr/gpu-poor-llm-arena)
- ✨ [The Kaitchup Index: A Leaderboard for Quantized LLMs](https://kaitchup.substack.com/p/the-kaitchup-index)
- [InferenceMAX™: Open Source Inference Benchmarking](https://newsletter.semianalysis.com/p/inferencemax-open-source-inference)
- [RFT, DPO, SFT: Fine-tuning with OpenAI: Ilan Bigio, OpenAI](https://www.youtube.com/watch?v=JfaLQqfXqPA)
- ✨ [Hand-picked selection of articles on AI fundamentals/concepts that cover the entire process of building neural nets to training them to evaluating results.](https://aman.ai/primers/ai/)
- ✨ [The State of Open Models](https://youtu.be/FUcilE5Gx_0?si=9aP_NAzTKi8qw78n)
- ✨ [The State of On-Device LLMs](https://app.getcontrast.io/register/sota-the-state-of-llms)
- [How to Scale Your Model](https://jax-ml.github.io/scaling-book/)
- ✨ [r/LocalLLaMA](https://www.reddit.com/r/LocalLLaMA/)
- ✨ [An Analogy for Understanding Transformers](https://www.lesswrong.com/posts/euam65XjigaCJQkcN/an-analogy-for-understanding-transformers)
- ✨ [Neural networks, 3Blue1Brown](https://www.youtube.com/playlist?list=PLZHQObOWTQDNU6R1_67000Dx_ZCJB-3pi)
- [GGUF Quantization Docs (Unofficial)](https://github.com/iuliaturc/gguf-docs)
- [Reverse-engineering GGUF | Post-Training Quantization](https://www.youtube.com/watch?v=vW30o4U9BFE)
- [Choosing a GGUF Model: K-Quants, I-Quants, and Legacy Formats](https://kaitchup.substack.com/p/choosing-a-gguf-model-k-quants-i)
- [Reference implementation of the Transformer architecture optimized for Apple Neural Engine](https://github.com/apple/ml-ane-transformers)
- ✨ [LLMs on a Budget](https://benjaminmarie.gumroad.com/l/llms-on-a-budget)
- ✨ [Personalized Machine Learning](https://cseweb.ucsd.edu/~jmcauley/pml/)
================================================================================
## Book: Licenses (https://www.tiles.run/book/licenses)
# Licenses
Tiles is free to use without limits. Licenses are optional and help fund independent development.
## Overview
- **Backer license**: for individual supporters with a one-time payment.
- **Commercial license**: for teams and organizations, priced per user per year.
- **Commercial use**: payment is encouraged, not required.
## Polar checkout details
Tiles purchases are processed through [Polar](https://polar.sh), which acts as merchant of record for payment processing.
### Payment methods
- Card payments are supported through Polar checkout.
- Wallet payments like Apple Pay and Google Pay are supported when device and browser requirements are met.
- For embedded checkout implementations, Polar requires manual domain validation to enable wallet methods. This does not apply to standard hosted checkout pages.
Reference: [Polar checkout wallet methods](https://docs.polar.sh/features/checkout/embed)
### Taxes, receipts, and invoices
- Polar handles sales tax and VAT collection as part of checkout.
- Polar handles invoicing and receipts for completed purchases.
Reference: [Polar platform overview](https://docs.polar.sh/)
### Customer portal
- Polar provides a customer portal where customers can view orders and subscriptions.
- Portal settings can expose actions like updating billing details and canceling subscriptions, depending on how the seller configures the portal.
Reference: [Polar customer portal](https://docs.polar.sh/integrate/sdk/adapters/nextjs)
## Backer
The Backer license is designed for individual supporters who want to help sustain the project.
### Payment
- Price: **$50 USD**
- Cadence: **one-time payment**
- Checkout: [Buy Backer license](https://buy.polar.sh/polar_cl_UaSG3EKkZRlrPdoeCThS8emJvA7eOCcCHyjdZ1uXyAW)
### What it includes
- Managed public relays for sync
- Direct support for development and relay infrastructure
- More say in what we build next
## Commercial
The Commercial license is designed for teams and organizations using Tiles for work.
### Payment
- Price: **$100 USD**
- Cadence: **per user, per year**
- Checkout: [Buy Commercial license](https://buy.polar.sh/polar_cl_acVtj1bKcYElIOYc7EuQSJuT9fzwSKHf0Gpd20jDseq)
- Bulk purchases: [support@tiles.run](mailto:support@tiles.run)
### What it includes
- Self-hosted relays for sync
- Recognition as a featured organization
## Notes
- Backer and Commercial licenses are non-refundable.
- Tiles remains free to use without payment.
- License purchases support the long-term independence of Tiles.
================================================================================
