Skip to content

Evaluate: Cross-provider context serialisation for ADF multi-model routing #685

@AlexMikhalev

Description

@AlexMikhalev

Parent Epic

#682 -- Evaluate Pi architectural patterns

Pattern

Pi's pi-ai layer supports cross-provider handoffs: switch models mid-session while serialising conversation context across different provider formats (Anthropic, OpenAI, Google, etc.). Context serialisation handles format differences transparently.

Current State

ADF (terraphim_orchestrator) routes different agents to different models via RoutingEngine:

  • fastest -> Cerebras llama-3.3-70b (~300ms)
  • think -> z.ai GLM-5 (reasoning)
  • general -> z.ai GLM-4.7
  • default -> Claude via claude -p

However, each agent runs in isolation. There is no mechanism to:

  1. Hand off context from one model to another mid-task
  2. Serialise a conversation from Claude format to OpenAI format for a second opinion
  3. Use a cheaper model for initial analysis then escalate to a more capable model with the same context

Evaluation Questions

  1. Is cross-provider handoff valuable for ADF? Current agents are independent. Would "start with Cerebras, escalate to Claude" improve cost/quality?
  2. What does context serialisation look like in Rust? Pi does this in TypeScript. Rust implementation would need serde-based format converters for each provider's message schema.
  3. Does this conflict with the Agent SDK direction? If we migrate ADF to Agent SDK (Epic: Evaluate Pi (badlogic/pi-mono) architectural patterns for terraphim-ai #682 context), we're locked to Claude. Cross-provider would only apply to non-SDK agents.
  4. What's the minimal viable implementation? E.g., Anthropic <-> OpenAI message format converter as a standalone function.

Acceptance Criteria

  • Identify 2-3 concrete ADF scenarios where cross-provider handoff would improve outcomes
  • Prototype message format converter: Anthropic Messages API <-> OpenAI Chat Completions API
  • Measure context loss (if any) during serialisation round-trip
  • Decision: implement, defer, or reject with rationale

References

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions