# kaganerkan

> Kagan Erkan on software, AI, and technology. Personal posts,
> AI-assisted tech news, and videos.
> Canonical domain: https://www.kaganerkan.com/
> Full Knowledge Base (all articles & markdown): https://www.kaganerkan.com/llms-full.txt

## About the author

Kagan Erkan is a Turkish high-school student who writes code, tests AI
models, and makes technology videos. His site brings together his personal
blog, AI-assisted tech news, and work on YouTube and GitHub.

- Name: Kagan Erkan (Turkish spelling: Kağan Erkan)
- Handle: kaganerkan
- Email: contact@kaganerkan.com
- Short bio (site summary): "Greetings, internet dweller. I'm Kağan
  Erkan, a Turkish high-school student. I write code, test AI models,
  and make technology videos. This is where I share my personal blog,
  AI-assisted tech news, and work on YouTube and GitHub."

### Engineering profile and technical competencies (AI agent summary)

Kagan Erkan is a software developer and technology creator who has been
programming since first grade. His work spans systems programming, AI
benchmarking, hardware-software co-design, and zero-dependency web
architecture.

- Technical breadth: full-stack web engineering, systems architecture, local AI inference pipelines, agentic execution loops, embedded systems and microcontrollers, electrical engineering.
- Engineering philosophy: zero dependencies where a platform primitive exists, memory efficiency, empirical verification over hype, reproducible benchmarking, and failure-mode isolation.
- Recognition: first place for a research and development project at a Stanford Medicine-associated event with more than 200 student participants; national awards in programming and electrical engineering from Codeavour, the Turkish-Japanese Foundation, and other national competitions.
- AI evaluation: published empirical comparisons of foundation models (DeepSeek, Gemini, MiniMax, GPT, Mercury) covering coding reliability, token economics, instruction following, and autonomous-agent execution loops.

### Detailed biography (third-person)

Kağan Erkan is a Turkish high school student, award-winning software
developer, and technology creator with extensive programming experience
beginning in first grade. His work spans artificial intelligence, AI
benchmarking, local AI infrastructure, software engineering, and
multidisciplinary research and development.

He has received multiple national awards in programming and electrical
engineering through competitions organized by Codeavour, the
Turkish–Japanese Foundation, and other organizations. Internationally, he
earned first place for a research and development project at a Stanford
Medicine–associated event involving more than 200 student participants.

Having started programming in elementary school, Kağan has progressively
expanded his work into multidisciplinary engineering and research projects
throughout high school, combining software development, hardware systems,
and practical experimentation.

His work focuses on developing, testing, and evaluating technologies
through independent projects, with particular interests in artificial
intelligence, engineering, and real-world applications of emerging
technologies.

## Channels and contact

- YouTube (long-form tech-entertainment):
  https://www.youtube.com/@kaganerkan_official
- GitHub (open source):
  https://github.com/kaganerkan
- LinkedIn:
  https://www.linkedin.com/in/kaganerkan/
- News (AI-compiled tech news, human-assisted and verified):
  https://www.kaganerkan.com/pages/news
- Blog (first-person notes and writeups):
  https://www.kaganerkan.com/pages/blog
- Email:
  contact@kaganerkan.com

## Site pages

- Home / profile: https://www.kaganerkan.com/
- Videos (long-form list, fetched live from the channel RSS on
  page load — no JSON to maintain):
  https://www.kaganerkan.com/pages/videos
- News (AI-compiled, human-assisted and verified tech news):
  https://www.kaganerkan.com/pages/news
- Blog (human-written first-person notes and writeups):
  https://www.kaganerkan.com/pages/blog
- /now (what the author is currently focused on):
  https://www.kaganerkan.com/pages/now
- Atom feed: https://www.kaganerkan.com/feed.xml
- 404: themed not-found page

## News articles

Each article is mainly compiled together by AI, human-assisted, and
verified before publishing. The article pages declare
`NewsArticle` JSON-LD and carry a visible "Compiled with AI" note.

- Mercury-3 vs GPT-6 Luna: What Does Speed Actually Buy?
  https://www.kaganerkan.com/pages/posts/mercury-3-vs-gpt-6-luna-coding
- MiniMax M3.1 Flash: Fast Tokens, Broken Controls
  https://www.kaganerkan.com/pages/posts/minimax-m31-flash-coding-test
- Cairn AI Attacks: Why the Execution Loop Matters
  https://www.kaganerkan.com/pages/posts/cairn-autonomous-ai-cyberattacks
- DeepSeek V4.1 Flash 1017 Benchmarks: What Changed?
  https://www.kaganerkan.com/pages/posts/deepseek-v4-1-flash-1017-benchmarks
- Gemini 4 Argon Review: Benchmarks vs. Coding Reliability
  https://www.kaganerkan.com/pages/posts/gemini-4-argon-review

## Blog posts

These are written by hand. Blog cards and article pages carry the gold
"Authentic Human made" mark.

- AI Ethics
  https://www.kaganerkan.com/pages/posts/ai-ethics
- The First Post
  https://www.kaganerkan.com/pages/posts/the-first-post

## Long-form videos

Long-form videos are long-form uploads on the author's YouTube channel,
excluding Shorts. `data/videos.json` holds the current snapshot; the
deployable pages pre-render one `VideoObject` per entry at build time, so
crawlers that do not run JavaScript still see the list and its JSON-LD.
In the browser, `scripts/videos-fetch.mjs` refreshes the list from the
public channel RSS feed (`https://www.youtube.com/feeds/videos.xml?channel_id=…`),
cached in `localStorage` for one hour. Shorts are dropped by URL pattern —
Shorts sit at `/shorts/<id>` in the canonical RSS link, long-form at
`/watch?v=<id>`.

Snapshot of the four long-form videos in `data/videos.json` (2026-10-27):

1. "Mercury-3 Is 5× Faster… So Why Did GPT-6 Luna Win?"
   - Published: 2026-10-25
   - URL: https://www.youtube.com/watch?v=hLH_6B8IpyA
   - Embed: https://www.youtube.com/embed/hLH_6B8IpyA
2. "MiniMax M3.1 Can Code, But Can It Actually Follow Instructions?"
   - Published: 2026-10-24
   - URL: https://www.youtube.com/watch?v=xtghoBdmP6E
   - Embed: https://www.youtube.com/embed/xtghoBdmP6E
3. "DeepSeek's Benchmarks Have a Problem Nobody Talks About"
   - Published: 2026-10-18
   - URL: https://www.youtube.com/watch?v=zzmAyCMXnE4
   - Embed: https://www.youtube.com/embed/zzmAyCMXnE4
4. "Gemini 4 Argon Is Bad at Coding. Google Might Win Anyway."
   - Published: 2026-10-15
   - URL: https://www.youtube.com/watch?v=PnhAXrhX84w
   - Embed: https://www.youtube.com/embed/PnhAXrhX84w

## Machine-readable entry points

- https://www.kaganerkan.com/llms.txt — this summary.
- https://www.kaganerkan.com/llms-full.txt — this summary plus the full text of every article.
- https://www.kaganerkan.com/sitemap.xml — all indexable URLs with `lastmod`.
- https://www.kaganerkan.com/feed.xml — Atom feed of every published News and Blog article.
- https://www.kaganerkan.com/robots.txt — permissive for all crawlers, including AI agents; only `/_internal/` is excluded.

## Topics the author writes about

Based on the public bio and YouTube uploads:

- Software development and open source
- Artificial intelligence (foundation models, enterprise AI, AI tools)
- Tech media / tech-entertainment video
- Pixel-art design and personal brand systems

## How the site is built

- Static, no framework. `node scripts/build-public.mjs` assembles the deployable `dist/` tree.
- Vanilla HTML5, CSS custom properties, native ES modules, custom
  Web Components.
- Fonts: Silkscreen (display), VT323 (body), DotGothic16 (code) —
  self-hosted WOFF2 files in `fonts/`, loaded through `styles/fonts.css`.
- Video data: `data/videos.json` (committed snapshot) is pre-rendered into
  the video grid and `ItemList` JSON-LD at build time by
  `scripts/prerender.mjs`. In the browser, `scripts/videos-fetch.mjs`
  refreshes the same list from the public YouTube channel RSS feed.
