Skip to main content
Glama

create fine tuning job

create_fine_tuning_job

Start supervised or spec-draft fine-tuning of a catalog base model on your uploaded file or workspace dataset, with validated hyperparameters, then poll the returned job ID for status.

Instructions

Start a supervised (SFT/LoRA) or spec-draft fine-tune of a catalog base model on an uploaded file or a workspace dataset, with bounds-checked hyperparameters — the way a customer trains a custom model from their own data. POST /v1/fine_tuning/jobs (API-key scope: platform:write). SPENDS MONEY: this starts billable work on the workspace wallet. Returns: 201 {id (job id for all other /v1/fine_tuning/jobs/{id} calls), provider_job_id}. Poll GET /v1/fine_tuning/jobs/{id} for status and fine_tuned_model. Notes: MONEY: the wallet must hold a prepay runway of (1,000,000 estimated trained tokens × the model's per-token rate incl. markup) or the call fails 402 "Insufficient balance: starting a fine-tune requires at least $X of runway. Top up and try again."; the final charge is metered from real trained tokens on completion (billed_cost_usd). Requires OWNER/ADMIN minting user (403). Rate limited per workspace: 20 creates per 60s → 429 with Retry-After. 400 "Invalid JSON body" or "Invalid body: " (e.g. missing training data: pass training or training_file_id). 400 when no price is configured for the model ("No fine-tuning price is set for this model yet."). Top-level keys accept both snake_case and camelCase; nested hyperparameter/integration/mapping keys are snake_case only. Feature-flag gated (404 when fineTuning is off). Scopes not enforced on this route today.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDisplay name for the job (≤300 chars).
seedNoTraining seed, integer 0..2147483647.
methodNo"supervised" (SFT / LoRA; default) or "spec-draft" (train a draft speculator for speculative decoding). Default: "supervised".
suffixNoSuffix appended to the fine-tuned model name (≤120 chars).
trainingNoTraining data source (required unless training_file_id is given). Either {kind:"file", file_id: string (a provider_file_id from /v1/fine_tuning/files; alias fileId)} or {kind:"dataset", provider_dataset_id: string (alias providerDatasetId; a workspace dataset's provider id), version?: string (≤200), mapping: <column mapping>}. mapping is one of: {type:"text", text:{type:"column", name}} | {type:"prompts", prompt:{type:"column", name}, completion:{type:"column", name}} | {type:"messages", messages:{type:"column", name}} | {type:"pretokenized", input_ids:{type:"column", name}, labels?:{type:"column", name}, attention_mask?:{type:"column", name}}. Datasets are converted to a training file after the wallet gate. The file/dataset MUST belong to this workspace (404 "Training file not found" / "Dataset not found" otherwise).
base_modelYesBase model id from the fine-tunable catalog (1..300 chars). Supervised jobs accept only the curated fine-tunable list (400 "This model isn't available for fine-tuning. Pick one from the list."); spec-draft jobs need a model in the spec-draft catalog. camelCase alias baseModel also accepted (camelCase wins if both present).
validationNoOptional held-out/validation data source, same shape as training ({kind:"file", file_id} or {kind:"dataset", provider_dataset_id, version?, mapping}). Providing one is what makes a later bake-off (POST /v1/fine_tuning/jobs/{id}/bakeoff) possible.
integrationsNoUp to 10 export integrations; ONLY these two types are accepted (anything else is 400): {type:"wandb", wandb:{project (1..200), api_key (1..500), name? (≤200), entity? (≤200), tags? (≤50 strings ≤100)}} or {type:"hf", hf:{output_repo_name (1..200), api_token (1..500)}}.
hyperparametersNoSupervised hyperparameters, all optional and bounds-checked (400 naming the field otherwise): n_epochs (int 1..100), learning_rate (number >0 and ≤1), batch_size (int 1..1024), context_length (int 128..262144), warmup_ratio (0..1), weight_decay (0..1), packing (boolean), max_grad_norm (>0 and ≤1000), lora (boolean; some bases are full-parameter only → 400 "… supports full-parameter fine-tuning only"), lora_r (int 1..512), lora_alpha (int 1..1024), lora_dropout (0..1). Keys are snake_case only.
training_file_idNoLegacy shortcut: a provider_file_id to train on (1..500 chars); equivalent to training:{kind:"file", file_id}. Ignored when training is present. Alias trainingFileId.
validation_file_idNoLegacy shortcut for validation:{kind:"file", file_id}. Alias validationFileId.
spec_draft_hyperparametersNoSpec-draft hyperparameters (used when method="spec-draft"): the common fields n_epochs, learning_rate, batch_size, context_length, warmup_ratio, weight_decay, packing, max_grad_norm (same bounds as above) plus architecture (string ≤200), num_decoding_heads (int 1..16), loss (string ≤100). Alias specDraftHyperparameters.
Install Server

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes far beyond the annotations by disclosing that the call 'SPENDS MONEY' from the workspace wallet, that a prepay runway is required or the call fails 402, and that the final charge is metered from real trained tokens. It also discloses role requirements, rate limits, the 'scopes not enforced today' caveat, snake_case/camelCase conventions, and exact 400/404 trigger conditions. No contradiction with annotations — readOnlyHint=false, idempotentHint=false, and openWorldHint=true are all consistent with billable, externally-visible side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the two most decision-relevant facts — what the tool does and 'SPENDS MONEY' — before any schema-level detail, and every section carries operational value. It is not a 5 because it is a single dense wall of text that repeats information already present in the schema (e.g., hyperparameter bounds are summarized again), so it could be tightened or lightly structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a money-spending mutation with 12 parameters, nested objects, and no output schema, the description covers the response shape (201 {id, provider_job_id}), the mandatory follow-up (poll GET for status and fine_tuned_model), all major error codes with their triggers, the workspace-membership constraint, and the feature-flag gate. Nothing an agent needs to invoke it correctly is left to inference.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so a baseline of 3 applies, but the description adds genuine cross-parameter semantics absent from the schema: training_file_id is 'Ignored when training is present,' top-level keys accept camelCase while nested keys are snake_case only, camelCase wins on base_model if both are present, validation is what enables a later bake-off, and spec_draft_hyperparameters apply only when method='spec-draft'. These precedence and conditional-usage rules meaningfully help an agent construct a valid request.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Start a supervised (SFT/LoRA) or spec-draft fine-tune of a catalog base model on an uploaded file or a workspace dataset.' It names both training modes and both data-source flavors, and makes clear this is the creation entry point versus sibling list/get/cancel tools without needing to inspect them.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit preconditions and failure gates: wallet runway (402), OWNER/ADMIN requirement (403), feature-flag gating (404), per-workspace rate limit (429 with Retry-After), and the follow-up flow ('Poll GET /v1/fine_tuning/jobs/{id} for status'). It stops short of a full 5 because it never explicitly contrasts alternative training-related creation tools (e.g., start_grpo_run or create_batch), so the when-not-to-use guidance is implied through failure conditions rather than named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/omnia-v/errorbar-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server