At some point, upstream moves. Then you run git rebase or git merge, and suddenly your nice isolated change is becomes a merge conflicts mess.

Sometimes this is manageable. A nearby function changed. A file moved. Someone renamed a type. Easy enough. You spend a few minutes fixing things, run the tests again, and move on.

Sometimes it’s super annoying and time consuming.

The maintainer reformatted the entire project. Or reorganized every module. Or rewrote internal structures your change depends on. Now your fork isn’t really a fork any more. It’s an archaeology project.

This is painful.

It’s not just boring mechanical work. It’s also risky work. The version you originally wrote was tested against a specific upstream state. You understood the code around it. You probably had a coherent reason for every line.

But after three painful rebases, the goal quietly changes.

You’re no longer trying to preserve the quality of the original change. You’re just trying to make the damn thing compile again. You’re trying to make tests pass again. You’re trying not to lose your mind while resolving the same conceptual conflict in five slightly different files.

And boom, bugs and vulnerabilities that didn’t originally exist get introduced. The quality of the fork degrades after every rebase.

The annoying part is that this used to be relatively rare.

Big, sweeping upstream changes happened, but they cost real human time. A maintainer had to decide that a massive refactor was worth the pain. They had to do the work. So most projects had some natural friction.

But AI removes a lot of that friction. Prompting is all you need.

Cheap experimentation is useful. But it also changes the shape of commits.

In vibe-coded projects, individual commits tend to be large. Way larger than regular commits traditionally made by humans. A single prompt often produces a diff that touches a lot of surface. The maintainer looks at the result, runs the tests, likes the direction, and commits it. Single commit, large changes.

The cost of producing that diff was tiny. The cost of everyone else integrating with it was not.

A large AI-generated refactor may be cheap for the person pressing enter, but it can be extremely expensive for anybody maintaining local changes, a downstream patch set, or a long-running pull request.

The project didn’t just change behavior. It changed shape.

And forks depend on shape.

A fork isn’t only a copy of code. It’s a set of assumptions about where things live, how functions are split, which internal boundaries are stable enough to build on, and which files can be changed without touching the rest of the world.

When every other upstream commit reshuffles that shape, the fork loses its anchor. This is especially bad for changes that are important but not immediately mergeable.

Maybe the maintainer agrees with the idea but wants a different API. Maybe the change needs more testing. Maybe it’s useful for one deployment but too specific for upstream. Maybe the project moves slowly on review because everybody is busy.

And if the upstream project is constantly being rewritten by prompts, the window for a sane merge gets much smaller. Either your work lands quickly, or it starts rotting immediately. Not because the logic became wrong. Because the surrounding code was churned into another shape.

After a while, maintaining the fork becomes virtually impossible.

You can stop updating from upstream, which means the fork slowly becomes its own project.

You can keep rebasing, which means spending more and more time repairing damage caused by unrelated global edits.

Or you can give up and ask an AI to generate your own competing version from scratch.

That last option sucks, but it’s exactly where the incentives point. If upstream treats code as disposable text that can be globally regenerated whenever the mood changes, downstream users will eventually treat upstream the same way.

Why maintain a careful fork of something that refuses to keep a stable shape?

There’s a difference between intentional large changes and casual churn.

A human refactor usually carries some scar tissue. You can see the maintainer trying to minimize damage. The diff has boundaries. The commit message explains why this had to happen. Compatibility layers appear. Old paths survive for a while. Reviewers ask whether this will hurt downstream users.

AI slop doesn’t naturally care about any of that.

It optimizes for satisfying the prompt in the current checkout. It doesn’t know which patch series exists in someone’s fork. It doesn’t care that a small function rename creates conflicts in ten open pull requests. It doesn’t feel the social cost of making everybody else redo work.

That’s why I don’t even bother contributing to vibe-coded projects anymore.

Forkability is (was?) a project quality. AI makes it easier than ever to destroy it.

But I had to push to someone else’s pull request today, and I couldn’t do it without asking an LLM, and it even didn’t do what I wanted. Yay, that’s embarrassing.

To modify files already changed by the PR, this is trivial and can be done directly through the GitHub UI. But if additional files need to be modified, some local Git command magic is required.

