Overview
Router actions are backend-defined and fetched by Bud admin from/routers/actions. The response provides action categories, parameter definitions, output definitions, icons, colors, descriptions, and validation metadata.
Action Categories and Features
The Router action catalog is organized into five functional families. The exact selectable list comes fromservices/budapp/budapp/router_ops/manifest.yaml, and disabled actions in that manifest are intentionally omitted from the UI and validation flow.
Signal Actions
Signals evaluate request, user, conversation, or environment facts. They are connected from the Trigger and then referenced by name inside Decision rule trees.Keyword Signal (signal_keyword)
Keyword Signal matches the request against configured words or phrases using exact, fuzzy, BM25, regex, or n-gram style matching. Use it to route requests that mention terms such as billing, refund, cancellation, or policy keywords.
Embedding Signal (signal_embedding)
Embedding Signal compares the request to reference prompts by semantic similarity instead of requiring exact wording. Use it to detect intents such as account support even when users phrase the same issue differently.
Domain Signal (signal_domain)
Domain Signal classifies the request into MMLU-style subject areas such as Law, Business, Biology, Computer Science, Math, Health, and others. Use it to send subject-specific prompts to specialist endpoints or safety policies.
User Feedback Signal (signal_user_feedback)
User Feedback Signal detects whether the user is satisfied, needs clarification, thinks an answer is wrong, or wants a different answer. Use it to escalate dissatisfied follow-up turns to stronger models or alternate prompting.
Reask Signal (signal_reask)
Reask Signal detects repeated or highly similar user messages across recent turns. Use it to change strategy when a user asks the same thing again after an unsatisfactory response.
Preference Signal (signal_preference)
Preference Signal detects requested answer style, such as concise, detailed, bullet-point, or alternative response preferences. Use it to route to paths or system prompts tuned for short, verbose, or structured answers.
Language Signal (signal_language)
Language Signal detects the language of the request, including English, Spanish, French, German, Chinese, Japanese, Korean, Arabic, Hindi, and others. Use it to route multilingual traffic to language-specialized endpoints or localized system prompts.
Geography Signal (signal_geography)
Geography Signal matches the caller’s resolved country code against configured ISO country codes or UNKNOWN. Use it to enforce data residency, regional compliance, or country-specific rollout rules.
Context Length Signal (signal_context)
Context Length Signal matches requests by token range using minimum and maximum token thresholds. Use it to send long-context prompts to endpoints with larger context windows and short prompts to faster models.
Structure Signal (signal_structure)
Structure Signal measures structural features such as question count, code blocks, ordered sequences, regex matches, keyword sets, or density. Use it to route coding tasks, multi-question prompts, or highly structured workflows to specialized models.
Complexity Signal (signal_complexity)
Complexity Signal scores whether a request appears easy or hard by comparing against configured easy and hard reference prompts. Use it to keep simple prompts on low-cost models and escalate reasoning-heavy prompts to stronger endpoints.
Knowledge Base Signal (signal_kb)
Knowledge Base Signal matches the request against registered knowledge-base labels or groups such as privacy, security, or MMLU domain catalogs. Use it for richer taxonomy-based routing for safety, privacy, escalation, or subject-matter policies.
Conversation Signal (signal_conversation)
Conversation Signal measures conversation shape, including message counts, roles, tool definitions, assistant tool calls, and tool-call cycles. Use it to distinguish first-turn requests, deep conversations, or agentic loops from regular chat traffic.
Decision Actions
Decisions evaluate signal and projection outputs, select candidate endpoints, and provide the attachment point for algorithms and plugins.Decision (decision)
Decision combines one or more signal or projection references with AND, OR, and NOT logic, then routes the first matching rule by priority to configured candidate endpoints. Use it to build route rules such as “Law domain AND hard complexity goes to legal-reasoning endpoints” with a lower-priority fallback decision.
A Decision’s priority controls evaluation order, rules contains the rule tree, and modelRefs lists the endpoints the Decision may route to. If multiple endpoints are present, an attached Algorithm chooses among them; without an Algorithm, the first endpoint is used.
Projection Actions
Projections derive reusable routing features from signals. Like signals, they connect from the Trigger and are referenced by name from Decision rules.Partition Projection (projection_partition)
Partition Projection groups several signal or projection members into named buckets and selects one or more members based on exclusive or overlapping semantics. Use it to turn several intent signals into a single selected intent, with an optional default member.
Score Projection (projection_score)
Score Projection combines multiple signals into one numeric score using weighted sum, max, min, or average aggregation. Use it to produce a cost, risk, quality, or complexity score from multiple weaker signals.
Mapping Projection (projection_mapping)
Mapping Projection converts a numeric score into named bands such as low, mid, or high using thresholds, percentiles, or sigmoid mapping. Use it to let Decisions reference score bands directly, such as routing high complexity to stronger models.
Algorithm Actions
Algorithms attach to Decisions and select the final endpoint from that Decision’s candidate endpoint list. The router editor allows Decision → Algorithm connections and treats algorithms as leaf nodes.Looper Algorithms
Looper algorithms can evaluate more than one candidate endpoint before returning a final response. They are useful when the route should trade additional model calls for better confidence, ranking, or reasoning quality.Confidence Looper (algorithm_confidence)
Confidence Looper tries candidates in an escalation order until a response meets a confidence threshold. Use it to start with cheaper models and escalate only when confidence is too low.
Ratings Looper (algorithm_ratings)
Ratings Looper runs candidate models in parallel and returns the response with the best rating. Use it when quality matters more than additional cost and concurrency.
ReMoM (Reasoning Mixture) (algorithm_remom)
ReMoM runs multiple reasoning rounds with configurable breadth and synthesizes a final response. Use it to improve hard reasoning outcomes by combining multiple model perspectives over several rounds.
Selection Algorithms
Selection algorithms choose one endpoint from the Decision’s candidate list. They are useful when a route needs deterministic selection, cost-aware escalation, latency optimization, load distribution, or controlled experiments.Static Selection (algorithm_static)
Static Selection always chooses the first candidate endpoint. Use it to keep a route deterministic or support simple one-endpoint Decisions.
Router-DC (algorithm_router_dc)
Router-DC ranks candidate endpoints by matching the request to model descriptions and optional capability tags. Use it to pick among specialized endpoints with distinct strengths such as code, writing, math, or vision.
AutoMix (algorithm_automix)
AutoMix tries a cheaper model first and escalates when verification fails. Use it to balance cost and quality by using stronger models only for harder or failed cheap-model attempts.
Hybrid Selection (algorithm_hybrid)
Hybrid Selection combines description matching, AutoMix-style signals, cost, and quality gap thresholds into a weighted score. Use it when you want a balanced endpoint selection strategy instead of optimizing only for cost, quality, or description match.
Latency-Aware (algorithm_latency_aware)
Latency-Aware scores candidates with TPOT and TTFT percentile targets. Use it to prefer endpoints that meet interactive latency or streaming responsiveness requirements.
Round-Robin (algorithm_round_robin)
Round-Robin rotates through candidate endpoints in order. Use it to spread traffic predictably across equivalent backends.
Random (algorithm_random)
Random selects a candidate endpoint uniformly at random for each request. Use it for simple load distribution when candidates are equivalent and deterministic rotation is unnecessary.
Weighted Random (algorithm_weighted_random)
Weighted Random selects endpoints randomly according to configured per-endpoint weights. Use it for canaries, A/B tests, gradual rollouts, or traffic bias toward preferred endpoints.
Least Busy (algorithm_least_busy)
Least Busy chooses the candidate with the fewest currently in-flight requests. Use it to smooth bursty traffic by preferring the least-loaded backend at request time.
Plugin Actions
Plugins attach to Decisions and modify request handling, response handling, caching, or policy behavior for requests that match that Decision. The router editor allows Decision → Plugin connections and treats plugins as leaf nodes.Semantic Cache (Plugin) (plugin_semantic_cache)
Semantic Cache reuses cached responses for semantically similar prior requests using a similarity threshold and TTL. Use it to reduce latency and cost for repeated or paraphrased common questions.
System Prompt (Plugin) (plugin_system_prompt)
System Prompt inserts or appends a route-specific system prompt before the request reaches the model. Use it to apply personas, safety instructions, or specialist behavior per route.
Request Params (Plugin) (plugin_request_params)
Request Params removes blocked request parameters, caps token or completion counts, and optionally strips unknown fields. Use it to enforce per-route input policy, cost limits, and parameter safety.
Fast Response (Plugin) (plugin_fast_response)
Fast Response returns a fixed response immediately without invoking a model. Use it for maintenance responses, deliberate refusals, or known-trivial fast paths.
Action Metadata
Each action includes metadata similar to:Supported Parameter Types
The router editor supports a broad set of parameter renderers:Router DAG API Shape
When saving a router, the UI converts editor steps intodag_config:
Router Resource Fields
Validation
Action parameters can be validated through/routers/actions/validate. Bud admin also performs client-side checks for required fields, empty arrays in required list parameters, ranges, string lengths, patterns, and conditional field visibility.