TilesTiles
DownloadBuy $50
Skip to Content
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) to optimize SYSTEM prompts in Modelfiles automatically. Use tiles optimize to refine the SYSTEM prompt in your Modelfile with the COPRO optimizer.

tiles optimize <MODELFILE_PATH> [--data <path>] [--model <provider:model-name>]  # Optimize SYSTEM prompt in Modelfile

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

# Optimize SYSTEM prompt in a Modelfile
tiles optimize path/to/Modelfile
 
# Optimize with custom training data
tiles optimize ./Modelfile --data training-data.json
 
# Optimize using a specific model
tiles optimize ./Modelfile --model anthropic:claude-3-5-sonnet-20240620

Options

  • --data <path>: Provide your own training data as a JSON file
  • --model <provider:model-name>: 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:

[
  {
    "input": "User query here",
    "output": "Expected AI response here"
  }
]

Example

Modelfile:

FROM llama3
SYSTEM "You are a helpful assistant."

Optimize using Claude:

export ANTHROPIC_API_KEY=sk-ant-...
tiles optimize ./Modelfile --model anthropic:claude-3-5-sonnet-20240620

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 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.