So this is the reference I wish I’d had open in a tab.

Find the source branch

gh pr view 42 --repo user/project \
  --json headRepository,headRefName,isCrossRepository

You need two things from that output: the repository that owns the PR branch, and the branch name.

If the PR came from the same repository, the branch lives on origin.

If the PR came from a fork, the branch lives on the fork. origin is still the upstream repository. Pushing to origin some-local-name:their-branch will create or update a branch in the upstream repository, not in the contributor’s fork.

Fetch the PR

pull/<pr-number>/head:<pr-branch-name> as the remote branch name is the key.

git fetch origin pull/42/head:pr-42
git switch pr-42

Now make your edits and commit them normally.

Push to the source branch

For a PR branch in the same repository:

git push origin HEAD:their-branch

For a PR branch in a fork:

git push git@github.com:contributor/project.git HEAD:their-branch

You can add the fork as a remote if you prefer:

git remote add contributor git@github.com:contributor/project.git
git push contributor HEAD:their-branch

The important part is the destination repository. The left side is your local branch or commit. The right side is the branch that GitHub is using as the pull request’s head.

Refuse to force push

After a while, you may want to squash commits and force push. Be careful.

git fetch git@github.com:contributor/project.git their-branch
git merge-base --is-ancestor FETCH_HEAD HEAD \
  && echo "fast-forward ok"

If it isn’t a fast-forward, stop. A force push would silently delete the author’s commits. Talk to them first.

Hope this helps.

It was a personal experiment, on a non-default Git branch, not announced anywhere.

That didn’t matter. Rust advocates popped champagne. Zig people were shocked. Actual Bun users got confused. Everybody fought like kids in a kindergarten playground.

Jarred Sumner has issues with Bun. Maybe the root cause is original technical decisions rather than anything inherent to Zig. Maybe moving to another language could help with some of them. Maybe not. But trying is not insane.

Rewriting software is often a good way to revisit how the code works, remove technical debt, and produce something better. Especially when the mature shape of the product is already known. You don’t have to rediscover every edge case, every awkward feature, and every hack that got added because the original design didn’t anticipate reality.

Rewriting Bun would still be a significant task.

But despite everybody talking about a Bun rewrite, that was not really the plan.

The plan looked more like this:

1. Transpile the Zig code to Rust. Every file, function, and structure should remain as close as possible to the original, so that a Zig file and its Rust equivalent are functionally interchangeable.
2. Incrementally tweak, rewrite, and refactor individual functions and types until the code becomes idiomatic, maintainable Rust.
3. Eventually, get a Rust rewrite.

Bun completed phase 1 only.

This is transpiled code. Automatically transpiled code. Since there are no Zig-to-Rust transpilers, Jarred used an AI prompt.

And it worked.

As in: the tests passed.

And that is not very surprising. LLMs are good at translating text, and code is text with a lot of structure. If you give them a large test suite to keep them from going off the rails, this kind of mechanical translation is exactly the sort of thing they can do well.

Anthropic can use it to show off Claude, but most coding models could probably do something similar with the right instructions.

The resulting Rust code was of poor quality.

Of course it was.

An experienced Rust developer would not accept code like that in their own project. And obviously, it was mocked, including by Rust advocates who had originally rejoiced at the idea of Bun being “rewritten” in Rust.

But idiomatic Rust was not the goal at that point.

Phase 1 was meant to be a literal, direct translation of the Zig code. In that context, Rust is almost an intermediate representation. The source of truth is still Zig. The Rust output is there to see whether the translation pipeline can preserve behavior before anyone starts improving the result.

Phase 1 was not about producing beautiful Rust.

It was about answering a narrow question: can a large Zig code base be translated automatically, with enough fidelity for the test suite to pass?

Apparently, yes.

With AI, that is a simple experiment to run. It is quick. It is cheap when you don’t pay for tokens. Failure is acceptable because it doesn’t require much commitment. That is exactly why Jarred described it as an experiment.

From the outside, though, the story looked very different.

People saw a leaked intention to do something controversial. Then they saw the controversial thing materialize. Then they saw horrific-looking generated Rust. In a few days, Bun went from a tool people trusted and used in production to, in their minds, a tool being blindly rewritten by AI with minimal quality control.

So they panicked.

Here is the uncomfortable part: the root cause of the drama may be that Jarred acted transparently.

He could have kept the Rust branch private until phase 3 was complete. And if the experiment failed, he could have never mentioned it.

Then, much later, he could have announced a new Bun version, actually rewritten in Rust, with code everyone agreed was good and stability numbers better than the original implementation.

Language advocates would still have fought. Of course. But actual users would mostly have judged the result.

Does it work? Is it reliable? Is the new version better than the previous one?

If yes, cool. If no, that is a good reason to leave.

Most users do not really care how software is built. They care whether the tool they rely on keeps working.

But Jarred did not do the safe corporate thing. He worked in the open, including the earliest and ugliest part of the experiment.

And that backfired.

Unfortunately, this is a common open source problem.

Maintainers need to experiment. That is a normal part of working on a project. It is fine to write unfinished, ugly, unsafe, half-broken code while exploring an idea. It is also convenient to push these branches to GitHub.

Yes, alternatives exist. But if you work from multiple devices, or want to share the branch with one person, pushing it to the same remote as everything else is by far the easiest workflow. Anything else adds friction.

The problem is that every bit pushed to a public repository becomes material for interpretation.

People will look at it. They will judge it. They will assign intent to it. They will write the missing context themselves, usually in the least charitable way possible.

If a project is open source, maintainers are somehow expected to make every public commit look clean, coherent, and strategically final.

That is absurd.

It also changes behavior. The more popular a project becomes, the less freedom maintainers have to think in public. A random branch stops being a scratchpad and becomes a press release. A quick experiment becomes a roadmap. A bad intermediate result becomes proof that the project has lost its mind.

So maintainers learn the obvious lesson: hide the messy parts.

That is bad for everyone.

The lesson for Bun is not that AI rewrites are good. It is not that Rust would fix Bun. It is not that Zig is the problem. None of that is proven by this experiment.

The lesson is that public development and public experimentation are not the same thing.

Users want transparency, but they also punish unfinished work. Maintainers want openness, but they also need private space to try stupid ideas before deciding whether they are stupid.

For large projects, maybe the practical answer is boring: keep experiments private until they have enough context to be understood, or label them so aggressively that nobody can pretend they are production plans.

That is less romantic than developing everything in the open.

But if every ugly branch becomes drama, more maintainers will stop showing ugly branches.

And then everybody will complain that open source became less open.

That warning is good. But the documentation also says something stronger: “because aHash is keyed, hashes cannot be predicted without knowing the keys”. That is not true.

For a hash table, keyed hashing usually means something much more modest. It means an attacker should not be able to precompute one pile of colliding keys and reuse it against every process on the internet. Per-map randomization is a practical defense against boring collision-flooding attacks.

But “cannot be predicted without knowing the keys” sounds like a keyed random function. It sounds PRF-like. It suggests that even after seeing hashes for inputs I choose, I still cannot predict the hash of a fresh input.

That is a much higher bar, and aHash does not clear it.

The construction is not AES

The usual fast path uses AES instructions. That detail is easy to overread.

Using AES round instructions does not make the whole construction AES, any more than using xor makes a protocol a stream cipher. The surrounding construction still has to absorb inputs safely, separate domains, and finalize with enough mixing for the security claim being made.

aHash state keeps three 128-bit values:

enc
sum
key

The basic block update is roughly:

enc = aesdec(enc, block)
sum = shuffle_and_add(sum, block)

Then finish() combines the state with a small number of AES instructions and returns 64 bits.

This is a good shape for a fast hash-table hasher. It is not AES-CMAC. It is not AES as a block cipher. It is not a standard PRF construction.

And in practice, it leaks simple key-independent relations between outputs.

aHash doesn’t securely hash transcripts

The Rust Hasher trait exposes several ways to feed data:

write(&[u8])
write_u8(...)
write_u64(...)
write_u128(...)

In aHash, the integer methods collapse into the same internal operation:

write_u8(i)   -> write_u64(i as u64)
write_u16(i)  -> write_u64(i as u64)
write_u32(i)  -> write_u64(i as u64)
write_u64(i)  -> write_u128(i as u128)
write_u128(i) -> hash_in(i)

So these are different public transcripts:

write_u8(0xab)
write_u16(0xab)
write_u32(0xab)
write_u64(0xab)
write_u128(0xab)

But they all become:

hash_in(0xab)

For every key, they produce the same final hash. There’s no context separation. Developers may not expect this.

There’s a more surprising one:

write(&[])
write_u128(0)

For non-empty byte strings, aHash adds the input length before absorbing bytes. For the empty string, it writes zero directly. The typed u128 path also hashes zero directly.

So two very different transcripts can produce the same hash, independently from the key.

That being said, the Hasher trait doesn’t really define how inputs are supposed to be handled. Being type-safe for hashing transcripts is an option, concactenating everything is another option, but anything else is technically valid as well, even if it is prone to misuse.

An integral distinguisher

Consider u128 inputs constructed that way:

X[a,b] = (a << 56) | (b << 120)

a and b each range from 0x00 to 0xff.

So these are 128-bit values where byte 7 and byte 15 vary over every possible value, and all other bytes are zero.

Now, consider every query:

h.write_u128(X[a,b])
h.finish()

That gives 65,536 different typed inputs. Their 64-bit outputs have a zero XOR sum for any key.

Again, that is not how a PRF from u128 inputs to 64-bit outputs behaves. For independent random outputs, the XOR should be zero with probability 2^-64. In aHash, it is zero every time.

The reason is that write_u128() feeds the value directly into hash_in(), and these byte positions create a balanced set through the reduced AES-based finalization. The key changes the individual hashes. It does not change the XOR relation.

This also makes the output predictable. Leave out one X[a,b], query the other 65,535 values, XOR their outputs, and the result is the missing output.

Here is a trivial PoC:

use aHash::RandomState;
use std::hash::{BuildHasher, Hasher};

fn hash_u128(state: &RandomState, x: u128) -> u64 {
    let mut h = state.build_hasher();
    h.write_u128(x);
    h.finish()
}

fn main() {
    let state = RandomState::with_seeds(1, 2, 3, 4);
    let mut xor = 0u64;
    for a in 0u8..=255 {
        for b in 0u8..=255 {
            let x = ((a as u128) << 56) | ((b as u128) << 120);
            xor ^= hash_u128(&state, x);
        }
    }
    assert_eq!(xor, 0);
    println!("xor {xor:016x}");
}

This prints:

xor 0000000000000000

Of course, typed u128 inputs are still easy to wave away. Many real keys are strings or byte slices. But they are affected by the same issue.

Transposing the distinguisher to strings

Consider this family of 16-byte strings:

S[a,b] = 00 00 00 00 00 00 00 aa 00 00 00 00 00 00 00 bb

a and b each range from 0x00 to 0xff.

That gives 65,536 different non-empty byte strings. No typed integer writes. No empty input. No repeated input. No weird transcript ambiguity.

For each string, do the ordinary thing:

h.write(&S[a,b])
h.finish()

The XOR of all 65,536 outputs is always zero, for any key.

That should not happen for a real PRF. For 65,536 independent 64-bit outputs, the XOR would be zero with probability 2^-64. Here, it happens every time.

The reason is that the varying bytes are placed as the high bytes of the two 64-bit lanes consumed by the 16-byte byte-slice path. Those positions avoid carry trouble in the lane additions, so the chosen set stays balanced before it reaches the reduced AES-based finalization. The key changes the individual outputs. It does not remove the relation.

This is the same kind of balanced-set behavior behind square/integral attacks on AES-like constructions, showing through a construction that uses too little AES-style mixing to hide it.

Pick a target:

T = S[0x42, 0xa5]

Now hash the other 65,535 strings in the family, but not T. XOR their outputs together.

The result is exactly the missing output:

prediction = xor_{(a,b) != (0x42,0xa5)} aHash_k(S[a,b])
prediction = aHash_k(T)

No key recovery. No brute force. Just a key-independent relation.

Another quick PoC

use aHash::RandomState;
use std::hash::{BuildHasher, Hasher};

