DEV Community: Ian Khasky

What Does a 1 Million Token Context Window Actually Look Like?

Ian Khasky — Tue, 15 Sep 2026 01:03:03 +0000

"1M context" is now a normal line in model specifications. But it is a terrible human-scale unit. Most of us cannot look at:

1,000,000 tokens

and immediately understand how much information that represents.

One Million Tokens is an interactive site that fixes that problem.

🧠 It visualizes one million tokens as a huge stack of text and then walks through the history of context-window growth from GPT-3 onward.

The basic scale

The site uses the following approximate conversions:

1M tokens
~ 750K words
~ 3,000 printed pages
~ 83 hours of conversation
~ 75,000 lines of code

Those numbers are meant to be intuitive rather than universal. Tokenization varies significantly by content. But they give us the right order of magnitude.

A million-token window is not merely "a very long prompt."

It is a small library.

The timeline starts at 2,048 tokens

The site's story begins in June 2020.

GPT-3
2,048 tokens

That is visualized as roughly six pages. Then:

ChatGPT
Nov 2022
4,096 tokens

Then:

GPT-4 32K
Mar 2023
32,768 tokens

Then:

Claude
May 2023
100,000 tokens

The graph starts getting steep.

Gemini crosses the million-token line

The site marks February 2024 as the point where Gemini 1.5 Pro reached 1M tokens.

Google's own launch material from 2024 also described Gemini 1.5 Pro as supporting up to a 1 million-token context in preview.

That was the moment "million-token context" stopped being a research curiosity and became a product capability.

The site then continues into models with multi-million-token windows.

From 2K to 10M

The visualization's complete timeline reaches a cited 10,000,000-token window.

It calculates the increase from GPT-3's 2,048 tokens to 10M as roughly:

4,883x

That is a six-year change in the amount of information a model can accept in its working context.

The visual curve is more revealing than the number. For several years, context capacity barely moves. Then it starts climbing by orders of magnitude.

Why context matters for software development

For developers, context length changes the amount of a system that an AI can inspect at once.

A rough progression:

2K:
small snippet / short conversation

32K:
large file or several files

100K+:
substantial subsystem

1M:
large code collections / potentially repo-scale input

The site's rough 1M-token code equivalent is 75,000 lines at ~13 tokens per line.

That number should not be treated as a hard engineering rule. Code token density varies dramatically.

Python, minified JavaScript, JSON, comments, generated source, and strongly typed languages will all behave differently.

But the order of magnitude is still useful.

Does long context replace RAG?

Not necessarily.

A larger window reduces one reason we use retrieval: the inability to fit all relevant source material.

But retrieval also solves other problems. It helps:

remove irrelevant material
lower input cost
reduce latency
focus the model
update source data independently

So long context and retrieval are complementary.

A 1M-token window lets you choose to include far more source material.

It does not mean including everything is always optimal.

Context window != perfect memory

This is the biggest conceptual mistake I see in discussions of long context.

Maximum context length is a capacity limit. It is not a guarantee of perfect use. A model with a 1M-token window may still:

miss a fact that appears in the prompt
perform differently depending on where information appears
degrade on complicated cross-document reasoning
become slower or more expensive with huge inputs
retrieve some details better than others

This is why long-context benchmarks test retrieval and reasoning quality, not merely whether the tokenizer accepts the input.

I would phrase it like this:

context size = size of the desk

reasoning/retrieval quality = how well the model uses what is on the desk

A larger desk is useful. It does not automatically make the worker better.

The page comparison is approximate

The site uses:

1 page ~ 333 tokens

and therefore:

3,000 pages ~ 1M tokens

This is a visualization convention. Real documents vary. Tokenizers vary. Languages vary.

The site's 83-hour conversation estimate similarly assumes around 150 spoken words per minute.

These are reference points, not exact conversions.

The open-vs-closed view is interesting too

The timeline can be filtered between:

ALL
OPEN
CLOSED

That makes it easy to see how long-context capabilities moved from closed frontier APIs into open-weight models.

The page credits Hassan at Together AI as the creator.

Why I like the project

Model cards are full of abstract specifications.

128K context
1M context
2M context

This site converts those numbers into something human.

The next time someone asks what a million-token context window actually means, I would rather send them this visualization than another table.

Because after scrolling through 3,000 pages, the number finally feels real.

How much of a million-token window have you actually been able to use?

Tencent/TeamAI puts your team's agent config behind a merge request

