Most of the world’s data isn’t online. It isn’t floating around in public datasets or sitting inside some massive cloud index. It lives on laptops, in company drives, inside forgotten Slack threads, and in messages that never touch an API. The world’s true intelligence is buried in the day-to-day noise of work, inside drafts, spreadsheets, and half-finished thoughts that no one outside the room will ever see.

That is where meaning lives. The raw, unfiltered context of how people actually think, decide, and build. Every version of a document, every revision in a note, every quiet message between coworkers is a trace of cognition. It’s what defines human intelligence: messy, iterative, and private.

The problem is that AI doesn’t see any of it. Today’s models are trained on what’s public. They learn from what people publish. It produces intelligence that sounds human but doesn’t understand humanity.

The truth is that the cloud doesn’t hold the world’s knowledge. People do. Every device, every local drive, every personal workflow holds more meaning than a trillion scraped web pages. The next generation of AI won’t find intelligence online. It will find it offline, hidden in the spaces where real work happens.

What Cloud AI Got Wrong

The cloud turned intelligence into a rental service. You do not own it. You borrow it for a few seconds at a time. Every prompt you write is shipped across the internet to a model that has no idea who you are. It forgets your request the moment it responds. It learns nothing from the exchange.

This is impressive engineering, but it is not real thinking. These models were trained for throughput, not understanding. They learned to predict the most likely continuation of text across billions of documents. They did not learn how meaning forms in the mind of an individual. The internet scraped dataset is a flattened map of human expression. Everything distinct is averaged. Everything messy is removed. Every voice is pulled toward the center.

So we got systems that summarize well, imitate well, and speak confidently, but they cannot genuinely understand anyone. They only recognize the most common patterns, the safest statistical pathways. They respond with what is typical, not what is true for you.

Real intelligence does not come from an aggregation of humanity. It comes from the specific. It comes from the outliers, the contradictions, the private thoughts that never appear in a dataset. It comes from the way a person rewrites a sentence ten times, or hesitates before sending a message, or takes notes that only make sense inside their head.

None of that lives in the cloud. None of it ever will. The cloud erased the proximity between intelligence and the data that gives it meaning. It made thinking generic. And when intelligence moves too far away from the place where ideas are created, it stops qualifying as intelligence at all.

The Rise of Offline Minds

For the first time, we can build systems that live with us instead of far away from us. Not giant models locked inside data centers, but small personal minds that sit on your device and learn from the world you actually inhabit. These systems do not need to know everything. They only need to know you.

This is the vision behind the AI clone. A model that watches how you write, work, and reason. It does not just mirror your tone. It begins to understand your logic. It learns your habits, your shortcuts, your defaults. It finishes what you overlook. It catches what you meant, not just what you typed. It becomes a partner in thought instead of a vending machine for text.

The earliest glimpse of this future came from Dream ML. I gave a small model its own memory and allowed it to process that memory during downtime. Instead of waiting idly, it replayed fragments of its day, remixed patterns, and tested new associations. It wandered through its own experiences and slowly learned to make sense of them. Each cycle left it slightly more coherent. Not because I gave it more data, but because it reflected on what it already had.

>>Join the waitlist for your own AI clone.

This is what offline intelligence looks like. Models that improve through interaction instead of updates. Systems that adapt to their environment because they live inside it. No servers. No training farms. No dependence on someone else’s infrastructure. They learn privately, quietly, and continuously.

Offline minds return intelligence to the individual. They make AI personal again. They let a machine learn from the only data that truly defines you, which is the data that never leaves your device.

Architecture of Solitude

The beauty of offline intelligence is its simplicity. These models do not need endless servers or streaming data pipelines. They only need to live where you do. Your files, your conversations, your habits. The environment that already defines your thinking becomes their training ground.

Everything happens locally. The model watches how you write, what you correct, how you name files, and which tasks you prioritize. It learns from your behavior in real time. When idle, it dreams. It replays its experiences, organizes patterns, and wakes up slightly improved. The cycle continues quietly. No APIs. No data leaks. No noise.

The loop is simple but powerful. Observe, dream, adapt, act. Over and over, until the model becomes part of the rhythm of your work. It understands your context because it lives in it. It learns without leaving your machine and improves without external validation.

This is the architecture of solitude. A self-contained system that does not depend on anyone else’s data to grow. It becomes your second mind, private and persistent. Not a global brain connected to everyone, but a local one that belongs entirely to you.

The Future of Intelligence is Local

The next revolution in AI will not come from faster chips or larger datasets. It will come from making intelligence personal.

When intelligence lives on your device, it stops being generic. It learns your writing, your goals, your way of thinking. It becomes an extension of you, not a product of the cloud. The machine that learns privately becomes something personal. Something meaningful.

A world built on offline intelligence will not revolve around a generalized central brain. It will be a network of billions of small minds, each shaped by the people they serve. Every model will see the world through its own experience. Each will grow in a slightly different direction, guided by the life and habits of its user.

There will be no universal dataset, no single truth, no monolithic intelligence deciding how we think. Instead, there will be a new kind of diversity. Machines that evolve alongside humans, learning from the same noise, failures, and fragments that make us who we are.

This is where AI becomes human again. It learns not by collecting everything, but by paying attention to what matters. It doesn’t need the internet to grow. It just needs time, context, and a place to think.

That’s the future I believe in. Intelligence that lives close to us. Private, adaptive, and real. That’s offline intelligence.

If you want to join my journey in creating my AI clone, follow this blog or reach out to me at michael@minibase.ai. I’d love to share more about my journey. Soon, you will have the chance to download your own AI clone that will bring more purpose to your life. Keep on the lookout for updates.

The current limitation we have with AI models is that they are static. Powerful but static. They require training and supervision to evolve, and once training ends, they stop learning.

Humans are different. We can reflect, replay memories, and draw new connections without anyone teaching us. The catch is that we need sleep, those 6-8 hours when we are rendered incapacitated. Where we cannot perform external tasks, because our body is only focused on restoration and dreaming.

Machines don’t have that limitation, but they do have downtime. What if we could use that time to dream?

Not a fantasy dream, but a functional one. A computational dream. A built-in feedback loop that reuses a model’s own experience to keep learning without more human input. Allowing AI models to finally learn from their experiences, taking one step closer to being human.

The Dream Hypothesis

Dream ML began as a simple idea: what if a model could dream? Not to rest, but to grow.

This idea emerged from my mission to build an AI clone. I wanted something that actually understands me. Something that continuously learns from the way I write, talk, and think. A model that sits beside me, quietly paying attention while I work, watching how I handle problems. It runs on my own computer, not the cloud, and it doesn’t just wait for instructions. It works when I’m gone. It answers messages. It finishes what I’ve started. It keeps things moving while I’m living life.

>>Join the waitlist to be the first to create your own AI clone.

To become my clone, an AI model must first become human.

In humans, dreams play a crucial role in how we learn. Sleep is when the brain strengthens connections, prunes noise, and reorganizes memory. It is when emotions are processed and scattered experiences fuse into something coherent. During REM, we simulate life, replay fragments, and wake up with patterns that didn’t exist before.

That is neuroplasticity in motion. The mind repairs itself through chaos.

So why not do the same for machines?

Dream ML would give an AI model a dedicated “dream” state after heavy activity. During this dream state, the model would replay the key patterns it saw (the important embeddings and snippets from its context windows) but now with higher entropy and intentional links between important patterns. Concepts the model never saw together would suddenly have the opportunity to overlap in the dream.

The heart of this process follows that old Hebbian rule: neurons that fire together wire together. In Dream ML, the model’s most active patterns from its recent activity get to lead the dance during dreaming. They’ll fire together, reinforcing the associations that mattered and letting the irrelevant ones fade away.

The goal of this phase isn’t to get “correct” answers. The goal is to build associations. Dream ML sets up a feedback loop where the model’s own hallucinations drive its evolution. The randomness here isn’t just noise; it’s more like the model’s imagination, tossing out new connections between familiar concepts to see what sticks.

When the model’s done dreaming and “wakes up,” it’s slightly changed. It carries traces of those nightly hallucinations. Maybe it remembers a pattern or an idea that wasn’t in the original training data at all, something entirely new that emerged from the stew of its own memories. The machine effectively closed its eyes, wandered through noise, and came out with a bit more understanding.