fn hash(state: &RandomState, bytes: &[u8]) -> u64 {
    let mut h = state.build_hasher();
    h.write(bytes);
    h.finish()
}

fn main() {
    let state = RandomState::with_seeds(1, 2, 3, 4);
    let target = (0x42, 0xa5);
    let mut prediction = 0u64;
    let mut actual = 0u64;
    let mut s = [0u8; 16];
    for a in 0u8..=255 {
        for b in 0u8..=255 {
            s[7] = a;
            s[15] = b;
            let out = hash(&state, &s);
            if (s[7], s[15]) == target {
                actual = out;
            } else {
                prediction ^= out;
            }
        }
    }
    assert_eq!(prediction, actual);
    println!("predicted {prediction:016x}");
}

This prints:

predicted 2929121e3dfcdd2a

The exact value is not the point. The assertion is. The program never adds the target hash to prediction. It only hashes the other 65,535 strings.

What this proves

This does not prove that aHash is useless.

It does not give a giant collision set. It does not recover the key. It does not immediately produce a practical HashMap denial-of-service attack. It does not mean every application using aHash is broken.

Hash-table hashers are not MACs. They are judged by different criteria: speed, distribution, and enough randomization to make precomputed collision attacks unattractive.

But aHash is not a PRF-like keyed hash over byte strings. Some outputs are algebraically related. One output in this family can be predicted exactly from the others without knowing the key.

That is incompatible with the strong reading of “cannot be predicted without knowing the keys”.

aHash can still be a perfectly reasonable fast hash-table hasher as long as the output remains secret. The crate is also right to say that it is not cryptographically secure.

But do not use it as a MAC. Do not use it as a cryptographic keyed hash. Do not use it as a PRF. Do not use its output as randomness. Be careful with non-cryptographic designs such as sharded routing if an adversary gets to choose inputs and observe outputs.

People are going to ask the obvious question.

Why build a new agent when Codex, Claude Code and Opencode already exist, are well established, and already look good enough for most people?

Because I wanted an agent that fixes the things existing agents still get wrong in actual daily use.

Privacy, local models, and not leaking secrets to a provider

Current agents are built around genuinely incredible models.

But I still don’t trust companies such as Anthropics with my data. For open source work, fine. For closed-source work, or anything sensitive or personal, I think the default posture of most current tools just isn’t acceptable.

Using an AI agent inevitably leaks internal information. Sometimes a lot of it.

That includes access tokens, internal project names, URLs, company names, and all the little bits of context that look harmless until they aren’t.

Mitigating that risk is something I have cared about for a long time. I even gave a Zigtoberfest talk about that exact topic.

So I wanted an agent that does two things properly.

First, it needs mitigations for leaking secrets to providers.

That means transparently encrypting secrets before sending them to providers, then decrypting them locally so that models can still reason about them without actually seeing them. And it means being able to block and redact specific strings such as internal project names, company names and URLs.

The fact that current agents, including the ones heavily used by corporations, still don’t ship these features is, to me, irresponsible and unacceptable.

Swival has transparent secret encryption and outbound LLM filters specifically to reduce how much information leaves your machine.

Second, it needs to work well with open source models. Not as a checkbox. Actually well.

Local models have predictable behavior and predictable cost. They don’t suddenly get worse because a provider changed something. They don’t suddenly get more expensive because pricing moved. You control them, not a third party.

And of course, they also don’t leak sensitive data to anyone.

Open source models are getting good fast. Gemma 4, Qwen 3.6, and GLM-5.1 make that pretty obvious. Plenty of exciting models are uploaded to Hugging Face every day.

At the same time, efficient local inference is turning into a basic requirement for modern devices, and it’s only going to improve. Apple M5 chips are a good illustration of where this is going.

No, local models aren’t a replacement for everything. But they’re already good enough for a lot of work, they have a bright future, and they can be fine-tuned.

Even modern small models have surprisingly strong agentic capabilities.

The frustrating part is that most agents are still optimized and tested mainly for frontier models. Even the ones that advertise support for many providers and local models usually behave badly with local models. Tools are used poorly. Context is managed poorly. Everything gets slower. Output quality gets unreliable. Then people blame the model instead of the tool.