Ian Khasky — Sun, 13 Sep 2026 18:47:53 +0000

I run three coding agents depending on the task, and I have never once managed to keep their rule files identical. They start as copies of each other. One picks up a new convention, another gets edited on a bad afternoon, and a few weeks later there is no answer to the question of which version the team actually agreed on. The agent reading the stalest copy is the one that argues confidently for last quarter's conventions in a review. 😅

Tencent published a CLI called teamai-cli that stops treating this as a discipline problem and treats it as distribution.

What lives in the repo

One git repo holds the whole harness, and each resource has a fixed home:

Resource	Path in the team repo
Skills	`skills/<name>/SKILL.md`
Rules	`rules/*.md`
Agents	`agents/<name>.yaml`
Hooks	`hooks/hooks.yaml`
MCP	`mcp/mcp.yaml`
Docs	`docs/`
Culture	`culture.md`

culture.md is the one I did not expect. It carries the team's mission, values and working principles, and it gets injected into each agent's CLAUDE.md or AGENTS.md, so every session inherits them without anybody pasting anything. docs/ is not all loaded by default, which the project calls progressive disclosure.

Setup

npm install -g teamai-cli
teamai init https://github.com/yourorg/yourrepo

Project scope is the default and installs the resources under the project directory. --scope user puts them under your home directory instead. The store can be GitHub, GitLab, GitCode, CNB, TGit or a git server you run yourself, so the repo can sit wherever your code already does.

The flow, which is the actual product

teamai push -> branch + MR -> reviewer approves and merges
                                       |
                                       v
             SessionStart hook -> teamai pull -> local agent config

That is it. A change to a rule goes through the gate a change to code already goes through. Prompt configuration gets edited by everybody on a team and reviewed by nobody, and it has the widest blast radius in the tree, because a bad rule is wrong in every session on every machine at once.

Nobody has to take all of it

teamai roles maps a role to a namespace so a member syncs only the skills their role needs. teamai tags lets people subscribe to the pieces they want. teamai source subscribes to another group's skill repo on top of your own, which is how a shared internal library arrives without a fork. And learnings/ at the repo root is shared with everyone while learnings/<project-id>/ stays project-private, so one client's notes stay out of the general pool.

What I counted before installing it

What decides whether any of this arrives on your machine is which agents the project actually covers, so I counted: 11 agents against 13 capability columns. Skills and docs are filled on all 11. Hooks, MCP and rules come in at 8 each. Usage, sessions and dashboard come in at 7. 🧐

The split decides something, because the automatic delivery runs off a hook. The project says every session pulls the latest with no manual sync, and its own flow diagram routes that through SessionStart, while three rows (OpenClaw, Hermes and DeepSeek Harness) show a dash in the hooks column. The project draws no conclusion from that and I am the one drawing it, but on those three the pull is something a person remembers to run.

The caveat

It sits one table away from the good part. Look at the env/ row: it offers "Shared team-level environment variables and switches" and then tells you not to put secrets in it. So the settings that cost the most to keep aligned, the keys and the endpoints, are the ones the repo will not hold. You still need whatever you were already using for that.

The architecture table labels two of its three layers beta: the recall that searches accumulated team experience, and the usage reporting. The distribution layer above is the one that is not.

Repo: https://github.com/Tencent/teamai-cli

Which pieces of your agent config would you actually want a reviewer to gate, and which would that just slow down?

Edge0 streams MoE experts off SSD to fit 35B in 3 GB

Ian Khasky — Sat, 12 Sep 2026 05:22:37 +0000

Where does a 35B model go when it only takes 2.9 GB of RAM? I went into Edge0 to find out, and I came out with a different mental model of what a local model costs.

What shipped

Edge0-AI open-sourced Edge0 the other day: a streaming inference engine under Apache 2.0, plus two preview models built on open sparse MoE bases. Edge0-35B-A3B sits on Qwen3.5-MoE 35B-A3B, 40 layers and 256 experts. Edge0-8B-A1B sits on inclusionAI's Ling 3.0 tiny, a hybrid that pairs multi-head latent attention (MLA) with MoE, 24 layers and 128 experts, about 1.2B active out of 7.9B. Both ship as 4-bit checkpoints, 19.6 GB and 4.55 GB on disk by the model cards. The clip of a 35B model answering on an iPhone at about 1 GB of peak memory is what made the rounds 🤯

The mechanism