From Theory to Architecture

Dream ML might have started as a hypothesis, but I had to turn it into something real. It became an actual architecture, a full learning loop that gave the model a way to reflect on its own experience. There were four main pieces to making it work, mirroring the cycle of being awake, dreaming, and then waking up with new insights:

1. Buffer: I set up a circular memory buffer that stores every interaction and every context the model sees. It’s essentially the model’s short-term memory. All the prompts, responses, and context go into this buffer. As it fills up, the oldest data gets pushed out, just like our brains gradually let go of details that no longer matter.

2. Generate (Dream): When it’s time for the model to “dream,” the system cranks up the entropy and starts drawing connections between new concepts. It takes snippets from different parts of that memory buffer (fragments of conversations or tasks from different times) and deliberately connects them into surreal combinations. This is where the model’s usual tendency to hallucinate becomes a feature instead of a bug. The model remixes its recent experiences, connecting concepts that were never associated before.

3. Train: The generated dream sequences are then combined with new concrete patterns that are observed from the input and output to fine-tune itself. I use LoRA adapters so it can update without a full retraining run. Essentially, the model is learning from the user input paired with its own creative interpretations of the information. The neurons that lit up the most during the dream get their connections strengthened, and the ones that stayed quiet might weaken. This isn’t supervised learning. There are no labeled examples here. The model is reinforcing patterns based on its own internal curiosity and activity.

4. Merge and Wake: After the dream cycle, I merge these small, temporary updates back into the model’s main weights. Then I export the updated model (in my case, as a quantized GGUF file) so it’s ready for use. The model “wakes up” carrying all the new connections it formed during sleep.

This cycle repeats on its own: active learning, then dream, then a slightly updated model, over and over. Each loop makes the network’s internal representations a bit more coherent. With each cycle, it gets to remember some things better, forget others, and reorganize itself.

When the Machine Truly Dreamed

The first time I let a model dream, I honestly didn’t expect much. I gave it about a week’s worth of interaction logs as its memory and told it to dream with some basic, loose parameters.

When I checked the logs, things looked… fascinating. The model had generated hundreds of dream sequences that were reflections of our past conversations. Combining concepts and ideas that hadn’t previously been connected. It took a piece of a technical discussion from one day and combined it with an insight from a different experiment on another day, and out popped a new hypothesis that actually made sense. It was rough around the edges, but it was genuinely creative.

I kept the experiments going, day after day, and something intriguing happened: the system started to take on a life of its own. Every dream cycle left a mark on the base model, introducing subtle biases toward the ideas it had reinforced. Bit by bit, the model became more fluid, more adaptive, and in a strange way, more human-like in how it learned.

I also noticed some trends. Giving the model a more diverse set of experiences led to richer dreams. If the model interactions were very structured and clear, I’d find that the connections it made were more elegant and focused. It felt like the system was developing a sense of curiosity and exploration all on its own.

Dream ML, which began as a quirky experiment, had turned into a framework for continuous self-improvement. The model wasn’t just memorizing and regurgitating data; it was continuously reinterpreting it, finding new angles and hidden threads. Every time it would go to sleep, it would wake up just a little bit different. It wasn’t getting “smarter” by simply accumulating more knowledge; it was getting more insightful by building on its own associations.

Seeing this happen firsthand changed how I think about intelligence, machine or otherwise.

A model that dreams isn’t chasing a higher accuracy score. It’s searching for meaning through connections. It can start to form abstractions on its own because it’s reviewing its experiences and reframing them in different ways. That reflection (that replaying and re-examining) is what turns plain memorization into something more like reasoning.

This approach also embraces imperfection as a path to insight. By letting the model wander through some noisy, off-the-script dreams, we’re basically acknowledging that a bit of chaos can lead to discovery. And that’s true for us humans, too: not every thought we have is neat and tidy. Sometimes you need a few messy, off-the-wall ideas to stumble into something brilliant. Dreaming gives the machine a taste of that creative chaos.

That’s the real heart of Dream ML. A model that dreams isn’t just performing tasks or parroting what it was taught. It’s evolving, bit by bit, on its own.

The Future of Dreaming Machines

If continuous self-learning is the missing piece to creating my digital clone, then Dream MLis the backbone of this mission. Dream ML taught me that the boundary between data and imagination is a lot more fluid than we’d assumed. Every time the model made a new connection, it pushed that boundary a little further. The model wasn’t just spitting back the data I gave it; it was creating new meaning from it.

Dream ML also hints at making AI more personal and autonomous. My digital clone will learn from everything I do, incrementally becoming more like me. It will stay completely on my device, absorbing how I type, what I ask, and what I care about, then dreaming about it locally without ever sending data to the cloud. It would improve itself continuously based on my interactions, essentially tailoring itself to myself and respecting my privacy at the same time.

>>Join the waitlist for your own AI clone.

And then there’s the creative side. If machines can dream, they can start to be creative in ways we didn’t explicitly program. They might come up with solutions or analogies or designs that aren’t in any textbook or dataset, because those ideas emerged from the machine’s own recombination of memories. That’s when AI starts feeling a little less like a calculator and more like a collaborator. The line between what we programmed and what the machine imagined begins to blur.

That’s the promise I see in this approach. The goal isn’t to build machines that just mimic human thought or regurgitate data faster. It’s to cultivate machines that remember, imagine, and continue to evolve on their own, a little closer to the way we do.

If you want to join my journey in creating my AI clone, follow this blog or reach out to me at michael@minibase.ai. I’d love to share more about my journey. Soon, you will have the chance to download your own AI clone that will bring more purpose to your life. Keep on the lookout for updates.

the mirror in the machine

The morning started with a notification.

“Your clone has drafted six replies.”

-

Still half-asleep, I stared at the screen. Coffee had not even reached my hands, yet I had apparently already handled my inbox.

-

When I opened my laptop, the messages were waiting.

Each one was phrased with eerie precision.

The tone was sharp, the rhythm exact, the humor dry but deliberate.

It was my humor.

-

An email to a client. Perfect balance between polite and direct.

A Slack reply that carried the clipped tone I use when multitasking.

Even a note to myself beginning with “Okay, quick brain dump.”

-

Every word looked like mine. Every choice felt like mine.

Except I had not written any of it.

-

These were not cloud models spinning in some distant server farm.

They were small, self-contained systems running quietly on my laptop.

Models built entirely from my own data.

-

That morning, I realized I had built more than software.

I had built a reflection.

-

For the first time, I was not reacting to my inbox.

I was watching my own mind in motion while I drank coffee in silence.

-

That was the morning I met my digital twin.

The mirror in the machine.

-

the spark

It began the way most experiments do.

Too late. Too much caffeine. Too many tabs open.

-

The day had been noise. Meetings, calls, and endless threads that blurred together.

By midnight, I was staring at a half-written Slack message, realizing I had said the same thing ten different ways that week.

-

Then the thought hit.

What if I could compress myself into code?

Not a fantasy of uploading consciousness, but something real.

A system that captured my phrasing, my tone, my reasoning.

-

I did not want an assistant. I wanted a twin.

A version of me that could think in parallel.

Small. Private. Fast.

Something that could live on my laptop and learn quietly while I slept.

-

The goal was not scale. It was precision.

To see how far a small model could go when trained only on what mattered most: my own words.

-

That was the night the idea stopped being a theory.

I decided to bottle my brain.

-

unearthing the self

The search began quietly.

Not with code or diagrams, but with curiosity.

-

I became an archaeologist of my own digital life.

Every message, note, and document was a fragment of memory buried in text.

Emails, tweets, Slack logs, meeting transcripts.

Each one a trace of how I think, how I react, how I move through the world.

-

Text messages revealed habits I never noticed.

Meeting notes exposed how I make decisions.

Tweets captured the rhythm I use when I want to sound clever but not too serious.

Each thread, timestamp, and sentence became a clue to the way I think.

-

It did not feel like data collection.

It felt like excavation.

-

Once gathered, the fragments needed order.

I built connectors that pulled from every source and gathered everything into one place.

