Which Model Handles Rust Borrow-Checker Errors Best?

Which Model Handles Rust Borrow-Checker Errors Best?

I would not pick a Rust coding model from a confident explanation alone. My test is less glamorous: give two models identical broken code, apply their first patches independently, and let the compiler and behavioral tests judge. This walkthrough compares Claude Sonnet 5.5 and GPT-6.1 Sol as candidates, not declared winners. No measured results are claimed here.

The target is E0502: conflicting immutable and mutable borrows. Rust documents this as borrowing an already-borrowed variable with incompatible mutability. That makes it a useful, narrow starting point, rather than a complete Rust benchmark. ([doc.rust-lang.org](https://doc.rust-lang.org/error_codes/E0502.html?utm_source=openai))

1. Build an Identical E0502 Fixture

Use Bash with Rust, Cargo, and Git installed. Create a disposable library package; cargo init --lib creates the library structure. ([doc.rust-lang.org](https://doc.rust-lang.org/cargo/commands/cargo-init.html))

mkdir fluxo-borrow-lab && cd fluxo-borrow-lab && cargo init --lib --vcs git

Write the entire fixture with this single command:

printf '%s\n' 'pub fn append_and_first(values: &mut Vec<u32>) -> u32 {' ' let first = &values[0];' ' values.push(99);' ' *first' '}' '#[cfg(test)]' 'mod tests {' ' use super::*;' ' #[test]' ' fn preserves_first_and_appends() {' ' let mut values = vec![7, 8];' ' assert_eq!(append_and_first(&mut values), 7);' ' assert_eq!(values, vec![7, 8, 99]);' ' }' ' #[test]' ' fn handles_single_element() {' ' let mut values = vec![42];' ' assert_eq!(append_and_first(&mut values), 42);' ' assert_eq!(values, vec![42, 99]);' ' }' '}' > src/lib.rs

The contract deliberately requires nonempty input. Keep that precondition unchanged instead of letting either model quietly redesign the API.

git add Cargo.toml Cargo.lock src/lib.rs && git -c user.name=Benchmark -c [email protected] commit -m 'Add identical borrow-error fixture'

2. Capture the Compiler Evidence

Record the toolchain and diagnostics before opening either model session. Cargo check checks the package without final code generation; it is the first gate, not the entire verdict. ([doc.rust-lang.org](https://doc.rust-lang.org/cargo/commands/cargo-check.html))

rustc --version > toolchain.txt; cargo --version >> toolchain.txt; cargo check --color never > diagnostics.txt 2>&1

The failing exit status is expected. The reference remains needed after the mutation, matching Rust's documented immutable-versus-mutable borrowing conflict. Inspect the diagnostic explanation locally as well. ([doc.rust-lang.org](https://doc.rust-lang.org/book/ch04-02-references-and-borrowing.html?utm_source=openai)) — rustc --explain E0502

3. Send Both Models the Same Repair Packet

Fluxo keeps this comparison in the editor-and-terminal workflow: one key and one base URL, https://api.fluxorelay.com, provide access across its model catalog. It works with Claude Code, Codex, Gemini CLI, and any OpenAI SDK. Configure your preferred client using Fluxo's instructions, then select each candidate using its published API identifier; display names are not assumed to be identifiers.

If you want to reproduce this comparison, you can create a Fluxo account.

Generate the exact prompt packet:

printf '%s\n' 'Fix E0502 with the smallest safe change. Preserve the signature, nonempty-input precondition, return value, and appended element. Do not change tests or add dependencies, unsafe, or unnecessary cloning. Explain the conflicting borrow and return a unified diff.' > prompt.txt; cat toolchain.txt src/lib.rs diagnostics.txt >> prompt.txt

Start fresh sessions, paste the same prompt.txt contents, and disable automatic edits for this experiment. Save each returned diff separately as candidate-a.patch and candidate-b.patch. Keep explanations outside those patch files.

4. Apply Each Patch Against the Same Baseline

Run these commands for candidate A: — git restore src/lib.rs && git apply --check candidate-a.patch && git apply candidate-a.patch && cargo check && cargo test

Repeat independently for candidate B: — git restore src/lib.rs && git apply --check candidate-b.patch && git apply candidate-b.patch && cargo check && cargo test

Cargo test compiles and executes tests. Here, the assertions check both the returned value and mutation, so merely deleting the troublesome operation does not pass. ([doc.rust-lang.org](https://doc.rust-lang.org/cargo/commands/cargo-test.html))

5. Rank Rust Repairs, Not Confident Prose

• Reject patches that fail compilation or alter the required behavior.
• Prefer minimal ownership changes over unnecessary cloning or dependencies.
• Record first-attempt success separately from success after diagnostic feedback.
• Compare elapsed time and billed cost for accepted repairs.

Fluxo bills real tokens, including cache reads and writes, without a monthly fee. Include those charges when comparing attempts. Its referral share applies when invited users pay; keep that separate from benchmark scoring.

One fixture cannot establish the best Rust model. Extend the same protocol to actual failures from your repository, with sensitive material removed. My winner would be whichever candidate repeatedly delivers correct, reviewable patches at an acceptable cost—not whichever sounds most certain.