symbiont.rs — Agent harness for hot-reloadable function evolution in Rust

Quick Start

symbiont::evolvable! {
    fn step(counter: &mut usize) {
        // Default body will be entrely evolved by the Agent
        *counter += 1;
        println!("doing stuff in iteration {}", counter);
    }
}

#[tokio::main]
async fn main() -> symbiont::Result<()> {
    let runtime = symbiont::Runtime::init(SYMBIONT_DECLS).await?;
    let agent = symbiont::inference::init_agent()?;
    let fn_sigs = runtime.fn_sigs();
    let prompt = format!(
        "Give a concise implementation for this function signature: ```{}```, \
        that increments the counter by a constant in the range (5..20). \
        Give Rust Code Only.",
        fn_sigs[0]
    );

    let mut counter = 0;
    loop {
        step(&mut counter);  // bare-metal: native dylib call
        println!("counter: {counter}");

        // LLM rewrites the fn, harness validates + compiles + hot-swaps
        runtime.evolve(&agent, &prompt).await?;
        // `step` function was updated and new Agent code runs in the next loop iteration
    }
}

Similar code to the above can be run with cargo run --bin counter-example in the repo to showcase the function evolution.
Here the function is evolved every 5 seconds.

Now that you grok the core concept, a whole new world of opportunity opens up...

Showcase: Fractal Studio

An interactive window whose per-pixel shader is written by the LLM and hot-swapped into the running binary as optimized native code. Type a prompt — "an animated Julia set, c orbiting the main cardioid, with a glowing sunset palette" — and the agent implements fn shade(x: f64, y: f64, t: f64) -> u32; the live animation morphs in place, no restart.

shade is called once per pixel (~0.5M calls/frame), parallelized over all cores — an interpreted agent-code loop would be orders of magnitude too slow to animate.
The user is the evaluator: the runtime keeps the chat history, so follow-up prompts refine the current shader.
Agent code panics are caught inside the dylib (rendered as black pixels) and fed back into the next evolution prompt.

Explore the fractal-studio example →

Showcase: Batched Evolution

evolve_batch runs one lane per prompt, concurrently — thirty-two slightly different prompts, thirty-two independent retry budgets, thirty-two candidate implementations. Against a server that batches (vLLM, SGLang, llama-server --parallel n) the lanes merge into shared forward passes, so a whole population round costs a fraction of the same evolutions run in a loop.

Population round

41s

32 candidates — 407s one at a time

Decode throughput

9.1×

72 → 656 tok/s, still climbing at 32 lanes

Prefix cache

74–76%

of prompt tokens, shared across every lane

Decode throughput by concurrency tokens/second, Bonsai-8B on vLLM, RTX PRO 6000 Blackwell

Measured data

Lanes in flight	Wall	Decode tok/s	Lanes converged
1	407.1s	72	18/32
2	679.6s	88	18/32
4	149.8s	196	18/32
8	102.3s	300	16/32
16	57.2s	475	16/32
32	40.8s	656	17/32

The 2-lane row is an outlier: it drew a set of lanes that ground through their full retry budgets and generated twice the tokens of every other level. Retries within a lane are sequential, so they lengthen that lane's critical path — and a level's wall clock is its slowest lane.

A batch registers every candidate but activates none. A pile of implementations with no fitness signal between them is not a hill to climb — you evaluate them through pinned RevisionFn handles and commit to a winner with activate_revision.
Because nothing is published, a batch is exempt from the feedback-loop contract: generation of the next round can overlap evaluation of the current one.
Each lane owns its retry budget and chat history. A lane that answers with prose ten times fails alone; its siblings neither see the corrections nor lose budget to them.
Candidates that come back byte-identical share one revision instead of each spending a cargo build.

Explore the batched-evolution example →

Core Highlights

Type-safe agentic code

LLms express intent as Rust functions with enforced signatures. The compiler is the guardrail.

Constrained generation

Parse errors, signature mismatches, and compiler diagnostics steer the LLM until it produces valid code.

Hot-swap dylibs

Functions compile to native shared libraries and swap in-place via libloading — no process restart.

Bare-metal performance

~1 ns dispatch overhead. Lock-free hot path via AtomicPtr. Multi-thread safe.

Batched evolution

One lane per prompt, run concurrently and merged into shared forward passes by the inference server. A whole population per round, for a fraction of the wall clock.