I wanted an agent that performs well with any model. From large frontier models all the way down to small local models with a small context window that anyone can run on their own machine.

And if it fails, I want the first instinct to be improving the agent so that it helps the model deliver as much as it can, not immediately declaring the model useless.

That’s one of the main reasons Swival isn’t just for frontier models. A lot of that comes from excellent context management.

Swival has a /compact command. But in practice, it’s rarely needed, if at all. The agent keeps trying to deliver regardless of the constraints, and the context window isn’t something you should have to babysit during a long session.

And when I want to test new models, there’s nothing more convenient than HuggingFace CPU-less inference. So I wanted that to be trivial as well.

With Swival, it’s as easy as:

swival --provider huggingface --model zai-org/GLM-5.1

Agent-to-Agent is too useful to remain niche

The A2A protocol is great.

People who actually use it know how powerful it is, and they usually don’t want to go back to a single isolated agent.

Unfortunately, for most people, A2A is still one of these things they have vaguely heard about but never really use, mostly because mainstream tools such as Claude Code still don’t support it.

That’s a shame, because A2A changes what an agent can be.

With A2A, you can run multiple agents with different configurations and different models, and let tasks naturally reach for the right one.

So instead of stuffing documentation and skills into one local agent, you can have a dedicated documentation agent with direct access to the material, while other agents don’t need to carry all of that context.

Then, when an agent needs to know how to do something, it asks the documentation agent to research it and return a concise, accurate answer instead of dumping blind grep results.

And of course, that specialized documentation agent can run a small, cheap, local model.

That’s the larger idea. Don’t restrict yourself to one model, or even a tiny set of related models. Use as many models as you want, including open source ones, depending on what needs to be done.

I wanted A2A to be simple enough that people would actually use it.

Swival comes with built-in support for A2A and can act both as a server and as a client.

You can set up a network of specialized agents in minutes.

Open source, readable, powerful, and not a circus

Existing agents have become ridiculously bloated over time.

Claude Code is enormous. It flickers. It crashes. New versions keep adding gadgets I don’t care about while making the whole thing even heavier.

I don’t want a kitchen sink. I want a small, reliable tool.

Swival is lean, fully open source, doesn’t depend on any company, and isn’t optimized around a specific provider. It’s totally free and open, and has nothing to sell.

It’s written in Python because Python is simple, readable and maintainable. Nothing is obfuscated. Anyone can read the code, understand it, and modify it for their own needs.

And this isn’t a toy. It’s a workhorse. A boring one, which is exactly what I want here.

It focuses on the tools a developer actually needs, not on gimmicks. But it still has the features you would expect from a modern agent, and then some.

Benchmarking needs a real environment

I also wanted to run benchmarks.

I wanted a tool to evaluate models, settings, skills, MCP servers, and similar pieces on real-world tasks, in an environment that actually resembles how a user works.

A lot of benchmarking tools aren’t designed that way.

They either assume tools optimized for specific models, or they provide an environment that doesn’t feel much like the real thing.

And if you want to learn anything useful from evaluations, you need traces. Detailed ones. Accurate ones.

You need to be able to look at what happened and understand how a model behaved under different conditions.

Swival comes with strong reporting features. Combined with calibra, you can compare traces, diff them, and run evaluations that are actually meaningful.

Evaluating many configurations can burn through a lot of tokens.

That’s yet another reason I cared so much about making the agent work well with open source models running locally. For evaluations, cost is often more important than wall-clock speed.

LLMs fail on the first try

The real problem is that models produce terrible code and then confidently tell you everything is fine.

Watching a model generate code is impressive. It’s hard not to be impressed when you type a prompt and a feature, or sometimes a whole project, appears in one shot.

And the final report is always soothing. Everything is done. Everything works.

Of course.

The reality is that AI-generated code is almost always poor quality.

It may compile. It may appear to work. But from a correctness perspective, it’s often terrible.

You may be very happy with the code generated by Claude Code with Opus 4.6 max pro high thinking max, and maybe even want to deploy it to production, merge it into open source projects, or write triumphant blog posts about it.

