agnostisk. dk

Agnostisk is my way of thinking about technical freedom of movement. Database-agnostic. Tool-agnostic. Model-agnostic. If the analogy is allowed to travel a bit further: agnostisk.liv.

The blinking endings are the point. You can use a technology very intensely without wanting to marry it. This is about what that looks like in practice when the stack includes Claude Code, Codex, local models on DGX Spark, and a toolkit layer that is meant to survive changes in vendors and interfaces.

This is not anti-Claude. Quite the opposite. It is about why Claude becomes more useful when it is part of a setup with real optionality around it, and the ways of thinking that make that hold together.

Claude Code CPH

The talk

A practical example of model-agnostic coding

How I switch between Claude, Codex, and Qwen on a DGX Spark without rebuilding the agentic setup each time.

The point is not to collect interfaces. The point is to build one working layer that can move between them. I want to show a concrete setup where the repo, the tools, and the expectations stay stable while the model backend can change.

Same repo

The work stays in the same project, not in three different workflows.

Same toolbox

Rules, tools, and prompt conventions live in one shared layer.

Three backends

Claude, Codex, and local Qwen are choices, not separate worlds.

Claude Code CPH

The build

How the toolbox is wired

The stable layer sits in the middle. Interfaces sit above it. Model backends sit below it.

Claude Code

Codex

Local shell

Shared layer

fhh-toolkit

Rules and prompts

Tools and plugins

Adapters and setup

Shared working patterns

`fos` consumes this layer instead of reinventing it per model.

Claude hosted

Codex hosted

Qwen on Spark local

Claude Code CPH

The switch

What actually changes when I switch model

The backend changes. The surrounding working method does not.

Claude

I use it when I want the strongest hosted coding experience and long-form reasoning inside Claude Code.

Codex

I use it when I want the same repo flow through a second provider and a different coding surface.

Qwen on DGX Spark

I use it when the work should stay local or when I want a private fallback that I control myself.

What stays the same

Repo structure, tool access, prompt rules, expected output shape, and the way I evaluate the result.

What changes

The backend, the privacy boundary, the cost profile, and sometimes the interface I choose to work in.

Hosted

Claude and Codex give me provider choice without changing the repo setup.

Local

Qwen on Spark gives me a private path when the work should stay on the machine.

Practical point

The model stops being the whole workflow and becomes one component in it.