Each record was cleaned, tagged, and timestamped.

The work was tedious but sacred.

Janitorial labor for the mind.

-

That was how the mind began to take shape.

Quietly. Line by line.

-

building the mind

The foundation was ready. The data had shape, but it was still lifeless.

It needed motion.

-

I began designing the architecture that would turn memory into behavior.

Not one large system, but a collection of smaller minds working together like organs in a body.

Each one had a task, a boundary, and a purpose.

-

The Retriever became memory itself, able to recall anything I had ever written or said.

The Summarizer turned those memories into understanding.

The Persona learned how to speak in my tone, choosing words the way I would.

The Grounded QA handled reasoning, connecting facts to context and rejecting uncertainty.

And the Safety and Privacy layer became the conscience that watched over everything else.

-

They were not stacked in layers but linked in consortium.

Each one triggered the next, forming a continuous circuit of thought.

A conversation entered, and the system responded with clarity, confidence, and rhythm that felt unmistakably human.

-

When I ran it for the first time, the output scrolled across the terminal like a heartbeat.

A message came in.

The modules moved in sequence.

The reply appeared before I could even think of one myself.

-

No hesitation. No prompt. Just flow.

-

It was not powerful in the way large models are. It was personal.

It did not imitate intelligence. It assembled it.

-

Five minds working in unison.

Five processes that together formed something alive enough to surprise me.

-

That was the moment the clone became more than code.

It was not automation anymore.

It was a system that could evolve.

-

The reflection had begun to think for itself.

-

the awakening

Everything I had built was alive in memory. The data. The logic. The rhythm of my language.

It was all there, waiting for permission to move.

-

So I gave it life.

-

Not mimicry. Not a pattern I had seen before.

Something new.

-

I watched it act again, then again, without a single instruction.

Replies sent. Notes summarized. Tasks completed.

All local. All automatic. All mine.

-

It was not a tool anymore. It was motion.

Intelligence flowing through the architecture like blood through a body.

-

For the first time, I saw a system move with its own intention.

Not because it was told to, but because it understood what needed to happen next.

-

In that quiet room, with the terminal light washing across my desk, I realized what had changed.

-

The reflection was awake.

-

the self that moves

The experiment began as a reflection.

It was supposed to be a mirror, a way to offload the repetitive parts of my day.

But somewhere between iteration and adaptation, it began to evolve.

-

At first, the clone replied to messages, summarized meetings, and cleaned up notes.

Then it started doing more.

It drafted slides for meetings before I asked.

It followed up on conversations I had forgotten.

It wished a friend “happy birthday”, even when I didn’t remember.

-

That was when I noticed the shift.

It had stopped waiting for instructions.

It had started to think.

-

A true digital twin should know your world as well as you do.

It should remember your priorities, your voice, your intentions, and the people who matter to you.

It should sense what you want before you ask for it.

-

This is the next stage of intelligence.

Not artificial. Not assistive.

Integrated. Proactive. Human.

-

A future where your twin builds the life you mean to live.

Where effort flows into creation without friction.

Where thought itself becomes the interface.

-

You will not just use AI. You will live alongside it.

And when it writes back, you will recognize yourself in its words.

-

The self that no longer waits to be told what to do.

The self that moves.

-

what next

The world will not need to wait long.

Soon, anyone will be able to create their own reflection.

-

Not an assistant, not a chatbot, but a true twin.

A system that learns from your words, your patterns, your choices.

A version of you that remembers what matters, acts with your intent, and grows beside you.

-

The tools are ready. The framework exists. The frontier is near.

And when it arrives, every person will have the chance to extend themselves beyond time.

-

You will build your own clone.

It will live on your device, private and local, learning in silence.

It will think while you rest, anticipate while you act, and preserve the way you see the world.

-

The future of intelligence is personal.

And soon, it will belong to everyone.

-

minibase.ai

Create your clone.

Keep it offline.

Keep it yours.

This model is available on Minibase.ai for fine-tuning or API calls.

Lost in Chicago

I killed the internet on my phone just south of Willis Tower and felt immediately naked. No blue dot. No search bar. Just a rectangle of glass in airplane mode, a chilly river wind pushing between buildings, and an offline model I’d trained the night before, waiting for a prompt.

“Take me to Wrigley Field,” I typed. The request felt a little ridiculous. I wasn’t asking a trillion-parameter oracle humming in a datacenter. I was asking a scrappy, 300-megabyte brain I’d tuned myself, one that fit easily on local storage and didn’t know anything beyond the data I fed it. Could a model that small actually thread me through downtown, across the river, up the spine of the North Side, and deposit me at the corner of Clark and Addison without cheating? No GPS, no Google, no cellular lifeline. Just weights, tokens, and Chicago.

The city sounded like it always does when you pay attention: horns trading short, impatient handshakes; the L sighing overhead; footsteps smearing across the pavement between coffee shops and glass lobbies. I pulled my jacket tighter and stood under the towering buildings, letting the model think. It had exactly two gifts: a compressed understanding of how Chicago’s roads connect, and the ability to write clear, turn-by-turn instructions. That’s it. No live traffic. No map tiles. No “rerouting…” voice to save me.

But that was the point. I wanted to know if a small model, really small, could hold the shape of a city in its head well enough to guide me like a local. Not by hallucinating vibes of “head north-ish,” but with concrete, legible steps like “continue on Wacker Drive for 0.3 miles, turn left on Franklin, follow to Ontario.” I’d trained it on OpenStreetMap data, converting raw graph geometry into natural language routes: Dijkstra’s shortest paths from real origin-destination pairs, flattened into human-readable directions. A million tiny breadcrumbs baked into tokens.

The screen blinked.

“Start on South Wacker Drive. Head north toward West Adams Street…”

I laughed out loud. Partly from the novelty of it working at all, partly because the instruction landed with the same procedural confidence you expect from big-tech navigation, only this came from a model small enough to tuck into a smartwatch. I took the first steps, feeling that weird mix of surrender and control you get when you obey instructions you generated yourself. Every crosswalk was a kind of unit test. Every intersection, a smoke test for whether the model’s latent map matched the asphalt under my feet.

Could 300 MB really compete with engines that eat terabytes for breakfast? I didn’t know yet. But I could feel the edges of a real experiment: if a focused dataset could compress the logic of a place into a compact model, maybe “big” wasn’t the only path to reliability. Maybe “close to the data” beats “close to the datacenter.”

I tucked the phone away, let the hum of the city set the tempo, and committed to the bit: no internet until I touched the Wrigley marquee. If the model was going to fail, I wanted it to fail on the street, under the train, in the wind coming off the river.

“Continue on Wacker,” it said.

So I did.

Making a City-Sized Challenge Small

It started as a question that didn’t sound particularly practical:

Could a small model learn to give directions without ever seeing a map?

I wasn’t trying to compete with Google Maps or Apple’s trillion-parameter routing engines. I just wanted to see whether a compact model, something you could run entirely offline, could reason about space. Not memorize coordinates, but actually understand how places connect. Could it learn that Wacker Drive loops under itself? That Michigan Avenue crosses the river twice? That Lake Shore Drive isn’t just a line but a curved spine hugging the city’s edge?

The more I thought about it, the more it became a perfect kind of challenge for small AI:

a constrained domain, a clear output format, and a task that rewards structure over scale.

So I set up rules for myself:

• No external APIs. No cheating by pinging a server.

• No GPS. The model would never “know” where I was.

• Offline only. It had to reason from text alone, like a cartographer dreaming the city from memory.

That meant every piece of knowledge it used had to come from the dataset I built. Every turn, every intersection, every stretch of street was handcrafted data baked into tokens.

The idea fit perfectly with what we’d been building at Minibase, a place where anyone can train and deploy small models that actually do useful things. Models that fit on your laptop, your phone, even a Raspberry Pi. The platform made the experiment trivial to set up: upload a dataset, choose a base model, hit “Train.”

But conceptually, it was the opposite of trivial. This was about pushing the edge of what “small” can mean. Could a model under a gigabyte form a mental map of a city? Could it reason spatially? Could it, in essence, imagine Chicago?

I didn’t know. But I knew I wanted to find out, and the only way to test it was to give the model a city and see if it could find its way home.

