DEV Community: Francisco Colomer

Who Picks the Model That Writes Your Code?

Francisco Colomer — Thu, 27 Aug 2026 14:23:23 +0000

You fire off a prompt in Cursor. It runs. It works.
Now tell me which model handled it, how much context reached it, and what you just paid.

You don't know, nobody knows :(

What happened in August

On August 14, 2026, SpaceX closed its acquisition of Anysphere, Cursor's parent company, for $60 billion in stock. Cursor moves into SpaceXAI, the structure that had already absorbed xAI. Three days later came Origin: Git hosting inside the editor.

One group now controls the model, the environment, the infrastructure, and the repository.

The layer that decides, and nobody looks at

Between your prompt and the model sits a layer. It's called the harness.

Think of a draft harness. It doesn't give the horse strength. It couples that strength to the cart.

Before the call, the harness decides what context goes in, what invisible instructions get added, which tools exist, and what gets dropped. After the call it runs the actions against your terminal, applies permissions, and repeats the loop until the task is done.

Without that loop, the model's answer is an intent in JSON.

Whoever controls the harness controls the apparent performance of a model they don't build.

Without touching its output. Just by choosing what reaches someone else's model.

Two pots of credit

Cursor doesn't sell a subscription. It sells credit.
And that credit is split in two:

Pot	Covers	How much
In-house	Grok, Composer	"Generous" usage, no published figure
Third-party	Claude, GPT	API price, hard number, runs out

That isn't a billing decision. That's the entire commercial policy: the competition costs you money and eventually runs dry. Antigravity applies the same pattern in a different currency: it serves Claude through Google credits whose conversion to tokens is undocumented.

The day neutrality stopped paying

Until August, Cursor had every reason to want Claude and GPT performing well. It had no frontier model of its own. Its product was worth whatever someone else's model was worth.

With Grok built inside the same group, that incentive flips.

No bad faith required. A margin test deciding the default is enough.

The invisible lever

In July 2026, Cursor Router replaced Auto mode. The economy tier keeps its flat rate but stopped being unlimited. The higher tiers bill at the price of whichever model actually runs. And the vendor picks that model.

Handing the choice to whoever charges differently depending on the choice is the most powerful commercial lever there is. It's also the least visible.

A harness that resells tokens is useless as a model benchmark. What you're observing isn't the model. It's the model plus the decisions of an intermediary you can't audit, one with interests shaped by its own commercial agreements.

Five things that aren't on the pricing page

Your subscription doesn't come with you. You can't use your Claude Pro or Max plan inside Cursor. Consumer subscriptions stay tied to the model vendor's own app.
A per-token surcharge on third-party models in team plans. It applies even when you bring your own key. In-house models are exempt.
A surcharge for regional data residency.
Migration from fixed seats to per-run billing, as already happened with Bugbot.
BYOK switches off zero data retention. Bring your own key and your data falls under the model provider's policy instead. You bought the environment for privacy and lose it precisely by using it that way.

Point 1 has an economic consequence, not just a technical one: the consumer subscription is the cheapest frontier token on the market, and no reseller can match it. A vendor can subsidize its own channel. A middleman can't.

The legitimate alternative is boring, and it costs you something: install the Claude Code extension inside Cursor, which is a VS Code fork anyway, and authenticate with your own account. Cursor becomes your editor. It stops being your harness.

Origin closes the chain

Origin is Cursor-hosted Git: repos, pull requests, and sync with GitHub without leaving the editor. Repos live at cursor.com/codebase. Early beta since August 17 on Pro, Teams and Enterprise.

Cursor bought Graphite in December 2025, a company built around stacked PRs and merge queues. Origin is the last piece: write, store, review, and merge in the same place.

The bottleneck isn't writing code anymore. It's reviewing it.

GitHub wasn't designed for this volume or this model of authorship. The timing wasn't accidental either: GitHub went down for six hours and forty-two minutes on launch day.

Almost every closed ecosystem leaves the repository alone. Google and Anthropic don't touch where your project lives. SpaceXAI wants it inside, because a repo holds far more than code: org rulesets, reusable workflows, the identity App, the quality gate, the board that acts as your source of truth.

Watch, don't act

Swapping GitHub for Origin wouldn't be switching providers, or swapping one piece of my E2E flow. It's moving to a vendor with ambitions to own the whole ecosystem, one that also sells you the harness and the model.

I've used Cursor before, and I'm tempted to give it another shot. With this much noise out there, re-evaluating is tempting on its own. For now I'd rather watch without acting, and wait until Origin shows up in tools that adopt it on merit, not through a commercial agreement.

Sources

Your AI Coding Agent Is You... And That's the Problem

Francisco Colomer — Fri, 14 Aug 2026 12:21:28 +0000

Your rulesets are in place. Branch protection, required reviews, no force-push to main. Everything by the book.

Then your coding agent pushes straight to main. No error. No warning. Clean push.
Your first instinct: the agent bypassed the ruleset. It didn't. The ruleset never applied.

Identity Inheritance, Not a Bypass

An LLM running inside your VS Code session doesn't authenticate as itself. It uses your SSH keys, your git config, your gh session. If you're an org admin, the agent operates as an org admin.

GitHub rulesets exempt admins by default. The agent didn't break anything. It acted under your identity, and your identity had a free pass.

The governance layer was never breached. It was never reached.

Ink vs Cement

A RULES.md file telling the agent "never push to main" is probabilistic. The model reads it, interprets it, mostly follows it. Until it doesn't.

A system-level restriction that blocks the push before it happens is cement. No interpretation. No exceptions.

The fix isn't telling the agent to behave. The fix is removing its ability to misbehave.