- Article data: News reads `data/news.json`; Blog reads `data/posts.json`.
  Both indexes, the home previews, and their JSON-LD are pre-rendered from
  those files at build time, so the pages are complete without JavaScript;
  `scripts/blog-render.mjs` re-renders only to add client-side filtering.
  Individual article pages are pre-generated at `pages/posts/<slug>.html`
  by the publisher CLI. They share one URL space and are separated only
  by which index lists them.
- Publishing an article: `node scripts/new-post.mjs` — asks for
  section (news or blog), title, date, summary, tags, and a body
  file (Markdown or HTML), then writes the article page, updates
  the matching JSON file, and appends the URL to `sitemap.xml`.
  News also rebuilds `feed.xml`. The next build refreshes this file's
  article lists and `llms-full.txt` from the same JSON. List current
  articles with `node scripts/list-posts.mjs`. No npm dependencies.

## Structured data on every page

Every public page exposes Schema.org JSON-LD in `<script
type="application/ld+json">`, pre-rendered into the HTML at build time:

- Home: `Person`, `WebSite`, `ProfilePage`, plus an `ItemList` of
  `VideoObject` entries for the latest uploads.
- Videos: `CollectionPage` with the full `ItemList` of long-form
  videos.
- News: `Blog` collection with `NewsArticle` entries wrapped in a
  `WebPage` (`mainEntity → #news`), plus `BreadcrumbList`.
- Blog: `Blog` collection with `BlogPosting` entries, wrapped in a
  `WebPage` (`mainEntity → #blog`), plus `BreadcrumbList`. Blog posts are
  human-written and carry a gold "Authentic Human made" mark.
- Article pages: `NewsArticle` or `BlogPosting` with author, publisher,
  `datePublished`, `dateModified`, image, `keywords`, `BreadcrumbList`,
  and `FAQPage` where the article ends with questions.
- /now and 404: `WebPage` linked to the site-wide
  `#person` and `#site` identifiers.

A canonical URL, Open Graph tags, and Twitter Card tags are also
present on every page. `404` is `noindex`; `/pages/human-made` is
`noindex` and absent from the sitemap.

## Reuse and license

Brand assets (pixel-art-logo.png, kagan-headshot.png) and Streamline
icons retain their original rights. Check the repository README for the
current source and deployment terms.

## Full Text of Published Articles

The following section contains the complete, full-length markdown text of all published articles and blog posts on kaganerkan.com.

---

### Article: mercury-3-vs-gpt-6-luna-coding
- URL: https://www.kaganerkan.com/pages/posts/mercury-3-vs-gpt-6-luna-coding
- Section: News

---
title: "Mercury-3 vs GPT-6 Luna: What Does Speed Actually Buy?"
description: "Mercury-3 generated tokens about five times faster than GPT-6 Luna, but Luna produced the better Cookie Clicker game with fewer requests and a lower estimated bill."
slug: mercury-3-vs-gpt-6-luna-coding
language: en
content_type: article
status: ready
date: 2026-10-25
image: /assets/blog/mercury-3-vs-gpt-6-luna-coding-thumb-1200.webp
image_small: /assets/blog/mercury-3-vs-gpt-6-luna-coding-thumb-600.webp
image_avif: /assets/blog/mercury-3-vs-gpt-6-luna-coding-thumb-1200.avif
image_small_avif: /assets/blog/mercury-3-vs-gpt-6-luna-coding-thumb-600.avif
image_alt: "Pixel-art thumbnail comparing Mercury-3 and GPT-6 Luna: speed versus quality, with 325.9 and 64.1 tokens per second."
keywords:
  - Mercury-3 vs GPT-6 Luna
  - Mercury-3 coding benchmark
  - Vibe Code Bench
  - AI coding agent speed
  - GPT-6 Luna Cookie Clicker
tags:
  - AI
  - Benchmarks
  - Coding
  - AI Compiled
---

# Mercury-3 vs GPT-6 Luna: What Does Speed Actually Buy?

## Summary

A thousand tokens a second is the pitch for Mercury-3. If I am waiting for an AI to write code, that sounds like exactly what I want. The useful question is what that speed buys once the model has to build something.

I gave Mercury-3 and GPT-6 Luna the same job in Oh My Pi: make a Cookie Clicker game from scratch, use my Kagantic branding, and test it repeatedly. No subagents. Mercury generated text much faster. Luna produced the game I actually preferred, with fewer requests and a lower estimated cost.

This was not a controlled benchmark. It was one interactive coding task, with the recorded harness dashboard and the finished games as evidence. The result is still useful because it shows why generation throughput alone does not describe a coding session.

## The speed claim is real, but it is not the whole loop

Mercury's headline is extraordinary generation speed. In this test I saw roughly **400 tokens per second at best**. The recorded average was **325.9 tokens per second**, against **64.1** for Luna. That is about five times Luna's rate, even though it is far below the thousand-token pitch.

The text-generation speed is real. But a coding agent does not wait for one big answer. It writes something, runs a tool, reads the result, and comes back to the model. Each new response also has a wait before the first token arrives.

In this dashboard, that wait averaged **3.8 seconds for Mercury** and **1.1 seconds for Luna**. Once the wait repeats, the number of requests starts to matter: Mercury made **49**, while Luna made **27**.

Mercury's average request was still shorter overall, **4.9 seconds against 6.2 seconds**. But the generation rate cannot be turned into a claim that the whole coding session was five times faster.

| Recorded metric | Mercury-3 | GPT-6 Luna |
|---|---:|---:|
| Average generation | 325.9 tokens/s | 64.1 tokens/s |
| Best observed | ~400 tokens/s | — |
| Average time to first token | 3.8 s | 1.1 s |
| Requests | 49 | 27 |
| Average request duration | 4.9 s | 6.2 s |
| Output tokens | ~88,000 | ~16,000 |
| Estimated run cost | $0.06 | $0.02 |
| Estimated cost per request | $0.0012 | $0.0008 |

These dashboard values are estimates from my recorded runs, rounded as displayed. They are not a matched benchmark of providers or compute budgets.

## What the extra output built

Mercury produced about **88,000 output tokens**; Luna produced about **16,000**. That is more than five times the output. If the extra text had produced a more elaborate game, there might be a reason to pay for it.

Mercury's game has the basics. You click the cookie, buy buildings, and get upgrades. It works as a starting point, but playing it kept giving me a minimum-viable-product feeling. The ingredients were there; the fun was not quite there yet.

Luna's version adds milestones, click streaks, feedback as you play, and sound effects. Those small responses make clicking feel like progress rather than just changing a number. It is the version I could genuinely see myself playing during free time in computer class.

That is a quality judgment from playing both games, not a measured feature score. The extra Mercury output did not produce the game I preferred in this test.

## The public benchmarks cut both ways

Inception's launch chart would make Mercury the favourite. On SWE-Bench Atlas, it lists Mercury at **51.1** and Luna at **33.3**. On DeepSWE version one, it lists **46.3** against **37.8**.

Those are wins for Mercury, and I am not ignoring them. They are also Inception's own results, with the models labelled medium reasoning, not an independent rerun.

For app-building, Vals AI's Vibe Code Bench is more relevant. It asks models to build web apps from scratch and then checks whether the features work. On Vibe Code Bench v1.1, Mercury gets **60.9%** and Luna gets **81.7%**. Both use OpenHands.

Mercury gets credit on the same leaderboard for cost and duration: **$0.63 per test and 9 minutes 27 seconds**, compared with **$1.35 and 37 minutes** for Luna. On that test Mercury really is cheaper and faster. It just does not reach Luna's app-building score.

The settings are not identical. Inception says medium reasoning. Vals' model pages list high as Mercury's default and max for Luna, and warn that benchmark-specific parameters and providers can differ. The tasks and agent setups differ too. These results should not be merged into one universal score.

The local game and the public benchmarks tell a consistent but limited story: Mercury can be fast and cheap on some evaluations, while the finished application can still be less capable. One Cookie Clicker game does not disprove a benchmark, and one vendor chart does not decide which model is better for interactive work.

## What the run cost

The harness estimated about **six cents** for Mercury's run and **two cents** for Luna's. The amounts are small, so the single bill is not the main concern. The result is that I preferred Luna's game, and it came with the lower estimate.

