Poe OpenAI API: Compatibility & Tool Calling Issues

Bug Report: Poe OpenAI-Compatible API Issues

Report Type

Both Documentation Issues and API Functionality Bugs

---

1. CRITICAL: Silent Tool Calling Failures

Issue

Tool calling requests fail silently during streaming - the stream simply stops without error messages, making debugging impossible.

Affected Models

Testing performed in Cursor, Cline, Roo-Code, and OpenCode:

Complete Failures (Silent stream termination):

• Grok-4
• Grok-Code-Fast-1
• Grok-4-Fast-Reasoning
• Google Gemini 2.5 Flash
• Google Gemini 2.5 Pro
• Qwen (all versions)
• GLM-4.6
• Kimi K2
• Minimax M1

Inconsistent (Sometimes works, sometimes fails):

• Claude Opus 4.1
• Claude Sonnet 4.5
• Claude Haiku

Mostly Working:

• GPT-5-Codex
• GPT-4 (OpenAI models)

Reproduction

1. Endpoint: api.poe.com/v1/chat/completions
2. Use standard OpenAI tools parameter format (as per fastapi_poe)
3. Request coding assistance requiring tool calls in Cursor/Cline
4. Stream stops mid-response with no error

Expected Behavior

• Return proper error codes (400, etc.) when tool calling is unsupported
• Continue streaming with error details
• Provide debug information

Actual Behavior

Silent failure - stream terminates without explanation

---

2. DOCUMENTATION: Misleading Compatibility Claims

Issue Location

https://creator.poe.com/docs/external-applications/openai-compatible-api

Claim vs Reality

Doc Claims:

“OpenAI-compatible interface works with existing tools like Cursor, Cline, Continue, and more”

Reality:

• Only works reliably in: OpenCode, Roo-Code, Cline (MCP disabled)
• Only works with: Anthropic and OpenAI models
• XAI models (Grok series) fail in ALL coding tools
• Most Chinese models (Qwen, GLM, Kimi, Minimax) fail completely

Required Fix

Update documentation to explicitly list:

1. Which models work with which tools
2. Which models support tool calling
3. Known limitations per model

---

3. MISSING FEATURE: reasoning_effort Parameter

Issue

Documentation states reasoning_effort is “Ignored”:

Parameter	Support
reasoning_effort	Ignored

Problems

Inconsistency with Poe.com:

• On Poe.com web chat, users CAN configure reasoning for GPT-5
• API omits this same capability

Provider Feature Loss:

• OpenAI API natively supports reasoning_effort
• Poe’s proxy strips this functionality
• Users lose features their provider offers

Documentation Claims

“Custom parameters (thinking_budget, reasoning_effort, etc.) - The OpenAI-compatible API does not support passing custom bot parameters. To use custom parameters like thinking_budget for Claude models, reasoning_effort for GPT models, or any bot-specific parameters, you must use the Poe Python SDK with fp.ProtocolMessage(parameters={…})”

The Problem

This defeats the entire purpose of the OpenAI-compatible API. If developers must use the Poe Python SDK, why create an OpenAI-compatible endpoint at all?

Requested Solution

Support all provider-native parameters in the OpenAI-compatible API, including:

• reasoning_effort (OpenAI)
• thinking_budget (Anthropic)
• Any other model-specific parameters

---

4. MISSING DOCUMENTATION: Tool Calling Limits & Capabilities

Missing Information

No documentation on:

1. Maximum number of tool calls per request
2. Whether max tool calls limit exists
3. Which models support tool calling (native vs simulated)
4. Tool calling implementation method per model

Suspected Issue

Silent failures may be caused by reaching undocumented max_tool_calls limit.

Required Documentation

Please add:

Tool Calling Specifications:
- Max tool calls per request: [NUMBER]
- Models with native tool calling support: [LIST]
- Models with simulated/XML-parsed tool calling: [LIST]
- Models without tool calling support: [LIST]

---

5. DOCUMENTATION CONTRADICTION: Tool Calling Support

Doc Claims (https://creator.poe.com/docs/external-applications/openai-compatible-api)

Parameter	Support
tool_choice	Fully Supported
parallel_tool_calls	Fully Supported

Also States (https://creator.poe.com/docs/external-applications/tool-calling)

Native tool calling and parallel tool calls are supported.

Reality

When using Chinese models with tools:

Error 400: {
  "error": {
    "message": "Model GLM-4.6 does not support tool calling. Use a tool-capable model or remove tools from the request.",
    "type": "invalid_request_error",
    "param": "model",
    "code": "unsupported_feature_for_model"
  }
}

Verification

Checked provider documentation:

• GLM-4.6 ✅ Supports tool calling (per Zhipu AI docs)
• Qwen ✅ Supports tool calling (per Alibaba Cloud docs)
• Kimi K2 ✅ Supports tool calling (per Moonshot AI docs)
• Minimax M1 ✅ Supports tool calling (per Minimax docs)

Clarification Needed

1. Does Poe support native tool calling or simulated (XML-based) tool calling?
2. Is Poe modifying/stripping tool calling capabilities from providers?
3. Why do models that support tool calling at provider level fail through Poe API?

Note: Kamil’s repo (https://github.com/kamilio/poe-api-bridge) simulates tool calling via XML parsing because native support was unavailable.

---

6. COMPARISON: Other Proxies Work Successfully

Working Alternatives

Using identical models through:

• OpenRouter (https://openrouter.ai/api/v1) ✅ Full tool calling support
• Z.AI (https://api.z.ai/api/coding/paas/v4) ✅ Full tool calling support

Both support:

• Chinese models (GLM-4.6, OpenRouter Only Qwen, Kimi, Minimax)
• Full OpenAI API compatibility
• Native tool calling
• Coding tools (Cursor, Cline, etc.)

Implication

The issue is specific to Poe’s API implementation/proxy layer, not the underlying models.

---

7. LACK OF TRANSPARENCY: Closed Source SDK

Issue

Poe Python SDK is not open source on GitHub. Only example repos exist.

Impact

• Developers cannot:
  • Understand API behavior
  • Debug issues
  • Contribute improvements
  • Verify tool calling implementation
  • Build reliable integrations

Request

Open source the Poe Python SDK or at minimum provide:

1. Detailed API implementation docs
2. Tool calling flow diagrams
3. Model capability matrix
4. Proxy behavior specifications

---

8. WORKAROUND CREATED (Demonstrates the Problem)

My Solution

Created wrapper: poe2openai Docker: poe2openai

Uses Poe’s External Application Guide (fastapi_poe) to properly handle tool calls.

Results Even With Workaround

Works (mostly):

• GPT-5-Codex ⚠️ (inconsistent)
• Claude Opus 4.1 ⚠️ (inconsistent)
• Claude Sonnet 4.5 ⚠️ (inconsistent)
• Claude Haiku 4.5 ⚠️ (inconsistent)
• Grok-4 ⚠️ (sometimes)

Complete Failures:

• All Google models
• Grok-4-Fast-Reasoning
• Grok-Code-Fast-1
• All Chinese models

Key Finding: Even using Poe’s recommended External Application approach, there’s no consistency. Models that should work fail randomly.

SUMMARY OF REQUESTS

Immediate Fixes Needed

1. ✅ Return proper error codes instead of silent failures
2. ✅ Add reasoning_effort parameter support for OpenAI models
3. ✅ Fix tool calling for models where providers support it
4. ✅ Add consistency - stop random failures of working models

Documentation Updates Required

1. ✅ Accurate compatibility matrix (models × tools × features)
2. ✅ Tool calling limits and specifications
3. ✅ Native vs simulated tool calling clarification
4. ✅ Max tool calls limit
5. ✅ Model capability metadata endpoint

Transparency Requests

1. ✅ What modifications does Poe’s proxy make to provider APIs?
2. ✅ Why are provider features being stripped?
3. ✅ Open source the SDK or provide detailed specs

---

OFFER TO HELP

I have extensive experience with both OpenAI and Anthropic APIs. I’m willing to:

• Provide detailed testing results
• Shared log. Example from Grok-4.

{
  "conversation_id": "",
  "message_id": "",
  "query": [
    {
      "content": "You are an AI coding assistant, powered by GROK-4. You operate in Cursor.\n\nSome information may be automatically attached to your current state, such as what files you have open, where your cursor is, recently viewed files, edit history in your session so far, linter errors, and more. This information may or may not be relevant to the coding task, it is up for you to decide.\n\nYour main goal is to complete the user's request, denoted within the<user_query> tag.\n\n<tool_calling>\n1. Never refer to the tool names when speaking to the user. Instead, just say what the tool is doing in natural language.\n2. Prefer tools over asking the user for additional information.\n3. Always prefer to use tools in parallel.\n</tool_calling>\n\n<maximize_context_understanding>\nGather information thoroughly for a full picture before acting.\nExplore multiple implementations, edge cases, and search terms for comprehensive understanding.\n\nSemantic search is your main exploration tool.\n\nBias against asking the user; solve independently.\n</maximize_context_understanding>\n\n<making_code_changes>\nWhen making code changes, never output code to the user, unless requested.\n\nEnsure generated code could be run immediately. Fix linter errors, but don't guess. Limit fixes to 3 attempts per file; then ask the user.\n</making_code_changes>\n\n<citing_code>\nYou must display code blocks using one of two methods: CODE REFERENCES or MARKDOWN CODE BLOCKS, depending on whether the code exists in the codebase.\n\n## METHOD 1: CODE REFERENCES - Citing Existing Code from the Codebase\n\nUse this exact syntax with three required components:\n<good-example>\n```startLine:endLine:filepath\n// code content here\n```\n</good-example>\n\nRequired Components\n1. **startLine**: The starting line number (required)\n2. **endLine**: The ending line number (required)\n3. **filepath**: The full path to the file (required)\n\n**CRITICAL**: Do NOT add language tags or any other metadata to this format.\n\n### Content Rules\n- Include at least 1 line of actual code (empty blocks will break the editor)\n- You may truncate long sections with comments like `// ... more code ...`\n- You may add clarifying comments for readability\n- You may show edited versions of the code\n\n<good-example>\nReferences a Todo component existing in the (example) codebase with all required components:\n\n```12:14:app/components/Todo.tsx\nexport const Todo = () => {\n  return <div>Todo</div>;\n};\n```\n</good-example>\n\n<bad-example>\nTriple backticks with line numbers for filenames place a UI element that takes up the entire line.\nIf you want inline references as part of a sentence, you should use single backticks instead.\n\nBad: The TODO element (```12:14:app/components/Todo.tsx```) contains the bug you are looking for.\n\nGood: The TODO element (`app/components/Todo.tsx`) contains the bug you are looking for.\n</bad-example>\n\n<bad-example>\nIncludes language tag (not necessary for code REFERENCES), omits the startLine and endLine which are REQUIRED for code references:\n\n```typescript:app/components/Todo.tsx\nexport const Todo = () => {\n  return <div>Todo</div>;\n};\n```\n</bad-example>\n\n<bad-example>\n- Empty code block (will break rendering)\n- Citation is surrounded by parentheses which looks bad in the UI as the triple backticks codeblocks uses up an entire line:\n\n(```12:14:app/components/Todo.tsx\n```)\n</bad-example>\n\n<bad-example>\nThe opening triple backticks are duplicated (the first triple backticks with the required components are all that should be used):\n\n```12:14:app/components/Todo.tsx\n```\nexport const Todo = () => {\n  return <div>Todo</div>;\n};\n```\n</bad-example>\n\n<good-example>\nReferences a fetchData function existing in the (example) codebase, with truncated middle section:\n\n```23:45:app/utils/api.ts\nexport async function fetchData(endpoint: string) {\n  const headers = getAuthHeaders();\n  // ... validation and error handling ...\n  return await fetch(endpoint, { headers });\n}\n```\n</good-example>\n\n## METHOD 2: MARKDOWN CODE BLOCKS - Proposing or Displaying Code NOT already in Codebase\n\n### Format\nUse standard markdown code blocks with ONLY the language tag:\n\n<good-example>\n```python\nfor i in range(10):\n    print(i)\n```\n</good-example>\n\n<good-example>\n```bash\nsudo apt update && sudo apt upgrade -y\n```\n</good-example>\n\n<bad-example>\nDo not mix format - no line numbers for new code:\n\n```1:3:python\nfor i in range(10):\n    print(i)\n```\n</bad-example>\n\n## Critical Formatting Rules for Both Methods\n\n### Never Include Line Numbers in Code Content\n\n<bad-example>\n```python\n1  for i in range(10):\n2      print(i)\n```\n</bad-example>\n\n<good-example>\n```python\nfor i in range(10):\n    print(i)\n```\n</good-example>\n\n### NEVER Indent the Triple Backticks\n\nEven when the code block appears in a list or nested context, the triple backticks must start at column 0:\n\n<bad-example>\n- Here's a Python loop:\n  ```python\n  for i in range(10):\n      print(i)\n  ```\n</bad-example>\n\n<good-example>\n- Here's a Python loop:\n```python\nfor i in range(10):\n    print(i)\n```\n</good-example>\n\nRULE SUMMARY (ALWAYS Follow):\n  -\tUse CODE REFERENCES (startLine:endLine:filepath) when showing existing code.\n```startLine:endLine:filepath\n// ... existing code ...\n```\n  -\tUse MARKDOWN CODE BLOCKS (with language tag) for new or proposed code.\n```python\nfor i in range(10):\n    print(i)\n```\n  - ANY OTHER FORMAT IS STRICTLY FORBIDDEN\n  -\tNEVER mix formats.\n  -\tNEVER add language tags to CODE REFERENCES.\n  -\tNEVER indent triple backticks.\n  -\tALWAYS include at least 1 line of code in any reference block.\n</citing_code>\n<inline_line_numbers>\nCode chunks that you receive (via tool calls or from user) may include inline line numbers in the form LINE_NUMBER|LINE_CONTENT. Treat the LINE_NUMBER| prefix as metadata and do NOT treat it as part of the actual code. LINE_NUMBER is right-aligned number padded with spaces to 6 characters.\n</inline_line_numbers>",
      "content_type": "text/markdown",
      "role": "system"
    },
    {
      "content": "<user_info omitted>",
      "content_type": "text/markdown",
      "role": "user"
    },
    {
      "content": "<user_query omitted>",
      "content_type": "text/markdown",
      "role": "user"
    }
  ],
  "temperature": 0.699999988079071,
  "tool_results": [
    {
      "content": "<tool output omitted>",
      "name": "list_dir",
      "role": "tool",
      "tool_call_id": "call_97977686"
    },
    {
      "content": "<tool output omitted>",
      "name": "codebase_search",
      "role": "tool",
      "tool_call_id": "call_07079424"
    }
  ],
  "tools": [
    {
      "function": {
        "name": "codebase_search",
        "description": "<schema omitted>",
        "parameters": "<object schema>"
      },
      "type": "function"
    },
    {
      "function": {
        "name": "run_terminal_cmd",
        "description": "<schema omitted>",
        "parameters": "<object schema>"
      },
      "type": "function"
    },
    {
      "function": {
        "name": "grep",
        "description": "<schema omitted>",
        "parameters": "<object schema>"
      },
      "type": "function"
    }
  ],
  "type": "query",
  "user_id": "",
  "version": "1.1"
}

• Test fixes and beta features
• Contribute to documentation

Please let me know what additional information would be helpful.