runbios-mcp 0.5.0 → 0.6.0-dev.368

package/dist/server.js

@@ -844,8 +844,6 @@ launchGates = resolveLaunchGates(), allowedTools) {
         epochs: z.number().positive().max(1000).optional().describe("Number of training epochs. Governs the full run when max_steps is omitted (the default)."),
         max_steps: z.number().int().min(1).max(10_000_000).optional().describe("Optional hard step cap that overrides epochs. Omit for no cap and all configured epochs; setting less than one epoch intentionally trains only part of the data."),
         learning_rate: z.number().positive().max(1).optional().describe("Learning rate."),
-        batch_size: z.number().int().min(1).max(65536).optional().describe("Per-device train batch size."),
-        gradient_accumulation_steps: z.number().int().min(1).max(65536).optional(),
         max_seq_length: trainingSeqLengthSchema(),
         lora_rank: z.number().int().min(1).max(4096).optional(),
         lora_alpha: z.number().positive().max(1_000_000).optional(),
@@ -857,6 +855,12 @@ launchGates = resolveLaunchGates(), allowedTools) {
             .describe("Learning-rate scheduler."),
         job_name: z.string().max(255).optional(),
         eval_split_ratio: z.number().min(0).max(0.99).optional(),
+        validation_rows: z.number().int().min(0).max(50_000_000).optional()
+            .describe("Validation rows held out and never trained on (0 turns validation off). Allowed: 100 (or 5% when that is fewer) up to 40% of the training rows; unset, 5% capped at 1,000. Preflight returns the exact range. Do not send with eval_split_ratio."),
+        precision: z.enum(["bf16", "fp8"]).optional()
+            .describe("Training precision. Offer only what get_managed_training_options lists for the model and adapter; bf16 is the default."),
+        optim: z.enum(["adamw_torch_fused", "adamw_8bit"]).optional()
+            .describe("Optimizer state: adamw_torch_fused (16-bit, default, most accurate) or adamw_8bit (less memory). Offer only what get_managed_training_options lists."),
         eval_steps: z.number().int().positive().optional().describe("Evaluate every N optimizer steps when a validation split exists."),
         save_steps: z.number().int().positive().optional().describe("Checkpoint interval in optimizer steps."),
         early_stopping_patience: z.number().int().min(0).max(20).optional()
@@ -918,7 +922,7 @@ on.
 8. loop_list_models - The models a pipeline can train, and the platform's fixed sample minimums (floors). The only list a pipeline's model may come from; unavailable says, in one plain sentence per model, why one is not offered.
 9. loop_create_pipeline - One use case: a name, a model (optionally a second model, a different one), its tags, when to train (optionally a schedule; the sample minimums are fixed by the platform) and how a new version goes live. It switches on the source named by its pipeline ID, so an app can send samples at once. SPEND CONSENT: saving it authorises trainings on the workspace's wallet whenever its data has grown enough; the platform chooses the GPUs, and what is charged is the GPU time its trainings use and, where the platform scores samples, the judge's scoring of unreviewed samples, shown on the training it was for. Say so and wait for a yes.
 10. loop_list_pipelines / loop_get_pipeline / loop_list_pipeline_attempts / loop_update_pipeline / loop_delete_pipeline - Each pipeline's versions (only trainings that went live: v1, v2 ...: version version numbers count up; nothing untested goes live any more, and each version's tested says whether it was), its trainings and how each ended (the latest on the pipeline, every one a page at a time with loop_list_pipeline_attempts, each with an explanation in plain words), the live version and whether its deployment answers (live_deployment), status and next_reason, and its settings. Deleting a pipeline stops its live version's deployment (unless another pipeline or model name answers from it too) and deletes its history.
-11. loop_run_pipeline / loop_import_into_pipeline - Train now (skips the schedule, never the minimum), and bring a file in as this pipeline's samples.
+11. loop_run_pipeline / loop_import_into_pipeline - Train now (skips the schedule, never the minimum), and bring a file in as this pipeline's samples. loop_list_live_deployments / loop_use_live_deployment - when the live version's deployment was deleted, find a deployment of its weights and answer the app from it; nothing is trained again.
 12. loop_create_benchmark / loop_list_benchmarks / loop_get_benchmark / loop_list_benchmark_items / loop_get_benchmark_history / loop_retire_benchmark / loop_get_benchmark_run / loop_list_benchmark_run_items / loop_benchmark_questions - Benchmarks: fixed sets of the user's questions with right answers that every training is tested on, so "is it getting better" has a yardstick that does not move, and each benchmark run's report: its scores, how many questions each model got right (score 0.70 or more), and every question behind them. loop_benchmark_questions shows each question with how a pipeline's recent trainings did on it.
 13. loop_list_pipeline_benchmarks / loop_attach_pipeline_benchmark / loop_move_pipeline_benchmark / loop_remove_pipeline_benchmark / loop_compare_versions / loop_compare_attempts - A pipeline's benchmarks in priority order (1 is the primary), its versions side by side (v1 against v5), and any two trainings side by side, live or not, question by question on the automatic-test questions both were scored on.
 14. loop_list_training_runs / loop_get_training_run / loop_get_training_curve - Every training of every pipeline (result filters by what became of it; each item's 'attempt' is the training as its pipeline's own list says it): its timeline, why it went live or did not (its going-live record, and verdict_checks: every bar its test needed, what it got and whether it was met), what each part cost, and available_actions — what this reader may actually do next, rather than what the state looks like it allows. loop_get_training_curve shows how one went while it trained, step by step, and the step it kept.
