swe-1.6 model not accessible in WindsurfAPI despite working in Windsurf IDE and Devin CLI

[dmdfami]

Issue Report: swe-1.6 model not working in WindsurfAPI

Title

swe-1.6 model not accessible in WindsurfAPI despite working in Windsurf IDE and Devin CLI

Problem Description

The swe-1.6 and swe-1.6-fast models cannot be used through WindsurfAPI, even though they work perfectly in:

• Windsurf IDE
• Devin CLI (not Claude CLI)

These models are listed as free/default models and should be accessible to Pro accounts.

Environment

• WindsurfAPI version: v2.0.97
• Account type: Pro (Trial plan with 83% quota remaining, $200 extra usage)
• OS: macOS (Darwin 25.5.0)
• Windsurf session: Using devin-session-token from active Devin CLI session

Steps to Reproduce

1. Setup WindsurfAPI

git clone https://github.com/dwgx/WindsurfAPI.git
cd WindsurfAPI
bash setup.sh
node src/index.js

2. Add Account (Pro account with swe-1.6 access)

# Using devin-session-token from active Devin CLI session
curl -X POST http://localhost:3003/auth/login \
  -H "Content-Type: application/json" \
  -d '{"token": "devin-session-token$..."}'

3. Attempt to call swe-1.6

curl http://localhost:3003/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"swe-1.6","messages":[{"role":"user","content":"Hello"}],"max_tokens":10}'

Expected Behavior

• Should successfully call swe-1.6 model
• Should return response from swe-1.6 (as it does in Windsurf IDE/Devin CLI)

Actual Behavior

Error 1: Model entitlement issue

{
  "error": {
    "message": "模型 swe-1.6 在当前账号池中不可用（未订阅或已被封禁）",
    "type": "model_not_entitled"
  }
}

Error 2: After bypassing entitlement check

{
  "error": {
    "message": "unknown model UID MODEL_SWE_1_6: model not found",
    "type": "upstream_error"
  }
}

Error 3: After trying legacy flow (modelUid=null)

{
  "error": {
    "message": "neither PlanModel nor RequestedModel specified. You must specify a valid model.",
    "type": "upstream_error"
  }
}

Investigation Results

1. Account Information

From accounts.json:

• Account shows as "pro" tier but userStatus.pro = false (shows as "Trial")
• Account has valid Pro entitlements for other models (claude-opus-4.6, swe-1.5, etc.)
• swe-1.6 shows as "ok": false, "reason": "not_entitled"

2. Model Configuration

From src/models.js (line 214-220):

// Proto canonical enums: 359=MODEL_SWE_1_5 (fast), 369=THINKING, 377=SLOW, 420=1_6, 421=1_6_FAST.
'swe-1.5':     { name: 'swe-1.5',     provider: 'windsurf', enumValue: 377, modelUid: 'MODEL_SWE_1_5_SLOW', credit: 0.5 },
'swe-1.5-fast': { name: 'swe-1.5-fast', provider: 'windsurf', enumValue: 359, modelUid: 'MODEL_SWE_1_5', credit: 0.5 },
'swe-1.6':     { name: 'swe-1.6',     provider: 'windsurf', enumValue: 420, modelUid: 'MODEL_SWE_1_6', credit: 0.5 },
'swe-1.6-fast': { name: 'swe-1.6-fast', provider: 'windsurf', enumValue: 421, modelUid: 'MODEL_SWE_1_6_FAST', credit: 0.5 },

Enum values 420 and 421 are correctly assigned for swe-1.6 models.

3. Root Cause Analysis

From src/models.js (line 222-227):

// ── Adaptive (Windsurf 2026-04-06 changelog) ────────────
// Adaptive Model Router + Arena models live in the cloud catalog but their
// UIDs aren't recognized by SendUserCascadeMessage's direct-call path —
// upstream returns "unknown model UID adaptive: model not found". They only
// work through the Windsurf IDE's special routing layer that Cascade-direct
// doesn't expose. Mark deprecated so they stop showing in /v1/models. #109.

