Recently we have had a few examples of issues or P...
# proj-agent
l
Recently we have had a few examples of issues or PR's that have been complaining about how tool calls were thinking blocks are not parsed properly. In my opinion these are not our responsibility they are rather the responsibility of the LM provider or litellm. So I would like to make a blanket policy that we will not be accepting these PRS by giving feedback to people about how they can mitigate the issue by choosing another provider or sending a PR to litellm. Does this sound reasonable?
👍 1
nod 1
@fresh-machine-37269 find all the places where we discuss repository divisions on OpenHands/{OpenHands,software-agent-sdk} and create a PR noting that issues due to failed parsing of tool calls or thinking blocks are the responsibility of the LLM provider or litellm, not OpenHands, so we recommend filing an issue upstream. Also find all open issues/PRs in this category.
👀 1
f
🤖 On it! View progress here: oss-agent-canvas.ngrok.dev/conversations/…
Done — here's the result: PR created: https://github.com/OpenHands/software-agent-sdk/pull/4614 Adds a
CONTRIBUTING.md
note that malformed tool calls / thinking blocks are the LLM provider's or LiteLLM's responsibility (not OpenHands), recommends filing upstream + switching providers, and states we generally won't accept PRs that only patch around a specific provider's/LiteLLM's malformed output. Where the repo-division guidance lives (files documenting
OpenHands/{OpenHands, software-agent-sdk}
boundaries): • OpenHands/OpenHands — README.md, AGENTS.md, docs/DEVELOPMENT.md, docs/architecture.md • OpenHands/software-agent-sdk — README.md, AGENTS.md, CONTRIBUTING.md Open issues/PRs in this category (still open): • software-agent-sdk #4540 — Tool calls return incorrect/weird syntax with Synthetic Provider (issue) • software-agent-sdk #4530 — LLM-generated conversation titles leak raw
<think>
reasoning blocks (issue) Note: the policy PR lives in the SDK repo (tool-call parsing is SDK-owned). If you'd like it mirrored into OpenHands/OpenHands too, I can open a second PR.
c
I think this is reasonable and simplifies things a lot sometimes. However, I do have an additional proposal: • people need to know, many times, what LLMs work well with OpenHands; in fact, even this policy is to tell people to use another, which will lead to the question “which do we recommend” • I think maybe the ‘openhands/‘ provider LLMs should be on that list • that seems to imply that for those, we except them or we remove them