Improve visualization API: allow passing ConversationVisualizer directly #1025
Conversation
- Enhanced the 'visualize' parameter to accept three types: - True: Use default visualizer (existing behavior, backward compatible) - False or None: No visualization (existing behavior, backward compatible) - ConversationVisualizer instance: Use custom visualizer (NEW) - This makes the API more intuitive: - Before: visualize=False + callbacks=[custom_viz.on_event] (confusing) - After: visualize=custom_visualizer (clear and direct) - Updated type signatures in: - Conversation factory class - LocalConversation - RemoteConversation - Added comprehensive tests for the new functionality - All existing tests continue to pass (backward compatible) Co-authored-by: openhands <[email protected]>
- Shows how to pass a ConversationVisualizer directly to Conversation - Demonstrates custom highlighting configuration - Makes the API usage clear and intuitive Co-authored-by: openhands <[email protected]>
Coverage Report •
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
- Added detailed step-by-step instructions for documenting examples - Included links to format documentation and example files - Makes it much clearer for contributors how to add documentation Co-authored-by: openhands <[email protected]>
- Added comprehensive guide for using custom ConversationVisualizer - Shows the new direct API: visualize=custom_visualizer - Includes examples of highlight patterns and customization options - Documents the improvement over the old callback-based approach Related to: OpenHands/software-agent-sdk#1025 Co-authored-by: openhands <[email protected]>
- Rename 20_custom_visualizer.py to 26_custom_visualizer.py to avoid conflict with existing 20_stuck_detector.py - Replace simple example with comprehensive MinimalProgressVisualizer implementation - Demonstrate the new API improvement where ConversationVisualizer instances can be passed directly to visualize parameter - Include detailed documentation and comparison between old and new approaches - Add proper error handling and step tracking functionality Co-authored-by: openhands <[email protected]>
Remove outdated API comparison comments and simplify example code to focus on the current API without referencing old approaches. Co-authored-by: openhands <[email protected]>
openhands-sdk/openhands/sdk/conversation/impl/local_conversation.py
Outdated
Show resolved
Hide resolved
- Replace if/elif chain with @Handles decorator pattern - Add EventHandlerMixin for clean event handler registration - Improve code maintainability and type safety - Self-documenting event handler methods - Easy extensibility for new event types Co-authored-by: openhands <[email protected]>
…on.py Co-authored-by: simonrosenberg <[email protected]>
- Create separate _sentinel.py module for _DEFAULT_VISUALIZER - Import sentinel from dedicated module in all conversation classes - Resolves circular import between conversation.py and implementation files - All visualizer API tests pass with proper default behavior Co-authored-by: openhands <[email protected]>
- Fix parameter name from 'visualize' to 'visualizer' in example code - Update comments to reflect the API change - Align with the simplified API that uses visualizer=ConversationVisualizer/None/default Co-authored-by: openhands <[email protected]>
- Fix parameter name from 'visualize' to 'visualizer' throughout documentation - Update visualization options to reflect simplified API: * Default behavior (no parameter): Creates default visualizer automatically * None: Disable visualization entirely * ConversationVisualizer instance: Use custom visualizer - Improve error handling example with more practical code - Align all examples with the API simplification changes Related to: OpenHands/software-agent-sdk#1025 Co-authored-by: openhands <[email protected]>
Documentation Review and API AlignmentIn response to @simonrosenberg's feedback: Fixed Issues:
|
- Added import to test_conversation_factory.py for visualizer parameter tests - Added import to test_remote_conversation.py for remote conversation tests - Added import to integration base.py for integration test framework - Fixed line length issue in integration base.py comment All visualizer parameter updates now complete and tests passing. Co-authored-by: openhands <[email protected]>
|
@OpenHands please fix the failing actions on PR #1025 at branch |
|
I'm on it! jpshackelford can track my progress at all-hands.dev |
- Update test files to use new visualizer parameter instead of visualize - Change visualize=False to visualizer=None for no visualization - Remove visualize=True from examples to use default visualizer - Fix all type check failures from API signature mismatches - All tests now pass with correct parameter usage Co-authored-by: openhands <[email protected]>
SummaryI successfully fixed all failing GitHub Actions on PR #1025 by resolving API signature mismatches throughout the codebase. The changes were minimal and focused: ✅ Request Completion Checklist:
🔧 Changes Made:Test Files (4 files updated):
Example Files (5 files updated):
✅ Verification:
The failing GitHub Actions should now pass because all API signature mismatches have been resolved while maintaining the intended behavior of the new visualizer API. |
- Update test to correctly verify that when a ConversationVisualizer instance is passed directly, it's used as-is - Remove incorrect expectation that create_default_visualizer() should be called when passing a custom instance - The test now properly verifies the custom visualizer instance is used and its callback is registered - All 1077 SDK tests now pass Co-authored-by: openhands <[email protected]>
| self._visualizer = visualizer | ||
| composed_list = [self._visualizer.on_event] + composed_list | ||
| # visualizer should happen first for visibility | ||
| elif visualizer is _DEFAULT_VISUALIZER: |
There was a problem hiding this comment.
@OpenHands think about ways we can handle _DEFAULT_VISUALIZER in a more elegant way rather than making visualizer: ConversationVisualizer | None | Any
There was a problem hiding this comment.
I'm on it! xingyaoww can track my progress at all-hands.dev
There was a problem hiding this comment.
Summary
I've successfully improved the visualizer API by replacing the sentinel value pattern with a more elegant boolean-based approach. Here's what was changed:
Changes Made:
-
Type Signature Improvement
- Changed from:
visualizer: ConversationVisualizer | None | Any = _DEFAULT_VISUALIZER - Changed to:
visualizer: bool | ConversationVisualizer | None = True
- Changed from:
-
Implementation Updates
- Replaced
visualizer is _DEFAULT_VISUALIZERchecks withvisualizer is True - Updated logic comments to reflect "False or None" instead of just "None"
- Removed the
_sentinel.pyfile entirely
- Replaced
-
Files Modified
conversation.py- Updated factory class type signatures (3 overloads + implementation)local_conversation.py- Updated implementation and docstringremote_conversation.py- Updated implementation and docstring- Deleted
_sentinel.py- No longer needed
Benefits:
✅ More Elegant: Uses intuitive boolean values (True/False) instead of custom sentinel objects
✅ Better Type Safety: Eliminates the need for Any type, enabling proper type checking
✅ Cleaner API: Intuitive behavior - True = default visualizer, False/None = no visualization, ConversationVisualizer = custom
✅ Simpler Code: No need for sentinel pattern boilerplate
✅ Fully Backward Compatible: All existing tests pass without modification
Verification:
- ✅ All 11 visualization tests pass
- ✅ All 226 conversation tests pass
- ✅ Pre-commit hooks pass (ruff, pyright, pycodestyle)
- ✅ Changes pushed to PR Improve visualization API: allow passing ConversationVisualizer directly #1025
The changes have been committed and pushed to the feature/improve-visualizer-api branch, updating PR #1025.
Replace the sentinel value pattern (_DEFAULT_VISUALIZER) with a more elegant boolean-based approach for the visualizer parameter. Changes: - Changed type signature from 'ConversationVisualizer | None | Any' to 'bool | ConversationVisualizer | None' - Updated default value from _DEFAULT_VISUALIZER to True - Replaced sentinel check 'visualizer is _DEFAULT_VISUALIZER' with 'visualizer is True' - Removed the _sentinel.py file as it's no longer needed - Updated documentation to reflect the new type signature Benefits: - Cleaner, more intuitive API (True = default, False/None = disabled) - Proper type checking without needing 'Any' - No need for custom sentinel values or types - Fully backward compatible with existing usage All tests pass successfully. Co-authored-by: openhands <[email protected]>
openhands-sdk/openhands/sdk/conversation/impl/local_conversation.py
Outdated
Show resolved
Hide resolved
|
@OpenHands -- your latest commit seems to be taking us in the wrong direction. Please see review comments from @simonrosenberg and @jpshackelford |
|
I'm on it! jpshackelford can track my progress at all-hands.dev |
Based on review feedback from @simonrosenberg and @jpshackelford, this commit improves the visualizer API by replacing the confusing True sentinel value with an explicit _DEFAULT_VISUALIZER object. Changes: - Replace 'visualizer: bool | ConversationVisualizer | None = True' with 'visualizer: ConversationVisualizer | None | Any = _DEFAULT_VISUALIZER' - Use explicit sentinel object _DEFAULT_VISUALIZER instead of True - Update logic from 'visualizer is True' to 'visualizer is _DEFAULT_VISUALIZER' - Update docstrings to reflect cleaner API (omit parameter for default) - Maintain full backward compatibility This makes the API much cleaner: - Default: Conversation(agent=agent) # Uses default visualizer - None: Conversation(agent=agent, visualizer=None) # No visualization - Custom: Conversation(agent=agent, visualizer=my_visualizer) # Custom The True sentinel was confusing because it didn't clearly indicate 'default'. The new explicit sentinel object makes the intent much clearer. Co-authored-by: openhands <[email protected]>
SummaryI have successfully addressed the review comments from @simonrosenberg and @jpshackelford regarding the visualizer API changes in PR #1025. ✅ Request Completion Checklist:
🔧 Key Changes Made:
🎯 Result - Much Cleaner API:# Default visualizer (when omitted)
Conversation(agent=agent)
# No visualization
Conversation(agent=agent, visualizer=None)
# Custom visualizer
Conversation(agent=agent, visualizer=my_visualizer)The API is now much more intuitive and follows better software engineering practices by using an explicit sentinel object rather than overloading the meaning of |
| visualize: bool = True, | ||
| name_for_visualization: str | None = None, | ||
| visualizer: ( | ||
| type[ConversationVisualizerBase] | ConversationVisualizerBase | None |
There was a problem hiding this comment.
Sorry, I'm a bit dense, is there a reason why this is a type too, or is it the agent overreacting?
There was a problem hiding this comment.
yes, basically in the default cases, it defaults to a class so that the conversation can initialize it -- i'm not sure if we can put DefaultConversationVisualizer() (an instance) as a default arg though?
There was a problem hiding this comment.
I think because the user can pass either an instance or class for the visualizer
e.g Conversation(visualizer=MyCustomVisualizer)
or
custom_visualizer = MyCustomVisualizer()
Conversation(visualizer=custom_visualizer)
I feel we could simplify this by asking the user to only pass in a class instead of an instance. We can check in the __init__ method whether the user sent an instance instead and raise an exception. It would also get rid of some duplicate code initializing the visualizer state.
There was a problem hiding this comment.
Here's what GPT-5 suggests
Generally no, it’s not a good idea to make the default argument of a function a class instance (or any mutable object like a list, dict, or set).
Here’s why — and when it can be acceptable.
⚠️ The core issue: Mutable default arguments
In Python, default argument values are evaluated once — at the time the function is defined, not each time it’s called.
That means if you do something like this:
class Config:
def __init__(self):
self.count = 0
def do_something(cfg=Config()):
cfg.count += 1
return cfg.countYou might expect each call to create a new Config object — but instead, every call shares the same instance:
do_something() # 1
do_something() # 2
do_something() # 3This happens because the single Config() instance created at function definition time is reused.
✅ The correct pattern
If you want a new instance each time, make the default None and create it inside the function:
def do_something(cfg=None):
if cfg is None:
cfg = Config()
cfg.count += 1
return cfg.countNow each call behaves as expected.
🧠 When a class instance
can
be a default
There are limited cases where this pattern is acceptable:
-
The object is immutable (e.g. a frozen Pydantic model, a tuple, or a dataclass with frozen=True).
-
The object is stateless or pure, meaning reusing it has no side effects.
-
It’s a sentinel or constant used only for comparison, not mutation.
Example:
EMPTY_CFG = Config()
def process(cfg=EMPTY_CFG):
...As long as you treat EMPTY_CFG as read-only, this is fine.
✅ Best practice summary
| Case | Good Idea? | Notes |
|---|---|---|
| Mutable object (list, dict, class instance) | ❌ | Causes shared state bugs |
| Immutable or stateless object | ✅ | Safe but rare |
| Use None as default and create new instance | ✅✅ | Idiomatic and safest |
Would you like me to show the same pattern using a Pydantic model as the default argument example (since you prefer Pydantic)?
There was a problem hiding this comment.
So the type[ConversationVisualizerBase] serve the purpose of a default_factory
There was a problem hiding this comment.
We might want to take Rohit's suggestion here
I feel we could simplify this by asking the user to only pass in a class
but idk if right now
There was a problem hiding this comment.
yeah i'd vote for go with the current version since it doesn't limit flexibility - but i can be convinced otherwise!
There was a problem hiding this comment.
@OpenHands Read this particular review thread. Now, there are some Ruff rules that check for mutable defaults in python: find them, you can search the internet docs if you need to. I think it's more than one.
Then checkout main branch, and verify if our Ruff in pre-commit and in CI contains those rules. If it doesn't, open an issue documenting the problem, and open a PR to add them.
There was a problem hiding this comment.
I'm on it! enyst can track my progress at all-hands.dev
There was a problem hiding this comment.
Summary of work
What I found (Ruff rules for mutable defaults)
- B006: mutable-argument-default
- B008: function-call-in-default-argument
- B039: mutable-contextvar-default
- RUF012: mutable-class-default
What I verified on main
- Our Ruff config (pyproject.toml) only selected E, F, I, UP, ARG. These mutable-default rules were not enabled.
- pre-commit and CI use that same config, so they weren’t enforcing these rules.
What I changed
- Created branch chore/lint-enable-mutable-defaults from main.
- Edited pyproject.toml to enable the rules via:
- [tool.ruff.lint] extend-select = ["B006", "B008", "B039", "RUF012"]
- Kept the change minimal: only pyproject.toml was modified.
What I observed after enabling the rules (for awareness)
- Quick local scan showed:
- 20× B008
- 8× RUF012
- 2× B006
- 0× B039
Tracking and PRs
- Opened issue documenting the gap and plan: Ruff config missing mutable-default checks (B006, B008, B039, RUF012) #1054
- Opened a draft PR adding the rules: Enable Ruff checks for mutable defaults (B006, B008, B039, RUF012) #1055
- Enable Ruff checks for mutable defaults (B006, B008, B039, RUF012) #1055
- Commit includes “Co-authored-by: openhands [email protected]”
Checklist
- Identified all relevant Ruff rules (B006, B008, B039, RUF012)
- Verified main branch, pre-commit, and CI didn’t include them
- Opened an issue documenting the problem and plan
- Opened a draft PR adding the rules with a minimal change
- Committed only the relevant file (pyproject.toml)
Next steps
- Decide whether to land the rules with fixes in follow-up PR(s) or add allowlists for intentional patterns; then mark the PR ready for review.
Co-authored-by: Engel Nyst <[email protected]>
Co-authored-by: Rohit Malhotra <[email protected]>
…improve-visualizer-api
|
Summary of my work (/codereview-roasted on PR #1025) What I did
Key findings (short)
Critical issues (must fix)
Improvement opportunities (should fix)
Verdict
Recommended next steps
|
xingyaoww
added
test-examples
|
Hi! I started running the integration tests on your PR. You will receive a comment with the results shortly. |
🔄 Running Examples with
|
| Example | Status | Duration | Cost |
|---|---|---|---|
| 01_standalone_sdk/02_custom_tools.py | ✅ PASS | 95s | $0.11 |
| 01_standalone_sdk/03_activate_skill.py | ✅ PASS | 10s | $0.01 |
| 01_standalone_sdk/05_use_llm_registry.py | ✅ PASS | 10s | $0.01 |
| 01_standalone_sdk/07_mcp_integration.py | ✅ PASS | 48s | $0.02 |
| 01_standalone_sdk/09_pause_example.py | ✅ PASS | 87s | $0.01 |
| 01_standalone_sdk/10_persistence.py | ✅ PASS | 35s | $0.02 |
| 01_standalone_sdk/11_async.py | ✅ PASS | 137s | $0.03 |
| 01_standalone_sdk/12_custom_secrets.py | ✅ PASS | 18s | $0.01 |
| 01_standalone_sdk/13_get_llm_metrics.py | ✅ PASS | 55s | $0.02 |
| 01_standalone_sdk/14_context_condenser.py | ✅ PASS | 162s | $0.28 |
| 01_standalone_sdk/17_image_input.py | ✅ PASS | 17s | $0.02 |
| 01_standalone_sdk/18_send_message_while_processing.py | ✅ PASS | 36s | $0.01 |
| 01_standalone_sdk/19_llm_routing.py | ✅ PASS | 22s | $0.02 |
| 01_standalone_sdk/20_stuck_detector.py | ✅ PASS | 18s | $0.01 |
| 01_standalone_sdk/21_generate_extraneous_conversation_costs.py | ✅ PASS | 12s | $0.01 |
| 01_standalone_sdk/22_anthropic_thinking.py | ✅ PASS | 15s | $0.01 |
| 01_standalone_sdk/23_responses_reasoning.py | ✅ PASS | 48s | $0.01 |
| 01_standalone_sdk/24_planning_agent_workflow.py | ✅ PASS | 682s | $0.64 |
| 01_standalone_sdk/25_agent_delegation.py | ❌ FAIL (exit: 1) | 59s | $0.00 |
| 01_standalone_sdk/26_custom_visualizer.py | ✅ PASS | 24s | $0.00N/A |
| 02_remote_agent_server/01_convo_with_local_agent_server.py | ✅ PASS | 96s | $0.05 |
| 02_remote_agent_server/02_convo_with_docker_sandboxed_server.py | ✅ PASS | 160s | $0.04 |
| 02_remote_agent_server/03_browser_use_with_docker_sandboxed_server.py | ✅ PASS | 64s | $0.04 |
❌ Some tests failed
Total: 23 | Passed: 22 | Failed: 1
|
Looks like there are a few issues preventing this PR from being merged!
If you'd like me to help, just leave a comment, like Feel free to include any additional details that might help me get this PR into a better state. You can manage your notification settings |
🧪 Integration Tests ResultsOverall Success Rate: 100.0% 📁 Detailed Logs & ArtifactsClick the links below to access detailed agent/LLM logs showing the complete reasoning process for each model. On the GitHub Actions page, scroll down to the 'Artifacts' section to download the logs.
📊 Summary
📋 Detailed Resultslitellm_proxy_deepseek_deepseek_chat
litellm_proxy_gpt_5_mini_2025_08_07
litellm_proxy_claude_sonnet_4_5_20250929
|
enyst
left a comment
enyst
left a comment
There was a problem hiding this comment.
Generally LGTM, thank you for this. I think it's more developer-friendly this way!
* Document custom visualizer feature - Added comprehensive guide for using custom ConversationVisualizer - Shows the new direct API: visualize=custom_visualizer - Includes examples of highlight patterns and customization options - Documents the improvement over the old callback-based approach Related to: OpenHands/software-agent-sdk#1025 Co-authored-by: openhands <[email protected]> * Update custom visualizer documentation for improved example - Fix file reference from 20_custom_visualizer.py to 26_custom_visualizer.py - Update example code to match the comprehensive MinimalProgressVisualizer implementation - Add documentation for both simple configuration and custom subclass approaches - Clarify the difference between basic highlighting and full custom visualization - Update running instructions to use correct file name This aligns with the improved example in software-agent-sdk PR #1025. Co-authored-by: openhands <[email protected]> * Comprehensive rewrite of custom visualizer documentation Transform the documentation from simple API usage examples to comprehensive educational content that teaches developers how to create effective custom visualizers: Key improvements: - Detailed explanation of the event system (ActionEvent, ObservationEvent, MessageEvent, AgentErrorEvent) - Two clear approaches: simple configuration vs. full subclassing - Comprehensive best practices section covering: * State management and progress tracking * Error handling and fallback strategies * Performance considerations for high-frequency events * Flexible output formats for different environments * Integration with external systems (webhooks, logging, monitoring) - Real-world code examples for each concept - Built-in visualizer reference with default patterns and configuration options - Updated to reference the improved 26_custom_visualizer.py example This transforms the guide from basic API documentation into a complete tutorial for building production-ready custom visualizers. Co-authored-by: openhands <[email protected]> * Address review feedback: remove 'production-ready', focus on custom visualizers, improve next steps - Remove 'production-ready' language as requested - Remove mention of API improvement to focus on custom visualizers - Update Next Steps section with more relevant related topics: * Async conversations and event callbacks * Conversation metrics and performance tracking * Interactive conversations with real-time updates * Pause/resume with custom logic Co-authored-by: openhands <[email protected]> * Add custom visualizer guide to navigation - Add convo-custom-visualizer to Agent Features section in docs.json - Position it after agent-custom as requested - This should resolve the 404 error and make the guide appear in sidebar Co-authored-by: openhands <[email protected]> * Add link to default visualizer source code - Add reference link to ConversationVisualizer implementation - Helps developers understand the code structure and implementation details - Positioned in Built-in Visualizer Reference section for easy access Co-authored-by: openhands <[email protected]> * Update custom visualizer documentation to match actual code patterns - Update example code to match the actual MinimalProgressVisualizer implementation - Remove overly speculative best practices that aren't evident in the code - Focus best practices on patterns actually demonstrated in the examples - Simplify performance considerations to match what's actually shown - Update state management examples to use the actual implementation patterns Co-authored-by: openhands <[email protected]> * Add comprehensive event types table to custom visualizer documentation Add a table overview of all event types handled by the default visualizer before diving into detailed descriptions. This provides a quick reference for developers to understand the complete event system. Co-authored-by: openhands <[email protected]> * Improve custom visualizer documentation with event properties and rendering details - Replace 'when fired' code snippets with detailed property information - Add comprehensive event property descriptions and default rendering info - Add Approach 3: Custom Object with on_event Method (no subclassing required) - Improve subclassing documentation with built-in features and patterns - Update code examples to show actual event property usage - Better explain ConversationVisualizer inheritance benefits Co-authored-by: openhands <[email protected]> * Document decorator-based event handler pattern for custom visualizers - Add section on EventHandlerMixin and @Handles decorator - Show how to avoid long if/elif chains in on_event methods - Explain benefits: self-documenting, type-safe, extensible - Provide complete working example with best practices Co-authored-by: openhands <[email protected]> * Update custom visualizer documentation for new API - Fix parameter name from 'visualize' to 'visualizer' throughout documentation - Update visualization options to reflect simplified API: * Default behavior (no parameter): Creates default visualizer automatically * None: Disable visualization entirely * ConversationVisualizer instance: Use custom visualizer - Improve error handling example with more practical code - Align all examples with the API simplification changes Related to: OpenHands/software-agent-sdk#1025 Co-authored-by: openhands <[email protected]> * Update documentation to reflect new visualizer API from PR #1025 - Changed base class from ConversationVisualizer to ConversationVisualizerBase - Updated to new DefaultConversationVisualizer for built-in visualization - Changed parameter from 'visualize' to 'visualizer' throughout - Updated all code examples to use new API - Simplified visualizer configuration options - Updated method signatures and initialization patterns - Synchronized all code blocks with latest examples from agent-sdk PR #1025 Co-authored-by: openhands <[email protected]> * Update convo-custom-visualizer.mdx --------- Co-authored-by: openhands <[email protected]> Co-authored-by: John-Mason P. Shackelford <[email protected]>
Summary
This PR improves the visualization API to make it more intuitive and flexible by allowing users to pass a
ConversationVisualizerinstance directly to thevisualizeparameter.Motivation
Currently, if a user wants to use a custom visualizer, they have to:
This is counter-intuitive because setting
visualize=Falsesounds like you DON't want visualization, but you actually do - just with a custom visualizer.Changes
Enhanced the
visualizeparameter to accept three types:True: Use default visualizer (existing behavior, backward compatible)FalseorNone: No visualization (existing behavior, backward compatible)ConversationVisualizerinstance: Use custom visualizer (NEW)Example Usage (New)
Files Modified
openhands-sdk/openhands/sdk/conversation/conversation.py: Updated factory class type signaturesopenhands-sdk/openhands/sdk/conversation/impl/local_conversation.py: Implemented new logic for LocalConversationopenhands-sdk/openhands/sdk/conversation/impl/remote_conversation.py: Implemented new logic for RemoteConversationtests/sdk/conversation/local/test_conversation_visualize_param.py: Added comprehensive tests for the new functionalityexamples/01_standalone_sdk/20_custom_visualizer.py: Added example demonstrating the new feature.github/scripts/check_documented_examples.py: Improved error messages with step-by-step documentation instructionsBackward Compatibility
✅ Fully backward compatible - all existing code will continue to work:
visualize=True(default) → creates default visualizer (unchanged)visualize=False→ no visualization (unchanged)Testing
Documentation
📚 Related documentation PR: OpenHands/docs#77
The documentation includes:
This addresses the feedback about making the visualization system more intuitive and user-friendly.
Agent Server images for this PR
• GHCR package: https://github.com/OpenHands/agent-sdk/pkgs/container/agent-server
Variants & Base Images
eclipse-temurin:17-jdknikolaik/python-nodejs:python3.12-nodejs22golang:1.21-bookwormPull (multi-arch manifest)
# Each variant is a multi-arch manifest supporting both amd64 and arm64 docker pull ghcr.io/openhands/agent-server:a578ad3-pythonRun
All tags pushed for this build
About Multi-Architecture Support
a578ad3-python) is a multi-arch manifest supporting both amd64 and arm64a578ad3-python-amd64) are also available if needed