In a mixture-of-experts model most of the parameters live in the experts, and the router only calls a few of them per token: 4 out of 256 here, about 3B active parameters out of 35B. A dense runtime loads every weight because every weight is used for every token. A MoE runtime has a choice, and Edge0 takes the aggressive one. The whole checkpoint stays on the SSD, the expert weights are memory-mapped, and only the routed experts are read as each token comes through. The project's own line is that peak memory is bounded by the active set rather than by the parameter count.

The numbers, all from the project and measured on a Mac mini M4 Pro with 24 GB of unified memory:

	edge0-35b	edge0-8b
Peak active memory, short context	2.9 GiB	1.0 GiB
Decode	14.9-17.7 tok/s	23.9-25.3 tok/s
Prefill	113 / 140 tok/s	500 / 1428 tok/s
Checkpoint on disk	19.6 GB	4.55 GB

The footnote on the memory row matters more than the row. It is a short-context figure: the KV cache sits in RAM, so a long prompt grows it, 3.3 GiB at 3.3k tokens on the 8B by the project's own note. Whatever you plan around, plan around that line moving.

The sums the table stops short of

Three things I worked out on top of the table. First, 35B at 4 bits is 17.5 GB of weights, so the 19.6 GB checkpoint carries about 2 GB at higher precision, presumably the embeddings, the attention weights and the quantisation scales. Second, 3B active at 4 bits is about 1.5 GB, so roughly half of the 2.9 GB peak is the routed experts and the other half is shared weights plus cache. Third, and this is the one I would watch: at 15 to 18 tokens a second, pulling a full 1.5 GB active set cold off the drive per token would need over 20 GB/s, and no consumer SSD does that.

So most expert reads must be served from the operating system's file cache, and my reading of "peak active memory" is that it counts the process's resident set while the mmapped pages the OS keeps cached sit outside it. A 24 GB Mac mini can hide a large share of the 19.6 GB checkpoint in that cache. A Mac with less memory cannot, and that is where the drive starts doing real work. I have not checked this against the code, so treat it as a reading, and as the first thing to measure on your own machine 🧐

Trying it

Install is a Python package, and the project wants Python 3.10 or newer on an Apple Silicon Mac. The one-liner:

pip install -e 'git+https://github.com/Edge0-AI/edge0.git#egg=edge0[fetch]'

Inside a checkout the project's own line is this, with the fetch extra pulling the checkpoint:

python3.12 -m venv .venv && .venv/bin/pip install -e '.[dev,fetch]'

Budget the 19.6 GB before you start, and put it on the drive you want reading from on every token, because that is what it will do.

One thing I hit in the repo rather than on a machine: garbled, mixed-language output on Apple A18 and A18 Pro is listed as a symptom of an older mlx. That is the only chip-level mention of an iPhone anywhere in the repo, and it points at a library version rather than at a build you can install on a phone.

What it costs

RAM is what you save. Disk, cache and speed are what you spend. The 35B checkpoint sits on the SSD for the whole session, decode is 14.9-17.7 tok/s on a desktop-class M4 Pro, and each token is a storage or cache read. I would want to know what that does to a drive over a few months before making it a daily driver, and the project does not say.

The caveat that matters most

The phone is in the demo video. The project says the MLX backend runs on macOS with Apple Silicon (M1 through M4) and that no other platform is supported yet, CUDA included. The "iPhone 15 Pro and newer" floor circulating in reposts appears nowhere in the README or the model cards, and what you can run today is a Python package on a Mac with 20 GB free.

Both models are also previews. The project's own eval has the 35B pipeline at 79.2 against 83.2 for the fp16 base, and tool use, multi-step planning and long-horizon autonomy are called weak. So this is a chat model that fits in a small RAM budget, and an agent backbone it is not yet.

Who it is for

Anyone with an Apple Silicon Mac that has more disk than RAM, which is most laptops. The mental model I took away: once expert weights stream from storage per token, the ceiling on a local model is your disk size, and RAM becomes a working-set budget, the way it is for a database. Repo: https://github.com/Edge0-AI/edge0/ and the 35B card: https://huggingface.co/Edge0/Edge0-35B-A3B-preview

If you run MoE models locally: do you already keep them on SSD with mmap through another runtime, and how did decode hold up past a few thousand tokens of context?

AI Video Just Became Programmable Television

Ian Khasky — Thu, 10 Sep 2026 03:18:42 +0000

A strange thing happened when fal made H3 Max faster than realtime.

The obvious benchmark story was:

