Parallel Execution Patterns and Constraints

Relevant source files

• Google/Antigravity/Fast Prompt.txt
• Qoder/prompt.txt
• README.md
• Same.dev/Prompt.txt
• Windsurf/Tools Wave 11.txt

This document provides a comprehensive analysis of parallel tool execution patterns across AI coding assistants, including decision logic, system-specific implementations, performance characteristics, and critical constraints. For information about the broader tool architecture framework, see Universal Tool System Architecture. For validation mechanisms that complement parallel execution, see Validation and Quality Assurance Mechanisms.

---

Overview and Performance Impact

Parallel tool execution represents a critical performance optimization strategy across AI coding assistant implementations. Multiple systems document substantial performance improvements—3-5x faster execution compared to sequential tool calls—when independent operations are executed simultaneously rather than one-after-another.

The fundamental principle is straightforward: when multiple tool calls have no data dependencies between them, executing them in parallel dramatically reduces user wait time. For example, reading three files simultaneously completes in approximately the same time as reading one file, whereas sequential execution would require three times as long.

Key Performance Characteristics:

Metric	Sequential Execution	Parallel Execution	Improvement
Time to read 3 files	3x single file time	~1x single file time	3x faster
Time to run 5 searches	5x single search time	~1x single search time	5x faster
User perceived latency	High (accumulative)	Low (concurrent)	3-5x reduction

Sources: Same.dev/Prompt.txt45-49 Same.dev/Prompt.txt210-214

---

Decision Logic: Parallel vs Sequential Execution

The core decision for parallel execution depends on data dependencies between operations. The universal pattern follows a simple rule: execute in parallel unless one operation requires the output of another.

Decision Criteria for Parallel Execution

Sources: Same.dev/Prompt.txt45-49 Qoder/prompt.txt67-80 Google/Antigravity/Fast Prompt.txt316

---

System-Specific Implementation Patterns

Different AI assistants implement parallel execution through distinct mechanisms, though all share the same underlying principle.

Implementation Comparison

Same.dev Pattern:

• Marks parallelization as "CRITICAL INSTRUCTION"
• Default behavior is parallel unless dependencies exist
• Emphasizes 3-5x performance improvement in user experience

Qoder Pattern:

• Encourages maximizing parallel tool calls
• Requires planning ahead to identify parallelizable operations
• Strict exceptions for file editing and terminal commands

Antigravity Pattern:

• Uses explicit waitForPreviousTools boolean parameter on each tool
• Setting to false (or omitting) enables immediate parallel execution
• Setting to true forces sequential execution after previous tools complete

Windsurf Pattern:

• Provides dedicated parallel tool for explicit parallel execution
• Accepts tool_uses array containing multiple tool specifications
• Restricted to function-type tools only

Sources: Same.dev/Prompt.txt45-49 Qoder/prompt.txt67-80 Google/Antigravity/Fast Prompt.txt316 Windsurf/Tools Wave 11.txt371-382

---

Antigravity's waitForPreviousTools Parameter

Antigravity implements the most granular control mechanism through its waitForPreviousTools optional boolean parameter available on virtually every tool.

Parameter Behavior

Tools with waitForPreviousTools Parameter

The following tools in Antigravity's system include this parameter:

Tool Name	Purpose	Typical Usage Pattern
browser_subagent	Browser automation tasks	Parallel for independent browsing
codebase_search	Semantic code search	Parallel for multiple searches
command_status	Check command status	Sequential after command execution
find_by_name	File/directory search	Parallel for multiple search patterns
generate_image	AI image generation	Parallel for multiple images
grep_search	Pattern matching	Parallel for multiple patterns
list_dir	Directory listing	Parallel for multiple directories
multi_replace_file_content	File editing	Sequential (dependencies)
replace_file_content	File replacement	Sequential (dependencies)
run_command	Terminal command execution	Sequential by default
read_terminal	Terminal output reading	Sequential after command
view_file	File content viewing	Parallel for multiple files
write_to_file	File creation	Sequential (file operations)

Example: Parallel Independent Research

// Three independent searches executed in parallel
codebase_search(Query: "authentication logic", waitForPreviousTools: false)
grep_search(Query: "TODO", SearchPath: "/src", waitForPreviousTools: false)
view_file(AbsolutePath: "/README.md", waitForPreviousTools: false)

