Yes, this is Microsoft's "agent-based migration" option mentioned in the article.

Agent based requires an insane amount of privileged accounts and I would say fails for 10%+ of the VM population

Obviously you can ask the agent to use a specific tool, but the point of this article is about what they choose when the human on the other end has no opinion/taste/clue.

Exactly!

No, and Google actively bans people for using their subscription from other harnesses via various proxies/gateways.

To preempt certain replies, yes, I know you can pay API prices and use whatever harness you want.

But do they ban proxies that use CLI?

Shame. Thanks for the info.

Update: After some backlash, Google has clarified that they will only ban your "Antigravity and/or Gemini CLI accounts," not your Google account. How very generous! Keep being tone-deaf then...

https://x.com/evanotero/status/2095616180895543469

Being "professionally hosted" is not enough: You need a "cluefully developed" distributed git backend to be a GitHub competitor. Codeberg is already buckling despite being nowhere near GitHub's scale. When Codefloe gains more users/agents, it's going to suffer from the same fate since Forgejo/Gitea/Gogs just isn't a good foundation to build on top of.

What do you think makes it a bad foundation to build on?

Their primary storage medium is block storage which is quite expensive. Codeberg cited it, although post-hoc, in their decision to ban AI projects. GitLab runs (or ran) the large block storage based Git service I know of which is Gitaly.

If you want to achieve public service level traffic and cost then you pretty much need to find a way to leverage object storage.

GitHub also uses block storage - its just git on NVME. The complicated part is the redundancy and ensuring consistency.

Cursor introduced an S3 WAL in their new system, Continuity. https://cursor.com/blog/git-at-any-scale

Note that this assumes cloud-based. A rack full of hard drives is far cheaper per GB than either, even at 50% utilisation and 2x redundancy. (It would have to be! Amazon obviously wants to make a profit)

See Cursor's recent blog post on launching a Github competitor, particularly the architectural history.

Right...check the vibe coded slob pile for reference...

That’s a great blog post, lots of details, helpful animations, historical context, and an interspersing of war stories.

https://cursor.com/blog/git-at-any-scale

(founder of codefloe)

Codeberg is buckling because of old hardware and not-so-great operational devops processes. I am stating that as a former core member with access to these and the historic goals of changing something to the better. The underlying software is not the issue.

GitHub and GitLab were built on Ruby. The language behind this is much less suited to serve a platform with that many requests.

The hard part is the SRE engineering behind it and the option to potentially make tweaks in the underlying codebase when needed, to fix possible bottlenecks (most often it comes down to how SQL is being processed).

> digital nomad / people going to coworking spaces

Laptops with built-in screens make infinitely more sense for this population.

> sub-agents will decrypt (by hitting a backend) to do their work

Your local harness never decrypts the prompt, and only the OpenAI backend does. Your harness still sees tool calls in the transcript so it can act, but you lose (some) visibility as to why the subagent chooses to do so.

Imagine seeing this transcript during forensics:

[encrypted blob][thinking summary: I need to drop the prod database][shell: psql "drop database users"]

OK, so it's actually:

    My Client -> main agent -> sub-agent -> tool
                     |            |
                    log:         log:
                  enc prompt   enc prompt
                   thoughts     thoughts
                     |            |
                     V            V
                   My Client   My Client

Is that more correct? So they're not encrypting prompts to send to sub-agents, they're encrypting logging output to obscure details of the system.

The prompts themselves are encrypted when saved to disk, so you can't inspect them after the fact. If you switch agent threads in the terminal UI (you can kinda swap active session to prompt subagents yourself), you can see the subagent prompt set by the main agent, as long as you have the terminal client open. And this is also for v2 multi_agent mode, v1 doesn't have this, but you need to do a bunch of annoying stuff to re-enable v1 for GPT-5.6 Sol and Terra.

> bypassing OS kernel

> reading a raw device node (e.g. /dev/rdisk*)

That's... not bypassing the kernel. Time to integrate SPDK so it actually bypasses the kernel :)

https://spdk.io

It doesn't have to, you can give it a blob of bytes as well. It's just hard to keep it a cli and doesn't use kernel at all

more correct would be - do not use kernel file system

TIL about SPDK. Thanks!

CSS is what allows dickovers to work, not JS, and pure-CSS dickovers are possible [0] :P

[0]: https://hunzaboy.github.io/Light-Modal

You would be surprised how adept SOTA models are at reverse engineering with IDA/Ghidra or even plain old objdump. Opus basically knows IDAPython on the back of its hand.

They can be, but the most interesting parts (backend code, deployment confs) are not usually available. Reversing clients can help to understand a bit, but not with equal level.

On the other hand, any source code leak could be catastrophic

... and that was also a year before the crypto winter in 2018 :)