When to use this profile
Use this recipe for Go agents that implement a change and validate it with the package test suite. Download modules during preparation, then run the build and test loop without broad network access. Pure Go projects need fewer system dependencies than projects using CGO, so determine that requirement before choosing the image.
Prepare a repeatable environment
- Pin the Go toolchain version and preserve go.mod and go.sum.
- Download modules from an approved proxy before the edit loop.
- Install the C compiler and required libraries only if the project uses CGO.
go test -p 2 ./...Return results the agent can use
- go test output or structured JSON from go test -json.
- A source patch with formatting applied.
- Build artifacts with the target operating system and architecture recorded.
Compile and test a small module offline after module download. Repeat with a CGO fixture if required, and verify failures preserve their exit status.
Resources and boundaries
Start with 4 vCPU and 4 GB of RAM, then measure peak memory and task duration on a representative fixture. These are workload planning values, not a benchmark or a provisioned configuration. Use the sandbox cost calculator to estimate running time and retained snapshots.
- The race detector increases runtime and memory demand; budget it separately.
- Integration tests can contact databases or APIs; run them against disposable fixtures.
- Limit package parallelism and GOMAXPROCS to the resources allocated to the task.
Keep model inference separate from this execution profile. A hosted model or gpuOS can decide the next action while the CPU environment runs it. The quickstart describes the account workflow and the proposed runtime contract.