> ## Documentation Index
> Fetch the complete documentation index at: https://docs.platform.toloka.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Generation node

> Expert and synthetic labeling settings, fields, quality control, onboarding, and pricing.

The Generation node turns raw items into labeled data. It is one of the [node types a pipeline can contain](https://docs.platform.toloka.ai/docs/data/reference/nodes.md). Labeled items are checked against the quality criteria you define, and the node returns the labels together with the verdicts. The review path under [Quality control](#quality-control) determines which items are checked and by whom. The agent sets each option as it builds the node, and every option can also be edited by hand on the node's cards until deploy. You alone set the review model, under **Quality Assurance** (see the [shared quality model](https://docs.platform.toloka.ai/docs/data/concepts/quality-control.md)), and onboarding's on/off switch, on the node's **Training** card. A single run feeds the node at most 10,000 items — a platform-wide per-run cap; [Label a large dataset in batches](https://docs.platform.toloka.ai/docs/data/guides/label-at-volume.md) covers larger workloads.

**Expert labelers produce labels by default. On request, an LLM produces them instead (synthetic labeling)**. [Who does the labeling](#who-does-the-labeling) covers that choice. [Input and output fields](#input-and-output-fields), [instructions and the labeling interface](#instructions-and-the-labeling-interface), [quality criteria](#quality-criteria), and [quality control](#quality-control) apply either way. The [expert labeling settings](#expert-labeling-settings) at the end apply only when experts do the labeling.

## Who does the labeling

See [Label with an LLM instead of experts](https://docs.platform.toloka.ai/docs/data/guides/synthetic-labeling.md).

| Setting | Values | Default | Notes |
| - | - | - | - |
| Labeler | Expert labelers or an LLM (synthetic labeling) | Expert labelers | Synthetic labeling is unavailable for data-collection nodes |
| Generation model | GPT-5.6 Terra, GPT-5.6 Luna, GPT-5.6 Sol, Claude Sonnet 5, Claude Opus 5, Claude Fable 5, Gemini 3.1 Pro Preview, Gemini 3.7 Flash | GPT-5.6 Terra | Synthetic labeling only. A node pinned to a retired model keeps it, disabled and badged **Unavailable** |
| Reasoning effort | Low, Medium, High | Medium | The GPT models only; rejected on the Gemini and Claude models. In the editor the effort carries over to any model that supports it, and clears on one that does not; asking the agent for an effort a model cannot take is refused |
| Extra model guidance | Free text | Empty | Sent to the model on top of the task instructions |
| Generation budget per attempt | From \$0.01 to the maximum shown for the selected model and effort | The editor prefills the maximum; the agent asks you to choose | Required for synthetic labeling. Changing the model or effort can change the allowed range |

Under synthetic labeling, the audience, pricing, per-expert cap, onboarding, and audience reuse below do not apply, and the Training card disappears from the node. Switching to synthetic forces the review path to LLM review. Asking the agent to switch also clears audience reuse; flipping the card yourself only hides the picker, so a reuse setting left behind blocks the deploy with *Sharing workforce with a previous version is not available for synthetic data generation*. Switching back differs by surface too: the card restores the audience, pricing, per-expert cap, and review path you had, while an agent switch leaves them to be set again. Onboarding settings survive either way.

Expert labeling is billed at the per-task price you set plus the platform commission (see [Pricing](#pricing)). Synthetic generation charges input, cached-input, and output tokens at the chosen model's rates. These token charges share a per-item cap of twice **Generation budget per attempt**, covering the first attempt and one retry. LLM review is billed separately. The model and reasoning effort determine token estimates; output repetition counts do not increase those estimates. See [Set the generation budget](https://docs.platform.toloka.ai/docs/data/guides/synthetic-labeling.md#step-3--set-the-generation-budget).

## Input and output fields

The node reads the input fields you declare and returns one output field for each label the labeler produces. Each follows the shared [field model](https://docs.platform.toloka.ai/docs/data/concepts/fields-and-data.md) for whether it is required or optional and whether it repeats. Quality control adds the per-criterion verdict fields and a review metadata field, shaped as the [shared quality model](https://docs.platform.toloka.ai/docs/data/concepts/quality-control.md) describes. The agent defines the fields from your task.

Under synthetic labeling the node adds one more output field, named `<node name>_evaluation_summary`. It holds the item's overall review verdict, which is always `pass` or `fail` — a narrower set than a per-criterion verdict, whose other values appear only in the counts — plus the number of generation attempts and a count of the per-criterion verdicts from the final attempt. An item that every attempt failed to get past LLM review still finishes, and this field is what marks it, so nothing is lost and you can tell the two outcomes apart. To send those items down a branch of their own, give a [Match node](https://docs.platform.toloka.ai/docs/data/reference/nodes/match.md) this field and test the location `$.overall_verdict` against `fail`.

Deployment enforces the field contract:

* At least one input field and at least one output field.
* Every field carries a description and one of the platform's data types.
* A repeating field's maximum count is a whole number from 1 to 50, and its location marks the repeating position exactly once. A field that does not repeat must not mark one.
* When the node has more than one field, every output field links to at least one other field, and links may point only to the node's own fields.
* A video output states a minimum and a maximum duration, with the minimum not above the maximum. The maximum also sets the rate of the video-review charge (see [Quality control](#quality-control)).
* A choice output offers at least two options. Option names are non-empty, and both the names and the stored keys (lowercase words joined by underscores) are unique.

### Who labeled and reviewed the item

With human experts, the node also returns a field named after the node with `_annotator_id` at the end, for example `translate_text_annotator_id`. It holds the ID of the expert whose answer was accepted. When an answer is sent back and another expert redoes the item, the field names the expert of the accepted answer, not the earlier ones.

When human review is on, the node returns one more field, ending in `_qa_annotator_id`. It holds the ID of the expert who made the last human review decision on the item.

* Both fields are optional. They are missing on an item that was canceled at this node before an answer was accepted, on items that finished before the fields existed, and, for the review field, on items that human review did not sample. An item accepted without review, on a run cancel or at the 14-day node timeout, ends as canceled and has its expert field. The field is in the dataset, and when the End node returns it, the run export and the API show it in `partialOutput`.
* Synthetic labeling returns neither field, because no expert labels or reviews the item.
* The fields are written to your dataset next to the answers. To use them inside the pipeline, add them as inputs of the next [Code node](https://docs.platform.toloka.ai/docs/data/reference/nodes.md#code). To get them in the run export, add them to the outputs of the [End node](https://docs.platform.toloka.ai/docs/data/reference/nodes/start-and-end.md). Both cards add them as optional.

## Instructions and the labeling interface

The labeler follows a written instruction document and works in a custom labeling interface where fields are shown and controls are filled in. A short display name appears alongside the task (the node's **Display name** card). The agent builds both the instructions and the interface. Under synthetic labeling the same instructions guide the model, and you can add model-only guidance on top (see [Who does the labeling](#who-does-the-labeling)).

Deployment rejects empty instructions and sets no instruction-specific length limit. The only ceiling is the 150,000-character cap on any single node setting. The display name is required and at most 64 characters. Deployment rejects a missing or longer name. None of these carry a direct cost.

## Quality criteria

Every output field on this node must be covered by at least one quality criterion. Each criterion can also carry an optional instruction of up to 5,000 characters, handed only to the LLM reviewer and never shown to experts. What a criterion is and the floor it must clear to deploy are covered in the [shared quality model](https://docs.platform.toloka.ai/docs/data/concepts/quality-control.md). The setting under [Quality control](#quality-control) determines which reviewer applies the criteria. When LLM review is on, each criterion adds one review check per item, or more when the checked field builds on repeating fields. Human review is priced per review, and an item can be reviewed more than once. Criteria do not affect that price.

## Quality control

The [shared quality model](https://docs.platform.toloka.ai/docs/data/concepts/quality-control.md) describes how labeled items are reviewed against the criteria. This section covers the settings and prices specific to this node. You set the review path, human-review sample, and review time by asking the agent or by hand under **Quality Assurance**.

| Setting | Values | Default | Notes |
| - | - | - | - |
| Review path | LLM review, human review, or both | LLM review | Forced to LLM review under synthetic labeling |
| Review model | GPT-5.6 Terra, GPT-5.6 Luna, Claude Sonnet 4.6 | GPT-5.6 Terra | Pick in **Quality Assurance**. GPT-5.4, GPT-5.4 Mini, GPT-5, and GPT-5 Mini remain visible only on nodes already using them |
| Human-review sample | 10% to 100% of items | 100% (human review only), 30% (both) | LLM review always covers every item |
| Review time per item | At least 30 seconds, or 3 seconds per quality criterion when greater | — | Required whenever human review is on. The node will not deploy without it |

A criterion's verdict field is required when the criterion targets a required output and optional when it targets an optional output.

Each charge is priced on its own basis, and for each the estimate assumes a per-item count. A human-reviewed item can be reviewed more than once when it is sent back for rework, which is why its expected and maximum counts differ:

| Charge | Priced per | Expected | Maximum |
| - | - | - | - |
| LLM review | Per check. A more capable review model costs more per check | One check per item per criterion, times the repetition maxima of repeating fields in the checked field's chain | Same as expected |
| Human review | Per review, from the per-task price you set scaled by review time divided by labeling time, plus a 10% premium | 2 reviews per sampled item (human review only), or 1.2 with both paths on | 3 reviews per item |
| Video tool | Per item whose LLM review watches a video field, shown as **Video tool** in the cost breakdown. Its rate grows with the total maximum duration of the videos watched | One charge per item. A repeating field raises the rate per charge while the number of charges stays the same | Same as expected |

Human review stops at a cap that is set when the run deploys: 3 reviews for each item of the run, the Maximum of the human review charge in the run's cost estimate. The cap counts every item of the run, not only the items the estimate expects at this node. A branch behind a [Match node](https://docs.platform.toloka.ai/docs/data/reference/nodes/match.md) that receives more than its even share of items still gets human review.

## Expert labeling settings

These settings apply only when expert labelers do the labeling. Under synthetic labeling they do not apply (see [Who does the labeling](#who-does-the-labeling)).

### Audience

The audience filters which experts are eligible to label by language, specialization, and country. Each filter lists several values. The audience card shows how many experts match the saved filters. When you ask the agent about the pool, it can count the same saved filters, so its number matches the card.

General projects label data you already have and require ID-verified experts. Data-collection projects, where experts produce new content, may instead use the wider unverified pool. A data-collection node must also include a media-upload control (recording or uploading video, or uploading a file) in its interface, or deployment is rejected. Specializations are unavailable with the unverified pool.

The audience carries no price of its own. The expert-labeling charge uses the per-task price under [Pricing](#pricing), plus the platform commission. Pool size feeds the estimate of how many experts will be onboarded (see [Onboarding](#onboarding)).

### Pricing

Set the per-task price and expected task time under **Audience & Pricing**.

| Setting | Values | Default | Notes |
| - | - | - | - |
| Price per task | Within the displayed range for your audience and task time, up to \$1,500 | \$6.00 | — |
| Time per task | 10 seconds to 99:59:59 | 1,800 seconds | — |
| Per-expert cap | 1 to 50 tasks | Off | Value ignored while the cap is off |

Deployment rejects a price outside the allowed range for the selected audience and expected task time, as well as prices above \$1,500.

Your expert-labeling charge is the per-task price you set plus the platform commission, billed once per labeled item. **Expert Service Cost** shows this combined charge; the commission is displayed as 33%.

## Onboarding

Onboarding is an optional one-time training course that is on by default. Experts complete it before labeling items. The agent writes the course on the node's **Training** card, and you can edit it there by hand. Only you turn the course on or off. The course consists of steps containing pages of content blocks: text to read, a quiz, a practice exercise, a consent block, or worked examples drawn from labeled data.

Deployment enforces the course contract when onboarding is on:

* 3 to 6 steps, each holding at least one block.
* A stated role, goal, and success criteria for the expert.
* At least one quiz. A quiz needs its question text, at least two named options, and a correct answer marked among them.
* Practice exercises and worked examples cannot be used in the same course. Worked examples require the labeling interface to be built first.
* No block left empty: text needs content, a consent block needs its consent text, a practice exercise needs a task description and grading criteria, and each worked example needs at least one filled-in check.

All text in the course counts together toward the 150,000-character limit for one node setting. A practice exercise is graded by an LLM against its grading criteria.

Onboarding does not apply under synthetic labeling, though the settings are kept (see [Who does the labeling](#who-does-the-labeling)). When you reuse an audience (see [Audience reuse](#audience-reuse)), experts who already passed the earlier course skip it.

Onboarding is billed once per expert who joins the task. The cost breakdown labels it **Onboarding (one-time per expert)**, or **Training (one-time per expert)** when an [exam](#exam) is enabled. An enabled exam adds a separate **Exam (one-time per expert)** charge when a passing expert starts work. Human reviewers are included in these one-time charges. See [Pipeline pricing](https://docs.platform.toloka.ai/docs/data/concepts/pricing.md#the-cost-lines).

### Audience reuse

A node can reuse the expert audience of a Generation or Quorum node in a previously deployed pipeline. This audience includes the labeling and human-review experts. Reuse is off by default. Two methods choose the source node, one of them agent-only:

| Method | Eligible source nodes |
| - | - |
| Curated picker — in the **Audience & Pricing** card or through the agent | Eligible deployed nodes from other pipelines in this project, as shown in the picker |
| Direct entry — agent only | A deployed source node your team owns, including one in another project |

The source must have a recorded deployment and belong to your team. Otherwise, the setting is rejected. If the source deployment ran with onboarding, the reusing node must keep onboarding on or deployment is rejected. Labeling experts are always reused. Human reviewers are reused only when the source is a Generation node whose deployment used human review. Experts who passed the source node's onboarding get access without repeating it. Reuse is cleared when you switch to synthetic labeling and is unavailable in synthetic mode.

Reuse carries no charge of its own. It can lower onboarding cost because already-trained experts skip the course.

## Exam

An exam tests experts on real tasks before they get production tasks. Experts who do not pass get none. Set it up on the node's **Exam** card or by asking the agent. The card appears only when experts do the labeling, and the Quorum node has the same card. When the node reuses an audience, **Enable Exam** follows the source node.

| Setting | What it sets |
| - | - |
| **Enable Exam** | Turns the exam on. It is off by default |
| **Golden Dataset** | A dataset in this project whose rows are the exam tasks. Each row holds a value for every required input and the correct answer for every output graded by **Ground Truth**; each value is a single answer that fits the field's type. Name its fields after the top-level keys the labeling interface reads and writes, which can differ from the node's field names. Provide at least as many rows as **Tasks per Expert**, up to 200 |
| **Entities to Evaluate** | How each output field is graded: **Ground Truth** compares the answer with the golden one by **Direct Match** or a **Custom Instruction**, **Quality Criteria** applies the node's criteria, and **Not Graded** leaves the field out of scoring. At least one output must be graded |
| **Tasks per Expert** | How many exam tasks each expert completes, from 1 to 10 |
| **Pass threshold** | How many of those tasks must be fully correct to pass, from 1 to **Tasks per Expert** |

Deployment needs a golden dataset, and the **Exam Golden Dataset Lint** must finish with no findings. It checks that the golden answers fit the task's answer format and quality criteria; see [Self-check](https://docs.platform.toloka.ai/docs/data/concepts/self-check.md). **Custom Instruction** and **Quality Criteria** grading use the node's review model, or the recommended default when the node has no LLM review. **Direct Match** uses no model.

With an exam enabled, a practice exercise in the onboarding course draws a warning, because the exam already tests experts on real tasks. After deployment, the card's **Exam funnel** shows how many experts started, completed, and passed.

Each expert who passes is charged once, when they start work, as **Exam (one-time per expert)**: one task at your per-task price plus the review-model calls that graded their exam answers. Human QA reviewers who pass the exam are charged the same way. With an exam enabled, the onboarding line is labeled **Training (one-time per expert)**. See [Pipeline pricing](https://docs.platform.toloka.ai/docs/data/concepts/pricing.md#the-cost-lines).

## Related

* [Overview of pipeline nodes](https://docs.platform.toloka.ai/docs/data/reference/nodes.md) — the other node kinds and how they compare
* [Quality control](https://docs.platform.toloka.ai/docs/data/concepts/quality-control.md) — the shared review model these verdicts and review paths build on
* [Fields and data](https://docs.platform.toloka.ai/docs/data/concepts/fields-and-data.md) — the field model behind required, optional, and repeating fields


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.