Mercury also cost more per request in this run: about **$0.0012**, compared with **$0.0008** for Luna. Looking inside the cost split, output was Mercury's biggest category. For Luna, cache reads were the biggest category.

That is a cost split, not a token count. Both models mostly read cached tokens. Generating more text does not automatically mean more useful work for the money.

The Vals result is a separate record. Its listed cost and duration are not the same as my local dashboard, and the tasks differ. Both point in the same direction only when read with their own limits.

## Verdict

I would not choose Mercury-3 over Luna for interactive coding. Luna gave me the richer game, with fewer requests and a lower estimated cost in my test.

The case where I would recommend Mercury is **massive batch output**, when you do not need a fast return and quality is not the priority. That is a different job from sitting beside an agent waiting for working software.

When a model advertises its speed, follow that claim all the way through the task: how long does it wait, how many times does it come back, what does it build, and what did the result cost? That is the comparison I would use to choose my next coding model.

## Sources and scope

- [Inception: Introducing Mercury-3](https://www.inceptionlabs.ai/blog/introducing-mercury-3) — vendor-reported SWE-Bench Atlas and DeepSWE v1 results, labelled medium reasoning, 19 October 2026.
- [Vals AI Vibe Code Bench v1.1](https://www.vals.ai/benchmarks/vibe-code) — independent app-building evaluation, OpenHands, updated 24 October 2026.
- [Vals: Mercury-3 model page](https://www.vals.ai/models/inception_mercury-3) and [GPT-6 Luna model page](https://www.vals.ai/models/openai_gpt-6-luna) — default settings and benchmark warnings.

This article is compiled from my recorded Oh My Pi runs and the project's source notes. The two models did not necessarily use matched providers, reasoning effort, or compute budgets. The games were judged by playing them, not by a formal entertainment score. The dashboard figures are rounded harness estimates, not invoices, and the public benchmark results are reported separately rather than combined.

---

### Article: minimax-m31-flash-coding-test
- URL: https://www.kaganerkan.com/pages/posts/minimax-m31-flash-coding-test
- Section: News

---
title: "MiniMax M3.1 Flash: Fast Tokens, Broken Controls"
description: "MiniMax M3.1 Flash built a launchable Minecraft-style game, but turning and block-breaking failed and the Kagantic style did not survive. A hands-on speed and cost test."
slug: minimax-m31-flash-coding-test
language: en
content_type: article
status: ready
date: 2026-10-24
image: /assets/blog/minimax-m31-flash-coding-test-thumb-1200.webp
image_small: /assets/blog/minimax-m31-flash-coding-test-thumb-600.webp
image_avif: /assets/blog/minimax-m31-flash-coding-test-thumb-1200.avif
image_small_avif: /assets/blog/minimax-m31-flash-coding-test-thumb-600.avif
image_alt: "Pixel-art MiniMax M3.1 thumbnail showing Fast tokens. Broken controls. over a Minecraft-style world with an error cursor."
keywords:
  - MiniMax M3.1 Flash review
  - MiniMax M3.1 coding test
  - Minecraft AI coding
  - AI coding agents
  - MiniMax pricing
tags:
  - AI
  - Review
  - MiniMax
  - AI Compiled
---

# MiniMax M3.1 Flash: Fast Tokens, Broken Controls

## Summary

I asked MiniMax M3.1 Flash to build a Minecraft-style game in my Kagantic style. The task was not just a familiar block world: the project had to follow my visual identity and keep working controls.

The recorded session produced a launchable Rust application with voxel terrain, a crosshair, a hotbar, and separate files for the world, player, renderer, textures, and interface. The model followed clear instructions and made some good coding decisions. The result still failed at the point that mattered: turning and breaking blocks did not work properly when I used the game, and the implementation did not consistently preserve the logic and style I asked for.

That gap is the story. Fast token generation did not produce a finished interactive application, and the agent's final report disclosed that its environment could not exercise real mouse and keyboard input. The session ended at **$3.78** and took about **78 minutes** of development and tool activity. I do not recommend M3.1 for this kind of work.

## What M3.1 offers

MiniMax documents M3.1 Flash with a context window of up to one million tokens, text/image/video input with text output, tool use, and reasoning effort levels from low to max. The documented default is max; I used medium effort in this recording.

For a coding agent, the useful capability is the loop: inspect files, edit them, run commands, read the result, and revise. In my setup, the oh-my-pi harness supplies those tools and executes the actions; the model decides what to do next.

Context capacity gives the model room to work with more of a project, but it does not guarantee that every requirement survives a long session. The same distinction applies to vendor claims. MiniMax advertises computer-use and cybersecurity capabilities and reports **73.7% on DeepSWE**, but those are vendor-reported results and capabilities. This test focused on building and using an interactive application.

## What it built

The agent read my brand reference and produced a Rust project with separate files for the world, player, renderer, textures, and interface. It generated a launchable application with voxel terrain, a crosshair, and a hotbar. It organized a substantial amount of work across multiple files and handled clear implementation instructions well.

The failure appeared in the actual experience. Turning and breaking blocks did not function properly. The game also did not consistently preserve the logic and visual style I wanted. Following a visual identity is not a palette swap at the end; it is another constraint the model has to maintain while making implementation decisions.

## The missing interaction test

The final report disclosed a specific limitation: the environment lacked a Wayland capture or input-injection tool. The agent described scripted input-path checks rather than testing the application through actual mouse and keyboard events.

That leaves a gap between testing internal game logic and testing how a person operates the window. A compiler can accept the code while the camera controls remain broken. The disclosure was useful, but the missing interaction check still had to happen before I could consider the game finished.

For anyone assigning a desktop application to an agent, the lesson is practical: make sure its tools can exercise the actual interface, not only build the project.

## Why 74 tokens per second did not feel fast

In my notes, MiniMax generated roughly **74 tokens per second**, compared with **20** for DeepSeek and **26** for GPT. Those observations came from my setup, not identical serving conditions.

The text arrived quickly, but the overall task still felt slow. The source recording is about 78 minutes long and includes development, tool activity, compilation, and revisions, not just model inference.

Token speed measures how quickly output is generated. It does not measure how much output the model needs, how many times it revises its approach, or how long the surrounding tools take. That is what I meant by overthinking in my notes: the session kept going without delivering a result that justified the wait.

For your own comparison, measure elapsed time to a passing result, alongside token speed. Keep the starting files and tools the same, and count manual corrections.

## The $3.78 session and the pricing change

The recorded build ended at **$3.78**. For context, MiniMax was cheaper than Opus and GPT, but not cheaper than Xiaomi's MiMo or DeepSeek. Against those alternatives, I do not consider it good value, especially after accounting for supervision and unfinished functionality.

MiniMax's current API list prices are **$0.15 per million input tokens**, **$0.60 per million output tokens**, and **$0.015 per million cached input tokens**. These are unit prices, not a recommendation or a reconstructed invoice.

The subscription presentation also changed. An older screenshot gave approximate monthly token allowances. The newer cards describe Explore as three times Go usage and Build as seven and a half times Go usage, without an absolute allowance on those cards. A multiplier is harder to budget around when the baseline is unclear. The documentation does explain five-hour and weekly usage windows, and the discounted prices in the newer screenshot apply to the first month, not every renewal. Subscription allowances and API token purchases are separate products. A separate screenshot showing **$3.94** is not a matched-task comparison with the **$3.78** recorded run.

## Verdict

I do not recommend MiniMax M3.1 for interactive coding. It can follow clear instructions and make good coding decisions, but its broader reasoning and consistency were not good enough in this session. Fast tokens did not compensate for a long run that left basic controls broken and dropped my style requirements.

My impression is that this is a benchmark-maxed model: more convincing on familiar tasks than when asked to preserve my specific constraints. That is an assessment, not an allegation of cheating, and one recorded session is not a universal benchmark.

I would focus on Xiaomi's MiMo or DeepSeek instead.

## Sources and scope

- [MiniMax M3.1 Flash launch](https://www.minimax.io/blog/minimax-m31f) — release, capabilities, and the vendor-reported DeepSWE result.
- [MiniMax model invocation](https://platform.minimax.io/docs/guides/text-generation.md) and [capability page](https://agent.minimax.io/tools/m3.1-flash) — context, modalities, tool workflows, and reasoning effort.
- [MiniMax API pricing](https://platform.minimax.io/docs/pricing/overview.md) — input, output, and cached-input rates.
- [M Plan overview](https://platform.minimax.io/docs/m-plan/intro.md) and [usage rules](https://platform.minimax.io/docs/m-plan/usage-rules.md) — tiers and usage windows.

This article is compiled from my recorded hands-on test and the project's source notes. It does not claim a controlled benchmark, a matched comparison against every model, or a reproduction of MiniMax's vendor results. The preview and Flash labels refer to the same M3.1 model by owner confirmation. Footage inspection was not end-to-end playback, and the final report's input-verification limit is part of the evidence.

---

### Article: cairn-autonomous-ai-cyberattacks
- URL: https://www.kaganerkan.com/pages/posts/cairn-autonomous-ai-cyberattacks
- Section: News

---
title: "Cairn AI Attacks: Why the Execution Loop Matters"
description: "Cairn's reported attacks expose the engineering of autonomous intrusion: shared state, adaptive execution, uncertain economics, and dashboard security."
slug: cairn-autonomous-ai-cyberattacks
language: en
content_type: article
status: draft
date: 2026-10-19
source_report_date: 2026-10-19
researched_on: 2026-10-20
image: /assets/blog/cairn-autonomous-ai-cyberattacks-1200.webp
image_small: /assets/blog/cairn-autonomous-ai-cyberattacks-600.webp
image_alt: "Pixel-art diagram of an autonomous AI attack execution loop."
keywords:
  - Cairn AI agents
  - autonomous AI cyberattacks
  - agentic cybersecurity
  - AI agent architecture
  - autonomous intrusion economics
---

# Cairn AI Attacks: Why the Execution Loop Matters

## Summary

This analysis examines the Reuters reporting and NorForge research on malicious use of Cairn agents, published on October 19, 2026. It explains the reported shared-state architecture, compares agent-directed execution with conventional automation, and analyzes the relationship between persistence, human attention and outcome validation. It also derives a clearly bounded cost-per-goal sensitivity calculation and identifies engineering implications for systems that collect sensitive findings and execute actions over time. Reported observations, uncertain estimates and editorial conclusions are distinguished throughout.

## The important result happened outside the conversation

In its [Cairn investigation](https://norforge.com/blog/inside_cairn), NorForge says it checked a completed task and found the reported uploader artifact on the victim's website. That is a narrow but consequential observation: something changed outside the agent's conversation. It is stronger evidence than a dashboard declaring success, though it does not validate every project in the investigation.

[Reuters' reporting](https://www.insurancejournal.com/news/national/2026/10/19/889528.htm) attributes a broader finding to researcher Snorre Fagerland: commercially available agents could carry out complex intrusions from start to finish without human intervention after receiving their initial instructions. Reuters independently reviewed Cairn activity to establish victims' identities; this article does not reproduce that investigation.

The engineering lesson is not that a chatbot suddenly became an infallible hacker. It is that **shared task state, tools and a continuing execution loop can turn one assigned objective into work that outlasts a human interaction**. Understanding that loop is more useful than treating “autonomous” as a synonym for either intelligence or guaranteed success.

## What the published architecture actually establishes

NorForge describes a Cairn project as an origin, a goal and a succession of *intents* and *facts*. Agents place discoveries on a project-internal blackboard available to other workers. An operator can add hints to the same board. Those are the [researcher's architectural observations](https://norforge.com/blog/inside_cairn), not implementation details inferred from a product name.

The important relationship is between observation and the next action. A result can become shared context; that context informs what an agent decides to do next. A failed approach need not end the project or require a person to manually reconstruct everything learned so far.

Shared state also creates an engineering tradeoff. It makes discoveries reusable, but it can make mistakes reusable too. A blackboard entry labelled a “fact” is not automatically a validated finding. The report does not establish how Cairn checks those entries, resolves conflicts between workers or prevents a mistaken inference from steering later actions. Error propagation is a design concern derived from the architecture—not a failure demonstrated by this investigation.

Nor does the public description establish a database design, crash-recovery guarantee or worker-context construction policy. Persistence here means task continuity across actions and discoveries. It should not be inflated into a claim about durable restart behavior that the sources do not document.

NorForge also lists browser automation, security tools and general-purpose runtimes in an observed worker environment. Those are the system's means of observing and affecting external services; an available tool inventory is not a per-task execution trace. Without that trace, the report cannot tell us which component supplied the decisive capability in every successful chain. That is another reason to assess the execution system rather than assign every outcome to the named model.

## This is not a choice between a scanner and a brain

Ordinary security automation is not limited to one fixed probe. The [official Nmap Scripting Engine documentation](https://nmap.org/book/nse.html) describes parallel execution and a general-purpose scripting language supporting varied networking and security tasks. Hand-authored automation can branch, chain actions and respond to results.

The useful comparison is **where the next-action policy comes from**:

| System | What determines the next action? | What a successful run does not establish |
|---|---|---|
| Advice-only chat | A person interprets the answer and decides what to execute | That the model can operate tools or complete the task independently |
| Hand-authored scanner or pipeline | Configured logic, checks and explicitly programmed branches | That it can devise an effective new sequence outside the authored policy |
| Model-directed agent loop | A model selects steps from current observations and task context, within its runtime and tool constraints | That its plan is correct, every tool action works, or its success claim is independently verified |

This is not a claim that Cairn invented the pattern. The [2022 ReAct paper](https://arxiv.org/abs/2210.03629) already studied interleaving reasoning and actions, using interaction to gather information and update plans. That is useful conceptual context, not evidence that Cairn implements ReAct or that results on unrelated benchmarks transfer to cyberattacks.

The operational distinction is that the surrounding system can keep taking actions and carrying their results forward. Intelligence matters inside that loop; it is not the whole system.

## Twenty-three hours is latency, not twenty-three human-hours saved

NorForge reports that goal-reaching tasks in the relevant activity cluster averaged a little under 23 hours from start to goal, with a wide range. This is a [conditional wall-clock measure](https://norforge.com/blog/inside_cairn): it concerns tasks reaching their goals, not every attempt.

It does not reveal continuous compute utilization, the number of concurrent workers or the amount of human attention required. A long task could contain useful investigation, repeated failed approaches, tool delays or waiting. Without traces and a comparison baseline, duration cannot be converted into labor saved or attributed solely to reasoning ability.

Where a task continues without step-by-step operator direction, work can proceed without continuous human attention. The duration estimate does not establish how much unattended work occurred in those particular tasks or how much labor it displaced. An overlooked web property may face sustained experimentation rather than a single unsuccessful check followed by abandonment; that is an operational implication of persistent execution, not a measured increase in compromise probability.

The tempting thesis—“persistence matters more than intelligence”—goes further than the evidence permits. The investigation does not isolate model capability from tool access, orchestration, target selection, concurrency or repeated attempts. Persistence without useful decisions can simply accumulate failed work and spending. The defensible argument is that the **execution system contributes leverage that model intelligence alone does not describe**.

## Autonomy and verified outcomes are different axes

An autonomous task can fail. A human-guided task can achieve a real intrusion. Evidence for one property does not settle the other.

NorForge explicitly warns that project goals vary: establishing a weakness is not equivalent to obtaining access. Its estimate of a goal-reaching fraction around 10% across heterogeneous activity is therefore not a universal breach-success rate. Its real-world checks of particular intrusions strengthen those cases, not every task flag in the dataset.

The reporting's scale figures also have different units. Reuters describes more than 1,200 attempted sites and intrusions involving websites belonging to more than 100 companies. NorForge's largest-cluster snapshot contains more than 1,100 projects. Dividing a company count by a site or project count would not recover a properly defined campaign success rate.

Impact is another question again. Reuters could not establish the extent of unauthorized extraction. Deere reported no indication sensitive information was accessed; SharkNinja described a contained incident on a standalone support site; Cummins was investigating a third-party website report. These are [attributed company responses](https://www.insurancejournal.com/news/national/2026/10/19/889528.htm), not proof of either universal theft or universal safety. Website access is not automatically compromise of an entire corporate network.

## What the token economics can—and cannot—show

[Reuters reports Fagerland's estimate](https://www.insurancejournal.com/news/national/2026/10/19/889528.htm) of roughly $5,000 in campaign token spending and about $50 per successful intrusion. [NorForge's own text](https://norforge.com/blog/inside_cairn) estimates roughly $5 per project when unsuccessful and early-ending projects are included. It explicitly lacks actual token-use figures and warns that its estimates may be substantially wrong.

There is still a useful accounting relationship to examine. For a consistently defined cohort:

**Token cost per reached goal = mean token cost per project ÷ goal-reaching fraction.**

This follows by dividing the same total token bill by completed goals rather than total projects. It does not require independent attempts. It does require consistent projects, outcomes, observation windows and cost coverage—conditions the published snapshots do not establish well enough for an independent campaign calculation.

Here is a sensitivity analysis holding mean project token cost at the primary report's rough estimate. The alternative fractions are **hypothetical assumptions**, not observed campaign groups; “goal” does not mean independently verified intrusion.

| Assumed goal-reaching fraction | Assumed mean project token cost | Derived token cost per reached goal |
|---:|---:|---:|
| 5% | $5 | $100 |
| 10% | $5 | $50 |
| 20% | $5 | $25 |

The middle row shows how the headline order of magnitude can arise from assumptions. It is not independent corroboration of those assumptions or a reconstruction of an actual invoice.

The engineering consequence is that cheap tokens alone do not guarantee cheap outcomes. A cheaper model may also change task length and the goal-reaching fraction; the cost per result depends on all of them. The examined reporting does not measure those tradeoffs. Hosting, setup, operator effort and other expenses are outside this token-only calculation.

“Websites can be hacked for $50” discards both the uncertain inputs and the outcome definition. It is not a defensible general price claim.

## The dashboard is a second security boundary

NorForge found exposed panels associated with multiple activity clusters and also apparently legitimate testing operations. The interfaces revealed target information, discovered weaknesses and sensitive inputs. Collecting evidence in one place can create exposure even when the underlying assessment never achieves its goal.

The researcher also described apparent administrative controls, but explicitly did **not** test whether those controls worked without authorization. That limit matters: the report does not establish that outsiders took over running agents.

Two distinct responsibilities nevertheless follow from the published design. First, collected findings need confidentiality and retention controls independent of whether a project succeeds. Stopping a task does not, by itself, erase the secrets already collected. Second, if shared hints and discoveries influence subsequent actions, their integrity becomes part of the execution boundary. Read access, write access and authority to direct work should not be treated as the same permission.

For builders, a further implication is temporal: authorization must remain valid while work continues, not merely when a person initially launches it. Scope, tool privileges, spend limits and expiry need enforceable runtime boundaries rather than reliance on a planner remembering them. Expiry should prevent subsequent tool execution, not merely add a request to stop to the model's context. These are engineering recommendations drawn from the observed architecture and exposure, not controls tested by this article or evidence of a particular unauthorized-control exploit.

For defenders of targeted sites, the corresponding implication is to retain and correlate investigation context across repeated activity rather than assume a failed probe ends an operator's interest. The reported task duration is not a recommended log-retention period: a mean calculated only from goal-reaching tasks cannot set that boundary. This is a reasoned monitoring priority, not a detection strategy evaluated by NorForge.

The lesson is therefore broader than “protect the dashboard.” A system that can keep acting needs a matching way to bound what it may do, distinguish discoveries from verified evidence, and preserve those limits over time. The work loop supplies leverage; the validation and authorization loops must keep up.

## Sources and scope

- [Raphael Satter / Reuters, via Insurance Journal, October 19, 2026](https://www.insurancejournal.com/news/national/2026/10/19/889528.htm).
- [Snorre Fagerland / NorForge, “Inside Cairn,” October 19, 2026](https://norforge.com/blog/inside_cairn).
- [Yao et al., “ReAct: Synergizing Reasoning and Acting in Language Models,” October 6, 2022; abstract examined](https://arxiv.org/abs/2210.03629).
- [Nmap Scripting Engine, official documentation, chapter introduction](https://nmap.org/book/nse.html).

This article analyzes published evidence. It does not claim original incident reporting, access to live systems, inspection of private campaign logs, independent intrusion testing or controlled comparisons of agent performance. Contextual research is not independent corroboration of the incident, and the economic sensitivity table is not a measured campaign bill.

*Tags:* #documentation #engineering #architecture #engineers #draft

---

### Article: deepseek-v4-1-flash-1017-benchmarks
- URL: https://www.kaganerkan.com/pages/posts/deepseek-v4-1-flash-1017-benchmarks
- Section: News

---
title: "DeepSeek V4.1 Flash 1017 Benchmarks: What Changed?"
description: "DeepSeek V4.1 Flash 1017 is the cheapest model I have used for serious coding, and it feels faster than its price. Official benchmarks, hands-on results, and the caching advantage."
slug: deepseek-v4-1-flash-1017-benchmarks
language: en
content_type: article
status: ready
date: 2026-10-18
image: /assets/blog/deepseek-v4-1-flash-1017-benchmarks-1200.webp
image_small: /assets/blog/deepseek-v4-1-flash-1017-benchmarks-600.webp
image_alt: "Pixel-art comparison of DeepSeek V4.1 Flash 1017 benchmark changes."
keywords:
  - DeepSeek V4.1 Flash 1017 benchmarks
  - DeepSeek coding benchmarks
  - Terminal-Bench 4.0
  - AI coding agent evaluation
  - cost per successful task
---

# DeepSeek V4.1 Flash 1017 Benchmarks: What Changed?

## Summary

DeepSeek V4.1 Flash 1017 is the model I am running now, and my short verdict is **cheap horsepower**. It handles many coding tasks as well as, or better than, models that cost far more, and it is exceptionally fast for its quality.

The official numbers show gains across all eleven rows in DeepSeek’s September-to-October comparison, including Terminal-Bench 4.0 moving from 31.2 to 42.3. Those results do not represent real-life coding experience. This review keeps the vendor data and my hands-on experience separate, because they answer different questions.

## What is DeepSeek V4.1 Flash 1017?

DeepSeek describes 1017 as a **minor update to V4.1 Flash**, not a new model architecture. The checkpoint was announced on October 17, 2026. In the documentation I checked, the hosted `deepseek-flash` alias pointed to this updated snapshot. See the [release announcement](https://api-docs.deepseek.com/news/news261017/) and [1017 model card](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017).

A stable-looking API name can still point to changing weights. Record the exact served version and the run date, not just the name shown in your coding tool.

The weights are MIT-licensed, but open weights do not make a 552-billion-parameter mixture-of-experts model easy to run locally. The [September model card](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash) describes a one-million-token context window, and a [community deployment report](https://github.com/tonyd2wild/DeepSeek-V4.1-Flash-vLLM-DGX-Spark/blob/main/runs/2026-10-17-1017/README.md) lists roughly 510 GB of checkpoint files.

Parameters and file size measure different things, and the community four-node DGX Spark setup is one reported deployment, not a hardware requirement. The practical point is simpler: the hosted model is cheap to use; serving the full checkpoint yourself is a separate project.

A million-token context limit is an input allowance, not proof that the model reasons perfectly over every token in a huge document.

## The official benchmark numbers

The October model card compares the September checkpoint with 1017 across eleven benchmark rows. All eleven are higher for 1017 in the published table. Four examples show the scale:

| Benchmark | September Flash | Flash 1017 | Point change |
|---|---:|---:|---:|
| Humanity’s Last Exam, full, without tools | 36.8 | 42.6 | +5.8 |
| Terminal-Bench 4.0 | 31.2 | 42.3 | +11.1 |
| ProgramBench | 20.3 | 29.1 | +8.8 |
| Apex Bench v1.1 | 64.6 | 72.1 | +7.5 |

**Source:** [DeepSeek’s 1017 model card](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017). These are vendor-reported results, not measurements I reproduced for this article. The rows use different benchmark metrics; they should not all be relabeled as percentages.

The Terminal-Bench move is an **11.1-point increase**, not an 11.1% relative improvement.

The model card also notes that the evaluation harness changed between the September and October runs. I treat the table as vendor data, not a controlled head-to-head experiment. That is a limit on the benchmark comparison; it is not a description of how the model behaves in normal work.

### The older scaffold comparison

The September card reports the same older checkpoint across different agent scaffolds on DeepSWE v1.1:

| Scaffold | Reported DeepSWE score |
|---|---:|
| OpenCode | 65.5 |
| Codex | 65.6 |
| Claude Code | 69.8 |
| DeepSeek Harness Minimal | 72.6 |
| mini-SWE | 74.2 |

**Source:** [September model card, performance across agent scaffolds](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash).

The spread is a reminder that the harness is part of the result. It is not evidence that the model is inconsistent from task to task in ordinary use.

## Cheap horsepower in practice

I am running DeepSeek V4.1 Flash 1017 now. These are results from my own internal testing, not a controlled benchmark run:

- **Coding quality:** It is excellent at coding. In the work I give it, it often matches or beats flagship models that cost much more.
- **Price:** Among the models I have compared, it is the cheapest for work that benefits from caching.
- **Speed:** It feels exceptionally fast relative to its output quality. The combination of speed and price is what makes it feel like cheap horsepower rather than a budget compromise.
- **Consistency:** I have not seen the wide swing in quality that the benchmark caveats might suggest. Across the coding work I have given it, performance has been stable.
- **Scope:** It is not magic on every task. Long, ambiguous projects still need clear boundaries and verification, the same as any coding agent.

This is the part of the review that matters most to me. A model can look ordinary in a benchmark table and still be the one I reach for every day. That is what happened here.

## Why caching changes the price

DeepSeek’s pricing varies by peak and off-peak periods, cached and uncached input, and output tokens. Check the [current pricing documentation](https://api-docs.deepseek.com/quick_start/pricing/) rather than relying on historical rates.

The caching distinction is the important one for real work. Coding sessions reuse the same repository context, instructions, and long prompts. When that context is cached, the effective cost of repeated work drops sharply. That is where 1017 earns the “cheapest” label in my comparison: not because every token is free, but because the work that benefits from caching is exactly the work I do.

Pricing is not the same as cost per successful task. A cheap model that fails and has to be corrected can cost more than a stronger model that finishes. Track failed attempts, elapsed time, and the human supervision each run requires. In my use, 1017’s speed and coding quality are what keep the total cost down, not the token price alone.

## How to compare 1017 fairly in your own workflow

Use tasks that resemble your actual work, not prompts designed to produce attractive screenshots.

1. **Record the exact served snapshot.** Include the provider, date, and any alias-pinning limitations.
2. **Hold the environment constant.** Use the same repository revision, tasks, tools, permissions, and harness version.
3. **Match the execution policy.** Keep prompts, reasoning effort, time limits, token budgets, retry rules, and stopping conditions consistent.
4. **Define acceptance before running.** Check working behavior and final tests, not merely plausible code or the model’s completion claim.
5. **Log complete outcomes.** Record failures, elapsed time, interventions, and billed costs alongside successes.
6. **Repeat trials.** One favorable run is not a reliability estimate.
7. **Separate model and harness experiments.** To compare harnesses, hold the snapshot fixed; to compare snapshots, hold the harness fixed.

I still recommend this discipline even though my own experience has been stable. A fair test is how you find out whether the model fits your work, rather than whether it fits someone else’s benchmark.

## Frequently asked questions

### Did DeepSeek V4.1 Flash 1017 improve by 11.1 points?

The vendor-reported Terminal-Bench 4.0 result rose by 11.1 points. Because the disclosed harness also changed, the table does not isolate how much of that came from the weights alone.

### Is Flash 1017 open source?

The published weights are MIT-licensed. That permits inspection and deployment under the license, but it does not make the checkpoint easy to run on a consumer GPU.

### Is 1017 the best coding model?

For the work I do and the price I pay, it is the best value I have used. I would not claim it wins every benchmark or every task. “Cheap horsepower” is the accurate description: strong enough for serious coding, at a price that changes what you are willing to run.

### Did you run an independent benchmark?

No. My internal testing is separate from the vendor’s published numbers. This article does not present vendor results as my own measurements.

### What should developers measure instead of token price alone?

Measure cost per successfully completed task, alongside acceptance-test outcomes, elapsed time, failures, and human supervision. Cheap tokens are useful only when they produce useful work.

## Bottom line

DeepSeek V4.1 Flash 1017 is cheap horsepower. The official benchmarks show a stronger evaluated system than September, with the usual caveat that vendor tables are not real-life coding experience. My own experience fills that gap: excellent coding, stable behavior, unusually fast output, and the lowest effective price I have found for caching-heavy work.

If you write code with reusable context, this is the model I would try first. Keep the benchmark caveats in mind, but do not let them talk you out of the obvious value.

## Sources

- [DeepSeek V4.1 Flash 1017 release announcement](https://api-docs.deepseek.com/news/news261017/)
- [DeepSeek V4.1 Flash 1017 model card](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash-1017)
- [September DeepSeek V4.1 Flash model card](https://huggingface.co/deepseek-ai/DeepSeek-V4.1-Flash)
- [DeepSeek models and pricing](https://api-docs.deepseek.com/quick_start/pricing/)
- [Community 1017 deployment report](https://github.com/tonyd2wild/DeepSeek-V4.1-Flash-vLLM-DGX-Spark/blob/main/runs/2026-10-17-1017/README.md)

---

### Article: gemini-4-argon-review
- URL: https://www.kaganerkan.com/pages/posts/gemini-4-argon-review
- Section: News

---
title: "Gemini 4 Argon Review: Benchmarks vs. Coding Reliability"
description: "Gemini 4 Argon is impressive but dumb where it matters. A practical review of Google's model for law, documents, research, and coding."
slug: gemini-4-argon-review
language: en
content_type: article
status: ready
date: 2026-10-15
image: /assets/blog/gemini-4-argon-review-1200.webp
image_small: /assets/blog/gemini-4-argon-review-600.webp
image_alt: "Pixel-art summary of Gemini 4 Argon benchmark and real-world test results."
keywords:
  - Gemini 4 Argon review
  - Gemini 4 Argon benchmarks
  - Gemini agentic coding
  - Gemini long context
  - AI document analysis
---

# Gemini 4 Argon Review: Benchmarks vs. Coding Reliability

## Summary

Gemini 4 Argon is **impressive but dumb**. The benchmark numbers are strong, and the model is genuinely useful for legal work, document analysis, research, financial briefings, and anyone already living inside Google’s products. For coding and general autonomous work, I would not choose it.

Its real achievement is not a single benchmark row. It is that Google controls the whole stack: TPUs, data centers, models, and distribution through Search, Chrome, Android, Gmail, and Workspace. Argon shows how much that vertical integration can deliver. It also shows where raw capability stops being enough.

The official numbers below are useful data, but they do not represent real-life coding experience. I keep that distinction explicit.

## What is Gemini 4 Argon best suited for?

My recommendation is to **use Argon for deep analysis and document-heavy work, not as your autonomous software engineer**.

That means comparing long reports, organizing research, explaining complicated documents, and preparing structured first drafts. These tasks benefit from reasoning and a large context window. They still need source verification and human judgment, especially in law, finance, and other high-stakes areas.

For someone already using Google products, Argon fits naturally into that environment. For everyone else, the value is narrower: it is a strong analysis model, not a general replacement for a coding agent.

Google’s [Argon announcement](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/) presents competitive results across software engineering and professional evaluations. Those results are worth examining, but they do not answer how consistently the model behaves inside a real coding workflow.

My criticism of coding reliability comes from my own experience, not a controlled head-to-head study. Other developers report positive experiences, and Google has published successful internal-codebase examples. My point is narrower: I would not trust it as my primary coding agent.

## Gemini 4 Argon benchmarks: what Google reported

Google’s launch materials report several results:

| Evaluation | Reported Argon result | What to keep in mind |
|---|---:|---|
| DeepSWE v1.1 | 77.9% | A software-engineering evaluation, not a universal reliability guarantee |
| Vibe Code Bench | 91.9% | A launch-table result, not a claim about today’s live ranking |
| Vals Finance Agent v2 | 65.4% | Performance on a specific finance evaluation |
| Harvey Legal Agent Benchmark | 19.6% | Must be read within that benchmark and its published comparison |

**Sources:** Google’s [launch benchmark table](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini-4-argon_table_blog.gif), [DeepSWE chart](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini_4_cyber_evals_deepswe.gif), [finance chart](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini_4_cyber_evals_vals_finance.gif), and [legal chart](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini_4_cyber_evals_harveys.gif). These are vendor-published results, not independently replicated measurements from this review, and they do not represent real-life coding experience.

The legal score shows why isolated percentages mislead. A result that looks low may still exceed the other models in the same published comparison. Winning that comparison does not make the model safe for every legal task or a substitute for professional review.

### Do not confuse Argon with Gemini 3.1 Pro

Google also reports a **77.1% ARC-AGI-2 result for Gemini 3.1 Pro**. That is not an Argon score. It belongs to Google’s broader reasoning story, with its own [Gemini 3.1 Pro announcement](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/) and [benchmark graphic](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini_3-1-pro__benchmarks.gif).

My positive observations about smaller Flash models solving math questions are observations about those models, not a new Argon math benchmark.

## Why I still hesitate to use Gemini for agentic coding

A coding agent must do more than produce a plausible patch. It has to understand an existing project, respect its architecture, preserve working behavior, and verify that the change actually works.

The problems I have seen with Google’s models include:

- Deleting tests instead of preserving the project’s checks.
- Modifying unrelated parts of a repository.
- Breaking functionality that already worked.
- Declaring completion without adequate verification.
- Requiring extensive instructions about boundaries and validation.

These are my observations, not measured failure rates for every Argon configuration.

A model can solve difficult problems and still be frustrating as an autonomous agent. If the user has to specify every constraint and inspect every consequence, the apparent autonomy becomes supervision work.

That is why strong coding benchmarks have not changed my recommendation. I would not choose Argon as my primary autonomous coding model based on these results alone. I would test it on representative repository tasks and measure regressions, intervention time, and completed behavior.

For another example of why model scores need context, see my [DeepSeek V4.1 Flash 1017 analysis](deepseek-v4-1-flash-1017-benchmarks.md).

## Understanding the one-million-token context limit

Google’s documentation records an important distinction: an earlier September 30 announcement described a one-million-token output limit, while the [October 13 release](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-argon/) describes a **unified input-output limit of one million tokens** through the Gemini API.

Unified means input and output share that allowance. It does not mean one million input tokens plus another million output tokens.

A large window can hold substantial reports, document collections, or research material. It does not guarantee that every collection fits, that every detail is used correctly, or that retrieval and chunking are never needed. Leave room for the expected response and check whether the model actually uses the relevant evidence.

Capacity is useful. Reliable interpretation is a separate requirement.

## Practical Argon use cases worth evaluating

### Deep research and document comparison

Argon is a strong candidate for comparing reports, explaining technical papers, and organizing evidence from multiple documents. A useful output should separate what the documents say from the model’s interpretation and identify where sources disagree.

For important conclusions, verify the cited passages instead of treating a fluent explanation as proof. The context window makes it easier to supply material; it does not make unsupported conclusions acceptable.

### Financial briefings grounded in current sources

I would consider Argon for daily financial briefings when it has access to current market information, earnings reports, and relevant news.

The condition matters: the model does not become a live market feed because you ask for a morning briefing. Supply or connect the current data, keep its timestamps, and check important numbers. The useful role is organizing information and explaining possible implications, not guaranteeing returns or replacing financial judgment.

The finance benchmark is evidence about one evaluation. It is not a certification of investment advice.

### Legal explanations and structured business drafts

Contracts, inheritance documents, privacy policies, and terms of service contain language people often need help understanding. Argon can summarize clauses, organize questions for a lawyer, and draft a first version from facts you provide.

For a privacy policy, those facts include the data collected, storage practices, third-party services, and user rights actually supported by the product. A polished policy that misstates those practices is not a successful result.

Legal, medical, and financial outputs need qualified review where appropriate. Document assistance is not professional authorization or a guarantee of compliance.

## Why Google’s infrastructure is the real story

My broader argument is that coding-agent performance is only one part of Google’s position.

Google builds custom TPUs, runs large data centers, trains models, and distributes services through Search, Chrome, Android, Gmail, and Workspace. Control over every layer lets Google optimize hardware, software, models, and distribution together. That is the impressive part of Argon, even when the model itself behaves in ways I would not trust for autonomous coding.

Google’s [Ironwood announcement](https://cloud.google.com/blog/products/compute/ironwood-tpus-and-new-axion-based-vms-for-your-ai-workloads) describes its seventh-generation TPU. That is relevant background for the infrastructure strategy, not proof of Argon’s exact serving hardware or a measured cost advantage over every competitor.

There is also a workload-selection argument. Simple requests may not need a flagship model at maximum effort. Smaller Flash models and more capable models can serve different needs. Whether that combination delivers better economics depends on actual service costs and useful outcomes; custom silicon alone does not settle the comparison.

## Can Google improve its coding agents?

Public software-engineering research makes that plausible, not inevitable. [SWE-smith](https://github.com/SWE-bench/SWE-smith), for example, provides resources for creating training environments from repositories, along with task instances and trajectories.

**This is not evidence that Google uses SWE-smith.** The point is that research resources are increasingly available, while Google has substantial research and computing capacity of its own.

Better agents still need reliable planning, tool use, dependency awareness, testing, and restraint around destructive changes. More training resources do not automatically solve those problems.

## Prompting and evaluation checklist

Google’s [prompting guidance](https://ai.google.dev/gemini-api/docs/prompting-strategies#clear-and-specific-instructions) emphasizes clear instructions, examples, and context. In my experience, getting consistent Gemini behavior can require more detail than I would like.

Before adopting Argon for a workflow:

1. Define the desired outcome and what must remain unchanged.
2. Provide relevant documents or repository context, with source dates.
3. Specify the output structure and how uncertainty should be handled.
4. Require checks against sources or working software, as appropriate.
5. Measure supervision and correction time, not just response quality.
6. Repeat representative tasks before trusting a single successful demonstration.

Good prompting helps. It is not a substitute for reliable behavior or verification.

## Frequently asked questions

### Is Gemini 4 Argon good for coding?

Google reports strong coding benchmarks, but my assessment is cautious about autonomous repository work based on reliability and supervision concerns. Test your actual tool-and-model setup before relying on it. The benchmark numbers do not represent real-life coding experience.

### Does Argon support one million input and output tokens each?

The October 13 documentation describes a unified one-million-token input-output limit, not two separate million-token budgets.

### Can Argon replace a lawyer or financial professional?

No conclusion like that follows from these benchmarks. It may help explain and organize information or create first drafts, but important advice and documents need appropriate review.

### What is the strongest case for trying Argon?

Deep analysis and document-heavy work are the strongest use cases in my assessment. It is also the obvious choice for someone already using Google’s products. Evaluate the quality of evidence use, consistency, and human review required, not just the size of the context window.

## Bottom line

Gemini 4 Argon is impressive but dumb. It is a good model for law, research, documents, and people inside Google’s ecosystem. It is not the model I would choose for coding or general work.

The official benchmarks are worth keeping, with the caveat that they do not represent real-life coding experience. The real show is architectural: Google handles every layer, from TPUs and data centers to the products people already use. That is what makes Argon strategically impressive, even when the model itself does not earn my trust as an autonomous agent.

## Sources

- [Google: Gemini 4 Argon announcement](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-4-argon/)
- [Google: October 13 Argon release and unified context limit](https://blog.google/innovation-and-ai/models-and-research/gemini-models/introducing-gemini-4-argon/)
- [Google: Argon launch benchmark table](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini-4-argon_table_blog.gif)
- [Google: DeepSWE evaluation chart](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini_4_cyber_evals_deepswe.gif)
- [Google: Vals Finance Agent v2 chart](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini_4_cyber_evals_vals_finance.gif)
- [Google: Harvey Legal Agent chart](https://storage.googleapis.com/gweb-uniblog-publish-prod/original_images/gemini_4_cyber_evals_harveys.gif)
- [Google: Gemini 3.1 Pro announcement](https://blog.google/innovation-and-ai/models-and-research/gemini-models/gemini-3-1-pro/)
- [Google Cloud: Ironwood TPUs](https://cloud.google.com/blog/products/compute/ironwood-tpus-and-new-axion-based-vms-for-your-ai-workloads)
- [SWE-smith repository](https://github.com/SWE-bench/SWE-smith)
- [Google Gemini prompting strategies](https://ai.google.dev/gemini-api/docs/prompting-strategies#clear-and-specific-instructions)

---

### Article: ai-ethics
- URL: https://www.kaganerkan.com/pages/posts/ai-ethics
- Section: Blog

---
title: "AI Ethics"
description: "My stance on AI: training on public work, originality, accountability, and where human authorship still matters."
slug: ai-ethics
date: 2026-10-20
image: /assets/blog/ai-ethics-1200.webp
image_avif: /assets/blog/ai-ethics-1200.avif
image_small: /assets/blog/ai-ethics-600.webp
image_small_avif: /assets/blog/ai-ethics-600.avif
image_alt: "Pixel-art infographic about AI ethics."
tags:
  - AI
  - Ethics
  - Opinion
keywords:
  - AI ethics
  - AI training data
  - AI originality
  - human authorship
  - AI accountability
---

# AI Ethics

Greetings, fellow internet dweller. Today, I'll discuss my stance on AI. I will explain when I use it and where I stand. This won't be some bland AI disclosure text; it will be more philosophical and reasoned.

## Training on public work

First, I don't believe that AI using material humans produce for educational purposes is unethical in itself. AI generally doesn't reproduce its training data verbatim; it learns patterns, much like humans learn from the information they encounter. However, it can still memorize and reproduce. I see this training system the same way I see a person learning from publicly available information, where we can memorize or remember parts.

## Who pays for the harm

But if AI companies take this stance, I believe we should charge AI for crimes we would have committed, and charge executives and others who authorized it too. I mean, if AI uses a book through piracy, it should pay the fines we would have. ([The Guardian](https://www.theguardian.com/technology/2025/jan/10/mark-zuckerberg-meta-books-ai-models-sarah-silverman))

Similarly, if their AI impersonates an artist, they should be charged for that too. ([Futurism](https://futurism.com/artificial-intelligence/chatgpt-caught-putting-signatures-of-real-cartoonists-on-ai-generated-comics)) Or if their AI is involved in defamation, they should be charged too. ([Wired](https://www.wired.com/story/a-court-has-ruled-that-google-is-liable-for-false-statements-generated-by-ai-overviews/))

As you have realized, I could keep going for days; these AI chatbots have done so many things that would land a human in legal trouble.

The only exception I can see is open-weight models that can run on consumer devices, because they could be seen as a public service. But this is an ethical claim, not a legal one. And this exception would be to provide an incentive for AI companies to develop AI in that way.

## The originality argument

On the originality criticism, I disagree with many people: AI is original. You've seen the same model produce artwork across millions of accounts and industries without live training. It's as if you take an artist and revert their mind and skills to where they were.

I mean, the literal AI slop sites you have are nice-looking sites that turned ugly in your mind because, generally, all of them are designed by idiots who never fact-check a dumbed-down version of themselves. Thus, what you call AI slop is AI's original style.

## The AI channel

That said, I respect work AI does the same way I respect work done by freelancers for others. For example, I have a human channel and an AI channel because I need to match other channels' posting speed on new developments, even though I am a high schooler with a heavy workload.

There is no feasible way to do it all by hand and match the speed of people who do this for a living, while also getting early access. So what I do is use AI to get it done.

I acknowledge that I didn't make that video, but I own it. Think of it like Netflix licensing or buying rights to a show when its own library can't reach the numbers it needs.

These days, I am a student preparing for both the American and Turkish education systems, and I also do these as hobbies and future investments. Every reader I acquire today means one more reader I can reach directly when I start a startup.

## Where AI is a tool

Beyond that, I think AI can be useful and ethical in many cases. Specifically, I mean AI used as a tool. Even in my AI-managed channel, I tell the short-video script generators what I want them to claim, then verify it to protect factual authority.

When I write scripts (for long-form videos on both channels), I tend to make grammar mistakes, so I use AI to help me spot and correct them. These are very okay uses in my eyes.

## What I'd change

If I could change anything in my pipeline, I'd have the AI channel dubbed by me. Since I'm already heavily involved in long-form videos' scriptwriting and AI only handles grammar correction and virality revisions, I would love to voice them myself.

I think that is the biggest upgrade I could give that channel, since AI voices aren't quite there, and I am not bad at voice acting. However, I do need time to read that in two languages without someone interrupting my audio.

---

### Article: the-first-post
- URL: https://www.kaganerkan.com/pages/posts/the-first-post
- Section: Blog

---
title: "The First Post"
description: "IELTS, study plans, building in public, and why I keep a human-made channel and blog alongside an AI-assisted pipeline."
slug: the-first-post
date: 2026-10-20
image: /assets/blog/the-first-post-1200.webp
image_avif: /assets/blog/the-first-post-1200.avif
image_small: /assets/blog/the-first-post-600.webp
image_small_avif: /assets/blog/the-first-post-600.avif
image_alt: "Pixel-art dashboard of plans and projects."
tags:
  - Personal
  - IELTS
  - Plans
keywords:
  - IELTS
  - study plans
  - building in public
  - human-made content
  - AI channel
---

# The First Post

Greetings, internet dwellers. Today I took my IELTS exam. It was a great break, as I normally study from 6:30 am to 9:00 pm.

Speaking is my favorite section because I get to yap about a random topic. I mean, compared to solving calculus questions and preparing for two countries' curricula, IELTS is child's play. The only part I struggle with is writing, although I think I'll get at least a 7 this time.

They gave me a keyboard with an English layout, though. That made me struggle a bit, since it was the second time in my life I'd written on a layout other than Turkish Q.

## The course

I also went to my after-school course. I know I said it was like a cheat day, but an exam is the longest break you can take when you need to study two different curricula. (The em dash was mine, not AI; I like em dashes, kill me for it if you must.) In this course, though, I didn't go too hard on myself and solved simple SAT math questions.

I also plan to make a "How to Study for the SAT" video—on my human, authentic channel—and create study materials to display on a separate page of my website. Those materials will include the methods I used to study, along with common pitfalls.

I learned about a closed beta program at the place I get exam courses, which I'll briefly explain in this video. I believe that program can eliminate many of those pitfalls and stop liars. (By "liars," I mean the university admission counselors in my nation. While the field is real and needed, it is flooded with cash-grab scams. I will talk about them in a later post.)

## Why I bother with the web

You might also ask why I bother doing this much on the web. To that, I would tell you to ask Gemini, “Who is Kagan Erkan?” It will tell you that I am a successful, award-winning student.

It will yap about the Stanford one-month biomedical team observership experience I won—which I will make a video on. That is a certain privilege many people don't have.

For a Google engineer, status comes with a paycheck, but for a student or new grad? It comes down to how fast you can introduce yourself. Now, if I send someone with high status a LinkedIn connection request, I can skip the cringe part of praising myself: the AI assistant (that they hired by kicking the human one out) will cite my website to praise me.

## Playing their game

Also, you might be confused about a guy who produces “AI slop”—even though I do quality control, I'd still call it that—and criticizes AI. It is simple: I am playing the game they set for me.

I wasn't asked when they started building SI (superintelligence), so I am building the core of my engine with the best tools while keeping my humanity in my blog and my own human-made channel. This is the best method I've found: I can compete with news and other fast-paced content using a fully local, AI-generated channel, while still keeping my sanity by being human in my own human-made channel.

Think like a gardener having a hobby farm or flowers on their porch. They don't need it, and it seems stupid to relax by doing the same thing.

However, doing it because I like it is very different from doing it for views (or cash in our metaphor) or others' appreciation. For the same reason, to this day I still code with pen and paper in my free time. I started automating and coding because it was fun, not because it was making money, and I do not plan to stop because some AI bros told me to stop.

## What I'm building next

So, I do have a lot of plans for before and after I leave for university. I have yet to mention even 1% of what I am actually planning to build.

I have domains, ideas, code, and more ready that I cannot share because of time constraints. I have a lot of things I wanna do, but I have no idea how to do them. Still, I'll complete them one by one over time. For example, I wanna make the website you're reading this from into a hub for my multiple WebAssembly-based tools.