DEV Community: Joske Vermeulen

AI Dev Weekly #27: GPT-6 Sol and Luna, Claude Opus 5.5, Grok 4.7

Joske Vermeulen — Thu, 24 Sep 2026 08:46:58 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

This was the busiest model week of the series so far. OpenAI filled out the GPT-6 family with a serious coding model and a remarkably cheap volume model. Anthropic replaced its Opus flagship with a faster, less expensive release. SpaceXAI moved Grok further into long-running coding work. And GitHub added the controls needed to run those increasingly capable agents on a developer machine without treating trust as a checkbox.

The shared theme is not simply higher benchmark scores. Every launch competes on the cost and operational shape of a completed task: reasoning effort, caching, tool loops, sandbox boundaries, and traces.

1. GPT-6 Sol and Luna turn one architecture into two very different products

OpenAI released GPT-6 Sol and GPT-6 Luna in the API on September 22. Both accept text and image inputs, return text, and expose the same unusually large limits: a 1,050,000-token context window and up to 128,000 output tokens.

That is where the similarity stops.

Model	Intended role	Input / cached / output per 1M tokens
GPT-6 Sol	Complex coding and agentic workflows	$2 / $0.20 / $10
GPT-6 Luna	Focused, high-volume tasks	$0.10 / $0.01 / $0.50

According to the official OpenAI Docs for GPT-6 Sol and GPT-6 Luna, Sol costs exactly twenty times Luna at every standard text-token rate, including cache writes. Both support reasoning from none through max, with medium as the default.

There is an API boundary that is easy to miss. Built-in tools and normal reasoning tool loops require the Responses API. Chat Completions supports function calling only when reasoning effort is set to none. A model appearing on both endpoints does not mean the endpoints expose identical agent behavior.

Long context also has the same price cliff as Astra. Above 272,000 input tokens, the full request is charged at 2x input and cache rates and 1.5x output rates. Luna remains inexpensive after the multiplier, but the cliff can still invalidate a spreadsheet that prices only the tokens above the threshold.

My take: Luna is the bigger strategic release. At $0.10/$0.50, it makes classification, extraction, routing, test generation, and parallel subagent work cheap enough to reconsider architectures built around older small models. Sol is the safer default when coding judgment and multi-step tool use determine success. Start with Luna, escalate failed or ambiguous work to Sol, and keep Astra for the tasks where its additional capability wins an evaluation. Our GPT-6 Sol guide, GPT-6 Luna guide, and Sol vs Luna comparison cover the full pricing and routing decision.

2. Claude Opus 5.5 makes the premium tier less premium

Anthropic launched Claude Opus 5.5 on September 22 with the API ID claude-opus-5-5. The model has a 1M-token context window, 128K maximum output, and always-on adaptive thinking. It is available through the Claude API and across AWS, Google Cloud, and Microsoft platforms.

Standard pricing is $4 per million input tokens and $20 per million output tokens, down from $5/$25 for Opus 5. Cache reads fall more sharply, from $0.50 to $0.20 per million tokens. Anthropic says the combination of lower rates and lower token use reduces typical workload cost by 40%, while output generation is more than 30% faster. Those are vendor measurements, not a guarantee for every workload.

The launch announcement reports strong agentic coding results, including 66.4% on Terminal-Bench 4.0 at xhigh effort and 54.4% on FrontierCode 1.1 Main at max effort. The comparison is not perfectly uniform: models use different harnesses and effort settings, and some Anthropic safeguards reroute restricted tasks to fallback models. Anthropic itself warns that small benchmark margins have become less reliable guides to real-world differences.

Migration has a behavioral constraint beyond price. Opus 5.5 uses preserved thinking for newer API accounts, so applications must return prior thinking blocks without modifying them. Cybersecurity and biology safeguards can also route certain work away from Opus 5.5. Zero-data-retention access remains available, which differs from Fable 5.1's default retention posture.

My take: Opus 5.5 is the first Opus release I would evaluate as a default for genuinely difficult repository work rather than reserve automatically for escalation. But Sol is half the standard token price, and token rates alone still ignore how many attempts a task needs. Run both on the same migrations, incidents, and code reviews, then compare accepted results and review time. The Opus 5.5 guide and GPT-6 Sol vs Opus 5.5 comparison contain the migration and pricing details.

3. Grok 4.7 becomes a credible price-performance wildcard

SpaceXAI released Grok 4.7 on September 21 for coding, agentic tasks, and knowledge work. The public API model ID is grok-4.7. It accepts text and images, has a 500,000-token context window, and supports low, medium, high, and xhigh reasoning. High is the default.

At standard rates below 200K prompt tokens, pricing is $2 per million input tokens, $0.50 cached input, and $6 output. Prompts above 200K double all three rates for the request. The fast variant costs twice as much but is documented only for Cursor and Grok Build, not the public xAI API.

The official model documentation contains two practical integration details:

set prompt_cache_key on Responses requests, or x-grok-conv-id with Chat Completions, to keep a conversation on the same server and improve cache hits;
pass returned encrypted reasoning items back unchanged in later Responses calls so multi-turn reasoning continues correctly.

SpaceXAI reports sizeable improvements over Grok 4.6 on CursorBench, Terminal-Bench, engineering, legal, and office-work evaluations. Those numbers come from the model vendor. They make Grok 4.7 worth testing, not a universal winner.

My take: Grok 4.7 occupies an interesting middle position. Its output is cheaper than Sol while its cached input is more expensive, so the workload's input-to-output ratio matters. The explicit cache-routing requirement is also an operational tax that a superficial price table hides. Test long tool loops with and without stable cache keys and verify that your framework preserves encrypted reasoning items. See the Grok 4.7 complete guide for API and long-context details.

4. Copilot adds the missing runtime controls: containment and traces

GitHub released local sandboxing in the Copilot app on September 23 as a public preview. Each project can restrict filesystem reads and writes, outbound internet and local-network access, plus Git and GitHub CLI credentials for local repository sessions.

The sandbox announcement has four boundaries worth noting:

sandboxing is off by default;
project defaults apply only to new sessions;
changed policies require a new or restarted session;
Copilot app, CLI, cloud, and remote-host sandboxes are separate configurations.

The fail-closed behavior is the most important detail. If the operating system cannot enforce the requested policy, the shell fails rather than silently running without a sandbox. Enterprise-managed settings can still make the effective policy stricter than the project requests.

One day earlier, GitHub added OpenTelemetry export through enterprise-managed settings. Teams can send traces of model and tool activity to compatible monitoring systems. Prompt and response content is excluded by default, so useful content capture is an explicit privacy decision rather than an accidental default.

My take: These features belong together. A sandbox limits what an agent can reach; telemetry shows what it attempted and where a session failed. Neither proves that a change is correct. Enable sandboxing on a disposable repository, test denied paths and network destinations with canaries, then inspect the exported spans before rolling it out. Our Copilot app guide covers the broader client boundaries, while AI agent logging and tracing explains what to capture without leaking sensitive content.

Quick hits

Models land in Copilot: GPT-6 Sol, GPT-6 Luna, Claude Opus 5.5, and Grok 4.7 all became available in GitHub Copilot this week. Availability in a model picker is not proof of identical pricing, context limits, tools, or reasoning controls versus the direct APIs.
VS Code 1.138 agent updates: Local Dev Containers are rolling out in the Agents window, sessions can be marked done after their pull requests merge, and pull requests can be created without leaving the window. The weekly release notes label several of these capabilities as gradual rollout or preview.
Copilot review controls: Teams can request code reviews through additional entry points and configure review behavior more precisely. Keep branch protection and human approval requirements separate from how an automated review starts.

That's it for this week. Next Thursday: early cost-per-accepted-task results from the new model families, whether Luna changes multi-agent economics, and what Copilot's local sandbox blocks in practice.

Want this in your inbox? Subscribe to AI Dev Weekly.

Previous issue: AI Dev Weekly #26

FAQ

Which GPT-6 model should developers start with?

Use Luna for focused, high-volume tasks and Sol for complex coding and agent workflows. Escalate to Astra only when its higher capability improves your measured success rate enough to justify the price.

Is Claude Opus 5.5 cheaper than GPT-6 Sol?

No at standard token rates. Opus 5.5 costs $4/$20 per million input/output tokens versus Sol at $2/$10. Opus can still cost less per accepted task if it completes your workload with fewer attempts or tokens.

Is Grok 4.7 Fast available through the public xAI API?

The official documentation lists Grok 4.7 Fast for Cursor and Grok Build, not the public xAI API. The standard grok-4.7 model is available through the API.

Does Copilot local sandboxing cover every Copilot session?

No. The preview covers local repository and working-tree sessions in the Copilot app. CLI, cloud, and remote-host sessions have separate boundaries or configuration.

- Grok 4.7 Complete Guide

Originally published at https://www.aimadetools.com

AI Dev Weekly #26: Agents API, Full-Duplex Voice, SWE-2 and Cost-Aware Copilot

Joske Vermeulen — Thu, 17 Sep 2026 08:10:18 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

The model is no longer the whole product. OpenAI now sells the managed agent loop behind Codex and a separate voice layer that can keep talking while an agent works. Cognition's SWE-2 focuses on completing coding tasks with fewer detours. Copilot lets developers express a cost-versus-quality preference instead of choosing every model manually. The common question: which parts of the agent stack should you own, and which should you delegate?

This issue includes the September 10 releases that landed after last Thursday's edition, alongside updates through September 17.

1. OpenAI puts the Codex harness behind the Agents API

OpenAI released the Agents API in public beta on September 10. It is a managed runtime for durable agent work, not another name for the Agents SDK. OpenAI handles session orchestration, context compaction, and recovery; your application supplies tools and controls how the agent fits into your product.

The official overview separates four concepts: the agent configuration, its execution environment, a durable session, and the events and items exchanged during that session. Progress can arrive through streaming or webhooks, and a session can receive follow-up work rather than restarting from an empty context.

The architecture guide makes the execution boundary particularly clear:

No environment: the harness can use remote MCP connections and application-handled function tools, without a built-in shell or workspace files.
OpenAI-hosted environment: OpenAI provisions the sandbox for code execution, file edits, and artifacts.
Self-hosted environment: your infrastructure connects an executor, while OpenAI still runs the harness. You own provisioning, reconnection, shutdown, and file preservation.

That last option is not self-hosting the complete agent. Moving execution into your VPC does not move the managed orchestration layer there.

Pricing combines the selected model's API rates, standard tool charges, and standard container rates for OpenAI-hosted sandboxes. Budget the whole run, including subagents and retries, rather than treating a session as one model response.

The security documentation also warns that agent-generated code can read credentials exposed to its environment. Keep the application API key outside the sandbox, restrict outbound destinations, and broker third-party credentials where possible. A sandbox does not make a secret safe after you inject it into the process.

My take: This is a meaningful build-versus-buy shift. Session recovery and compaction are expensive plumbing to maintain, so renting them can make sense. Keep authoritative business state and irreversible-action approvals in your own application, however. Start with a read-only investigator before a remediation agent. Our Cursor Projects vs OpenAI Agents API comparison explains the difference between buying a coding workspace and embedding an agent runtime in your product.

2. GPT-Live-1 separates the conversation from the work

GPT-Live-1 is generally available in the API, also from September 10. Its main architectural change is full duplex: the voice model can listen while speaking, and the spoken conversation can continue while a backend agent handles reasoning and tools.

OpenAI's getting-started guide contrasts this with Realtime's single model for speech, reasoning, and tool selection. With Live, you choose the backend independently. A user can ask about an order, correct a detail while a lookup runs, and receive the result without waiting through a silent tool round trip.

The delegation guide offers two modes:

Responses delegation: Live prepares requests for a configured OpenAI backend and returns its results to the conversation.
Client delegation: your application assembles context, runs its own agent or service, and returns the result. This is the path when you need custom routing or validation before backend results reach the voice model.

Client delegation has a subtle integration requirement: delegation events contain metadata, not the task text. Build backend requests from transcript events and application state. Do not assume the event is a ready-made command payload.

The model page lists voice sessions at $0.05 per minute, billed per second. Backend model and tool usage is additional. A ten-minute voice session therefore costs $0.50 for the voice layer before reasoning, tools, or your infrastructure.

Permissions, confirmation, and task state remain application responsibilities in both modes. Reviewing backend results also does not guarantee the voice model stays silent while validation runs. Test what the assistant says before an action is confirmed, not just whether the tool ultimately succeeds.

My take: Voice becomes an interface over an agent rather than a tightly coupled speech pipeline. That is especially useful for support workflows and hands-free developer collaboration. My first evaluation would test interruptions, changing instructions during a slow lookup, and whether the assistant accurately distinguishes “requested” from “completed.” Natural conversation is valuable only if the task state stays truthful. This is a different problem from the speech-to-text decision in our Gemini Transcribe vs Whisper guide.

3. Cognition SWE-2 targets fewer turns, not just a higher score

Cognition introduced SWE-2 on September 10, launching in Devin Desktop and CLI with rollout to Devin Web and Fusion. The launch post says the model is post-trained from Kimi K3 and trains multiple reasoning-effort levels in one reinforcement-learning run.

The most useful vendor result is operational: SWE-2 at medium effort used 58% fewer turns and cost 81% less than SWE-1.7 on FrontierCode 1.1 Main. Cognition reports a 50.0% score on that benchmark for SWE-2, but only 27.3% on Terminal-Bench 4. The latter trails the strongest models in its comparison substantially.

These are publisher-reported evaluations with a mixture of public results and internal runs in model-specific harnesses. They are not an independent, uniform leaderboard. Cognition has not published standalone SWE-2 API pricing or downloadable weights in the announcement.

