Phoenix: The Behavioral Prediction System

Twitter built a sequence-based prediction system for user behavior. Instead of aggregating features, Phoenix models up to 522 of your recent actions (spanning hours to days of behavior) to predict what you'll do next—like, reply, click. The architecture suggests a fundamental shift from feature-based to sequence-based recommendation.

From Averages to Sequences

The current recommendation system (NaviModelScorer) thinks about you in terms of averages and statistics: "Alice likes 30% tech content, 20% sports, follows 342 people, engages 10 times per day." Phoenix thinks about you in terms of what you're doing right now: "Alice just clicked 3 tech tweets in a row, expanded photos, watched a video—she's deep-diving into tech content."

The Core Difference

User features: {
  avg_likes_per_day: 10.5
  avg_replies_per_day: 2.3
  favorite_topics: [tech, sports]
  follower_count: 342
  engagement_rate: 0.15
  ... (many aggregated features)
}

Action sequence: [
  CLICK(tech_tweet_1)
  READ(tech_tweet_1)
  LIKE(tech_tweet_1)
  CLICK(tech_tweet_2)
  EXPAND_IMAGE(tech_tweet_2)
  CLICK(tech_tweet_3)
  ... (up to 522 aggregated actions)
]

The LLM Analogy (Inferred from Architecture)

Hypothesis: Phoenix uses a transformer-based architecture similar to language models, but instead of predicting text, it predicts actions. This inference is based on:

• Service name: user_history_transformer - external service (dependency in BUILD.bazel:20, gRPC client in PhoenixUtils.scala:26)
• Sequence-to-sequence prediction pattern (verified in PhoenixScorer.scala)
• Log probability outputs (verified in PhoenixUtils.scala:143-159)
• Self-attention over temporal sequences (inferred from architecture)

Comparison to language models:

What Phoenix Could Capture (Inference from Sequence Modeling)

Hypothesis: By modeling behavior as a sequence, Phoenix could understand dynamics that aggregated features miss. These capabilities are inferred from how sequence models typically work, not explicitly verified in code:

Scenario: User interested in both Tech and Sports (50/50 split)

Navi prediction: 50% tech, 50% sports (always the same)

Phoenix prediction:
  Monday morning: [TECH] [TECH] [TECH] [TECH] → 85% tech, 15% sports
  Monday evening: [SPORTS] [SPORTS] [SPORTS] → 10% tech, 90% sports

Same user, different behavioral context → different predictions

Engagement Streak:
[LIKE] [REPLY] [LIKE] [LIKE] [CLICK] [LIKE] → High engagement mode
Phoenix: Next tweet gets 75% engagement probability

Passive Browsing:
[SCROLL] [SCROLL] [CLICK] [SCROLL] → Low engagement mode
Phoenix: Next tweet gets 15% engagement probability

Same user, different momentum → different feed composition

Context Switch Detection:
[NEWS] [NEWS] [NEWS] → [MEME] [MEME] → Context switch!

Phoenix recognizes: User shifted from serious content to entertainment
Adapts feed: More memes, less news (for this session)

Behavioral Pattern: Profile Click + Follow
[CLICK_TWEET] → [CLICK_PROFILE] → [FOLLOW] → Next tweet from that author

Phoenix learns: Profile click + follow = strong interest signal
Result: Boost similar authors immediately

Why This Could Change Everything

Hypothesis: Phoenix could represent Twitter's move toward "delete heuristics"—the vision of replacing manual tuning with learned patterns. This interpretation is based on architectural design patterns:

The result: An algorithm that understands your current intent from your behavioral patterns, not your historical preferences from aggregated statistics. This is closer to how humans actually browse—following threads of interest as they emerge, not mechanically consuming averaged content.

Experience Behavioral Prediction (Simulation)

This simulator demonstrates how sequence-based prediction could work based on Phoenix's architecture. The predictions shown are illustrative of what behavioral sequence modeling enables, not actual Phoenix output.

The Technical Architecture

Two-Stage Pipeline

Phoenix splits prediction and aggregation into two separate stages:

Stage 1: PhoenixScorer (Prediction via gRPC)
  Input: User action sequence (up to 1024 actions) + candidate tweets
  Process: Transformer model predicts engagement probabilities
  Output: 13 predicted probabilities per tweet

Stage 2: PhoenixModelRerankingScorer (Aggregation)
  Input: 13 predicted probabilities from Stage 1
  Process: Per-head normalization + weighted aggregation
  Output: Final Phoenix score for ranking

