Test
b2cebe1ba7
- Add LLMBatcher for grouping similar LLM requests - Automatic grouping by request type and model - Enqueue requests with optional result channels - Auto-flush on max batch size - Manual flush on demand - Time-based flush (max batch age) - Result delivery via channels - Batch status tracking and error handling - API cost reduction through request consolidation - 29 LLM batching tests, all passing Features: - Enqueue() for adding LLM requests - Flush() for manual batch creation - GetPendingBatch() for next batch - MarkBatchExecuting/Completed/Failed() - GroupByTypeAndModel() - automatic grouping - ResultDelivery() via channels - GetStats() for batching statistics - Token counting and tracking Performance Benefits: - 3 Implementer requests → 1 API call - N requests in M batches saves N-M API calls - Example: 30 requests in 3 batches saves 27 API calls (90% reduction) - Configurable batch size (default 10) - Configurable max age (default 2s) Grouping Strategy: - Requests grouped by (Type, Model) - Implementer + claude-opus → separate batch from Implementer + gpt-4 - Judge requests grouped separately from Implementer - Enables provider-specific optimizations Result Delivery: - Each request gets async result channel - Results delivered to channels on completion - Error results on batch failure - Non-blocking result delivery Statistics: - Total requests tracked - Total batches created - Average requests per batch - API calls saved calculation - Total tokens used - Total execution time Test Coverage: - 29 LLM batching tests (enqueue, flush, grouping, delivery) - Result delivery verification - Token counting tested - Auto-flush and manual flush - Error handling - Multi-type grouping - Concurrent safety (RWMutex) Next: T2.7 (Workflow history pruning)
20 lines
1.8 KiB
Markdown
20 lines
1.8 KiB
Markdown
# Task Board — Milestone T2: Scale & Performance
|
||
|
||
**Submilestone:** T2 (Distributed execution, caching, performance optimization)
|
||
|
||
| ID | Scope | Status | Branch | Verification |
|
||
|----|-------|--------|--------|--------------|
|
||
| T2.1 | Activity result caching: deduplicate repeated LLM calls for same task state | [x] | `task/T2.1` | Implementer called 2x on same code → second call returns cached Implementer output |
|
||
| T2.2 | Parallel task dispatch: multiple T0.x tasks execute truly concurrently (not sequential) | [x] | `task/T2.2` | 9 tasks complete in ~1/9 total time (wall-clock speedup measured) |
|
||
| T2.3 | Prompt template caching: pre-compile Go templates on worker startup | [x] | `task/T2.3` | Template render latency < 100ms (vs parse+render each time) |
|
||
| T2.4 | Lessons file indexing: fast lookup of past failures without full file scan | [x] | `task/T2.4` | Query lessons by task type → return in < 10ms for 1000s of entries |
|
||
| T2.5 | Git operation batching: combine multiple worktree commits into single push/merge | [x] | `task/T2.5` | N tasks → 1 push (vs N pushes), measured via git ref-log |
|
||
| T2.6 | LLM request batching: group similar Implementer calls into one API request | [x] | `task/T2.6` | 3 implementer tasks → 1 Anthropic API call with batch input (vs 3 separate calls) |
|
||
| T2.7 | Workflow history pruning: trim old task unit outputs from orchestrator history | [ ] | `task/T2.7` | Continue-as-new cycle history size constant despite 1000s of task units completed |
|
||
| T2.8 | Distributed lock optimization: replace flock with Redis/etcd for multi-pod scenarios | [ ] | `task/T2.8` | 5 concurrent orchestrators on different pods share FS safely via distributed lock |
|
||
|
||
---
|
||
|
||
## Submission Criteria
|
||
All T2.1–T2.8 marked `[x]` → submilestone complete → squash-merge `task/T2.*` to main.
|