Claude Code

For Claude Code:

$env:ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic"
$env:ANTHROPIC_AUTH_TOKEN="sk-YOUR_DEEPSEEK_KEY"
$env:ANTHROPIC_MODEL="deepseek-flash[1m]"

claude

The published block also maps the default model slots and the subagent model. Those variables belong to one terminal window, which makes the setup easy to walk back.

Codex CLI

irm https://cdn.deepseek.com/api-docs/codex-deepseek-setup-en.ps1 | iex

Codex reaches DeepSeek over the Responses API, and that script writes the provider section, the model catalog and a backup of what it replaced.

OpenCode

OpenCode takes DeepSeek from inside its own interface: /connect for the key, /models for Flash or Pro.

Aider

setx OPENAI_API_BASE "https://api.deepseek.com"
setx OPENAI_API_KEY "sk-YOUR_DEEPSEEK_KEY"

aider --model openai/deepseek-flash

Aider edits the repository directly and commits as it goes, so a rollback is a Git operation.

LiteLLM

LiteLLM puts one local endpoint in front of DeepSeek, Claude, GPT and Gemini, with fallback, visible spend and a budget.

Ollama

ollama run deepseek-coder:6.7b

An 11 GB card handles DeepSeek Coder 6.7B and the 7B and 8B R1 distills, and 14B only in 4-bit and slow.

Why DeepSeek Flash instead of Claude Sonnet 5 or GPT-5.6 Terra?

DeepSeek publishes two rates per million tokens, and off-peak is half of peak:

Flash, off-peak   $0.15 input (cache miss)   $0.60 output
Flash, peak       $0.30 input (cache miss)   $1.20 output
Pro, off-peak     $0.66 input (cache miss)   $1.98 output
Pro, peak         $1.32 input (cache miss)   $3.96 output

The standard rung at the two providers a coding CLI reaches for by default:

Claude Sonnet 5   $2 input    $10 output
GPT-5.6 Terra     $2 input    $12 output

Flash vs Claude Sonnet 5   ~7-17x cheaper
Flash vs GPT-5.6 Terra     ~7-20x cheaper

The low end of each range is peak input, the high end is off-peak output, so where a run lands depends on the hour it runs and on how much of it is output. This compares API rates against API rates, so a fixed monthly subscription is not directly comparable.

Flash is a strong default for:

• repository exploration

• tests

• docs

• boilerplate

• routine refactors

• CI fixes

• subagent loops

I would still escalate to a frontier Claude or GPT model for:

• ambiguous architecture

• hard debugging

• security review

• risky migrations

Neither side is universally weaker, and the split is where each one is worth its price.

Privacy

Do not casually send API keys, .env files, production credentials or large database dumps to a cloud model. For confidential code, prefer local inference or a provider whose retention policy matches your requirements.

When the model switched but the traffic did not

The interface says DeepSeek-Flash and the traffic still goes to the OpenAI Responses endpoint, with no OpenAI key in play. The model catalog changed and the provider section did not.

[model_providers.deepseek]
name = "deepseek"
base_url = "https://api.deepseek.com/"
wire_api = "responses"
experimental_bearer_token = "sk-YOUR_DEEPSEEK_API_KEY"

Close Codex, ChatGPT Desktop and VS Code completely and open them again, because picking the model in a running window does not reload the provider.

Reference links

• Claude Code integration: https://api-docs.deepseek.com/quick_start/agent_integrations/claude_code/

• Codex CLI integration: https://api-docs.deepseek.com/quick_start/agent_integrations/codex/

• DeepSeek pricing: https://api-docs.deepseek.com/quick_start/pricing/

• Claude pricing: https://platform.claude.com/docs/en/about-claude/pricing

• OpenAI pricing: https://developers.openai.com/api/docs/pricing

Follow me for more on AI, LLMs, and Software Development: @khasky — LinkedIn / Patreon / GitHub / Bluesky / Mastodon @khaskydev — X / Threads / Instagram / Pinterest

