This week is about familiar ideas taking on new meaning in the agent era: an informal pelican benchmark gets tested for contamination, context windows become a pricing decision rather than a bragging right, and Git worktrees turn into a practical way to keep parallel coding agents from stepping on each other.

📖 Story 1: Are AI labs pelicanmaxxing?

dylancastillo.co · Read

Dylan Castillo tested whether AI labs are optimizing their models for Simon Willison’s famous “pelican riding a bicycle” prompt. He generated 1,008 SVGs across seven models and 48 animal-and-vehicle combinations.

The pelican ranked sixth among eight animals, bicycles ranked second-to-last among six vehicles, and the complete pelican-on-a-bicycle prompt finished 42nd out of 48 combinations. After adjusting for difficulty, Castillo found little evidence that any lab had specifically trained for the benchmark.

The experiment is small—three samples per prompt and a single LLM judge—but the result points toward a more ordinary explanation: models are getting better at SVG generation generally, rather than secretly pelicanmaxxing.

💬 HN Discussion

Some commenters pointed out that Google has discussed improving SVG generation openly. The concern was not necessarily that a model had memorized one pelican, but that it may have learned a reusable template for prompts shaped like “animal X doing activity Y.”

Others argued that this would not really be cheating. If training on SVG generation makes a model better at spatial reasoning and writing graphics code more generally, that is a useful capability. It would be like “benchmarkmaxxing” a weightlifting competition by genuinely becoming stronger.

There was also the recurring criticism that the pelican prompt has outlived its usefulness. It does not test the long-running tool use, planning, debugging, and context management that now matter most for coding agents. At best, it is one memorable qualitative test—not a serious ranking of which model is best.

Still, the absurdity is part of why it works. Any public benchmark can eventually become contaminated once it becomes visible and valuable enough. The pelican gives us a small, entertaining experiment for testing whether that contamination is already happening.

For now, the answer appears to be no. The labs may be improving at SVGs, but they probably are not secretly producing terabytes of training data featuring pelicans on bicycles.

→ Discuss on Hacker News

📖 Story 2: Kimi K3 Adds a 256K Mode That Uses Half the Quota

kimi.com · Read

Kimi has introduced k3-256k, a new configuration of Kimi K3 with a 256,000-token context window.

This is not a smaller model. Within the 256K window, Kimi says it produces the same results as the full K3 configuration while consuming roughly half as much subscription quota. The regular k3 configuration continues to support contexts of up to one million tokens.

For most coding sessions, 256K may already be plenty. Kimi recommends the new configuration for everyday questions, code completion, routine feature development, and edits involving one or a few files. The full one-million-token version remains useful for large codebases, long-running research sessions, and workflows involving video, which k3-256k does not support.

The release also makes context size feel less like a benchmark number and more like a product setting. A larger context window costs more to serve, and keeping every previous tool call, failed attempt, and piece of research in the conversation is not always helpful. Sometimes a smaller, cleaner context is both cheaper and better.

Switching configurations can also introduce some overhead. Kimi generally recommends starting a fresh session, while conversations that already exceed 256K may need to be compacted before moving to the smaller window.

💬 HN Discussion

The Hacker News discussion quickly turned into a debate over how much context coding agents actually need.

Some developers argued that 256K is already generous when the harness uses subagents, writes plans to files, and starts fresh sessions instead of preserving an entire project history. Others said large refactors and research-heavy work can exhaust that window quickly, forcing repeated compaction and potentially losing useful reasoning.

Another theme was that maximum context is not free. The cheapest model on paper may still use more tokens, and a giant context window can increase both quota consumption and noise. Several commenters described “right-sized context” as more useful than automatically selecting the largest window available.

The discussion also returned to the limits of open weights. Kimi K3 may be open, but its enormous size means that self-hosting the full model remains a data-center project. For most developers, the practical benefit is therefore provider choice rather than genuinely local inference.

→ Discuss on Hacker News

📖 Story 3: Git Worktrees Are Becoming Infrastructure for Coding Agents

dev.to · Read

Git worktrees are not new, but AI coding agents are making them much more relevant.

Normally, a Git repository gives you one active working directory. You can create as many branches as you like, but switching between them means changing the state of that directory. Uncommitted work has to be committed, stashed, or carried across the switch.

Worktrees change this. They let you check out multiple branches from the same repository at the same time, with each branch placed in its own directory. One workspace can remain on a feature branch while another contains a bug fix or pull request.

For a human developer, this removes a lot of context switching. You no longer have to stash unfinished changes just to review a pull request or fix something urgent. The article even provides aliases for creating, listing, and removing worktrees, plus a small command that checks out a GitHub pull request directly into its own workspace.

For coding agents, the idea becomes even more useful.

Instead of allowing several agents to operate inside the same directory, each task can receive its own branch and worktree:

• one agent implements a feature;
• another investigates a bug;
• another updates the tests;
• and the developer keeps the main workspace open for review.

Each agent gets an isolated filesystem state, so it can edit files, run commands, and create commits without another agent switching branches underneath it or overwriting its unfinished changes. The worktrees remain attached to the same Git repository rather than requiring a completely separate clone for every task.

This does not eliminate merge conflicts. Two agents can still modify the same code and create conflicts when their branches are combined. But it moves those conflicts to the normal review and merge stage instead of letting the agents interfere with each other while they are working.

Branches give a repository multiple possible histories. Worktrees give those histories multiple active workspaces.

💬 Community Moment

Just one last change before the deadline

🛠️ Projects Worth Checking Out

• franken.domains: Stitched-Together Domains, Because Every Dictionary .com Is Taken
• Herdr: one terminal for the whole herd
• GitHub - drumih/turbo-fieldfare: Gemma 4 26B-A4B inference in ~2 GB of RAM on any M-series MacBook
• GitHub - sqliteai/waste: Run the full 2.78-trillion-parameter Kimi K3 model beyond available RAM by streaming activated weights directly from NVMe.
• GitHub - vectara/FaithBench