Today, we are in­tro­duc­ing Kimi K3 — our most ca­pa­ble model. Kimi K3 is a 2.8T-parameter model built on our Kimi Delta Attention and Attention Residuals, with na­tive vi­sion ca­pa­bil­i­ties and a 1-million-token con­text win­dow. It is the world’s first open 3T-class model, de­signed for fron­tier in­tel­li­gence across long-hori­zon cod­ing, knowl­edge work, and rea­son­ing.

While its over­all per­for­mance still trails the most pow­er­ful pro­pri­etary mod­els, Claude Fable 5 and GPT 5.6 Sol, Kimi K3 demon­strated fron­tier-level per­for­mance across our eval­u­a­tion suite, con­sis­tently out­per­form­ing other tested mod­els.

Kimi K3 is avail­able to­day on Kimi.com, Kimi Work, Kimi Code, and the Kimi API. At launch, Kimi K3 will use max think­ing ef­fort by de­fault, with low- and high-ef­fort modes to be in­tro­duced in sub­se­quent up­dates. We are cur­rently work­ing closely with in­fer­ence part­ners and open-source main­tain­ers to align tech­ni­cal de­tails and en­sure a re­li­able roll­out across the ecosys­tem. The full model weights will be re­leased by July 27, 2026. Further de­tails on the ar­chi­tec­ture, train­ing, and eval­u­a­tions will be re­leased along­side the Kimi K3 tech­ni­cal re­port.

An Open 3T-Class Model

Kimi K3 is the first open model to reach 2.8 tril­lion pa­ra­me­ters. It marks the lat­est step in Kimi’s sus­tained push at the scal­ing fron­tier: for nine of the past twelve months, Kimi mod­els have set the up­per bound of open-model sizes.

Kimi K3 is built on Kimi Delta Attention (KDA) and Attention Residuals (AttnRes), two ar­chi­tec­tural up­dates de­signed to im­prove how in­for­ma­tion flows across se­quence length and model depth. We have also scaled up Mixture of Experts (MoE) spar­sity, ef­fec­tively ac­ti­vat­ing 16 out of 896 ex­perts when paired with a Stable LatentMoE frame­work. Together with re­fined train­ing and data recipes, these struc­tural changes yield an ap­prox­i­mate 2.5× im­prove­ment in over­all scal­ing ef­fi­ciency com­pared to Kimi K2, al­low­ing the model to con­vert com­pute into in­tel­li­gence more ef­fec­tively.

Coding

Kimi K3 has strong long-hori­zon cod­ing per­for­mance. Operating with min­i­mal hu­man over­sight, it can sus­tain long en­gi­neer­ing ses­sions, nav­i­gate mas­sive repos­i­to­ries, and or­ches­trate ter­mi­nal tools.

Kimi K3 also ex­cels in tasks blend­ing soft­ware en­gi­neer­ing with vi­sual rea­son­ing — it lever­ages screen­shots and vi­su­als to op­ti­mize game dev, fron­tend, and CAD.

The case stud­ies be­low show how Kimi K3′s cod­ing ca­pa­bil­ity trans­lates into open-ended soft­ware cre­ation and sci­en­tific re­search.

Kernel Optimization

We tested the mod­els’ ca­pa­bil­ity to op­ti­mize GPU ker­nels. Each model works in­de­pen­dently in an iden­ti­cal sand­box, with up to 24 hours to pro­file, rewrite, and bench­mark four tasks span­ning AttnRes, KDA, and a 512-head-dimension MLA ker­nel across NVIDIA H200 and GPGPU from an al­ter­na­tive ven­dor. Kimi K3 per­formed com­pet­i­tively with Fable 5 (with fall­back) and sub­stan­tially out­per­formed Opus 4.8, GPT 5.6 Sol, and GPT 5.5.

Claude Fable 5 was eval­u­ated by a third party, and its re­sults may in­clude fall­back be­hav­ior. Across most mod­els, some tra­jec­to­ries in­clude small, ac­cept­able pre­ci­sion short­cuts that re­main within our nu­mer­i­cal tol­er­ance. GPGPU de­notes gen­eral-pur­pose GPUs used for com­pu­ta­tion be­yond graph­ics ren­der­ing.

In the late stages of Kimi K3 de­vel­op­ment, an early ver­sion of Kimi K3 han­dled the ma­jor­ity of the team’s ker­nel op­ti­miza­tion works.

GPU Compiler Development

We fur­ther tested whether Kimi K3 could build a GPU pro­gram­ming sys­tem from scratch. Kimi K3 de­vel­oped MiniTriton, a com­pact Triton-like com­piler with its own tile-level IR layer over MLIR, op­ti­miza­tion passes, and a PTX code-gen­er­a­tion pipeline. Across sup­ported roofline bench­marks, MiniTriton de­liv­ers per­for­mance on par with or bet­ter than Triton and torch.com­pile — beat­ing Triton on cer­tain work­loads. Beyond mi­crobench­marks, MiniTriton sus­tains end-to-end nanoGPT train­ing with sta­ble con­ver­gence, the loss curve closely track­ing the ref­er­ence with only mi­nor di­ver­gence — val­i­dat­ing the full pipeline on a re­al­is­tic work­load. These re­sults demon­strate that Kimi K3 can build a co­her­ent end-to-end com­piler — from DSL fron­tend and IR passes to PTX code­gen and run­time — rather than iso­lated ker­nels; its from-scratch Tensor Core path al­ready ri­vals Triton’s ex­ten­sively op­ti­mized stack.

Game Dev and Digital Creation

Kimi K3 com­bines strong 3D rea­son­ing, cod­ing, and vi­sion ca­pa­bil­i­ties to turn con­cepts, im­ages, and videos into fully playable in­ter­ac­tive ex­pe­ri­ences. Kimi K3 achieves true “vision in the loop” by seam­lessly it­er­at­ing be­tween code and live screen­shots—in­stantly see­ing and re­fin­ing out­puts.

Chip Design

As an early proof of con­cept, Kimi K3 de­signed a chip to serve a nano model built on its own ar­chi­tec­ture. In a sin­gle 48-hour au­tonomous run, K3 built, op­ti­mized, and ver­i­fied the chip us­ing open-source EDA tools on the Nangate 45nm li­brary. Within 4 mm², the chip closes tim­ing at 100 MHz and sus­tains over 8,700 to­kens/​s de­code through­put in sim­u­la­tion, pack­ing 1.46M stan­dard cells, 0.277 MB of SRAM, and an INT4 MAC ar­ray with fused de­quan­ti­za­tion. A chip built by a model, for a model, re­flects K3′s long-hori­zon agen­tic ca­pa­bil­i­ties.

Coding for Research

Kimi K3 bridges sci­en­tific lit­er­a­ture and ex­e­cutable code, au­tonomously im­ple­ment­ing, val­i­dat­ing, and an­a­lyz­ing com­plex com­pu­ta­tional re­search work­flows.

In one case, Kimi K3 com­pleted in about two hours what would typ­i­cally re­quire one to two weeks of work by an ex­pe­ri­enced re­searcher. To re­pro­duce the I–Love–Q uni­ver­sal re­la­tions in com­pu­ta­tional as­tro­physics, it re­viewed and cross-val­i­dated 20+ pa­pers, im­ple­mented the full nu­mer­i­cal pipeline, eval­u­ated 300+ equa­tions of state, iden­ti­fied in­con­sis­ten­cies in pub­lished for­mu­las, gen­er­ated 3,000+ lines of Python code, and pro­duced an in­ter­ac­tive HTML dash­board for ex­plor­ing the re­sults.

Knowledge Work

Kimi K3 ad­vances end-to-end knowl­edge work. Beyond pub­lic bench­marks, Kimi K3 (max) demon­strates con­sis­tent gains across our in­ter­nal eval­u­a­tions, which are de­rived from re­cur­ring pat­terns and chal­lenges ob­served in real-world user-agent work­flows. These con­sis­tent ad­van­tages across dis­tinct pro­duc­tion-ori­ented work­flows re­flect a broad im­prove­ment in Kimi K3′s agen­tic knowl­edge work ca­pa­bil­i­ties.

Research with Interactive Visualization

Below are a few ex­am­ples of what Kimi K3 in Kimi Work can pro­duce across fi­nan­cial con­sult­ing and sci­en­tific re­search:

Case 1: Interactive 42 years of AI ASIC in­dus­try re­search web­site

An in­ter­ac­tive re­search re­port you can drill into: 42 years of the ASIC in­dus­try, cre­ated through 120+ rounds of re­cur­sive self-im­prove­ment. Kimi K3 trans­forms ev­i­dence into be­spoke charts, an­i­mated di­a­grams, and in­ter­ac­tive vi­sual nar­ra­tives. It pulled data via 2.8k+ web searches/​fetches and 1.1k+ ter­mi­nal data pulls, across 11k+ pages span­ning 87 quar­terly re­ports and 99 orig­i­nal PDFs.

Case 2: Fusion Industry Research

A con­sult­ing-style in­dus­try re­port with in­ter­ac­tive vi­su­al­iza­tions—in­clud­ing time­lines, Funnel Chart, Range Bar Chart, Gantt Charts, and pub­li­ca­tion-qual­ity slides.

Case 3: GWTC-5 Gravitational-wave Analysis

An analy­sis of 391 grav­i­ta­tional-wave events us­ing 20+ con­cur­rent sub­agents, pro­duc­ing 7 sci­en­tific vi­su­al­iza­tions, 2 ta­bles, and a lit­er­a­ture syn­the­sis from 10+ pa­pers.

Kimi K3 is also par­tic­u­larly ef­fec­tive at pro­duc­ing in­fo­graphic-style pre­sen­ta­tions, such as the fully ed­itable heatmap and an­nual re­port shown be­low:

Widgets and Dashboard

In Kimi Work, we in­tro­duce two new fea­tures - Widgets and Dashboard - which make in­ter­ac­tions with Kimi K3 more vi­sual and per­sis­tent. Widgets let you gen­er­ate in­ter­ac­tive com­po­nents di­rectly within a chat, with con­nec­tions to lo­cal data or ex­ter­nal plu­g­ins for con­tin­u­ous up­dates. Dashboard brings the wid­gets you care about most into one per­sis­tent, per­son­al­ized view or­ga­nized around a topic, pro­ject, or goal.

Video Editing

Kimi K3 ex­cels at mo­tion de­sign, an­i­ma­tion, and video edit­ing be­cause its na­tive mul­ti­modal ar­chi­tec­ture un­der­stands text, im­ages, and video within the same model.

In one ex­am­ple, K3 cre­ated a 3Blue1Brown-style mo­tion-graph­ics ex­plainer of its own ar­chi­tec­ture, trans­lat­ing tech­ni­cal ideas into an­i­mated di­a­grams and tran­si­tions.

In an­other, Kimi K3 edited its own teaser video from 56 source clips, han­dling clip se­lec­tion, mo­tion-matched cuts, frame-ac­cu­rate beat syn­chro­niza­tion, au­dio pro­cess­ing, and mul­ti­ple rounds of re­vi­sion. A high-den­sity short video like this would typ­i­cally take an ex­pe­ri­enced ed­i­tor one to two work­ing days, or a be­gin­ner three to five.

Architecture and Infrastructure

Kimi K3 is built on Kimi Delta Attention (KDA) and Attention Residuals (AttnRes). KDA pro­vides an ef­fi­cient foun­da­tion for scal­ing at­ten­tion, while AttnRes se­lec­tively re­trieves rep­re­sen­ta­tions across depth rather than ac­cu­mu­lat­ing them uni­formly. Together, they form the ar­chi­tec­tural back­bone of a model de­signed to scale well be­yond the tril­lion-pa­ra­me­ter regime.

Kimi K3 uses Stable LatentMoE, ef­fec­tively ac­ti­vat­ing 16 of 896 ex­perts. At this level of spar­sity, rout­ing and op­ti­miza­tion be­come first-or­der chal­lenges. Quantile Balancing de­rives ex­pert al­lo­ca­tion di­rectly from router-score quan­tiles, elim­i­nat­ing heuris­tic up­dates and a sen­si­tive bal­anc­ing hy­per­pa­ra­me­ter, while Per-Head Muon ex­tends Muon by op­ti­miz­ing at­ten­tion heads in­de­pen­dently for more adap­tive learn­ing at scale. Sigmoid Tanh Unit (SiTU) and Gated MLA im­prove ac­ti­va­tion con­trol and at­ten­tion se­lec­tiv­ity re­spec­tively. Together, these ad­vances en­able sta­ble and ef­fi­cient train­ing at the 2.8-trillion-parameter scale.