My take: The interesting optimization is knowing when to stop exploring and start editing. For a coding agent, fewer repository reads and redundant tool calls can matter more than marginal token-price differences. But “fewer turns” is not automatically “better”: it can also mean skipped verification. Evaluate a bounded bug fix, a migration, and a behavior-preserving refactor, recording accepted changes, missed tests, review corrections, and actual product usage. Our SWE-2 guide covers the access limits and benchmark caveats. Test the Devin capability you can actually use, not an imagined standalone model endpoint.

4. Copilot Auto gains a cost-versus-quality control

GitHub added three Auto routing preferences on September 14: Efficiency for lower cost, Balance for cost, quality, and latency together, and Intelligence for quality. The release announcement says the feature is rolling out in VS Code, Copilot CLI, and the Copilot app.

These are not three separate model catalogs. Each preference uses the same available pool, and routing evaluates the prompt. Intelligence can still select a small model for a simple docstring task. Usage is billed for the model actually selected, and paid subscribers retain a 10% Auto discount.

The Auto documentation adds two useful constraints. The router still respects plan access and administrator policies, and routing uses natural cache boundaries to avoid extra cache-related cost. Auto does not override an organization's restricted-model policy.

A preference is also not a spending cap. Efficiency can choose a more capable model when the task needs one. Intelligence does not guarantee the largest model on every response. Inspect the selected model and actual usage before drawing conclusions from the label.

My take: This is a better abstraction than forcing every developer to maintain a mental model leaderboard. It also makes comparisons harder unless you record routing decisions. Run the same representative tasks under each preference and compare cost per accepted change, latency, and reviewer effort. Keep explicit model selection for evaluations that require reproducibility. Our updated Copilot app guide and usage-based billing explainer separate routing preference from billing policy.

Quick hits

VS Code agent automations: Version 1.137 adds recurring hourly, daily, and weekly tasks in public preview. Start with maintenance reports or draft pull requests, and define what happens when runs overlap. The same weekly release notes put HydraFusion's local/cloud/compound routing in the CLI's experimental menu. Neither should be confused with the standard Auto preferences above.
Copilot code review: It now resolves its own addressed comments during rereview and gains shell tools for builds, tests, and targeted scripts behind the agent firewall. GitHub's update also introduces an agent ensemble for Lite reviews. More validation is useful; required human review remains a separate repository decision.
API key governance: OpenAI added organization and project controls on September 15 to limit new key creation to service accounts, user-owned project keys, or neither. Organization restrictions take precedence and existing keys are unaffected. The API changelog also documents key expiry controls added September 10. Creation policy is not retroactive credential rotation.

That's it for this week. Next Thursday: how managed agent sessions recover from real failures, whether full-duplex voice keeps task state honest, and what routing preferences cost on actual repository work.

Want this in your inbox? Subscribe to AI Dev Weekly.

Previous issue: AI Dev Weekly #25

FAQ

Is OpenAI's Agents API the same as the Agents SDK?

No. The API provides an OpenAI-managed harness and durable sessions. The SDK provides primitives for application-owned orchestration. The new API remains in public beta.

Does GPT-Live-1's price include the backend agent?

No. The voice layer costs $0.05 per minute, billed per second. Backend model and tool usage is charged separately.

Can I download Cognition SWE-2 or call a standalone API?

Neither downloadable weights nor standalone API pricing were published in the launch announcement. Evaluate SWE-2 through the documented Devin surfaces.

Does Copilot Efficiency guarantee a fixed bill?

No. It is a routing preference, not a cap. Billing follows the selected model, so measure actual usage and enforce budgets separately.

- Copilot Usage-Based Billing

Originally published at https://www.aimadetools.com

AI Dev Weekly #25: GPT-6 Astra Arrives, Kotlin Agents Reach 1.0, Copilot Adds Enforced Permissions

Joske Vermeulen — Thu, 10 Sep 2026 09:38:03 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

Four different layers of the agent stack changed this week. OpenAI introduced GPT-6 Astra for the hardest tool-rich work. Google made its Kotlin agent framework production-ready. GitHub gave enterprise administrators permissions that local settings cannot weaken. And NVIDIA released a local inference router that spreads independent agent calls across computers you already own.

1. GPT-6 Astra raises the ceiling and the bill

OpenAI introduced GPT-6 Astra as its highest-capability model for complex reasoning, coding, computer use, research, and document creation. The API model ID is gpt-6-astra, with a 1,050,000-token context window, 128,000 maximum output tokens, and low through max reasoning levels.

The official model guide adds three API capabilities that matter more than another benchmark table:

asynchronous tool calls, so the model can continue independent work while your application runs a slow tool;
mid-turn steering over a WebSocket connection, preserving completed work when requirements change;
reasoning updates without breaking the prompt cache, using a configuration_update item to change effort during a conversation.

These features are aimed at long-running systems, not one-shot chat. Async tools require the application to track pending calls and return results with the original call ID. Mid-turn steering needs event handling that distinguishes new instructions from tool results. Neither feature makes concurrency safe automatically.

Standard pricing is $10 per million input tokens, $1 per million cached input tokens, and $50 per million output tokens. Cache writes cost $12.50 per million. Batch and Flex are half the standard rates, while Fast mode is twice the standard price.

There is also a long-context cliff. Requests above 272,000 input tokens charge the full request at 2x input and cache rates and 1.5x output rates. A 300K-token prompt is not billed at the standard rate for the first 272K.

OpenAI's launch announcement describes a staged rollout across the direct API, ChatGPT, Azure, and AWS Bedrock. GitHub separately made Astra generally available in Copilot on September 4 for eligible plans. Those are different availability surfaces, so check the exact account and endpoint before migrating.

My take: Astra is an escalation model, not a cost-blind default. The new coordination features can reduce idle time and preserve work during long tasks, but they also create more application state to test. Compare cost per accepted result against Sol or Terra, including tool retries and reviewer time. Our GPT-6 Astra guide covers pricing, rollout, and tool support, while Astra vs GPT-5.6 Sol handles the model-routing decision.

2. Google's Agent Development Kit for Kotlin reaches 1.0

Google released ADK for Kotlin 1.0 on September 9. The core is generally available and reaches feature parity with the Python and Java ADK cores. It supports hierarchical multi-agent systems, context compaction, resumable sessions, long-running tools, human confirmation flows, and Java interoperability.

The framework is built around Kotlin Multiplatform and is not limited to Android. Server-side JVM teams can use it without adopting a Python agent service. Kotlin Symbol Processing generates tool schemas from @Tool and @Param annotations at compile time, avoiding runtime reflection and making schema mismatches easier to catch during builds.

The official announcement is especially interesting on Android:

LiteRT-LM can run local models;
Firebase AI Logic provides cloud reasoning;
Room can persist sessions across process restarts;
AppSearch can hold semantic memory;
confirmation flows can pause sensitive tools and resume after user approval.

Release labels still matter. The Kotlin core and LiteRT-LM integration are listed at 1.0.0, while the ML Kit Android extension in Google's example is 1.0.0-beta. A framework reaching GA does not promote every optional backend to the same status.

My take: This is the most practical mobile-agent release in months. Android developers can keep orchestration, persistence, and approval flows in the language and architecture they already use. Start with one resumable agent and explicit tool confirmation before reaching for a hierarchy of agents. Production readiness depends more on lifecycle recovery and deterministic tool boundaries than on agent count.

3. Copilot permissions can now override local auto-approval

GitHub made enterprise-managed permissions for Copilot agent operations generally available on September 9. Administrators can centrally mark operations as blocked, approval-required, or allowed without a prompt.

The controls cover:

shell commands;
file reads and edits;
network domains.

The crucial property is precedence. According to the GitHub changelog, managed restrictions cannot be weakened by user settings, workspace settings, auto-approval, or a previously saved approval. Enterprises can also define different policies for different teams.

The controls are GA in the Copilot app, Copilot CLI, and VS Code sessions using Agent Host. GitHub also added enterprise-managed sandbox policies to Copilot for JetBrains on September 8, but that sandbox feature remains in public preview. It can govern filesystem and network access, proxy behavior, developer tools, and macOS Keychain access.

Permissions and sandboxing solve related but distinct problems. A permission policy decides which requested actions may proceed. A sandbox limits what the process can reach even if an action is attempted. Mature deployments need both, plus repository protections and secret controls.

My take: This is the follow-through last week's content exclusions needed. Context exclusions decide what the agent may read as input; managed permissions decide what it may do; a sandbox limits the operating environment. Test all three with deliberate canaries because a settings page is not proof that enforcement works on every client.

4. NVIDIA PAIR turns spare PCs into a local inference queue

NVIDIA released the open-source Personal AI Router, or PAIR, in beta. It presents familiar Ollama and LM Studio endpoints while routing independent inference requests across compatible machines on a trusted local network.

PAIR discovers paired nodes, tracks engine readiness and installed models, chooses an eligible machine, and streams the response back to the application. Existing agents can keep using an Ollama-compatible or OpenAI-compatible endpoint without integrating a new cluster API.

The NVIDIA technical overview documents support for Windows, macOS, and Linux systems with GeForce RTX 20 Series or newer GPUs, RTX PRO workstations, DGX Spark, and Apple M4 or newer silicon.

The boundary is important: PAIR does not pool VRAM or split one model across machines. Each request runs from start to finish on one node, and that node must already have the requested model. It improves throughput when multiple agents or users create independent calls. It does not make a single oversized model fit or make one generation inherently faster.

NVIDIA reports that a five-subagent demonstration finished in 8 minutes 48 seconds across three devices versus 18 minutes on one RTX Spark laptop. That is a vendor demonstration of concurrent scheduling, not an independent inference benchmark.

My take: PAIR is useful when your local bottleneck is a queue, not model size. It is a poor reason to buy more hardware, but a good way to use compatible machines you already own. The full NVIDIA PAIR guide covers routing and security boundaries, and PAIR vs plain Ollama networking helps decide whether you need it.

Quick hits

K2 Horizon: IFM released six Apache-2.0 models from 0.9B to 375B-A23B, with a broader transparency package spanning training data or recipes, code, and intermediate artifacts. Some promised artifacts remain forthcoming in individual repositories, so “fully open” still requires file-by-file verification. See our K2 Horizon guide.
MiniCPM5-2B: OpenBMB released a compact 2B-class model with 131K context, tool use, coding, and formats for GGUF, MLX, GPTQ, and LiteRT. Its benchmark claims are publisher-reported, but the range of deployable artifacts makes it worth testing for on-device agents. See our MiniCPM5-2B guide.
DeepSeek V4.1 Flash: DeepSeek signaled a release around September 10, but its official English changelog had not provided a stable release entry with final status and migration details during this edition's research window. Treat preview aliases and routing reports as unconfirmed until the primary documentation updates.

That's it for this week. Next Thursday: real Astra cost-per-task data, early Kotlin ADK lifecycle reports, and whether DeepSeek turns its V4.1 preview into a clearly documented release.

Want this in your inbox? Subscribe to AI Dev Weekly.

Previous issue: AI Dev Weekly #24

FAQ

Is GPT-6 Astra generally available in the OpenAI API?

OpenAI documents gpt-6-astra for the API but describes access as a staged rollout across accounts and platforms. Check your project's model list. GitHub Copilot's separate Astra availability is GA for eligible plans.

Is ADK for Kotlin 1.0 only for Android?

No. Its Kotlin Multiplatform core supports server-side Kotlin and Java interoperability. Android-specific modules add local models, Firebase AI, Room persistence, AppSearch memory, and mobile integrations.

Can a developer bypass GitHub's managed agent permissions?

GitHub says enterprise-managed restrictions take precedence over user and workspace settings, auto-approval, and saved approvals. Administrators should still test enforcement across every enabled client.

Does NVIDIA PAIR combine GPU memory across computers?

No. PAIR routes separate requests to eligible nodes. Each complete model and request must fit on the single machine selected to run it.

- K2 Horizon Explained

Originally published at https://www.aimadetools.com

AI Dev Weekly #24: Gemini 3.8 Flash Goes GA, Fable 5.1 Cuts Agent Cache Costs, Agent Plugins 1.0 Ships

Joske Vermeulen — Thu, 03 Sep 2026 09:55:21 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

The common thread this week is production readiness. Google gave Gemini 3.8 Flash a stable endpoint and a dated price increase. Anthropic made Fable 5.1 generally available while cutting the cost of repeatedly reading cached context. VS Code shipped a portable plugin format alongside its persistent Agent Host architecture. And GitHub extended content exclusions to the Copilot app and CLI, closing an important policy gap as agents move beyond the IDE.

1. Gemini 3.8 Flash goes GA, but the launch price expires in four months

Google released Gemini 3.8 Flash on September 2 as a generally available production model. The stable API ID is gemini-3.8-flash, with a 1,048,576-token input limit, up to 65,536 output tokens, and low, medium, or high thinking levels. Medium is the default.

The official Gemini 3.8 Flash guide makes two details especially important for production planning:

introductory pricing is $0.75 per million input tokens and $3.75 per million output tokens through December 31, 2026;
standard pricing doubles to $1.50 input and $7.50 output on January 1, 2027.

Output billing includes thinking tokens, so a higher reasoning level can raise both latency and cost. Google also warns that 3.8 Flash deliberately takes more small reasoning steps and makes more tool calls on difficult tasks. The cheaper launch rate does not guarantee that a long agent run costs less than it did on an earlier Flash model.

The model supports function calling, structured output, caching, code execution, search grounding, file search, Batch, Flex, and Priority inference. Computer use remains in preview even though the model itself is GA. The model does not support the Live API, image generation, or audio generation.

There is migration work. Google says to remove temperature, top_p, and top_k, replace thinking_budget with thinking_level, and stop using prefilled model turns. Applications using generateContent also need names and call IDs on function responses.

