DecisionNode is Bynn Intelligence’s decision model and inference API for returning typed answers from text, structured state and images. Its useful distinction is an answer contract: a caller declares the possible outputs. Before connecting those outputs to actions, however, read each type’s confidence definition. The same numeric threshold does not mean the same thing across types.
The official introduction describes a service that answers several questions about one state without generating a prose response. That can suit routing, classification and bounded scoring. It does not remove the need to determine whether the chosen answer is correct for your workload.
A valid choice can still be the wrong choice
The decision endpoint reference documents six answer types: choice, score, truth, number, point and box. A choice returns one of the caller’s declared keys. A truth answer returns a probability for a statement; it is not an interchangeable version of choice confidence.
Consider a synthetic event router with three destinations: documentation, technical support and account support. A legitimate sales inquiry fits none. A response can obey the schema perfectly while sending that inquiry to the wrong team. Include an explicit “other” destination where the taxonomy is incomplete, and give that destination a defined handling policy. The endpoint documentation explicitly warns that a choice selects one of the supplied keys even when none fits.
Question independence matters too: the reference says that one answer is not fed into another question in the same request. If a second decision needs the first result, that is another request. Batching questions about shared evidence does not create a sequential reasoning workflow.
Choice confidence rescales the leading probability
The confidence documentation defines choice confidence as (K × p_max − 1) / (K − 1), where K is the number of options and p_max is the selected option’s probability. It measures concentration above a uniform distribution. It should not be displayed to users as a measured probability of correctness.
For a three-option question with a leading probability of 0.80, the formula gives (3 × 0.80 − 1) / 2 = 0.70. Conversely, a confidence threshold of 0.80 corresponds algebraically to a leading probability of about 0.867. With two options, that same confidence threshold corresponds to 0.90. These are calculations from the documented definition, not model observations.
A threshold can still be useful. Its operational meaning needs evidence from the question, options and model version you intend to deploy. Bynn describes calibration as an estimate on its evaluation data and asks users to check their own error rate.
Here is a proposed evaluation: label a representative set of resolved routing events, including ambiguous and out-of-taxonomy cases. For each threshold, report the fraction routed automatically and the error fraction among those accepted events. Keep a separate evaluation set after choosing the threshold. A setting that handles very few events correctly may be too conservative to save work; one that handles nearly everything may create an expensive correction queue. No DecisionNode evaluation was executed for this article.
The low token price is only one part of the decision
As checked on October 26, the pricing page lists text input at $0.042 per million tokens for DecisionNode and $0.035 for Flash, with no output-token charge. Image and video tokens have separate rates; boosters also have their own charges. The free tier lists 50 Flash requests and 20 DecisionNode requests daily for the first workspace, with conditions described on that page.
For a deliberately simplified text-only example, one million calls using 1,000 billed input tokens each consume one billion tokens. At the listed Flash text rate, the model-token charge is $35; at $0.042 it is $42. That excludes boosters, other token classes and surrounding infrastructure. Use the actual usage and cost returned by the service to reconcile billing rather than estimating from visible characters.
The Flash model page documents the hosted tier and its request limits. The homepage’s approximately 5 ms Flash claim is a vendor timing claim, not an observed latency from a reader’s application. Measure the caller’s complete request duration separately from the server latency header, and separate cached responses, first requests and steady traffic. A short model execution does not eliminate network or queue time.
The benchmark headline leaves a calibration question open
Bynn’s October 19 preliminary evaluation reports 81.6% mean accuracy across 15 text suites and 25,134 items for MoE. It is a company-run development-split evaluation; the headline is a mean of suite accuracies, not a guarantee for each task. Bynn explicitly says that the article does not report calibration results per question type.
Accuracy and calibration answer different questions. A model can select the right option frequently while giving misleading probabilities on the cases your threshold accepts. Per-type calibration results and a held-out evaluation of the intended application would therefore be more useful for choosing automation thresholds than the aggregate score alone.
DecisionNode is worth evaluating when a bounded answer is the product requirement. Start by specifying the destinations, the handling of uncertain cases and the error budget. Then establish which documented field expresses the quantity your code actually needs.
Reporting note: Prepared with AI assistance from primary documentation. Numerical examples are calculations; the proposed evaluation and API requests were not executed. No independent performance result is claimed. The featured image is an original AI-generated editorial illustration.