Kimi K3 ap­plies quan­ti­za­tion-aware train­ing from the SFT stage on­ward, us­ing MXFP4 weights with MXFP8 ac­ti­va­tions for broad hard­ware com­pat­i­bil­ity. To pre­vent ex­pert im­bal­ance from de­grad­ing through­put at large ex­pert-par­al­lel scales, we in­tro­duce a fully bal­anced ex­pert-par­al­lel train­ing method with sta­tic shapes and no host syn­chro­niza­tion on the crit­i­cal path. Since in­fer­ence ef­fi­ciency like­wise ben­e­fits from larger high-band­width com­mu­ni­ca­tion do­mains, we rec­om­mend de­ploy­ing Kimi K3 on su­pern­ode con­fig­u­ra­tions with 64 or more ac­cel­er­a­tors. Finally, as KDA poses new chal­lenges for con­ven­tional pre­fix caching, we have con­tributed a cor­re­spond­ing im­ple­men­ta­tion to the vLLM com­mu­nity, to be re­leased along­side the model. KDA with pre­fill cache al­lows us to serve Kimi K3 at a highly com­pet­i­tive to­ken price de­spite its scale and long con­text.

More tech­ni­cal de­tails will be avail­able in our com­ing re­port.

Availability

Kimi K3 Agents: Download or up­date to the lat­est Kimi app from your mo­bile app store, avail­able on iOS, Android, and HarmonyOS, or visit kimi.com.

Work with Kimi K3: Download the lat­est Kimi Work desk­top app, ver­sion 3.1.0 or later, avail­able for Windows and Apple sil­i­con Macs.

Code with Kimi K3: Run Kimi Code in your ter­mi­nal and se­lect Kimi K3 us­ing the /model com­mand.

Build with the Kimi API: Visit the Kimi API Platform and se­lect kimi-k3. Pricing is $0.30/MTok for cache-hit in­put, $3.00/MTok for cache-miss in­put, and $15.00/MTok for out­put. Powered by Mooncake’s dis­ag­gre­gated in­fer­ence ar­chi­tec­ture, the of­fi­cial Kimi API achieves a cache hit rate above 90% in cod­ing work­loads.

Bring Kimi to your or­ga­ni­za­tion: Kimi Enterprise pro­vides en­ter­prise-grade data pri­vacy and mem­ber man­age­ment, with com­plete sep­a­ra­tion be­tween per­sonal and or­ga­ni­za­tion ac­counts. Visit the pric­ing page and se­lect “Get Kimi Enterprise” to sub­scribe for your team.

Full Benchmark Table

Footnotes

All Kimi K3 re­sults re­ported be­low are ob­tained with the rea­son­ing ef­fort set to ‘max’, set­ting tem­per­a­ture = 1.0 and top-p = 1.0. Depending on the bench­mark, each model is eval­u­ated un­der one of three agen­tic har­nesses — KimiCode, Claude Code, or Codex — as spec­i­fied in the notes be­low.

Coding bench­marks