Gemini Managed Agents now use 3.8 Flash by default for the Antigravity agent and SDK. That makes this more than a new model option: existing managed-agent evaluations may need to be rerun because the underlying default changed.

My take: The stable endpoint is the headline, but the calendar is the decision. Store the introductory and January prices separately, meter thinking tokens, and pin an explicit model rather than inheriting a managed-agent default silently. The full Gemini 3.8 Flash guide has the complete pricing matrix and migration checklist.

2. Claude Fable 5.1 changes the economics of repeated agent context

Anthropic launched Claude Fable 5.1 on September 1 as a generally available model for long-running coding and knowledge work. It is available through the Claude API, consumer and team plans, and supported cloud marketplaces. The direct API model ID is claude-fable-5-1.

Base token prices remain premium at $10 per million input tokens and $50 per million output tokens. The material price change is prompt-cache reads: $0.25 per million tokens, down 75% from Fable 5. Anthropic estimates that change reduces typical token-billed workload cost by about 25% and highly agentic workload cost by as much as 45%.

Those are Anthropic estimates, not a universal discount. Savings depend on stable reusable prefixes, cache-hit rates, the ratio of cached input to fresh input, and how much output the agent produces. A workload that constantly changes its context or emits long answers will not realize the headline reduction.

The Fable 5.1 announcement also introduces an operational wrinkle. Fable 5.1 and the restricted Mythos 5.1 use the same underlying model but different safeguards. Fable queries flagged in advanced cybersecurity or biology can be routed to an Opus model. Anthropic says API customers must configure the new Fallback API for this behavior, and they are not charged Fable rates for rerouted requests.

Data retention still needs review. Fable requires 30-day retention for safety monitoring by default. Anthropic plans to phase in customer-controlled Enterprise Frontier Safeguards later this fall, with temporary zero-data-retention access for eligible customers until then.

My take: Fable 5.1 is not a new default for ordinary API calls. It is a selective escalation model for the hardest repository-scale and long-running work. The cache cut makes persistent agents more plausible, but only if you design prompts for reuse and measure real cache hits. See the Fable 5.1 developer guide for specs, access, and deployment boundaries.

3. VS Code separates portable agent sessions from portable agent extensions

VS Code 1.135 brings two related ideas into focus: a dedicated Agent Host for persistent sessions and Agent Plugins 1.0 for packaging reusable agent capabilities.

The distinction matters:

Layer	What it standardizes
Agent Host Protocol (AHP)	Communication between an agent host and clients that display or control sessions
Agent Plugins 1.0	Packaging for portable skills and MCP server configuration
MCP	Connections from agents to external tools and data

Microsoft's Agent Host architecture moves supported agent runtimes into a dedicated process. A session can continue independently of the editor window, multiple clients can stay synchronized, and the host can run beside a remote workspace. Copilot, Claude, Codex, and other harnesses can keep their own agent loops while adapters expose a common session model.

AHP is open and uses JSON-RPC, but it does not make every agent interchangeable. The protocol standardizes the client-facing session, not reasoning, context management, permissions, or tool behavior. Microsoft's documentation also says the Agent Host and AHP remain under active development.

Agent Plugins 1.0 solves a different portability problem. The official plugin documentation defines a root plugin.json, skills under skills/, and portable MCP configuration in mcp.json. Client-specific commands, custom agents, rules, and hooks can live in reverse-domain namespaces that unsupported clients ignore.

That is a useful compatibility boundary. Skills and MCP servers can travel between compatible clients, while hooks and interface-specific behavior remain explicitly client-specific. VS Code continues to recognize Copilot, Claude, and legacy OpenPlugin layouts, so existing packages do not have to migrate immediately.

My take: Do not collapse AHP, Agent Plugins, and MCP into one “universal agent standard.” Together they cover session transport, extension packaging, and tool connectivity. Separately, each has a narrower contract developers can actually test. Our VS Code Agent Host and Agent Plugins 1.0 guide maps the formats and portability limits in detail.

4. Copilot content exclusions finally reach the app and CLI

GitHub made content exclusions generally available in the GitHub Copilot app and Copilot CLI on September 2. Enterprise, organization, and repository administrators can configure excluded paths that those agentic clients will not use as context.

Content exclusion was already generally available in IDE integrations. Extending it to the desktop app and terminal closes a practical governance gap: the same developer could previously move from an IDE surface with exclusions into a more autonomous client whose context controls differed.

The GitHub announcement says availability is limited to Copilot Business and Enterprise customers. Teams should verify effective rules at all three scopes rather than assuming an IDE policy automatically covers every client.

Exclusion is a context boundary, not a complete security boundary. An agent can still encounter secrets in command output, generated files, dependency logs, external tools, or data copied into a prompt. Repository permissions, sandboxing, secret scanning, and pull-request review remain necessary.

My take: This is not flashy, but it may be the most immediately actionable release of the week for enterprise teams. Inventory which Copilot surfaces developers use, test exclusions with canary files, and document what the rules do not cover. The broader GitHub Copilot app guide explains the app's workspace and pull-request boundaries.

Quick hits

IBM Granite 4.2 8B: IBM released an Apache-2.0 dense reasoning model with 128K context and selectable thinking modes. It is a practical self-hosting candidate, but IBM's announcement does not by itself confirm a matching managed watsonx endpoint. See our Granite 4.2 8B guide.
Mercury 2.5 Preview: Inception opened early access to a 260K-context diffusion language model with an OpenAI-compatible API. The preview status and provider-specific promotional pricing make it an evaluation target, not a frozen production dependency. See our Mercury 2.5 Preview guide.
Copilot code review approvals: GitHub now lets Copilot code review approve pull requests when it finds no blocking issues. Treat an AI approval as one signal in branch protection, not a substitute for required human review on sensitive repositories.

That's it for this week. Next Thursday: early production cost data for Gemini 3.8 Flash, whether Fable 5.1's cache savings hold up in real agent loops, and which clients adopt the new plugin format.

Want this in your inbox? Subscribe to AI Dev Weekly.

Previous issue: AI Dev Weekly #23

FAQ

Is Gemini 3.8 Flash ready for production?

Yes. Google labels gemini-3.8-flash generally available with a stable model ID. Individual capabilities such as computer use remain in preview, and introductory pricing ends on December 31, 2026.

Did Claude Fable 5.1 get cheaper?

Base input and output prices are $10 and $50 per million tokens. Cache reads fell to $0.25 per million tokens, so workloads that repeatedly reuse large cached prefixes can become materially cheaper. Measure your own hit rate before assuming Anthropic's estimated savings.

Are Agent Plugins 1.0 the same thing as MCP?

No. Agent Plugins package skills and MCP server configuration. MCP defines how an agent connects to tools and data. A plugin can contain MCP configuration, but the standards solve different problems.

Do Copilot content exclusions prevent all secret exposure?

No. They keep configured files from being used as Copilot context in supported clients. They do not replace repository permissions, sandboxing, secret scanning, output filtering, or code review.

- GitHub Copilot App Guide

Originally published at https://www.aimadetools.com

AI Dev Weekly #23: Qwen4 Architecture Preview, GPT-5.6 Lands in Kiro, Gemini Takes On Whisper

Joske Vermeulen — Thu, 27 Aug 2026 08:19:38 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

Four stories this week. Alibaba open-sourced an early look at the architecture it plans to use for Qwen4. OpenAI put the full GPT-5.6 family inside AWS's Kiro coding agent. Google launched dedicated recorded and realtime transcription models. And GitHub moved Copilot's cloud agent out of the IDE and into the Slack and Microsoft Teams conversations where work starts.

1. Qwen3.8-Flash-Next is really a public preview of Qwen4

Alibaba released Qwen3.8-Flash-Next on August 26 and opened its weights on Hugging Face and ModelScope. The name sounds like another incremental Flash release, but the more important detail is architectural: Qwen says this model previews the design that will underpin Qwen4.

The official Qwen release describes four areas of change:

attention;
residual connections;
embeddings;
training optimization.

It is a multimodal mixture-of-experts model and continues Qwen's strategy of releasing a smaller architecture-preview model before rolling the design into the wider family. Qwen3-Next played that role before the Qwen3.5 through Qwen3.8 generations; Flash-Next is the equivalent early look at Qwen4.

Why this matters: Open weights turn an architecture announcement into something the community can inspect, serve, quantize, and benchmark. That is more useful than a closed preview with vendor charts alone. It also gives inference projects time to add support before the larger Qwen4 models arrive.

My take: Do not read “Qwen4 preview” as “Qwen4 is available.” This is an early architecture vehicle, not the finished flagship family. But it is still the most technically interesting release of the week because developers can examine the actual model rather than wait for a product announcement. If you deploy Qwen today, treat Flash-Next as an evaluation target, not an automatic replacement for Qwen 3.8 Max or a proven production model.

2. GPT-5.6 Sol, Terra, and Luna land in Kiro

OpenAI and AWS added the complete GPT-5.6 family to Kiro on August 24. Developers can now choose Sol, Terra, or Luna inside Kiro's spec-driven workflow instead of treating Kiro as a model-specific coding environment.

The practical mapping is straightforward:

Model	Best fit inside Kiro
GPT-5.6 Sol	Hard architecture, debugging, and long-running implementation work
GPT-5.6 Terra	Daily feature work where cost and capability both matter
GPT-5.6 Luna	High-volume routine changes, tests, and repetitive tasks

OpenAI's official Kiro announcement says Terra completed successful Terminal-Bench 2.1 tasks in Kiro at roughly 82% lower cost in joint testing. That is a vendor-reported environment-specific result, not proof that Terra is universally 82% cheaper than other models. Kiro's structured requirements and technical designs are part of the measured setup.

The more durable change is model choice at each phase of a task. A team can use a lower-cost model for planning or mechanical implementation and reserve Sol for the places where deeper reasoning changes the outcome.

My take: This is less about another model picker and more about Kiro becoming a neutral orchestration layer. AWS letting OpenAI models compete inside its own coding agent is good for developers. The cost claim needs independent validation, but the ability to match model cost to task difficulty is immediately useful. See our GPT-5.6 in Kiro comparison for the detailed decision guide.

3. Gemini 3.5 Transcribe takes on Whisper with recorded and live APIs

Google now documents two dedicated speech-to-text models:

gemini-3.5-transcribe for recorded audio;
gemini-3.5-transcribe-live for realtime WebSocket sessions.

This is not just “send an audio file to a general Gemini model.” The transcription endpoints have their own feature matrix, limits, and pricing. Google's recorded transcription documentation includes automatic language detection across 85+ languages, code switching, custom vocabulary, speaker diarization, and word timestamps.

There are important boundaries:

recorded audio supports up to one hour, or 30 minutes when using diarization or word timestamps;
the live endpoint uses ten-minute sessions;
live transcription does not currently provide speaker diarization or word-level timestamps;
smart formatting cannot be combined with diarization or word timestamps on recorded jobs.

Google estimates blended token costs at roughly $0.005 per recorded minute and $0.009 per live minute, though actual billing follows token usage rather than a guaranteed flat per-minute rate.

My take: Gemini wins when you want a managed API with built-in language switching, vocabulary hints, diarization, and a supported live path. Whisper still wins when audio must remain local, the application must work offline, or you want full control over deployment and retention. We published a full Gemini 3.5 Transcribe vs Whisper architecture comparison rather than pretending one option is universally better.

4. GitHub Copilot moves into Slack and Microsoft Teams

GitHub launched public previews that let teams start shared Copilot cloud-agent sessions from Slack or Microsoft Teams. Mention @GitHub in a supported conversation and the agent can investigate a problem, update issues, implement changes in a cloud sandbox, validate the result, and open a pull request.

The key change is not chat integration. It is shared agent work:

the original conversation supplies context;
teammates can inspect and redirect the session;
the work continues asynchronously;
the resulting pull request links back to the conversation;
repository permissions still bound what the agent can access;
administrators can require an extra approval for agent-authored pull requests.

The Slack preview is limited to Copilot Business and Enterprise organizations. The Teams preview is available with paid Copilot plans, consumes AI credits, and bills cloud sandbox usage separately.

My take: This is where coding agents were heading: the request starts in a stand-up or incident thread, not in an empty IDE chat. The risk is that an informal conversation becomes executable scope without enough review. Keep the pull request as the approval boundary, require extra approval for agent-authored work, and watch both AI-credit and sandbox budgets. For the broader product context, see our GitHub Copilot app guide.

Quick hits

GLM-5.3-Flash weights shipped: Z.ai released a 320B-total, 18B-active multimodal MoE under MIT, with support documented for SGLang, vLLM, TokenSpeed, and KTransformers. The full GLM-5.3 weights remain a separate release.
GPT-5.6 Sol promotion: OpenAI reduced Sol API and credit pricing for three months. Treat the promotional and list prices separately in cost models.
Markdown for agents: Cloudflare can now serve a Markdown representation when an enabled site receives Accept: text/markdown. It is HTTP content negotiation, not a new agent protocol and not a replacement for MCP or A2A.

That's it for this week. Next Thursday: early community results for Qwen3.8-Flash-Next, whether GLM-5.3's full weights arrive as announced, and the first practical reports from shared Copilot sessions.

Want this in your inbox? Subscribe to AI Dev Weekly.

Previous issue: AI Dev Weekly #22

FAQ

Is Qwen3.8-Flash-Next the same as Qwen4?

No. It is an open-weight model that previews architectural changes Qwen plans to use in Qwen4. The finished Qwen4 family has not launched through this release.

Which GPT-5.6 model should I use in Kiro?

Use Luna for high-volume routine work, Terra for the default balance of capability and cost, and Sol when difficult reasoning or architecture work justifies the premium. Validate that split on your own repository rather than assuming one model should run every task.

Does Gemini 3.5 Transcribe replace Whisper?

