Skip to main content
Glama

start grpo run

start_grpo_run

Start a budget-bounded GRPO training run that improves a fine-tunable model against a calibrated judge, using logged traffic or candidate queue to produce a trained adapter.

Instructions

Start an online-RL (GRPO) training run that improves a fine-tunable base model against a calibrated judge as the reward, with hard reward and GPU-hour budgets — use it to turn logged traffic or the candidate queue into a trained adapter. POST /v1/grpo/runs (API-key scope: platform:write). SPENDS MONEY: this starts billable work on the workspace wallet. Returns: 201 with { trigger_run_id: string } — the orchestration handle for the run (the GrpoRun id shows up in GET /v1/grpo/runs once registered). Notes: SPENDS MONEY: the whole commitment (rewardBudgetUsd + GPU hours at the frozen marked-up rate, or a conservative ceiling for autoProvision) is atomically HELD on the wallet at start; 402 when the wallet can't hold it; 400 'No wallet for this workspace' when there is no payment method. Body keys are camelCase only (except environment.proxy_base_url / max_steps and verifier[].timeout_sec, which are snake_case); unknown keys pass through. Zod validation failure returns 400 { error: 'Invalid body: ' } (flat error shape). Rate limited to 20 starts/min per workspace (429). Feature-flag gated (fineTuning flag off → 404). Requires OWNER/ADMIN (403). Other 400 refusals: unaligned/wrong-unit/drift-flagged judge, iterated-RL round gate (fresh grades needed on a self-trained policy), model not fine-tunable, promptCount < 10, not enough logged prompts or queued candidates, autoAdopt alias missing, no GPU price set, orchestration not configured.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
modelYesThe policy model to train. Must be on the platform's fine-tunable base-model list, otherwise 400.
qloraNoQLoRA 4-bit training. Default true.
rewardYesReward spec (camelCase keys). Either { mode: "single", criterionId: string } or { mode: "compositional", criterionIds: string[] (min 1), assertions?: object[] }. Each assertion is { type: "json_valid"|"json_schema"|"regex_match"|"contains"|"not_contains"|"max_length"|"min_length"|"completed"|"tool_called"|"no_tool_call", value?: string } or an exec assertion { type: "exec", command: string, timeoutSec?: integer (1..120) } — exec assertions are only allowed when `environment` is set (agentic/trace-unit rewards). Every criterion must exist in the workspace and be calibrated; a non-agentic run requires request-unit criteria, an agentic run (with `environment`) requires trace-unit criteria.
paramsBNoParameter count (billions) override for models whose name doesn't carry it. Must be > 0; capped at 1000.
useVllmNoColocated vLLM rollouts (much faster steps). Forced true when `environment` is set.
maxStepsNoTraining steps. Default 100, clamped 1..5000.
autoAdoptNoOpt-in auto-deploy on an 'improved' bake-off verdict: { aliasName: string (1..120, must already exist in the workspace or the start is refused), canaryPercent?: integer 1..50, gpuType: string, region: string, templateFlavor?: string }. Deploys to a dedicated endpoint, canaries on the alias, and the online gate earns the promote. Inconclusive/regressed rounds never deploy.
groupSizeNoRollouts sampled per prompt. Default 8, clamped 2..16.
promptTagNoDraw training prompts only from logged requests carrying this tag. Omit to sample the whole workspace's successful logged traffic.
environmentNoAgentic mode — run episodes inside the tool environment: { proxy_base_url: string (snake_case, required), max_steps?: integer, simulate?: boolean }. Setting this forces useVllm=true and requires trace-unit reward criteria.
platformGpuNoBill a platform-provisioned GPU: { gpuType: string, region: string, gpuCount?: integer (clamped 1..8) }. Rate + markup are frozen at start. Omit for bring-your-own compute (no GPU billing). 400 if no price is set for that GPU/region.
promptCountYesNumber of prompts to train on. Minimum 10 (400 below that); clamped to 1..10000 at scheduling. A ~20% holdout (min 3) is carved off on top, and the workspace must have promptCount+holdout matching prompts logged or the run is refused with the real counts.
tasksInlineNoUp to 10000 task objects for agentic runs: { goal: any[] (min 1), image?: string (<=500 chars), recorded?: any[], verifier?: [ { command: string (1..4000 chars), timeout_sec?: integer 1..120 } ] }.
holdoutCountNoHoldout size override (rounded, clamped 1..2000). Use 50+ for a real bake-off claim. Default max(3, ceil(promptCount*0.2)).
autoProvisionNoLet the platform provision an auto-sized GPU box. 400 if provisioning isn't configured; holds a conservative GPU commitment (highest active rate x 8 GPUs x gpuHourBudget) on the wallet.
gpuHourBudgetYesHard cap on GPU hours. Must be > 0. For platform-provisioned GPUs the hours x frozen marked-up rate are held on the wallet at start.
rewardBudgetUsdYesHard cap (USD) on judge/reward spend. Must be > 0. Held on the wallet at start.
allowSideEffectsNoAgentic runs only: permit calls to tools not declared read-only. Default false.
useCandidateQueueNoTrain on the workspace's GRPO candidate queue (the self-improvement give-up set) for the single reward criterion instead of a tag sample. Only effective with reward.mode=single.
curriculumMixRatioNoCandidate-queue runs: fraction of the training slice drawn from regular successful traffic. Clamped 0..0.9.
maxCompletionTokensNoPer-rollout generated-token budget, clamped 256..32768. Defaults: 8192 agentic, 1024 single-turn.
vllmGpuMemoryUtilizationNoClamped 0.05..0.9.
Install Server

TDQS

A4.5/5.0
Behavior5/5

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

The description goes far beyond the sparse annotations by explicitly warning that this tool SPENDS MONEY, holds the commitment on the wallet, requires OWNER/ADMIN, is rate limited, is feature-flag gated, and returns specific failure codes (402, 403, 404, 429, 400) with their causes. This gives an agent a strong model of side effects and failure behavior before invoking it.

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

Conciseness5/5

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

The description is long, but every sentence carries load-bearing operational information for a high-stakes, 22-parameter, money-spending tool. It front-loads purpose, endpoint, spending warning, and return value, then groups notes logically by billing, validation, auth, rate limits, and refusal reasons.

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 tool with no output schema but many non-obvious failure modes, the description supplies the return shape (201 with trigger_run_id), wallet implications, auth requirements, rate limits, feature gating, and the full set of 400 refusal reasons. This is comprehensive enough for an agent to call the tool confidently and diagnose failures.

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

Parameters3/5

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

The input schema covers 100% of parameters with rich descriptions, so the baseline is 3. The description adds useful body-level conventions (camelCase, selected snake_case exceptions, validation error shape) but does not deepen individual parameter semantics beyond what the schema already provides.

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?

It states a specific verb ('start'), a precise resource ('online-RL (GRPO) training run'), and the mechanism ('improves a fine-tunable base model against a calibrated judge as reward'), with clear boundaries (hard reward and GPU-hour budgets). The REST endpoint and the explicit goal of turning logged traffic or the candidate queue into a trained adapter make it readily distinguishable from siblings like create_fine_tuning_job or stop_grpo_run.

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?

The description gives a clear when-to-use signal ('use it to turn logged traffic or the candidate queue into a trained adapter') and notes prerequisites such as a fine-tunable model and calibrated judge. It does not explicitly contrast with alternative tools or state when not to use it, so it stops short of a full 5.

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