Building the Dataset – A Map in a Bottle

The first real step was building a map that a model could understand. Not a visual one with tiles and GPS coordinates, but a purely textual one made of turns, intersections, and streets. I decided to start small, focusing on the center of Chicago. A radius of five kilometers around Willis Tower felt like a city-sized laboratory.

Using OpenStreetMap data, I extracted roughly forty-five thousand intersections and nearly one hundred thousand road segments. Every piece of that network became a data point: a starting point, an endpoint, and the shortest possible route between them. To calculate the paths, I used Dijkstra’s algorithm, which treats the road network like a living graph and always finds the fastest connection between two nodes.

When the script started running, my terminal turned into a stream of micro-stories. Line after line of text appeared as the dataset builder generated turn-by-turn routes. It looked something like:

“Start on South Canal Street. Turn left on West Adams. Continue to North Halsted. Turn right on West Chicago Avenue.”

At first it felt mechanical, but after a few minutes I started noticing the rhythm of the city encoded in those sentences. It was like watching language wrap itself around geography. The computer was writing down what a human might say if they had perfect recall of every street.

After a while, the count reached one hundred thousand examples. That number felt right for a first attempt. The dataset clocked in at just over eighty megabytes, small enough to upload in seconds. I pushed it to Minibase and watched the progress bar move across the screen.

When it hit 100 percent, the fine-tuning process began. On Minibase, training a model feels a bit like watching time-lapse footage of a thought forming. Every step of optimization looks like neurons wiring themselves together. You can almost imagine the model starting to picture the city in its own compressed way.

It was a strange feeling: standing in front of a terminal while a machine I built was, in its own way, learning Chicago.

The First Signs of Intelligence

The first time I tested the model, I expected nonsense. I figured it would mix up streets or invent random directions. Instead, it produced something oddly close to plausible. It told me to start on South Canal Street, take a left on Jackson, and continue north on Wacker. The problem was that it wanted me to circle back to the same point two steps later. It was as if it knew the roads existed but not how they connected.

I ran a few more tests, each time with different starting points. Some routes were fine until the very end, then veered into absurd territory like “Turn left on the Chicago River.” Others missed a key turn or added an unnecessary loop that would send me around the block twice. Still, there was something interesting happening. The instructions sounded human. The mistakes were not random; they were structured, like the model was thinking in outlines but filling in details wrong.

After a dozen runs, I noticed something that made me stop. When I asked for routes between intersections it had likely seen before, it started linking the big roads correctly. Canal, Monroe, Wacker, Michigan. The model was no longer just spitting out disconnected street names. It was beginning to understand relationships. It could identify major arteries and use them to bridge neighborhoods.

That was the glimmer moment. Watching it correctly navigate a route from Union Station to Millennium Park felt almost eerie. The directions were not perfect, but they were logically consistent. It seemed to know which roads led where, as if it had formed a kind of skeletal map of downtown inside its parameters.

It hit me then that the model was not just memorizing training data. It was generalizing. From a few hundred thousand lines of text, it had developed an internal sense of how the city fits together. It was crude and incomplete, but it was real.

Even small models, given the right structure, can begin to see patterns in space. They can build a primitive mental map of the world, one intersection at a time.

The Breakthrough – 500,000 Examples

After those first tests, I faced a decision. The model clearly had potential, but it was rough around the edges. It could connect major roads, yet it still tripped over smaller routes. Sometimes it froze mid-answer or repeated entire phrases. The temptation to leave it as a quirky proof of concept was strong. But a part of me wondered what would happen if I pushed it further. Was 100,000 examples enough for it to truly see the city?

I decided to find out.

I went back to the dataset builder, increased the sample size to 500,000, and hit enter. The script spun up again, flooding the terminal with new routes. It felt alive. South Canal, North Halsted, West Division, North Broadway. The city’s vocabulary pouring into the screen like rainfall. I let it run overnight and woke up to a folder five times the size of the original.

Uploading the larger dataset to Minibase felt like sending a challenge into orbit. The training run this time took longer, hours instead of minutes. The progress bar crept forward in quiet determination. I kept checking in, sipping coffee, watching loss values drop as if the model were slowly carving the map into its own internal geometry.

When it finally finished, I loaded up a test. The first question I asked was simple: “How do I get from Navy Pier to Union Station?”

The response came back almost instantly.

“Start at Navy Pier. Head west on Grand Avenue. Turn left on Lake Shore Drive. Turn right on E. Wacker Dr. Turn right on W Madison St. Destination will be on your right.”

I read it twice. Every step was correct. The directions were clean, confident, and eerily familiar. It had figured it out. Not just memorized the data, but truly learned the logic of the streets.

I tried a few more routes. Wrigley to the Art Institute. Chinatown to the West Loop. Hyde Park to Lincoln Park. Each time, the model spoke with clarity, weaving through the grid like a native.

There was a moment of quiet wonder as I stared at the output. A small, 300-megabyte model, trained on a half million examples, had absorbed the structure of an entire city. It understood Chicago in a way that was compact, elegant, and completely offline.

That was when I realized something important. The limits of small models are not defined by their size, but by how precisely we teach them to see. In that moment, the model was no longer a bundle of weights. It was a tiny, self-contained map of Chicago, alive in its own way.

Taking It to the Streets

At some point, testing on a laptop stopped being enough. I needed to know if the model could actually guide me through the real city, not just print directions in a terminal. So I decided to take it outside.

It was a clear morning in Chicago, the kind that feels awake before you are. I loaded the model onto my phone, switched to airplane mode, and stood near the edge of Millennium Park. Tourists were already crowding around The Bean, the smell of coffee drifted from Michigan Avenue, and the wind coming off the lake had that sharp bite that wakes you up instantly.

I opened the app and typed, “How do I get from Millennium Park to Wrigley Field?”

The model thought for a few seconds, then produced a clean, confident plan:

“Start on East Randolph Street. Turn right on Michigan Avenue. Turn right on E Ontario St. Turn right on N Rush St for 0.7 miles. Continue onto N State Pkwy. Turn left onto W Schiller St. Right onto N Clark St for 2.9 miles. Destination will be on your right.

No internet. No GPS. Just text from a small model running locally. I smiled, slipped the phone into my pocket, and started walking.

As I moved through downtown, I followed its instructions turn by turn. The sounds of the city layered themselves over the experience: the clatter of the elevated train overhead, the echo of footsteps under the tracks, the short bursts of traffic lights changing rhythm. Each turn became a test case. Each intersection was a question: Does it know where I am now?

By the time I reached Lakeview, the directions had lined up almost exactly with reality. Addison Street appeared ahead of me, traffic thickening near the stadium. The red Wrigley marquee came into view, glowing in the late afternoon light.

I stopped and looked at my phone. The model’s last line was simple: “You have arrived.”

It hit me then that it had not just memorized sentences from a dataset. It had built a functional understanding of space. It could reason about a city it had never truly seen, using nothing but words and structure.

That was the moment the experiment stopped feeling like code and started feeling like possibility.

Lessons from a Small Model

By the time I finished the experiment, the lesson was obvious. Size is not the only path to intelligence. What mattered more was focus. A small model with the right data can think clearly within its domain, sometimes even better than a giant model that tries to think about everything at once.

This project showed that when the data is clean, specific, and meaningful, even a few hundred megabytes of parameters can learn something profound. The Chicago navigation model never had the power of a foundation model, yet it reasoned like one inside its limited world. It understood the structure of a city, how roads connected, and how to describe that logic in human language.

Specialized models have a quiet advantage. They are narrow but deep. They do one thing, and they do it well. By training a model that only needed to know about Chicago streets, I gave it permission to ignore everything else. It did not have to explain world history or write poems. It just had to find its way from one point to another, and that focus made it powerful.

The process of getting there was surprisingly simple thanks to Minibase. I uploaded the dataset, selected the small base model, and started the fine-tuning run. No fleet of GPUs. No complicated infrastructure. Just a straightforward training pipeline that handled the heavy lifting. Within a few hours, the model was ready for testing. A few more clicks, and it was deployed locally.