But there’s a good chance that the code is inefficient, buggy, hard to maintain, and going to cost you later.

There’s a trivial experiment anyone can try.

Ask your favorite agent to generate code, or even just a plan.

Then, in a separate environment, ask another AI agent, even one running the same model, to review that code or plan.

It’s very likely to find issues immediately. Sometimes critical ones.

As much as I like AI, in my own projects I refuse pull requests blindly generated by tools such as Claude Code for exactly that reason. And in a company context, I wouldn’t deploy that output to production either.

There are two ways to significantly improve quality and confidence.

First, write the tests first, then force the agent not to declare the task complete until the tests pass.

The tests don’t even have to be part of the application’s formal test suite. A simple shell script with curl commands can be enough.

What matters is that this becomes a contract the agent has to satisfy.

That’s much stricter than a prompt, because a contract can’t be hand-waved away or interpreted creatively.

Second, use a loop with an LLM-as-a-judge.

Let one agent write code, documentation or a plan. Then let another agent review that work against the original instructions, and force the implementer to retry until the reviewer thinks it’s correct.

Swival makes both of these approaches trivial because they’re built in.

Before starting a task, you can give the agent a script that will act as a reviewer.

That reviewer can be another swival instance with a custom configuration. Or, even more simply, you can start with --self-review, and tasks will be reviewed by the same instance and same model in a dedicated context.

There’s nothing else to wire together.

One of the most interesting things to watch is how bad the initial output of an LLM agent can be, especially for code, and how honest and picky a model can suddenly become when it’s reviewing its own output without realizing it.

After a couple of iterations, the code, plan or documentation is often far better than the first attempt.

This is also one of the main reasons I wrote a new agent at all.

I don’t want to use AI to generate a mountain of code just so I can brag about productivity if the result is unreliable, insecure and unmaintainable.

I wanted an agent that optimizes for quality rather than raw time savings.

It can be slow. It can be expensive. But I want the output to be something I can trust and deploy to production.

Long sessions shouldn’t make the agent dumber

Another thing I wanted was continuity.

I wanted an agent that remembers what I did before, and what it did before.

When I come back to the same project the next day, I want the agent to remember prior work without filling the live context with junk.

Swival does that in a way that feels much more natural than in other agents.

I also wanted it to stop making the same mistakes twice.

So Swival has a /learn command: at the end of a session, the agent can reflect on the issues it ran into and write concise instructions about how to avoid repeating them. And once those learnings exist, it will keep updating them automatically.

That has turned out to be much more effective than premade agent skills. Or, more accurately, it’s an extremely effective way to produce the right skills, because the agent discovers what it actually needs from real sessions instead of from speculation.

Goals

One of the most frustrating things about working with an agent on a non-trivial task is how often it declares victory too early.

It runs for a few turns, fixes something, and then politely tells you it’s done. Except it’s not. There are still failing tests, missing pieces, or edge cases it quietly decided weren’t worth its time.

You re-prompt. It does a bit more work. It tells you it’s done again. And so on, until you give up and finish the task yourself.

People have been working around this with the so-called Ralph-style loop, which essentially means feeding the same prompt back to the agent in a shell loop until it stops finding things to do. It works, but it’s clumsy and wasteful.

I wanted something more structured, built directly into the agent.

In Swival, you set an objective with /goal <objective> in the REPL, and the agent stays on task across turns. The original objective is fed back to the model after every answer, and the loop only ends when the agent itself signals that the goal is complete after a real evidence-based audit, declares a blocker that needs your input, or hits an optional token budget.

The agent doesn’t get to walk away after one turn just because it feels good about its work.

This makes it practical to point Swival at ambitious long-running tasks such as refactors, audits or end-to-end fixes, and let it grind for hours without giving up halfway. You can pause, resume, replace, or clear the goal at any time.

It’s a small feature on paper, but in practice it changes what you can reasonably ask an agent to do.

Modern features, but without the usual mess

Skills, MCP, parallel subagents and similar capabilities are table stakes for serious agent use now. Of course Swival supports all of that.

But I also wanted it to avoid the usual security and reliability mistakes.

So tool and MCP output are explicitly tagged as untrusted in order to reduce prompt-injection risk.