a 5-second video can render in under 3 seconds.

The more interesting story is what developers started building once generation became faster than playback.

They built television.

The first demo got banned

Fal engineer Rehan Sheikh connected H3 Max to a livestream inspired by the "interdimensional cable" idea from Rick and Morty.

The important technical property was simple:

generation time < playback time

If the system can finish the next segment before the current one ends, the stream does not need to stop.

The experiment went viral.

It was removed from Twitch and then Kick.

Rehan later said both platforms banned the stream within an hour.

Instead of continuing to move between platforms, fal built its own.

fal.live is interactive AI television

fal.live is fal's experimental streaming platform.

It currently exposes generated channels such as:

Chaos
Sitcom
Anime
Soap Opera
Popcorn

Availability is still experimental, and individual channels can pause or reconnect.

The interesting part is the interaction model.

Viewers are not just watching.

They influence what happens next through prompts and voting.

That turns the stream into a feedback loop:

audience
-> direction
-> model
-> generated scene
-> audience reaction
-> next direction

📺 That loop is much closer to a game engine than a traditional video file.

Infinite Slop makes the idea even clearer

Pieter Levels (@levelsio) built Infinite Slop with fal.

The site describes itself very accurately:

an endless AI-generated TV channel

People type what they want to see next.

Suggestions enter a queue.

The system generates new scenes continuously.

It is chaotic and often absurd, but I think the roughness makes the underlying shift easier to see.

The audience is moving from spectator to input device.

H3 Max Director is the real technical story

The important release underneath these demos is H3 Max Director.

A normal video generation endpoint behaves roughly like this:

prompt -> request -> finished clip

Director behaves more like this:

open session
-> start stream
-> send direction
-> continue scene
-> send another direction
-> continue again

The session is carried over WebRTC.

According to fal's documentation, each generated segment continues with 39 frames of carried context.

Director also retains previous direction prompts as memory: 12 by default, configurable up to 50.

That matters because continuity is not being approximated only by giving the next request the previous final frame.

The model keeps a running context and evolves the same stream.

Fal's public Director sessions currently run up to 2 minutes. Longer sessions are being enabled gradually for approved use cases.

This changes what a video API can be

Most video APIs today produce assets.

You request something and receive a file.

Director starts looking more like a runtime.

That enables a different class of product.

Interactive stories

A viewer can choose what a character does next while the story is already playing.

Generative games

Game state can be converted into directions for the model.

Live visual agents

Speech, sensor data, an LLM or any other source of text can steer the visual stream.

Adaptive marketing

A live experience can react to the audience rather than playing one prerecorded creative.

Synthetic channels

Instead of storing a fixed content library, the channel continuously produces the next segment.

This is why I think "AI video generation" is starting to become too narrow a phrase.

The interesting system is not a generator.

It is an interactive visual process.

The cost is already calculable

Director currently bills by generated video time.

During its launch discount:

$0.02 / second

After the promotion:

$0.08 / second

If I naively kept a Director feed generating 24/7 at the current promotional rate:

$1,728 / day
$51,840 / 30 days
$630,720 / year

At the $0.08/sec list price:

$6,912 / day
$207,360 / 30 days
$2,522,880 / year

That is obviously not a casual hobby stream.

But I also do not think the right comparison is with a YouTube subscription.

The comparison is with the cost of producing, operating and continuously supplying content for a real channel or interactive visual experience.

From that perspective, the economics are already interesting.

This is the worst version of this medium

fal.live and Infinite Slop are rough.

That is exactly why I am paying attention.

The first websites looked bad.

The first streamed video looked bad.

The first mobile games looked primitive.

The first useful version of a medium usually arrives before the polished version.

H3 Max Director gives developers a new primitive:

a visual world that can keep running and accept new instructions while it runs. ⚡

That sounds much more consequential than another "best video model" leaderboard result.

2026 might be remembered as the year generative video stopped being a file and started becoming a process.

FreeToken Runs Frontier-Scale MoE Models by Treating the Whole PC as the Inference Platform

Ian Khasky — Tue, 08 Sep 2026 18:23:11 +0000

The most interesting FreeToken benchmark is easy to summarize:

Qwen3.6-35B-A3B
RTX 4060 Laptop
8 GB VRAM
39.3 tok/s

Then it gets more unusual:

DeepSeek-V4-Flash
284B parameters
single RTX 5090
22-25 tok/s

FreeToken is an open-source serving engine designed specifically for Mixture-of-Experts models on personal hardware.

