Customization Job Reference
Use this page when you need field-level details for customization job specifications, the complete API schema, or integration options.
For concepts, see Customization Job overview.
Key Fields
A customization job is submitted with a backend-specific spec (AutomodelJobInput for the automodel backend, UnslothJobInput for the unsloth backend). Both specs share the same top-level envelope, but several field names differ between backends. The table below lists the common envelope; for the full per-backend field list, see Training Configuration.
Deployment config validation
All three backends (automodel, unsloth, RL) resolve a referenced deployment_config at submit time and reject it before any GPU time is spent. A job fails to submit when:
- The string reference does not resolve to a deployment config.
- The job trains a standalone LoRA adapter and the referenced config has
lora_enabled: false— the deployment could never load the adapter. - The job trains a standalone LoRA adapter and the referenced config names a model other than the job’s base model. The adapter is served from its base model’s deployment, so the config has to target that base.
- The job registers a new model entity (
all_weights, or a LoRA job with a merged save method) and the referenced config names a different model. The output entity does not have to exist yet — a config may point forward at the model the run will produce, which is what Studio creates up front. Retraining is fine for the same reason. - The config sets
tool_call_config.tool_call_pluginand the caller lacks themodels.tool-call-plugin.setpermission.
A merged save (lora_merged, or unsloth’s merged_16bit / merged_4bit) folds the adapter into the base weights and produces a standalone model, so the LoRA-specific rules above do not apply to it.
Two config shapes are therefore valid ahead of a model that does not exist yet:
- A forward reference — the config names the model the run will produce. Creating it up front means a bad engine or image is rejected in milliseconds at submit instead of after a training run, and the deployment can start the moment training ends. One config per run.
- An unbound template — a config with neither
model_entity_idnormodel_spec.model_name. It carries only engine and executor settings, is accepted by any job, and is bound to the trained model at deploy time. Use this to share settings across runs.
Complete API Reference
For generated REST API details, see the Customizer API Reference and search for AutomodelJobInput or UnslothJobInput.
Weights & Biases Integration
Both backends accept the same integrations object on the job spec. Add a wandb block to request W&B tracking; the training runtime activates it when the required credentials are available.
The api_key_secret field references a stored secret containing your WANDB_API_KEY. Use the secret name (e.g., "my-wandb-key") to resolve it from the request workspace. To create the secret, see Weights & Biases Keys.
To view your training metrics in W&B after the job starts, see ft-tut-metrics-wandb.
MLflow Integration
Add an mlflow block to the same integrations object to request MLflow tracking:
Next Steps
- Create a customization job: Start a job with a model, dataset, training configuration, and optional integrations.
- Monitor training metrics: View logs and metrics through MLflow or W&B.
- Manage secrets: Store credentials such as W&B API keys and provider tokens.
- Troubleshooting MLflow integrations: Diagnose failed or misconfigured customization jobs.