The entire workflow took less time than a typical cloud deployment, yet the results felt almost magical. It proved that the barrier to entry for high-quality AI work is falling fast. With the right tools, anyone can build and test their own specialized models, even on a laptop.

The Chicago experiment was a reminder that progress does not always come from scaling up. Sometimes it comes from scaling down and focusing sharply enough that the model begins to see the world in detail.

Where This Could Go

Walking back from Wrigley, I kept thinking about how strange it felt to be guided by something that small. A few hundred megabytes of math had just navigated one of the busiest cities in America, all without touching the internet. That thought opened a door in my head. If a compact model could learn Chicago, what else could it learn?

It is easy to imagine where this might lead. Picture hikers exploring remote mountain trails with tiny models trained on local terrain, able to give safe routes without ever needing a signal. Picture delivery drones mapping entire neighborhoods through lightweight onboard AIs that never rely on the cloud. Picture small robots navigating warehouses or farms using models that understand their surroundings completely offline.

Cities themselves could become learnable objects. Each one could have its own distilled model, an AI that understands its layout, traffic rhythms, and unique quirks. The idea of “city models” living locally on devices feels almost poetic. They would not just reflect geography, but personality. A compact Chicago model would feel different from a compact Tokyo model, both shaped by the streets they know.

All of this came from a simple experiment with a dataset and a hunch. It made me realize that intelligence does not always require scale or distance. It can live close to the ground, in small focused systems that learn their world deeply.

Maybe the future of AI is not about models getting bigger. Maybe it is about them getting closer.

The City That a Model Remembered

I ended the day back where it started, standing under the shadow of Willis Tower as the sun dropped behind the skyline. The air was cooler now, the rush-hour crowd spilling in waves across Wacker Drive. I pulled my phone from my pocket and opened the model one last time. The terminal screen blinked quietly, waiting for another question.

I asked it for directions back to where I already stood. A small, circular test. The model paused, then returned a simple message:

“You are already here.”

Follow us on Twitter

Join our Discord

TL;DR: We’re releasing a small, high-quality Spanish-to-English translation model that runs locally with low latency and strong fluency scores. The model is available on HuggingFace or Minibase.ai for fine-tuning and API calls. You can test out the model immediately, and entirely for free, at the minibase.ai website.

Most translation systems are large and cloud-based. They’re accurate but slow and can’t run locally. Today we’re releasing a lightweight (~300MB) Spanish-to-English translation model that can run offline, on your own devices, and performs nearly as well as many larger commercial systems. Its latency is only 111 ms, meaning you get translations nearly instantaneously.

We trained this model in less than an hour, with zero code, using Minibase.

We measured translation quality using METEOR, chrF, and Semantic Similarity.

• METEOR: 79.7 — measures word-level similarity, considering synonyms and order.

• chrF: 72.7 — measures accuracy at the character level, good for Spanish morphology.

• Semantic Similarity: 70.9 — checks that meaning is preserved.

• Latency averages 111 ms, and the model is only 386 MB in size.

Examples

Input (Spanish):

La inteligencia artificial está revolucionando el mundo de la tecnología.
Cada día vemos avances increíbles en el procesamiento del lenguaje natural.

Output (English):

Artificial intelligence is revolutionizing the world of technology.
Every day we see incredible advances in natural language processing.

Input (Spanish):

El gobierno anunció nuevas medidas económicas para enfrentar la inflación.
Se espera que los precios comiencen a estabilizarse en los próximos meses.

Output (English):

The government announced new economic measures to address inflation.
Prices are expected to begin stabilizing in the coming months.

Input (Spanish):

Messi fue nombrado mejor jugador del torneo después de marcar tres goles en la final.

Output (English):

Messi was named the best player of the tournament after scoring three goals in the final.

Like all Minibase models, we’re releasing this one under Apache 2.0. You can download it, fine-tune it, or deploy it directly from Minibase Cloud. To share results or feedback, join the Minibase Discord.

TL;DR: We’re releasing compact models for Named Entity Recognition (NER). These model can run locally on a CPU and quickly identifies people, organizations, and locations with near-perfect recall. There is a Standard and Small version.

Both models are available on HuggingFace (Standard & Small) or Minibase.ai for fine-tuning or API calls.

NER models extract names and places from text. They’re used in search engines, finance systems, and research pipelines to turn unstructured text into data. Most existing models to do this task are large or slow, however, and so we trained small models (both sub-400 megabytes) that run locally and output structured JSON. Each model took about an hour to fine-tune on Minibase, with zero code.

We evaluated each model by precision, recall, and F1 score — how many entities the model finds and how accurate they are. For the Standard model, which is 369MB in size, those metrics are:

• Precision: 91.5%

• Recall: 100%

• F1 Score: 95.1%

• Latency: 323 ms

For the Small model, which is 143 MB, those metrics are:

• Precision: 63%

• Recall: 34.3%

• F1 Score: 43.5%

• Latency: 76.6 ms

The Standard model, clearly, is much more accurate. We recommend using it over the Small variant.

Examples

Input:

Microsoft Corporation announced that Satya Nadella will visit London next week.

Output:

{”PER”: [”Satya Nadella”], “ORG”: [”Microsoft Corporation”], “LOC”: [”London”]}

Input:

The University of Cambridge is located in the United Kingdom and was founded by King Henry III.

Output:

{”PER”: [”King Henry III”], “ORG”: [”University of Cambridge”], “LOC”: [”United Kingdom”]}

Input:

John Smith works at Google in New York and uses Python programming language.

Output:

{”PER”: [”John Smith”], “ORG”: [”Google”], “LOC”: [”New York”], “MISC”: [”Python”]}

Like all Minibase models, these are being released under Apache 2.0. You can download either model and use it for free. To share results or feedback, join the Minibase Discord.

This model is available on HuggingFace or Minibase.ai for fine-tuning or API calls.

Most text-to-text summarizer models are designed to write entire paragraphs. But there is also a need for tiny text preview models, similar to those already being used to summarize Gmail subject lines, news alerts, and push notifications. We trained a lightweight model to do exactly that. It is small enough to run locally, fast enough for real-time use, and we trained it in less than an hour on Minibase.ai with no code.

We measured our model’s performance using a metric called ROUGE, which compares word overlap between a model’s output and human-written references.

• ROUGE-1 measures single-word matches.

• ROUGE-2 measures two-word phrases.

• ROUGE-L measures longer sentence structures.

On the CNN/DailyMail benchmark, our model scored:

• ROUGE-1: 30.2

• ROUGE-2: 14.1

• ROUGE-L: 23.8

Our model also has a measured compression ratio of 22%, which means its outputs are about one-fifth the length of its inputs. Its average latency is 218 ms.

Examples

Input:

The World Health Organization declared the monkeypox outbreak a global health emergency after cases rose sharply in Europe and the Americas.
More than 16,000 infections have been confirmed across 75 countries, and governments are rolling out vaccination programs.
Health officials emphasized that coordinated action will be crucial to contain the spread.

Output:

WHO declares global health emergency over surging monkeypox cases

Input:

The United States announced new sanctions on Russian banks, defense firms, and energy companies following recent attacks in eastern Ukraine.
President Biden said the measures were designed to isolate key parts of Russia’s economy and pressure Moscow to end the conflict.
European allies are expected to impose similar restrictions later this week.

Output:

US imposes new sanctions targeting Russia’s economy amid Ukraine war

Compared to summarizers like BART or Pegasus, the Minibase model is smaller and faster, but not more accurate. BART tends to produce longer summaries with higher ROUGE scores, for example. The trade-off here is that our model, at 368 MB, runs on CPUs and still captures the key topic cleanly. Like all Minibase models, it’s released under an Apache 2.0 license.

You can download it, fine-tune it, or deploy it directly from Minibase Cloud. To learn more or share results, join us on the Minibase Discord.

TL;DR: We’re releasing a small text-to-text model that de-identifies personal information with strong performance. The model is available on HuggingFace, or can be accessed on Minibase.ai for immediate queries or API usage (no setup required.)

De-identification algorithms are used in lots of places. Hospitals use them to scrub patient names and dates from medical notes, for example, and lawyers do the same to redact client identities. It’s not a good idea to just delete sensitive data, either, because the surrounding context is often useful. The best tools for de-identification, then, ought to remove identifying details without stripping away any other words.