The important idea is not "VRAM no longer matters."

It is that VRAM is only one resource in the machine.

FreeToken treats the GPU, CPU, host RAM, and interconnect as one heterogeneous inference system. ⚡

Why MoE changes the problem

A dense model effectively needs all relevant weights for every token.

A Mixture-of-Experts model has many expert blocks but activates only a subset for each token.

FreeToken's paper gives DeepSeek-V4-Flash as an example.

The model contains 284B total parameters.

Only 13B participate in a single token.

That makes the computation much more manageable on a consumer GPU.

But the rest of the model does not disappear.

The full expert pool is still huge.

The hard problem becomes:

where do experts live?
which experts stay in VRAM?
what happens when one is missing?
how do we hide transfer latency?

FreeToken is built around those questions.

The expert pool lives in host memory

At a high level, FreeToken uses a two-level expert-memory hierarchy.

The full routed-expert pool stays in CPU-accessible host RAM.

Non-expert weights remain on the GPU.

Remaining VRAM becomes a shared expert cache across MoE layers.

When an expert is already cached, the GPU can execute it immediately.

When it misses, the engine has two possible routes.

route A:
RAM -> PCIe -> VRAM -> GPU execute

route B:
RAM -> CPU execute directly

Neither route is universally better.

Bandwidth-adaptive CPU/GPU co-execution

This is one of the most interesting parts of the design.

PCIe transfer consumes link bandwidth.

Direct CPU expert execution consumes host-memory bandwidth.

A laptop and desktop can have completely different ratios between those resources.

So FreeToken measures the machine instead of relying on a fixed expert-placement policy.

Its q* decode policy divides cache misses between GPU cache fills and direct CPU execution based on the actual host-memory and PCIe bandwidth.

The goal is to keep both resources productive.

That is a more sophisticated strategy than static CPU offloading.

Prefill requires a different approach

MoE sparsity helps decode because each token touches a small subset of experts.

A long prompt is different.

Thousands of prompt tokens can collectively route through almost every expert.

That makes the effective working set much denser.

FreeToken handles this with full-layer double buffering.

While the GPU computes layer l, the experts for layer l+1 stream over PCIe.

GPU:  compute layer N
PCIe: load layer N+1

The two buffers then swap.

This hides transfer behind useful computation.

Semantic-aware caching for agents

The project is explicitly designed around agent workloads too.

Agent contexts are not simple append-only conversations.

Tool calls modify context.

Thinking blocks may be removed.

Prompts get edited.

Traditional recurrent-state or KV reuse can become invalid.

FreeToken creates semantic anchor checkpoints around boundaries such as tool calls and thinking segments.

When the context changes, it can resume from a surviving anchor and re-prefill only the suffix instead of starting over.

That is a very practical optimization for long-running coding agents.

Elastic VRAM management

Personal hardware is not a datacenter.

The GPU shares VRAM with:

the desktop
browsers
creative apps
games
other local workloads

At the same time, an agent's KV cache grows as context grows.

FreeToken can resize and rebuild the GPU expert cache under a new memory budget without restarting the engine or reloading the host-resident expert pool.

The memory split is allowed to move with the workload.

Published performance

The paper reports:

Qwen3.6-35B-A3B at 39.3 tok/s on an 8 GB RTX 4060 Laptop
Qwen3.6-35B-A3B at 77-83 tok/s on RTX 5090
DeepSeek-V4-Flash 284B at 22-25 tok/s on RTX 5090
GLM-5.2 753B served on one RTX PRO 6000 workstation GPU

Across five consumer systems, the paper reports a 1.3-2.1x decode-throughput improvement over the tested edge-serving baselines.

Those numbers are project/paper benchmarks, so I would treat them as published benchmark results rather than a promise for every machine.

RAM is still part of the requirement

A giant model still has to live somewhere.

The project's FAQ explains that MoE expert weights live in host RAM.

For example, Qwen3.6-35B-A3B in BF16 needs roughly 70 GB of free system RAM for experts.

Quantized checkpoints reduce that requirement substantially.

So the correct interpretation of the 8 GB RTX 4060 result is:

8 GB GPU is enough for the GPU side of the serving strategy

not:

the entire 35B model fits in 8 GB total memory

That distinction matters.

Current hardware support

The current install docs list:

Linux x86_64 for the Python install
NVIDIA GPU
Ampere / RTX 30-series or newer
driver r580+
CUDA 13
Python 3.10+