And markdown comments are ignored, so what you see in a rendered skill isn’t different from what the agent actually interprets.

There’s another common failure mode I have always found silly.

If an MCP command or tool returns a large output, many agents either stuff the whole thing into the context window or fail in some awkward way.

I wanted an agent that handles that properly. Swival writes large outputs to a temporary file and lets the agent access them in chunks later instead.

I also wanted a clean way to share files such as agent memories and AGENTS.md across multiple devices working on the same project, without committing them into a Git repository.

Swival has lifecycle hooks specifically for that sort of workflow.

Arbitrary commands are easy too. In ~/.config/swival/commands/, you can place either scripts or plain files. Then ! command_name will inject either the content of the file or the output of the script into the prompt.

Yes, other agents have versions of this. But I wanted it to be trivial from a user perspective.

Not five overlapping systems with five different names for basically the same thing. Just one simple mechanism.

The same goes for shell command inspection and rewriting.

I didn’t want people to need to learn some complicated generic hook system.

In Swival, enabling command middleware is safe and straightforward.

And more importantly, I wanted the agent to be usable programmatically, not just from the CLI.

I also didn’t want that to require a separate SDK with its own worldview and its own behavior. Everything the CLI agent does should be accessible in a consistent way from Python code.

This is why Swival can be used as a CLI, but also as a library. It exposes a very simple API so anyone can build custom agents, or more general applications, on top of a batteries-included agentic environment.

Small things matter

Some of the things I cared about aren’t glamorous.

They’re just the kind of rough edges that make a daily tool annoying.

For example, markdown rendering for LLM output looks nice, but I dislike the fact that copy-pasting rendered output often strips the markdown markers.

I also don’t love the idea of an agent accidentally deleting files.

These are small things. But they matter if you actually use the tool every day.

Swival renders LLM markdown output while preserving the formatting tags.

So the output looks good, but can still be copied and pasted without losing the markdown.

And even in full YOLO mode, it has safety guards against dangerous commands, plus built-in support for the AgentFS copy-on-write filesystem overlay.

Also, when a file is deleted using Swival’s own tools, it isn’t actually deleted. It’s moved to a Trash directory instead.

I have never personally seen an agent delete the wrong file. But if it ever does happen, I want recovery to be possible.

Why I use it

At this point, I use Swival almost exclusively. It’s reliable, and I’m happy with the output I get from it.

I use open source models as much as possible, both locally and via HuggingFace inference endpoints.

But when I need a frontier model, I use it with GPT-5.5. This is a fantastic model. It works amazingly well with a regular ChatGPT subscription, and I have never hit any usage limit.

If you are happy with your current agent, there are no reasons to switch.

But I would still strongly encourage you to try Swival. Maybe even use it alongside the agent you already use.

Because even with the very same models, it’s likely to find bugs your other agent never found. That isn’t magic: different agents expose different environments to models, and models behave differently in those environments.

I have used the /audit built-in command and it found bugs and vulnerabilities in pretty much every code base I tried it on, including code bases that had already been audited with Codex and Claude Code.

That’s the kind of difference I care about. Whether the tool helps me find real problems and ship better work.

So yes, give it a try.

What’s next

Version 1.0.0 doesn’t mean Swival is done.

It means it now checks all the boxes from my original todo list, and it’s stable enough for daily use.

The API is also unlikely to see major breaking changes, so it’s something you can reasonably rely on if you want to build applications and agents on top of it.

There are still many planned changes and features. But Swival will remain driven by real-world usage and user feedback, not by a roadmap for the sake of having a roadmap.

Related projects are going to keep expanding as well.

Right now, they’re:

• Calibra, to evaluate models, MCP servers, skills, and related configurations
• Skillscheck, a linter for agent SKILL.md files
• Agent Skill Lint, a Visual Studio extension for agent skills linting
• Swival commands, a repository for user-contributed commands

Swival exists because I wanted an agent that takes privacy seriously, works with the models I actually want to run, gets better over long sessions, and pushes code quality up instead of pretending quality doesn’t matter.

Most agents still optimize for marketing. I wanted one that optimizes for the work.

That’s Swival.