Stage 1: Behavioral Sequence Prediction

Code: PhoenixScorer.scala:30-85

Input: Action Sequence

User action sequence (522 aggregated actions spanning hours to days):
[
  Session 1: FAV(tweet_123, author_A) + CLICK(tweet_123, author_A),
  Session 2: CLICK(tweet_456, author_B),
  Session 3: REPLY(tweet_789, author_C) + FAV(tweet_790, author_C),
  Session 4: FAV(tweet_234, author_A),
  ...
  Session 522: CLICK(tweet_999, author_D)
]

(Actions grouped into sessions using 5-minute proximity windows)

Candidate tweets: [tweet_X, tweet_Y, tweet_Z]

Processing: Transformer Model (Inferred Architecture)

Verified: Phoenix calls an external gRPC service named user_history_transformer (dependency in BUILD.bazel:20, client interface RecsysPredictorGrpc in PhoenixUtils.scala:26, usage in PhoenixUtils.scala:110-135)
Note: The actual service implementation is not in the open-source repository.
Inferred: The internal architecture likely follows transformer patterns based on the service name and sequence-to-sequence design:

Inferred Transformer Architecture:
  1. Embed each action in the sequence (action type + tweet metadata)
  2. Apply self-attention to identify relevant behavioral patterns
  3. For each candidate tweet, compute relevance to behavioral context
  4. Output 13 engagement probabilities via softmax

Verified Output Format (log probabilities):
{
  "tweet_X": {
    "SERVER_TWEET_FAV": {"log_prob": -0.868, "prob": 0.42},
    "SERVER_TWEET_REPLY": {"log_prob": -2.526, "prob": 0.08},
    "SERVER_TWEET_RETWEET": {"log_prob": -2.996, "prob": 0.05},
    "CLIENT_TWEET_CLICK": {"log_prob": -1.273, "prob": 0.28},
    ... (9 more engagement types)
  },
  ...
}

Why gRPC Service? (Verified: separate service, inferred: reasons)

• Verified: Phoenix calls external gRPC service for predictions (PhoenixUtils.scala:110-135)
• Inferred: Sequence model inference is compute-intensive (likely GPU/TPU accelerated)
• Inferred: Separate service allows independent scaling
• Inferred: Runs on specialized ML infrastructure, not home-mixer cluster

Stage 2: Per-Head Normalization and Aggregation

Code: PhoenixModelRerankingScorer.scala:23-81

Step 1: Per-Head Max Normalization

For each engagement type (each "head"), find the maximum prediction across all candidates:

3 candidates, 3 engagement types:
Candidate A: [FAV: 0.42, REPLY: 0.08, CLICK: 0.28]
Candidate B: [FAV: 0.15, REPLY: 0.35, CLICK: 0.20]
Candidate C: [FAV: 0.30, REPLY: 0.12, CLICK: 0.25]

Per-head max:
  Max FAV: 0.42
  Max REPLY: 0.35
  Max CLICK: 0.28

Attach max to each candidate for normalized comparison:
Candidate A: [(0.42, max:0.42), (0.08, max:0.35), (0.28, max:0.28)]
Candidate B: [(0.15, max:0.42), (0.35, max:0.35), (0.20, max:0.28)]
Candidate C: [(0.30, max:0.42), (0.12, max:0.35), (0.25, max:0.28)]

Why normalize per-head? Different engagement types have different prediction ranges. Normalization ensures fair aggregation.

Step 2: Weighted Aggregation

Phoenix uses the same weights as NaviModelScorer for fair A/B testing comparison:

Weight parameters: HomeGlobalParams.scala:786-1028
Actual values: the-algorithm-ml/projects/home/recap

Weights (configured in production):
  FAV: 0.5
  REPLY: 13.5
  REPLY_ENGAGED_BY_AUTHOR: 75.0
  RETWEET: 1.0
  GOOD_CLICK: 12.0
  ... (8 more positive weights)
  NEGATIVE_FEEDBACK: -74.0
  REPORT: -369.0

Final Score = Σ (prediction_i × weight_i)

Example for Candidate A:
  FAV:    0.42 × 0.5   = 0.21
  REPLY:  0.08 × 13.5  = 1.08
  CLICK:  0.28 × 12.0  = 3.36
  ... (sum all 13 engagement types)

  Phoenix Score = 0.21 + 1.08 + 3.36 + ... = 8.42

The 13 Engagement Types

Code: PhoenixPredictedScoreFeature.scala:30-193

Phoenix predicts probabilities for 13 different action types:

Context Window: 522 Aggregated Actions (Hours to Days)

Action sequence hydration: UserActionsQueryFeatureHydrator.scala:56-149
Max count parameter: HomeGlobalParams.scala:1373-1379

CRITICAL: The "5-minute window" is for aggregation (grouping actions within proximity), not filtering (time limit on history).

Configuration:
// Aggregation window (for grouping, NOT filtering)
private val windowTimeMs = 5 * 60 * 1000  // Groups actions within 5-min proximity
private val maxLength = 1024                // Max AFTER aggregation

// Actual default used
object UserActionsMaxCount extends FSBoundedParam[Int](
  name = "home_mixer_user_actions_max_count",
  default = 522,    // ← Actual default
  min = 0,
  max = 10000       // ← Configurable up to 10K
)

Processing flow:
1. Fetch user's full action history from storage (days/weeks)
2. Decompress → 2000+ raw actions
3. Aggregate using 5-min proximity window (session detection)
   → Actions within 5-min windows grouped together
4. Cap at 522 actions (default)

Result: 522 aggregated actions spanning HOURS TO DAYS, not 5 minutes!

What "5-minute aggregation window" means:

• ❌ NOT: "Only use last 5 minutes of actions"
• ✅ YES: "Group actions that occur within 5-minute proximity"
• ✅ Purpose: Session detection and noise reduction

Actual temporal span (522 actions):

Active user (~100 actions/hour):  ~5 hours of behavioral history
Normal user (~30 actions/hour):   ~17 hours of behavioral history
Light user (~10 actions/hour):    ~52 hours (2+ days) of behavioral history

Maximum (10,000 actions): Could span WEEKS for light users

Comparison to LLM context windows:

GPT-3:   2048 tokens (~1500 words, ~3-4 pages of text)
GPT-4:   8K-32K tokens (~6K-24K words)
Phoenix: 522 aggregated actions (~hours to days of behavior)

Phoenix vs Navi: Architecture Comparison

Current Status (Verified from Code)

Phoenix Infrastructure: All components verified in twitter/the-algorithm repository

Infrastructure Status (September 2025 commit):

• ✅ Verified: Complete two-stage architecture deployed (PhoenixScorer + PhoenixModelRerankingScorer)
• ✅ Verified: External transformer service user_history_transformer - dependency in BUILD.bazel:20, gRPC client RecsysPredictorGrpc in PhoenixUtils.scala:26
• ✅ Verified: User action sequence system complete (522 default, up to 10K configurable, aggregated via 5-min proximity windows - HomeGlobalParams.scala:1373-1379)
• ✅ Verified: 13 engagement predictions supported (PhoenixPredictedScoreFeature.scala)
• ✅ Verified: Per-head normalization for fair aggregation (RerankerUtil.scala:38-71)
• ✅ Verified: 8 experimental clusters configured
• ✅ Verified: Production-ready with comprehensive stats collection
• ⚠️ Verified: Feature-gated (default = false in code)

What This Means:

• Infrastructure is production-ready but not yet default
• Feature flags allow enabling Phoenix without code deployment
• The system is designed for A/B testing (multiple clusters configured)
• Whether it's currently active in production is unknown from open-source code

Multi-Model Experimentation Infrastructure

Cluster configuration: HomeGlobalParams.scala:1441-1451
Connection management: PhoenixClientModule.scala:21-61
Cluster selection: PhoenixScorer.scala:52-53

Phoenix isn't a single model—it's 9 separate transformer deployments designed for parallel experimentation:

PhoenixCluster enumeration:
- Prod          // Production model
- Experiment1   // Test variant 1
- Experiment2   // Test variant 2
- Experiment3   // Test variant 3
- Experiment4   // Test variant 4
- Experiment5   // Test variant 5
- Experiment6   // Test variant 6
- Experiment7   // Test variant 7
- Experiment8   // Test variant 8

What This Enables

// From PhoenixScorer.scala:52-53
val phoenixCluster = query.params(PhoenixInferenceClusterParam)  // Select cluster
val channels = channelsMap(phoenixCluster)                        // Route request

// Default: PhoenixCluster.Prod
// But can be dynamically set per user via feature flags

User Alice (bucket: control)      → PhoenixCluster.Prod
User Bob   (bucket: experiment_1) → PhoenixCluster.Experiment1
User Carol (bucket: experiment_2) → PhoenixCluster.Experiment2

Week 1: Deploy new model to Experiment1
        Route 1% of users to Experiment1
        Other 99% stay on Prod
        ↓