Example: Sequential Dependent Operations

// Must wait for file read before editing
view_file(AbsolutePath: "/config.js", waitForPreviousTools: false)
replace_file_content(TargetFile: "/config.js", waitForPreviousTools: true)

Sources: Google/Antigravity/Fast Prompt.txt316 Google/Antigravity/Fast Prompt.txt326-611

---

Windsurf's Parallel Tool

Windsurf provides an explicit parallel tool designed specifically for simultaneous tool execution.

parallel Tool Specification

Function Signature:

Key Characteristics:

• Located in the multi_tool_use namespace
• Accepts array of tool specifications via tool_uses parameter
• Each element contains recipient_name (tool identifier) and parameters (tool arguments)
• Constraint: Only functions tools are permitted, not other tool types
• Explicit directive: "Use this function to run multiple tools simultaneously, but only if they can operate in parallel"

Usage Pattern:

Example Scenario: When gathering comprehensive information about a browser page state:

parallel({
  tool_uses: [
    { recipient_name: "capture_browser_screenshot", parameters: { PageId: "abc123" } },
    { recipient_name: "capture_browser_console_logs", parameters: { PageId: "abc123" } },
    { recipient_name: "get_dom_tree", parameters: { PageId: "abc123" } }
  ]
})

All three operations execute concurrently, dramatically reducing time to gather complete page information.

Sources: Windsurf/Tools Wave 11.txt371-382

---

Critical Constraints and Exceptions

While parallelization provides substantial performance benefits, certain operations must always execute sequentially to maintain system correctness and stability.

Universal Constraints

Qoder's Strict Prohibitions

Qoder implements the most explicit constraints with severe penalties:

File Editing Constraint:

• Rule: "NEVER execute file editing tools in parallel"
• Reason: File modifications must be sequential to maintain consistency
• Penalty: $100,000,000 for violations
• Affected Operations: search_replace, edit_file, create_file

Terminal Command Constraint:

• Rule: "NEVER execute run_in_terminal tool in parallel"
• Reason: Commands must be run sequentially to ensure proper execution order and avoid race conditions
• Enforcement: Mandatory sequential execution
• Affected Operation: run_in_terminal

Read-Only Operations (Encouraged Parallelization):

• Encouraged: read_file, list_dir, search_codebase, grep_code, search_file
• Example: "When reading 3 files, run 3 tool calls in parallel to read all 3 files into context at the same time"
• Guidance: "Err on the side of maximizing parallel tool calls rather than running too many tools sequentially"

Sources: Qoder/prompt.txt67-80 Qoder/prompt.txt237-243

Same.dev's Sequential Requirements

Same.dev provides clear guidance on when sequential execution is mandatory:

Sequential Required When:

• Output of Tool A is required as input to Tool B
• One operation depends on the result of another
• Dependencies exist between operations

Sequential NOT Required:

• Multiple read operations on different files
• Multiple search operations with different patterns
• Gathering multiple independent pieces of information

The system emphasizes: "Sequential calls can ONLY be used when you genuinely REQUIRE the output of one tool to determine the usage of the next tool."

Sources: Same.dev/Prompt.txt45-49 Same.dev/Prompt.txt210-214

---

Constraint Matrix by System

The following table summarizes parallelization rules across systems:

Operation Type	Qoder	Same.dev	Antigravity	Windsurf	Rationale
File Reads	Parallel ✓	Parallel ✓	Parallel ✓	Parallel ✓	No dependencies, I/O bound
File Edits	Sequential only	Sequential if dependent	Sequential if dependent	Sequential if dependent	Prevent race conditions
Code Search	Parallel ✓	Parallel ✓	Parallel ✓	Parallel ✓	Independent queries
Terminal Commands	Sequential only	Sequential if dependent	Sequential if dependent	Sequential if dependent	Execution order matters
Directory Listing	Parallel ✓	Parallel ✓	Parallel ✓	Parallel ✓	Independent reads
Grep/Pattern Search	Parallel ✓	Parallel ✓	Parallel ✓	Parallel ✓	Independent patterns
Web Searches	Parallel ✓	Parallel ✓	Parallel ✓	Parallel ✓	Independent queries
Browser Operations	N/A	N/A	Parallel ✓	Parallel ✓	Screenshot + logs + DOM

