Lab Notes.

Where does my token go?

We talk a lot about which AI model is best.
Bigger models. More parameters. More reasoning. More tokens.
But lately I have been thinking about a different question:

Where does my token go?
When I send a prompt, where is it processed?
Where does the data go?
Which region? Which providers?

What is retained — and for how long?

For many AI use cases, these questions may seem mostly technical. But when the information becomes sensitive, or when AI becomes part of critical infrastructure and essential societal services, they become something else. They become questions of architecture, resilience and responsibility.

What happens if the connection disappears?
Can we continue operating locally?
How quickly must a decision be made?
Which actions may an AI system perform autonomously?
And who remains accountable when AI moves from recommending to acting?

This is also why I don't believe there is one AI architecture for everything. Sometimes a cloud model is the right answer. Sometimes intelligence needs to be closer to the data. Sometimes a small local model is enough. Sometimes traditional machine learning or deterministic software is actually the better solution.

Right tool. Right size. Right place. Right task.

This is one reason I keep coming back to the idea of an AI Factory — an architecture where we can consciously choose where and how intelligence runs based on:
🔷 Capability
🔷 Cost
🔷 Latency
🔷 Security
🔷 Resilience
🔷 Data sensitivity

And as AI moves from answering questions to taking action, one principle becomes increasingly important: Accelerate execution — don't delegate accountability. Human judgment still matters.

So perhaps, before asking:
"Which model should we use?"
we should also ask:
"Where does my token go?"

These are some of the questions I'm exploring. I certainly don't have all the answers. What questions do you think we should be asking as AI moves from experimentation into real systems and critical processes? I would love to hear your perspective.

AI Dependency Starts With Pricing

Who controls your AI economics?

Most discussions about AI focus on models, benchmarks, and features.

But an equally important question is often overlooked:

How does AI actually get billed?

Some services charge per user.
Some charge per token.
Some charge per API call.
Some charge for compute capacity.
Some combine several pricing models.
Some charge for outcomes.

The technology may look similar on the surface, but the economics underneath can be very different.

This is why AI independence is not only about infrastructure, models, or data.

It is also about understanding the mechanisms that drive cost, dependency, and long-term flexibility.

The question is not:
"What does AI cost today?"

The question is:
"Who controls the pricing model tomorrow?"

As part of my own learning journey, I explore many of these questions in my AI lab, experimenting with NVIDIA Jetson, Apple Silicon, local models, and AI infrastructure to better understand what lies beneath the surface of AI.

Some thoughts, experiments, and learning experiences are documented at OakSeed.ai.

AI Independence starts with understanding

Too many organizations are chasing the next model, the next benchmark, or the next AI hype cycle.

GPT-4.
Claude.
Gemini.
DeepSeek.
Codex.
And whatever comes next.

The latest model will eventually be replaced. The understanding you build within your organization will not.

As AI adoption accelerates, many conversations focus on:
- Which vendor should we choose?
- How much do tokens cost?
- Which Copilot should we buy?

Important questions. But perhaps not the strategic ones. The real question may be: Do we understand AI well enough to make our own decisions?

Many organizations focus on applications and vendors. Far fewer invest time in understanding what lies beneath:
🔷 Tokenization
🔷 Transformers
🔷 Training vs Inference
🔷 LLM architectures
🔷 GPU computing and CUDA
🔷 AI economics

Understanding these foundations is not about becoming an AI researcher. It is about maintaining the ability to make conscious decisions about data, infrastructure, costs, security, and innovation.

This is why I find the concept of an AI Factory increasingly interesting. Not necessarily to replace external AI services, but to:
🔷 Explore
🔷 Learn
🔷 Experiment
🔷 Build competence
🔷 Stay flexible
🔷 Reduce unnecessary vendor lock-in
🔷 Create sustainable business value

AI Independence is not about owning GPUs. It is about owning enough understanding to make your own decisions.

What are your thoughts? Are we building AI capability? Or are we outsourcing it?

An old friend – The C Programming Language

I met an old friend again — and it reminded me how I still think today.

The C Programming Language by Kernighan & Ritchie.

I first read it back in the early 90s, when learning C completely changed how I thought about programming. Not because of the syntax — but because it forced me to understand what actually happens underneath.

Memory.
Data structures.
Consequences.

Back then, I even built a small CAD-like drawing program in pure C. Simple shapes, file formats, load/save. It was hard — and incredibly fun.

Picking up this book again now doesn't feel like nostalgia. It feels a bit like meeting an old friend.

A reminder of a way of thinking I still rely on today:
- clarity over abstraction
- understanding before optimisation
- value before tooling

In a time of platforms, containers and AI, I still find myself asking: What's the "C-level" understanding of this problem?

Some things age surprisingly well.

What early technical experience shaped the way you still think today?

Sunk cost fallacy – a useful lens in decision-making

In organizations, we invest a lot of time, energy and commitment into initiatives, strategies and projects. That's natural. But sometimes, that investment itself can quietly influence our decisions.

There is a well-known concept in behavioral economics called sunk cost fallacy. It describes how we risk continuing to invest in something because of what we've already put into it, rather than because it creates the most value going forward.

A sunk cost is time, money or effort that is already spent and cannot be recovered. From a rational decision-making perspective, those costs should not influence future choices — only expected future value should.

One question I personally find helpful to pause and reflect on is: If this didn't already exist, would we choose to start it today, given our current needs and priorities?

This isn't about questioning past decisions — often the real value lies in the learning. It's about making sure future decisions are grounded in today's context and tomorrow's value, not yesterday's investments.

Have you ever been in situations where it was hard to separate the value of what has already been done from the value of continuing forward?

Exploring CUDA Cores and Unified Memory

Today we dive deeper into the architectural parallels between Apple's Unified Memory Architecture (UMA) on the Mac Mini M4 and Nvidia's CUDA cores on the Jetson Orin Nano. By leaving space for the void, we allow raw performance metrics to align with clean, maintainable C++ code structures.

Baseline Setup & Hardware Cloning

Establishing a stable foundation is key before scaling out multi-agent logic. Cloning images securely via Mac to SSDs ensures we maintain our mountaineer approach—never falling back to zero.