Week 2: Compare metrics (engagement, dwell time, follows, etc.)
        If Experiment1 > Prod: increase to 5%
        If Experiment1 < Prod: rollback instantly
        ↓
Week 3: Gradually increase: 10% → 25% → 50%
        Monitor metrics at each step
        ↓
Week 4: If consistently better, promote Experiment1 → Prod
        Start testing next variant in Experiment2

// getPredictionResponsesAllClusters queries ALL clusters in parallel
User request → Candidates [tweet_A, tweet_B, tweet_C]
             ↓
Query Prod:         tweet_A: {FAV: 0.40, REPLY: 0.10, CLICK: 0.60}
Query Experiment1:  tweet_A: {FAV: 0.45, REPLY: 0.12, CLICK: 0.58}
Query Experiment2:  tweet_A: {FAV: 0.38, REPLY: 0.15, CLICK: 0.62}
Query Experiment3:  tweet_A: {FAV: 0.42, REPLY: 0.11, CLICK: 0.65}
... (all 9 clusters)
             ↓
Log to Kafka: "phoenix.Prod.favorite", "phoenix.Experiment1.favorite", ...
             ↓
Offline analysis: Compare predicted vs actual engagement across all models

Hybrid Mode: Mixing Navi and Phoenix Predictions

Hybrid configuration: HomeGlobalParams.scala:1030-1108

Twitter can use Navi predictions for some action types and Phoenix predictions for others:

Hybrid Mode Configuration (per action type):
- EnableProdFavForPhoenixParam         = true   // Use Navi for favorites
- EnableProdReplyForPhoenixParam       = true   // Use Navi for replies
- EnableProdGoodClickV2ForPhoenixParam = false  // Use Phoenix for clicks
- EnableProdVQVForPhoenixParam         = false  // Use Phoenix for video views
- EnableProdNegForPhoenixParam         = true   // Use Navi for negative feedback
... (13 total flags, one per engagement type)

Incremental migration strategy:

Phase 1: Enable Phoenix, but use Navi for all predictions
         (Shadow mode - Phoenix predictions logged but not used)
         ↓
Phase 2: Use Phoenix for low-risk actions (photo expand, video view)
         Keep Navi for high-impact actions (favorite, reply, retweet)
         ↓
Phase 3: Gradually enable Phoenix for more action types
         Monitor metrics after each change
         ↓
Phase 4: Full Phoenix mode - all predictions from transformer
         Navi retired or kept as fallback

Why this matters: Reduces risk by preserving proven Navi predictions while testing Phoenix predictions incrementally. If Phoenix predictions for clicks are great but favorites are worse, Twitter can use Phoenix for clicks only.

What This Reveals

Technical Details

Connection pooling: Each cluster maintains 10 gRPC channels for load balancing and fault tolerance (90 total connections across 9 clusters).

Request routing: Randomly selects one of 10 channels per request for even load distribution (PhoenixUtils.scala:107-117).

Retry policy: 2 attempts with different channels, 500ms default timeout (configurable to 10s max).

Graceful degradation: If a cluster fails to respond, the system continues with other clusters (for logging) or falls back to Navi (for production scoring).

Code References

The Bottom Line

What we know: Phoenix infrastructure is complete, feature-gated, and production-ready. The architecture represents a fundamental shift from feature-based to sequence-based prediction. More importantly, Phoenix has sophisticated A/B testing infrastructure that strongly suggests active deployment on real users.

Evidence of Active Deployment

What This Means

Paradigm shift in progress:

• From static features to behavioral sequences: Your last 522 aggregated actions (hours to days of behavior) replacing lifetime averages
• From "what you usually like" to "what you're doing now": Session-aware, context-sensitive predictions that adapt as you browse
• From manual tuning to learned patterns: Transformer learns what matters from behavioral data, replacing 15+ hand-tuned engagement weights and penalties
• From daily batch updates to continuous adaptation: Algorithm learns your behavioral patterns over hours/days, not months

If/When Phoenix Becomes Default

The algorithm would understand you not as a static profile of historical preferences, but as a dynamic behavioral sequence revealing your current intent. Your feed would adapt as you browse, following threads of interest that emerge in your behavior—not mechanically serving averaged content from long-term statistics.

This mirrors how humans actually consume content: following curiosity as it arises, deep-diving into topics that capture attention, switching contexts when interest shifts. An algorithm that learns to follow your behavioral lead, not force you into a predetermined statistical box.

Current Reality