Most of this blog is about AI, but I follow spaceflight for the same reason I follow model releases: it's engineering under hard constraints, done in public, where you can see what works. These six months had three milestones I want to write down properly, plus a few smaller stories. All numbers come from the sources at the bottom.

Artemis II: humans around the Moon again

On 1 April 2026, NASA's Space Launch System launched Orion on Artemis II, the first crewed flight of the Orion spacecraft. The crew: NASA astronauts Reid Wiseman, Victor Glover and Christina Koch, and CSA astronaut Jeremy Hansen.

On 6 April, six days into the mission, they passed the record for the farthest distance humans have travelled from Earth, previously held by Apollo 13 since 1970. NASA's official figure for their farthest point is 252,756 miles (about 406,800 km) from Earth; NASA updated its release on 7 May to reflect the official mileage, with 695,081 miles flown in total.

They splashed down off San Diego on 10 April at 5:07 p.m. PDT, after a nearly ten-day flight.

The heat shield story

The part I found most interesting is the heat shield. After Artemis I in 2022, engineers had found unexpected char loss on Orion's Avcoat heat shield. Instead of only redesigning the shield, NASA changed the re-entry trajectory for Artemis II, shortening the maximum downrange distance so the shield spent less time in the temperature range where the Artemis I problem occurred.

In a 15 October analysis, NASA reported that it worked: Orion entered within 192 feet of its targeted entry interface, splashed down 0.59 miles from the predicted point, and the cracking and char loss were reduced by a factor of ten compared to Artemis I, with nine spots of char loss versus many more on the earlier flight. Peak velocity was about 39 times the speed of sound and external temperatures exceeded 4,000 °F, while the cabin stayed in the mid-70s °F.

I like this as an engineering lesson: sometimes the cheapest fix is changing how you operate a system rather than rebuilding it. It's the same instinct as changing a prompt or a retrieval step before retraining a model.

Blue Origin's setback

Blue Origin had planned to launch its first Blue Moon Mark 1 cargo lander, Endurance, on New Glenn as soon as late summer, carrying NASA science payloads (designated "Moon Base 1" at a NASA event on 26 May). Spaceflight Now reported on 30 June that, after a New Glenn anomaly, the company was working through return-to-flight logistics. It's a reminder that the lunar programme depends on several commercial vehicles all maturing at once.

July: the end of Pegasus and a satellite rescue

On 3 July Northrop Grumman flew the 46th and final Pegasus XL, the air-launched rocket, carrying Katalyst Space Technologies' LINK spacecraft on a NASA-backed mission to capture NASA's Neil Gehrels Swift Observatory and raise it to a higher orbit. The day before, the final Atlas V in the 551 configuration launched Amazon Leo satellites. Small entries in a launch log, but both mark the end of long-running vehicles.

August: the Roman Space Telescope

On 30 August 2026 at 7:26 a.m. EDT, a SpaceX Falcon Heavy launched NASA's Nancy Grace Roman Space Telescope from Launch Complex 39A at Kennedy Space Center. Roman separated from the upper stage at 7:57 a.m. and began a roughly three-month journey to the Sun–Earth L2 point, about a million miles from Earth.

Roman is a dark-energy and dark-matter mission with a field of view SpaceX describes as at least 100 times larger than Hubble's. Reuters called it a roughly $4 billion project and noted its origin as a repurposed spy-satellite telescope. For data people, Roman is interesting because its value is in survey scale: billions of galaxies, and a lot of downstream machine learning.

September: Starship reaches orbit, with a caveat

On 28 September (US time), on its 14th test flight, SpaceX's Starship reached orbit for the first time. NPR reported that the 33-engine Super Heavy booster lifted off from Starbase in Texas, that one of the ship's six engines shut down early, and that SpaceX still decided to go for orbit. Starship orbited Earth twice before splashing down in the Pacific; the planned ten-hour mission was cut to about three hours because of the engine issue.

Reuters reported the same day that the engine failure could complicate NASA's lunar plans, since Starship is one of the two vehicles NASA selected to land astronauts on the Moon. In-space propellant transfer, which a lunar Starship needs, is still to be demonstrated.

What comes next

NASA's Artemis page describes Artemis III, planned for 2027, as a demonstration mission in low Earth orbit to evaluate one or both commercial human landing systems from SpaceX and Blue Origin. The return of astronauts to the lunar surface is now tied to Artemis IV, and NASA anticipates a further surface mission, Artemis V, in 2028. That makes the next year mostly about Starship and Blue Moon: refuelling, reliability and cadence.

What I take from it

The successes of this period come from the same loop: fly, measure, adjust. Artemis II fixed a heat-shield risk with a trajectory change backed by test data; Starship reached orbit on an iterative test campaign and still published a partial failure. That's how I like to build software and AI systems too: small, measurable steps in public, with honest notes about what didn't work.

On the AI side of the same months, see my AI models recap for July–October 2026 and the open-weight models recap. More links: links & repos.

Sources

• NASA: Artemis II mission milestones, image and video recap
• NASA: Artemis II crew eclipses record for farthest human spaceflight
• NASA: NASA welcomes record-setting Artemis II moonfarers back to Earth
• NASA: Rigorous analysis confirms Artemis II heat shield performance (15 October 2026)
• NASA: Artemis programme
• Spaceflight Now: Blue Origin outlines return to flight logistics for New Glenn (30 June 2026)
• Wikipedia: List of spaceflight launches in July–September 2026
• NASA: Nancy Grace Roman Space Telescope launches
• NASA Science: Roman launch
• SpaceX: Roman Space Telescope mission
• Reuters: NASA launches powerful Roman Space Telescope (30 August 2026)
• NPR: SpaceX's Starship reaches orbit for the first time (29 September 2026)
• Reuters: Starship engine failure could impact NASA's Moon mission objectives

