docs: add Sandbox Grouping Strategy section to Application Settings#514
docs: add Sandbox Grouping Strategy section to Application Settings#514jpelletier1 wants to merge 1 commit into
Conversation
Document the Sandbox Grouping Strategy feature that was exposed to all users in PR OpenHands/OpenHands#14291. - Add new section explaining sandbox grouping - Document all 5 available strategies with descriptions: - No Grouping (default, new sandbox per conversation) - Group by Newest (add to most recent sandbox) - Least Recently Used (add to oldest sandbox) - Fewest Conversations (add to least busy sandbox) - Add to Any (use first available sandbox) - Include note about shared state implications Co-authored-by: openhands <openhands@all-hands.dev>
|
@tofarr Can you review these docs on Sandbox Strategy? It was identified as a feature in Local GUI that's not documented. Thanks! |
all-hands-bot
left a comment
There was a problem hiding this comment.
🟢 Good taste - Clear documentation that follows the style guide.
The documentation is well-structured and provides helpful information about the Sandbox Grouping Strategy feature. A few minor clarifications would help users make more informed decisions about which strategy to use.
Was this automated review useful? React with 👍 or 👎 to this review to help us measure review quality.
Workflow run: https://github.com/OpenHands/docs/actions/runs/26173741100
| |----------|-------------| | ||
| | **No Grouping** | Creates a new sandbox for each conversation. This is the default behavior and provides maximum isolation between conversations. | | ||
| | **Group by Newest** | Adds new conversations to the most recently created sandbox. Useful when you want to continue working in the same environment across multiple conversations. | | ||
| | **Least Recently Used** | Adds new conversations to the oldest (least recently used) sandbox. This helps distribute work across sandboxes and can reuse existing environments. | |
There was a problem hiding this comment.
🟡 Suggestion: The term "oldest" is ambiguous. Consider rewording for clarity:
| | **Least Recently Used** | Adds new conversations to the oldest (least recently used) sandbox. This helps distribute work across sandboxes and can reuse existing environments. | | |
| | **Least Recently Used** | Adds new conversations to the sandbox that was least recently accessed (longest time since last use). This helps distribute work across sandboxes and can reuse existing environments. | |
| | **Group by Newest** | Adds new conversations to the most recently created sandbox. Useful when you want to continue working in the same environment across multiple conversations. | | ||
| | **Least Recently Used** | Adds new conversations to the oldest (least recently used) sandbox. This helps distribute work across sandboxes and can reuse existing environments. | | ||
| | **Fewest Conversations** | Adds new conversations to the sandbox with the fewest active conversations. This provides load balancing across your sandboxes. | | ||
| | **Add to Any** | Uses the first available sandbox for new conversations. This is the most flexible option and optimizes for sandbox reuse. | |
There was a problem hiding this comment.
🟡 Suggestion: "First available sandbox" is vague. What makes a sandbox available vs. unavailable? Consider clarifying:
| | **Add to Any** | Uses the first available sandbox for new conversations. This is the most flexible option and optimizes for sandbox reuse. | | |
| | **Add to Any** | Uses the first available sandbox for new conversations (any sandbox that exists in your environment). This is the most flexible option and optimizes for sandbox reuse. | |
Alternatively, if there are specific conditions that make a sandbox unavailable (e.g., being terminated, exceeding capacity), those should be documented.
| ### Available Strategies | ||
|
|
||
| | Strategy | Description | | ||
| |----------|-------------| | ||
| | **No Grouping** | Creates a new sandbox for each conversation. This is the default behavior and provides maximum isolation between conversations. | | ||
| | **Group by Newest** | Adds new conversations to the most recently created sandbox. Useful when you want to continue working in the same environment across multiple conversations. | | ||
| | **Least Recently Used** | Adds new conversations to the oldest (least recently used) sandbox. This helps distribute work across sandboxes and can reuse existing environments. | | ||
| | **Fewest Conversations** | Adds new conversations to the sandbox with the fewest active conversations. This provides load balancing across your sandboxes. | | ||
| | **Add to Any** | Uses the first available sandbox for new conversations. This is the most flexible option and optimizes for sandbox reuse. | |
There was a problem hiding this comment.
🟡 Suggestion: Consider adding a brief "When to Use" column or section to help users choose the right strategy. For example:
- No Grouping: When isolation is critical or debugging issues specific to one conversation
- Group by Newest: When iterating on the same project across multiple conversations
- Least Recently Used: When you want even distribution and have multiple long-running sandboxes
- Fewest Conversations: When you need automatic load balancing across sandboxes
- Add to Any: When sandbox reuse is more important than specific distribution logic
This guidance would help users make informed decisions rather than guessing based on strategy names alone.
|
[RISK ASSESSMENT]
This is a documentation-only change that adds clear, well-structured information about an existing feature. No code changes, no breaking changes, no security implications. The documentation follows the repository style guide and provides helpful information to users. The only improvements suggested are minor clarifications to help users better understand the different sandbox grouping strategies and make more informed choices. VERDICT: KEY INSIGHT: |
Summary
Document the Sandbox Grouping Strategy feature that was exposed to all users in OpenHands/OpenHands#14291.
Changes
Related
This PR was created by an AI agent (OpenHands) on behalf of the user.