32K
128K
200K
1M
2M

But those numbers are difficult to translate into real working material.

One Million Tokens is an interactive visualization built to make that scale intuitive. 🧠

Its core estimate is:

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

From GPT-3 to million-token models

The visualization starts in 2020:

GPT-3
2,048 tokens

Then:

ChatGPT
4,096

GPT-4 32K
32,768

Claude
100,000

By 2024, the timeline reaches the million-token range with Gemini 1.5 Pro.

Then it continues into multi-million-token windows. The site's full chart stretches to a cited 10M context window. That is about a 4,883x increase from GPT-3's 2,048 tokens.

Why this matters for code

Longer context changes the unit of reasoning. With small windows, the model sees fragments. With large windows, it can see more relationships at once:

function
-> file
-> module
-> subsystem
-> large repository slice

The site's 75K-lines-of-code comparison is approximate, but it is still useful for intuition.

A million tokens is large enough that "just put the relevant code in context" can mean something very different than it did in 2020.

But long context does not guarantee long-context quality

A model's advertised context window tells us how much input it can accept.

It does not tell us how well it uses that input. A 1M-token model can still miss a relevant detail. It can have positional bias. It can struggle with relationships spread across many documents. It can become slower and more expensive as context grows. So I would separate:

maximum context capacity

from:

effective retrieval/reasoning quality

They are related but not identical.

Longer context also does not eliminate retrieval

RAG remains useful because it can:

• reduce irrelevant material

• lower cost

• reduce latency

• focus the model on likely-relevant evidence

Long context gives developers more flexibility in choosing where the retrieval/context boundary sits.

That is a better way to think about it.

Open vs closed models

The site lets you filter the context-window timeline by open-weight and closed models.

That makes another trend visible: very long context is increasingly available outside closed APIs.

The page was built by Hassan at Together AI.

For me, the best feature is simply that it turns a model-card specification into a physical intuition.

"1M context" sounds technical. "3,000 pages" sounds real.

Do you trust long-context recall, or still chunk your inputs?

Tencent's teamai-cli treats this as distribution rather than discipline.

The repo is the unit