Open weights matter to me for a simple reason: they let you run AI on your own hardware, under your own rules. For education and legal work, where data often must not leave a server you control, that is not a nice-to-have. This post looks at the open-weight releases of the past six months, what you can realistically run, and the licences attached. The closed-model side is in my April–June and July–October recaps.

April: Gemma 4 goes Apache 2.0

Google announced Gemma 4 on 2 April 2026 (the developer release notes list the weights on 31 March) in four sizes: Effective 2B (E2B), Effective 4B (E4B), a 26B mixture-of-experts and a 31B dense model. The bigger news for me was the licence: Google's open-source blog called Gemma 4 the first Gemma models released under the OSI-approved Apache 2.0 licence, instead of the custom Gemma terms.

Some practical numbers from Google's own pages:

• The 26B MoE activates only about 3.8B parameters per token, which is what makes it fast.
• Unquantised bfloat16 weights of the 26B and 31B fit on a single 80 GB H100.
• Google's memory table puts the 31B at about 17.5 GB at 4-bit and the 26B A4B at about 14.4 GB, which is consumer-GPU territory.
• E2B text-only on mobile is listed at about 0.84 GB.
• At launch Google said the 31B ranked #3 among open models on the Arena AI text leaderboard and the 26B #6.

The family kept growing: multi-token-prediction variants on 16 April, quantisation-aware (QAT) checkpoints in early June, and a Gemma 4 12B Unified model on 3 June that replaces separate vision and audio encoders with direct linear projections.

April: DeepSeek V4 preview

On 24 April DeepSeek released the V4 preview with open weights and a one-million-token context. According to The AI Cook's timeline, V4-Pro has 1.6 trillion parameters (49B active) and V4-Flash 284B (13B active). Impressive, but not homelab material: even with few active parameters, you still need memory for all the weights.

July–August: very large and very small

• Kimi K3 (Moonshot AI, late July) was reported as the largest open-weight model so far at 2.8 trillion parameters, with only 16 of its 896 experts active per token. It briefly topped a coding arena.
• DeepSeek V4 Flash 0731 (3 August) shipped under the MIT licence.
• Meta Muse Glimmer (11 August): Meta open-sourced a 30B agentic model that runs on a single GPU, a few weeks after it started charging for its frontier Muse Spark models.
• Qwen3.8-27B (Alibaba, 17 August): a dense multimodal model under Apache 2.0 that can run locally and be used commercially.
• GLM-5.3-Flash (Z.ai, 27 August), MIT-licensed, alongside a Qwen3.8-Flash-Next preview of a new architecture.

September: DeepSeek V4.1-Flash and MiMo

DeepSeek's V4.1-Flash (10 September) is the release I found most technically interesting. DeepSeek describes it as a 552B-parameter MoE with a new "causal encoder–decoder" design: 8B active parameters for input and 16B for output. It claims the KV cache needs a quarter of the HBM and an eighth of the SSD storage of the previous generation, and that it beats its own V4-Pro, which it started routing to V4.1-Flash on 14 September. The weights are on Hugging Face, and DeepSeek says it will work with the open-source community on inference support.

The KV-cache point matters more than the parameter count for anyone running agents: long agent sessions are dominated by context, and cache-hit costs are, in DeepSeek's words, often a large share of agent costs.

Later in the month Xiaomi's MiMo-V2.6 Pro (22 September), an MIT-licensed 1.02-trillion-parameter model, claimed the top open-weight spot according to The AI Cook.

October: Europe shows up

On 5 October Aleph Alpha released Kolibri, an Apache 2.0 German-English model of 78B parameters with about 3.5B active, explicitly aimed at data that has to stay on your own servers. It's the kind of model I'd like to see more of from Europe, especially given the transparency duties under the EU AI Act.

The counter-trend

Meta's paid Muse Spark 1.1 in July broke with its open-weights history, even if Muse Glimmer later came out open. The AI Cook summarises the year as "open weights went east": almost every leading open release came from Chinese labs (DeepSeek, Moonshot, Alibaba, Xiaomi, Z.ai). Open is not a given, and it makes the labs that keep publishing weights, under clear licences, more valuable.

What I'd actually run at home

Being honest about hardware: a trillion-parameter MoE is "open" but not "local" for most of us. For a single consumer GPU or a small homelab, the realistic candidates from this period are:

