Automated research is usually framed as a reasoning problem: propose an idea, write code, inspect the result, and try again. But once an agent starts testing candidate algorithms, it becomes a compute problem too.
The model may already be using GPUs to think. That is fine: inference is the thinking compute. C3 is for the execution compute.
An agent can have a GPU in its head and still need a computer in front of it: somewhere to compile code, run benchmarks, launch simulations, call verifiers, train candidates, return logs, and hand artifacts back into the next step of the loop.
That is the execution layer C3 is built for.
The Loop
In an algorithm-discovery workflow, the agent can stay on a CPU machine or other cheap control node while model inference happens wherever the model is served. When the agent has a batch of candidates, it fans out the expensive experiment with C3, collects the artifacts, and uses the returned results to optimize the next batch.
The important boundary is simple:
- The agent proposes, mutates, reads logs, and decides what to try next.
- C3 runs the bursty shard jobs on GPU workers.
- Artifacts come back to the agent as the input for the next optimization round.
That lets automated research systems keep their reasoning loop responsive without keeping experiment GPUs attached while the agent is planning, editing, or inspecting results.
The Cost Shape
At AIDDA 2026, we tested this pattern in an automated-discovery experiment. Compared with assigning always-on GPU machines to agents, C3 reduced GPU cost by 18.54x by charging only while deployed GPU jobs were actually running.
The exact saving depends on the workload. If every second of the loop is dense GPU computation, there is less to save. But most agentic research loops are not that shape. They include planning, code edits, scheduling, log inspection, artifact parsing, scoring, and the next prompt. Those steps can run on cheaper compute while GPUs are reserved for the candidate evaluations that actually need them.
Try The Example
We built a small algorithm-discovery example that follows this pattern. It is intentionally tiny and CPU-only so it is easy to inspect, but it uses the same execution shape you would use for a real benchmark, verifier, simulation, GPU kernel, RL rollout, or model-training candidate.
git clone https://github.com/c3-research/c3-examples.git
cd c3-examples/algorithm-discovery-loop
python3 launch_shards.py --shards 3The free trial shape is a 3-chip burst. On Team, the same pattern can burst to 50 chips, subject to live capacity.
Run the algorithm-discovery loop example
For automated research, the useful abstraction is not "give every agent a GPU." It is "let agents ask for compute exactly when the experiment needs it, then hand the result back into the optimization loop."