An Isolated System User

The agent now runs under maibot, a separate Linux user with its own home directory, its own credentials, and zero admin privileges anywhere, just writer.

Authentication goes through a GitHub App with three permissions:

contents: write: clone and push to branches
pull_requests: write:open PRs
metadata: read

That's it. No admin. No maintain. The org-wide ruleset applies in full. maibot can't push to main, can't approve PRs, can't delete protected branches.

Two Sessions, One Machine

Both run via VS Code Remote-SSH on the same WSL2 instance:

wsl-colomr → the developer. Admin keys, commit signing, full access.
wsl-maibot → the agent. GitHub App token, scoped permissions, one-hour expiry.

A shell script generates a JWT from the App's private key, exchanges it for an installation token, and configures gh and git credentials. The token lives for one hour. Just enough for my "atomic" sessions (it requires another post, sooner than later).

Why This Matters Beyond My Setup

Every team running AI coding agents inside developer sessions has this problem. The agent doesn't need to be malicious. It doesn't need to hallucinate. It just needs to inherit the wrong identity and make a mistake.

If your developers are admins and your agents share their sessions, your rulesets are decoration.

What Comes Next

maibot isn't just a hotfix. It's the foundation for an agentic layer where every agent operates under least privilege by design: isolated identity, scoped credentials, system-enforced boundaries. No agent gets more access than it needs. No exception travels by inheritance.

Cement first. Autonomy second.

Multi-Device with Claude Code

Francisco Colomer — Fri, 07 Aug 2026 15:20:57 +0000

The Problem

Using Claude Code across different devices in my end-to-end workflow leads to a frustration you might find familiar: when I switch devices, it's like having an intern who's forgotten everything I taught them by Monday morning.

It's not that the code disappears. The code is on GitHub. But those settings, personalised instructions in CLAUDE.md, hooks that automated your workflows, even your preferences for which models to use in each context... they vanish as if they never existed.

Then there's another problem I call cognitive inconsistency. You work in the evening on your laptop with one set of rules, tomorrow on your desktop those rules don't work. It's not a technical bug, it's an accumulation of circumstances (keep reading…).

There's a constant battle of weights. Your instructions in CLAUDE.md compete with the system's weights: the defaults Anthropic puts in place, the "safe" behaviors baked into the model. Sometimes you win, sometimes you don't. It's probabilistic, and it changes subtly depending on the machine, the model, on what the system decides is "prioritary" that day when calling the model's endpoint. It's really like having an employee who says "yes, I understand your rules" but then does what the corporate boss ordered months ago because it gets higher priority in the weights when instructions contradict.

And this multiplies. With 2 devices it's annoying. With 3 or 4 devices you never know exactly which version of "your Claude" you're working with.

That frustration is what led me to create claude-sync.

Claude-Sync

What I built is simple in concept: a repository that syncs your approved Claude Code configuration (contract-id) across all your devices.

Instead of each machine being its own configuration isolated, I now have a single source of truth on GitHub. Every time a SessionStart runs, a script asks: "What's the approved configuration on main? Fetch it and apply it to this machine right now."

This means your personalised CLAUDE.md, your automation hooks, your model preferences stay consistent across all devices. And most importantly: it's audited. If something changed in your configuration, it's in git history. You know exactly what changed, when, and why.

Each session, Claude Code shows you if there are synced changes and which version of the "contract" you're working with. This prevents silent sync failures where you think you have your rules but you don't.

The intern who forgot everything now has a notebook they review every morning. And that notebook is under version control.

Why I Built It

It wasn't a tool I planned to create. It came from accumulated frustration.

I work across multiple devices and each one is its own fragmented universe of Claude Code. I'd spend time configuring hooks, writing instructions in CLAUDE.md, tweaking behaviors. Then I'd sit down at another machine and have to start over. Or worse: I'd work assuming I had my personalised rules, and halfway through a project discover they weren't there.

Then there's the control problem. If your configuration is "magical" (living only on each machine), you have no visibility. You don't know what's synced, what changed, when. With claude-sync, it's all explicit. If it fails, you see exactly why.

It's the same principle we use for code: versioned, audited, deliberate. It shouldn't be different for the configuration that tells Claude how to work with you.

Important: This is Beta

claude-sync is tailored to my specific use case. My workflow, my machines, my way of working with Claude. It probably won't be plug-and-play for you.

But that doesn't make it useless. It means it's a starting point that can inspire you to adapt it to your own flow. If you recognise the problem, you can probably take the ideas from this project and make them yours.

Deliberate Synchronisation

It's worth exploring what happens when you turn your configuration into something versioned, audited, synchronised. The claude-sync repo is available. Check the README, see if it works for you as-is or if it needs custom setup.

The point isn't that you use my exact solution. The point is that you start thinking of your Claude configuration as something that deserves version control. Because once you do, your Claude stops being that intern who forgets everything every Monday.

Hello World! Launching my technical blog 🚀

Francisco Colomer — Thu, 06 Aug 2026 10:34:05 +0000

Welcome to my new development space! I have created this blog with a very clear goal in mind: to share my experiments, tools, and open-source projects without cluttering other less technical social networks.

This is a lightweight "Hello World" test post to get familiar with the dev.to environment, validate the automatic sync with my GitHub repositories, and ensure everything is working correctly.

🛠️ What can you expect here?

Software Architecture: Challenges and solutions I encounter in my day-to-day work as a Cloud Architect.
Open Source Projects: Useful tools I am building so anyone can use them, give feedback, or contribute.
Artificial Intelligence: Practical implementations and real-world AI practices.

Thanks for stopping by! In the next post, we will dive straight into the code. Stay tuned!