DeepSWE. Kimi K3 is eval­u­ated with the KimiCode har­ness. The GLM-5.2 score is taken from the GLM-5.2 re­lease blog (https://​z.ai/​blog/​glm-5.2); all re­main­ing scores are from the of­fi­cial DeepSWE leader­board (https://​deep­swe.dat­acurve.ai/), un­der which Kimi K3 at­tains 67.3 with the mini-SWE-agent har­ness. We re­port the DeepSWE v1.1 tasks.

Terminal-Bench 2.1. Kimi K3 is eval­u­ated with the KimiCode har­ness. For all other mod­els, we re­port the best score across har­nesses: GLM-5.2 with Claude Code (https://​z.ai/​blog/​glm-5.2); Claude Opus 4.8 and Claude Fable 5 with Terminus 2 (https://​ar­ti­fi­cial­analy­sis.ai/​eval­u­a­tions/​ter­mi­nal­bench-v2 – 1); GPT 5.5 and GPT 5.6 Sol with Codex (https://​ope­nai.com/​in­dex/​pre­view­ing-gpt-5 – 6-sol/).

Program Bench. Kimi K3 is eval­u­ated with the KimiCode har­ness. The GLM-5.2 score is from https://​z.ai/​blog/​glm-5.2; all other scores are from https://​www.vals.ai/​bench­marks/​pro­gram­bench.

SWE Marathon. Kimi K3, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT-5.6 Sol is eval­u­ated with the Codex har­ness. The GLM-5.2 score is from https://​z.ai/​blog/​glm-5.2. Our eval­u­a­tion is based on an H20-calibrated branch of the of­fi­cial v1.1 tasks (https://​www.swe-marathon.org/): the Docker im­ages, per­for­mance gates, and ref­er­ence or­a­cles for the GPU tasks have been re­cal­i­brated for H20, while the cor­rect­ness and anti-cheat val­ida­tors re­main un­changed. Additionally, Claude Fable 5 hit fall­backs on 35% of the tasks in our eval­u­a­tion, which may have neg­a­tively im­pacted its mea­sured per­for­mance.

FrontierSWE. Kimi K3 is eval­u­ated with the KimiCode har­ness and GPT-5.6 Sol with the Codex har­ness; all other re­sults are from https://​www.fron­tier­swe.com/. Dominance scores are re­com­puted from the raw scores us­ing the of­fi­cial eval­u­a­tion script and are cur­rent as of July 16, 2026.

PostTrain Bench. Scores for GLM-5.2, GPT-5.5, and Claude Opus 4.8 are adopted from the of­fi­cial PostTrainBench (https://​post­train­bench.com/) re­sults. Kimi K3, Claude Fable 5, and GPT-5.6 Sol are eval­u­ated with the of­fi­cial Harbor im­ple­men­ta­tion at max­i­mum rea­son­ing ef­fort, av­er­aged over three runs on H20 GPU (instead of H100 in the of­fi­cial set­ting) — Kimi K3 and Claude Fable 5 with the Claude Code har­ness, and GPT-5.6 Sol with the Codex har­ness.

MLS Bench Lite. Kimi K3 is eval­u­ated with the KimiCode har­ness; GLM-5.2 and the Claude mod­els with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness.

KCB 2.0. Kimi K3 is eval­u­ated with both the KimiCode and Claude Code har­nesses; GLM-5.2, Claude Opus 4.8, and Claude Fable 5 with the Claude Code har­ness; GPT-5.5 and GPT-5.6 Sol with the Codex har­ness. All mod­els are eval­u­ated at max­i­mum rea­son­ing ef­fort, ex­cept GPT-5.5, which uses the “xhigh” set­ting. We also note that on this in-house bench­mark, 10% of the tasks en­tered GPT-5.6 Sol’s cy­ber guard.

Productivity and agen­tic bench­marks

For OfficeQA Pro, each test case pro­vides the agent with the en­tire PDF cor­pus, with all PDFs ren­dered as im­ages and no ma­chine-read­able text avail­able.

OfficeQA Pro and SpreadsheetBench 2. Kimi K3, GLM-5.2, Claude Opus 4.8, and Claude Fable 5 are eval­u­ated with the Claude Code har­ness; GPT 5.5 and GPT 5.6 Sol are eval­u­ated with the Codex har­ness.

MCP Atlas. All mod­els are eval­u­ated on the 500-task pub­lic sub­set with a 100-turn limit, us­ing Gemini 3.1 Pro as the judge.

AutomationBench. All mod­els are eval­u­ated on the 600-task pub­lic sub­set, fol­low­ing the of­fi­cial GitHub setup in all other re­spects.

BrowseComp. We adopt the con­text-com­paction strat­egy used in the Claude model cards, trig­gered at 300K to­kens. When eval­u­ated with a 1M-token con­text win­dow and no con­text man­age­ment, Kimi K3 achieves a score of 90.4. The re­sults of Claude Fable 5, Claude Opus 4.8, GPT 5.6 Sol, and GPT 5.5 are cited from https://​www.an­thropic.com/​news/​claude-fa­ble-5-mythos-5 and https://​ope­nai.com/​in­dex/​gpt-5 – 6/.

GDPval-AA v2 and AA-Briefcase scores are cited from https://​ar­ti­fi­cial­analy­sis.ai/.

Multimodal bench­marks

Except for ZeroBench, which fol­lows the of­fi­cial set­ting and is run five times, all mul­ti­modal scores are av­er­aged over three runs. MMMU-Pro is eval­u­ated fol­low­ing the of­fi­cial pro­to­col, pre­serv­ing the orig­i­nal in­put or­der and prepend­ing im­ages to the text in­put.

PerceptionBench. PerceptionBench is an in-house bench­mark that fo­cuses on atomic vi­sual per­cep­tion ca­pa­bil­i­ties.

Limitations

Sensitivity to think­ing his­tory. K3 was trained in the pre­served think­ing his­tory mode. If the agent har­ness fails to pass back all the his­tor­i­cal think­ing con­tent as re­quired, or if an on­go­ing ses­sion with an­other model is switched over to K3, gen­er­a­tion qual­ity may be­come highly un­sta­ble. We rec­om­mend us­ing a har­ness with ver­i­fied com­pat­i­bil­ity, such as Kimi Code, and avoid­ing switch­ing to K3 in the mid­dle of a ses­sion.

Excessive proac­tive­ness. K3′s train­ing places par­tic­u­lar em­pha­sis on long-hori­zon, chal­leng­ing tasks. As a re­sult, when it en­coun­ters mi­nor is­sues or am­bigu­ous user in­tent dur­ing task ex­e­cu­tion, it may make un­ex­pected de­ci­sions on the user’s be­half. If your ap­pli­ca­tion re­quires the agent to op­er­ate within well-de­fined bound­aries and re­frain from ex­ces­sive im­pro­vi­sa­tion, please im­pose more ex­plicit be­hav­ioral con­straints on K3 in the sys­tem prompt or in AGENTS.md.

Despite be­ing a highly com­pet­i­tive model over­all, K3 nonethe­less ex­hibits a no­tice­able gap in user ex­pe­ri­ence com­pared with Claude Fable 5 and GPT 5.6 Sol.

Ask any­thing, or task an agent…

Explore in­spi­ra­tion

I ha­rass the sea with my tiny boat and am called a pi­rate, you do it with a great fleet and are called a king.

I ha­rass the sea with my tiny boat and am called a pi­rate, you do it with a great fleet and are called a king.

Anthropic is ac­tively cam­paign­ing to end soft­ware en­gi­neer­ing. They need you to be­lieve they can do that. Well, maybe it’s not you that they need to con­vince. Maybe it’s your C-Suite, var­i­ous world lead­ers, or the man­ager of your re­tire­ment fund. They’ve raised $132 bil­lion in in­vest­ment, and are ap­proach­ing an IPO val­ued over $1 tril­lion. Since they can­not show prof­itabil­ity, this de­pends on sell­ing their hy­po­thet­i­cal fu­ture im­pact.

In lit­er­ary terms, Anthropic is an un­re­li­able nar­ra­tor.

One of their key nar­ra­tives is: Coding is go­ing away, then the rest of soft­ware en­gi­neer­ing, and even­tu­ally most other hu­man la­bor. This kind of money be­hind this kind of story has an im­pact, re­gard­less of how true we think the story is.

People will make ar­chi­tec­ture, prod­uct, and staffing de­ci­sions based on these events. Many of those de­ci­sions will be based on fear - fear of lay­offs, rap­ture-esk warn­ings of be­ing “Left Behind”, Doom Trolling, etc…

To make good de­ci­sions we need to think clearly, which is hard right now. Put on your skep­ti­cal hat.

Views are my own. I have no his­tory with Zig. I’ve never spo­ken to Andrew Kelley, but found his re­cent JetBrains in­ter­view a great watch.

My in­ter­est here is in pub­lic lit­er­acy about AI in soft­ware. That’s been my ca­reer fo­cus now for 3 years, along with im­prov­ing the tech­nol­ogy it­self. During half of that time I was Chief Architect of a cod­ing agent startup - both a cus­tomer of Anthropic’s mod­els and com­peti­tor to their agent Claude Code. My cur­rent pro­ject is The Coding Agency.

So where were we?

This week, Anthropic / Bun put out their ex­pla­na­tion of the de­ci­sion to port Bun from Zig to Rust. This ex­pla­na­tion came two months af­ter merg­ing the mi­gra­tion to the main­line. Explaining the di­rec­tion be­fore­hand would have been more tra­di­tional in an in­fra­struc­ture pro­ject like this, but mean­while the de­lay con­ve­niently al­lowed the story to be car­ried by sexy head­lines like The Register’s Anthropic’s Bun Rust rewrite merged at speed of AI. Much in­vest. Very wow.

Zig’s cre­ator Andrew Kelley has now put out a re­sponse with his own thoughts. It’s blunt, to an un­usual de­gree. That has ques­tion­able op­tics. As a gen­eral rule, you would not want to worry that when you switch pro­gram­ming lan­guages you will wake up the next morn­ing to the old lan­guage’s leader un­load­ing on your per­sonal flaws. As Dax hi­lar­i­ously put it:

guys we have a pretty sub­stan­tial open­source zig code­base and i’m ter­ri­fied he’s gonna look at it

guys we have a pretty sub­stan­tial open­source zig code­base and i’m ter­ri­fied he’s gonna look at it

Still, as I read Andrew’s piece I found my­self cheer­ing out loud. I may have briefly jumped around the room. Some called his take a “meltdown”, all I can say is he’s gained a new fan to­day.

Sometimes things need to be called out.

What is model be­hav­ior?

On my best days I’d as­pire to some­thing like Buddhist right speech, a high stan­dard that every­thing we say should meet all five of these cri­te­ria.

Is it true?

Is it help­ful?

Is it timely?

Is it kind?

Is it from kind­ness?

We’re break­ing deco­rum a lit­tle, stray­ing into “true, but un­kind” ter­ri­tory. I’m de­fend­ing some­one’s choice to do that. I don’t do that lightly, and I hope it’s help­ful.

Background

Just to catch you up…

Bun is a TypeScript run­time, like a faster NodeJS.

Zig is a sys­tems pro­gram­ming lan­guage, like a mod­ern C.

Bun was writ­ten in Zig un­til re­cently - one of the largest Zig code­bases.

Bun claims near 100% AI con­tri­bu­tions.

Zig al­lows 0% AI con­tri­bu­tions.

Bun was ac­quired by Anthropic, a lead­ing AI model lab.

Bun’s founder ex­per­i­mented with a mas­sive agen­tic rewrite from Zig to un­safe Rust.

That ex­per­i­ment was merged days later and is now the of­fi­cial ver­sion.

This is sit­u­a­tion is con­tro­ver­sial on a few fronts, though ap­par­ently no one in­volved ac­tu­ally wants Bun to stay in Zig. The drama lives purely in the meta-dis­cus­sion. The mi­gra­tion process it­self is pretty in­ter­est­ing, I would con­sider do­ing some­thing sim­i­lar in the right sit­u­a­tion.

Who to be­lieve

When peo­ple choose be­tween Zig and Rust for their pro­jects, they will nat­u­rally see the Bun sit­u­a­tion as a data-point. That fact that one of the biggest Zig users wound up re­vers­ing the de­ci­sion feels rel­e­vant, re­gard­less of the rea­sons. People will try to un­der­stand what hap­pened, and de­cide which is more true:

Anthropic/Bun story: Bun tried every­thing rea­son­able, and was still over­whelmed by mem­ory bugs be­cause Zig was­n’t up to the task.

Anthropic/Bun story: Bun tried every­thing rea­son­able, and was still over­whelmed by mem­ory bugs be­cause Zig was­n’t up to the task.

Andrew’s story: The Bun code is a mess be­cause of their en­gi­neer­ing de­ci­sions, in­clud­ing overus­ing AI agents to write and re­view every­thing.

Andrew’s story: The Bun code is a mess be­cause of their en­gi­neer­ing de­ci­sions, in­clud­ing overus­ing AI agents to write and re­view every­thing.

I’d lean more to­ward the lat­ter, but I sus­pect the dom­i­nant fac­tor is more bor­ing:

Ray’s story: Faced with a le­git­i­mate chal­lenge of mem­ory bugs, there were sev­eral vi­able op­tions. Management ea­gerly ap­proved the Rust rewrite op­tion be­cause it was a great mar­ket­ing op­por­tu­nity to show­case their new Fable model, Anthropic al­ready uses Rust, and Zig is openly against us­ing Anthropic’s prod­ucts.

Ray’s story: Faced with a le­git­i­mate chal­lenge of mem­ory bugs, there were sev­eral vi­able op­tions. Management ea­gerly ap­proved the Rust rewrite op­tion be­cause it was a great mar­ket­ing op­por­tu­nity to show­case their new Fable model, Anthropic al­ready uses Rust, and Zig is openly against us­ing Anthropic’s prod­ucts.

That makes fine busi­ness sense, it just is­n’t a mar­ket­ing story. The mar­ket­ing needed to fo­cus on how their AI was pow­er­ful enough to do this rewrite (even though it was not pow­er­ful enough to catch a use-af­ter-free).

For bet­ter or worse, this bag­gage is now top-of-mind in the Rust vs Zig ques­tion. The sit­u­a­tion tends to pit Jarred’s judge­ment against Andrew’s in the eye’s of the com­mu­nity. Any face-sav­ing ex­ag­ger­a­tion spo­ken through Anthropic’s mega­phone could un­in­ten­tion­ally af­fect Zig’s rep­u­ta­tion.

I can un­der­stand why rather than leave well enough alone, Andrew would de­cide to… add some con­text.

Is this a smear?

From my per­spec­tive, Anthropic is the party we need to hold ac­count­able here. That’s what this is all about. Bun founder Jarred Sumner is get­ting caught in the cross­fire in a sense. So is Zig.

It would be nice if this could be dis­cussed strictly on the tech­ni­cal points, and we’ll get to them. However, I don’t think Anthropic is mak­ing a tech­ni­cal ar­gu­ment, they are deal­ing in spec­ta­cle.

Anthropic is us­ing Jarred’s cred­i­bil­ity to help sell their nar­ra­tive. In re­spond­ing to that, we’re com­ment­ing on his cred­i­bil­ity. That’s messy. I don’t love it.

Still, if re­port­ing the things that some­one says and does comes off as a smear, then maybe that be­hav­ior was part of the prob­lem too.

The meat grinder

My first im­pres­sion of the Bun pro­ject was the 2022 an­nounce­ment, in­clud­ing this warn­ing to re­cruits.

Oven is go­ing to be a grind, es­pe­cially the first nine months or so. If work-life bal­ance means a lot of time spent not work­ing, it’s prob­a­bly not a good fit.

Oven is go­ing to be a grind, es­pe­cially the first nine months or so. If work-life bal­ance means a lot of time spent not work­ing, it’s prob­a­bly not a good fit.

When I see a state­ment like that from a prospec­tive man­ager, it says a num­ber of things, not the least of which is “this per­son has no idea what they are do­ing”. A lot of rea­son­ably good coders have never seen an ex­am­ple of a good man­ager, and have all kinds of weird ideas about what man­age­ment is.

Running at “crunch time” all the time is bad for health and bad for pro­duc­tiv­ity. That is a ro­bustly es­tab­lished fact about knowl­edge work. For some ref­er­ences, see the Human Factors sec­tion of Hillel’s Empirical Software Engineering.

My ad­vice? Don’t work for peo­ple that brag about 90 hour weeks. Work for peo­ple who will de­fend your abil­ity to sleep at night.

In Andrew’s piece, he sum­ma­rizes what he’s heard from the grapevine of the Bun team’s ex­pe­ri­ence:

Poor com­mu­ni­ca­tion, un­re­al­is­tic ex­pec­ta­tions, low em­pa­thy, no ex­pe­ri­ence. Just a to­tal shit show

Poor com­mu­ni­ca­tion, un­re­al­is­tic ex­pec­ta­tions, low em­pa­thy, no ex­pe­ri­ence. Just a to­tal shit show

I mean… of course it was. The hearsay is es­sen­tially re­peat­ing what was an­nounced pub­licly. Their job list­ing might as well have said, “now seek­ing ap­pli­cants for to­tal shit show”. It’s bad form for us to say this out loud. We’re sup­posed to let the Tech Bros go on about how cut­ting cor­ners is some ge­nius pro­duc­tiv­ity hack. Then the peo­ple that lis­ten to them can even­tu­ally call us in to fix the re­sults. It would be a great arrange­ment if I cared less about out­comes. It’s quite lu­cra­tive.

FWIW, I’ve used Bun a few times and liked it well enough. Cool tech is of­ten pro­duced in spite of bad work en­vi­ron­ments. I’m not the one say­ing that their en­vi­ron­ment re­sulted in a buggy un­main­tain­able mess, Bun is the one say­ing that.

Say some­thing nice

The piece about the mi­gra­tion process is very cool, with de­tails that are reusable. No com­plaints, I think that’s the real con­tri­bu­tion here. I par­tic­u­larly like the hon­esty in ex­plain­ing that this was a port to un­safe Rust, al­low­ing a lit­eral file-by-file mi­gra­tion to min­i­mize risk, paving the way for re­design in fu­ture steps. That’s a sen­si­ble move ex­plained well.

There’s some truth to the idea that lan­guage choice is be­com­ing more re­versible. This method will take it’s place among other types of rewrite au­toma­tion with pros and cons. These tech­niques can be com­bined and fur­ther hard­ened with Formal Methods. Darpa’s TRACTOR (Translating All C to Rust) re­search pro­gram pub­lished a re­port this year which should cover the state of the art.

My fa­vorite book on soft­ware mod­ern­iza­tion pro­jects is Kill It With Fire by Marianne Bellotti. As agents al­low us more moves we can make with old code, we still need good judge­ment and com­mu­ni­ca­tion in de­cid­ing where to go. Let’s talk about that next.

The rewrite ra­tio­nale is fluff

These are the ba­sic in­gre­di­ents of ex­plain­ing a tech­ni­cal de­ci­sion:

What is the mo­ti­va­tion?

What op­tions did you con­sider?

What are the pros and cons?

Here’s a great ex­am­ple by Richard Feldman on his de­ci­sion to move the Roc com­piler from Rust to Zig. I was ini­tially shocked by that move (I’m some­what fa­nat­i­cal about lan­guage safety), but ul­ti­mately his points made sense and this started my cu­rios­ity about Zig.

When the Bun rewrite was merged, I’d hoped to see a sim­i­lar treat­ment. This is what we got in­stead, two months late.

✅ What is the mo­ti­va­tion?

⚠️ What op­tions did you con­sider?

🚫 What are the pros and cons?

For the as­pir­ing tech leads out there: When you skimp on these in­gre­di­ents, es­pe­cially the “pros and cons”, you risk giv­ing the im­pres­sion that you ap­proached the prob­lem with one an­swer al­ready in mind and are giv­ing it a post-hoc jus­ti­fi­ca­tion. Maybe you have rea­sons that you aren’t say­ing.

It feels dis­hon­est.

All pros no cons

Rather than a real trade­off com­par­i­son, we get a “Bun is bet­ter in Rust” sec­tion cov­er­ing only up­sides. A change like this al­ways has trade-offs, an ob­vi­ous one would be build time.

Typically when you use Rust for a large code­base, you are buy­ing safety and pay­ing in slower com­pi­la­tion. There’s no shame in that, it can be a win­ning bar­gain. In that past, this fac­tor was im­por­tant enough to Bun that they forked the Zig com­piler to try and im­prove it. If we’re right that the Rust port in­creased build time for con­trib­u­tors, why not dis­close that? It comes off as more cred­i­ble to own the im­pact and the pri­or­i­ties that make it right move over­all.

They also seem to be padding the list by mix­ing in other im­prove­ments they’ve made af­ter the rewrite that aren’t re­ally re­lated to it.

They did­n’t try a style guide?

Recall that the mo­ti­va­tion was mem­ory bugs. Definitely not Bun’s only source of bugs but a fre­quent one, caus­ing four fix com­mits per week by my count. Painful.

Theoretically, every mem­ory bug rep­re­sents a vi­o­la­tion of some con­ven­tion - an ex­pec­ta­tion of how this kind of ob­ject should be dealt with. Therefore it be­hooves us to es­tab­lish a clear idea of what’s ex­pected in what cir­cum­stance. We should try to use any lan­guage ef­fec­tively for that mat­ter, Rust style guides are a thing too, but man­ual mem­ory man­age­ment adds scope to the ex­pec­ta­tions we need.

How have other peo­ple solved this prob­lem? Another flag­ship Zig code­base is TigerBeetle, a fi­nan­cial trans­ac­tion data­base. It is not plagued by mem­ory bugs, in fact it ap­pears to be one of the most re­li­able data­bases in ex­is­tence. They will gladly tell you that this is due to their TigerStyle ap­proach and some in­no­v­a­tive test­ing strate­gies. Worth a look! The word “style” might un­der­sell it, it’s a whole en­gi­neer­ing phi­los­o­phy with Zig cod­ing guide­lines as one el­e­ment.

Here’s a taste of TigerStyle. Not every ap­pli­ca­tion can copy-and-paste this ex­act strat­egy, but it il­lus­trates the re­la­tion­ship be­tween mem­ory al­lo­ca­tion and other de­sign de­ci­sions.

All mem­ory must be sta­t­i­cally al­lo­cated at startup. No mem­ory may be dy­nam­i­cally al­lo­cated (or freed and re­al­lo­cated) af­ter ini­tial­iza­tion. This avoids un­pre­dictable be­hav­ior that can sig­nif­i­cantly af­fect per­for­mance, and avoids use-af­ter-free. As a sec­ond-or­der ef­fect, it is our ex­pe­ri­ence that this also makes for more ef­fi­cient, sim­pler de­signs that are more per­for­mant and eas­ier to main­tain and rea­son about, com­pared to de­signs that do not con­sider all pos­si­ble mem­ory us­age pat­terns up­front as part of the de­sign.

All mem­ory must be sta­t­i­cally al­lo­cated at startup. No mem­ory may be dy­nam­i­cally al­lo­cated (or freed and re­al­lo­cated) af­ter ini­tial­iza­tion. This avoids un­pre­dictable be­hav­ior that can sig­nif­i­cantly af­fect per­for­mance, and avoids use-af­ter-free. As a sec­ond-or­der ef­fect, it is our ex­pe­ri­ence that this also makes for more ef­fi­cient, sim­pler de­signs that are more per­for­mant and eas­ier to main­tain and rea­son about, com­pared to de­signs that do not con­sider all pos­si­ble mem­ory us­age pat­terns up­front as part of the de­sign.

Clearly, if we’re weigh­ing a rewrite in Rust, we’d first con­sider if we should use the cur­rent lan­guage dif­fer­ently. Hear’s how Bun’s write-up pre­sents that op­tion.

Many pro­jects opt to an­swer these kinds of ques­tions through a style guide. TigerBeetle’s TigerStyle is an ex­am­ple in Zig and Google’s 31,000 word C++ style guide is an­other. The chal­lenge with style guides is en­force­ment. How do you make sure the style guide is fol­lowed? Historically, code re­view was the an­swer with best-ef­fort en­force­ment via lin­ters & sta­tic an­a­lyz­ers.

Many pro­jects opt to an­swer these kinds of ques­tions through a style guide. TigerBeetle’s TigerStyle is an ex­am­ple in Zig and Google’s 31,000 word C++ style guide is an­other. The chal­lenge with style guides is en­force­ment. How do you make sure the style guide is fol­lowed? Historically, code re­view was the an­swer with best-ef­fort en­force­ment via lin­ters & sta­tic an­a­lyz­ers.

I ex­pected the next sen­tence to dis­cuss Bun’s style guide, why it was­n’t work­ing, per­haps how it evolved over time… nope. They seem to just pay lip-ser­vice the pri­mary way the com­mu­nity ad­dresses their prob­lem, shrug their shoul­ders and move on. Did I miss some­thing? Over four years on a pro­ject of this size, it’s sur­pris­ing they did­n’t se­ri­ously at­tempt this if they ex­pe­ri­enced these prob­lems. It’s al­most like the pro­ject was run by some­one who tries to hold all the con­text in their head and never have meet­ings.

What’s more be­wil­der­ing is that they dis­miss style guides with hes­i­ta­tions that are re­futed within their own ar­ti­cle. Consider that clas­sic ob­jec­tion that guides are hard to en­force. Fair, though maybe an odd bar­rier for a team ad­vanced enough to fork the com­piler they use. Here’s the thing, they al­ready claim to have solved the en­force­ment prob­lem be­cause they use agen­tic re­view. PORTING.md is it­self a style guide, scoped to the mi­gra­tion process. They have just con­ducted an agen­tic re­view of their en­tire rewrit­ten code­base against strin­gent guide­lines and de­clared it a suc­cess.

This does­n’t make sense. Let’s as­sume agen­tic re­view works, I think it can un­der the right cir­cum­stances. That would re­quire de­sign and well-thought guide­lines. I think they were sim­ply more ex­cited about putting that men­tal en­ergy into a rewrite than a re-ar­chi­tec­ture, for any num­ber of un­stated rea­sons. It may have been the right choice.

We’re still wor­ried about syn­tax?

There’s one more bit I want to nit­pick, a com­mon cog­ni­tive dis­so­nance in dis­cus­sions about agent-first cod­ing. Bun’s piece briefly dives into to the weeds of what a “style guide op­tion” might look like.

Having a rigid style guide with clear own­er­ship ex­pec­ta­tions ex­plic­itly spelled out in the type sys­tem was a real op­tion for Bun. Since Zig has no op­er­a­tor over­load­ing, we would likely end up with a lot of code look­ing some­thing like this:

Our mis­sion is to build AI that ex­tends hu­man will and judg­ment. We have de­vel­oped a plat­form that lets any­one cus­tomize mod­els, pre­viewed an AI sys­tem built for in­ter­ac­tive col­lab­o­ra­tion, and pub­lished novel re­search. Today we are ad­vanc­ing our mis­sion by re­leas­ing a model we trained from scratch with the full weights avail­able, so that peo­ple can make it their own.

Our model, called Inkling, is a Mixture-of-Experts trans­former with 975B to­tal pa­ra­me­ters, 41B ac­tive. It sup­ports a con­text win­dow of up to 1M to­kens. It was pre­trained on 45 tril­lion to­kens of text, im­ages, au­dio and video. It is the first in a fam­ily of mod­els of dif­fer­ent sizes: along­side it we are shar­ing a pre­view of Inkling-Small, a lighter-weight model with 12B ac­tive pa­ra­me­ters, trained with a sim­i­lar recipe, that achieves strong per­for­mance with even lower cost and la­tency.

Inkling rea­sons na­tively over text, im­ages, and au­dio, and bal­ances cost with per­for­mance through ef­fi­cient and con­trol­lable think­ing ef­fort. We trained it to be a broad, bal­anced foun­da­tion model: strong across many do­mains, flex­i­ble enough to adapt. Inkling is not the strongest over­all model avail­able to­day, open or closed. Instead, a com­bi­na­tion of qual­i­ties makes it a good open-weights base for cus­tomiza­tion: mul­ti­modal ca­pa­bil­i­ties, ef­fi­cient think­ing, and avail­abil­ity on Tinker for fine-tun­ing. Inkling is just the start: our first re­lease in a model fam­ily we will con­tinue to build on.

We want to make cus­tomiza­tion ac­ces­si­ble for more use cases, so Inkling is avail­able for fine-tun­ing on Tinker to­day. Picking the right base model to fine-tune is a qual­i­ta­tive judg­ment that com­bines mea­sur­able bench­marks with the unique feel of a model that comes from play­ing with it. To en­able the lat­ter we’re adding the Inkling Playground in the Tinker con­sole: a de­vel­oper-fac­ing in­ter­face for chat­ting with Inkling.

To show what cus­tomiza­tion means in prac­tice, we asked Inkling to fine-tune it­self. Using Tinker, the model wrote its own fine-tun­ing job, ran it, and eval­u­ated the re­sult:

Build · inkling · tin­ker-prod

Capabilities

Real-world ap­pli­ca­tions re­quire mod­els with a wide range of ca­pa­bil­i­ties that can be com­bined and im­proved with fine-tun­ing. We show­case what Inkling can do and how it mea­sures up on im­por­tant qual­i­ties such as trust­wor­thi­ness and safety.

Generalist model

Inkling is de­signed to be broad. We trained it across agen­tic, rea­son­ing, cod­ing, in­struc­tion-fol­low­ing, fac­tu­al­ity, vi­sion, and au­dio tasks, rather than nar­rowly op­ti­miz­ing for one do­main. That breadth mat­ters for cus­tomiza­tion and real-world use: dif­fer­ent users need mod­els that can adapt to very dif­fer­ent work­flows, not just ex­cel on bench­marks.

Spider chart com­par­ing Inkling, Nemotron 3 Ultra, GLM 5.2, GPT 5.6 Sol, and Claude Fable 5 on ten eval­u­a­tions scored from zero to one hun­dred. Inkling is shown with the heav­ier cobalt line. Evaluations with­out a re­ported model score are plot­ted at zero. Hover an eval­u­a­tion to com­pare every mod­el’s score.

Agentic cod­ing and tool use

A strong base for fine-tun­ing needs to flex­i­bly solve a wide va­ri­ety of tasks with agen­tic tool use. Inkling scores well among open-weights mod­els on most agen­tic bench­marks.

We trained Inkling to run in­side a va­ri­ety of cod­ing and agent har­nesses, and we ran­dom­ized the tool set and schema dur­ing train­ing to re­duce sen­si­tiv­ity to any par­tic­u­lar one. Inkling’s con­trol­lable think­ing ef­fort, de­scribed in the next sec­tion, can be set from within the har­ness.

Below are a few demos show­cas­ing Inkling’s agen­tic cod­ing and tool use and the ar­ti­facts it cre­ates.

One-shot web app with em­bed­ded browser use

Inkling built a func­tional web app in a sin­gle shot, then pow­ers an em­bed­ded AI as­sis­tant that can op­er­ate the web app in­ter­face through nat­ural lan­guage in­struc­tions.

Design Arena

Inkling was eval­u­ated on Design Arena’s Agentic Web Dev leader­board, where blinded hu­man eval­u­a­tors com­pare gen­er­ated web apps head to head. It ranks among the strongest open-weights mod­els.

Claude Sonnet 5

1333

Claude Fable 5

1329

Claude Opus 4.8

1285

GLM 5.2

1275

Grok 4.5

1271

GPT-5.6 Sol

1260

Inkling

1257

Claude Opus 4.6

1257

Gemini 3.5 Flash

1254

Kimi K2.6

1249

Claude Sonnet 4.6

1237

Kimi K2.7 Code

1234

GLM 5.1

1233

Claude Opus 4.5

1212

Grok 4.20 Reasoning

1203

Gemini 3.1 Pro Preview

1187

Grok 4.3

1185

Kimi K2.5 (Thinking)

1185

Cohesively styled ar­ti­facts

Inkling cre­ates multi-page ar­ti­facts with pre­cise in­struc­tion fol­low­ing, ac­cu­rate in­for­ma­tion, and co­he­sive styling and de­sign through­out.

Multiplayer game cre­ated through long re­fine­ment loop

Inkling re­fined an on­line snake game through 40 it­er­a­tions of feed­back from GPT Codex serv­ing as a re­viewer. The abil­ity to sus­tain a long process of re­fine­ment and im­prove from feed­back is cru­cial to cre­at­ing the best col­lab­o­ra­tive work.

Controllable think­ing ef­fort

Test-time scal­ing and prob­lem-solv­ing are the core ca­pa­bil­ity of every model, but that ca­pac­ity is hard to cap­ture with a sin­gle num­ber. Developers fine-tun­ing mod­els for a spe­cial­ized task care as much about ef­fi­ciency as about the max-ef­fort per­for­mance on a pub­lic bench­mark. Cost and la­tency are of­ten bind­ing con­straints in real-world ap­pli­ca­tions, and low la­tency in par­tic­u­lar is cru­cial for en­abling col­lab­o­ra­tion and im­prove­ment through it­er­a­tion.

Inkling (effort sweep) GLM-5.2 Kimi K2.6 Nemotron 3 Ultra Kimi K2.5 GPT-OSS (high)

Inkling sup­ports con­trol­lable think­ing ef­fort, al­low­ing you to bal­ance per­for­mance with to­ken ef­fi­ciency. The chart above shows the ef­fort/​per­for­mance curve of Inkling as well as other open-weights mod­els on a range of bench­marks: Terminal Bench 2.1 for agen­tic cod­ing, HLE for ad­vanced rea­son­ing, and IFBench for in­struc­tion fol­low­ing. Inkling spends one third as many to­kens to achieve the same per­for­mance as Nemotron 3 Ultra on Terminal Bench. Cost and la­tency mat­ter for a model that you run mil­lions of times and as part of longer work­flows; look­ing at the full cost curve al­lows de­vel­op­ers to choose the best model for each use case.

Multimodality

A ma­jor goal of Inkling’s de­sign is to serve as the back­ground rea­son­ing model in the in­ter­ac­tion mod­els sys­tem we re­cently in­tro­duced. Interaction mod­els en­able the user to col­lab­o­rate nat­u­rally, us­ing voice and vi­sion in real time. This re­quires a model na­tively trained for broad mul­ti­modal ca­pa­bil­i­ties.

Audio and vi­sion bench­marks against spe­cial­ist omni mod­els (open- and closed-weight), re­ported at ef­fort=0.99.

The mul­ti­modal com­po­nents were trained from scratch on gen­eral-do­main data. We opted for an en­coder-free ar­chi­tec­ture for au­dio and vi­sion in­puts, con­sis­tent with the in­ter­ac­tion model de­sign. Audio sig­nals are in­put as dMel spec­tro­grams­d­Mel: Speech Tokenization made Simple (Richard He Bai et al, 2024), while im­ages are en­coded as patches of 40x40 pix­els us­ing a four-layer hMLPThree things every­one should know about Vision Transformers (Hugo Touvron et al, 2022). Both are trans­formed via a light-weight em­bed­ding layer and processed jointly with text to­kens.

Inkling tran­scribes speech, fol­lows spo­ken in­struc­tions, an­swers ques­tions about record­ings, and rea­sons over longer-form au­dio. These ca­pa­bil­i­ties place it among the strongest open-weights au­dio mod­els on VoiceBench, MMAU, and AudioMC. For vi­sion, Inkling ac­cepts im­ages as in­put and can de­scribe vi­sual con­tent, an­swer ques­tions, and per­form in-depth rea­son­ing based on the pro­vided vi­sual in­for­ma­tion. It demon­strates strong per­for­mance on charts, di­a­grams, and math­e­mat­i­cal vi­sual rea­son­ing tasks. During in­fer­ence, Inkling can also lever­age a Python tool to sup­port im­age un­der­stand­ing through op­er­a­tions such as zoom­ing and crop­ping, while seam­lessly in­te­grat­ing vi­sual rea­son­ing with code-based rea­son­ing.

As our first re­lease, Inkling es­tab­lishes a ro­bust mul­ti­modal foun­da­tion for fu­ture work. We ex­pect its mul­ti­modal ca­pa­bil­i­ties to con­tinue im­prov­ing as we ex­pand the model and train­ing pipeline in sub­se­quent it­er­a­tions.

Epistemics

We trained Inkling for cal­i­bra­tion, in­struc­tion fol­low­ing, and re­sis­tance to cen­sor­ship, which we re­fer to col­lec­tively as the mod­el’s epis­temics.

Getting the facts right re­quires more than mem­o­riz­ing a large cor­pus of knowl­edge. A use­ful model must be well-cal­i­brated, ex­press­ing the right amount of con­fi­dence in its an­swers — in­clud­ing on ques­tions which aren’t yet set­tled. The lat­ter is a cru­cial ca­pa­bil­ity for pre­dic­tion and fore­cast­ing, an im­por­tant use case where fine-tuned mod­els have shown rapid im­prove­ment in re­cent months, out­per­form­ing fron­tier LLMs.

Results were ob­tained dur­ing test­ing be­tween June 30 and July 13, 2026 on a dif­fer­ent check­point of Inkling than the one re­leased.

Forecasting re­quires in­te­grat­ing mul­ti­ple sources of in­for­ma­tion into a cal­i­brated prob­a­bil­ity, a core skill for a model users can trust. A model that’s con­fi­dent in every an­swer it gives, in­clud­ing when it’s miss­ing info and con­fab­u­lates, forces the user to dou­ble-check every­thing. A model that gives the ap­pro­pri­ate mea­sure of con­fi­dence is use­ful across more real-world do­mains where in­for­ma­tion is of­ten con­flict­ing, un­re­li­able, or hard to find. We trained for cal­i­bra­tion with RL against proper scor­ing rules on a large cor­pus of re­solved real-world ques­tions.

The sec­ond com­po­nent of a trust­wor­thy model is in­struc­tion fol­low­ing, in­clud­ing on hard-to-ver­ify, com­plex queries. We did RL with two au­to­mated graders: a rubric grader and claims grader. The first grader scores each re­sponse against a check­list of what a good an­swer should con­tain. Rubrics can pe­nal­ize er­rors in prin­ci­ple, but in prac­tice they em­pha­size re­call and can be hacked by mod­els spray­ing plau­si­bly rel­e­vant facts hop­ing to match rubric items. The claims grader ver­i­fies each fac­tual claim in the re­sponse, pe­nal­iz­ing claims that don’t check out. It per­forms agen­tic web search for claim ver­i­fi­ca­tion, not re­ly­ing solely on its own knowl­edge. Together, the two graders im­prove help­ful­ness and re­duce hal­lu­ci­na­tion at the same time, rather than trad­ing one for the other.

These re­wards don’t di­rectly tar­get cal­i­brated un­cer­tainty in long-form re­sponses, so we added tar­geted datasets that do. The largest is short-form fac­tual QA with ab­sten­tion-aware re­wards: an­swer­ing only pays off when the model is likely to be right, so the op­ti­mal pol­icy is to an­swer when con­fi­dent and oth­er­wise say “I don’t know” or give a hedged best guess. Some prompts en­cour­age or for­bid hedg­ing, teach­ing the model to fol­low the user’s pref­er­ence for a forced guess ver­sus a cal­i­brated non-an­swer.

Finally, we trained Inkling to an­swer di­rectly on top­ics that may be sub­ject to cen­sor­ship. Cognition eval­u­ated the model on their Propaganda and Censorship EvalThe Cognition Team, “Measuring the Trustworthiness of Open-Source-Derived Models,” 2026., and it ex­hib­ited strong pat­terns of cen­sor­ship non-com­pli­ance.

Safety

We trained Inkling to an in­ter­nal spec of safe model be­hav­ior across all modal­i­ties. We then com­mis­sioned ex­ter­nal safety testers to ver­ify the re­sults.

We eval­u­ated Inkling’s safety in sev­eral ar­eas. For dan­ger­ous ca­pa­bil­i­ties — CBRN, cy­ber, and loss of con­trol — we ran in­ter­nal eval­u­a­tions and en­listed ex­ter­nal testers. We at­tended to hu­man-AI threat vec­tors, in­clud­ing syco­phancy, vul­ner­a­ble users, and harm­ful ma­nip­u­la­tion, us­ing in­ter­nal eval­u­a­tions and ex­ter­nal testers.

Inkling shows the strongest built-in safe­guards of any open-weights model we com­pared on FORTRESS, a bench­mark that tests re­fusal of re­quests re­lated to weapons and vi­o­lence along­side be­nign look-alike queries. Inkling re­fused more harm­ful re­quests with­out over-re­fus­ing be­nign analogs. Inkling scores above 98% on StrongREJECT — a re­fusal test of un­am­bigu­ous harm­ful re­quests — in line with other open and closed-weights mod­els.

Safety is cru­cial for open-weights mod­els. We’re con­tin­u­ing to study safety be­hav­ior and ca­pa­bil­ity up­lift in cus­tomiz­able mod­els, in­clud­ing how safety be­hav­ior is im­pacted by fine-tun­ing on Tinker.

Benchmarking Inkling

We bench­mark Inkling on a broad range of ca­pa­bil­i­ties. All evals are run at ef­fort 0.99 and tem­per­a­ture 1.0. All cod­ing evals run with 256K max-to­ken tra­jec­tory limit.

To im­prove con­sis­tency, we rely on ex­ter­nally re­ported eval­u­a­tions for both in­ter­nal and ex­ter­nal mod­els when ap­plic­a­ble. Specifically, we use the score re­ported by Artificial Analysis for the fol­low­ing evals: Humanity’s Last Exam, GPQA Diamond, GDPVal, Tau 3 Banking, AA Omniscience, MMMU Pro.

*SWEBench Verified: Inkling num­bers are re­ported us­ing a bash-only har­ness. We use self-re­ported num­bers for ex­ter­nal mod­els.*Ter­mi­nal Bench 2.1: Inkling num­bers are re­ported us­ing an in­ter­nal cod­ing har­ness. A small num­ber of so­lu­tions were found to be con­t­a­m­i­nated from web search and were as­signed a score of 0. We use self-re­ported num­bers for ex­ter­nal mod­els where avail­able. Otherwise, we re­port per­for­mance us­ing our in­ter­nal har­ness.†Au­dio MC: Other mod­els were eval­u­ated in­ter­nally since they are not on the of­fi­cial leader­board.†VoiceBench: VoiceBench uses rule-based, hard-coded string match­ing for grad­ing, mak­ing the eval­u­a­tion sen­si­tive to out­put-for­mat­ting dif­fer­ences. We there­fore added a sys­tem mes­sage in­struct­ing mod­els to fol­low the ex­pected an­swer for­mat.†CharXiv RQ with tools: We bench­marked Claude Fable 5 and GPT 5.6 Sol (max/xhigh) us­ing our in­ter­nal Python har­ness.

The mak­ing of Inkling

Architecture

Inkling is a Mixture-of-Experts Transformer with a hand­ful of de­par­tures from the com­mon recipe, each cho­sen for ef­fi­ciency and long-con­text per­for­mance.

The MoE de­sign largely fol­lows DeepSeek-V3. Each MoE layer con­tains 256 routed ex­perts and 2 shared ex­perts, with 6 routed ex­perts ac­tive per to­ken. Inkling uses a sig­moid-based router with an aux­il­iary-loss-free load-bal­anc­ing bias. The scores of the se­lected routed ex­perts and the shared ex­perts are nor­mal­ized jointly and used to weight their com­bined out­puts.

For at­ten­tion, we in­ter­leave slid­ing-win­dow and global lay­ers at a 5:1 ra­tio with 8 KV heads. We find that en­cod­ing po­si­tion with a rel­a­tive po­si­tional em­bed­ding­Self-At­ten­tion with Relative Position Representations (Peter Shaw et al, 2018)Music Transformer (Cheng-Zhi Anna Huang et al, 2018) per­forms bet­ter and ex­trap­o­lates bet­ter to longer se­quences than the more widely adopted Rotary Positional Embedding (RoPE). We also ap­ply short con­vo­lu­tions at two points — af­ter the key and value pro­jec­tions in each at­ten­tion layer, and on the at­ten­tion and MLP resid­ual branch out­puts be­fore they re­join the main resid­ual stream.

Training

Inkling was pre­trained on 45 tril­lion to­kens from a va­ri­ety of con­tent types, in­clud­ing text, im­ages, au­dio and video. We trained Inkling with a hy­brid op­ti­miza­tion strat­egy — Muon for large ma­trix weights, Adam for other pa­ra­me­ters — and hy­per­pa­ra­me­ter sched­ules in­spired by our pre­vi­ous re­search on mod­u­lar man­i­folds. We cou­pled the weight de­cay strength to the square of the learn­ing rate, which we found kept the over­all size of the model weights sta­ble across train­ing hori­zon­sSee also Kosson et al. (2023) and Defazio (2025)..

We post-trained Inkling on a broad dis­tri­b­u­tion of math, agen­tic code & tool use, au­dio, im­age, chat, and safety do­mains. To boot­strap post-train­ing, we ran an ini­tial SFT on syn­thetic data gen­er­ated by open-weights mod­els in­clud­ing Kimi K2.5. The boot­strap ac­counts for a small frac­tion of com­pute, with the ma­jor­ity be­ing em­ployed for large-scale RL on syn­thetic and hu­man-cre­ated en­vi­ron­ments.

Inkling was our first ma­jor train­ing ef­fort and was trained on NVIDIA GB300 NVL72 sys­tems. Future mod­els will fur­ther push the scale of com­pute across pre-train­ing, post-train­ing and RL.

RL at scale

We re­lied on large-scale asyn­chro­nous RL to shape model be­hav­ior and im­prove its rea­son­ing and over­all per­for­mance. The chart be­low shows the mod­el’s score on a held-out ag­gre­gate of rea­son­ing evals such as AIME, HLE, GPQA, and oth­ers. We scaled RL to over 30M roll­outs, with sta­ble train­ing sus­tained over two long con­tin­u­ous runs. Reasoning per­for­mance im­proved log-lin­early through­out the en­tire process, re­sult­ing in a sig­nif­i­cant in­crease over­all.

We spec­i­fied the mod­el’s ef­fort level on dif­fer­ent sam­ples by chang­ing the sys­tem mes­sage and ad­just­ing the per-to­ken cost. This caused the model to use a dif­fer­ent amount of to­kens in dif­fer­ent roll­outs and learn the abil­ity to con­trol think­ing ef­fort.

We also ob­served an emer­gent shift in the rea­son­ing style over the course of RL train­ing. The chain of thought be­came more con­cise over time, drop­ping gram­mat­i­cal over­head while re­main­ing com­pre­hen­si­ble and leav­ing the fi­nal re­sponse un­af­fected. This was­n’t tar­geted by the re­ward — ef­fi­ciency alone drove the com­pres­sion. A sim­i­lar ef­fect was also re­cently noted by the Cognition team in the process of train­ing SWE-1.7The Cognition Team, “SWE-1.7: Frontier Intelligence at a Fraction of the Cost.”. Below is an ex­am­ple of how Inkling’s chain of thought on the same math prob­lem evolved with RL:

Early in RL ver­bose, gram­mat­i­cal

Please en­able cook­ies.

Error 1005

What hap­pened?

The owner of this web­site (videocardz.com) has banned the au­tonomous sys­tem num­ber (ASN) your IP ad­dress is in (14061) from ac­cess­ing this web­site.

Please see https://​de­vel­op­ers.cloud­flare.com/​sup­port/​trou­bleshoot­ing/​http-sta­tus-codes/​cloud­flare-1xxx-er­rors/​er­ror-1005/ for more de­tails.

Was this page help­ful?

Thank you for your feed­back!

Cloudflare Ray ID: a1d50­ca25c9b6b0e •

Your IP:

167.99.127.20 •

Performance & se­cu­rity by Cloudflare

Jul 13, 2026

After I men­tioned a Jurassic Park anec­dote the other day, I watched the movie again. I must have seen it at least ten times now. This time, I re­searched every com­puter/​soft­ware I spot­ted.

EDIT: Just when I was putting the fi­nal touches on this ar­ti­cle, I read the sad news that Sam Neill, who played pa­le­on­tol­o­gist Alan Grant in JP, has passed away to­day. R.I.P Sam.

Surprisingly, the first com­puter vis­i­ble is not on the is­land Isla Nublar but in Alan Grant and Ellie Sattler’s mo­bile trailer. It is an Apple Powerbook 100, vis­i­ble in the im­age be­low on the left side.

It had a Motorola 68000 proces­sor at 16 MHz, 2 – 8 megabytes (MB) of RAM, a 9-inch (23 cm) mono­chrome back­lit liq­uid-crys­tal dis­play (LCD) with 640 × 400 pixel res­o­lu­tion, and the System 7.0.1 op­er­at­ing sys­tem. Wikipedia

This ma­chine’s specs re­minds me of how aw­ful ’90s lap­top screens, based on a pas­sive ma­trix, were. Definitely some­thing I don’t miss from that era.

All com­put­ers and soft­ware are lo­cated in the Control Room on the desks of two en­gi­neers, Dennis Nedry and Ray Arnold.

Dennis Nedry’s desk is an in­de­scrib­able mess with three ma­chines (two macs, one SGI), three mon­i­tors, one PDA, and stor­age de­vices.

Ray Arnold’s desk is much ti­dier. It fea­tures a CCTV screen, stor­age de­vices, two com­put­ers (a Mac and a SGI), and two mon­i­tors.

In the back of the Control Room, we can make out a gi­ant screen and a su­per­com­puter with tall pan­els and blink­ing red lights.

The book The Making Of Jurassic Park has in­ter­est­ing de­tails about how they de­signed the Control Room.

Everything in the set was real. We could­n’t fake any of it, be­cause au­di­ences are so so­phis­ti­cated now in their knowl­edge of com­put­ers. All told, $875,000 worth of com­puter hard­ware loaned by Silicon Graphics, $350,000 worth from Apple and some $500,000 in ad­di­tional hard­ware and soft­ware went into equip­ping both the set and off-stage con­trol room. Cory Faucher (Special Effects Coordinator)

This means, ad­justed for in­fla­tion, Apple and SGI loaned roughly $4,000,000 of 2026 dol­lars for the pro­duc­tion of Jurassic Park.

Ray Arnold’s work­sta­tion is a SGI R4000 Indigo. It is barely vis­i­ble in two shots. Blink and you will miss it at 54:48.

We get a some­what bet­ter view of it to­wards the end of the movie thanks to a Velociraptor that never skips leg-day.

For the needs of the movie, that SGIs came in handy to run real-time 3D an­i­ma­tion of the Hurricane. Or did they?

A dy­namic and in­ter­ac­tive method was em­ployed to cre­ate the graph­ics, both on the big screen and on the com­puter mon­i­tors at each in­di­vid­ual sta­tion. A makeshift room was built ad­ja­cent to the set, then equipped with a bat­tery of Silicon Graphics and Apple Macintosh com­puter sys­tems. Stored on com­puter disks were an­i­ma­tions gen­er­ated over a pe­riod of six months by a four-man com­puter graph­ics team headed by Michael Backes.

Responding to cues re­ceived via ra­dio from the set, Backes and his team were able to feed their graph­ics di­rectly to the ap­pro­pri­ate mon­i­tors on stage, mak­ing it seem as though the ac­tors in­volved were ac­tu­ally call­ing up the im­agery. The Making Of Jurassic Park

A dy­namic and in­ter­ac­tive method was em­ployed to cre­ate the graph­ics, both on the big screen and on the com­puter mon­i­tors at each in­di­vid­ual sta­tion. A makeshift room was built ad­ja­cent to the set, then equipped with a bat­tery of Silicon Graphics and Apple Macintosh com­puter sys­tems. Stored on com­puter disks were an­i­ma­tions gen­er­ated over a pe­riod of six months by a four-man com­puter graph­ics team headed by Michael Backes.

Responding to cues re­ceived via ra­dio from the set, Backes and his team were able to feed their graph­ics di­rectly to the ap­pro­pri­ate mon­i­tors on stage, mak­ing it seem as though the ac­tors in­volved were ac­tu­ally call­ing up the im­agery.

Gregory Gosson emailed me to elab­o­rate on the an­i­ma­tion show­ing on the Indigo.

The soft­ware run­ning on the SGI Indigo, show­ing the an­i­mated hur­ri­cane, was called Earthwatch, de­vel­oped by Paul Douglas.

The soft­ware was cre­ated so tele­vi­sion me­te­o­rol­o­gists could cre­ate 3D fly-bys/​fly-throughs of weather. The in­ter­face you see in the movie is the ex­act same in­ter­face the me­te­o­rol­o­gists would use when cre­at­ing the an­i­ma­tions.

I worked with a lo­cal ca­ble news sta­tion for over two decades. We used Earthwatch in the 1990s for our on-air weather graph­ics. The soft­ware al­lowed you to not only cre­ate the cool 3D graph­ics but also the 2D fore­cast pages, like the five-day and ten-day fore­casts, and then to put them into a se­quence that a hand-held re­mote switch would trig­ger. Basically, think of it as a PowerPoint slide deck. It was fan­tas­tic-look­ing stuff for the day, but the ren­der times were very slow. The me­te­o­rol­o­gists would start the ren­der se­quence and then go to lunch. It could play the re­sult­ing an­i­ma­tions in real-time, but could not ren­der in real-time.

Gregory Gosson Former Broadcast Engineer for RNews/Spectrum News in Rochester NY

The soft­ware run­ning on the SGI Indigo, show­ing the an­i­mated hur­ri­cane, was called Earthwatch, de­vel­oped by Paul Douglas.

The soft­ware was cre­ated so tele­vi­sion me­te­o­rol­o­gists could cre­ate 3D fly-bys/​fly-throughs of weather. The in­ter­face you see in the movie is the ex­act same in­ter­face the me­te­o­rol­o­gists would use when cre­at­ing the an­i­ma­tions.

I worked with a lo­cal ca­ble news sta­tion for over two decades. We used Earthwatch in the 1990s for our on-air weather graph­ics. The soft­ware al­lowed you to not only cre­ate the cool 3D graph­ics but also the 2D fore­cast pages, like the five-day and ten-day fore­casts, and then to put them into a se­quence that a hand-held re­mote switch would trig­ger. Basically, think of it as a PowerPoint slide deck. It was fan­tas­tic-look­ing stuff for the day, but the ren­der times were very slow. The me­te­o­rol­o­gists would start the ren­der se­quence and then go to lunch. It could play the re­sult­ing an­i­ma­tions in real-time, but could not ren­der in real-time.

Dennis Nedry’s pow­er­house work­sta­tion is an SGI IRIS Crimson. It is such a beast that it won’t fit on his desk. It is on the floor on the right of his desk (red box).

Most of the time it is used to dis­play a 3D chess game (monitor the right end of Dennis desk).

The SGI Crimson is rarely vis­i­ble on screen. It is briefly vis­i­ble af­ter Dennis’s “white rab­bit” lock­down brings Samuel Jackson into a de­pres­sion.

The SGI Crimson was a very pow­er­ful work­sta­tion re­leased in 1992. Its main ap­peal was its panel of real-time 3D graph­ics cards. The CPU was also very pow­er­ful with hard­ware Floating-Point Unit, a lux­ury for 3D graph­ics.

One MIPS 100 MHz R4000 or 150 MHz R4400 proces­sor Choice of seven high-per­for­mance 3D graph­ics sub­sys­tems (Entry, XS, XS24, Elan, Extreme, Reality Engine, VGXT) Up to 256 MB mem­ory and in­ter­nal disk ca­pac­ity of up to 7.2 GB, ex­pand­able to more than 72 GB us­ing ad­di­tional en­clo­sures I/O sub­sys­tem in­cludes four VMEbus ex­pan­sion slots, Ethernet and two SCSI chan­nels with disk strip­ing sup­port

Wikipedia

One MIPS 100 MHz R4000 or 150 MHz R4400 proces­sor

Choice of seven high-per­for­mance 3D graph­ics sub­sys­tems (Entry, XS, XS24, Elan, Extreme, Reality Engine, VGXT)

Up to 256 MB mem­ory and in­ter­nal disk ca­pac­ity of up to 7.2 GB, ex­pand­able to more than 72 GB us­ing ad­di­tional en­clo­sures

I/O sub­sys­tem in­cludes four VMEbus ex­pan­sion slots, Ethernet and two SCSI chan­nels with disk strip­ing sup­port

Both Dennis and Ray use PLI Mini Arrays for their backup. Dennis has an im­pres­sive stack of five on the left-end of his desk.

There is a con­ti­nu­ity er­ror in the movie. See how the stack of PLI is fac­ing left in this early shot.

Later in the movie, af­ter Ray takes over Dennis’s desk, we can see the PLIs have mag­i­cally ro­tated to face the de­vel­oper.

On Ray’s desk we also find a smaller stack of two PLIs.

There is a close-up shot when John Hammond fol­lows the jeeps’ progress on the CCTV.

Despite the at­ten­tion to de­tail, it seems the PLIs were not con­nected since the LEDs are all blank. In Macs Place of Spring 1993 we can find an ad on page 38 giv­ing more de­tails about the ca­pac­ity.

Since John Hammond “spared no ex­pense”, it is fair to say he picked 1GiB ver­sion at $3,598 a piece. That would give them 7 GiB of stor­age for a 2026 equiv­a­lent of $33,223.70. In 2026, 7 GiB of HDD would cost $0.49.

Seven GiB was a MASSIVE amount in 1993 when a high-end PC would come with 120 MiB HDD.

The Motorola Envoy is a per­sonal dig­i­tal as­sis­tant used by Dennis. It is vis­i­ble next to his right el­bow in the im­age be­low.

It is an ex­tremely im­pres­sive de­vice for the early ’90s. It is a fold­able that fea­tures an an­tenna when de­ployed (video).

The hard­ware of the Motorola Envoy in­cluded a Motorola Dragon I/68349 mi­cro­proces­sor, 4 MB of read only mem­ory (ROM), 1 MB of ran­dom ac­cess mem­ory (RAM), and an LCD. Of par­tic­u­lar in­ter­est were the wire­less com­mu­ni­ca­tions ca­pa­bil­i­ties of the Envoy. Its built-in com­mu­ni­ca­tion com­po­nents in­cluded a ra­dio mo­dem ca­pa­ble of 4,800 bits per sec­ond com­mu­ni­ca­tion, a fax and data mo­dem, and an in­frared trans­ceiver ca­pa­ble of 38.4 kbit/​s of data trans­fer. Wikipedia

The hard­ware of the Motorola Envoy in­cluded a Motorola Dragon I/68349 mi­cro­proces­sor, 4 MB of read only mem­ory (ROM), 1 MB of ran­dom ac­cess mem­ory (RAM), and an LCD. Of par­tic­u­lar in­ter­est were the wire­less com­mu­ni­ca­tions ca­pa­bil­i­ties of the Envoy. Its built-in com­mu­ni­ca­tion com­po­nents in­cluded a ra­dio mo­dem ca­pa­ble of 4,800 bits per sec­ond com­mu­ni­ca­tion, a fax and data mo­dem, and an in­frared trans­ceiver ca­pa­ble of 38.4 kbit/​s of data trans­fer.

Dennis must have used it since we see it moved and par­tially un­folded later in the movie.

It is un­clear how Jurassic Park crew got their hands on a Motorola Envoy. The movie was shot from August to November 1992. Motorola only fin­ished the PDA in mid-1994 but de­layed re­leas­ing it to February 1995[1].

EDIT : Hackernews user kalle­boo solved the mys­tery!

The head of frogde­sign (Hartmut Esslinger) ended up run­ning into Spielberg on a plane and showed it to him. The one in the movie is an orig­i­nal mockup

(source and

dis­cus­sion). kalle­boo

The su­per­com­puter of the con­trol room looks a lot like five Thinking Machines CM-5 with there char­ac­ter­is­tic front panel with thou­sands of red blink­ing LEDs. With a pric­etag of “only” $46,000 per ma­chine, it is very pos­si­ble these were au­then­tic.

The CM-5, “Connection Machine”, was re­leased in 1991[2]. In 1993 it was still con­sid­ered the most pow­er­ful com­puter in the world[3]. Each ma­chine was called a “node”, fea­tur­ing a Sparc CPU, four vec­tor units, and 32 MiB RAM. As many nodes as needed could be con­nected to­gether to form a mesh. The National Center for Atmospheric Research (NCAR) build a 32-node su­per­com­puter with CM-5[4].

Does the red LED pat­tern in the front panel mean any­thing? Absolutely not, they were ran­domly gen­er­ated[5].

If you lis­ten care­fully you can ac­tu­ally hear Dennis Nedry talk about the CM-5, “Connection Machine”.

I am to­tally un­ap­pre­ci­ated in my time. You can run this whole park from this room with min­i­mal staff for up to 3 days. You think that kind of au­toma­tion is easy? Or cheap? You know any­body who can net­work 8 con­nec­tion ma­chines and de­bug 2 mil­lion lines of code for what I bid for this job? Because if he can I’d like to see him try. Dennis Nedry

User pivo (from hack­ernews) ex­plained why the movie fea­tures CM-5 while the novel has Cray su­per­com­puter.

My wife worked for Thinking Machines back then. I re­mem­ber that they’d asked Cray to loan them a su­per­com­puter for the film be­cause that’s the com­puter used in the book. Cray brushed them off, so they turned to Thinking Machines who were happy to do it.

To thank them, the pro­duc­ers rented a the­ater in Cambridge, MA [Kendall Sq. cin­ema] to screen the film just for Thinking Machines and I was also able to at­tend. By far the biggest re­ac­tions from the au­di­ence that night were when the CM-5 was shown for the first time and then when the young ac­tress says, “It’s a Unix sys­tem. I know this” pivo (from hack­ernews)

My wife worked for Thinking Machines back then. I re­mem­ber that they’d asked Cray to loan them a su­per­com­puter for the film be­cause that’s the com­puter used in the book. Cray brushed them off, so they turned to Thinking Machines who were happy to do it.

To thank them, the pro­duc­ers rented a the­ater in Cambridge, MA [Kendall Sq. cin­ema] to screen the film just for Thinking Machines and I was also able to at­tend. By far the biggest re­ac­tions from the au­di­ence that night were when the CM-5 was shown for the first time and then when the young ac­tress says, “It’s a Unix sys­tem. I know this”

I used to work at Oregon State University in their oceanog­ra­phy de­part­ment where they had CM-5. I was friends with the tech­ni­cian who did the in­stalls in the ’90s. He had to leave part way to work on JP. He told me they only in­stalled the front pan­els with the RED leds (not real CM-5). Side story: When they were de­com­mis­sioned, I res­cued the LED pan­els and re­built them. William Dillon

One of the very best mon­i­tors money could buy in 1993 was the SuperMatch 20-T. The twenty means 20″ and T meant Trinitron. The SuperMatch was fea­tured on the cover of MacUser in Feb 92. In MacUser of Oct 94, page 180 (out of 252!!), we can see it cost $2,589 ($6,000 in 2026).

20″ mon­i­tors were con­sid­ered ab­solutely mas­sive in 1993 and only seen in pro­fes­sional work­spaces. A typ­i­cal PC would come with a 15″ CRT. 21″ is al­most the max­i­mum CRTs reached, their depth and weight made them very hard to move. They were re­placed by LCD around 2005.

A lot of at­ten­tion was paid to avoid show­ing CRT re­fresh ar­ti­fact in the movie. SuperMatch had en­gi­neer on-site and pro­duc­tion had peo­ple ded­i­cated to sync­ing CRT fram­er­ate with film rate.

My un­cle (John Monsour) worked on this movie as the “24 Frame Computer Sync Engineer”. Because film cam­eras and CRT mon­i­tors have dif­fer­ent frame rates, you needed to use spe­cial­ized elec­tron­ics to syn­chro­nize them with the cam­era frame rate oth­er­wise you would have band­ing and weird mov­ing ar­ti­facts on all the screens. It’s crazy to imag­ine need­ing to do this for all the screens vis­i­ble in these shots. am­c­col­lum

Sure enough, if we check out Jurassic Park cred­its, we can see 24 Frame Computer Sync: John Monsour.

The mon­i­tor fea­tures a par­tic­u­lar “chin”. The ab­solutely gor­geous SGI Hardware Developer Handbook, on page 4 – 59, re­veals this is a 19″ Mitsubishi HL7965 Monitor which SGI re­branded. It likely cost as much as the SuperMatch 20-T.

On Ray Arnold’s desk, we can no­tice a weird key­board with a con­nec­tor on the side. This is a SGI Granite Keyboard (Indigo Style)[6]. It is a pretty cool key­board with two 6 Pin Mini-DIN con­nec­tors[7] on each side. The key­board can be con­nected to the work­sta­tion from ei­ther side and the mouse is to be daisy-chained into the other port.

Ray is seen us­ing the same key­board later. If you look closely at the screen, you’ll see the com­mand sta­tus net­work was called. It is­sued four (successful) ping to four dis­tinct IP ad­dresses.

Dennis Nedry uses two Macintosh Quadra 700. Apple must have been very happy with the prod­uct place­ment. Although they usu­ally re­quire their com­put­ers not to be used for ne­far­i­ous ac­tiv­ity which is not the case here.

Released in 1991, The Quadra 700 ran on Motorola 68040 @ 25 MHz with 4 MB RAM, ex­pand­able to 68 MB. HDD sizes avail­able were 80 and 160 MB. Ray also uses a Macintosh Quadra 700 but he has only one on his desk.

Dennis ne­go­ti­ates with his co-con­spir­a­tor lo­cated in the har­bor to give him time to make it there. It hap­pens via a VC on the Mac. Why not on a SGI? Because the whole thing was faked via Quicktime Video player run­ning on System 7.

The cur­sor on the progress bar is clearly vis­i­ble. This is 1-minute clip. Even the mouse cur­sor is still on the “play” but­ton of the Quicktime win­dow.

Notice the video folder, named VIDnet.

Quicktime is used ear­lier in the movie. When Dennis is re­vealed to be work­ing at Jurassic Park, he had Jaws played on his left screen[8].

IRIX System Usage util­ity, named gr_os­view can be seen a few times. It looks like a pow­er­ful tool, able to re­port not only user time, sys time, but also in­ter­rupt over­head and even gfx over­head ac­cord­ing to IRIX - Desktop User’s Guide on p182.

Despite re­ports that mon­i­tors screens were faked via re­mote op­er­a­tors, gr_os­view seems to re­act ap­pro­pri­ately to key­strokes in the se­quence above. Maybe this one was ac­tu­ally live.

When Ray ac­ci­den­tally locks down the whole sys­tem, Nedry’s face su­per­im­posed onto an Elvis Presley jump­suit shows up on his Macintosh. That is the UI of the “White Rabbit”, which Ray Arnold briefly men­tions when he ex­plains the lock­down to Ellie Sattler “White rab­bit ob­ject. Whatever it did, it did it all. But with the key-checks off, the com­puter did­n’t file the key­strokes.”. It is only in the novel that the pro­gram file­name, whte_rbt.obj is re­vealed. Michael Crichton, the au­thor of Jurassic Park, was ac­tu­ally a highly ca­pa­ble pro­gram­mer.

The leg­endary “It’s a Unix sys­tem. I know this” se­quence was done us­ing an ex­per­i­men­tal SGI file ex­plorer ap­pli­ca­tion named fsn. Lex Murphy takes over Dennis’s SGI Crimson and opens the /usr di­rec­tory.

SGI was su­per happy to see this since they men­tioned “YOU SAW IT IN JURASSIC PARK!” on their web­site[9].

IRIX sup­ported spaces in file and di­rec­tory names. I as­sume they put a dot be­tween Visitors and Center for style.

Nedryland is the sys­tem mod­estly named by Dennis Nedry to con­trol Jurassic Park. We can catch a few glimpses of the name on screen when the sys­tem suc­cess­fully re­boots.

There is very lit­tle on­line about how these screens were cre­ated ex­cept that they were cre­ated by Michael Backes and his team.

Fans have recre­ated Nedryland. Checkout JPOS NEDRYLAND YouTube chan­nel to see it in ac­tion. There is also an on­line ver­sion at juras­sic­sys­tems.com.

Some code as­so­ci­ated with Nedryland is vis­i­ble on screen. It looks like ac­tual source code[10] with Classic Mac OS API func­tions calls. EDIT: Several hack­ers news users pointed out this is Pascal from MPW (Macintosh Programmers Workshop).

Later dur­ing the faked video-con­fer­ence, we can see more files be­long­ing to a Nedryland di­rec­tory.

One last de­tail for the road. The book on the top of Dennis’s shelf (upper-right) is System 7 Revealed by Anthony Meadow. Wow they re­ally did pay at­ten­tion to every de­tail!

References

^[ 1]Motorola Envoy Release date ^[ 2]Connection Machine Series ^[ 3]The CM-5, Moore’s Law, and the Future of Computational Performance ^[ 4]NCAR’s Connection Machine 5 - Littlebear ^[ 5]CM-5 in Jurassic Park ^[ 6]SGI hard­ware de­vel­oper hand­book p4 – 25 ^[ 7]Using the Indigo Keyboard with a Personal Iris ^[ 8]In Jurassic Park, when Nedry is in­tro­duced, you can see he’s watch­ing Jaws on his com­puter. ^[ 9]3D File System Navigator for IRIX 4.0.1+ ^[10]Source code on Nedry’s work­sta­tion: real pro­gram­ming lan­guage/​s?

Why is this an “app”?

This sum­mer, the kids’ per­form­ing arts school are singing and danc­ing in a show at Disneyland. We’re all very ex­cited, but my ex­cite­ment, at least, was muted a lit­tle when I was told to in­stall the “Travelbound” app in or­der to get ac­cess to the itin­er­ary, travel arrange­ments, and ac­com­mo­da­tion de­tails.

Fuck that noise. This should have been a web­page. Why do you want me to in­stall a(nother) shitty app just to tell me some­thing that could have been a (smaller, faster, more uni­ver­sally-ac­ces­si­ble) doc­u­ment?

There only seem to be two things that this “app” does, that a web­page might not have, and they’re both anti-fea­tures:

It re­ports track­ing data as­so­ci­ated with your Google Account back to the de­vel­op­ers.

It shows you ad­ver­tise­ments (which they call “inspirations”) for other trips or­gan­ised by the same agency.

Fuck. Everything. About. That.

A web­page would have been so much bet­ter. Unlike this app, a web­page can be…1

Copy-pastable

Printable

Saveable

Bookmarkable

Searchable

Usable on vir­tu­ally any de­vice

(Potentially) more-ac­ces­si­ble

I’m an­noyed enough… that I’m go­ing to “fix” this app. Hold my beer.

Intercepting app traf­fic

It’s been a while since the last time I re­verse-en­gi­neered an Android app from its net­work traf­fic, so I had to brush-up on the best way. Here’s what I ended up do­ing.

Created a new vir­tual de­vice in Android Studio’s Virtual Device Manager.

Tested adb shell was work­ing and used rootAVD to root it: ./rootAVD.sh sys­tem-im­ages/​an­droid-33/​google_apis_­play­store/​x86_64/​ramdisk.img.2

Performed a cold boot, ran Magisk, and tweaked its set­tings to au­to­mat­i­cally grant su ac­cess to any app that asked.3

Ran HTTP Toolkit and told it to in­ter­cept AVD traf­fic. It in­stalled a (fake) VPN provider, rout­ing the phone’s traf­fic through the proxy.4

Installed the Travelbound app from the Play Store.

Configured HTTP Toolkit to proxy only the Travelbound app (more sig­nal, less noise).

With only a cou­ple of min­utes ex­per­i­men­ta­tion I dis­cov­ered that the app works by con­cate­nat­ing the user­name and pass­word5 and us­ing it in a URL of the form:

https://​trav­el­bound.api.va­moos.com/​api/​itin­er­aries/{​user­name}-{pass­word}

https://​trav­el­bound.api.va­moos.com/​api/​itin­er­aries/{​user­name}-{pass­word}

This re­turns a pile of JSON which, with a lit­tle in­ter­pre­ta­tion, can be seen to rep­re­sent all of the con­tent the app “shows”. E.g., there’s:

an ar­ray con­tain­ing each leg of the itin­er­ary,

an ar­ray con­tain­ing all of the “inspirations” ad­ver­tise­ments to show you,

a cross-ref­er­enced ar­ray con­tain­ing all of the files (images etc.) that are ref­er­enced by the other sec­tions, etc.

A lit­tle ex­per­i­men­ta­tion showed me that the S3 im­age URLs were be­ing de­liv­ered with mod­er­ately-short ex­pi­ra­tion times, so the JSON needs re-fetch­ing pe­ri­od­i­cally even if the con­tent has­n’t been changed.6

Turning it into some­thing bet­ter

Now I had every­thing I needed to make some­thing… bet­ter. I wrote a Ruby script that runs on a Cron sched­ule to pull the lat­est JSON and use it to build a HTML page.

I chose to have it com­pletely skip over the “inspirations” (“overlayRows” in the data schema) and just list:

the items from the itin­er­ary and

all of the files not ref­er­enced by the in­spi­ra­tions nor itin­er­ary, (a lazy way to col­late the PDF down­load links).

Then I hosted the page, pro­tected by a pass­word: the same one my tour group were given in the first place. I in­cluded the raw JSON it used in <details> el­e­ments so it can be checked if e.g. there are bits of the schema I did­n’t see but that might ap­pear later.

Some peo­ple like an “app”, and that’s… fine, I guess. But some apps could have been a web­page. And es­pe­cially where, like this one, the con­tent they de­liver is al­ready writ­ten in HTML and de­liv­ered over HTTP… they should be a web­page, right?

I can’t un­der­stand how we got to this place with “app cul­ture”! Software com­pa­nies are happy to make their lives harder (and more ex­pen­sive: de­ploy­ing to the big app stores is­n’t free!), in or­der to de­liver HTML con­tent to fewer peo­ple and with fewer fea­tures7 than if they just pub­lished di­rectly to the Web in the first place!

There are (some) tasks for which an “app” is ab­solutely the right choice of medium. Travelbound is not one of them.

But at least I (and the rest of our group, whom I’ve shared it with) now get the choice about how we ac­cess this con­tent. Either a 43MB app (ballooning to 124MB when it’s fin­ished down­load­ing ex­tra con­tent) with track­ing and ad­ver­tise­ments… or a 0.05MB web page (with an op­tional ex­tra 35MB of im­ages) that pro­vides more fea­tures and works on more de­vices. I know which one I’ll be us­ing!

Footnotes

1 And these are just the fea­tures that every­body can get be­hind. The web­page I ul­ti­mately ended up mak­ing to re­place the app also has some user-friendly/​de­vel­oper-hos­tile fea­tures, like the fact that it re­moves the track­ing code and does­n’t show ad­ver­tise­ments.

2 You need to root the de­vice in or­der to force ap­pli­ca­tions that use Certificate Pinning to trust your man-in-the-mid­dle proxy server. Without this, some ap­pli­ca­tions — in­clud­ing the one I wanted to re­verse-en­gi­neer — will recog­nise your self-signed TLS cer­tifi­cate as in­valid and refuse to com­mu­ni­cate.

3 Without chang­ing this set­ting in Magisk, I found that HTTP Toolkit would re­quest su ac­cess but not wait for the re­sponse, and go on to run in un­priv­i­leged mode be­fore I had a chance to grant it!

4 Owing to Android se­cu­rity con­sid­er­a­tions I needed to man­u­ally in­stall the root CA cer­tifi­cate it in­stalled for me, but the in­struc­tions “just worked”.

5 The user­name and pass­word is shared by an en­tire tour group. I’m guess­ing they don’t have a plan for if some cre­den­tials get leaked? Or pos­si­bly they con­sider all of the data they hold to be low-sen­si­tiv­ity enough that it does­n’t mat­ter if it does… in which case I re­turn to my orig­i­nal point: why the hell was­n’t it just a web­page in the first place?

6 Or else the im­ages need caching lo­cally, which seems to be what the app does, in the bloat­i­est pos­si­ble way.

7 And, of­ten, with worse ac­ces­si­bil­ity. I’ve not au­dited the ac­ces­si­bil­ity of this app, but there are things about it that sug­gest that it’d be harder to use us­ing ac­ces­si­bil­ity tech­nolo­gies than my plain, sim­ple Web ver­sion.

Pigeons & Planes is all about mu­sic dis­cov­ery, sup­port­ing new artists, and de­liv­er­ing the best mu­sic cu­ra­tion on­line and IRL. We’re al­ways lis­ten­ing. Pigeons & Planes is all about mu­sic dis­cov­ery, sup­port­ing new artists, and de­liv­er­ing the best mu­sic cu­ra­tion on­line and IRL. We’re al­ways lis­ten­ing. Pigeons & Planes is all about mu­sic dis­cov­ery, sup­port­ing new artists, and de­liv­er­ing the best mu­sic cu­ra­tion on­line and IRL. We’re al­ways lis­ten­ing. Pigeons & Planes is all about mu­sic dis­cov­ery, sup­port­ing new artists, and de­liv­er­ing the best mu­sic cu­ra­tion on­line and IRL. We’re al­ways lis­ten­ing. Pigeons & Planes is all about mu­sic dis­cov­ery, sup­port­ing new artists, and de­liv­er­ing the best mu­sic cu­ra­tion on­line and IRL. We’re al­ways lis­ten­ing. Pigeons & Planes is all about mu­sic dis­cov­ery, sup­port­ing new artists, and de­liv­er­ing the best mu­sic cu­ra­tion on­line and IRL. We’re al­ways lis­ten­ing. Pigeons & Planes is all about mu­sic dis­cov­ery, sup­port­ing new artists, and de­liv­er­ing the best mu­sic cu­ra­tion on­line and IRL. We’re al­ways lis­ten­ing. Pigeons & Planes is all about mu­sic dis­cov­ery, sup­port­ing new artists, and de­liv­er­ing the best mu­sic cu­ra­tion on­line and IRL. We’re al­ways lis­ten­ing.

The chat client that brought Comic Sans to the world is now on GitHub

Today, we’re ex­cited to an­nounce the open-source re­lease of Microsoft Comic Chat, the chat client that au­to­mat­i­cally turned con­ver­sa­tions within Internet Relay Chat (IRC) into comic pan­els fea­tur­ing il­lus­trated char­ac­ters, speech bub­bles, and ex­pres­sions, and helped in­tro­duce the world to a lit­tle font called Comic Sans.

Yes, that Comic Sans. Originally de­signed by Microsoft ty­pog­ra­pher Vincent Connare in 1994, Comic Sans found its first real home in Comic Chat, where its in­for­mal, hand-let­tered feel matched the soft­ware’s speech-bub­ble con­ver­sa­tions per­fectly.

For many peo­ple, Comic Chat is a nos­tal­gic ar­ti­fact from the early days of the in­ter­net as we tran­si­tioned from tech­nolo­gies like tel­net, Usenet, and IRC to the largely vi­sual web that we en­joy to­day. For oth­ers, it’s a leg­endary piece of Microsoft his­tory they have only heard about in sto­ries, screen­shots, and de­bates about ty­pog­ra­phy. Now, de­vel­op­ers, his­to­ri­ans, retro com­put­ing en­thu­si­asts, and any­one who ap­pre­ci­ates a won­der­fully un­con­ven­tional idea can ex­plore the source code for them­selves.

A dif­fer­ent vi­sion for on­line com­mu­ni­ca­tion

Today we’re ac­cus­tomed to mes­sag­ing apps with re­ac­tions, stick­ers, GIFs, avatars, video, and AI-generated con­tent. But in the mid-1990s, in­ter­net chat was largely walls of scrolling text.

Rather than dis­play­ing mes­sages as plain text, Comic Chat pre­sented par­tic­i­pants as il­lus­trated char­ac­ters. Conversations un­folded in comic pan­els, with speech bub­bles, ex­pres­sions, and ges­tures gen­er­ated from what peo­ple typed. If some­one wrote “I like that,” the char­ac­ter might point to it­self. If the text sug­gested anger, the char­ac­ter might frown or cross its arms. It was quirky, am­bi­tious, oc­ca­sion­ally chaotic, and sur­pris­ingly for­ward-look­ing.

Many ideas we now take for granted in on­line com­mu­ni­ca­tion can trace some of their spirit to ex­per­i­ments like Comic Chat.

The peo­ple who built it

David “DJ” Kurlander, work­ing in the Microsoft Research Virtual Worlds Group, con­ceived the idea of a new vi­sual rep­re­sen­ta­tion of con­ver­sa­tional his­to­ries, and started de­vel­op­ing Comic Chat in 1995. Built in Visual C++ 4.0 and MFC, Comic Chat was re­leased in 1996 with the Internet Explorer 3 web browser.

Under the hood, Comic Chat was more than a clever skin for IRC. It was able to in­ter­pret con­ver­sa­tional cues in the text and choose ap­pro­pri­ate poses, fa­cial ex­pres­sions, ges­tures, and panel lay­outs. That meant Comic Chat was not sim­ply dis­play­ing mes­sages but also mak­ing real-time ed­i­to­r­ial de­ci­sions about how a con­ver­sa­tion should look and feel as a comic. DJ, Tim Skelly, and David Salesin pub­lished a pa­per on the tech­nol­ogy in Comic Chat at SIGGRAPH ’96, a com­puter graph­ics con­fer­ence, de­scrib­ing what they had built as an ex­per­i­ment in au­to­matic il­lus­tra­tion con­struc­tion and lay­out.

The vi­sual world of Comic Chat was the work of Jim Woodring, a highly re­garded in­de­pen­dent comic artist whose char­ac­ters gave the soft­ware its dis­tinc­tive look. The team would hand Jim tran­scripts of real chat ses­sions to il­lus­trate, then use the re­sults to fig­ure out whether the whole idea was worth pur­su­ing. It was.

Why open source it now?

Comic Chat rep­re­sents a fas­ci­nat­ing chap­ter in the evo­lu­tion of on­line com­mu­ni­ca­tion. It emerged dur­ing a pe­riod when the in­ter­net was still dis­cov­er­ing what it wanted to be­come. Many rules had not yet been writ­ten, which gave de­vel­op­ers per­mis­sion to try bold con­cepts that might seem un­usual even to­day.

By re­leas­ing Comic Chat as open source, we’re pre­serv­ing an im­por­tant piece of soft­ware his­tory and giv­ing the com­mu­nity an op­por­tu­nity to ex­plore, learn, and build upon it.

The source is avail­able now for ex­plo­ration, study, and ex­per­i­men­ta­tion. Alongside the orig­i­nal snap­shots, we’ve in­cluded a few AI-powered mod­ern­iza­tion at­tempts that demon­strate what’s pos­si­ble—get­ting this 1990s-era C++ and MFC code build­ing with cur­rent Visual Studio tools, con­nect­ing to mod­ern IRC servers, and run­ning leg­i­bly on to­day’s high-res­o­lu­tion Windows ma­chines. These are not pol­ished re-re­leases, but worked ex­am­ples that show Comic Chat can still come alive on mod­ern sys­tems. We’re ex­cited to see what im­prove­ments, ports, ex­per­i­ments, and en­tirely new forms the com­mu­nity brings to it next.

A time cap­sule of in­ter­net op­ti­mism

Looking back, Comic Chat cap­tures some­thing spe­cial about the era in which it was cre­ated.

The early web was filled with ex­per­i­men­ta­tion. “What if chat rooms looked like comics?” That ques­tion sounds won­der­fully un­rea­son­able. And yet it was built, shipped, lo­cal­ized into 24 lan­guages, and bun­dled with Windows 98.

That’s part of what makes Comic Chat mem­o­rable decades later. It re­minds us that in­no­va­tion of­ten starts with ideas that are play­ful, un­con­ven­tional, and cre­ative.

One last speech bub­ble

Comic Chat was cre­ated dur­ing a pe­riod when soft­ware teams were will­ing to color out­side the lines, lit­er­ally and fig­u­ra­tively. DJ Kurlander, Tim Skelly, David Salesin, Jim Woodring, and every­one else who touched this pro­ject made some­thing that peo­ple still re­mem­ber and still run thirty years later.

Take a look at the source code, ex­plore what they built, and use its story as in­spi­ra­tion to come up with new un­con­ven­tion­ally de­light­ful things to cre­ate.

And if you hap­pen to read the source code in Comic Sans, we promise not to judge.