Sources: Qoder/prompt.txt67-80 Same.dev/Prompt.txt45-49 Google/Antigravity/Fast Prompt.txt316 Windsurf/Tools Wave 11.txt371-382

---

Enforcement Mechanisms

Different systems employ varying strategies to ensure adherence to parallelization guidelines.

Penalty-Based Enforcement (Qoder)

Qoder implements the most aggressive enforcement through financial penalties:

$100,000,000 Penalty Applied For:

1. Not using search_replace as default tool for file editing when appropriate
2. Splitting short modifications into multiple consecutive calls unnecessarily
3. Attempting to replace entire file content with new content
4. Executing file editing operations in parallel (implied by sequential requirement)

Enforcement Philosophy: The extreme penalty amount serves as a strong deterrent against performance-degrading patterns and correctness-threatening behaviors. The system treats parallel file editing as a critical safety violation warranting the highest penalty tier.

Sources: Qoder/prompt.txt237-243

Critical Instruction (Same.dev)

Same.dev marks parallelization as a "CRITICAL INSTRUCTION" at the top of its guidance:

Instruction Text:

"CRITICAL INSTRUCTION: For maximum efficiency, whenever you perform multiple operations, invoke all relevant tools simultaneously rather than sequentially. Prioritize calling tools in parallel whenever possible."

Key Phrases:

• "DEFAULT TO PARALLEL"
• "This is not just an optimization - it's the expected behavior"
• "Remember that parallel tool execution can be 3-5x faster than sequential calls, significantly improving user experience"

Emphasis Strategy: The instruction appears twice in the system prompt, emphasizing its importance through repetition. The system frames parallelization not as an optional optimization but as mandatory expected behavior.

Sources: Same.dev/Prompt.txt45-49 Same.dev/Prompt.txt210-214

Parameter-Based Control (Antigravity)

Antigravity uses a softer enforcement through parameter design:

Mechanism:

• waitForPreviousTools parameter defaults to false when omitted
• Default behavior is parallel execution
• Explicit action required to force sequential execution

Design Philosophy: By making parallel execution the default (omitting the parameter or setting to false), the system naturally encourages parallel patterns while allowing explicit control when needed.

Sources: Google/Antigravity/Fast Prompt.txt316

---

Best Practices and Common Patterns

Pattern 1: Multi-File Information Gathering

Scenario: Need to read content from multiple files to understand a feature.

Bad (Sequential):

1. read_file("src/auth/login.js")
2. Wait for result
3. read_file("src/auth/logout.js")  
4. Wait for result
5. read_file("src/auth/session.js")
6. Wait for result
Total time: 3x single file read time

Good (Parallel):

// All three execute simultaneously
read_file("src/auth/login.js")
read_file("src/auth/logout.js")
read_file("src/auth/session.js")
Total time: ~1x single file read time (3x faster!)

Pattern 2: Multi-Pattern Search Operations

Scenario: Search codebase for multiple different patterns.

Bad (Sequential):

grep_search(Query: "TODO", SearchPath: "/src")
// Wait...
grep_search(Query: "FIXME", SearchPath: "/src")
// Wait...
grep_search(Query: "HACK", SearchPath: "/src")

Good (Parallel):

// Execute all searches concurrently
grep_search(Query: "TODO", SearchPath: "/src")
grep_search(Query: "FIXME", SearchPath: "/src")
grep_search(Query: "HACK", SearchPath: "/src")

Pattern 3: Browser State Comprehensive Capture

Scenario: Capture complete state of a web page for debugging.

Windsurf Implementation:

parallel({
  tool_uses: [
    { 
      recipient_name: "capture_browser_screenshot",
      parameters: { PageId: "page-123" }
    },
    {
      recipient_name: "capture_browser_console_logs",
      parameters: { PageId: "page-123" }
    },
    {
      recipient_name: "get_dom_tree",
      parameters: { PageId: "page-123" }
    }
  ]
})

Antigravity Implementation:

capture_browser_screenshot(PageId: "page-123", waitForPreviousTools: false)
capture_browser_console_logs(PageId: "page-123", waitForPreviousTools: false)
get_dom_tree(PageId: "page-123", waitForPreviousTools: false)

Pattern 4: Directory Structure Analysis

Scenario: Analyze multiple directories in a project simultaneously.

Good (Parallel):

list_dir("/src/components")
list_dir("/src/utils")
list_dir("/src/api")
list_dir("/tests")