Key Finding: The comment indicates that adaptive models (like arena-fast, arena-smart) only work through "Windsurf IDE's special routing layer" that the Cascade-direct path (used by WindsurfAPI) doesn't expose.

Hypothesis: swe-1.6 may be an adaptive model that requires the same special routing layer that Windsurf IDE and Devin CLI have access to, but WindsurfAPI doesn't.

4. Comparison with Working Models

• ✅ swe-1.5-fast - Works perfectly (enumValue: 359, modelUid: 'MODEL_SWE_1_5')
• ✅ swe-1.5 - Works perfectly (enumValue: 377, modelUid: 'MODEL_SWE_1_5_SLOW')
• ✅ claude-opus-4.6 - Works perfectly
• ❌ swe-1.6 - Fails with "unknown model UID"
• ❌ swe-1.6-fast - Fails with "unknown model UID"

5. Architecture Analysis

From src/windsurf.js (line 6-8):

* Two flows:
*   Legacy  → RawGetChatMessage (streaming, simpler)
*   Cascade → StartCascade → SendUserCascadeMessage → poll GetCascadeTrajectorySteps

From src/models.js (line 4-6):

* Routing logic:
*   modelUid present  → Cascade flow (StartCascade → SendUserCascadeMessage)
*   only enumValue>0  → RawGetChatMessage (legacy)

Both routing methods fail for swe-1.6, suggesting the issue is with the underlying protocol/backend support rather than routing logic.

Attempted Workarounds

1. Manual entitlement override

Modified accounts.json to set swe-1.6 entitlement to true - Result: Auto-reverted by WindsurfAPI's probe mechanism

2. Model UID mapping

Attempted to map swe-1.6 → MODEL_SWE_1_5 (swe-1.5-fast UID) - Result: Works but calls wrong model (swe-1.5 instead of swe-1.6)

3. Legacy flow (modelUid=null)

Set modelUid to null to force legacy RawGetChatMessage flow - Result: "neither PlanModel nor RequestedModel specified" error

4. Entitlement check bypass

Modified src/handlers/chat.js to bypass entitlement check for swe-1.6 - Result: Still fails with "unknown model UID" error

Impact

• Users cannot access swe-1.6 through WindsurfAPI despite having valid Pro accounts
• swe-1.6 is reportedly a free/default model in Windsurf IDE/Devin CLI
• Creates inconsistency between WindsurfAPI and official Windsurf tools
• Limits the utility of WindsurfAPI for users who specifically want swe-1.6

Suggested Solutions

1. Implement Special Routing Layer (Recommended)

• Reverse-engineer or obtain documentation for Windsurf IDE's special routing layer
• Implement this routing mechanism in WindsurfAPI
• This would enable adaptive models like swe-1.6, arena models, etc.

2. Direct Cloud API Integration

• Investigate if there's a direct cloud API endpoint (like the GetCascadeModelConfigs endpoint in src/windsurf-api.js)
• Implement alternative calling mechanism that bypasses the local language server limitation
• The cloud API might support swe-1.6 where the local LS doesn't

3. Backend Registration

• Work with Windsurf team to register MODEL_SWE_1_6 and MODEL_SWE_1_6_FAST in the Cascade-direct path
• This would make the model UIDs recognizable by the current SendUserCascadeMessage flow

4. Documentation and Deprecation

• If swe-1.6 truly cannot be supported through the current architecture:
  • Clearly document this limitation
  • Remove swe-1.6 from the model catalog or mark it as unsupported
  • Provide guidance on using swe-1.5-fast as an alternative

Additional Information

Cloud API Endpoints

From src/windsurf-api.js:

• server.self-serve.windsurf.com/exa.api_server_pb.ApiServerService/GetCascadeModelConfigs
• This endpoint successfully fetches model configs including swe-1.6
• Suggests the cloud backend recognizes swe-1.6 even if the local LS doesn't

Account Verification

Account used for testing has:

