Dev & AI weekly — July 18, 2026
Dev & AI weekly — July 18, 2026
Two open-weight frontier models landed within 24 hours of each other this week, which is the kind of thing that would have been the story of the quarter a year ago. Meanwhile the pipeline that actually ships your code got popped again — by the exact same GitHub Actions misconfiguration we wrote about last week. Here's what matters.
Thinking Machines ships Inkling — and is refreshingly honest about it
Mira Murati's Thinking Machines Lab released its first in-house model, Inkling, on July 15. It's open-weight: you can download it, modify it, run it.
The specs are serious. It's a mixture-of-experts system with 975B total parameters but only ~41B active for any given task, trained on 45 trillion tokens of text, image, audio, and video — and it reasons natively across all four rather than bolting on modality adapters. Benchmarks: 97.1% on AIME 2026, 87.2% on GPQA Diamond, 77.6% on SWE-bench Verified, and 54.3% on SWE-bench Pro Public.
The most interesting thing is what they said about it. From their own announcement, Inkling is "not the strongest overall model available today, open or closed." You almost never see a lab ship with that sentence attached.
That's not modesty, it's positioning. Inkling isn't sold as a finished product — it's sold as a starting point you fine-tune yourself through Tinker, their customization platform. The supporting stat is the one builders should notice: on one coding benchmark it reportedly hits the same performance as Nvidia's Nemotron 3 Ultra using a third of the tokens. Token efficiency compounds brutally in agent loops, where you're paying for thousands of turns, not one.
Why it matters: if your workload is narrow and repetitive — a specific codebase, a specific ticket format, a specific domain — a smaller open model you fine-tune can beat a bigger general one you rent. Inkling is a bet that the future is many specialized models rather than one giant API. Whether that bet pays off depends on whether fine-tuning stays hard.
Kimi K3: the largest open-weight model ever, and it's beating closed models on code
The next day, Moonshot AI shipped Kimi K3 — 2.8 trillion parameters, MoE, which makes it the largest open-weight model released to date. It has a 1M-token context window, native visual understanding, and an always-on reasoning mode.
The benchmark that'll get attention: K3 took #1 in the Frontend Code Arena at 1,679, ahead of Claude Fable 5 (1,631), GPT-5.6 Sol (1,618), and GLM-5.2 (1,587). On the broader Artificial Analysis Intelligence Index it scores 57, 4th out of 189 models — level with Opus 4.8 and GPT-5.5, behind only Fable 5 and GPT-5.6 Sol.
API pricing is $3 / $15 per million input/output tokens. It's live now via the app, playground, and API; full weights are scheduled for July 27, so "open-weight" is currently a promise with a date on it rather than a download link.
Why it matters: an open model taking the top spot on a frontend coding arena — over the frontier closed models — is a genuine milestone, not a press-release milestone. Two caveats before you rewrite your stack: arena rankings measure human preference on specific task distributions, not your codebase; and a 2.8T-parameter model is "open" in the license sense, not the "I'll run this on my GPU" sense. Realistically you're using someone's API either way, so evaluate it on price and quality, not the open-weight badge.
The same GitHub Actions footgun took out AsyncAPI
Now the part that should make you check your own repos. On July 14–15, Microsoft Threat Intelligence identified a coordinated compromise of the @asyncapi npm organization. Five versions across four packages were republished within roughly ninety minutes, each carrying the same injected loader:
@asyncapi/specs(6.11.2-alpha.1 and 6.11.2)@asyncapi/generator@3.3.1@asyncapi/generator-components@0.7.1@asyncapi/generator-helpers@1.1.1
All five have been unpublished. But look at the root cause: a misconfigured pull_request_target workflow executed attacker-controlled pull-request code, which exposed the asyncapi-bot personal access token, which enabled pushes to auto-publish branches.
If that sounds familiar, it's because it's the same chain that compromised TanStack (CVE-2026-45321) — which we covered two weeks ago. Two separate, widely-used projects, same footgun, inside a month.
The trap is subtle by design. pull_request_target runs in the context of the base repository — with write permissions and secrets — specifically so maintainers can label PRs and post comments from forks. The moment you also check out and execute the PR's code inside that workflow, you're running a stranger's script with your tokens in scope:
# DANGEROUS — runs untrusted fork code with secrets in scope
on: pull_request_target
jobs:
build:
steps:
- uses: actions/checkout@v4
with:
ref: ${{ github.event.pull_request.head.sha }} # ← attacker's code
- run: npm install && npm run build # ← with your PAT available
The fix is boring and absolute: never check out PR head code in a pull_request_target workflow. Use pull_request (no secrets, no write) for anything that builds or tests contributor code, and keep pull_request_target for metadata-only jobs. If you need both, split them into two workflows. Then go audit whether any bot PAT in your org can push to a branch that auto-publishes.
Why it matters: this is the highest-leverage attack in the ecosystem right now — one workflow misconfiguration converts into publish rights over packages that thousands of projects install transitively. It also lands with npm v12's script-blocking defaults arriving this month, which is the ecosystem admitting the same thing: the install pipeline was never safe by default.
The through-line
The models got dramatically more open this week and the supply chain got no safer. Those are related. As more teams pull open weights, self-host, and glue inference stacks together from packages, the attack surface moves down — out of the model and into the boring plumbing that installs it. The interesting capability news and the scary security news are increasingly the same story from opposite ends.
What to watch next: whether Kimi K3's weights actually land on July 27 as promised — and how many more pull_request_target compromises surface now that two high-profile ones have shown the pattern works.
Sources: Thinking Machines — Introducing Inkling · TechCrunch — Inkling · Axios — Murati's first model · Simon Willison — Inkling · VentureBeat — Kimi K3 · Tom's Hardware — Kimi K3 · Simon Willison — Kimi K3 · Microsoft Security — AsyncAPI npm compromise · The Hacker News — AsyncAPI packages · Unit 42 — npm threat landscape