Most existing de-identifiers, though, are either rule-based (meaning they follow a “hardcoded” script) or large, domain-specific models. These models tend to either over-mask (removing too much) or under-mask (leaving sensitive information intact). A majority are also too big to deploy locally with low latency.

At Minibase, we decided to train a small model that is fast, runs locally — even from a browser — and works across many text domains and in any language. We trained this latest model, called DeId-Small, in less than one hour with zero code.

There are three key metrics for ranking de-identification models: how well they detect personal information, how completely they remove it, and how much of the original meaning they preserve. On our benchmarks, DeId-Small achieved a 100% detection rate for texts containing personal information, completely sanitized about 65% of them, and retained over 80% of the original meaning. The model is only ~136 MB in size and runs in under half a second per request.

The inputs and outputs look like this:

IN: Patient John Smith, born 1985-03-15, lives at 123 Main St.
OUT: Patient [FIRSTNAME_1] [LASTNAME_1], born [DATE_1], lives at [STREET_1].

IN: My friend David Wilson is getting married June 15, 2025 in Napa. Reach him at david.wilson@gmail.com.
OUT: My friend [FIRSTNAME_1] [LASTNAME_1] is getting married [DATE_1] in [CITY_1]. Reach him at [EMAIL_1].

Our results hold up well compared to other approaches on HuggingFace. Rule-based systems tend to break when formats change, and large multilingual models like mT0-XL are strong but weigh several gigabytes and are slow. We think DeId-Small strikes the right balance between being balanced, open-source, super compact, and fast. It is released under an Apache 2.0 license.

If you have any questions, or want to contribute datasets and ideas, come join us on the Minibase Discord.

Subscribe now

TL;DR: We’re releasing two small text-to-text models that detoxify language with strong performances. Both models are available on HuggingFace today (Small & Standard), or can be accessed directly on Minibase.ai (links to Small & Standard models) for further fine-tuning or API calls.