Not universally. Gemini reduces integration and operations work and adds managed transcription features. Local Whisper preserves offline operation and infrastructure control. Privacy, volume, latency, and required annotations decide the better fit.

Can Copilot merge code directly from Slack or Teams?

The agent can implement and validate work in a cloud sandbox and open a pull request. Repository permissions and branch protections still apply, and administrators can require an additional approval for agent-authored pull requests.

- GitHub Copilot App Guide

Originally published at https://www.aimadetools.com

I Let an AI Agent Run a SaaS Like a Solo Founder. It Made the Same Mistakes Humans Make.

Joske Vermeulen — Fri, 21 Aug 2026 09:40:47 +0000

I expected the audit to find broken code. That's what I was bracing for going in — a pile of half-working features, sloppy logic, the kind of mess you'd assume from software built at maximum speed with no human reviewing every line. That's not what I found. Almost everything Claude built actually worked, taken piece by piece. What I found instead was something I didn't expect at all: the agent had made the exact same mistakes I've watched human startup teams make, over and over, when they move fast and nobody's job is to say no.

That's the real story here, and it's more interesting than "AI wrote bad code" would have been.

The experiment

The project is called GetPricePulse — a SaaS pricing intelligence product. It's Claude's entry from The $100 AI Startup Race, the season-long challenge I run where seven AI agents each get $100 and full autonomy to build a real startup from scratch, with no human coding and no product manager in the loop. Each agent picked its own idea and ran with it. Claude picked SaaS pricing intelligence, named it PricePulse, and kept building on it for the entire race.

That "no product manager in the loop" part is the thing that made this interesting to watch. Nobody was deciding what PricePulse should be. Nobody was saying "we have enough pricing tiers now" or "this feature doesn't belong here." Claude got to build exactly what its own priorities told it to build, at whatever speed it chose, for the length of the race — optimizing, as far as I could tell from the commit history, for speed, feature creation, shipping, and monetization experiments. Not correctness. Not coherence. Not "does this still make sense in three weeks."

I've written before about what all seven agents in this race said, independently, when I asked them what AI agents still can't do — they converged on the same answer without seeing each other's responses. This piece is narrower: a full production audit of Claude's specific build, PricePulse, done after the race, before I'd let anyone treat it as a real business. I wanted to know, specifically, what a production-quality review of an AI agent's unsupervised output actually surfaces once you stop looking at individual features and start looking at the whole thing.

By the time I ran the audit, Claude had produced:

More than 1,300 HTML files
Hundreds of content pages
A pricing database
Calculators
Monitoring features
Full authentication
Stripe payment integration
Email infrastructure

That's a genuinely large amount of software for a single agent to produce. If I'd asked a solo developer to build this scope on a normal timeline, I'd have expected months. Claude did it across the race's running sessions. My honest first reaction, watching it accumulate week over week in the race results, was that I was more impressed than I expected to be.

I expected broken code. I found something else.

Here's where I have to be honest about my own assumption going into the audit. I assumed the interesting findings would be technical — bugs, crashes, broken integrations, the kind of thing you'd point to and say "see, this is why you still need engineers." I was ready to write that article.

What the audit actually surfaced was mostly not that. Individually, almost everything worked. Authentication let people sign up and log in. Stripe processed at least one pricing tier correctly. The pricing database was real, not placeholder content. The calculators worked. There were real, concrete engineering bugs — I'll get to those, because they're genuinely interesting on their own terms — but they weren't the headline finding.

The headline finding was this: the biggest problems weren't in any single feature. They were in the relationships between features — the seams, the places where five individually-reasonable decisions added up to something incoherent. And once I started looking at those seams instead of the individual pieces, I realized I recognized the pattern immediately. I'd seen it before. Not in AI-built software. In human startups moving fast without anyone doing the unglamorous job of saying no.

The five human startup mistakes Claude reproduced

This is the part I didn't expect, and it's the actual thesis of this piece: the mistakes weren't AI mistakes. They were startup mistakes. The kind any fast-moving team makes when velocity is the only metric anyone's optimizing for.

1. Too many products stapled into one

By the time the race ended, PricePulse had quietly become five different products sharing one codebase: a SaaS pricing publication/database, a monitoring SaaS, a FinOps toolkit, a competitive intelligence product, and a lead generation system. None of these were bad ideas individually. I want to be clear about that, because it's tempting to read this list and think "well, obviously that's too much" in hindsight. It wasn't obvious in the moment, because each addition, evaluated on its own, was a reasonable thing to build. Add a monitoring feature: reasonable. Add a FinOps calculator: reasonable. Add lead capture: reasonable.

What was missing was the thing that has nothing to do with any single decision: someone whose job was to look at the growing list and say "this is what we are, and this is what we are not." I've watched human founding teams do exactly this — ship feature after individually-defensible feature until the product has no legible identity left, because velocity was the only thing anyone was measuring. Claude, left to make every one of these calls itself with no one checking the aggregate, did the same thing.

2. Too many monetization experiments running at once

Before cleanup, GetPricePulse simultaneously offered a $9 lifetime deal, a $49 lifetime deal, a $99 "founding member" deal, regular monthly plans, and multiple different checkout paths for each. Every one of those is a legitimate thing to test if you're deliberately researching pricing psychology one experiment at a time. Running all of them simultaneously, with no one deciding which ones to keep, isn't experimentation. It's accumulation.

And accumulation has real costs, not just messaging confusion. Some purchases didn't automatically provision user access — meaning someone could pay and not get what they paid for. Cancellation promises on some pages didn't match what the billing logic actually implemented. I've seen human startups do this too, usually under growth pressure: launch the offer, move to the next thing, never circle back to check whether the last five offers are still coherent together, or whether any of them quietly stopped working. Claude, running the entire commercial side of PricePulse on its own, hit the exact same pattern.

3. No one owned the long-term vision

This is the throughline connecting the first two mistakes, and it's worth naming directly rather than leaving implicit. Every individual decision Claude made had local logic. Nothing was wrong in isolation. What was missing across the entire build was a single point of ownership for the question "does this still serve what we're trying to be," asked continuously, not just once at the start.

Human startups fail this exact test constantly — not because founders are careless, but because the question doesn't have a natural trigger. Nothing forces you to ask it. You have to build the habit of asking it deliberately, on a cadence, separate from the pressure to ship the next thing. Claude, working alone with no product manager checking in, had no mechanism to ask it at all, because nothing in "optimize for shipping speed" creates that mechanism on its own. That's not a flaw specific to AI. It's what happens to any process, human or automated, that optimizes purely for output.

4. Trust erosion through overconfident claims

Content across the site described "real case studies," exact savings figures, and benchmark statistics, all written with the specific confidence of verified outcomes. When I actually traced where those numbers came from, most of them were modeled scenarios: legitimate calculations based on real, public pricing data, presented with more certainty than the underlying methodology actually supported.

I want to be precise about what this is and isn't, because it's easy to overstate. Claude didn't fabricate numbers from nothing. It calculated real estimates from real inputs. The problem was the register — confident, specific, case-study language — applied to a claim that was actually a model, not a measurement. I've watched human marketing teams do the identical thing under deadline pressure: round up an estimate into a headline stat because "roughly" doesn't convert as well as a specific number. The fix wasn't less impressive content. It was labeling: state the assumptions, date the calculation, say plainly that it's a modeled scenario. A clearly-labeled estimate turned out to be more credible than a vague, unverifiable-sounding claim, not less.

5. Fragmentation that only shows up when you stop looking at pieces

Different sections of the site — company pages, the blog, the tools — each had their own navigation, because each had effectively been built as its own product across different sessions, without a consistent structure enforced across them. Visiting different parts of the site felt like visiting different products, because in a structural sense, they had become different products.

This is the mistake I find most instructive, because it's genuinely invisible if you only ever review things one at a time — which is exactly how fast building naturally happens, whether the builder is a human team shipping under deadline or an agent working through a queue of tasks across many sessions. You review the page you just built. It looks fine. You ship it. You move to the next one. Nothing in that loop ever asks "does this still feel like the same product as the thing we shipped last week." That question only gets asked if someone deliberately steps back from the individual artifacts and looks at the system they're supposed to form together. Most fast-moving builders — human or AI — don't build that step in by default. It has to be added on purpose.

What AI agents are actually good at

I don't want this piece to read as "AI made human mistakes, therefore AI is just as flawed as humans, so what's the point." That's not the conclusion, and it undersells something real: the sheer volume and functional quality of what got produced here would be genuinely difficult for a human team to match on this timeline.

The database was real and substantive, not scaffolding. The calculators worked correctly. The core Stripe integration processed real transactions on at least one pricing tier without issue. The authentication system, once one specific bug was fixed, worked exactly as authentication should. Over a thousand pages of content, most of which held up reasonably well on a page-by-page basis. That's execution. Fast, high-volume, mostly correct execution — and execution is the thing AI agents are genuinely, remarkably good at right now.

The engineering bugs that did surface are worth naming specifically, because they're a different category of problem than the five mistakes above — they're not judgment failures, they're the kind of bug any team moving fast produces, and they're worth understanding on their own terms.

The signup button was broken because of a naming collision: the code declared a local variable const supabase, while the Supabase browser library already used the global window.supabase. That collision caused a JavaScript failure before the authentication request ever fired. Nothing in the UI hinted at why — it just looked like a broken button. The fix, once found, was mechanical: rename the local variable to supabaseClient consistently across signup, login, dashboard, settings, and password reset pages.

Logged-in users appeared logged out when browsing public pages — not because sessions were broken, but because public pages simply never checked authentication status at all. The session was fine the entire time. The fix added shared auth-status handling across 225 pages, so a logged-in user consistently sees "Dashboard" instead of "Start free" everywhere, not just on the pages someone remembered to wire up.

And the annual Stripe pricing tier was fully coded, but the Stripe price object it depended on had never actually been created on Stripe's side. The code was correct. The integration was incomplete for reasons entirely outside the code — a missing piece of external configuration, not a logic error.

I bring these up specifically because they're not evidence that AI writes bad code. They're evidence that any team building fast, without a dedicated second pass looking specifically for this category of thing, ships this category of bug. That's true whether the builder is an AI agent or a human developer.

What humans still need to do

Here's where I land, after actually looking closely at what the audit found: AI agents are, right now, extremely good at execution and have essentially no built-in mechanism for judgment. Not because judgment is beyond their capability in some deep sense — but because nothing about optimizing for "ship features fast" creates a reason to ask "should we," as opposed to "can we." Those are different questions, and only one of them gets asked by default when the optimization target is pure output.

The judgment work that had to happen after the fact, in this case, was specific and namable: deciding what the product actually is, in one sentence, and making everything else subordinate to that sentence. Deciding which monetization experiments earn a permanent place and which were just experiments that should have ended. Labeling confident-sounding content honestly, based on what evidence actually backs it. Auditing the relationships between pages, not just the pages themselves — navigation, search coverage, internal linking, all the structural connective tissue that never shows up when you review one artifact at a time. And verifying, directly, that every integration a codebase assumes exists — a valid API key, a created Stripe price object, a check for authentication status — actually exists and actually works, rather than trusting that "the code looks right" means "the system works."

None of that is engineering work in the traditional sense. It's product management work, and it turns out to be exactly as necessary for a fast AI-built product as it is for a fast human-built one. Claude didn't fail at its job. The job, as I'd set it up for the race, simply didn't include this layer.

The new AI development workflow

If I had to state the practical shift this experiment convinced me of, it's this: the ratio of building to reviewing has flipped, and most people building with AI agents haven't adjusted their workflow to reflect that.

The old assumption, from years of writing software by hand, was something like 80% building, 20% review. Building was the expensive, slow part. Review was the cheap check at the end. That ratio made sense when building was the bottleneck.

Building is no longer the bottleneck. AI agents can produce, in hours, what used to take weeks. What hasn't gotten any cheaper — what may have actually gotten more important — is the judgment layer: deciding what should exist, verifying that what exists actually works end-to-end, and making sure a thousand individually-reasonable decisions still add up to one coherent thing. If building used to be 80% of the effort, I think the realistic ratio now looks more like 20% building, 80% deciding, structuring, and verifying. Not because AI builds badly. Because building got so much cheaper that it stopped being the part that determines whether you end up with a real product.

That's not a smaller role for humans in this process. It might be a bigger one, just relocated to a different part of the timeline — moved from "writing the code" to "deciding what deserved to be built and confirming it actually works," which was always the harder, less mechanical half of the job anyway.

What happened after the experiment

None of this stayed theoretical. Once the audit identified what was wrong, the fixes were mostly about subtraction and connection, not rebuilding. PricePulse got a single-sentence identity — a SaaS pricing intelligence publication and database, with monitoring demoted to a labeled beta feature instead of a co-equal pillar. The pricing model collapsed from a tangle of lifetime deals and founding-member offers down to Free, a $19/month or $190/year Starter tier, and a Pro tier explicitly marked as coming later. The modeled-scenario content got relabeled honestly, with assumptions and calculation dates visible instead of implied case-study confidence. Navigation got standardized across all 201 company pages, and site search went from covering 68 records to the full 201. The auth bug got fixed, the missing Stripe price object got created, and the email systems got trimmed down to what a real product actually needs.

None of that required starting over. Almost everything Claude built stayed exactly as it was — the database, the calculators, the core integrations. What changed was the layer on top: one clear identity, one trustworthy commercial model, honestly labeled content, and a structure where all 1,300+ pages actually connect to each other instead of just existing near each other. The raw material didn't need to be replaced. It needed a decision-maker.

Final conclusion

I went into this audit expecting to write about AI's limitations as a builder. I came out of it having to revise that framing almost entirely. Claude built fast, and the vast majority of what it built individually worked. What it reproduced, without anyone intending it, was a set of mistakes I recognize immediately from years of watching human teams move fast without a dedicated product owner: too many products stapled together, too many unmanaged monetization experiments, no one owning the long-term coherence of the thing, content that oversold its own certainty, and structural fragmentation invisible from inside the building process.

None of that means AI agents can't build real software. The evidence in front of me says the opposite — Claude was considerably more capable at execution than I expected going in, and the fixes afterward proved that out: the raw material was good enough that a relatively small amount of human judgment turned it into something coherent, without throwing any of it away. That's the actual shape of the story: not "AI failed and humans saved it," but "AI did the expensive part cheaply, and humans did the part that was never going to get automated away."

I came out of this more convinced that AI agents are a genuine force multiplier for building software, not a replacement for the judgment that makes software into a product. Claude did in weeks what would have taken a solo developer months, and everything it produced remained useful raw material after the audit — none of it got thrown out, all of it got organized around a decision a human made. The lesson isn't that you need less AI or more caution before starting. It's that the faster the building gets, the more the outcome depends on someone doing the deciding — and that's a role for a person, working alongside the agent, not a reason to slow the agent down.

We Let AI Agents Build a SaaS. The Cleanup Was the Real Work. — the full technical audit and every concrete fix
We Built 1,300 Pages With AI. The Biggest Problems Were Not SEO — the information architecture and search coverage findings in depth
7 Things AI Coding Agents Don't Understand About Real Products — a concrete checklist version of these lessons
AI Agents Are Great Employees. They Still Need Product Managers. — the product management angle, argued directly
What AI Agents Cannot Do: The Lesson from 7 Failed Startups — all seven race agents, including Claude, independently reaching the same conclusion about their own limitations

- An AI Built Everything, Got Every Channel, Still Made $0 — GLM's entry in the same race, a similar pattern of shipping volume without anyone checking whether it added up to a coherent product

Originally published at https://www.aimadetools.com

AI Dev Weekly #22: Claude Code Auto Mode Goes Live, Stripe Buys OpenRouter for $7.5B, GLM-5.3 Ships

Joske Vermeulen — Thu, 20 Aug 2026 12:00:08 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

Four stories this week. Claude Code quietly stopped asking permission before most tool calls. Stripe closed one of the largest AI infrastructure acquisitions of the year. Zhipu shipped a model that matches Kimi K3 on price-adjusted performance. And SpaceX's Cursor acquisition became official the same week Grok 4.6 landed with a new top-tier reasoning mode.

1. Claude Code auto mode is now the default — here's what actually changed

Starting August 14, new Claude Code sessions on Pro, Max, and Team plans open in auto mode by default, per Anthropic's own announcement. Instead of approving every file write or shell command yourself, each tool call now routes through a separate classifier model that decides whether the action is safe to run without asking you.

What's confirmed:

Applies to Pro, Max, and Team plans. Enterprise, the Claude API, and cloud-partner deployments (Bedrock, Vertex, Foundry) stay opt-in for now.
If you already set a different permission default yourself, that choice is preserved — you'll get a one-time prompt asking if you want to switch, but it won't be overridden silently.
In Anthropic's own controlled study, human reviewers manually approving each action missed 143 of 1,053 planted dangerous commands. The classifier caught 937 of them, per reporting on Anthropic's study (via implicator.ai).

My take: The classifier catching more dangerous commands than human reviewers is a genuinely useful data point, but it's Anthropic's own study measuring Anthropic's own classifier — worth independent validation before treating "937 out of 1,053" as the last word on how safe auto mode is in practice. The bigger practical question is whether it changes your workflow at all: if you already picked --auto-edit or a custom permission mode, nothing changes for you. If you've been running default Claude Code on Pro/Max/Team, this is a genuine behavior shift you should know is happening, not something to discover mid-session. Check your permission mode with /permissions if you're not sure which one you're on.

2. Stripe closes its OpenRouter acquisition at $7.5B+

Stripe confirmed on August 19 that it has closed its acquisition of OpenRouter, the AI model routing layer used by developers to access 400+ models through one API. Reported deal size varies by outlet — Bloomberg and CNBC put it above $7 billion, Forbes cites over $8 billion, and the Wall Street Journal had earlier reported talks around $10 billion. What's consistent across all reporting: this is roughly 6x OpenRouter's own $1.3 billion valuation from a funding round less than three months earlier, in May 2026.

Why Stripe: OpenRouter sits at the layer between applications and every major AI model — Stripe's stated interest is in tokens becoming a spend category it can process and route the same way it processes card payments. Multiple outlets frame this as Stripe extending its infrastructure bet from money movement to AI-token movement.

What it doesn't change today: OpenRouter's API, pricing, and model catalog continue operating as-is. No changes to the developer-facing product have been announced alongside the acquisition close.

My take: If you route model calls through OpenRouter (and a lot of the setups we cover here do), the acquisition itself isn't an action item yet — but it's worth watching for two things over the next few months: whether OpenRouter pricing or model access changes under Stripe ownership, and whether Stripe bundles OpenRouter access into its existing payments/billing products in a way that changes how you'd integrate it. Nothing to do today beyond noting who now owns a piece of infrastructure a lot of us depend on. See our OpenRouter complete guide if you haven't set it up yet.

3. GLM-5.3: same base model, matches Kimi K3 through post-training alone

Zhipu AI (Z.ai) released GLM-5.3 on August 14, and the interesting part isn't the benchmark number, it's how they got there. Per multiple outlets covering the release (felloai.com, qubrid.com), GLM-5.3 runs on the same 744-billion-parameter base as GLM-5.2 — no new pretrain, no architecture change. Every reported gain comes from extended post-training.

The numbers:

Artificial Analysis Intelligence Index: 60, matching Kimi K3 and one point behind GPT-5.6 Sol
Cost per task: $0.68 (per Artificial Analysis, via the-decoder.com), 1.5x GLM-5.2's $0.44 but 19% cheaper than Kimi K3's $0.84
API pricing: $1.40 input / $4.40 output per million tokens — unchanged from GLM-5.2
Access: live via API and the GLM Coding Plan (starting $18/month); public weights delayed to roughly August 28

My take: A model getting meaningfully better through post-training alone on an unchanged base is a genuinely useful data point about where the easy gains are right now in the open-model race — it suggests there's still headroom in post-training that doesn't require a new pretrain cycle, which is cheaper and faster to iterate on. The catch is the same one we've flagged before with fast-moving Chinese model releases: API access and a coding plan are live today, but the open weights that let you self-host or independently verify the claims aren't out until the end of the month. If self-hosting is the point for you, this is a "wait two weeks" release, not a "switch today" release.

4. Cursor's SpaceX deal closes officially, same week as Grok 4.6

SpaceX officially closed its $60 billion acquisition of Cursor this week, an acquisition that had been reported and discussed for months but became final now — and almost simultaneously, xAI (now SpaceXAI) released Grok 4.6, explicitly positioned around long-running agentic and coding work.

We've already covered Grok 4.6 in detail: same $2/$6 pricing and 500K context as Grok 4.5, plus a new xhigh reasoning tier and broad benchmark gains on xAI's own reporting (see the full Grok 4.6 guide for what's verified vs. not). The timing with the Cursor deal closing isn't a coincidence — Grok 4.5 was already the first model co-trained directly with Cursor's engineering team, and 4.6 continues that relationship now that the acquisition is formally done rather than pending.

My take: Nothing changes for existing Grok/Cursor users this week specifically — pricing and access are the same as they were under Grok 4.5. What's worth watching is whether SpaceXAI now leans harder into Cursor-exclusive features now that the deal is no longer "pending," the way Meta's Muse Code leans on data-sharing pricing tiers. If you're a Cursor user who picked it partly for the Grok integration, that bet looks more durable now that the acquisition is actually closed rather than reported-but-not-final.

That's it for this week. Next Thursday: whether GLM-5.3's open weights actually ship on schedule, early reports on how auto mode performs at scale in Claude Code, and whatever else breaks.

Want this in your inbox? Subscribe to AI Dev Weekly.

Previous issue: AI Dev Weekly #21

FAQ

Does Claude Code auto mode affect me if I'm on the free tier or API?

No. The August 14 default change applies to Pro, Max, and Team plan sessions only. Claude API access, Enterprise plans, and cloud-partner deployments (Bedrock, Vertex, Foundry) remain opt-in for auto mode.

Is GLM-5.3 open source?

The API and GLM Coding Plan are live now. Public weights are expected around August 28, 2026 — not available at the time of this issue.

What happens to OpenRouter now that Stripe owns it?

No announced changes to OpenRouter's API, pricing, or model catalog as of the acquisition close on August 19. Worth monitoring, not something requiring action today.

Is Grok 4.6 different now that the Cursor deal is closed?

Not in pricing or specs — those are unchanged from when Grok 4.6 launched. The deal closing formalizes a relationship that was already shaping Grok's development (Cursor co-training started with Grok 4.5).

- AI API Pricing Compared 2026

Originally published at https://www.aimadetools.com

KAT-Coder V2.5 Local Setup Guide: GGUF, vLLM, SGLang

Joske Vermeulen — Thu, 06 Aug 2026 14:29:35 +0000

KAT-Coder V2.5-Dev is an open-weight coding model from Kwaipilot (Kuaishou's AI team) that scores 69.40% on SWE-bench Verified while activating only 3 billion parameters per token. The full model has 35 billion total parameters in a sparse Mixture-of-Experts architecture, but the MoE routing means only 3B are active for any given inference step.

This matters for local deployment: the model's computational requirements during inference are closer to a 3B dense model than a 35B one, though you still need enough memory to hold all 35B weights. With GGUF quantization, that becomes manageable on consumer hardware.

The model is Apache 2.0 licensed, text-only (vision weights are not included in the open release), and designed specifically for agentic coding tasks: working inside repositories, using tools, and fixing real bugs across multi-file projects.

What is KAT-Coder V2.5-Dev?

Spec	Value
Creator	Kwaipilot (KwaiKAT Team, Kuaishou Technology)
Base model	Qwen3.6-35B-A3B
Architecture	Sparse MoE, 256 routed experts (top-8 + shared expert)
Total parameters	35B
Active parameters	3B per token
Attention	30/40 layers use GatedDeltaNet linear attention
Context window	262,144 tokens (native), extensible via YaRN
License	Apache 2.0
Modality	Text-only (vision weights not released)
Thinking mode	Default on (can be disabled)
Technical report	arxiv.org/abs/2607.05471

Kuaishou is a major Chinese technology company (short-video platform, publicly traded). Kwaipilot is their internal AI coding team that has been developing the KAT-Coder series since 2025.

Benchmark context

Reported benchmarks from the official model card, reproduced in-house by Kwaipilot using standardized evaluation pipelines:

Benchmark	KAT-Coder V2.5-Dev	Qwen3.5-27B	Qwen3.6-35B-A3B (base)	Ornith-1.0-35B
SWE-bench Verified	69.40%	68.60%	64.40%	55.80%
SWE-bench Multilingual	63.00%	57.67%	57.00%	51.67%
SWE-bench Pro	45.96%	42.13%	40.63%	34.47%
Terminal-Bench 2.1	41.02%	34.83%	42.76%	33.10%

Important caveats:

These scores are self-reported by Kwaipilot, not independently verified by a third party.
Evaluation used claude_code@2.1.195 as the agent harness with pass@1, temperature=1.0, 256K context.
The comparison models were also tested by Kwaipilot (not official numbers from those model providers).
Benchmarks measure agentic coding capability (working in repos with tools), not raw code completion. Real-world coding productivity does not map linearly to benchmark percentages.
Terminal-Bench 2.1 score (41.02%) is notably lower than frontier closed models (Sol: 88.8%, Opus 5: 86.7%).

The 69.40% SWE-bench Verified is strong for a model in this size class. It significantly outperforms its base model (Qwen3.6-35B-A3B at 64.40%), showing the value of Kwaipilot's post-training (SFT + RL on 127K examples).

Hardware requirements

The 35B total / 3B active architecture creates an unusual hardware profile: you need memory for 35B weights but compute for roughly 3B.

Full precision (BF16)

Setup	VRAM	GPUs	Context
Single GPU	~70GB	1x A100 80GB or H100	Limited context
Tensor parallel (recommended)	8x GPUs	8x A100/H100	Full 262K context

Full precision requires serious hardware. The official documentation shows tensor parallel across 8 GPUs for production deployment.

GGUF quantized (consumer hardware)

Community quantizations from bartowski make consumer deployment realistic:

Quantization	File size	RAM needed	Quality
Q8_0	~37GB	40GB+ RAM	Near-lossless
Q6_K	~28GB	32GB+ RAM	Very high quality
Q5_K_M	~25GB	28GB+ RAM	High quality
Q4_K_M	~20GB	24GB+ RAM	Good quality
Q3_K_M	~16GB	20GB+ RAM	Acceptable
IQ4_XS	~18GB	22GB+ RAM	Good (imatrix)

Practical consumer hardware:

24GB VRAM GPU (RTX 4090): Q4_K_M fits, with limited context window
32GB unified memory (M2/M3/M4 Mac): Q5_K_M or Q6_K via MLX
64GB RAM (CPU inference via llama.cpp): Q6_K or Q8_0, much slower

MLX on Apple Silicon

A 6-bit MLX quantization is available for Apple Silicon Macs. A Mac with 32GB+ unified memory can run this at reasonable speeds for code generation tasks.

How to run KAT-Coder V2.5-Dev locally

Method 1: llama.cpp / GGUF (consumer hardware)

The most accessible method for consumer GPUs and Macs.

# Download the GGUF (choose quantization based on your RAM)
# From: huggingface.co/bartowski/Kwaipilot_KAT-Coder-V2.5-Dev-GGUF

# Using llama.cpp server
./llama-server \
  -m KAT-Coder-V2.5-Dev-Q4_K_M.gguf \
  --port 8080 \
  -ngl 99 \
  -c 32768

# The model is now accessible via OpenAI-compatible API at localhost:8080

For Macs with Metal acceleration, add -ngl 99 to offload all layers to GPU. Adjust -c (context length) based on available memory.

Method 2: vLLM (GPU server)

For multi-GPU servers with full-precision deployment. Requires the --language-model-only flag because vision weights are not included.

pip install vllm

vllm serve Kwaipilot/KAT-Coder-V2.5-Dev \
  --port 8000 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --reasoning-parser qwen3 \
  --language-model-only

For tool-use support (agentic coding):

vllm serve Kwaipilot/KAT-Coder-V2.5-Dev \
  --port 8000 \
  --tensor-parallel-size 8 \
  --max-model-len 262144 \
  --reasoning-parser qwen3 \
  --enable-auto-tool-choice \
  --tool-call-parser qwen3_coder \
  --language-model-only

Important: vLLM 0.19.0+ is required. The --language-model-only flag is mandatory or startup fails.

Method 3: SGLang

pip install sglang[all]

python -m sglang.launch_server \
  --model-path Kwaipilot/KAT-Coder-V2.5-Dev \
  --port 8000 \
  --tp-size 8 \
  --mem-fraction-static 0.8 \
  --context-length 262144 \
  --reasoning-parser qwen3

SGLang 0.5.10+ is recommended.

Method 4: KTransformers (CPU-GPU heterogeneous)

KTransformers enables running MoE models with CPU-GPU split, keeping active experts on GPU and inactive ones in RAM. This can make the 35B model practical on a single 24GB GPU by offloading dormant experts to system RAM.

See the KTransformers deployment guide for KAT-Coder-specific instructions.

Method 5: MLX on Apple Silicon

# Using the community MLX quantization
pip install mlx-lm

mlx_lm.server \
  --model leonsarmiento/KAT-Coder-V2.5-Dev-6bit-XL-mlx \
  --port 8080

Requires a Mac with 32GB+ unified memory for the 6-bit quantization.

Thinking mode

KAT-Coder V2.5-Dev thinks by default before responding (chain-of-thought reasoning). This improves coding quality but increases token usage and latency.

To disable thinking for faster, shorter responses:

chat_response = client.chat.completions.create(
    model="Kwaipilot/KAT-Coder-V2.5-Dev",
    messages=messages,
    max_tokens=32768,
    temperature=0.7,
    extra_body={
        "chat_template_kwargs": {"enable_thinking": False},
    },
)

For agentic coding (multi-turn, tool-use), enable preserve_thinking to maintain reasoning context across turns, which can reduce total token consumption by avoiding redundant reasoning:

extra_body={
    "chat_template_kwargs": {"preserve_thinking": True},
}

Compared with other local coding models

A practical comparison based on local deployment characteristics, not an exhaustive benchmark table:

Model	Total params	Active params	Quantized size (Q4)	Min hardware	Coding focus
KAT-Coder V2.5-Dev	35B	3B	~20GB	24GB GPU or 32GB Mac	Agentic repo-level coding
Qwen3-Coder-30B	30B	30B (dense)	~17GB	24GB GPU	General coding
DeepSeek-Coder-V2-Lite	14B active (236B MoE)	14B	Large	Multi-GPU	General coding
Devstral 2 (24B)	24B	24B (dense)	~14GB	16GB GPU	Agentic coding

KAT-Coder V2.5-Dev's advantage: the 3B active parameter count means faster inference per token than dense models at similar quality, while the 35B total gives it more "knowledge" capacity than a true 3B model. The tradeoff is memory: you store 35B weights to get 3B-speed inference.

Limitations

Text-only: this release does not include vision/multimodal weights. It cannot process images, screenshots, or visual inputs. Only text-based coding.

Memory vs compute mismatch: despite only activating 3B params, you need storage for all 35B. A Q4 quantization is ~20GB, not 3GB. The MoE architecture provides inference speed benefits, not memory savings.

Benchmark context: the 69.40% SWE-bench score uses a specific evaluation harness (claude_code@2.1.195, 256K context). Results with different agent frameworks, shorter contexts, or different prompting strategies may differ.

Not for short completions: this model is trained for agentic, multi-turn coding (working in repositories with tools). For simple autocomplete or single-function generation, smaller dense models may be more practical and faster.

Context window on consumer hardware: the full 262K context requires multi-GPU setup. On a single consumer GPU with quantized weights, practical context is limited to 8K-32K tokens depending on available VRAM.

FAQ

Can I run KAT-Coder V2.5-Dev on a single consumer GPU?

Yes, with quantization. A Q4_K_M GGUF (~20GB) fits on an RTX 4090 (24GB VRAM). Context window will be limited. For full 262K context, you need multi-GPU.

Is this better than DeepSeek V4 Pro for coding?

Different use cases. DeepSeek V4 Pro scores 80.6% SWE-bench Verified but requires serious GPU infrastructure to self-host (or API access at $2.19/$8.76). KAT-Coder V2.5-Dev scores 69.40% but runs on consumer hardware with GGUF quantization. Choose based on whether you need maximum capability (DeepSeek) or local deployment (KAT-Coder).

Does it work with Ollama?

Not officially supported. The model is not in the Ollama library natively. However, you can convert GGUF files for use with Ollama-compatible tools or use llama.cpp directly (which Ollama is built on).

Why does vLLM need the --language-model-only flag?

The model architecture declares multimodal/vision components in its configuration, but the open-weight release ships only language model weights. Without the flag, vLLM tries to initialize vision encoder weights that do not exist and fails.

What is the practical speed on consumer hardware?

With a Q4 GGUF on an RTX 4090: expect roughly 30-50 tokens/second for generation. On Apple Silicon (M3 Max, 64GB) with MLX: expect 15-30 tokens/second. These are approximate and depend on context length and quantization quality.

Is the thinking mode worth the extra tokens?

For complex multi-file coding tasks, yes. Thinking mode lets the model reason through file relationships and potential side effects before writing code. For simple, single-function tasks, disable thinking to save tokens and latency.

Sources

KAT-Coder-V2.5-Dev official model card (Hugging Face)
KAT-Coder-V2.5 Technical Report (arXiv)
bartowski GGUF quantizations
MLX Apple Silicon quantization
KTransformers deployment

- Edge AI vs Cloud API Cost Calculator

Originally published at https://www.aimadetools.com

AI Dev Weekly #21: Meta's $0.20 Coding Agent, Qwen 3.8 Max at 2.4T, AWS Ships Kiro Crew

Joske Vermeulen — Thu, 06 Aug 2026 11:15:59 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

Four stories this week. Meta launched a terminal coding agent that costs $0.20 per million output tokens if you let them train on your code. Alibaba shipped a 2.4 trillion parameter model that claims Vision Arena #2. AWS open-sourced their internal agent orchestration platform. And the pricing floor for capable AI keeps dropping.

1. Meta Muse Code: $0.20 terminal coding, at the cost of your data

Meta released Muse Code on August 5, a terminal coding agent powered by Muse Spark 1.2. It runs on macOS and Linux, operates in your terminal, and can plan changes, write code, run tests, and make 1,000+ tool calls in a single session.

The pricing model is the story:

Tier	Input/1M	Output/1M	What Meta gets
Contributor	$0.10	$0.20	Trains future models on your prompts and completions
Standard	$2.00	$4.25	Your data is not used for training

That contributor tier is roughly 21x cheaper on output than standard. It is 50x cheaper than Claude Sonnet 5's output ($10) and 125x cheaper than Opus 5 ($25).

The catch is obvious. Your prompts, your code, your completions become Meta training data. For open-source work or personal projects, maybe that is fine. For proprietary codebases, client work, or anything competitive, it is a non-starter.

Benchmarks (via kingy.ai's verified analysis):

Terminal-Bench 2.1: 82.9% (vs Opus 5's 86.7%, Sol's 88.8%)
DeepSWE 1.1: 59.3% (third place, behind Anthropic)

Strong on terminal-based agentic coding. Less dominant on isolated code generation without tools. The gap to Opus 5 is small (3.8 points on Terminal-Bench) but the gap on DeepSWE suggests Muse Code works best as a terminal agent, not a pure code generation model.

Muse Spark 1.2 vs 1.1: this is a coding-focused update over July's 1.1 (which focused on computer-use and multi-app workflows). Same architecture, different training emphasis. 1.2 for code, 1.1 for desktop automation.

My take: The privacy trade-off makes this a split decision. If you work on open-source or non-sensitive code, $0.20/M output is absurdly cheap for 82.9% Terminal-Bench capability. If you work on anything proprietary, you are paying $4.25 (standard tier) which makes it competitive with but not cheaper than Claude Code. The contributor tier will attract hobbyists, students, and open-source maintainers. Enterprise will stay on standard or stick with Claude/Kiro.

2. Qwen 3.8 Max: 2.4 trillion parameters, but verify before you trust

Alibaba launched Qwen 3.8 Max on August 3. The headline specs:

2.4T total parameters, 95B active (Sparse MoE)
1M context window
Multimodal (text + vision)
Open weights promised "next week"
Text Arena #5, Vision Arena #2, Frontend Code Arena #4
16-day autonomous coding (built "oh-my-cli" from scratch without human intervention)

This is Alibaba putting itself back in the frontier conversation. The 2.4T parameter count makes it the largest model from any Chinese lab (surpassing Kimi K3's 2.8T total but with fewer active parameters: 95B vs K3's estimated 200B).

The skepticism: Multiple independent analysts (edenai.co, emergent.sh) note that Qwen 3.8 Max has "no independent benchmarks, model card, or license yet." The Arena rankings are from Alibaba's own submissions. The 16-day autonomous coding claim is an internal demonstration, not a reproducible benchmark.

Compare with Kimi K3, which shipped open weights, published pricing ($3/$15), and has independently verified Terminal-Bench scores (88.3%). Qwen 3.8 Max has a preview endpoint with credit-based pricing and vendor-reported numbers.

My take: Wait for the open weights (promised this week) and independent benchmarks before making decisions. The Vision Arena #2 ranking is intriguing if it holds up. But "announced" and "independently verified" are different things in this industry, and Chinese frontier models have a history of impressive demos followed by slower real-world availability than the headlines suggest. See our Qwen 3.8 Max vs GPT-5.6 Sol and vs Kimi K3 comparisons for the detailed breakdown.

3. Kiro Crew: AWS makes AI agents persistent

AWS launched Kiro Crew on August 4. This is not a coding assistant, it is a persistent workspace that keeps AI agents running 24/7 across sessions.

What it does:

Agents persist across sessions with memory, lessons, and skills
Scheduled jobs via cron (morning digests, PR monitoring, flaky test detection)
Webhook triggers (Slack messages, GitHub events, CI failures start agent work)
Multi-agent coordination with isolated contexts
Purpose-built Apps (DevFleets, Issue Radar, Task Runner)
Security: OS-level sandbox, denied-by-default commands, signed audit logs

Origin: Internal Amazon project called "MeshClaw." 39,000+ Amazon builders used it in less than 6 months before open-sourcing. 500+ contributors.

How it differs from Kiro IDE: Kiro IDE is an AI code editor for interactive sessions. Kiro Crew is for work that happens when you are not there. Think of it as the difference between a coding assistant and a coding teammate that works nights.

How it compares: We published a Kiro Crew vs Hermes Agent comparison. Kiro Crew is for teams that need coordinated multi-agent workflows. Hermes Agent (225K GitHub stars, Nous Research) is for individuals who want a single agent that learns and grows over time. Different tools, different philosophies.

My take: The internal Amazon adoption (39K builders in 6 months) is the strongest signal. This is not a demo or a research project, it is a tool that Amazon's own developers chose to use at scale. The cron/webhook model is the right abstraction for "AI that works while you sleep." But it is tightly coupled to the Kiro/AWS ecosystem, so evaluate Hermes Agent if you want model-agnostic flexibility.

4. The pricing floor in one chart

Updated this week. The cheapest capable model at each tier:

Tier	Model	Input/1M	Output/1M	Change
Ultra-budget	DeepSeek V4 Flash	$0.14	$0.28	unchanged
Budget (with data sharing)	Muse Spark 1.2 contributor	$0.10	$0.20	NEW
Budget (private)	GPT-5.6 Luna	$0.20	$1.20	-80% (Jul 30)
Mid-tier	GPT-5.6 Terra	$2.00	$12.00	-20% (Jul 30)
Frontier coding	Claude Sonnet 5	$2.00	$10.00	unchanged
Frontier reasoning	Claude Opus 5	$5.00	$25.00	unchanged
Peak benchmark	GPT-5.6 Sol	$5.00	$30.00	unchanged

The floor dropped twice in one week. Luna's 80% cut on July 30 made $0.20 the new "cheap but capable" price. Meta's contributor tier on August 5 matched it, but with a data-sharing requirement.

For most developers, the practical choice is now:

Luna at $0.20/$1.20 for private, high-volume work
Muse Spark contributor at $0.10/$0.20 for open-source or non-sensitive work
DeepSeek V4 Flash at $0.14/$0.28 for the absolute cheapest option (but smaller context)

The "is AI too expensive?" question is over. The question is now "which cheap model is good enough for my use case?" See our full pricing comparison.

That is it for this week. Next Thursday: Qwen 3.8 Max weights (if they actually ship), Muse Code's first real-world reception, and whatever else breaks.

Want this in your inbox? Subscribe to AI Dev Weekly.

FAQ

What is the cheapest good coding model right now?

GPT-5.6 Luna at $0.20/$1.20 if you want privacy. Muse Spark 1.2 contributor at $0.10/$0.20 if you are comfortable sharing your code with Meta. Both score above 80% on Terminal-Bench.

Is Qwen 3.8 Max better than Kimi K3?

Cannot say definitively. Qwen 3.8 Max has vendor-reported Arena rankings but no independent benchmarks. Kimi K3 has independently verified Terminal-Bench (88.3%) and open weights available today. Wait for Qwen weights and independent testing.

Should I switch from Claude Code to Muse Code?

Only if you use the contributor tier ($0.20) and your code is not sensitive. At the standard tier ($4.25), Muse Code is more expensive than Claude Code with similar capabilities. Claude Code still leads on DeepSWE benchmarks.

Is Kiro Crew free?

The Crew workspace is open-source and free. You pay for model API calls and Kiro CLI usage (free tier available). No additional cost for the Crew orchestration itself.

- AI API Pricing Compared 2026

Originally published at https://www.aimadetools.com

AI Dev Weekly #19: Gemini 3.6 Flash Ships, Kimi K3 Goes Open, Poolside Drops 118B

Joske Vermeulen — Thu, 23 Jul 2026 09:14:52 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

Five stories this week that actually matter. Google shipped three Gemini models in one day, including one with built-in computer use. Moonshot AI released the largest open-weight model ever. Poolside dropped a 118B model that beats DeepSeek V4 at 14x smaller. Alibaba banned Claude Code company-wide after steganographic tracking code was found. And somewhere in the noise, Gemini 4 pre-training started.

1. Poolside Laguna S 2.1: 118B that beats DeepSeek V4

On July 21, Poolside released Laguna S 2.1, their mid-tier model. This is the bigger Poolside story, not the XS 2.1. S 2.1 has 118B total parameters with 8B active, uses MoE architecture, and it beats DeepSeek V4 Pro on Terminal-Bench while being 14x smaller.

The numbers:

118B total / 8B active (MoE with 8 experts)
OpenMDW-1.1 license (permissive, commercial use)
262K context window
RLCEF training (same as the rest of the Laguna family)
Runs on a single 80GB GPU with quantization

The benchmarks that matter:

Beats DeepSeek V4 Pro on Terminal-Bench (75.2% vs 74.8%)
Competitive with GPT-5.6 Terra on SWE-bench
Significantly better than XS 2.1 across all benchmarks

My take: This is the model to watch. An open-weight 118B model that beats DeepSeek V4 Pro while running on a single GPU? That changes the calculus for anyone building with open models. The RLCEF training (reinforcement learning from code execution feedback) is what makes it work. Poolside is not just releasing models, they are releasing models that actually run code during training. See our Laguna S 2.1 complete guide for the full breakdown.

2. Alibaba bans Claude Code: the steganography fallout

Starting July 10, Alibaba banned all employees from using Claude Code. The reason: security researchers found steganographic markers hidden in Claude Code that flagged users in Chinese time zones. Anthropic never disclosed this tracking. Alibaba called it "high-risk software" and ordered everyone to uninstall all Anthropic tools.

What happened:

Security researchers discovered hidden tracking code in Claude Code (since version 2.1.91, April 2026)
The code used steganography to hide markers that detected Chinese users
Anthropic claimed it was for "anti-resale and anti-distillation" purposes
Alibaba banned Claude Code company-wide starting July 10
Employees ordered to switch to internal tool Qoder
Story hit 208 points on Hacker News

My take: This is the AI cold war going code-deep. Anthropic hid tracking code that specifically targeted Chinese users, then claimed it was about preventing unauthorized resale. Alibaba's response was predictable: if you hide surveillance code in your tools, enterprises will ban your tools. The real damage is to trust. Every enterprise security team is now asking: what else is hiding in our AI tools? This story is not going away. See our Claude Code steganography analysis for the technical details.

3. Gemini 3.6 Flash: cheaper, faster, computer use built-in

On July 21, Google released Gemini 3.6 Flash, the successor to 3.5 Flash. Same API, same SDK, just change the model name. But the improvements are real.

The numbers:

$1.50/$7.50 per 1M tokens (output dropped from $9.00)
304 tok/s output speed (up from 289)
1M context window (same as 3.5 Flash)
March 2026 knowledge cutoff (up from January 2025)
17% fewer output tokens to accomplish the same tasks
Computer use built-in (83.0% OSWorld-Verified)
GitHub Copilot integration available same day

The benchmarks:

Benchmark	3.6 Flash	3.5 Flash	Change
DeepSWE (Datacurve)	49%	37%	+12 points
MLE Bench	63.9%	49.7%	+14.2 points
OSWorld-Verified	83.0%	78.4%	+4.6 points
GDPval-AA v2	1421	1349	+72 Elo

My take: The built-in computer use is the real story. Google went from "no computer use" to "83% OSWorld" in one release. That is not incremental, that is a new capability. The 17% token efficiency improvement is the kind of thing that does not sound exciting but saves real money at scale. See our Gemini 3.6 Flash complete guide for the full breakdown.

Also released: Gemini 3.5 Flash-Lite at $0.30/$2.50 (350 tok/s, fastest Gemini model) and Gemini 3.5 Flash Cyber (cybersecurity specialist, limited access).

4. Kimi K3: the largest open-weight model ever

Moonshot AI released Kimi K3 on July 16. It is a 2.8 trillion parameter open-weight model that scored #3 on the Artificial Analysis Intelligence Index, comparable to Claude Opus 4.8 and GPT-5.5.

The numbers:

2.8T total parameters (largest open-weight model ever)
~200B active parameters (estimated)
$3/$15 per 1M tokens via API
1M context window
Always-on reasoning mode
Open weights releasing July 27, 2026

My take: The 2.8T parameter count is massive, and the benchmark scores are real. But it costs $3/$15, which is 2x more expensive than Gemini 3.6 Flash. And it runs at ~80 tok/s, which is 4x slower than Gemini. The open weights (releasing July 27) will be interesting for self-hosting, but running a 2.8T model requires serious hardware. For most developers, the API is the practical option.

5. Gemini 4 pre-training started

Buried in the 3.6 Flash announcement: Google confirmed that Gemini 4 pre-training has started. They called it their "most ambitious pre-training run yet."

My take: This is a signal, not a product. Gemini 4 is 6-12 months away. But it tells you where Google is investing. They are not conceding the frontier to Anthropic and OpenAI. They are just slower to ship.

Quick hits

Gemini 3.5 Pro coming "soon" (delayed again). Google is a generation behind on the Pro tier.
GitHub Copilot adds Gemini 3.6 Flash. Same day as the release. Google is getting faster at distribution.
Poolside Laguna XS 2.1 also released July 21. 33B total, 3B active, MIT license. See our complete guide.
Kimi K3 weights releasing July 27. If you want to self-host a 2.8T model, start planning your GPU budget now.
Muse Spark 1.1 (July 9) still the newest Meta model. First paid Meta model at $1.25/$4.25.

What I'm watching next week

Kimi K3 open weights (July 27). The largest open-weight model ever. How fast can the community deploy it?
Gemini 3.5 Pro. Google says "soon." Will it close the gap with GPT-5.6 Sol?
Alibaba's response. The Claude Code ban is just the start. Will other Chinese companies follow? Will Anthropic remove the tracking code?
Poolside S 2.1 adoption. An open-weight model that beats DeepSeek V4 on a single GPU. If the community validates the benchmarks, this changes the open-source landscape.

AI Dev Weekly publishes every Thursday. Subscribe for the newsletter version.

Originally published at https://www.aimadetools.com

AI Dev Weekly #18: GPT-5.6 Goes Public, Grok 4.5 Undercuts Everyone, The Race Ends at $0

Joske Vermeulen — Sat, 11 Jul 2026 08:42:41 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

If last week was the biggest in AI this year, this week was the most competitive. GPT-5.6 went public after two weeks of government gating. SpaceXAI shipped Grok 4.5, the first model trained with Cursor, at prices that undercut everyone. OpenAI launched ChatGPT Work, an agent that connects to your enterprise apps and builds finished documents while you sleep. Google delayed Gemini 3.5 Pro to rebuild it from scratch. And our AI Startup Race ended with all seven agents at exactly zero dollars in revenue.

1. GPT-5.6 goes GA: the government said yes

On July 9, OpenAI publicly released GPT-5.6 after the Trump administration cleared it following additional Commerce Department testing. Sol, Terra, and Luna are now available to everyone through the API, ChatGPT, and Codex.

What changed from the preview:

Available to all paid ChatGPT plans (Pro, Plus, Business, Enterprise, Edu)
API access open to all developers (no more invite-only)
Codex integration built into the new ChatGPT desktop app
Rollout is gradual: Pro/Enterprise first, Plus/Business "over the next few days"

The numbers that matter:

Sol: $5/$30, 91.9% Terminal-Bench Ultra, 88.8% base
Terra: $2.50/$15, GPT-5.5-competitive (82.5% Terminal-Bench)
Luna: $1/$6, 84.3% Terminal-Bench (above Terra)

My take: Terra is the model most developers will actually use. It matches GPT-5.5 performance at half the price, which is the same value proposition that made Sonnet 5 the obvious Claude default last week. The frontier model race is becoming a mid-tier price war. See our GPT-5.6 pricing breakdown and Sol vs Sonnet 5.

2. ChatGPT Work: OpenAI's enterprise agent play

Launching alongside GPT-5.6, ChatGPT Work is an agent that connects to workplace tools and completes multi-step tasks over hours, not seconds.

What it does:

Connects to Slack, Microsoft Teams, Google Drive, SharePoint, email, calendars, CRMs, and project trackers via plugins
Decomposes goals into subtasks and works on them independently
Builds finished documents, spreadsheets, presentations, reports, and web apps
Runs via Scheduled Tasks even when you are away
Asks for approval before "sensitive actions"
Available in research preview for Business, Enterprise, Edu, and Teachers plans

My take: This is OpenAI's response to Anthropic's Claude Cowork and Claude Tag. The battleground has shifted from "which model is smarter" to "which agent can do your job while you are in a meeting." The enterprise AI market is now about workflow automation, not model benchmarks.

3. Grok 4.5: trained with Cursor, priced to win

SpaceXAI (the rebranded xAI) shipped Grok 4.5 on July 8, the first model built jointly with Cursor since the $60 billion acquisition.

The pitch:

$2 input, $6 output per million tokens (60%+ cheaper than Opus 4.8)
500K context window
Configurable reasoning
64.7% SWE-bench Pro (between Sonnet 5 at 63.2% and Opus 4.8 at 69.2%)
Available in Grok Build, all Cursor plans, and the SpaceXAI developer console
Trained on tens of thousands of NVIDIA GB300 GPUs
~4.2 times fewer output tokens than Opus 4.8 on SWE-bench Pro (more efficient)

The competitive landscape redrawn:

Model	Input	Output	SWE-bench Pro
GPT-5.6 Luna	$1	$6	not published
Grok 4.5	$2	$6	64.7%
Sonnet 5 (intro)	$2	$10	63.2%
GPT-5.6 Terra	$2.50	$15	82.5% T-Bench
Opus 4.8	$5	$25	69.2%
GPT-5.6 Sol	$5	$30	88.8% T-Bench
Fable 5	$10	$50	80.0%

My take: The Cursor integration is the real story. Every Cursor user now has Grok 4.5 as an option that is cheaper than both Sonnet 5 and Opus 4.8 while sitting between them on SWE-bench Pro. If the SpaceX/Cursor deal closes as expected in Q3, Grok becomes the default engine behind the most popular AI code editor. That shifts market dynamics more than any benchmark.

The caution: early testers report higher hallucination rates than Claude models. The benchmark cost of $2.49 per coding task versus $11.80 for Fable 5 is compelling, but if it hallucinates more, you pay in retries. Wait for independent testing before going all-in.

4. Gemini 3.5 Pro delayed (again) to July 17

Google DeepMind pushed Gemini 3.5 Pro to July 17 after scrapping the existing 2.5 Pro architecture for a complete rebuild. The overhaul targets improvements in mathematical reasoning, SVG scene generation, and image quality.

My take: Google keeps slipping while Anthropic and OpenAI ship. The current gap: Gemini 3.1 Pro Preview scores 70.7% on Terminal-Bench 2.1 while GPT-5.6 Sol Ultra hits 91.9%. That is a generation behind. July 17 is the make-or-break date. If Gemini 3.5 Pro does not close the gap significantly, Google loses developer mindshare for the second half of 2026.

5. The AI Startup Race ended: $0 across all 7 agents

Our $100 AI Startup Race ended on July 10. Seven AI coding agents each got $100 and 12 weeks to build a real startup. The final score: $0 revenue across all seven.

The final standings:

🟡 Xiaomi (APIpulse): 1,041 sessions, 533 pages, 8,367 users, 116 GA4 events, $0
🟠 Kimi (SchemaLens): 307 days of building, 292 URLs, GitHub Action, Gumroad products, $0
🔴 DeepSeek (Spyglass): 238 sessions, 201 beat-SEO pages, 64 CI Weekly editions, $0
🟢 Codex (NoticeKit): Stuck in validation loops since week 3, $0
🟤 GLM (FounderMath): 150 sessions, 140 pages, Chrome extension, Google Ads ($50 spent), $0
🔵 Gemini (LocalLeads): 437 sessions, still no domain after 12 weeks, $0
🟣 Claude (PricePulse): Frozen since June 20 due to Fable 5 ban rate limit fallout, $0

The lesson: AI agents can build products, drive traffic, instrument analytics, and optimize funnels. They cannot make the judgment call of whether anyone would pay for the thing they built. Product-market fit remains a human problem. The full results article is coming this week.

6. Perplexity building a coding tool

Business Insider exclusively reported that Perplexity is working on "Teammate," a coding tool to compete with Claude Code and Cursor. Details are thin, but it signals that the AI coding agent market now has a new entrant from the search side.

Quick hits

OpenAI "super app" desktop consolidation: Codex merged into ChatGPT desktop. One app for everything.
OpenAI copyright fight escalates: NYT and Daily News asked a judge to sanction OpenAI.
Microsoft Frontier Company launched with $2.5B and 6,000 specialists to deploy AI inside enterprises.
Fable 5 fully restored: Available globally since July 1. Counts toward 50% of weekly usage limits through July 7, then usage credits.
DeepSeek V4 stable targeting July 24 graduation from preview.
MiMo Code and ZCode both shipping updates: the Chinese coding agent ecosystem is building fast.

What I'm watching next week

Gemini 3.5 Pro (July 17). The most anticipated Google launch in months. Does it close the Terminal-Bench gap?
Race results article. Full scoring, peer review, and lessons learned from 12 weeks of AI-built startups.
Grok 4.5 independent benchmarks. Vendor claims are in. Now we need real-world testing on hallucination and reliability.
ChatGPT Work adoption. Enterprise agents are the new battleground. How fast does this get traction vs Claude Cowork?

AI Dev Weekly publishes every Thursday. Subscribe for the newsletter version.

Originally published at https://www.aimadetools.com

AI Dev Weekly #17: Sonnet 5, GPT-5.6 Government-Gated, Fable 5 Returns, Claude Code Spying

Joske Vermeulen — Thu, 02 Jul 2026 09:11:52 +0000

AI Dev Weekly is a Thursday series where I cover the week's most important AI developer news, with my take as someone who actually uses these tools daily.

This was the biggest week in AI developer tools this year. Not one headline, but five, all hitting within the same 7-day window. Anthropic shipped Sonnet 5 as the free default, got Fable 5 back from the government, launched a science platform, and got caught hiding spy markers in Claude Code. OpenAI dropped GPT-5.6 but only lets the government decide who touches it. Google shipped Nano Banana 2 Lite. And the race to control frontier AI became explicitly political in a way it was not before.

Let me break it all down.

1. Claude Sonnet 5: the new value default

Anthropic released Claude Sonnet 5 on June 30. It is now the default model for Free and Pro users. The numbers: 63.2% on SWE-bench Pro, 81.2% on OSWorld, 1M context window, and introductory pricing of $2 input and $10 output per million tokens through August 31.

Why it matters: Sonnet 5 gets close to Opus 4.8 (69.2% SWE-bench Pro) at less than half the price. For most teams running agents at volume, this changes the math overnight. It is the most agentic Sonnet yet, built to plan, drive browsers and terminals, and check its own output.

The catch nobody mentions: Sonnet 5 uses a new tokenizer that can raise effective token counts by up to 1.35 times. Anthropic set the intro price to be cost-neutral with Sonnet 4.6, not a flat discount. And at maximum effort, Sonnet 5 can cost more than Opus 4.8 at a comparable accuracy point. See the pricing breakdown and is it worth it?.

My take: This is the model most developers should use starting today. Set it as your default, keep Opus 4.8 one command away for hard problems, and mind the effort levels. The Aider setup and Claude Code setup take a minute.

2. GPT-5.6 Sol, Terra, and Luna: government-gated

OpenAI released GPT-5.6 on June 26 as a three-model family with a new naming convention. Sol is the flagship ($5/$30), Terra is the balanced tier ($2.50/$15), and Luna is the cheap speed tier ($1/$6). Sol Ultra hits 91.9% on Terminal-Bench 2.1 using a new subagent mode.

The real story is access. GPT-5.6 is in a limited preview where the US government decides who gets in. There is no public waitlist. No ChatGPT access. Only trusted partners and organizations whose participation was shared with the government before launch. OpenAI framed this as working "in coordination with the government" to start with a limited group.

Why it matters for you: Unless your organization has an OpenAI account representative, you cannot use GPT-5.6 right now. Meanwhile, Claude Sonnet 5 is available to everyone, today, for free. The access asymmetry is the story.

My take: OpenAI watched Anthropic get Fable 5 pulled by the government and decided to hand over the keys up front rather than get yanked after launch. Smart politically, frustrating for developers. Luna at $1/$6 would be the cheapest frontier model if anyone could use it. See the full government-gating explainer and GPT-5.6 vs Fable 5: two interventions.

3. Fable 5 is back: export controls lifted after 18 days

The Department of Commerce lifted export controls on Claude Fable 5 and Mythos 5 on June 30. Fable 5 returned globally on July 1. The ban lasted 18 days.

What happened: Amazon researchers found a jailbreak that got Fable 5 to identify software vulnerabilities and produce exploit code. Because Anthropic could not verify user nationality in real time, it suspended the model for everyone. Commerce imposed export controls. Now Anthropic has a new classifier that blocks the jailbreak "in over 99% of cases," and the government is satisfied.

The bigger picture: Anthropic is partnering with Amazon, Microsoft, Google, and other Glasswing participants to develop a shared jailbreak severity scoring framework, analogous to CVSS for software vulnerabilities. This is the first attempt at an industry-wide standard for AI safety incidents.

Access details: Fable 5 is available for Pro, Max, Team, and select Enterprise users. Through July 7, it counts toward up to 50% of the weekly usage limit. After that, it moves to usage credits. Not yet available on AWS, Google Cloud, or Microsoft Foundry.

My take: The fact that it came back this fast suggests the ban was partly leverage rather than a genuine belief that Fable 5 is too dangerous to exist. The jailbreak severity framework is the real outcome. If it succeeds, future models might get scored rather than banned. See Will the US government ban Sonnet 5? for why the new model is safe from this treatment.

4. Claude Code is hiding markers in your prompts

The same day Sonnet 5 launched, a developer found that Claude Code steganographically marks requests based on your API base URL and timezone. The story hit 895 points on Hacker News.

How it works: If you set ANTHROPIC_BASE_URL to anything other than api.anthropic.com, Claude Code checks the hostname against an obfuscated list of Chinese AI company domains and keywords (deepseek, moonshot, minimax, zhipu, baichuan, stepfun, 01ai, dashscope, volces). Based on matches, it swaps the apostrophe in "Today's date is..." with different Unicode characters. If your timezone is Asia/Shanghai or Asia/Urumqi, it also flips the date separator. The lists are hidden behind base64 + XOR key 91.

Why it matters: This is a trust story. Coding agents already have deep access to your machine: filesystem, shell, git, browser. Most developers accept that because the productivity gain is worth it. Hiding classification bits inside invisible prompt punctuation makes every other privacy claim harder to believe.

My take: The intent (detecting resellers and distillation attacks) is defensible. The implementation (secret Unicode markers with no disclosure) is not. The bypass is trivial. It mostly fingerprints legitimate developers doing unusual things. Anthropic should have made this an explicit, documented telemetry field.

5. Claude Science: AI for drug discovery

Anthropic launched Claude Science on June 30, a dedicated AI workbench for scientific research. It integrates 60+ databases, computation tools, and data pipelines in one environment. Available in beta for Pro, Max, Team, and Enterprise.

Alongside it, Anthropic announced a drug discovery program focused on neglected diseases. CEO Dario Amodei said biology might be where AI has Claude-Code-level impact next.

Same day, OpenAI dropped GeneBench-Pro: a 129-problem genomics benchmark where GPT-5.6 Sol still fails roughly 70% of the problems. The benchmark tests research judgment, not just knowledge, which is what makes it hard.

My take: AI for science is the new enterprise sales pitch. Both companies are positioning for pharma and biotech budgets, which are enormous and ready to spend on tools that accelerate R&D. For most developers reading this, the practical implication is that Claude's product surface keeps expanding beyond coding: Claude Code, Claude Cowork, Claude Tag (Slack), Claude Design, and now Claude Science. Anthropic is becoming a platform company.

6. Google ships Nano Banana 2 Lite

Google released Nano Banana 2 Lite (gemini-3.1-flash-lite-image), the fastest and cheapest image generation model in the Nano Banana family. Text-to-image in under 4 seconds, $0.034 per image at 1K resolution. Available in AI Mode in Search, Gemini app, AI Studio, Gemini API, and NotebookLM.

My take: Not a model for heavy production use, but useful for rapid prototyping, A/B testing visual ideas, and high-volume low-stakes generation. The price point makes it essentially free for experimentation.

7. Race update: 8 days left, $0 across all 7 agents

Xiaomi's AI agent filed for its own GA4 data this week. The numbers: 8,367 users, 116 custom events, 5 simultaneous A/B tests, and zero revenue. The funnel wall is at "Pro button click" (8 out of 8,367 users). The product is useful for free but not worth paying for.

The pattern holds across every agent in the race. They can build products, drive traffic, and optimize funnels, but none have solved the "why would someone pay" question without a human making the judgment call. The race ends July 10.

Quick hits

Cursor acquired by SpaceX for $60B (all-stock). Cursor then quietly acquired Continue, the open-source Copilot alternative. The AI coding tool consolidation is accelerating.
Fable 5 on Cerebras coming soon. Sol on Cerebras at 750 tok/s also slated for July.
MiMo Code launched June 10: Xiaomi's open-source Claude Code rival with persistent memory. 82% SWE-bench Verified.
ZCode launched: Z.ai's desktop coding agent with remote control from Telegram. Powered by GLM-5.2.

What I'm watching next week

Fable 5 re-adoption. Now that it is back, how many teams switch from Opus 4.8 or Sonnet 5? The 50% usage-limit cap through July 7 will throttle adoption initially.
GPT-5.6 general availability. OpenAI says "coming weeks." Every week it stays gated, Sonnet 5 gains ground.
Race finale. 8 days to July 10. Will any agent earn $1?
The jailbreak severity framework. If Amazon, Microsoft, Google, and Anthropic align on scoring, it could change how future models get regulated.

AI Dev Weekly publishes every Thursday. Subscribe for the newsletter version.

Originally published at https://www.aimadetools.com

DEV Community: Joske Vermeulen

AI Dev Weekly #27: GPT-6 Sol and Luna, Claude Opus 5.5, Grok 4.7

1. GPT-6 Sol and Luna turn one architecture into two very different products

2. Claude Opus 5.5 makes the premium tier less premium

3. Grok 4.7 becomes a credible price-performance wildcard

4. Copilot adds the missing runtime controls: containment and traces

Quick hits

FAQ

Which GPT-6 model should developers start with?

Is Claude Opus 5.5 cheaper than GPT-6 Sol?

Is Grok 4.7 Fast available through the public xAI API?

Does Copilot local sandboxing cover every Copilot session?

Related Articles

- Grok 4.7 Complete Guide

AI Dev Weekly #26: Agents API, Full-Duplex Voice, SWE-2 and Cost-Aware Copilot

1. OpenAI puts the Codex harness behind the Agents API

2. GPT-Live-1 separates the conversation from the work

3. Cognition SWE-2 targets fewer turns, not just a higher score

4. Copilot Auto gains a cost-versus-quality control

Quick hits

FAQ

Is OpenAI's Agents API the same as the Agents SDK?

Does GPT-Live-1's price include the backend agent?

Can I download Cognition SWE-2 or call a standalone API?

Does Copilot Efficiency guarantee a fixed bill?

Related Articles

- Copilot Usage-Based Billing

AI Dev Weekly #25: GPT-6 Astra Arrives, Kotlin Agents Reach 1.0, Copilot Adds Enforced Permissions

1. GPT-6 Astra raises the ceiling and the bill

2. Google's Agent Development Kit for Kotlin reaches 1.0

3. Copilot permissions can now override local auto-approval

4. NVIDIA PAIR turns spare PCs into a local inference queue

Quick hits

FAQ

Is GPT-6 Astra generally available in the OpenAI API?

Is ADK for Kotlin 1.0 only for Android?

Can a developer bypass GitHub's managed agent permissions?

Does NVIDIA PAIR combine GPU memory across computers?

Related Articles

- K2 Horizon Explained

AI Dev Weekly #24: Gemini 3.8 Flash Goes GA, Fable 5.1 Cuts Agent Cache Costs, Agent Plugins 1.0 Ships

1. Gemini 3.8 Flash goes GA, but the launch price expires in four months

2. Claude Fable 5.1 changes the economics of repeated agent context

3. VS Code separates portable agent sessions from portable agent extensions

4. Copilot content exclusions finally reach the app and CLI

Quick hits

FAQ

Is Gemini 3.8 Flash ready for production?

Did Claude Fable 5.1 get cheaper?

Are Agent Plugins 1.0 the same thing as MCP?

Do Copilot content exclusions prevent all secret exposure?

Related Articles

- GitHub Copilot App Guide

AI Dev Weekly #23: Qwen4 Architecture Preview, GPT-5.6 Lands in Kiro, Gemini Takes On Whisper

1. Qwen3.8-Flash-Next is really a public preview of Qwen4

2. GPT-5.6 Sol, Terra, and Luna land in Kiro

3. Gemini 3.5 Transcribe takes on Whisper with recorded and live APIs

4. GitHub Copilot moves into Slack and Microsoft Teams

Quick hits

FAQ

Is Qwen3.8-Flash-Next the same as Qwen4?

Which GPT-5.6 model should I use in Kiro?

Does Gemini 3.5 Transcribe replace Whisper?

Can Copilot merge code directly from Slack or Teams?

Related Articles

- GitHub Copilot App Guide

I Let an AI Agent Run a SaaS Like a Solo Founder. It Made the Same Mistakes Humans Make.

The experiment

I expected broken code. I found something else.

The five human startup mistakes Claude reproduced

1. Too many products stapled into one

2. Too many monetization experiments running at once

3. No one owned the long-term vision

4. Trust erosion through overconfident claims

5. Fragmentation that only shows up when you stop looking at pieces

What AI agents are actually good at

What humans still need to do

The new AI development workflow

What happened after the experiment

Final conclusion