FreeToken also ships a desktop app for Windows and Linux.

The maintainers list macOS, AMD, and aarch64/DGX Spark on the roadmap.

Quick start

uv pip install "freetoken[accel]"

Then:

ft serve --model ~/models/Qwen3.6-35B-A3B

The server exposes OpenAI-compatible APIs:

/v1/chat/completions
/v1/responses
/v1/models

and Anthropic-compatible endpoints:

/v1/messages

Local coding agents

FreeToken also has a useful launcher:

ft launch claude
ft launch codex
ft launch dsh
ft launch hermes
ft launch openclaw
ft launch opencode

It configures the agent to use the local server.

That makes FreeToken more than a local-chat runtime.

It can serve as the local inference backend for coding and tool-calling agents.

My takeaway

For dense models, local inference is often summarized as:

model size <= VRAM

MoE gives us a different equation:

small active path
+ large host-resident expert pool
+ smart caching
+ CPU/GPU co-execution
+ enough bandwidth

FreeToken is an attempt to optimize that entire equation.

And the published results suggest that the practical ceiling for local open-weight models can be much higher than VRAM alone would imply.

Paper:
https://arxiv.org/abs/2608.16157

The 10-Line Claude Skill That Turns Hard Topics Into Visual Explain-Like-I'm-Five Pages

Ian Khasky — Tue, 08 Sep 2026 07:43:57 +0000

I like AI explanations, but I keep running into the same problem.

The answer is often correct.

It is just not the answer I need first.

If I ask about a topic I barely understand, I may get a long explanation full of correct terminology before I have any mental model of how the pieces fit together.

That is why the eli5 skill for Claude caught my attention.

The command

Use:

/eli5 <topic>

For example:

/eli5 how does DNS work

Claude creates an HTML artifact with big pictures and very few words.

The skill is here:

anthropics/claude-plugins-community/eli5

The whole skill is only 10 lines

The actual SKILL.md is 10 lines long.

There is no complicated tutoring framework, MCP server, external search pipeline, or giant prompt.

The value is mostly in the output constraint.

Why the constraint works

When I learn something new, I usually need a mental model before vocabulary.

Take DNS.

A full explanation may immediately introduce recursive resolvers, authoritative nameservers, root servers, TLD servers, caching, TTLs, and DNSSEC.

All of those terms matter.

But if I do not yet understand the basic flow, the terminology becomes noise.

A visual first pass can instead show:

browser
-> asks resolver
-> resolver finds answer
-> browser gets IP

Once that relationship is clear, I have somewhere to attach the terminology. 🧠

"ELI5" should not mean inaccurate

The name stands for "Explain Like I'm Five."

I think the best interpretation is not literally "use the vocabulary of a five-year-old."

The better rule is:

assume zero background, not zero intelligence.

A technical explanation can remain accurate while removing hidden prerequisites.

This works for more than coding

Developer examples:

/eli5 virtual memory
/eli5 event loop
/eli5 TLS handshake
/eli5 Git rebase
/eli5 Kubernetes networking

Other subjects:

/eli5 Bayes theorem
/eli5 inflation
/eli5 existentialism
/eli5 quantum entanglement

The only real requirement is that the subject benefits from a visual mental model.

Codebases are an especially good use case

Instead of asking:

Explain this repository.

I want something closer to:

/eli5 how does this codebase work

The useful output is not a giant inventory of folders.

It is a picture of where requests enter, which modules matter, where state lives, and how data flows.

Then I can inspect the code with a structure already in my head.

This is a first-pass tool

I would not stop at an ELI5 explanation when details matter.

For security-sensitive code, math, production architecture, or anything I need to implement precisely, I still want documentation, source code, proofs, benchmarks, and primary sources.

ELI5 is the orientation layer.

It gets me from:

I do not know what any of this means.

to:

I understand the basic structure. Now I know what to ask next.

Anthropic's Thariq Shihipar shared the skill publicly and said people at Anthropic had been using it a lot recently.

The entire trick fits into a tiny skill file.

The improvement in learning experience can be much larger.

I Want More Coding Agents to Work Like This

Ian Khasky — Tue, 08 Sep 2026 00:11:31 +0000

💻 One thing I dislike about coding-agent setups is how quickly they become part of one specific machine.

Provider config goes in one place, session state somewhere else, local models live in another directory, and suddenly moving to a second machine means rebuilding the environment.