@@ -1172,6 +1176,7 @@ get_inference_status instead of asserting them.
 5. get_model_config - Get recommended settings for your chosen model
 6. list_supported_architectures - Check which architectures can be trained or served
 7. get_training_capabilities - Read the authoritative training contract; call this before building automated payloads
+7a. get_managed_training_options - With managed_training on: the context lengths, precisions and optimizer states a model can be trained with; offer only these
 8. get_gpu_pricing - See GPU options and pricing
 9. get_recommended_gpu - Read default-config sizing; use full preflight for the actual run
 9a. recommend_training_config - Ask the trainer's sizing model for batch, accumulation, LR, predicted peak memory, minimum GPU count and wall clock on the GPU you picked; check your own batch size against it
@@ -1232,25 +1237,18 @@ Option B: Import from HuggingFace — call import_huggingface_dataset with a rep
 
 Dataset upload accepts one file type: JSONL. SFT rows may use messages, conversations, instruction/output, prompt/completion, query/response, input/output, question/answer, or problem/solution. CPT rows require a non-empty text field. Preference, reward, KTO, GRPO, PPO, and GKD datasets are refused while those training methods are unavailable.
 
-### Step 4: Choose method, adapter, and the complete training configuration
-Call get_model_config and get_training_capabilities. Choose SFT or CPT, adapter, sequence length, per-device batch, gradient accumulation, optimizer, precision, epochs/optional max_steps, validation and checkpoint settings BEFORE asking for a GPU. Empty max_steps means no cap: all configured epochs train. Early stopping defaults on when validation exists.
+### Managed training (check first)
+Call get_training_capabilities. If its features list has managed_training enabled, the platform chooses the hardware: do NOT choose or send a GPU, GPU count, per-device batch, gradient accumulation, recompute level, checkpoint count or price cap -- they are ignored (preflight warns FIELD_IGNORED). Call get_managed_training_options for the model, method and adapter, and offer only what it returns: the context length (max_length, one of 2048-131072), precision (bf16 or fp8) and optimizer state (optim: adamw_torch_fused = 16-bit, adamw_8bit = 8-bit). Send only: model, method (sft/cpt), adapter (lora/qlora/full), dataset(s), max_length, precision, optim, learning_rate, lr_scheduler_type, warmup_ratio, weight_decay, epochs or max_steps, lora_rank (8-64), lora_alpha, and optionally validation_rows (0 turns validation off) and early_stopping_patience. On preflight_training_job and create_training_job these are the inputs max_seq_length, precision, optim, scheduler, validation_rows. Validation rows must be between 100 (or 5% of the rows when that is under 100) and 40% of the training rows; unset, the job holds out 5% capped at 1,000 rows, and preflight returns the exact rows and range in validation. Unset, the schedule is cosine; it keeps its best (lowest validation loss) and latest checkpoints, is charged per trained token only, and waits unbilled in the queue, first come first served, when no machine is free (the customer is emailed when it starts and may cancel it while queued). Training logs and machine metrics (memory, MFU, throughput) are not available to the customer: report progress from get_training_status and training metrics from get_training_metrics. Samples longer than max_length lose their oldest turns, never the answer; image samples that do not fit are skipped. Preflight returns the placement validity and, when token_billing is enabled, an estimate (estimated tokens and cost at the model's per-token price; the charge is the exact tokens trained). Customers never see hardware; do not describe GPUs to them.
 
-### Step 5: Preflight the complete request and choose a GPU LAST
-Call preflight_training_job with the model, dataset(s), method, adapter and complete config. Its GPU choices are sized from ALL of those inputs and joined to live inventory. Choose only a returned configuration; never guess a GPU count or use a choice below min_gpus.
+### Step 4: Preflight
+Call preflight_training_job with the model, dataset(s), method, adapter and training settings. It returns valid, the validation rows and their allowed range, warnings and the per-token cost estimate. Show the estimate to the user before creating.
 
-### Step 6: Create the training job
-Call create_training_job with:
-- model: the model name from step 2
-- dataset_id: the ID from step 3
-- method: "sft" for instruction tuning (most common)
-- adapter: "lora" (fastest, recommended for first jobs)
-- Leave other params as defaults unless you have specific needs
+### Step 5: Create the training job
+Call create_training_job with the same request. The job is placed on tested machines; when none is free it is queued (first come first served, unbilled) and starts automatically. The user is emailed when it starts and can cancel at any time with stop_training_job.
 
-### Step 7: Monitor progress
-create_training_job books a GPU before returning (~40s). A 'booked' status means the GPU is secured (booked==secured) and training is starting; 'securing' means it is still booking — poll get_training_status until 'booked'/'running'. A booking-time capacity miss returns CAPACITY_UNAVAILABLE and no job is created.
-Call get_training_status periodically. Training typically takes 1-4 hours for small models.
-If a started job loses its pod it rests at 'interrupted' (billing already stopped, not 'failed') — call resume_training_job to continue from the last checkpoint.
-Call get_training_metrics for semantic summaries first; request a bounded series when you need to inspect curve shape. Follow each metric's returned goal instead of assuming every number should decrease.
+### Step 6: Monitor progress
+Call get_training_status for progress (queued, getting ready, downloading the model, preparing data, training step N of M, saving). Call get_training_metrics for loss, eval loss, gradient norm, token accuracy, learning rate and tokens trained. The job keeps two checkpoints: the best (lowest validation loss) and the last.
+If a started job loses its machine it rests at 'interrupted' (nothing is charged for that) -- call resume_training_job to continue from the last checkpoint.
 
 ### Tips
 - Start with LoRA, not full fine-tune — it's 10x faster and 5x cheaper
@@ -1357,25 +1355,21 @@ When to use: Before SFT, when your domain has specialized vocabulary/knowledge.
 - A VLM architecture does not imply support for image-only pretraining or multimodal preference objectives.
 - DPO, PPO and GRPO are not enabled by these training tools. They require separately verified training implementations; PPO/GRPO also require rollout inference and reward handling.
 - Training starts from catalog models. Do not promise a CPT-to-SFT pipeline using a customer's trained checkpoint as a new training source: that workflow is not exposed here.`,
-            gpu_selection: `# GPU Selection Guide
-
-## Configure first, choose the GPU last
-1. Select the catalog model and revision, method, adapter and compatible datasets.
-2. Set supported configuration fields from get_training_capabilities: sequence length, batch and accumulation, validation and run-length bounds. Review effective precision/optimizer settings; leave disabled engine-managed controls such as activation checkpointing to the engine.
-3. The current preflight API requires a concrete gpu_type/gpu_count. Use get_recommended_gpu only to obtain a provisional candidate, then call preflight_training_job with that candidate and the complete configuration. Never treat default-config sizing as approval of the final run.
-4. Review the service-calculated minimum, supported counts and current quote. Choose only a qualifying available type/count. Fit is not stock, and an unknown availability result is not permission to book.
-5. Re-run preflight after changing any sizing input or GPU choice; create only after valid=true with the final selection. GPU-free preflight discovery is not currently supported by the deployed API.
-
-## Booking and recovery
-- Create rechecks capacity. Do not report a run as started while it is only securing; booked means capacity was accepted, not that the trainer has begun executing steps.
-- A capacity miss must show fresh qualifying alternatives and preserve the configuration. Ask before substituting hardware or exceeding a price cap.
-- Queueing is explicit consent and applies only when no qualifying alternative is available. Waiting is unbilled.
-- Reuse the idempotency key after timeouts instead of creating a second run.
-
-## Memory and quality
-- Memory depends on the full configuration and input shapes, not parameter count alone. Do not invent a smaller minimum or claim that quantization always halves total memory.
-- Full fine-tuning is not a guarantee of higher accuracy than adapters. Use representative validation to compare outcomes.
-- Preflight admission is not proof of universal freedom from hardware faults or OOM. Report actual tested configurations and measured headroom.`,
+            gpu_selection: `# Machines (managed training)
+
+The platform chooses the machines. Do not choose, ask for, or describe GPUs, GPU counts, batch size, gradient accumulation, memory settings, checkpoint counts or price caps: the training tools do not take them, and the API ignores them with a FIELD_IGNORED warning.
+
+## How a job is placed
+- Every offered combination of model, adapter, context length, precision and optimizer was measured on our machines first. get_managed_training_options lists exactly what is offered for a model and adapter; anything else is refused before any money is spent, with a reason.
+- The platform picks the fastest tested setup that fits the job, with batch and memory settings that keep it from running out of memory, and checks the run's memory again before it starts.
+- Short samples are packed together into each context window, so a longer context costs no speed.
+
+## When no machine is free
+- The job waits in the queue, first come first served with fair turns per user. Waiting is never charged and a queued request expires after seven days.
+- It starts automatically and the user is emailed when it does. It can be cancelled at any time, queued or running.
+
+## What the user pays
+- Only for the exact tokens trained, at the model's per-token price. preflight_training_job returns the estimate.`,
             serverless_inference: `# Serverless Inference
 
 Serverless is the immediate, per-token inference product. It does NOT create or manage a deployment and does not reserve a GPU.
@@ -1490,149 +1484,55 @@ ignored rather than honored — the server derives them again either way.
 - Training and deployment use the shared capacity broker. It evaluates priority first, then rotates fairly across users at equal priority while preserving FIFO inside each user's own requests. This prevents a high-volume user from starving others; do not describe the queue as strict global FIFO.`,
             hyperparameters: `# Hyperparameter Guide
 
-## Key Hyperparameters
-
-### Learning Rate
-- Default: 2e-4 (0.0002)
-- Range: 1e-5 to 5e-4
-- Higher = faster learning but risk of instability
-- Lower = more stable but slower convergence
-- Tip: Start with 2e-4 for LoRA, 2e-5 for full fine-tune
-
-### Batch Size (per_device_train_batch_size)
-- Default: 4
-- Range: 1-32 (limited by GPU VRAM)
-- Larger = smoother gradients, more stable training
-- Smaller = faster per-step but noisier
-- Use gradient_accumulation_steps to simulate larger batches
-
-### Epochs (num_train_epochs)
-- Default: 3
-- Range: 1-10
-- More epochs = more passes through data
-- Watch for overfitting: if eval loss starts increasing, you've trained too long
-- For small datasets (<1000 rows): 3-5 epochs
-- For large datasets (>10000 rows): 1-3 epochs
-
-### LoRA Rank (lora_r)
-- Default: 16
-- Range: 4-256
-- Higher = more trainable parameters, better quality, but slower
-- 8-16 is sufficient for most tasks
-- 32-64 for complex tasks requiring more model capacity
-- 128+ for near-full-fine-tune quality
-
-### LoRA Alpha (lora_alpha)
-- Default: 32 (typically 2x lora_rank)
-- Controls the scaling of LoRA updates
-- Rule of thumb: set to 2x your lora_rank
-
-### Max Sequence Length
-- Default: 2048
-- Range: 512-8192
-- Must cover your longest training example
-- Longer = more VRAM usage
-- Set to slightly above your longest example
-
-### LR Scheduler
-- cosine (default) — gradually decreases, good for most tasks
-- linear — constant decrease, predictable
-- constant_with_warmup — stays flat after warmup, good for short training
-
-### Warmup Ratio
-- Default: 0.03 (3% of total steps)
-- Prevents early instability by slowly ramping up learning rate
-
-## Recommended Defaults by Use Case
-| Parameter | Quick Test | Standard | High Quality |
-|-----------|-----------|----------|--------------|
-| Adapter | LoRA | LoRA | Full |
-| Learning Rate | 3e-4 | 2e-4 | 2e-5 |
-| Epochs | 1 | 3 | 5 |
-| Batch Size | 4 | 4 | 8 |
-| LoRA Rank | 8 | 16 | 64 |
-| Scheduler | cosine | cosine | cosine |`,
+Offer only the settings below. Ranges and the context lengths, precisions and optimizers a model offers come from get_training_capabilities and get_managed_training_options.
+
+### Learning rate (learning_rate)
+How big a step the model takes each time it learns. Start with 2e-4 for LoRA and QLoRA and 1e-5 to 2e-5 for full fine-tuning. Lower it if the loss jumps around.
+
+### Epochs (epochs) and max steps (max_steps)
+How many times the model reads the whole dataset. One to three is usual: small datasets (under 1,000 rows) 3 to 5, large datasets 1 to 3. max_steps is an optional cap; leave it empty to train every epoch.
+
+### Context length (max_length)
+The longest text read in one go, in tokens: 2K, 4K, 8K, 16K, 32K, 64K or 128K where the model offers it. Pick one that fits the longest examples. Longer samples lose their oldest turns, never the answer.
+
+### Precision (precision)
+bf16 is accurate and fast and right for most runs. fp8 can be faster on large models and is offered only where it was tested.
+
+### Optimizer state (optim)
+adamw_torch_fused keeps 16-bit state and is the most accurate. adamw_8bit uses less memory, which helps large full fine-tunes, and is offered only where it was tested.
+
+### LoRA rank (lora_rank) and alpha (lora_alpha)
+Rank is how much the adapter can learn (8 to 64; 16 is a good start). Alpha is usually twice the rank.
+
+### Warmup ratio, weight decay and schedule
+warmup_ratio (default 0.03) eases the first steps in. weight_decay (around 0.01) helps the model generalize. lr_scheduler_type defaults to cosine.
+
+### Validation rows (split_dataset_samples) and early stopping (early_stopping_patience)
+Rows held out and never trained on, used to measure real progress and keep the best checkpoint. Allowed: 100 rows (or 5% when that is fewer) up to 40% of the rows; default 5% capped at 1,000. Early stopping ends the run after that many evaluations without improvement (default 3).`,
             monitoring: `# Training Monitoring Guide
 
-## Key Metrics to Watch
-
-### Training Loss
-- Should decrease steadily during training
-- Sharp drops early are normal (learning basic patterns)
-- Gradual decrease later shows fine-grained learning
-- If loss plateaus: try higher learning rate or more LoRA rank
-- If loss spikes: learning rate is too high, reduce it
-
-### Eval Loss (if eval dataset provided)
-- Should track training loss but may be slightly higher
-- If eval loss increases while training loss decreases = OVERFITTING
-- Early sign of overfitting: gap between train and eval loss growing
-- Action: Stop training and use the last checkpoint before divergence
-
-### Learning Rate
-- Should follow your chosen schedule (cosine, linear, etc.)
-- Warmup period: LR starts low and ramps up
-- Main phase: LR follows the schedule downward
-
-## Monitoring Tools
-1. get_training_status — Progress %, current step, elapsed time, ETA
-2. get_training_metrics — Semantic metric summaries plus bounded curve data on request
-3. get_training_logs — Raw training output for debugging
-4. get_training_checkpoints — Saved model snapshots at intervals
-
-## When to Stop Early
-- Loss has plateaued for many steps (no improvement)
-- Eval loss is increasing (overfitting)
-- You've reached satisfactory quality and want to save GPU cost
-- The model is producing good outputs in eval samples
-
-## Checkpoints
-- Saved automatically at regular intervals during training
-- Each checkpoint is a complete model snapshot you can use
-- If training is interrupted, resume from the last checkpoint
-- Best practice: compare outputs from different checkpoints to pick the best one`,
-            cost_optimization: `# Cost Optimization Guide
-
-## Per-Second Billing
-Run BiOS charges per-SECOND of GPU usage, not per hour. This means:
-- You only pay for actual compute time
-- Stopping a job immediately stops billing
-- No wasted time rounding up to the next hour
-
-## Cost Estimation
-Before launching a job, estimate cost:
-1. Call get_recommended_gpu for your model — it includes a cost estimate
-2. Rough formula: (dataset_rows / batch_size) × epochs × seconds_per_step × gpu_price_per_second
-
-## Money-Saving Strategies
-
-### 1. Start Small
-- Train for 1 epoch first to validate your setup
-- Check if the loss is decreasing and outputs look reasonable
-- Only then train for the full 3-5 epochs
-
-### 2. Use LoRA
-- LoRA is 5-10x cheaper than full fine-tune
-- Quality is comparable for most tasks
-- QLoRA is even cheaper (uses 4-bit quantization)
-
-### 3. Optimize Batch Size
-- Larger batch sizes = fewer total steps = less time
-- Use gradient accumulation to simulate large batches on limited VRAM
-
-### 4. Choose the Right GPU
-- Don't pick H100 for a 7B LoRA job — A100 is plenty and cheaper
-- Use get_recommended_gpu to find the cost-optimal choice
-
-### 5. Monitor and Stop Early
-- Read the summaries from get_training_metrics, then request a bounded series for any curve that needs inspection
-- Treat a plateau as evidence to review alongside eval metrics and the configured run bound, not an automatic stop verdict
-- Check wallet balance with get_wallet_balance before long jobs
-
-### 6. Check Your Balance First
-- Call get_wallet_balance before creating a job
-- Ensure you have enough credits for the estimated training time
-- Set up auto top-up to avoid interruptions mid-training`,
+## Tools
+1. get_training_status -- where the job is: queued, getting ready, downloading the model, preparing data, training step N of M, saving, finished.
+2. get_training_metrics -- training metrics only: loss, eval loss, gradient norm, token accuracy, perplexity, learning rate, epoch and tokens trained. Read the summaries first and ask for a bounded series when you need the curve.
+3. get_training_checkpoints -- the kept checkpoints: the best (lowest validation loss) and the last.
+
+Training logs and machine metrics (memory, MFU, throughput) are not available to customers.
+
+## Reading the curves
+- Training loss should fall. A sharp early drop is normal.
+- Eval loss should follow it. If eval loss rises while training loss falls the model is starting to memorize; early stopping ends the run and the best checkpoint is kept.
+- The learning rate follows the schedule: warmup, then the decay.`,
+            cost_optimization: `# Cost Guide
+
+## Per-token pricing
+Training is charged for the exact tokens it trained, at the model's per-token price for the adapter. Waiting in the queue, setup and machine time are never charged. preflight_training_job returns the estimate; the charge after the run is the exact count.
+
+## Spending less
+- Train 1 epoch first to check the setup, then the full run.
+- LoRA and QLoRA cost less per token than full fine-tuning and are close in quality for most tasks.
+- Early stopping (on by default when validation rows are held out) ends a run once it stops improving.
+- max_steps caps a run when you only want part of the data.
+- Check get_wallet_balance before long runs.`,
             capacity_errors: `# Standard GPU Rejection Errors
 
 Training and inference speak ONE GPU rejection contract: one body shape, and a
@@ -2559,6 +2459,21 @@ create (1-5 choices), and the queue itself stays opt-in.`,
         return json(stripBuildIdentity(data));
     });
     /* ══════════════════════════════════════════════════════════════════════════ */