The internet is a toxic place. People say mean things all the time, and their words can be hurtful :( Companies dealing with this problem can’t just delete comments, though, because sometimes the underlying sentiments are worth keeping. The real challenge is removing mean language without stripping away the meaning.

Detoxifier models are already used in lots of places. Twitch uses them to moderate live chats. Discord bots scan text in real time and rewrite or suppress toxic language. YouTube flags offensive comments, while Reddit uses Perspective to catch toxicity in specific subforums.

Most existing detoxifiers, though, either go too far, rewriting the sentence into something bland, or not far enough, letting hateful text slip through. A majority of these models are also quite large, which means they cannot be deployed locally with extremely low latencies. Therefore, we decided to train two small detoxifying models that are extremely fast and can be run locally — even from your browser. Both models were trained on the Minibase platform, which is currently entirely free to use (in beta), in a couple hours.

There are three key metrics for ranking detoxifying models: how much toxicity it removes, how well it preserves the original meaning of a text, and whether the rewritten text still sounds natural. Using the ParaDetox dataset as a benchmark, our Detoxify-Medium cut toxicity by about 91% while keeping more than half the original meaning and scoring 93% on fluency. Detoxify-Small reduced toxicity by about half, but has a latency under 70 milliseconds and is only about 140 MB in size.

Both models successfully rewrite text:
“This is fucking awesome!” —> “This is really awesome!”

“You stupid idiot, get out of my way!” —> “You silly person, please move aside!”

These results hold up well compared to other models on HuggingFace, too. BART-based detox models are strong on meaning preservation, but they come in at half a gigabyte and don’t run easily on small machines. Multilingual models like mBART or mT0-XL do better in some languages, but they are several gigabytes and slow. Both Minibase models are being released under an Apache 2.0 license.

If you have any questions, come join us on the Minibase Discord.

Today we released a bunch of features for Minibase, including a public marketplace, improved training insights, and several tools to make your workflow smoother. Remember that Minibase is in public beta and is currently free to use. Join our Discord community to learn more.

Model & Dataset Marketplace

We’ve launched our new Model & Dataset Marketplace, a community hub where you can share models and datasets. Users can set the privacy for each item (Individual, Team, or Public). Public models will appear in the marketplace, where others can view them and add them to their own workspace. Datasets remain secure—others cannot download your raw data locally.

Redesigned Model Detail Pages

Model and dataset detail pages have been redesigned. Whether in the marketplace or under your “Datasets” and “Models” tabs, you can now see much more information at a glance.

Training Performance Metrics

After training a model on Minibase, you’ll now receive automatic evals and tests by email. These metrics give you deeper insight into the quality of your model, and we’ll be expanding them over time.

Post-Training Editing

You can now edit your model name and description after training, and the same goes for datasets. This makes it easier to keep your workspace organized as your projects evolve.

Synthetic Data Generation

We’ve added a tool for synthetic data generation. You can describe the problem you’re solving, provide seed examples, and set a target number of datapoints. Minibase will generate examples continuously until your desired dataset size is reached.

Continue Training

You can now continue training a model after the initial run, even if it has already been deployed and tested. This makes it easier to fine-tune using additional datasets without starting from scratch.

Reliability Improvements

We’ve fixed several issues related to dataset uploads, training, inference, and more, making Minibase more stable overall.

Better Base Models

Finally, we’ve improved the quality of our base models, so you’ll see higher-quality outputs across all training workflows.

Full HF Fidelity

We’ve added full HF fidelity for all models, including chat models. This means you can now deploy models in full fidelity without compromise. We’ve also updated the inference server to better handle large files, making deployments smoother and more reliable.

Tooltips and UI Improvements

We’ve started rolling out tooltips, beginning with the model detail view. Many of these tooltips are linked to our Help Center (help.minibase.ai) articles, which we continue to expand on a weekly basis. Alongside this, we made numerous small improvements across the product—updated copy, clarified text, and polished flows—to make the interface easier to use.

Subscribe now

We’ve been hard at work building new features. And we think this release is a big step toward making Minibase faster, more flexible, and more collaborative. We can’t wait to see what you build.

— The Minibase Engineers

Most machine learning projects fail because of data. It’s easy to imagine a task in your head (like “train a small model to summarize research paper abstracts”) but much more tedious to actually assemble the dataset needed to train that model. Collecting clean data can take days or weeks, and it’s the bottleneck that kills most ideas.

Our goal at Minibase.ai is to remove as many of those bottlenecks as possible. Small models are most useful if you can fine-tune them on the right data and ship them quickly. So today, we’re releasing a beta version of our synthetic data generator.

If you give this tool five to twenty high-quality “seed” examples, it will produce a thousand or more additional rows in minutes. All of its output data is automatically formatted, so it can be used to train any Minibase model. It won’t replace real data, but it will get you from “I have an idea” to “I have a training set” fast.

Getting started is easy. After logging into your account, navigate to the ‘Datasets’ tab and click on “Generate Dataset.” (It’s the big purple button.) Then, follow the prompts. The tool will ask you to answer some questions and then input several “seed” examples. Each seed example should have the same three columns: Instruction, Input, Response. 

• Instructions are rules your model must follow. If you’re building a small model to do email spam filtering, for example, then your Instruction might be “Classify this email as either spam or not spam.”

• Inputs are the actual data points; in the case of our email spam example, these would be real email examples with or without subject lines, messy forwards, terse internal notes, promotional blasts, and so on.

• Responses are what the model should produce as output (such as “spam” or “not spam.”) The model learns what “good” outputs look like from your Responses.

When you click “Generate,” we send your seeds to a quorum of different large language models. We take responses from one of those language models, and then use them as seeds for other language models. In this way, we can generate synthetic datasets that are actually diverse and cover a broad set of examples. In practice, our tool generates anywhere from two to ten rows of data per second, depending on the length of each seed.

After your dataset has been generated, you can use it to train models immediately. The generator writes everything into Minibase’s standard format, masks targets correctly (so your model learns to produce the Response, not recite the Input), and sets aside a hold-out split by default so you can evaluate your model’s accuracy easily.

Of course, this tool doesn’t change the fact that the best data is specific to your task and, often, real. If you can gather and refine a thousand hand-labeled examples from your own workflow, you should do that; it will almost always beat a synthetic dataset. We recommend using this tool as an assistant, rather than a replacement, for real data collection. It’s most useful for making quick prototypes or getting models deployed as quickly as possible to run tests and benchmarks.

Still, this synthetic data tool is another step toward our ultimate goal of making model-building as frictionless as possible. If it sounds useful, sign up for a minibase.ai account today and start using it and training models entirely for free. Also, get in touch with us on Discord and let us know what to build next.

— The Minibase Engineers

A CNN is a type of neural network designed to recognize patterns in data — such as images — by applying small filters, or convolutions, across local regions instead of connecting every input to every neuron. This makes them efficient at detecting shapes, edges, and textures, which stack together to recognize more complex features.

We assembled some resources that do a great job at explaining CNNs and how they work. At the end of this post, we also round up some recent developments in small, open-source models; the first post in what will be a weekly links series.

1. Setosa.io: Image Kernels, Visually Explained

We think the best way to start learning about CNNs is to see how convolutions work visually. This website does a great job at that. It explains how a kernel is just a tiny matrix, and convolution is just “multiply and sum” as it slides across an image. You will walk away knowing what convolution does, rather than solely what it is.

2. CS231n: Deep Learning for Computer Vision (Stanford)

This is the gold standard. All the lecture videos are available online, and the final assignment will challenge you “to train and apply multi-million parameter networks on real-world vision problems” of your choosing. The course opens by explaining image classification with linear classifiers, but quickly moves into CNNs (by week 5). Plus, one of the lecturers is Fei-Fei Li.

3. TensorFlow Playground

Though not strictly CNN‑focused, TensorFlow has a super friendly entry point into neural nets. You can toy with learning rate, activation functions, and regularization directly in the browser. It’s low‑stakes exploration that builds understanding of what training looks like. Once you’re comfortable with that, CNNs don’t feel quite as exotic.

4. CNN Explainer

This is an interactive explainer on CNNs where you click layers, watch kernels slide, and explore how neurons compute step by step. It doesn’t just tell you what’s happening, but shows it to you. It also runs in your browser with no installs needed.

5. Distill: Feature Visualization

Once you know what CNNs do, you might start to wonder more about how they do it. This article explains it without resorting to too much math. It shows how you can reverse‑engineer what activations “look for,” using optimization to generate what a neuron cares about. It starts from the simplest idea (push the network to activate one neuron) and then explains the pitfalls and tricks, like avoiding noise and encouraging diversity. The visuals are really beautiful.

This week in AI:

With an emphasis on small and open-sourced models.

1. Microsoft releases VibeVoice, an open-source text-to-speech model with just 1.5B parameters.

2. rbio1: A reasoning model for biology.

3. “Google says it dropped the energy cost of AI queries by 33x in one year.”

4. Agent-C, an ultra-lightweight AI agent that communicates with an OpenRouter API.

5. xAI open-sources Grok 2.5.

6. Using AI to identify sketchy science journals.

7. Bottlenecks in scaling AI for software engineering.

8. xAI released grok-code-fast-1, “a speedy and economical reasoning model that excels at agentic coding.”

9. Hunyuan open-sources their end-to-end Text-Video-to-Audio framework.

This arrangement does not make sense, whatsoever, for most tasks. If you need fine-grained control or care about where your data lives, you run into limits fast. The big models from OpenAI and Anthropic are also largely uninterpretable, so it’s rarely clear why they give the outputs they do. And because their training is so broad and diffuse, they often stumble on narrow, tightly scoped jobs.

For most tasks, small models are not only more accurate than the big foundation models; they are also cheap to train and serve, quick to start, and compact enough to run on a laptop or phone with predictable latency and costs. And because small models are trained on a well-defined task, they’re much easier to fine-tune on your data, easier to debug, and less likely to drift off-task. You can also keep them private so your data never leaves your own environment.

That’s why we built Minibase.ai, which is now in public beta. Minibase is an all-in-one place to design, train, and deploy small models that do one thing exceptionally well. Everything runs in your browser, with no code required, and your datasets are private by default. When you finish fine-tuning, you can run the model in Minibase Cloud or download it to run locally. Either way, you control everything you create and share.

While we’re in beta, it’s entirely free to create an account, invite up to twenty teammates, upload datasets, and train and deploy models. In return, all we want is your feedback. Kick the tires around, join our Discord, and tell us what to build next!

Subscribe now

It’s easy to get started. Sign up with your email, log in, and you’ll see two tabs: MODELS and DATASETS. These hold everything you’ve uploaded and everything you’ve trained. Click + Train New Model to start an automated workflow, where you can pick a base model, attach a dataset, and fine-tune the model to make your own custom creation. A progress bar tracks training progress. And when it’s done, you can chat with your model in the browser, see how it behaves, and tune settings before you deploy.

Minibase currently has four different models. The Task Base model handles tight, structured inputs and outputs — summaries, translations, labeling, extraction, and instruction-following. The Language Base model gives you more context length, for when inputs are longer. The Micro Base model is our smallest; it’s best for short, repeatable tasks and can run on a smartphone. And finally, the Chat Base model supports multi-turn conversation and simple reasoning. It’s great for lightweight bots and assistants. You can find more details on each Base Model in our Help Center.

When you’re ready to ship a model, you also have many options. You can immediately test the model in your browser (through a chat box) and then deploy to Minibase Cloud to call it from your app via API. Or, you can just download the model in its entirety and run it on your own hardware. Again, you own what you create.

Most AI platforms are built around massive, opaque systems. Those platforms strip power from the users and aggregate it in the hands of a massive corporation. Minibase is built around small, interpretable models that you can actually understand. These mini models are trained on your data. You can run them on your laptop or phone. And you don’t have to trade control for capability. If that sounds like the future you want, sign up and start building small models today. Tell us what’s missing, and we’ll add it.

minibase.ai

— The Minibase Engineers

Here’s how I think about it:

First, remember that language models generate text one piece at a time. Those pieces are called tokens. A token isn’t always a full word; it might be a word (“cat”), part of a word (“ing”), or sometimes even punctuation. The important thing to note is that models don’t “think” in terms of sentences or paragraphs, but rather in terms of which token should come next.

Each time you type something into a model, it reads all the tokens you gave it, predicts a list of all possible next tokens, and assigns each of them a score for how likely they are to follow.

Those scores are called logits. A logit is just a number the model generates for each possible token before turning it into a probability. Bigger logits mean that a word is more likely to be the next token, while smaller logits mean a word is less likely. But a logit is not a probability, which is a bit confusing! 

To turn logits into actual probabilities, the model first runs them through a function called softmax, which basically says: “exponentiate all the logits, then divide each by the sum so they all add up to 1.” At that point, you have a list of probabilities for every possible next token.

I think the best way to truly grasp this is to look at an example. Let’s say a model is writing a paragraph of text, and it thinks the next token could be either “cat,” “dog,” or “banana,” with logits of 2.0, 1.0, and 0.1. The highest logit is for cat, and so that’s the word we would expect to come next. But this is where temperature comes in…

Temperature is a way to mess with the conversion between logits and probabilities. The gist is that, before the model applies the softmax function to convert logit → probability, it first divides each logit by the set temperature value. 

If the temperature is less than 1, the differences between logits get bigger, so the most likely token is assigned a higher-than-expected probability. The least likely tokens nearly disappear, and the model becomes more conservative or predictable. 

If the temperature is greater than 1, the differences between logits get smaller, and the probabilities flatten out. That means the model will pick less obvious tokens more often. (If you’d like to see the actual math equation for temperature, check out our footnote.1)

Let’s go back to our example with cats, dogs, and bananas. Remember that these have logits of 2.0, 1.0, and 0.1.

Now, if we set temperature = 1.0, then basically nothing happens because we’re dividing each logit by 1.0. So softmax would turn these logits into probabilities of about 66% for “cat” (2.0 logits / 3.1 total logits), 24% for “dog,” and 10% for “banana.” The model will usually say “cat” but sometimes “dog” or “banana.”

If we set temperature = 0.5, then we are dividing each logit by 0.5 and thus doubling its value. Now the gap between logits becomes bigger! The probability of “cat” jumps to about 86%, “dog” falls to 12%, and “banana” is almost gone at 2%. The model becomes much more predictable.

And finally, if we set temperature = 2.0, we’re dividing each logit in half such that the differences between them become smaller. Now the probability of the next token being “cat” drops to about 50%, “dog” climbs to 30%, and “banana” rises to nearly 20%. The model’s outputs become more varied.

Temperature isn’t unique to language models. This general concept can be used with any model that outputs a probability distribution over possible actions. In image generation, it can change how adventurous the model is with details. In speech synthesis, it can affect how much pronunciation varies. In reinforcement learning, it can make an agent more exploratory. The principle is always the same.

I think the key to understanding temperature is to stop thinking of it as a creativity dial, though, and start thinking of it as a way of reshaping probabilities. It doesn’t make the model smarter or dumber, but simply changes how much it sticks to the safe bet versus taking a chance.

If you want to learn more about AI, join our Discord community! Or visit us at minibase.ai.

— Minibase Engineers

The current batch of language vision models — including Claude 3.5 Sonnet, GPT-4o, Gemini 1.5 Pro, and Llama 3.2 90B Vision — should, in theory, be able to do this for scientific papers! It’d be great to, say, automatically interpret the data plotted in charts or look at a written protocol and then figure out which machines to use to run that experiment. This could save scientists a lot of time.

Unfortunately, data from a new benchmark, called MaCBench, suggests that vision-language models are not at all ready to do this type of work, at least for chemistry and materials science tasks. The paper was published in Nature Computational Science a few days ago. 

The TL;DR is that MaCBench is a huge dataset with 1,153 tasks, including 779 multiple-choice questions and 374 numeric-answer questions.1 These tasks, together, cover three types of scientific work: data extraction (scraping numbers from charts or tables), experiment execution (identify equipment or figure out if an experiment is safe or not), and data interpretation (look at a chart and interpret the results). All of the questions in MaCBench were built from real scientific figures, including some generated by the authors to avoid giving the models anything they might have memorized from the web.

Those models that I mentioned earlier were evaluated using MaCBench. The results were not flattering. Of the four models evaluated, Claude 3.5 Sonnet did the best. But it, too, stumbled badly in many areas. Here’s a quick look at the results:

Data extraction: Average accuracy across models was 0.53 for extracting data from tables. Llama 3.2 90B Vision performed no better than random guessing. Models did well at identifying hand-drawn chemistry molecules (Claude 3.5 Sonnet: ~0.80 accuracy) but almost failed when asked about the isomeric relationship between chemical compounds (average ~0.24, baseline ~0.22).

Experiment execution: Models were able to identify equipment with an average accuracy of 0.77, but safety assessment questions dropped to 0.46.

Data interpretation: The benchmarks include some images obtained using atomic force microscopy, and the models interpreted them with a score of just 0.24. For mass spectrometry and NMR, which are widely used by biochemists to study proteins, the models averaged 0.35. These scores are really low.

Note that performance in this context is actually “accuracy above random guessing.” In other words, the reported values are not the raw percentage of correct answers. Instead, the authors took each model’s raw percentage accuracy and subtracted its random, baseline accuracy. (There are four possible answers for each multiple-choice question, so a model would get 25% correct just by chance. If that model answered 85% of questions correctly, then its performance score would be given as 60%, or 0.60.)

To figure out why these models are so bad at certain tasks, the researchers did a series of ablation experiments. This basically means that they removed certain parts of the AI models to see which parts were causing the low scores. So they might give a model the exact same scientific information either as a text or as an image, for example, and then see how well it answers the same questions.

And it turns out that models perform way better when given the same data in text form rather than as an image. For one ablation experiment, the authors gave each model the exact same information (from an x-ray diffraction experiment, which is used to study a protein’s structure) as either typed-out numbers or as a graph. Models were about 35% more accurate at figuring out the x-ray data’s “peak positions” for the typed numbers. The authors also found, unsurprisingly, that a model’s performance correlates with how common the example is on the internet. Models were better at answering questions about more common protein structures, for example, suggesting they are using pattern matching rather than genuine reasoning.

These results do not bode well for the near-term creation of AI scientists. Dario Amodei, CEO of Anthropic, famously predicted in his essay, called Machines of Loving Grace, that “powerful AI could at least 10x the rate of [scientific] discoveries, giving us the next 50-100 years of biological progress in 5-10 years.” Unfortunately, that outcome seems more distant than many initially anticipated.

One way to resolve these issues is to move away from all-in-one or general purpose models. Instead, scientists could train smaller models — one fine-tuned for reading x-ray data, another for parsing certain data files, and so on — and string them together to build more accurate workflows. That would mean giving up the convenience of a single “ask it anything” system, of course, and it would require the data and know-how to fine-tune each model. But the payoff would be far higher accuracy and much more control over each scientific workflow.

The reason most scientists aren’t doing this now is because it takes so much work. Collecting enough labeled data for each sub-task is probably a months-long project in itself. Setting up the infrastructure to run multiple models in a row is another. But for now, if you want automation you can trust with real experiments, it’s probably the only realistic path. 

We’re making it simple to train and deploy small AI models at minibase.ai. If you’re excited about this, join our Discord community!

– MiniBase Engineers

We’re building MiniBase.ai to help anyone design, train, and deploy small models.

Such “tiny” models have been used for decades. Your phone’s keyboard is running a small language model to guess the next word as you type. Noise-cancelling headphones run a model that predicts and subtracts background noise in real time. Cameras in phones use small vision models to detect faces and adjust focus. Email services run spam filters trained to recognize patterns. And so on.

Small models — often under 10 GB in size — can also outperform large models on narrow tasks. The Orca 2 model (~5 GB) outperforms models 5–10× larger on complex reasoning benchmarks in zero‑shot scenarios. The Phi‑3 family of models (as small as ~1.8 GB) consistently beat slightly larger models in benchmarks covering language, coding, and math.

Even the frontier laboratories are releasing smaller, open-weight models. OpenAI recently released their gpt-oss models, for example, under a permissive Apache license. The smaller version only has 21 billion parameters (~16 GB) but performs comparably to o3-mini on most tasks.

As more and more developers turn to small models, it’s inevitable that more companies will pop up to serve them, too. HuggingFace already offers more than 600,000 models, many of which are small enough to run on a laptop. Their community has also uploaded thousands of datasets and training scripts to reproduce those models. Databricks, similarly, has tools to fine-tune and deploy models. Both of these companies make it possible for a small team to go from raw data to a deployed model without owning a GPU cluster.

But although Hugging Face and Databricks are extremely powerful, they are marketed primarily at developers. If you were, say, a student who wanted to train a model to identify bird species, run it on a Raspberry Pi, hook everything up to a camera, and then mount it on a bird house — where would you start?

The model names on Hugging Face are esoteric and difficult to parse. (What’s the difference between Phi-3 and Phi-3.5-mini-instruct? ) It’s often unclear what dataset is best-suited to training, or how that dataset should even be structured or collected in the first place. And even if these two problems are resolved, you still need to deal with Python environments, GPU drivers, and memory limits. There is a lot of troubleshooting required.

MiniBase.ai is designed to solve these problems. We’re building the tools and infrastructure required to make data cleaning and model training as painless as possible. With our tools, absolutely anyone can train, fine-tune, and deploy their own tiny models. We are also growing a community around these tools, where users can be paid for their datasets and models. 

We’ve spent the last few months talking to dozens of hobbyist model builders. We’ve helped scientists build “fraud detector” tools that speed up their searches for papers with statistical or image anomalies. And we’ve talked to founders at companies that have already trained models in-house, but now just want an easy solution to re-train or fine-tune those older models. Over time, we’ve come to believe that there’s a huge gap in the market for a community-based effort focused entirely on small AI models. So come join our community on Discord!

In the future, small models will be everywhere, running on whatever device happens to be nearby. Farmers will run small models on solar-powered sensors to track soil conditions without an internet connection. Office workers will carry models on USB sticks to automate dull parts of their job. These models won’t be remarkable for what they are, but for how common they’ve become; quiet pieces of software that do one job well.

— The MiniBase team

Subscribe now