OpenClaude-Portable takes a much cleaner approach.

It packages the coding agent, runtime and persistent data into a self-contained folder.

It supports cloud and local models in the same setup

The project currently supports 9 provider options:

Anthropic Claude
OpenAI
Google Gemini
DeepSeek
OpenRouter
NVIDIA NIM
Ollama
LM Studio
custom OpenAI-compatible APIs

I like this because the portable part is not tied to one model vendor.

I can use a cloud model when I want the strongest hosted option, then switch to Ollama or LM Studio when I want a local workflow.

The important caveat is simple: cloud providers still need internet. Ollama can run offline after the initial setup.

The "zero footprint" idea is more useful than it sounds

The project redirects its persistent data into a local data folder.

That includes provider settings, API keys, logs, session history, agent memory and local Ollama files.

According to the repository, it does not write configuration into the host system.

For me, this is the real feature.

I do not care that the agent happens to be on a USB drive. I care that I can move the folder and keep my environment with it. 💾

There are two very different ways to run the agent

The launcher offers a normal mode that asks before file writes or shell commands.

There is also an optional Limitless mode that can run without approval prompts.

I like that these are explicit choices rather than one hidden permission switch.

For normal development I would keep approval mode on. For a disposable test project or a controlled autonomous task, the second mode could be useful.

Sessions can survive the move

Another practical detail is session resume.

The project stores session history inside the portable data folder and includes a resume command for interrupted sessions.

That matters more to me than a flashy UI feature because an agent becomes useful over time only if its working context is not constantly thrown away.

There is also a browser dashboard with a chat-style interface, agent mode, tool cards and a thinking visualization.

So you are not limited to a terminal-only experience.

The local-model optimization is surprisingly aggressive

Running a coding agent against a small Ollama model on CPU can be painfully slow because the agent itself sends a large system prompt.

OpenClaude-Portable includes a local proxy that trims that prompt before sending it to Ollama.

The repository says it reduces the prompt from roughly 10,000 tokens to around 300 for this local path, and reports typical first-token latency improving from 60-120 seconds to roughly 5-20 seconds on CPU-only hardware.

I would treat those numbers as project-reported rather than universal benchmarks, but the idea is smart: optimize the agent protocol for the limitations of small local models instead of pretending local and cloud inference behave the same way.

The base installation is small

The project itself needs roughly 150 MB for the runtime and engine.

Local models are the part that grows quickly, with the repository suggesting roughly 800 MB to 8 GB depending on the Ollama model.

That makes a portable setup realistic.

One warning from the README is worth repeating: first-time installation on slow USB media can take 10-15 minutes. A USB 3.x drive or doing the initial setup on internal storage and copying the completed folder back is a better experience.

What I would use it for

I would not move my primary development environment onto a random flash drive.

But I absolutely see value in a prepared portable agent for:

travel
a backup machine
a recovery environment
temporary workstations
offline coding with a small local model
testing different providers without rebuilding config

For me, OpenClaude-Portable is interesting because it treats the coding agent as part of the project environment instead of part of the computer.

I want more developer tools to work that way.

Two Claude Code sessions can message each other. That does not stop them overwriting your files.

Ian Khasky — Wed, 02 Sep 2026 07:00:39 +0000

I ran two Claude Code sessions against one repository and assumed the hard part was coordination. It is not. The hard part is that coordination looks like it solves a problem it never touches.

What is actually built in 🧐

Two sessions can find each other and talk. Anthropic's docs on cross-session messaging describe it: one session warns another that a change broke what it was building on, or answers a question the other was blocked on. Claude uses two tools for it, ListAgents to see who is reachable and SendMessage to write to one of them by name. Nothing to switch on. You check what a session can reach with /list-agents, also spelled /peers.

There is a version floor. Cross-session messaging needs Claude Code 2.1.224 or later on macOS, Linux and WSL 2, and 2.1.234 or later on native Windows. Below that the command is not recognised at all.

The sentence that changes the plan

From the same page: "A message is a piece of text one Claude writes to another, never the sender's conversation history or files."

Text. Not files.

So two sessions can be perfectly informed about each other and still be pointed at the same schema.ts in the same folder, both about to write it. Anthropic says this outright: two agents editing one file in a shared working directory can overwrite each other's changes. There is no source-file locking underneath, and no merge layer doing the reconciling.

Messaging is a channel. It was never a lock.

What actually protects the work