One git repo holds the harness: skills/<name>/SKILL.md, rules/*.md, hooks/hooks.yaml, mcp/mcp.yaml, agents/<name>.yaml, docs/, and a culture.md carrying the team's mission and working principles, which lands in each agent's CLAUDE.md or AGENTS.md by itself.

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

Project scope is the default, and --scope user installs under your home directory instead. GitHub, GitLab, GitCode, CNB, TGit or your own git server all work as the store.

The release process

teamai push opens the branch and the merge request. Someone reviews and merges. The next SessionStart hook runs teamai pull and it is there.

A change to a rule now goes through the gate a change to code already goes through. That is the whole idea and it is worth the install on its own, because a bad rule is wrong in every session on every machine at once.

teamai roles maps a role to a namespace so a member syncs only the skills their role needs, teamai tags handles subscriptions, and learnings/ at the repo root is shared while learnings/<project-id>/ stays project-private.

What I counted before installing it

The support table decides whether any of this reaches a given machine, so that is what I counted: 11 agents against 13 capability columns. Skills and docs are filled on all 11, hooks and MCP on 8, usage and dashboard on 7.

The automatic delivery runs off a hook, and the OpenClaw, Hermes and DeepSeek Harness rows show a dash in that column. The project draws no conclusion from it. My read is that on those three you are still the sync mechanism.

The caveat

The env/ row offers "Shared team-level environment variables and switches" and warns you off putting secrets in it. So the settings that cost the most to keep aligned are the ones the repo will not hold. The recall and the dashboards, which are what lift this above a file sync, both carry a beta label from the project.

Repo: github.com/Tencent/teamai-cli

If your team already keeps its agent rules in a repo, who reviews those merge requests: the person who wrote the rule, or someone who has to live with it?

The release in one paragraph

Edge0-AI open-sourced Edge0 the other day: a streaming inference engine under Apache 2.0, with two preview models built on open sparse MoE bases, Edge0-35B-A3B (Qwen3.5-MoE underneath) and Edge0-8B-A1B (Ling 3.0). In a mixture-of-experts model the router calls only a few experts per token, 4 out of 256 here, about 3B active parameters out of 35B. Edge0 keeps the whole 4-bit checkpoint on the SSD, memory-maps the expert weights and reads only the routed ones as each token comes through, so peak RAM is 2.9 GB for the 35B and 1.0 GB for the 8B at short context on a Mac mini M4 Pro. The clip of a 35B model answering on an iPhone at about 1 GB of peak memory is what made the rounds 🤯

Budget one: disk

The checkpoint never leaves storage. It is 19.6 GB for the 35B and 4.55 GB for the 8B by the model cards, and it stays on the SSD for the whole session because that is where the experts are read from. My first sum: 35B at 4 bits is 17.5 GB of weights, so about 2 GB of that checkpoint is kept at higher precision, presumably embeddings, attention and scales. So the first thing I would check is free space on the internal drive, and the second is that the drive is the one the runtime will actually map the files from. Install is a Python package on an Apple Silicon Mac with Python 3.10 or newer:

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

The fetch extra pulls the checkpoint. Inside a checkout the project's own line is python3.12 -m venv .venv && .venv/bin/pip install -e '.[dev,fetch]'.

Budget two: cache

Every token routes to 4 experts and reads them off the drive, or so the headline goes. The sum says otherwise. 3B active at 4 bits is about 1.5 GB per token as an upper bound, and at 15 to 18 tokens a second that is over 20 GB/s if every read were cold. No consumer SSD moves that, so most expert reads are being served from the operating system's file cache, and the decode figures, 14.9-17.7 tok/s for the 35B and 23.9-25.3 for the 8B on that M4 Pro, are as much a statement about how much of the checkpoint a 24 GB machine can keep cached as about the GPU. My reading is that "peak active memory" counts the process's resident set and leaves those cached pages out. What I would measure first on my own Mac is decode with something else hitting the disk at the same time, because the project's numbers were taken on a Mac mini with nothing else to do.

Budget three: context

The 2.9 GB is a short-context number, and the project says so in a footnote. Expert weights stream off the drive, while the KV cache sits in RAM and grows with the prompt, 3.3 GiB at 3.3k tokens on the 8B. So the working set is the active experts plus whatever the model needs on every token plus the cache, and only the first of those is fixed. If your use is long documents, the RAM figure you plan around is a different one from the headline 🧐

What is not in the release

The iPhone. The project says the MLX backend runs on macOS with Apple Silicon and that no other platform is supported yet, with CUDA on the roadmap. The "iPhone 15 Pro and newer" floor in the reposts is absent from the README and from both model cards. The one chip-level mention of an iPhone anywhere in the repo is a troubleshooting note that garbled output on A18 and A18 Pro means an older mlx, and that points at a library version.

Quality is the other gap. Both models are previews, the project's own eval puts the 35B pipeline at 79.2 against 83.2 for the fp16 base, and tool use and multi-step planning are called weak. Fine for a chat model in a small RAM budget, and I would keep agent loops off it for now.

What I would do with it

Install the 8B first, since 4.55 GB downloads faster than 19.6 GB, watch peak memory as the prompt grows, and watch how much of the checkpoint stays in the file cache while it decodes. Then decide whether the machine with the biggest drive is now the machine for local models, which is the conclusion the sums pushed me toward. Repo: https://github.com/Edge0-AI/edge0/ and the 8B card: https://huggingface.co/Edge0/Edge0-8B-A1B-preview

For anyone who has run expert offload through another runtime: how much did decode drop when the SSD was busy with something else?

The funny demo is infinite AI television.

The important part is that the underlying video model is now fast enough to support it.

Faster than playback changes the architecture

Fal's H3 Max can generate a 5-second video in under 3 seconds.

That changes what can be built.

With slower video models, an interactive application usually looks like:

user input
-> wait
-> render
-> receive clip
-> play clip

With faster-than-playback generation, the next segment can be created while the viewer is still consuming the current one.

The pipeline becomes:

play segment N
-> generate segment N+1
-> play N+1
-> generate N+2

Once that loop stays ahead of playback, continuous AI video becomes possible.

The first viral experiment became a platform

Fal engineer Rehan Sheikh hooked H3 Max into an interdimensional-cable style livestream.

It was removed from Twitch.

Then it was removed from Kick.

Fal's response was to build fal.live.

The platform is a live experiment in audience-directed generative video.

There are channels such as Chaos, Sitcom, Anime and Soap Opera.

Instead of a fixed broadcast schedule, the audience influences the next generated scene.

The system can moderate or surface directions, viewers vote, and the next selected direction reaches the model.

📺 It is basically "Twitch Plays" applied to a video generator.

Infinite Slop turns the audience into the prompt source

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

The interface is intentionally simple:

• watch the current generated scene

• write what you want to see

• wait for the queue

• see the idea become video

The result is chaotic.

But it demonstrates a useful property: generative media no longer has to be produced before the audience arrives.

The audience itself can become part of the production loop.

H3 Max Director is more interesting than the livestreams

The technical release I am watching is H3 Max Director.

Director does not behave like fal's regular H3 Max text-to-video endpoint.

It opens a realtime WebRTC session and keeps that session alive.

Directions arrive as text while the stream is running.

The model then carries the stream forward.

Fal says each segment continues with 39 frames of context from the previous segment.

The Director also retains prior prompts in its running memory, 12 by default and up to 50.

That means the model has a concept of previous direction rather than treating every generation as a completely independent request.

Public sessions are currently limited to 2 minutes.

Longer sessions are being opened gradually.

I think "native continuity" is the key idea

Most multi-scene AI video workflows fake continuity at the application layer.

Generate one clip.

Take its last frame.

Feed that frame into the next request.

Repeat.

This can work, but every request is still basically starting again.

A persistent Director session is a different abstraction.

The context survives within the session.

That allows a new instruction to act more like:

turn the story this way

instead of:

create another clip that looks like the previous clip.

That difference is what makes interactive video plausible.

What can developers build with this?

The obvious answer is AI TV, but I think that is the least interesting long-term answer.

Interactive games

A game can convert player actions into the next video direction.

Generative NPC scenes

A reasoning model can decide what a character should do, then the video model can render that action continuously.

Adaptive training

A tutorial can respond visually to a learner's questions or choices.

Live simulations

The rendered environment can evolve based on external state.

Dynamic marketing

Viewers can steer branded experiences instead of watching static creatives.

AI presenters

A live visual agent can change what it says and does while the stream continues.

The common pattern is simple:

the application keeps sending state into a running visual process.

The economics are no longer abstract

H3 Max Director currently costs $0.02 per generated second during its launch promotion.

A continuous feed would therefore cost approximately:

1 hour:   $72
24 hours: $1,728
30 days:  $51,840
1 year:   $630,720

After the promo, the listed rate is $0.08/sec.

That makes the same hypothetical stream 4x more expensive.

These are not small bills.

But they are already within the range where companies can seriously prototype new media products.

And the cost curve of inference rarely stands still.

The marketing is almost as interesting as the model

There is also a product lesson here.

Fal could have published an inference chart.

Instead, the internet got:

1. an absurd continuous livestream

2. bans from major platforms

3. fal's own AI television site

4. Infinite Slop by @levelsio

5. a public realtime API underneath it

That is a much better way to explain "faster than realtime."

You do not need to understand tokens, throughput or GPU kernels.

You watch the channel keep going.

The demo proves the benchmark.

⚡ That is excellent developer marketing.

The current shows may be slop.

The new primitive is not.

#ai #generative-video #developer-tools #realtime #machine-learning

Its headline benchmarks are unusual:

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

and:

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

⚡ The trick is not fitting the entire model into VRAM.

FreeToken treats the whole machine as one inference platform.

MoE makes the active compute small

An MoE model stores many experts but routes each token through only a few.

DeepSeek-V4-Flash has 284B total parameters, but FreeToken's paper says only 13B participate in a single token.

This makes the per-token compute much smaller than the headline parameter count.

The complete expert pool still has to be stored, though.

Host RAM becomes the expert store

FreeToken keeps the full routed-expert pool in host memory.

Remaining VRAM is used as a shared expert cache.

A cache miss can be handled in two ways:

transfer expert to GPU
or
execute expert on CPU

The engine measures the deployed machine's host-memory and PCIe bandwidth and dynamically divides work between those paths.

This is the project's bandwidth-adaptive q* policy.

Prefill uses double buffering

Long prompt prefills touch a much larger portion of the expert set than one decode token.

FreeToken streams the next layer's experts while the GPU computes the current layer.

That overlaps PCIe movement with GPU execution.

VRAM allocation is elastic

FreeToken can dynamically resize the memory assigned to expert cache and KV cache without restarting or reloading the whole expert pool.

That matters on consumer PCs where VRAM availability changes while other applications run.

Agent-aware context caching

The system also targets coding/tool-use agents.

Semantic anchor checkpoints help preserve reusable state when tool calls or thinking segments edit the context.

This reduces unnecessary re-prefill work in long-running agent sessions.

Hardware caveat

The 8 GB RTX 4060 result does not mean the full 35B model needs only 8 GB total memory.

MoE expert weights live in system RAM.

The FreeToken FAQ says Qwen3.6-35B-A3B in BF16 needs roughly 70 GB of free host RAM for experts; quantized checkpoints need significantly less.

Current support

The current docs focus on:

x86_64
NVIDIA RTX 30-series+
CUDA 13
driver r580+

Windows/Linux have desktop support.

Linux also has pip/uv installation.

macOS and AMD are on the roadmap.

Install

uv pip install "freetoken[accel]"

Serve:

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

The server supports OpenAI- and Anthropic-compatible APIs.

It can also configure local coding agents such as Claude Code, Codex, OpenCode, OpenClaw, and DeepSeek Harness.

For me, the bigger lesson is that MoE local inference should not be judged by VRAM alone.

The real resource is the entire memory/computation hierarchy of the machine.

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

#localai #moe #llm #developer-tools

In practice, models often optimize for completeness.

If I ask about an unfamiliar topic, I get terminology, edge cases, context, and caveats before I have built a basic mental picture.

The eli5 skill for Claude uses a surprisingly small instruction to change that.

One command

/eli5 <topic>

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

Skill: eli5

It is only 10 lines

The actual SKILL.md is 10 lines long.

That matters because it shows what the skill is really doing.

It is not adding new knowledge.

It is changing the teaching format.

🧠 The constraint is the product.

The first problem in learning is often missing context

Imagine I ask:

How does virtual memory work?

A normal answer might immediately introduce address spaces, page tables, TLBs, page faults, swapping, and MMUs.

Every term is correct.

But I may still not understand the core relationship.

A visual explanation can first establish:

program thinks it has memory
        |
OS maps addresses
        |
physical RAM / disk

Now the detailed terminology has somewhere to go.

That order is much more efficient for someone entering the topic cold.

ELI5 is not the same as oversimplification

The phrase "Explain Like I'm Five" can sound like "make everything childish."

I do not think that is the useful interpretation.

The better rule is:

assume zero background, not zero intelligence.

A technical explanation can remain accurate while removing hidden prerequisites.

The HTML output matters

The explanation does not have to be a plain chat response.

It can become a visual artifact.

That makes diagrams, spatial relationships, and simple sequences much easier to understand.

Where I would use it

For developer topics:

/eli5 DNS
/eli5 Git rebase
/eli5 public key cryptography
/eli5 message queues
/eli5 OAuth

For math and science:

/eli5 eigenvectors
/eli5 entropy
/eli5 gradient descent

For general knowledge:

/eli5 inflation
/eli5 utilitarianism
/eli5 game theory

I can also imagine using the same pattern to understand a codebase or architecture before reading the implementation.

It should be the first layer, not the final source

I would not use an ELI5 artifact as proof or as a substitute for primary sources.

Its job is different.

It should help me understand enough to ask better questions.

A useful sequence is:

visual intuition
-> vocabulary
-> detailed explanation
-> primary source

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

The skill is tiny.

The improvement in learning flow can be much larger.

#claudecode #learning #developer-tools #ai

What I do care about is avoiding repetitive setup.

That is why [OpenClaude-Portable](https://github.com/techjarves/OpenClaude-Portable) caught my attention.

It packages an AI coding agent into a self-contained folder and keeps the runtime, settings and persistent data with it.

One portable setup, multiple model providers

The project currently supports 9 provider options, including Claude, OpenAI, Gemini, DeepSeek, OpenRouter, NVIDIA NIM, Ollama, LM Studio and custom OpenAI-compatible APIs.

That is useful because I do not have to choose between "portable" and "flexible."

I can use cloud providers when I have connectivity, or use a local Ollama model when I want the setup to keep working offline.

The first setup needs internet, but after that Ollama mode can run without it.

The state travels with the project

This is the feature I care about most.

Provider configuration, API keys, logs, session history and agent memory are redirected into the project's own `data` folder.

The repository describes this as a zero-footprint setup because it avoids writing configuration into the host system.

That means the environment can move between machines with much less cleanup or reconstruction. 💾

Windows, Linux and macOS share the same persistent data structure.

For someone who uses more than one computer, that is much more practical than it sounds.

It has a sensible permission split

The launcher has two modes.

Normal Mode asks before the agent writes files or runs shell commands.

Limitless Mode removes those approval prompts for a more autonomous workflow.

I like that the distinction is visible and intentional.

My default would be Normal Mode, but having an autonomous option is useful for controlled environments where I already know what I want the agent to do.

A local model does not have to feel unbearably slow

Running a coding agent against a small local model is often disappointing because the agent framework sends a very large system prompt.

OpenClaude-Portable adds a proxy that trims that prompt before it reaches Ollama.

The repository reports reducing roughly 10,000 tokens to about 300 on that path, and typical first-token latency on CPU-only hardware improving from 60-120 seconds to around 5-20 seconds.

Those are project-reported numbers rather than independent benchmarks, but the direction is what interests me.

It is a design that takes the weakest part of local coding agents and tries to solve it directly.

Session resume is another detail I appreciate

Agent sessions and memory live inside the project folder, and the Windows setup includes a resume command for interrupted sessions.

There is also a browser dashboard if you prefer a ChatGPT-style interface over the terminal.

Those are small features, but they make the portable setup feel less disposable.

Storage requirements are reasonable

The base runtime and engine need about 150 MB.

Local Ollama models add roughly 800 MB to 8 GB depending on the model.

The README also warns that first-time installation can be slow on old USB media. I would use USB 3.x or, better, a small external SSD if I planned to work from the drive regularly.

Where I would use it

For me, the strongest use cases are:

- travel

- a backup development environment

- temporary machines

- offline coding with Ollama

- testing several providers from one configuration

- recovery when my main workstation is unavailable

The interesting part is not carrying an AI agent in my pocket.

It is carrying the configuration and state that make the agent useful.