+    /*  TOOL: get_managed_training_options                                       */
+    /* ══════════════════════════════════════════════════════════════════════════ */
+    server.tool("get_managed_training_options", "Managed training only (get_training_capabilities lists managed_training enabled): what this model, method and adapter can be trained with. Returns options, each a precision (bf16 or fp8) and optimizer state (adamw_torch_fused = 16-bit, adamw_8bit = 8-bit) with the context lengths (2048 ... 131072) a certified setup covers. Offer the customer only these; every option listed is accepted by preflight_training_job and create_training_job. Empty options means the model is not trainable with that method and adapter yet. No hardware is named and none should be described to the customer.", {
+        model_id: z.string().describe("Model id, e.g. Qwen/Qwen3.5-9B."),
+        method: z.enum(TRAINING_METHODS).optional().describe("Training method: sft (default), or pt/cpt for continued pre-training."),
+        adapter: z.enum(TRAINING_ADAPTERS).optional().describe("lora (default), qlora or full."),
+    }, async ({ model_id, method, adapter }) => {
+        const q = new URLSearchParams({
+            model_id,
+            training_method: method === "cpt" ? "pt" : method || "sft",
+            train_type: adapter || "lora",
+        });
+        return json(await client.api(`/api/training/managed-options?${q}`));
+    });
+    /* ══════════════════════════════════════════════════════════════════════════ */
     /*  TOOL: preflight_training_job                                            */
     /* ══════════════════════════════════════════════════════════════════════════ */
     /**
@@ -2602,7 +2517,7 @@ create (1-5 choices), and the queue itself stays opt-in.`,
             ...(params.eval_dataset_ids ? { eval_dataset_ids: await Promise.all(params.eval_dataset_ids.map((ref) => resolveDatasetRef(ref, "eval_dataset_ids"))) } : {}),
         };
     }
-    server.tool("preflight_training_job", "Validate and canonicalize a proposed training job without creating a job, charging the wallet, entering the queue, or allocating a GPU. Returns dataset compatibility, model facts, authoritative GPU choices/prices, queue eligibility, alternatives, warnings, and a request hash.", {
+    server.tool("preflight_training_job", "Validate and canonicalize a proposed training job without creating a job or charging the wallet. You choose the model, adapter, datasets and training settings; the platform chooses the machines, batch and memory settings from tested setups. Returns dataset compatibility, the per-token cost estimate, the validation rows it will hold out (and their allowed range), warnings (FIELD_IGNORED for anything the platform sets) and a request hash.", {
         model: z.string().describe("Base model id from the Run BiOS catalog (e.g., 'meta-llama/Llama-3.1-8B-Instruct'). Must be hosted on Run BiOS — pick from list_models/search_models. Training always starts from a catalog base model; start_from (where enabled) adds earlier LoRA versions of that same base on top of it, and training from any other fine-tuned model is not supported."),
         model_revision: z.string().max(256).optional().describe("Requested model branch, tag, or commit. Copy the exact 40-hex value returned in canonical_request into create."),
         dataset_id: z.string().optional().describe("Dataset id from list_datasets. An exact, unique dataset name is also accepted and resolved to its id."),
@@ -2610,25 +2525,7 @@ create (1-5 choices), and the queue itself stays opt-in.`,
         eval_dataset_ids: z.array(z.string()).min(1).max(64).optional().describe("Separate evaluation datasets, composed sequentially. Mutually exclusive with eval_split_ratio."),
         method: z.enum(TRAINING_METHODS),
         adapter: z.enum(TRAINING_ADAPTERS).optional(),
-        gpu_type: z.string().optional(),
-        gpu_count: z.number().int().min(1).max(8).optional(),
-        gpu_priorities: z
-            .array(z.object({
-            gpu_type: z.string(), gpu_count: z.number().int().min(1).max(8),
-            provider: z.string().min(1).max(30).optional(), region: z.string().min(1).max(64).optional(),
-            tier: z.literal("secure").optional(),
-        }))
-            .min(1)
-            .max(5)
-            .optional()
-            .describe("Ranked GPU placement choices. Copy these unchanged from preflight; queueing accepts one exact placement through five ranked choices, and entry one must match gpu_type/gpu_count."),
-        queue_if_unavailable: z.boolean().optional().describe("Explicit consent to wait in the capacity queue when none of the ranked GPU choices are free; accepts 1 to 5 gpu_priorities because some training configurations have one valid shape."),
-        queue_deadline: z.string().min(1).optional().describe("Optional RFC 3339 deadline from one minute through seven days in the future; requires queue_if_unavailable=true."),
-        max_price_hour_cents: priceCapSchema(true),
-        storage_gb: z.number().int().min(1).max(10000).optional(),
-        num_checkpoints: z.number().int().min(1).max(100).optional(),
         integration_id: z.string().optional(),
-        network_volume_id: z.string().optional(),
         dataset_mixing: z.enum(["shuffle", "sequential", "interleave"]).optional(),
         mixing: datasetMixingSchema.optional().describe("Composition plan. Dataset IDs define source order and weight positions; default seed is 42. The source pins, plan and checksum are retained for metadata-only resume."),
         start_from: startFromSchema.optional(),
@@ -2649,7 +2546,7 @@ create (1-5 choices), and the queue itself stays opt-in.`,
     // server-side (403 TRAINING_COMING_SOON before any billing or booking) as the
     // authority. At launch the flag opens and the registration returns verbatim.
     if (!launchGates.training) {
-        server.tool("create_training_job", "Create a training job using the same BOOK-BEFORE-REVEAL contract as the web UI. Call preflight_training_job first with the complete model/method/adapter/dataset/config request, then choose one returned GPU configuration: GPU is last because its minimum depends on every earlier choice. The call does not reveal a run as started until a real pod is secured; status is booked (secured) or securing (poll get_training_status). A booking-time miss returns CAPACITY_UNAVAILABLE with fresh qualifying available_gpus and no job/no charge: choose one and retry with the same setup. The rejected GPU type is never recommended back. Queue consent is valid only when available_gpus is empty; waiting is unbilled and expires automatically. Reuse one idempotency key after timeouts.", {
+        server.tool("create_training_job", "Create a training job with the same request preflight_training_job validated. The platform places it on tested machines; when none is free it waits in the queue (first come first served, unbilled, expires after seven days), starts automatically and emails the user when it starts. It is charged for the exact tokens it trained. Report progress from get_training_status and training metrics from get_training_metrics; cancel any time with stop_training_job. Reuse one idempotency key after timeouts.", {
             model: z.string().describe("Base model id from the Run BiOS catalog (e.g., 'meta-llama/Llama-3.1-8B-Instruct'). Must be hosted on Run BiOS — pick from list_models/search_models. Training always starts from a catalog base model; start_from (where enabled) adds earlier LoRA versions of that same base on top of it, and training from any other fine-tuned model is not supported."),
             model_revision: z.string().max(256).optional().describe("Exact model_revision from preflight canonical_request; a branch or tag is accepted but resolved again before any paid mutation."),
             idempotency_key: z
@@ -2664,25 +2561,7 @@ create (1-5 choices), and the queue itself stays opt-in.`,
             eval_dataset_ids: z.array(z.string()).min(1).max(64).optional().describe("Separate evaluation datasets, composed sequentially. Mutually exclusive with eval_split_ratio."),
             method: z.enum(TRAINING_METHODS).describe("Training method: sft, or pt/cpt for continued pre-training."),
             adapter: z.enum(TRAINING_ADAPTERS).optional().describe("Any adapter supported by the Run BiOS contract."),
-            gpu_type: z.string().optional().describe("GPU type returned by preflight_training_job after the complete training configuration is known. Do not guess or use a pre-configuration recommendation."),
-            gpu_count: z.number().int().min(1).max(8).optional().describe("Number of GPUs for the primary choice."),
-            gpu_priorities: z
-                .array(z.object({
-                gpu_type: z.string(), gpu_count: z.number().int().min(1).max(8),
-                provider: z.string().min(1).max(30).optional(), region: z.string().min(1).max(64).optional(),
-                tier: z.literal("secure").optional(),
-            }))
-                .min(1)
-                .max(5)
-                .optional()
-                .describe("Ranked GPU placement choices. Copy these unchanged from preflight; queueing accepts one exact placement through five ranked choices, and entry one must match gpu_type/gpu_count."),
-            queue_if_unavailable: z.boolean().optional().describe("Explicit consent to wait in the capacity queue when none of the ranked GPU choices are free; accepts 1 to 5 gpu_priorities because some training configurations have one valid shape."),
-            queue_deadline: z.string().min(1).optional().describe("Optional RFC 3339 deadline from one minute through seven days in the future; requires queue_if_unavailable=true."),
-            max_price_hour_cents: priceCapSchema(true),
-            storage_gb: z.number().int().min(1).max(10000).optional(),
-            num_checkpoints: z.number().int().min(1).max(100).optional(),
             integration_id: z.string().optional(),
-            network_volume_id: z.string().optional(),
             dataset_mixing: z.enum(["shuffle", "sequential", "interleave"]).optional(),
             mixing: datasetMixingSchema.optional().describe("Composition plan. Dataset IDs define source order and weight positions; default seed is 42. The source pins, plan and checksum are retained for metadata-only resume."),
             start_from: startFromSchema.optional(),
@@ -2766,7 +2645,7 @@ create (1-5 choices), and the queue itself stays opt-in.`,
     /* ══════════════════════════════════════════════════════════════════════════ */
     /*  TOOL: get_training_logs                                                 */
     /* ══════════════════════════════════════════════════════════════════════════ */
