Request Routing & Transformers

Relevant source files

The following files were used as context for generating this wiki page:

• src/proxy/request-router.ts
• src/proxy/transformers/request-transformer.ts
• src/glmt/glmt-transformer.ts
• tests/unit/proxy/request-router.test.ts
• tests/unit/proxy/transformers/request-transformer.test.ts
• tests/unit/glmt/glmt-transformer.test.js

The Request Routing and Transformers system serves as the core orchestration layer for CCS, enabling the seamless translation of Anthropic-style requests into formats compatible with various upstream providers, such as OpenAI, GLM, and Gemini. This system manages the decision-making process for which provider profile to use based on request content, model names, or specific scenarios like long-context or thinking-heavy tasks.

By abstracting the complexities of different API protocols, CCS allows users to maintain a consistent CLI experience while leveraging a diverse ecosystem of AI backends. The architecture is split into a routing phase, which selects the destination, and a transformation phase, which rewrites the request and response payloads to match the target provider's requirements.

Sources: README.md, src/glmt/glmt-transformer.ts:1-12, tests/unit/proxy/request-router.test.ts:98-105

Request Routing Logic

The routing engine, primarily implemented in resolveProxyRequestRoute, determines the target profile and model for an incoming request. It uses a prioritized set of strategies to match requests to the most appropriate backend.

Routing Strategies

Routing is resolved using the following priority order:

1. Explicit Profile Selectors: Users can force a specific profile and model using the profile:model syntax in the request.
2. Scenario-Based Routing: Requests are routed based on specific characteristics (e.g., presence of thinking tags, long context, or specific tools).
3. Model Match: Plain model IDs are matched against the profiles that natively own or provide them.
4. Default Routing: If no specific match is found, the system falls back to a configured default profile.

Sources: src/proxy/request-router.ts, tests/unit/proxy/request-router.test.ts:117-172

Scenario-Based Resolution

The system supports specialized scenarios that override standard model matching:

Scenario	Trigger	Description
think	Reasoning effort flags or <Thinking:On> tags	Routes to profiles optimized for deep reasoning (e.g., DeepSeek Reasoner).
longContext	Request exceeds token threshold	Routes to models with massive context windows (e.g., Gemini 2.5 Pro).
webSearch	Request includes web_search tool	Routes to profiles capable of executing external search queries.
background	claude-3-haiku model request	Routes fast, low-cost tasks to efficient background models.

Sources: tests/unit/proxy/request-router.test.ts:139-183

Routing Flow

The following diagram illustrates how a request is routed to a specific profile.

The diagram shows the hierarchical decision tree used to resolve the destination for every proxied request.
Sources: tests/unit/proxy/request-router.test.ts:117-183

Request Transformers

Once a route is resolved, the ProxyRequestTransformer (or specialized ones like GlmtTransformer) converts Anthropic-style message blocks into the target provider's format.

Key Transformations

• Message Role Mapping: Converst roles like assistant and user and handles system messages embedded within the messages array.
• Tool Call Translation: Converts Anthropic's tool_use and tool_result blocks into OpenAI-compatible tool_calls and tool roles.
• Multimedia Handling: Translates base64 image blocks into OpenAI image_url parts.
• Reasoning Control: Maps thinking budget and effort flags (e.g., budget_tokens: 9000) to provider-specific fields like reasoning_effort: high.

Sources: tests/unit/proxy/transformers/request-transformer.test.ts:4-60, src/glmt/glmt-transformer.ts:60-65

Transformation Process Example

This sequence illustrates the bidirectional transformation performed by the proxy.
Sources: tests/unit/proxy/transformers/request-transformer.test.ts:4-30, src/glmt/glmt-transformer.ts:68-85

GLMT Pipeline Architecture

The GlmtTransformer orchestrates a specialized pipeline for OpenAI-compatible providers that support reasoning/thinking features.

Pipeline Components

• RequestTransformer: Handles the initial Anthropic → OpenAI conversion.
• StreamParser: Processes SSE delta events in real-time, accumulating content and reasoning segments.
• ResponseBuilder: Generates valid Anthropic response structures, including mandatory "thinking" signatures.
• ToolCallHandler: Manages the extraction and formatting of tool calls from upstream responses.

Sources: src/glmt/glmt-transformer.ts:15-41

Thinking and Reasoning Control

The transformer supports explicit extraction of thinking tags from user messages and parameters:

• Tag Detection: Identifies <Thinking:On> and <Effort:High> tags in prompt content.
• Keyword Detection: Detects keywords like ultrathink or think hard to automatically enable high-effort reasoning modes.
• Budget Mapping: Maps Anthropic token budgets to reasoning effort tiers (e.g., 2049-8192 tokens maps to medium effort).

Sources: tests/unit/glmt/glmt-transformer.test.js:65-100, tests/unit/glmt/glmt-transformer.test.js:233-280

Response Transformation & Validation

Responses from upstream providers are normalized back into the Anthropic format expected by the client.

Content Normalization

• Reasoning Content: Upstream reasoning_content is converted into a content block of type thinking.
• Stop Reason Mapping: Provider-specific finish reasons (e.g., length) are mapped to Anthropic constants (e.g., max_tokens).
• Signatures: The system generates opaque, deterministic thinking signatures required by the Anthropic contract for thinking blocks.

Sources: src/glmt/glmt-transformer.ts:85-110, tests/unit/glmt/glmt-transformer.test.js:125-145, tests/unit/glmt/glmt-transformer.test.js:164-175

Validation Checks

The system validates transformed responses against five criteria:

1. hasContent: Content block array exists and is non-empty.
2. hasThinking: Reasoning content was successfully captured if provided.
3. hasText: Primary response text is present.
4. validStructure: Metadata (role, type) matches the assistant role.
5. hasUsage: Token usage statistics are attached.

Sources: src/glmt/glmt-transformer.ts:193-206, tests/unit/glmt/glmt-transformer.test.js:200-215

Conclusion

Request Routing and Transformers provide the logic necessary to bridge different AI provider ecosystems. By combining flexible routing based on request "scenarios" with robust payload transformation, CCS ensures that advanced features like tool use and chain-of-thought reasoning work consistently across diverse backends like OpenAI, GLM, and Gemini.