Custom Features

When to Use Custom Features

If the base prompt and decoding parameters are not enough to distinguish routing decisions, attach extra context such as user tier, traffic campaign, or lightweight classifier outputs. Custom features let you steer the parameter tower without editing the prompt.

Header Format

Set headers that start with X-Arfniia-Feature- (case-insensitive). The router strips these headers before forwarding the request downstream.

• Scalars: numeric values (e.g. 0.42, -3) are parsed as floats. Values outside [0, 1] are softly squashed with tanh so extreme magnitudes remain useful but bounded.
• Booleans: true / false (any casing) map to 1.0 / 0.0.
• Categoricals: any other non-empty string is hashed into the parameter embedding. Use them for labels such as enterprise, retail, or ab-test-b.

Example request:

curl -X POST "$BASE_URL/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer placeholder" \
  -H "X-Arfniia-Feature-User-Tier: enterprise" \
  -H "X-Arfniia-Feature-Risk-Score: 0.87" \
  -d '{
    "model": "advanced-reasoning",
    "messages": [
      {"role": "user", "content": "Summarize the attached claim."}
    ]
  }'

Inspecting Their Effect

• Use GET /v1/routers/{router}/explanations/{response_id} to view how much the parameter tower influenced a decision (attribution.params).
• Monitor router_overhead_latency_seconds to ensure feature parsing overhead stays negligible even when many headers are attached.

Tips

• Stick to concise keys (<= 32 characters) to avoid large hashed vocabularies.
• Center binary features around meaningful defaults. For example, send 0 for the majority case and 1 for the rare flag rather than encoding multiple mutually exclusive labels.
• When features come from untrusted sources, sanitize them before forwarding to avoid exploding the categorical space.