-    server.tool("get_training_logs", "Get structured recent training log entries (level, message, timestamp). Results are newest first and bounded by tail.", {
+    server.tool("get_training_logs", "Get structured recent training log entries (level, message, timestamp). Results are newest first and bounded by tail. Not available when managed_training is enabled (the platform runs the machines): use get_training_status for progress and get_training_metrics for loss, eval loss, gradient norm and accuracy.", {
         job_id: z.string().describe("Training job ID"),
         tail: z
             .number()
@@ -2777,9 +2656,21 @@ create (1-5 choices), and the queue itself stays opt-in.`,
             .describe("Number of most recent log entries to return (default: 200, max: 1000)"),
     }, async ({ job_id, tail }) => {
         validateId(job_id, "job_id");
-        const data = await client.api(`/api/training/jobs/${job_id}/logs`, {
-            params: { tail: tail?.toString() },
-        });
+        let data;
+        try {
+            data = await client.api(`/api/training/jobs/${job_id}/logs`, {
+                params: { tail: tail?.toString() },
+            });
+        }
+        catch (error) {
+            if (/\bLOGS_NOT_AVAILABLE\b/.test(error instanceof Error ? error.message : String(error))) {
+                return json({
+                    logs: [],
+                    note: "Training logs are not available under managed training. Use get_training_status for progress and get_training_metrics for training metrics.",
+                });
+            }
+            throw error;
+        }
         // Log lines are written by the training engine, so a boot/pull line can
         // quote the image reference it started from. Redact by content: the
         // customer keeps every line, minus any build identity inside it.
@@ -3428,6 +3319,11 @@ create (1-5 choices), and the queue itself stays opt-in.`,
         method: "POST",
         body: {},
     })));
+    server.tool("loop_list_live_deployments", "For a pipeline whose live version's deployment was DELETED (live_deployment.status deleted on loop_get_pipeline): the deployments of this workspace that serve exactly the live version's weights, with their status, and the live version itself (live.training_job_id and live.checkpoint_id, what the user deploys again from Deployments). Nothing has to be trained again: the weights are kept. 409 NO_LIVE_VERSION when the pipeline has none. Read-only.", { pipeline_id: z.string() }, async ({ pipeline_id }) => json(await client.api(`/api/loop/pipelines/${encodeURIComponent(pipeline_id)}/live/deployments`)));
+    server.tool("loop_use_live_deployment", "Answer the pipeline's model name from this deployment of the live version's weights (one loop_list_live_deployments named), after the pipeline's own deployment was deleted. Nothing is trained again and the version number does not change; the deployment bills the user by the hour, like any deployment, so say so. Refused while the pipeline's own deployment still exists (409 LIVE_DEPLOYMENT_PRESENT: the user starts it again in Deployments instead), for other weights (422 DEPLOYMENT_WEIGHTS_DIFFER) and for a deployment that is not running (409 DEPLOYMENT_NOT_RUNNING). A later rollback stops it.", { pipeline_id: z.string(), deployment_id: z.string() }, async ({ pipeline_id, deployment_id }) => json(await client.api(`/api/loop/pipelines/${encodeURIComponent(pipeline_id)}/live/deployment`, {
+        method: "POST",
+        body: { deployment_id },
+    })));
     server.tool("loop_import_into_pipeline", "loop_import_rows with every row given this pipeline's ID (own_tag), so the file becomes this pipeline's samples. source defaults to the pipeline ID. default_feedback 'good' records every answered row that brought no feedback of its own as a good example to learn from — use it only when the user says the file's answers are good; without it such rows wait for review. The result, the retry token (import_id) and the 5000-row limit are loop_import_rows' own.", {
         pipeline_id: z.string(),
         rows: z.array(z.record(z.string(), z.any())).describe("The rows, already parsed, at most 5000, each in the shape it already has"),