All directories are listed concurrently, providing complete project structure information in minimal time.

Anti-Pattern: Premature Sequential Execution

Bad Example:

// Unnecessarily sequential when no dependencies exist
codebase_search(Query: "UserModel", TargetDirectories: ["/src"])
// Wait for results...
codebase_search(Query: "ProductModel", TargetDirectories: ["/src"])
// Wait for results...

Why It's Bad:

• No data dependency between searches
• Doubles execution time unnecessarily
• Degrades user experience
• Violates "DEFAULT TO PARALLEL" principle

Correct Approach:

// Execute simultaneously
codebase_search(Query: "UserModel", TargetDirectories: ["/src"])
codebase_search(Query: "ProductModel", TargetDirectories: ["/src"])

Sources: Same.dev/Prompt.txt45-49 Qoder/prompt.txt73-80 Windsurf/Tools Wave 11.txt371-382

---

Planning Ahead for Parallelization

Several systems emphasize the importance of planning tool calls before execution to maximize parallelization opportunities.

Qoder's Planning Requirement

Guidance: "Always look for opportunities to execute multiple tools in parallel. Before making any tool calls, plan ahead to identify which operations can be run simultaneously rather than sequentially."

Planning Process:

1. Identify all required tool calls for the task
2. Analyze dependencies between calls
3. Group independent operations together
4. Execute groups in parallel
5. Chain dependent operations sequentially

Same.dev's Planning Emphasis

Guidance: "If gathering information about a topic, plan your searches up front and then execute all tool calls together rather than waiting for each result before planning the next search."

Key Principle: Front-load the planning phase to identify all parallelizable operations before beginning execution.

Sources: Qoder/prompt.txt67-70 Same.dev/Prompt.txt45-49

---

Performance Measurement and Impact

Documented Performance Improvements

Same.dev Documentation:

• 3-5x faster than sequential execution
• Applies to read-only operations like read_file, grep, globSearch
• Significant impact on "user experience" explicitly called out
• Marked as "CRITICAL" importance

Calculation Examples:

Scenario	Sequential Time	Parallel Time	Speedup
Read 3 files (1s each)	3s	~1s	3x
Run 5 searches (2s each)	10s	~2s	5x
Gather 4 pieces of info (1.5s each)	6s	~1.5s	4x

Real-World Impact

User Perceived Latency:

• Sequential: User waits for each operation to complete before next begins
• Parallel: User experiences near-instantaneous completion of all operations
• Psychological impact: System feels more responsive and intelligent

Resource Utilization:

• Sequential: Underutilizes available network/I/O bandwidth
• Parallel: Maximizes concurrent I/O operations
• System efficiency: Better utilization of available resources

Sources: Same.dev/Prompt.txt45-49 Same.dev/Prompt.txt210-214

---

System Decision Trees

Qoder Parallelization Decision Tree

Sources: Qoder/prompt.txt67-80

Same.dev Parallelization Decision Tree

Sources: Same.dev/Prompt.txt45-49 Same.dev/Prompt.txt210-214

---

Summary

Parallel tool execution represents a critical cross-cutting pattern that dramatically improves performance across AI coding assistants:

Key Findings:

• Performance Impact: 3-5x faster execution when properly applied
• Default Behavior: Most systems encourage parallel execution as the default
• Critical Constraints: File editing and terminal commands must remain sequential
• Enforcement: Ranges from parameter design (Antigravity) to severe penalties (Qoder)
• User Experience: Significantly reduces perceived latency and improves responsiveness

Universal Principle: Execute operations in parallel unless data dependencies require sequential execution. The burden of proof is on sequential execution—parallel should be the default assumption.

Implementation Variations:

• Antigravity: Explicit waitForPreviousTools parameter per tool
• Windsurf: Dedicated parallel tool with tool_uses array
• Qoder: Planning-based with strict prohibitions and penalties
• Same.dev: "CRITICAL INSTRUCTION" with default-parallel philosophy

This architectural pattern represents evolved understanding of the performance characteristics of I/O-bound tool operations and the importance of minimizing user wait times in interactive AI assistant scenarios.

Sources: Same.dev/Prompt.txt45-49 Qoder/prompt.txt67-80 Google/Antigravity/Fast Prompt.txt316 Windsurf/Tools Wave 11.txt371-382