• Email: dmd.fami@gmail.com
• Pro tier access (despite showing as "Trial" in some fields)
• 83% daily quota remaining
• $200 extra usage balance
• Successfully uses swe-1.6 in Windsurf IDE and Devin CLI

Related Issues

• Issue [Feature] 这个没用5.5模型 #109: Similar adaptive model routing limitation mentioned in code comments
• The comment explicitly mentions arena models having the same "special routing layer" requirement

Priority

High - This affects a core model that is:

• Advertised as free/default in official Windsurf tools
• Working in Windsurf IDE and Devin CLI
• Not accessible through WindsurfAPI despite valid account credentials
• Creates significant inconsistency in the Windsurf ecosystem

[dmdfami]

@dwgx Cảm ơn phản hồi. Tôi có một đề xuất giải pháp khác:

Đề xuất: Sử dụng Devin CLI làm OpenAI Shim

Thay vì cố gắng reverse engineer đường dẫn SWE models trong Windsurf IDE, tại sao không tái cấu trúc WindsurfAPI để có thể sử dụng Devin CLI làm OpenAI shim?

Lợi ích của cách tiếp cận này:

1. Giữ toàn bộ năng lực model gốc

   • SWE-1.6 hoạt động hoàn hảo trong Devin CLI
   • Không cần reverse engineer gRPC interface phức tạp
   • Sử dụng trực tiếp API đã được Windsurf cung cấp

2. Đầy đủ media toolcalling

   • Devin CLI đã hỗ trợ đầy đủ toolcalling
   • Không cần reimplement từ đầu
   • Giảm thiểu rủi ro bug

3. Vision capabilities

   • Devin CLI đã có sẵn vision support
   • Không cần xử lý riêng cho image inputs
   • Duy trì tính nhất quán với official tool

4. ACP (Agent Control Protocol)

   • Devin CLI có thể đã implement ACP
   • WindsurfAPI có thể proxy qua ACP layer
   • Tận dụng kiến trúc agent sẵn có

Cách triển khai đề xuất:

WindsurfAPI hiện tại:
Client → WindsurfAPI → gRPC Cascade → Windsurf Backend

Đề xuất mới:
Client → WindsurfAPI → Devin CLI (OpenAI Shim) → Windsurf Backend

Implementation options:

1. Subprocess mode: WindsurfAPI spawn Devin CLI process và giao tiếp qua stdin/stdout
2. HTTP proxy mode: Devin CLI chạy ở HTTP server mode, WindsurfAPI proxy requests
3. Hybrid: Sử dụng Devin CLI cho SWE models, giữ gRPC cho các models khác

Ưu điểm:

• ✅ SWE-1.6 và các models đặc biệt hoạt động ngay lập tức
• ✅ Giảm maintenance burden (không cần theo dõi changes trong gRPC interface)
• ✅ Tận dụng full feature set của official Devin CLI
• ✅ Tương thích với các models mới mà Windsurf thêm vào Devin CLI

Nhược điểm:

• ❌ Phụ thuộc vào Devin CLI binary
• ❌ Có thể chậm hơn do thêm một layer
• ❌ Cần handle process management/lifecycle

Tiếp theo:

Bạn nghĩ sao về cách tiếp cận này? Nếu hợp lý, tôi có thể:

1. Tạo một POC (proof of concept) cho việc wrap Devin CLI
2. Đóng góp code cho WindsurfAPI
3. Hoặc tạo một fork riêng nếu bạn không muốn merge vào main repo

Cách này có vẻ thực tế hơn reverse engineer gRPC interface, và sẽ giải quyết triệt để vấn đề SWE models cũng như các models đặc biệt khác trong tương lai.

[dwgx]

Keeping this open for swe-1.6 / swe-1.6-fast support.

I do not want to fake this as a normal Cascade catalog model. Direct Cascade has failed with unknown or missing model routing, while Devin CLI appears to use a separate agent path. The next useful update here should be a real Devin/ACP special-agent smoke, not guessed UID changes.