Use SDK agent settings and model switch UI#457
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
all-hands-bot
left a comment
There was a problem hiding this comment.
Taste Rating: 🟡 Acceptable - Solid architectural improvement delegating agent creation to the SDK.
Architecture Assessment:
Moving agent construction from frontend to SDK is the right direction—the frontend should describe what it wants through settings rather than how to build it. The code quality is good with proper type safety, test coverage, and clear documentation of the breaking change.
Key Observations:
-
Tool merging behavior - The new
getAgentTools()uses Map-based merging where defaults are always included and configured tools can override/extend them. This is more flexible than the old behavior (fixed defaults only), but the semantics should be documented. -
Condenser delegation - Frontend previously built full condenser config (
kind: "LLMSummarizingCondenser",llm: {...}), now just passes raw settings (enabled,max_size). The description confirms this is intentional SDK delegation, but verify the SDK creates equivalent configs. -
Behavioral equivalence - This changes who creates the agent but shouldn't change what agent is created. However, since agent creation logic moves to the SDK, there's inherent uncertainty until tested against a live agent-server with the new SDK.
Risk Assessment:
- Breaking change to conversation start payload (properly documented and blocked on SDK release)
- Moves core agent creation logic from frontend to SDK
- Behavioral equivalence depends on SDK correctly interpreting the new
agent_settingsformat - Recommendation: Per eval/benchmark risk policy, this PR should undergo lightweight evaluation testing against a real agent-server with the SDK changes before merging, since agent creation logic has moved and could plausibly affect agent behavior.
Verdict: ✅ Code is solid, tests pass, breaking change is documented. Request human review for eval/benchmark validation before merge.
|
@OpenHands /iterate |
|
I'm on it! neubig can track my progress at all-hands.dev |
Co-authored-by: openhands <openhands@all-hands.dev>
|
Addressed the review feedback in 6c5f9e5 and resolved the two inline threads. Local verification passed: targeted adapter test, typecheck, build, and lint. Ready for another look. This comment was created by an AI agent (OpenHands) on behalf of the PR author. |
all-hands-bot
left a comment
There was a problem hiding this comment.
Taste Rating: 🟡 Acceptable - Solid architectural improvement but requires eval verification
Architecture Assessment:
Delegating agent construction to the SDK is the right direction — the frontend should describe what it wants through settings rather than how to build it. Code quality is good with proper type safety, focused tests, and previous review feedback addressed.
Eval-Risk Flag:
This PR changes core agent initialization behavior (tool construction, condenser setup, agent creation all delegated to SDK). According to our review guidelines, changes affecting agent behavior must be validated with evals before merge.
Recommendation: Run lightweight evals to confirm this delegation doesn't introduce behavioral regressions, then merge. The architectural direction is sound.
[RISK ASSESSMENT]
- [Overall PR]
⚠️ Risk Assessment: 🟡 MEDIUM
Changes agent initialization flow by delegating to SDK. Potential for behavioral differences in tool availability, condenser behavior, or agent defaults. Risk is mitigated by focused regression test and SDK version pin, but eval verification is recommended.
VERDICT:
✅ Worth merging after eval verification
KEY INSIGHT:
This correctly shifts the responsibility boundary — frontends send declarative settings, the SDK owns agent construction.
…ngs' into codex/use-sdk-conversation-settings
|
Since my last summary, there have been no additional code changes or tool actions. Final status:
Remaining note:
|
|
@OpenHands /iterate |
|
I'm on it! neubig can track my progress at all-hands.dev |
Co-authored-by: openhands <openhands@all-hands.dev>
|
Fixed the CI Prettier failure in c0203cc and verified locally with |
Co-authored-by: openhands <openhands@all-hands.dev>
|
Merged the latest |
|
CI is green on the latest SHA 1e1b298: CI, snapshot tests, PR artifacts, and Vercel all passed. The branch is now mergeable with zero unresolved review threads.\n\nRemaining note: the existing review-bot comment is still a COMMENTED review recommending lightweight eval verification before merge; no code-change threads are open.\n\n_This comment was created by an AI agent (OpenHands) on behalf of the PR author._ |
|
OpenHands encountered an error: Sandbox not running: 80f5d20f57bb4621ab7c3dca811e340d See the conversation for more information. |
|
@OPEN /iterate |
|
@OpenHands /iterate |
|
I'm on it! neubig can track my progress at all-hands.dev |
…ation-settings # Conflicts: # src/api/agent-server-adapter.ts Co-authored-by: openhands <openhands@all-hands.dev>
|
Merged the latest Verification on
GitHub checks are green for the latest SHA (CI, snapshot tests, PR artifacts, and Vercel), the branch is mergeable, and there are zero unresolved review threads. Remaining note: the prior review-bot COMMENTED review still recommends lightweight eval verification before merge; no code-change review threads are open. This comment was created by an AI agent (OpenHands) on behalf of the PR author. |
|
Since my last summary, there have been no additional code changes or tool actions. Final status:
Remaining note: the existing review-bot |
|
@OpenHands /iterate |
|
I'm on it! neubig can track my progress at all-hands.dev |
…ation-settings Co-authored-by: openhands <openhands@all-hands.dev>
…ation-settings Co-authored-by: openhands <openhands@all-hands.dev>
📸 Snapshot Test ReportWarning Snapshot comparison step crashed (timeout, OOM, or runner error) — diff results below may be incomplete or absent. ❌ 1 snapshot differ from the main branch baseline. Add the
✅ Unchanged snapshots (72)
Generated by the Snapshot Tests workflow. This comment was created by an AI agent (OpenHands) on behalf of the repo maintainers. |
|
Since my last summary, there were no additional tool actions or code changes. Final status:
Overall: PR #457 was successfully driven through conflict resolution, local verification, CI monitoring, and merge. |



Summary
agent_settingsto the local agent server instead of constructing a concreteagentin the frontendcreate_agent()path so SDK default tools likeSwitchLLMToolare included when available/modelslash-command model message path for successfulSwitchLLMToolcalls, while still rendering failed switch observations as chat errorsStatus
The required agent-server support shipped in OpenHands/software-agent-sdk#3261 (
openhands-agent-server==1.22.1), so this PR is no longer blocked on the SDK release.Related regression coverage for the release behavior: OpenHands/software-agent-sdk#3264.
Verification
npm test -- --run __tests__/api/agent-server-adapter.test.tsnpm test -- --run __tests__/components/conversation-events/chat/event-content-helpers/should-render-event.test.ts __tests__/components/features/chat/model-messages.test.tsx src/hooks/mutation/conversation-mutation-utils.test.tsnpm run typechecknpm run buildNotes
Also filed OpenHands/typescript-client#164 to generate request/response types from the agent-server OpenAPI schema, so downstream frontends do not need to keep local
Record<string, unknown>payload boundaries for server-owned SDK models.Related issue: #699
🐳 Docker images for this PR
• GHCR package: https://github.com/OpenHands/agent-canvas/pkgs/container/agent-canvas
ghcr.io/openhands/agent-canvasghcr.io/openhands/agent-server:1.23.0-pythonopenhands-automation==1.0.0a33809f8286bd476c958e4b25730d93e0ecbd74436Pull (multi-arch manifest)
# Multi-arch manifest — Docker automatically pulls the correct architecture docker pull ghcr.io/openhands/agent-canvas:sha-3809f82Run
All tags pushed for this build
About Multi-Architecture Support
sha-3809f82) is a multi-arch manifest supporting both amd64 and arm64sha-3809f82-amd64) are also available if needed