A worktree per session. claude --worktree backend in one terminal and claude --worktree frontend in another, and each session gets its own directory, its own branch and its own copy of the tracked files. The docs put the effect plainly: edits in one session never touch files in another. Claude Code also refuses an edit aimed from inside a worktree back at the main checkout, so the isolation is enforced rather than agreed.

Add .claude/worktrees/ to .gitignore while you are in there, or the worktree contents turn up as untracked noise in your main checkout.

Now messaging becomes the thing it is good at. Session A changes the API, makes a small commit, and sends session B the commit hash and the list of files that moved. B rebases or cherry-picks, then re-reads what changed. If both of them touched the same file, git raises a conflict. A conflict interrupts you. A silent overwrite is a loss you find out about later, if at all 😬

The part no tool does for you 🤔

Worktrees do not decide who owns package.json.

For the files both sessions genuinely need to change, the only reliable scheme is boring: one owner at a time. Different files in parallel, the same file in sequence. Write it into the prompt as a protocol. Name the directories each session owns, require a handoff through a message before either one touches a file the other holds, and require a commit before the handoff.

The two alternatives, and why neither replaces this

Agent Teams is the experimental mode where one lead session spawns and supervises teammates, behind CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS. It gives a shared task list, a mailbox, and direct messages between agents, and claiming a task is protected by a file lock. Read that last part slowly: the lock is on the task record, not on the source files. It coordinates who does what. It does not stop two writers landing on one file, which is why the recommendation is still to split responsibility by file.

MCP Agent Mail is the closest third-party attempt: persistent agent identities, an inbox and outbox with threads, file reservations by path and glob, TTL on stale reservations, and an optional pre-commit or pre-push guard. It is the only one of the three that models file ownership at all. But those reservations are advisory. The server reports the conflict, it is not a transactional write lock, and the guard can block a commit without stopping a write already under way in a shared directory. Even with it, I would still run worktrees.

Plugins named swarm or orchestration mostly automate prompts and roles on top of Agent Teams. They add no locking of their own.

What I would take away

Isolation buys the safety. Ownership settles the rest. The message is only how the other session finds out.

Anthropic's page on cross-session messaging is worth reading in full: https://code.claude.com/docs/en/cross-session-messaging

How Biology Became the Foundation of Artificial Intelligence 🧠

Ian Khasky — Sun, 21 Jun 2026 18:24:57 +0000

Modern AI may look incredibly complex today.

We talk about transformers, attention mechanisms, large language models, embeddings, agents, and reasoning systems.

But at the foundation of neural networks is a much simpler idea: the artificial neuron.

The biological inspiration

A biological neuron receives signals through dendrites.

These signals are integrated in the cell body, also called the soma. If the combined signal is strong enough, the neuron generates an impulse and sends it forward through the axon.

In simple terms:

dendrites -> cell body -> impulse

The neuron receives input, processes it, and then decides whether to pass a signal forward.

This biological process inspired one of the earliest building blocks of artificial intelligence.

The artificial neuron

An artificial neuron follows a similar logic, but mathematically.

Instead of biological signals, it receives numerical inputs.

Each input is multiplied by a weight. Then all weighted inputs are added together, adjusted by a bias, and passed through an activation function.

inputs -> weights -> weighted sum + bias -> activation function -> output

Or, in a simplified formula:

z = w1*x1 + w2*x2 + ... + wn*xn + b

Here:

x values are the inputs
w values are the weights
b is the bias
z is the weighted sum before activation

Why activation functions matter

Without an activation function, a neural network would mostly behave like a linear mathematical model.

Activation functions introduce non-linearity, allowing neural networks to learn more complex patterns.

One classic example is the sigmoid activation function:

sigma(z) = 1 / (1 + e^(-z))

The sigmoid function always produces a value between 0 and 1.

That means the neuron does not simply output "yes" or "no".

Instead, it produces a smooth value that can often be interpreted as confidence or probability.

Before transformers, there was the perceptron

Before transformers, attention mechanisms, and large language models, there was a much smaller foundation: the perceptron.

A perceptron is one of the earliest models of an artificial neuron. It takes inputs, applies weights, adds bias, and produces an output through an activation function.

This simple structure became one of the building blocks for modern neural networks.

Why this still matters

Today's AI systems are much more advanced than a single perceptron.

But the core idea remains important:

small mathematical units process information, pass signals forward, and combine into larger systems capable of learning complex behavior.

Modern AI begins at the smallest level, with one artificial neuron.

And that idea began with biology.