The Art of the Blend: A User's Precision Directives for Dataset Construction
In the sprawling, multi-threaded conversation of an opencode coding session, most user messages are brief requests for status updates or simple corrections. But occasionally, a message arrives that fundamentally redirects the trajectory of the work — not through volume, but through precision. Message [msg 9602] is one such message. It is a single sentence from the user, yet it contains three distinct, technically nuanced directives that reshape the entire data expansion pipeline. To understand why this message was written, one must appreciate the context that immediately precedes it: the assistant had just been caught flat-footed, downloading only three of the eight datasets listed in the project's DATA_EXPANSION.md plan, and had been prompted by the user to include the rest ([msg 9595]). The assistant scrambled to update the prep script, killing the running generation and restarting from scratch ([msg 9596]–[msg 9600]). But when the user checked progress and aborted the monitoring command ([msg 9601]), they realized something deeper was wrong: the assistant was approaching data expansion as a mechanical concatenation problem rather than a deliberate curation exercise. Message [msg 9602] is the corrective.
The message reads in its entirety:
Also do a blend of extraction; Tool calling - make sure we pass tool specs in a way that works. Blend - smaller datasets include as a whole, then do 200k-ish tokens total in some general-heavy blend;
This is not a casual remark. It is a compact, multi-part specification that reveals the user's deep understanding of the data pipeline's architecture and its pitfalls. Let us unpack each clause.
"Also do a blend of extraction"
The first directive — "a blend of extraction" — is the most conceptually significant. The assistant's initial approach had been to download each dataset, extract prompts using a generic column-matching heuristic, and concatenate everything into a single massive JSONL file. The result, as the assistant would later discover ([msg 9604]), was a 910K-sample monolith with severe quality issues: 57,072 out of 58,180 extracted Agent Training samples were flagged as duplicates, WildClaw yielded zero usable prompts due to a column name mismatch, and Hermes Function Calling produced only ~2K samples instead of the full 1,893 rows with proper tool definitions. The user's use of the word "blend" signals a fundamental shift in strategy. A blend is not a concatenation — it is a curated mixture with controlled proportions, where each component is prepared according to its own requirements before being combined. The user is telling the assistant to treat dataset construction as a deliberate recipe, not a bulk import.
This directive also implies a rejection of the "more is better" philosophy that had driven the assistant to target 910K samples. The user understands that data quality and compositional balance matter more than raw volume, especially for a training run that will ultimately consume these prompts to generate completions for DFlash drafter training.
"Tool calling - make sure we pass tool specs in a way that works"
The second clause is a pointed technical requirement. The datasets Hermes Function Calling v1 and Agent Training both contain structured tool definitions — JSON objects describing function names, parameters, and descriptions that the model must learn to invoke. These tool specifications are stored in a tools column alongside the conversations column. The user's instruction to "pass tool specs in a way that works" reveals an awareness of a subtle but critical failure mode: if the extraction pipeline strips or mangles these tool definitions, the resulting prompts will be useless for training the model to perform tool calling. The model needs to see the full system message with embedded <tools> XML tags and the structured function definitions to learn the pattern.
The assistant's subsequent investigation ([msg 9604]–[msg 9605]) confirms the user's implicit diagnosis. The original prep script was extracting prompts by looking for generic columns like instruction or query, which don't exist in these datasets. The Hermes FC dataset has columns ['id', 'conversations', 'tools', 'category', 'subcategory', 'task'], and the Agent Training dataset has ['conversations', 'tools', 'source', 'category', 'difficulty', 'domain', 'language', 'id']. Neither has a standalone instruction field — the prompt must be reconstructed from the system message (which contains the tool definitions) plus the first user turn. The user's directive forces the assistant to rewrite the extraction logic to handle this structure properly.
"Blend - smaller datasets include as a whole, then do 200k-ish tokens total in some general-heavy blend"
The third clause is the blending strategy itself, and it contains an ambiguity that reveals the gap between user intent and literal interpretation. The user writes "200k-ish tokens total" — literally 200,000 tokens. But as the assistant notes in its reasoning ([msg 9604]), "when they said '200k-ish tokens total,' they probably meant samples, not literal token count, since that would only give us around 100 examples." This is a correct inference. In the context of dataset construction, "200k" naturally refers to sample count — the project already has 902K existing samples, and the expansion is meant to add diversity, not double the dataset. The assistant's eventual implementation uses --target-total 200000 as a sample count ([msg 9607]), which is the correct interpretation.
The strategy itself is elegant: small datasets (Hermes FC at ~1.9K, WildClaw at ~686, Agent Training at a curated subset) are included in their entirety — every sample matters when you only have a few thousand. The remaining capacity is filled from the larger general-purpose datasets (Infinity-Instruct, MetaMathQA, CodeFeedback, WebInstructSub) with a "general-heavy" bias, meaning the majority of the blend comes from the broadest, most diverse source. This ensures the model sees plenty of tool-calling examples without being overwhelmed by them, maintaining the general conversational capability that the DFlash drafter needs to learn.
The Thinking Process Visible in the Response
The assistant's response to this message ([msg 9604]) shows a sophisticated reasoning process. It first checks the actual data structures of the tool-calling datasets, discovering that Hermes FC has 1,893 rows with proper conversations and tools columns, and that the system message already contains the <tools> XML format the user wants. It discovers that Agent Training has 59,401 rows with the same structure, and that the earlier 57K dedup was an artifact of poor column extraction rather than actual data redundancy. It discovers that WildClaw stores prompts in an HTTP body field rather than a query column. The assistant then designs a blend: include all 1,893 Hermes FC samples, ~10K Agent Training samples (a curated subset to avoid overwhelming the blend with agent data), all 686 WildClaw samples, and fill the remaining ~187.5K with a general-heavy mix from Infinity-Instruct, MetaMath, WebInstructSub, and CodeFeedback. This directly implements the user's three-part specification.
Assumptions and Input Knowledge
To understand this message, one must know: the structure of the DATA_EXPANSION.md plan; the distinction between ShareGPT format and raw Hugging Face dataset columns; the concept of tool-calling data with structured function definitions; the existing 902K-sample training dataset; and the DFlash training pipeline that will consume these generated completions. The user assumes the assistant understands all of this implicitly — and the assistant does, which is why the message works as a compact, efficient specification rather than requiring lengthy explanation.
Output Knowledge Created
This message creates the blueprint for the final prep script that generates 193K diverse, properly formatted prompts. The blend strategy — small datasets whole, large datasets sampled, general-heavy bias — becomes the architectural principle for the entire data expansion. The tool-spec requirement ensures that the 1,893 Hermes FC and curated Agent Training samples carry their full function definitions, enabling the model to learn tool calling from the generated completions. The message transforms the assistant's approach from bulk extraction to deliberate curation, and the resulting dataset — 192,995 successful completions with only 15 failures ([chunk 54.0]) — stands as a testament to the power of a well-specified user directive.