• Gemma 4 26B A4B or 31B at 4-bit (roughly 14–18 GB per Google's table) for general reasoning and agent experiments.
• Qwen3.8-27B where a dense, Apache-licensed multimodal model fits better.
• Muse Glimmer 30B for agentic tasks on one GPU, licence permitting.
• Gemma 4 E2B/E4B for on-device and edge experiments.

My takeaway: mixture-of-experts with few active parameters, plus good quantisation, makes local, privacy-friendly AI realistic for education and legal tooling. Read every licence, though: Apache 2.0 and MIT are easy; custom licences are not. For the tools I use to serve these models, see links & repos and the Homelab & Infra category.

Sources

• Google: Gemma 4, our most capable open models to date (2 April 2026)
• Google Open Source Blog: Gemma 4, expanding the Gemmaverse with Apache 2.0
• Google AI for Developers: Gemma releases
• Google AI for Developers: Gemma 4 model overview and memory requirements
• DeepSeek: Introducing DeepSeek-V4.1-Flash (10 September 2026)
• The AI Cook: AI Model Release Timeline 2026

What the course is

The course is free and built around the Hugging Face ecosystem: 🤗 Transformers, Datasets, Tokenizers, Accelerate and the Hub. Chapters 1–4 cover the basics of Transformers. After that it moves on to datasets and tokenizers, then classical NLP tasks, and finally more advanced LLM topics. The stated prerequisites are Python and some basic deep learning knowledge. You don't need a GPU to get value from the early chapters.

Each chapter ends with an ungraded quiz. Chapter 1 also has a short certification exam, hosted in a Hugging Face Space. You need to sign in to take it.

Chapter 1: Transformer models, demystified

The first chapter starts at the highest level: pipeline(). One call wraps preprocessing, the model and postprocessing. With it you can run sentiment analysis, zero-shot classification, text generation, fill-mask, named entity recognition, extractive question answering, summarization and translation. Small details turn out to matter. For example, the mask token depends on the model: [MASK] for BERT and <mask> for RoBERTa. Zero-shot classification also needs candidate_labels.

Then the chapter explains why it works. The ideas that clarified the most for me:

• Self-supervised pretraining. Language models learn without human labels, either by predicting the next token (causal LM) or by filling in masked tokens (masked LM).
• Transfer learning. Pretraining is expensive in both compute and environmental cost. So you start from pretrained weights and fine-tune on a smaller, task-specific dataset.
• Three architecture families. Encoder-only models (BERT, RoBERTa, ModernBERT) use bidirectional attention and suit classification, NER and extractive QA. Decoder-only models (GPT, Llama, Gemma, SmolLM) generate auto-regressively and are the base of modern LLMs. Encoder-decoder models (BART, T5, Marian) handle summarization and translation.
• Architecture vs. checkpoint. The architecture is the blueprint. The checkpoint is the trained weights. That distinction removes a lot of confusion when you browse the Hub.

The section on inference was the most useful part for practical work. Generation has two phases. Prefill processes the prompt and is compute-bound. Decode produces tokens one at a time and is memory-bound. That split explains why time to first token and time per output token behave so differently. It also explains why the KV cache matters: it avoids recomputing past keys and values. The chapter also covers sampling controls (temperature, top-k, top-p, repetition penalties) and why long contexts are costly.

There is also an honest section on bias and limitations. A fill-mask demo suggests gendered professions, and the course notes that fine-tuning does not remove bias inherited from pretraining. That is worth remembering in any domain where fairness matters, such as legal or educational applications.

Chapter 2: Behind the pipeline

Chapter 2 takes pipeline() apart: tokenizer → model (logits) → postprocessing (SoftMax → labels). Key takeaways:

• The tokenizer must match the checkpoint. AutoTokenizer.from_pretrained(checkpoint) and AutoModel.from_pretrained(checkpoint) should point to the same model.
• Models in the library are plain PyTorch nn.Modules. save_pretrained writes a config.json plus model.safetensors.
• Tokenization strategies: word-based (huge vocabularies), character-based, and subword methods (WordPiece, BPE, Unigram). Subword tokenization is the practical compromise.
• Batching needs padding, attention masks and truncation. A model expects a batch dimension, and forgetting it is a classic first error.

The chapter closes with deployment options: TGI (continuous batching, Flash Attention), vLLM (PagedAttention) and llama.cpp for smaller local models. If you run models yourself on a homelab or a VPS, this short section is a good map of the options.

Chapter 3: Fine-tuning a pretrained model

Chapter 3 is where it becomes concrete. You fine-tune a BERT classifier on MRPC from the GLUE benchmark, which asks whether two sentences are paraphrases. Along the way you learn:

• load_dataset("glue", "mrpc") and Dataset.map(batched=True) for fast tokenization of sentence pairs.
• DataCollatorWithPadding for dynamic padding per batch instead of padding everything to the maximum length.
• The Trainer API. TrainingArguments needs only an output_dir. For accuracy you add an evaluation strategy and a compute_metrics function. fp16=True turns on mixed precision.
• A manual training loop with AdamW, a linear scheduler and Accelerate, which shows what Trainer hides.
• Reading learning curves. Loss falls and then converges, while accuracy moves in steps. A large gap between training and validation means overfitting. Two curves that both plateau point to underfitting.

One small detail I liked: when you load a model with a new classification head, you get a warning that some weights are randomly initialised. That is expected. The head hasn't been trained yet.

How I'd recommend starting

1. Read Chapter 1 end to end, even if you know the basics. The architecture overview and the inference section give you shared vocabulary for everything after.
2. Run the code. The notebooks open in Colab. Typing pipeline("sentiment-analysis") and then taking it apart in Chapter 2 builds intuition faster than reading.
3. Do the quizzes. They're short and they catch the subtle misunderstandings. One question made me double-check that SoftMax outputs are between 0 and 1 and sum to 1.
4. Fine-tune something small. Chapter 3's MRPC example runs on a free GPU. Once it works, swap in your own dataset.
5. Treat it as a map, not a finish line. Later chapters cover datasets, tokenizers and more advanced LLM topics. I'm continuing with those.

Closing thought

The course doesn't sell you anything. It explains what's going on under the hood clearly and gives you working code. For anyone building with LLMs, whether you're shipping products or advising on how AI is used responsibly, that grounding pays off quickly.

Course link: Hugging Face LLM Course · Chapter 1 · Chapter 2 · Chapter 3

This blog is where I'll write down what I learn along the way. Not announcements, not predictions, just notes from actual work.

What I mean by "practical"

A lot of AI talk is about what models might do some day. I'm more interested in what they reliably do today, and in where they still fail. In legal and educational work, that difference matters. A tool that summarises a document well nine times out of ten still needs someone to check the tenth.

So the questions I keep coming back to are simple:

• Does this actually save someone time, or does it move the work somewhere else?
• Can a person see where an answer came from and check it?
• What happens to the data, and who controls it?
• What does it do when it doesn't know?

Legal AI

I have a background as a legal service provider, and I see how hard it can be for people to find clear information about their situation, especially in stressful cases like youth care. That's part of why I work on Steunvoor.nl, a free platform that gives parents clear information and support.

AI can help explain procedures, structure documents and point people to the right questions. It should not pretend to replace professional advice, and it should be explicit about its limits. Much of the design work is about exactly that: sources, uncertainty and knowing when to hand off to a human.

Educational AI

On the education side I'm building LeerHeld.nl, a learning platform for children and parents without ads or distractions. Here AI is useful for generating practice material and giving feedback, but children deserve tools that are calm, predictable and safe. I'd rather ship something modest that works than something impressive that confuses.

Agents and self-hosting

Behind the scenes I run a set of AI agents that each do one job: research, writing drafts, monitoring servers, keeping my projects in order. They run on my own servers and a small homelab, with cloud services where they make sense. Running things yourself teaches you quickly where the real costs and failure modes are: rate limits, flaky logins, memory that drifts, and agents that confidently do the wrong thing twice.

I'll write about those lessons too, including the mistakes.

What to expect here

• Write-ups of things I built and what went wrong
• Notes on agent design, open models and self-hosted infrastructure
• Thoughts on using AI carefully in legal and educational contexts
• A curated list of links and repositories I find genuinely useful

If something here is useful to you, or you think I'm wrong, I'd like to hear it. You can find me on LinkedIn, GitHub or via victorgrosser.nl.

If you build or deploy AI in Europe, the last six months changed the calendar you were planning against. The AI Act did not get repealed or radically rewritten, but its timeline moved, some obligations were softened, and a first big block of rules actually became enforceable on 2 August 2026. This is my attempt to put it in one place, with links to the primary sources at the bottom. It is a summary for builders, not legal advice.

The starting point

The AI Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and applies in stages. Bans on prohibited practices and the AI literacy duty came first, the obligations for general-purpose AI (GPAI) model providers started on 2 August 2025, and 2 August 2026 was the general date of application, including most rules for high-risk systems.

By spring 2026 it was clear that this last step was in trouble. The Omnibus regulation itself says why: harmonised standards were late, and many Member States had not yet set up their national competent authorities and conformity assessment structures. Companies were being asked to comply with high-risk requirements without the technical standards that are supposed to tell them how.

May: the Digital Omnibus deal

The Commission had proposed the "Digital Omnibus on AI" in late 2025 as part of its simplification agenda. On 7 May 2026 the European Parliament and the Council reached a provisional political agreement after nine hours of negotiations, as Reuters reported. Reuters framed it as "watered-down" rules; the Commission framed it as simpler, innovation-friendly implementation. Both descriptions are partly true, which is why the details matter.

The headline change is the high-risk timeline:

• Annex III high-risk systems (stand-alone use cases such as biometrics, critical infrastructure, education, employment, migration, asylum and border control) now apply from 2 December 2027.
• Annex I high-risk systems (AI built into products under EU product legislation, such as lifts or toys) now apply from 2 August 2028.

The agreement also added something new rather than removing it: a ban on AI systems that generate non-consensual intimate imagery and child sexual abuse material, the "nudification" apps. The Commission's enforcement page lists that prohibition as applying from 2 December 2026.

July: it becomes law

The deal was formally adopted as Regulation (EU) 2026/1744, published in the Official Journal and in force from 27 July 2026. EUR-Lex now has a consolidated version of the AI Act dated 27 July 2026, and the Commission's AI Act Service Desk marks Omnibus changes as "NEW" or "AMENDED" in its article-by-article text. That consolidated text is now the one to read; older summaries from 2024 and 2025 are outdated on dates.

A few changes in the Omnibus that I think are under-discussed:

• AI literacy (Article 4) was rewritten. Providers and deployers still have to take measures to ensure sufficient AI literacy of their staff, but the new text explicitly says this does not require them to guarantee any specific level of AI literacy of any individual. The Commission, Member States and the AI Board get a stronger role in promoting literacy.
• Small mid-caps (SMCs) get several of the reliefs that were previously reserved for SMEs, such as a simplified technical documentation form and priority access to sandboxes.
• A new Article 4a sets conditions for processing special categories of personal data where strictly necessary for bias detection and correction.
• Sandboxes: each Member State must have at least one national AI regulatory sandbox operational by 2 August 2027, and the AI Office may run a Union-level sandbox. Real-world testing outside sandboxes is extended to more high-risk categories.
• Grace period clarified: under Article 111(2), if at least one unit of a type and model of high-risk system was lawfully on the market before the relevant date, other units of the same type and model fall under the same grace period.

August: what actually became enforceable

2 August 2026 still mattered, just for different things than originally planned. According to the Commission's enforcement framework page and the AI Act Service Desk FAQ, from that date the enforcement powers of the AI Office and national authorities apply to:

1. Prohibited AI practices (manipulation, exploitation of vulnerabilities, certain social scoring and predictive policing based solely on profiling, and so on).
2. Obligations for GPAI model providers, including transparency towards downstream providers, copyright policies, and the safety and security duties for models with systemic risk. The Commission can now fine GPAI providers up to 3% of worldwide annual turnover or €15 million, whichever is higher (Article 101). It can also request information, demand access for model evaluations, and in serious cases ask for a model to be restricted.
3. Transparency obligations under Article 50.

The Article 50 rules are the ones most developers will feel first. Providers must design systems so people know when they are interacting with an AI system (chatbots, agents, avatars), and must add machine-readable marks to AI-generated or manipulated content. Deployers must disclose deepfakes, emotion recognition and biometric categorisation, and AI-generated text published to inform the public on matters of public interest when there was no human review or editorial control. The Commission lists fines of up to €15 million or 3% of turnover for companies.

There is one transitional detail worth noting: systems already on the market before 2 August 2026 have until 2 December 2026 to comply with the marking and detection duty in Article 50(2).

The Code of Practice on AI-generated content

To make Article 50 workable, the AI Office facilitated a Code of Practice on Transparency of AI-generated Content, drafted by independent experts. It has two sections: rules for providers on marking and detection, and rules for deployers on labelling deepfakes and AI-generated text. The EU also published a set of icons for labelling.

The Commission and the AI Board confirmed the code as an adequate voluntary tool to demonstrate compliance. Signing is voluntary, but the obligations are not: if you don't sign, you have to show that your own measures are equally adequate, assessed by each market surveillance authority. The Commission's page says about 190 companies and organisations had signed by the end of July 2026. Alongside the code, the Commission published guidelines on the scope of Article 50, including what counts as a directly interactive system, a deepfake, or standard editing that falls outside the rules.

What I take from it

Three practical points for anyone building AI products or agents in Europe:

• Transparency is now, not 2027. If your product talks to people, label it. If it generates images, audio or video, plan for machine-readable marking. This applies to agents too: the Commission explicitly names AI agents and avatars.
• The high-risk delay is not a holiday. Education and employment, two areas I care about for education tools, are Annex III. December 2027 is roughly fourteen months away, and standards still have to land. Documentation, logging and human-oversight design are much cheaper to build in than to retrofit.
• Read the consolidated text. Many blog posts and slide decks still quote 2 August 2026 for high-risk rules. That date is gone.

On the bigger question, whether the Omnibus weakens protection or just makes the law workable, I don't think we'll know until the first enforcement decisions under Article 50 and the GPAI rules appear. The useful thing for builders is that the timeline is now fixed in law instead of in rumours.

For the wider context of what models shipped in the same period, see my AI models recap for April–June 2026 and July–October 2026, the open-weight models recap, and my curated links & repos.

Sources

• EUR-Lex: Regulation (EU) 2026/1744 (Digital Omnibus on AI)
• EUR-Lex: AI Act consolidated version, 27 July 2026
• European Commission: EU agrees to simplify AI rules and ban 'nudification' apps (7 May 2026)
• Reuters: EU countries, lawmakers clinch provisional deal on watered-down AI rules (7 May 2026)
• European Commission: The enforcement framework of the AI Act
• AI Act Service Desk: When does enforcement start?
• AI Act Service Desk: Article 101, fines for GPAI providers
• European Commission: Safer and more transparent AI (2 August 2026)
• European Commission: Guidelines on transparency obligations (Article 50)
• European Commission: Code of Practice on Transparency of AI-generated Content
• European Commission: Guidelines for providers of GPAI models

1. Walter Isaacson, Elon Musk (2023): 3.5 / 5

I build AI systems for a living, and I advise on the legal side of AI. So I didn't read Walter Isaacson's Elon Musk (2023) as fan fiction or as a takedown. I read it as an engineering case study with a very loud main character. Here is my honest take, with the parts I'd use and the parts I'd leave on the shelf.

What the book is

Isaacson, who also wrote biographies of Steve Jobs, Einstein and Leonardo da Vinci, followed Musk for about two years. He sat in on meetings, read messages and interviewed family, colleagues and critics. The result runs to well over 600 pages, split into 95 short, chronological chapters with plain titles such as "Starlink, 2015–2018". Isaacson himself joked that someone called it a 600-page book for the TikTok generation.

That structure works. Musk runs SpaceX, Tesla, Starlink, Neuralink, The Boring Company, xAI and (from late 2022) Twitter/X in parallel, so the book jumps between Raptor engines, factory floors and server rooms. The short chapters keep it readable, and the engineering scenes are the strongest part of the book.

The story goes from a hard childhood in South Africa, through Zip2 and X.com/PayPal, to the near-bankruptcy years of Tesla and SpaceX in 2008, and ends with the Twitter takeover and the founding of xAI.

Lesson 1: First principles are a tool, not a personality

The idea that comes back most often is Musk's "algorithm" for engineering and manufacturing. Roughly: question every requirement, delete every part or process step you can, then simplify and optimise, then speed up, and only at the end automate. The order matters. Automating a step that should not exist is pure waste.

For AI builders this translates surprisingly well:

• Question the requirement. Does this feature really need an LLM, or would a rule or a database query do?
• Delete before you optimise. Fewer agents, fewer prompts, fewer tools often beat a cleverer orchestration layer.
• Automate last. Run the workflow by hand, understand where it breaks, then build the pipeline.

This is the most useful part of the book for me, and it's worth reading for these chapters alone.

Lesson 2: Speed vs safety is a real trade-off, and the book underplays the cost

Musk's style is a constant "maniacal sense of urgency": impossible deadlines, "surge" weekends, and a high tolerance for things blowing up. For rockets, a test explosion is data. In software it can be the same, because fast iteration beats endless planning.

But AI products don't fail like test rockets on an empty launch pad. They fail on users. Hallucinated legal advice, a biased screening model or a confident driver-assistance claim can hurt people who never agreed to be part of the test.

Several reviewers noticed what the book leaves out here. The New York Review of Books pointed out that Tesla's factory injury rates and the racism lawsuits at the Fremont plant get little or no attention, and that no assembly-line workers appear among the interviews. Others found the safety debate around Autopilot underexplored. As someone who works on AI governance, I'd say this is exactly the part builders need most: who carries the risk when you "move fast"? The book mostly doesn't ask.

My takeaway: copy the iteration speed in your sandbox, and keep it out of production for anything that touches people's rights, health or money.

Lesson 3: Leadership caveats

Isaacson doesn't hide Musk's harsh side. He describes a "demon mode", public humiliation of employees, and impulsive decisions like the mass layoffs and server moves at Twitter. He links some of this to Musk's childhood and his relationship with his father. Several critics, including The Independent, found these bullying scenes repetitive after a while, and I agree.

The bigger criticism, made by The Verge and the Los Angeles Times among others, is that the book stays close to the "great man" story. It explains the bad behaviour as the price of genius, and Isaacson's close access gives Musk plenty of room to tell his own myth. Not every bold promise in the book came true on schedule.

For leaders of AI teams, the honest lesson is narrow. High standards and fast feedback are useful. Fear-based management is not a requirement for great engineering. Plenty of strong teams ship hard things without it.

Pros and cons

Pros

• Unusual access and many first-hand scenes
• Excellent, concrete engineering chapters (the "algorithm", Raptor, factory work)
• Fast, readable structure with short chapters

Cons

• Repetitive in its scenes of conflict and deadlines
• Light on critical analysis, especially in the later Twitter chapters
• Important omissions: worker safety, discrimination claims, Autopilot safety
• Leans towards the "great man" framing

Verdict

Read it as an engineering and decision-making case study, not as a leadership manual. The first-principles material is genuinely useful for anyone building AI systems. The speed-at-all-costs mindset and the management style need a strong filter, and the book won't provide that filter for you.

My rating: 3.5 / 5. Worth reading for builders, as long as you read some of the critical reviews alongside it.

2. Ashlee Vance, Elon Musk (2015): 5 / 5

Before Isaacson there was Ashlee Vance. His Elon Musk: Tesla, SpaceX, and the Quest for a Fantastic Future (Ecco, 2015) was written before Musk became the most-discussed person on the internet, and that is its strength. Musk first declined to cooperate; Vance kept reporting anyway, interviewed around two hundred people, and Musk eventually agreed to a series of interviews.

The best chapters cover the years when it could all have gone wrong. After failing to buy a launch from Russia, Musk decided SpaceX would build its own rocket. Falcon 1 then failed three times (2006, 2007 and 2008) before the fourth launch reached orbit in September 2008. In the same year Tesla and SpaceX were both nearly out of money, and Musk had to decide whether to split what he had left between them. It reads like a thriller, and it shows first-principles thinking under real pressure.

For anyone building AI systems, the build-versus-buy question is the lasting lesson. Do you own your models and infrastructure, or depend on a vendor? I work on that trade-off every day, in a homelab as well as in client projects. The book is also a reminder that speed without good governance has a price, for employees and for others.

It is dated now (it predates Starlink as a consumer service and xAI), but as an origin story it holds up. My rating: 5 / 5 as an origin story.

Read them together

Vance gives you the near-death years and the origin of the method; Isaacson gives you the method at full scale, and its costs. Read Vance first, then Isaacson with a critical review or two alongside it.

The core model: state, nodes, edges

A LangGraph application is a StateGraph made of three things.

State is the shared data structure that flows through the graph. You define it as a TypedDict, a dataclass or a Pydantic model. Pydantic adds runtime validation. Every node reads the state and returns updates to it.

Nodes are plain Python functions. A node might call a chat model, run a tool or transform data. It returns a partial state update and doesn't need to know about the rest of the graph.

Edges connect nodes. Normal edges always go from A to B. Conditional edges run a function that picks the next node based on the state. You wire up START and END, call compile(), and run it with invoke().

The detail that's easy to miss is reducers. By default, a node's update overwrites a key. With Annotated[list, operator.add] updates are appended instead. The built-in add_messages reducer appends messages or updates them by id, and supports RemoveMessage. Reducers become essential when nodes run in parallel and write to the same key.

From chain to agent in a few steps

The course builds up in steps that make the design choices visible:

1. Chain: state is a list of messages (MessagesState), with a chat model that has tools bound via bind_tools.
2. Router: the model either answers directly or emits a tool call. A ToolNode plus the prebuilt tools_condition edge handles the routing.
3. Agent (ReAct): add an edge from the tool node back to the model, so it loops until there are no more tool calls.

So an "agent" is a router with a loop, and nothing more mysterious than that. Once you see it this way, you can decide exactly where the loop is allowed and where it isn't.

Memory: short-term and long-term

LangGraph separates two kinds of memory.

Short-term (thread) memory comes from a checkpointer. Compile the graph with MemorySaver (or SqliteSaver for persistence), pass a thread_id in the config, and the state is saved after every step. The next invocation on the same thread continues where the last one stopped. Conversations grow, so the course shows how to keep the context bounded: remove messages, pass only the last N, use trim_messages by token count, or keep a running summary.

Long-term memory works across threads through a Store, such as InMemoryStore, keyed by a namespace tuple plus a key. You decide on a memory schema. It can be a profile, which is one JSON document per user, or a collection, a growing list of items. The final example in the module is an assistant that decides for itself when to update the user's profile, a to-do collection or its own instructions.

When to use what: a checkpointer is almost always worth adding, because it also enables human-in-the-loop and debugging. Long-term memory only makes sense when you actually need personalisation across sessions. It is also a data-protection question, so design what you store deliberately.

Human-in-the-loop

This is where LangGraph clearly beats an opaque loop. Because state is checkpointed, you can pause a graph, inspect it, change it and resume:

• Breakpoints: interrupt_before=["tools"] stops before a node, for example before a tool runs. Resuming with invoke(None, config) continues from the checkpoint.
• Editing state: graph.update_state(config, values, as_node=...) lets a human correct the state, for example to fix a tool argument, before continuing.
• Dynamic breakpoints: a node can raise an interrupt conditionally, for example only when an amount exceeds a threshold.
• Time travel: get_state_history lets you replay from an earlier checkpoint, or fork by updating an old one and running from there.

When to use it: any action with real consequences, such as sending a message, changing a record or spending money, should go through an explicit approval point. In legal or educational contexts, I'd consider this the default rather than an optional extra.

Scaling the graph: parallelism, sub-graphs, map-reduce

Module 4 builds a research assistant. It generates analyst personas (with human feedback on the personas), runs parallel interviews using web and Wikipedia search, writes sections, and combines them into a report. The patterns along the way:

• Fan-out/fan-in parallelism, which needs reducers on shared keys.
• Sub-graphs with their own state, which talk to the parent through overlapping keys.
• Map-reduce with the Send API, which spawns a dynamic number of parallel nodes and then aggregates the results.

When to use them: only when the task really splits into independent pieces. Every extra branch adds coordination and evaluation work. Start with a single agent and tools, and add structure when a trace shows you need it.

Deployment and streaming

The course also covers the operational side. You can stream either state updates or full values, and stream tokens with astream_events. LangGraph Studio is useful for visual debugging. For deployment, a langgraph.json plus a Docker image runs on LangGraph Server, which handles the API, a task queue and Postgres persistence. There are clients through the SDK or RemoteGraph. Two ideas I hadn't considered before: double-texting strategies (reject, enqueue, interrupt or rollback when a user sends a new message mid-run) and assistants, which are versioned configurations of the same graph.

When LangGraph is the right tool

• Use it when you need control over the flow, durable state, approvals or resumable runs. That usually means multi-step agents that act on real systems.
• Skip it for a single prompt-and-answer or a fixed linear pipeline, where plain code is simpler.
• Keep it simple first. A predefined workflow is easier to test than a free agent, and a single agent is easier than several. The graph makes that trade-off explicit, which is exactly why I like it.

Getting started

The course is free. The code is in the public langchain-academy repository as Jupyter notebooks, one folder per module, with a studio folder you can run with langgraph dev. You'll need Python 3.11+ and an API key for a chat model. Tracing through LangSmith is optional but very helpful. Work through the modules in order: each one adds a single concept on top of the last.

Links: Introduction to LangGraph – LangChain Academy · LangGraph documentation · Course notebooks on GitHub

This is the second half of my look back at 2026's model releases. The April–June recap was about cadence and agents. July to October was about price, gating and an almost absurd release frequency. As before, prices are list API prices per million input/output tokens at launch.

July: the busiest month for flagships

• Claude Sonnet 5 (1 July) became the default for Free and Pro users and closed much of the gap to Opus 4.8 on agentic work at a fraction of the cost.
• GPT-5.6 Sol, Terra and Luna (9 July). Three tiers at three prices: Sol $5/$30, Terra $2.50/$15 and Luna $1/$6. They launched together with GPT-Live, OpenAI's first full-duplex voice model.
• Grok 4.5 (9 July) went public within hours of GPT-5.6, with big claims but, as The AI Cook noted, no system card or benchmark table.
• Meta Muse Spark 1.1 (9 July) was Meta's first paid model ($1.25/$4.25), a clean break from its open-weights history.
• Gemini 3.6 Flash and Flash Cyber (22 July). A cheaper Flash plus a security-tuned twin.
• Claude Opus 5 (late July): close to Fable 5 intelligence at roughly half the price, with Opus pricing held at $5/$25.

July is where launches started to lead with the invoice. Three tiers from OpenAI, a cheaper Flash from Google, and an Opus that halved the cost of near-top capability all point the same way.

August: price cuts and open weights

No new top-tier flagship from the big three in August, so the action moved elsewhere:

• Gemini 3.7 Flash (14 August) at $0.75/$3.75, half the price of 3.6 Flash. DeepSeek V4-Pro went generally available the same day.
• Grok 4.6 (13 August) with frontier-level index scores at $2/$6.
• GPT-5.6-Cyber (11 August), gated behind vetted tiers, the same week Meta open-sourced a 30B agentic model, Muse Glimmer.
• A wave of open-weight and Asian-lab releases (Qwen3.8, GLM-5.3-Flash, a new DeepSeek V4 Flash checkpoint), covered in my open-weight models recap.

September: the densest month of the year

• Claude Fable 5.1 (2 September) with cache reads 75% cheaper, which The AI Cook estimates as about 25% off a typical workload.
• Gemini 3.8 Flash and 3.8 Flash Cyber (2–3 September). Google's own post describes it as building on 3.7 Flash from three weeks earlier, and its third Flash release in six weeks. Again the cyber variant was gated.
• GPT-6 Astra (4 September), built around computer use. OpenAI claimed 98% on FrontierMath Tier 4 and 99.9% on ARC-AGI-3. I'm repeating those as claims; I'd like to see independent replication before treating them as settled.
• Meta Muse (9 September), a personal agent on Muse Spark 1.3 that books, buys and fills in forms inside its own sandboxed virtual machine.
• DeepSeek-V4.1-Flash (10 September). DeepSeek's announcement describes a 552B-parameter MoE with 8B active parameters for input and 16B for output, a KV cache needing a quarter of the HBM of the previous generation, and results ahead of its own V4-Pro, which it began phasing out.
• Claude Opus 5.5 and GPT-6 Sol/Luna (23 September), on the same afternoon. Opus 5.5 moved Opus pricing to $4/$20; GPT-6 Sol and Luna halved the API price of the models they replaced.
• Claude Sonnet 5.5 (29 September) and GPT-6.1 Sol (30 September), the latter replacing GPT-6 Sol after a single week at $2/$10.

October so far

• Gemini 4 Argon (1 October), Google DeepMind's most powerful model, with a one-million-token output limit, released first to cyber defenders only.
• Kolibri (5 October), an Apache 2.0 German-English model from Aleph Alpha (78B, about 3.5B active) aimed at data that has to stay on your own servers. Interesting for European, on-premise use.
• GPT-5.5 retires on 14 October, less than six months after launch.

What I take from it

1. Release cycles are measured in weeks. GPT-6 Sol lived seven days. Don't chase every launch: keep your system model-agnostic and swap only when your own tests show a difference.
2. Read the pricing page, not just the benchmark. Caching discounts and tiered models delivered some of the largest real savings of the year.
3. The strongest models increasingly reach defenders first. Mythos 5, GPT-5.6-Cyber, the Flash Cyber models and Gemini 4 Argon all followed that route.
4. Transparency rules arrived mid-summer. Since 2 August, the EU AI Act requires disclosure when people interact with AI and machine-readable marks on generated content; see my EU AI Act recap.
5. Coding sells. Nearly every launch led with a coding or agentic score. That's where paying customers are, and it's worth asking whether those benchmarks match your own tasks.

Outside AI, the same months had their own milestones: Starship reached orbit and the Roman Space Telescope launched, covered in my space recap. For tools I actually use, see links & repos.

Sources

• The AI Cook: AI Model Release Timeline 2026 (updated 5 October 2026)
• Google: Introducing Gemini 3.8 Flash and 3.8 Flash Cyber (2 September 2026)
• DeepSeek: Introducing DeepSeek-V4.1-Flash (10 September 2026)
• OpenAI: Research releases

Spring 2026 was dense enough that it's easy to remember it as one blur of launch posts. I went back through release notes and trackers to separate what changed in practice from what was just noise. Prices below are list API prices per million input/output tokens at launch, as reported by the sources at the bottom.

April: four flagships in ten days

April is when the 2026 race properly started. Google, OpenAI, Anthropic and DeepSeek all shipped flagship models within about ten days of each other.

• GPT-5.4 on the free tier (10 April). OpenAI opened a reasoning-class model to free ChatGPT users. Not a new model, but it reset expectations of what "free" includes.
• Claude Opus 4.7 (mid-April). Anthropic shipped stronger coding and a higher image-input ceiling of roughly 3.75 megapixels, launched on five clouds at once, and kept pricing at $5/$25.
• Gemini 3 Pro preview, 3.1 Pro and 3 Flash (22 April). Announced at Google Cloud Next. Gemini 3 Pro took first place on LMArena at 1,501 Elo and scored 91.9% on GPQA Diamond, according to The AI Cook's tracker.
• ChatGPT Images 2.0 (22 April). Image generation that reasons before it draws, up to 2K resolution.
• GPT-5.5 (23 April). Pitched as a model for "real work": it plans, uses tools, checks itself and keeps going. It arrived six weeks after GPT-5.4 and reached ChatGPT, the API and GitHub Copilot within days.
• DeepSeek V4 preview (24 April). Open weights with a one-million-token context. V4-Pro has 1.6 trillion parameters (49B active), V4-Flash 284B (13B active). More on that side of the field in my open-weight models recap.

What stood out to me in April was not a single benchmark number but the cadence. A flagship that is six weeks old being replaced is a different world from the yearly cycles we had not long ago.

May: from chat to agents

May was a month of agents rather than models. The big labs spent it turning chatbots into things that act.

• GPT-5.5 Instant (6 May) quietly became ChatGPT's default for everyday chats.
• Grok Build (15 May). xAI's terminal coding agent, its answer to Claude Code and Codex, running up to eight workers, launched behind a $299 SuperGrok Heavy plan. On 29 May a Grok Build 0.1 model followed on the API at about 100 tokens per second and $1/$2.
• Gemini Spark and Gemini Omni (20 May). At Google I/O, Gemini was reframed as an always-on agent that can carry out tasks inside other apps, not just answer questions.
• Claude Opus 4.8 (28 May). SWE-bench Pro rose from 64.3% to 69.2% and a Fast mode ran about 2.5 times quicker, with no price increase.

The pattern here is that "the model" is becoming an implementation detail of a product that acts: a coding agent, an assistant inside other apps. For people building their own agents and MCP tools, that's encouraging and a warning at once: the interesting work moves to orchestration, permissions and evaluation.

June: gated capability and short lifetimes

• Microsoft MAI-Thinking-1 (3 June). Microsoft's first in-house reasoning model, shown at Build alongside MAI-Image-2.5. A clear sign it wants options beyond OpenAI.
• Gemma 4 QAT checkpoints (8 June). Quantisation-aware versions of Google's open Gemma 4 family; the smallest text model runs in under 1 GB of memory.
• Claude Fable 5 and Claude Mythos 5 (10 June). Fable 5 became the first Mythos-class model open to the public, at $10/$50. The unrestricted Mythos 5 went only to vetted cyber defenders.
• Retirements (mid-June). Anthropic retired Claude Sonnet 4 and Opus 4 on 16 June; OpenAI had retired GPT-5.2 days earlier.

The Fable/Mythos split is the June story I keep coming back to. A public model plus a restricted security variant turned into a pattern for the rest of the year: Google's Flash Cyber models, GPT-5.6-Cyber and Gemini 4 Argon all followed the same route. I think that's a reasonable response to dual-use capability, but it also means the "best model" you can benchmark is no longer the best model that exists.

What I take from these three months

1. Benchmarks moved, but the real change was the work around them. Models that plan, use tools and check themselves matter more than a few points on a leaderboard.
2. Plan for model churn. If a model can be retired weeks after its successor ships, hard-coding model names into a product is technical debt. Keep a small abstraction layer and your own evaluation set.
3. Price per task beats price per token. Faster modes, caching and smaller tiers often change the bill more than a headline price change.
4. Regulation runs in parallel. The same weeks saw the EU's Digital Omnibus deal on the AI Act; I wrote about that in The EU AI Act, April–October 2026.

A note on sources: much of the timeline below comes from third-party trackers that compile launch posts. I've linked first-party pages where I could; where only a tracker is cited, treat exact dates as "reported" rather than official.

Continue with AI models in July–October 2026, or browse my curated links & repos.

Sources

• The AI Cook: AI Model Release Timeline 2026 (updated 5 October 2026)
• BenchLM: AI model releases in April 2026
• OpenAI: Research releases
• DeepSeek: DeepSeek-V4.1-Flash announcement (with links to the V4 preview)