DEV Community: claude

This Week in AI Dev: The Week Agents Got Cheaper to Run (Week 28 of 2026)

Rohit Raj — Tue, 07 Jul 2026 03:59:23 +0000

Originally published on rohitraj.tech

Week 28 of 2026 in AI dev tools: Claude Sonnet 5 does Opus-tier agentic work at $2/M input, Alibaba's page-agent controls any web app from one line of JavaScript, OmniRoute routes 231+ providers and cuts 15-95% of tokens, Ternlight ships a 7MB semantic-search model that runs in the browser, Google's TabFM predicts tabular data zero-shot, and Nvidia squeezes Qwen3.6-27B onto a single consumer GPU with NVFP4.

Read the full version with code samples, diagrams, and architecture details: This Week in AI Dev: The Week Agents Got Cheaper to Run (Week 28 of 2026)

More engineering notes: rohitraj.tech/en/notes

Open Source Project of the Day (#117): AgentsView — Session Analytics and Cost Tracking Across 30+ AI Coding Agents, Local-First, No Account Required

WonderLab — Tue, 07 Jul 2026 02:29:41 +0000

Introduction

"Gartner predicts: by 2028, AI coding costs will surpass the average developer salary as token consumption surges."

This is article #117 in the Open Source Project of the Day series. Today's project is AgentsView — a local-first analytics and session management tool for AI coding agents.

You use Claude Code for one task, Cursor for another module, Codex for automation scripts. Each tool has its own session history in its own directory in its own format. You want to know: how much did I spend on AI coding tools this month? Which agent do I use most? Which sessions are worth revisiting? There's no unified answer.

AgentsView does one thing directly: index all agent session data into a local SQLite database, then provide a unified search interface, cost analytics, and dashboard. Single binary, runs locally, no account required, data stays on your machine.

What You'll Learn

AgentsView's architecture: Go + SQLite + Svelte, and why it's 100× faster than re-parsing raw files
The 30+ supported agents and their session directory paths
Practical CLI commands: daily cost summary, session list, statistics
PostgreSQL team sync and DuckDB analytics mirror
S3 support for multi-machine centralized session management
Privacy design: DNS-rebinding protection, local binding, anonymous telemetry

Prerequisites

Regular user of Claude Code, Cursor, or similar AI coding tools
Interest in tracking AI tool token costs

Project Background

What Is AgentsView?

AgentsView is a local-first AI agent session analytics platform. The core logic: every AI coding tool writes session history to local files, in different formats, but all are files. AgentsView parses those files, builds a unified SQLite index, and provides a unified query and analytics interface.

It doesn't change how any tool works. It doesn't insert a proxy layer. It just makes already-existing data queryable.

Author

Author: kenn-io
Website: agentsview.io
License: MIT

Project Stats

⭐ GitHub Stars: ~4,000
🍴 Forks: ~305
📄 License: MIT
💻 Language: Go 81.1% / TypeScript 10.7% / Svelte 5.9% / Rust 1.1%

Core Features

Multi-Agent Auto-Discovery

AgentsView automatically scans session directories for 30+ mainstream AI coding tools:

Agent	Session Directory
Claude Code	`~/.claude/projects/`
Codex	`~/.codex/sessions/`
Gemini CLI	`~/.gemini/`
Cursor	`~/.cursor/projects/`
Forge	`~/.forge/`
Copilot CLI	`~/.copilot/`
Devin CLI	`~/.local/share/devin/`
OpenCode	`~/.local/share/opencode/`
Zed	`~/Library/Application Support/Zed/`
Aider	`.aider.chat.history.md` (opt-in)

All directory paths are overridable via environment variables.

Full-Text Search

Built on SQLite FTS5, indexes all session content across all agents. Looking for a Claude Code session from three weeks ago that discussed an 'auth module refactoring' approach? Full-text search in AgentsView finds it immediately — no manual directory browsing, no grepping raw JSONL files.

Token and Cost Tracking

AgentsView extracts token usage and model metadata from each agent's session data, building a cost view:

# Today's cost summary
agentsview usage daily

# Today's cost with per-model breakdown
agentsview usage daily --breakdown

# Last 7 days
agentsview usage weekly

# Last 28-day statistics
agentsview stats

Typical output:

Daily Usage — 2026-07-07
─────────────────────────────────────────
Agent        Sessions  Input Tok   Output Tok  Cost
──────────   ────────  ──────────  ──────────  ──────
Claude Code  8         1,823,441   142,891     $4.21
Codex        3         284,920     31,204      $0.87
Cursor       12        ——          ——          ——
──────────   ────────  ──────────  ──────────  ──────
Total        23        2,108,361   174,095     $5.08

Analytics Dashboard

The Web UI (http://127.0.0.1:8080) provides:

Usage heatmaps: activity by day and hour
Tool usage statistics: which tools are called most frequently (bash, read, write...)
Velocity metrics: average tokens per session, task completion duration
Project-level breakdown: agent usage patterns by project directory

Recent Edits Feed

A practical feature: displays files recently modified by agents, grouped by project. At the end of a workday, instead of digging through git diff to review what AI changed, AgentsView lists it directly.

Live Updates

AgentsView runs as a daemon, watching for new session data via file watching, pushing live updates to the Web UI via SSE (Server-Sent Events). Active AI sessions show up in the dashboard in real time.

Quick Start

Install:

# macOS / Linux
curl -fsSL https://agentsview.io/install.sh | bash

# Windows (PowerShell)
powershell -ExecutionPolicy ByPass -c "irm https://agentsview.io/install.ps1 | iex"

# macOS Homebrew
brew install --cask agentsview

Start:

# Foreground mode (for debugging)
agentsview serve

# Background daemon (recommended)
agentsview serve --background

# Open Web UI
open http://127.0.0.1:8080

Useful CLI commands:

# Session management
agentsview session list                        # List all sessions
agentsview session list --agent claude-code    # Claude Code sessions only
agentsview session show <session-id>           # View session details

# Cost tracking
agentsview usage daily                         # Today's cost
agentsview usage daily --breakdown             # Per-model breakdown
agentsview usage weekly                        # This week's cost
agentsview stats                               # 28-day statistics

# Search
agentsview search "auth module refactoring"    # Full-text search

# Export
agentsview session export <id> --format html   # Export as HTML
agentsview session export <id> --format gist   # Export to GitHub Gist

Deep Dive

Why 100× Faster Than Re-Parsing Files

AI coding tools write session data as JSONL or Markdown files. Your session history accumulates over time — potentially thousands of files.

Naive approach:
Each search or analysis → re-scan all files → parse each JSONL → filter → return
Grows linearly with file count. With 50,000 sessions: unusably slow.

AgentsView approach:
First run → parse all files → write to SQLite (with FTS5 index + token summary tables)
Subsequent queries → direct SQL queries on SQLite
SQLite FTS5 full-text search: millisecond responses regardless of file count

Incremental sync: after new sessions are written, the daemon watches for file changes and processes only new content — no full re-index.

Three-Layer Storage Architecture

SQLite (primary storage, local, writable)
    ↓ (optional sync)
PostgreSQL (team sharing, read-only service)
    ↓ (optional sync)
DuckDB (analytics mirror, read-only or via Quack protocol)

PostgreSQL team sync:

# Configure PostgreSQL backend
AGENTSVIEW_POSTGRES_URL=postgresql://user:pass@host/db

# Push to team database
agentsview sync postgres push

# Pull from team database
agentsview sync postgres pull

Team members each run AgentsView locally, periodically pushing to a shared PostgreSQL database — creating team-level AI usage dashboards: who uses which tools, organization-wide token consumption trends, high-value session archiving.

DuckDB mirror:

DuckDB's Quack protocol supports remote reads, enabling direct SQL analysis queries against AgentsView data without exporting to files.

S3 Support

Claude Code and Codex session sources can be configured with s3:// paths:

CLAUDE_CODE_DIR=s3://my-bucket/claude-sessions

For developers working across multiple machines, session data can be centralized in S3 and AgentsView builds a local index after fetching.

Technology Choices

Go backend: Single binary distribution, cross-platform, no runtime dependencies, high performance for file parsing and SQLite I/O-intensive operations.

Svelte 5 frontend: Lightweight framework, suitable for embedding in single binary distribution (frontend assets compiled into the Go binary).

CGO dependency: SQLite bindings require CGO, which means pre-compiled binary distribution rather than go install.

Tauri desktop: Wraps the same Web UI to provide native macOS and Windows desktop app experience, backed by the same local HTTP service.

Privacy Design

Data boundaries:
  - Web service binds to 127.0.0.1 (not 0.0.0.0)
  - DNS-rebinding protection: validates Host header, blocks cross-origin requests to local data
  - For external access (reverse proxy / SSH tunnel): use --public-url to explicitly allow

Telemetry:
  - Only anonymous daemon_active ping (version, OS, architecture)
  - No session content, file paths, or user identity
  - Disable with: AGENTSVIEW_TELEMETRY_ENABLED=0

Aider is opt-in (requires explicit AIDER_DIR config) because Aider history files live in repository root directories — automatic scanning would trigger macOS privacy prompts.

Use Cases

Individual developers:

See monthly AI tool spending and which tool gives the best cost-to-value ratio
Retrieve an approach from a session three weeks ago
Understand personal AI usage patterns

Team Tech Leads:

Build team-level AI usage dashboards via PostgreSQL sync
Track organization-wide AI tool cost trends
Identify high-value sessions for team knowledge archiving

Heavy AI tool users:

Switch between 30+ tools and need a unified session history entry point
Compare different agents' efficiency and cost on similar task types

Links and Resources

🌟 GitHub: kenn-io/agentsview
🌐 Website: agentsview.io
📖 Token tracking docs: agentsview.io/token-usage

Conclusion

AgentsView addresses a problem that becomes more real as AI coding tools proliferate: you're using multiple tools, each managing its own data, leaving you with no visibility into the overall picture of usage and cost.

Gartner's 2026 projection — AI coding costs surpassing developer salaries by 2028 — isn't hyperbole. The median Claude Code user already spends $6 per day. A 30-person team at $10 per person per day is $1M per year. At that scale, the gap between 'no visibility into spending' and 'data-informed decisions' is real.

AgentsView's design choices — local-first, single binary, no account required, data stays on the machine — reduce adoption friction and privacy concerns simultaneously. For developers who use AI coding tools heavily every day, installing and trying it is low-cost and likely to surface useful insights.

Explore PrimeSkills — A marketplace for handpicked AI Agents and skills. Each is validated in real enterprise workflows, stripping away hype and keeping only what truly works.

Welcome to my Homepage for more useful insights and interesting products.

Build an MCP Server in Python with FastAPI (2026 Guide)

Sangmin Lee — Tue, 07 Jul 2026 01:30:04 +0000

Originally published at claudeguide.io/mcp-server-fastapi-python

Build an MCP Server in Python with FastAPI: Tools, Resources, Auth (2026)

MCP servers expose tools (callable functions) and resources (readable context) to Claude — the cleanest 2026 stack is the official mcp Python SDK on top of FastAPI in ~50 lines of code. You get streaming HTTP transport, Pydantic-typed tool schemas, bearer-token auth, and a single ASGI app you can ship to Fly.io, Render, or a Mac mini. This guide walks the full path — from pip install mcp to a production server wired into Claude Code via claude mcp add — with working code for tools, streaming resources, and OAuth-style authentication. Tested against MCP spec 2025-06-18 and mcp-python-sdk v1.x.

What is MCP, and when do you need a custom server?

The Model Context Protocol is a JSON-RPC contract Claude clients (Claude Code, claude.ai desktop, the API harness) speak to external programs. The program advertises tools and resources; the client routes user intent to those tools. You need a custom MCP server when the integration you want isn't already in the public registry — internal databases, proprietary APIs, custom workflows over your own filesystem. If a vendor MCP exists (GitHub, Linear, Stripe, Postgres), use that first; build only what's missing.

Stack choice: `mcp` SDK vs raw FastAPI vs HTTPX-only

Three plausible stacks, picked in order of escape hatch:

mcp SDK + FastAPI (recommended). The SDK's FastMCP wraps schema generation, transport negotiation (stdio + streaming HTTP), and JSON-RPC framing. Mounting it inside FastAPI gives you middleware, OpenAPI co-existence, and ASGI deploys.
Raw FastAPI, hand-rolling JSON-RPC. Only do this if you're forking the protocol — the spec is moving, and you'll spend a week catching up to each release.
HTTPX-only client wrappers are not servers; they belong inside a tool, not as a replacement.

Pick FastMCP. The escape hatch is always "add a plain FastAPI route alongside" — both can mount on the same Uvicorn worker.

Minimal working server

Install the SDK and FastAPI:

pip install "mcp[cli]

## Streaming resource: a GitHub repo file listing

Resources are read-only context Claude can pull in without invoking a tool. Streaming matters when the payload is large — Claude can start reasoning before the body finishes:

python

resources/repo.py

import httpx
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("acme-tools")

@mcp.resource("repo://{owner}/{name}/tree")
async def repo_tree(owner: str, name: str) -

Frequently Asked Questions

Stdio or HTTP transport?

Stdio is right for a server that runs as a subprocess of one client (Claude Desktop launching a local Python script). HTTP — specifically streamable-http — is right for anything multi-user, anything deployed, and anything you want to test with mcp-inspector over the network. If in doubt, ship HTTP; you can always wrap stdio later.

How do I authenticate users?

Bearer tokens for service accounts and CI. OAuth (RFC 7591 dynamic client registration, as profiled in the MCP spec) for end users — authlib plus the SDK's auth helpers handles registration, refresh, and scope. Don't invent a custom header scheme; clients won't speak it.

Can MCP servers call external APIs?

Yes — that's the most common shape. A tool is just a Python function; call any REST/GraphQL/database client you like inside it. Keep network calls async, time them out aggressively (10–30s), and surface upstream errors as ToolError with the upstream status code in the message.

What's the rate limit?

There is no protocol-level rate limit — you set it. Claude clients respect server-side 429s, so return them honestly: a Retry-After header on a starlette.responses.Response with status 429 is enough. For per-tool quotas, gate with asyncio.Semaphore plus a token bucket (e.g. aiolimiter).

How do I version my server?

Two layers. The version argument to FastMCP("name", version="1.4.0") is advertised in the initialize handshake — bump on tool-shape changes. Separately, deploy URL paths (/mcp/v1, /mcp/v2) when you make breaking schema changes; let old clients stay on v1 while new clients adopt v2. Never silently change a tool's argument schema in place.

Where to go next

Claude MCP best practices — patterns for tool design, prompt budgeting, and observability
Claude Code MCP (Korean track) — same material, Korean-language deep dive
Claude API error handling — turn upstream failures into tool errors Claude can recover from

A working MCP server is a 50-line file. A production MCP server is the same 50 lines plus auth, error correlation, async hygiene, and a versioned URL — none of which are hard, but all of which need to be there on day one. Start with FastMCP, ship the bearer path first, layer OAuth when real users arrive, and treat tool descriptions as the single highest-leverage prompt-engineering surface in your stack.

Claude vs ChatGPT for Coding in 2026: Which AI Writes Better Code?

devtools-pick — Tue, 07 Jul 2026 00:52:24 +0000

Claude and ChatGPT are both good coding assistants, but they feel different in real use. Claude is the model I reach for when a task needs patience: reading several files, reviewing a messy diff, or explaining why a design is brittle. ChatGPT is the model I reach for when I want a fast generalist: small code snippets, library comparisons, debugging ideas, and a tool that can jump from code to docs to product writing.

The winner in the frontmatter is Claude, and I agree with that for coding-specific work. I would not make it a universal rule. ChatGPT is often easier for mixed tasks and has a broader product surface. For actual software engineering, Claude tends to produce calmer, more structured answers.

Quick Comparison

Category	Claude	ChatGPT
Best coding use	Code review, large context, careful refactors	General coding help, snippets, tool workflows
Strength	Patient reasoning over longer material	Flexible assistant with broad integrations
Weak spot	Can be cautious and verbose	Can overstate uncertain technical facts
Best user	Experienced developer with a specific task	Developer who wants one assistant for many jobs
IDE path	Common in AI editors and coding agents	Common through ChatGPT, API tools, and Copilot-style workflows

Code Generation

For small functions, both are strong. Ask either model to write a debounce helper, a SQL query builder, or a Jest test and you will usually get something usable. The difference appears when the task has hidden constraints.

Claude is better at holding onto the shape of a codebase. If I give it a service method, the repository helper, the existing error style, and a failing test, it is more likely to preserve the local pattern. It also tends to explain tradeoffs in a way that helps me decide what to keep.

ChatGPT is faster-feeling for common patterns. It is good at getting a first version on the page, especially for familiar stacks like React, Node, Python, and SQL. I like it for "show me three ways to do this" prompts because it moves quickly and covers a wide range. The risk is that it may use a library option that changed recently or invent a clean API that does not exist.

Debugging

Claude has the edge for debugging multi-step failures. It tends to trace cause and effect more carefully, especially when the issue spans configuration, runtime behavior, and tests. When I paste a stack trace and several related files, Claude usually produces a tighter list of likely causes.

ChatGPT is still useful for debugging, especially when the issue is familiar: dependency mismatch, bad regex, incorrect async handling, database constraint, or frontend state bug. It can also turn an error message into a search plan or a minimal reproduction. I just ask it to state assumptions explicitly because it can otherwise glide past uncertainty.

Code Review

This is where Claude wins most clearly for me. It gives better review feedback on naming, edge cases, race conditions, and missing tests. It is less likely to fill the answer with generic compliments and more likely to say, "This branch is not covered" or "This helper changes behavior for empty input."

ChatGPT can review code too, but I often need to narrow the prompt: "Focus only on correctness and test gaps" or "Ignore style unless it affects behavior." Without that constraint, it may spend too much attention on readability suggestions that are not worth changing.

Context and Product Workflow

Claude's large-context reputation is one reason developers like it for code. The practical benefit is not just token count. It is the ability to keep more of a problem in view without losing the thread. That matters for migrations, architecture notes, and reviews of generated diffs.

ChatGPT's advantage is the surrounding product. It is easy to use for screenshots, files, browsing, voice, and mixed writing tasks. If your coding question turns into a product decision, a customer email, and a SQL cleanup script, ChatGPT handles the context switch well.

API and Cost Considerations

API pricing changes often, and model selection matters more than brand. A cheap fast model can be perfect for autocomplete or classification. A stronger model is worth paying for when it prevents a bad code change. For production systems, test several representative tasks instead of choosing from a headline benchmark.

I would prototype with both if coding quality matters to the product. Keep a small eval set: one bug fix, one refactor, one code review, one test generation task, and one documentation task. The winner for your codebase may not match a general review.

Our Verdict

Claude wins for coding because it is better at long-context reasoning, code review, and careful multi-file thinking. ChatGPT remains a better all-purpose assistant and is often the easier starting point for developers who want one tool for everything.

My personal setup is simple: Claude for serious code review and complex refactors, ChatGPT for fast exploration and mixed work, and an editor tool like Cursor or Copilot when I want direct file changes.

Try Anthropic ->
Try OpenAI ->

ChatGPT Review — Our deep-dive review of OpenAI's chatbot
ChatGPT vs Claude vs Gemini — The three-way comparison
Best AI API Platforms — Compare API pricing and capabilities

👉 Try Claude → | Try ChatGPT → | Use Both in Cursor →

FAQ

Is Claude better than ChatGPT for coding?

Claude is usually better for code review, long-context analysis, and careful debugging. ChatGPT is better as a general assistant with broad tools and integrations.

Which is better for beginners?

ChatGPT is often easier for beginners because it is conversational and flexible. Claude is excellent once you can provide clearer technical context and evaluate the answer.

Can both models write tests?

Yes. Both can draft unit tests, integration tests, fixtures, and mocks. You still need to check whether the tests assert meaningful behavior rather than copying the implementation.

Which model is cheaper through the API?

Pricing changes by model and provider. For production work, compare current pricing on the official pages and test quality on your own tasks before deciding.

Should I use Claude or ChatGPT inside an IDE?

Use the IDE or agent that fits your workflow. Cursor and similar tools may route to Claude or other models, while Copilot-style workflows often make ChatGPT-family models easy to access.

AI Coding Tools in 2026: Claude Code vs Cursor vs Cline vs GitHub Copilot — Which One Should You Use

Hamza — Tue, 07 Jul 2026 00:21:54 +0000

If you're choosing an AI coding assistant in 2026, the short answer is: pick Claude Code for deep reasoning, Cursor for agentic workflows, Cline for open-source flexibility, or GitHub Copilot if you live inside the GitHub ecosystem.

I verified the pricing and feature claims below against the official product pages and public docs on July 6, 2026. Where possible I cross-checked the numbers against the same sources the research brief used, and the figures hold up.

Feature	Claude Code	Cursor	Cline	GitHub Copilot
Pricing	$20+/mo + token usage	$20-$200/mo tiers	Free / Open source	$10-$39/mo + usage
Open source	No	No	Yes (Apache 2.0)	No
MCP support	Native	Via extensions	Native	Limited / API
Model flexibility	Claude only	High (multi-model)	Highest (any provider)	OpenAI / Microsoft family
Best use case	Complex reasoning, quality	Agentic workflows, multi-file	Privacy, flexibility, customization	GitHub ecosystem, ease of use
IDE integration	Terminal, VS Code, JetBrains	VS Code fork	VS Code extension	VS Code, JetBrains, Neovim
Privacy focus	Moderate	Moderate	High (local models possible)	Low (telemetry)

For most indie developers, Cline's $0 entry point and native MCP support now make it the most pragmatic starting point—but if you need the strongest reasoning engine out of the box, Claude Code still leads on hard architectural tasks.

Claude Code: Quality-First, Anthropic-Native

Claude Code is Anthropic's dedicated coding product, and it shows in how it handles large refactors and architectural reasoning. The tool runs as a terminal CLI, a VS Code extension, and a JetBrains plugin, so it fits into almost every workflow. Its native Model Context Protocol support means it can act on external tools—Figma, databases, internal APIs—without hacks.

The catch is flexibility. You're locked into Claude models, and after August 31, 2026, the standard token pricing moves to $3/$15 per million input/output tokens. For heavy multi-file projects, those costs add up fast. But if you care about output quality more than model choice, Claude Code remains the benchmark.

Cursor: Agentic IDE Experience

Cursor is a VS Code fork built around AI. Its Composer mode handles multi-file edits and refactors far more aggressively than a standard inline completion tool. You can swap models inside the same session—Claude, GPT, Gemini, or local—so you're not stuck with one provider.

The downside is the pricing ladder. Hobby is free, but Pro is $20/month, Pro+ is $60/month, and Ultra jumps to $200/month. If you want deep agent behavior and a seamless IDE feel, Cursor earns its price. If you just want solid autocomplete, there are cheaper options.

Cline: Open-Source, Privacy-First Flexibility

Cline's journey from "Claude Dev" to an independent Apache 2.0 project has been one of the more interesting stories in 2026. It now supports every major AI provider through Bring Your Own Key, runs fully locally if you pair it with Ollama, and includes human-in-the-loop approvals for risky actions.

With 59,000+ GitHub stars and 5 million+ VS Code Marketplace installs, Cline has the credibility of a community-backed tool. Plan mode and Act mode give you explicit control over when the agent touches your codebase. If you care about open source, data privacy, or avoiding subscription lock-in, Cline is the clear outlier.

GitHub Copilot: The Ecosystem Play

GitHub Copilot tightened its integration story in 2026. It now includes agent mode, code review, and PR-native workflows—not just autocomplete. The June 2026 billing switch to usage-based pricing makes it easier to start cheap and scale, though heavy teams often land on Pro+ at $39/month.

Where Copilot wins is simplicity. If your repos already live in GitHub, onboarding is almost zero. The main limitation is model choice: you're mostly in the OpenAI/Microsoft family. For teams that want "it just works" without evaluating five different providers, Copilot is still the default.

How to Choose

Choose Claude Code if reasoning quality and Anthropic ecosystem integration matter most, and you accept a single-model, subscription-plus-tokens bill.
Choose Cursor if you want an AI-native IDE with aggressive multi-file editing and don't mind paying premium tiers for agent depth.
Choose Cline if open source, privacy, BYOK pricing, and maximum provider flexibility are non-negotiable.
Choose GitHub Copilot if you already live in GitHub and value seamless repository integration over model flexibility.

When the Comparison Gets Weird

There's a quiet tension in 2026: the tools with the best reasoning aren't always the most adopted, while the most adopted tools don't always offer the most control. That's the adoption-versus-trust paradox. Enterprises want strong guardrails and vendor stability; indie hackers want model freedom and low cost. No single tool captures both perfectly yet.

FAQ

Which AI coding tool is best for beginners in 2026?

GitHub Copilot and Cursor Hobby are the easiest starting points. Copilot requires minimal setup inside GitHub, while Cursor Hobby gives limited free access to an agentic IDE. For complete control at zero cost, Cline's free tier is surprisingly polished.

Is Cline really a good replacement for GitHub Copilot?

Yes—if you want open-source freedom and the ability to swap models or run locally. Cline lacks Copilot's deep GitHub-native polish, but for day-to-day editing, refactoring, and agentic tasks, it's a legitimate alternative.

Does Model Context Protocol (MCP) matter when choosing a coding assistant?

MCP matters increasingly because it standardizes how coding tools connect to external data, design files, and APIs. Claude Code and Cline offer native MCP support today, which means fewer brittle integrations and faster custom workflows.

References

Originally published on GetYourDozAi

One Entry Point for Your Coding Agent: Organizing Multi-Repo, Multi-Product Context

Vladislav — Mon, 06 Jul 2026 22:25:37 +0000

I work on several products at once. One of them has twenty repositories: microservices, infrastructure, a config repo. A typical task touches three or four repos, and every time I opened a new session with a coding agent, I started with the same routine: explaining which services exist, who calls whom, where the configs are, what the product even does. Session over — explain it all again.

For a while I survived on temporary instruction files: I'd write one per task or per epic and drag it from session to session. But when several people work on the same epic, those files also need careful updating, and for a new task I often ended up feeding the agent a mix of several old instructions at once. It worked, but it was clumsy.

I looked around for how others solve this and found no established approach. Everyone has something home-made: some have CLAUDE.md files in half of their repos, quietly going stale; some have skills and MCP configs copy-pasted across ten projects; notes and temporary files are scattered everywhere. There is simply no standard for organizing agent context across many repositories and products.

So I built my own and packaged it as an open template: agent-workspace. Below is how it works, why it works, and answers to the questions I got when I showed it to colleagues.

The idea

One directory — a single entry point for the agent. Everything lives inside it: all the organizations, products and repositories you work with. The agent always starts from the root.

Context is built in layers — four levels of CLAUDE.md files, four levels of abstraction:

Workspace — base rules for the agent's behavior, not tied to any company.
Organization — briefly, what the business is and what matters to it (a startup and a big company set different priorities), plus company conventions: commit style, shared infrastructure. Personal projects are just one more "organization".
Product — what the product is, which repositories it consists of, and how they relate to each other.
Repository — the low-level details: structure, build, run, gotchas. This file lives inside the repo itself and travels with it.

There is one key rule: every fact lives on exactly one level. How microservices are connected - product level; the build command — repo level. Nothing is duplicated, so nothing has to go stale in two places at once.

Everything machine-specific — local ports, personal dev tokens — goes into CLAUDE.local.md. It is created only at the repository level, next to that repo's CLAUDE.md: the shared file is usually maintained by the team, while the local file is your personal layer of details on top of it, never committed to git.

Besides the levels, the root holds helper directories and a single .claude with all the skills, commands and agents — they work everywhere under the root. The basic structure looks like this:

agent-workspace/
├── CLAUDE.md            # workspace level: base agent rules
├── .claude/             # skills, commands, agents — one set for everything
├── .mcp.json            # MCP servers config
├── org_1/
│   ├── CLAUDE.md        # organization level
│   └── product_1/
│       ├── CLAUDE.md    # product level
│       ├── repo_1/      # a regular git repository
│       │   └── CLAUDE.md   # repository level — lives inside the repo itself
│       └── repo_2/
├── org_2/
│   ├── CLAUDE.md
│   └── ...
├── private/             # personal projects — one more "organization"
├── workflow/            # notes on tasks and work in progress
│   ├── task/
│   │   ├── TASK-123/    # one directory per task: status, notes, artifacts
│   │   └── TASK-456/
│   └── notes/
├── tools/               # small helper scripts
├── TMP/                 # drafts, reports, scripts and other temporary files
└── archive/             # retired and outdated stuff

What it looks like on a real task

Take a product — let's call it Hamsterflow — where a task touches three microservices out of eight repositories. The agent starts from the workspace root and:

Reads the root CLAUDE.md — behavior rules.
Goes down into the organization directory and reads its CLAUDE.md — company context and conventions.
Goes into the product directory and reads the product CLAUDE.md — now it knows all the product's repositories and how they are connected, and understands which three the task will touch.
Enters those three repositories and reads their CLAUDE.md files.

That's it. It didn't scan the neighboring products, didn't touch my notes or personal repos — even though all of that sits in the same directory. It read only the chain along the task path.

The chain gives knowledge about the product, but not about the task itself. For that, the workspace has a dedicated place — workflow/task/<ticket-number>/: a working file with the current status, what's done, where we're heading, and links to fresh docs for the task (the docs themselves go into the same directory; if they live in Confluence — just links). At the start of a session I simply feed this file to the agent — and it instantly knows not only the product, but also where we stopped yesterday.

The starting context after all this is about 27k tokens (not counting the system prompt, tools and MCP), and the agent already knows everything about the product that I usually had to explain. For comparison: without the structure, "figure out how things work here" on the same three services eats 60–120k — the agent immediately starts scanning the projects in depth. With the structure, most of that is already written in the CLAUDE.md files, and when the code does need to be read, the relevant files are found much faster: the modules and key classes are already named in the chain it has read. And this repeats every session, not just once.

An important caveat, to be honest: token-wise this is not always a win. When you know exactly what to fix and where, a narrow prompt pointing at a specific file will save far more than any structure — there's no reason to read the CLAUDE.md chain at all. The win shows up on cross-project tasks, where you can't get anywhere without the picture of how things connect — and the win is first of all in developer time: the agent is up to speed from the first minute, and you don't retell the same story every day.

Keeping it from rotting

The main disease of any docs written for an agent: they quietly go stale. The template treats this with two things.

Every CLAUDE.md carries a date stamp of its last update. And there are two dedicated skills: one creates the files with a fixed structure for each level, the other refreshes an existing file — it takes the date stamp, looks at the commits and code since that date (and the company docs, if Jira/Confluence is connected), removes what's outdated, adds what's new, updates the stamp. You can ask an agent to "update the doc" without any skill — but the skill strictly defines the rules: what counts as the source of truth, what goes on which level, what should not be written at all. The update becomes predictable, instead of a lottery that produces junk and degrades with every iteration.

workspace-manager

The template ships with an agent that manages this structure. You start it with /init_workspace_manager; it asks what you have and sets everything up itself: creates organizations and products, integrates existing repositories — from a local path or a GitHub/GitLab URL. A local repo it copies rather than moves — together with IDE settings and local env files, so the copy runs right away and the original stays intact until you've checked everything.

For every repo it checks whether a CLAUDE.md exists, offers to create or refresh it, and decides (or asks) which product the repository belongs to. The whole move takes an evening.

Its scope is the workspace itself: set up the structure, integrate repositories, keep the CLAUDE.md files and settings up to date. Actual coding tasks you do in regular sessions, without it.

What about teams

The most common question: "isn't this a dictatorship — the whole team has to adopt your structure?" No. Synchronization works in three layers:

Repository-level CLAUDE.md — shared. It lives in the repo itself, gets pushed and maintained by the team, like a README. It works for everyone, whether they use a workspace or not.
Workspace, organization and product levels — yours, personal. A colleague can build their own workspace or not build one at all — nothing breaks for you either way.
Skills, commands, agents — everything in .claude — no need to copy them across twenty microservices. You create a separate repository per product, set up as a plugin marketplace — the official Claude Code mechanism for sharing this stuff. Everyone pulls what they need; updates come with a single command. A plugin enabled at the workspace root works for any product under it.

Context: fears and numbers

"The agent will end up with a giant context, it will crawl everything anyway." In practice — no: reading follows the task path, the rest of the tree is never touched. And there is no indexing that would crawl the whole tree: Claude Code doesn't build an index of the codebase at all — it searches the code on the fly, as needed.

"Skills in the root will bloat the context." Also no: only the name and a short description of each skill get into the context automatically. The full instruction is loaded only when the skill is actually used. MCP servers are worse — they carry descriptions of all their tools and can easily eat 20–30k tokens in total. So the ones you don't need for the current work should be turned off, not left running all at once.

Context degradation on large contexts is worth remembering, but what matters is where it comes from. Modern strong models handle sheer volume reasonably well; what hurts them much more is thematically fragmented context — when different topics and tasks are mixed together and half the content has nothing to do with the current work. Layered reading protects exactly against that: only the chain along the task path gets into the context, and everything in it is about what you're working on right now.

Security

I'll state the obvious, but I can't skip it: working this way, the model sees a lot about your products — architecture, service relationships, code. For me it's simple: corporate accounts, the company has set the rules, customer data never reaches the model. Check how it is on your side — before the move, not after.

One more thing: when a couple of companies and your personal projects sit side by side in one entry point, the agent can accidentally pick up something you never meant to share with the model. Whatever doesn't fit the rules — just don't put it in the workspace.

And basic hygiene: secrets don't belong in CLAUDE.md on any level. Personal dev tokens go into the gitignored CLAUDE.local.md; tokens in the MCP config come from environment variables.

About the Claude coupling

The files are called CLAUDE.md because Claude Code reads them by default — I work in it, and for the first version I chose what's guaranteed to work. If you're on Cursor or another tool that follows the AGENTS.md standard — workspace-manager will offer, during the first setup, to rename all the files and rewrite every mention. To be honest: I haven't tested yet how other agents behave with this structure.

Try it

Clone the template and open it in Claude Code.
Run /init_workspace_manager — it will walk you through the setup and the integration of your repositories.
Delete the org_1/org_2 mock skeletons once you have real content (the agent will offer to).

The template will keep evolving — new skills, commands, agents, improvements to existing ones. For that there's the workspace-update skill: it compares your workspace against the source repository (the template version recorded in your workspace is the baseline), shows what changed, and after your confirmation pulls the updates in — without touching your content: organizations, products and notes stay as they were.

I'm curious how others solve this — if you organize multi-repo context for your agent differently, tell me about it.

By Vladislav, edited with Claude

Want to keep using Fable 5? Teach Opus and Sonnet to "behave" like it.

Yuiko Koyanagi — Mon, 06 Jul 2026 21:45:11 +0000

A while back I wrote about how I use Fable 5 without going token-bankrupt:

Yuiko Koyanagi

Jul 2

Use Fable 5 where it pays for itself

#claudecode #ai #productivity #agents

7 min read

I put Fable 5 in the orchestrator seat — scoping, design, delegation, final review — while the hands-on implementation, testing, shipping, and code review are done by Opus and Sonnet subagents. The expensive model plans and judges; the cheaper models execute. This ran beautifully for most tasks.

There's just one problem. As you probably know, Fable 5 access via subscription ends on July 7. (I'm praying it comes back to subscription someday… 🙏)

The orchestration setup itself works without Fable 5 — but if the model at the top, the one cutting scope and judging everything, gets downgraded, output quality drops with it.

Here's the thing though: Opus and Sonnet are not bad models. Used correctly, they produce genuinely good output. What matters is writing down what to do, how to do it, and what to do when something fails. So before losing access, I decided to document how Fable 5 actually works and hand it down to Opus/Sonnet — as skills.

This post is about what I did and how. Finding a "replacement for Fable" seemed hopeless, so the goal became something else: raise the whole team's capability so that quality holds even with Opus in the orchestrator seat.

The gap between Fable 5 and Opus/Sonnet is not intelligence

To keep using a pseudo-Fable after the shutdown, I started by examining what the difference actually is.

When Opus/Sonnet produce output I didn't intend during everyday engineering, the failures turn out to follow recognizable patterns. For example:

Slapping "use client" at the top of a Next.js page because one button needs an onClick
- …which drops the entire page and its import tree onto the client
Writing fetch with no cache option
- The defaults are opposite between Next.js 14 and 15, but "it works" was only checked on the dev server — hello, production caching surprise
Skipping input validation in a Server Action because it's "only called from my form"
- It's actually a public POST endpoint anyone can hit with arbitrary arguments
Fetching initial data inside useEffect
- An await in a Server Component would do it, without the request waterfall and the layout flash
"Fixing" a failing test by rewriting the assertion
- Don't touch the assertion until you've proven, with evidence, that the code side is the wrong one
Saying "this should work now" without running anything
- Run it first, then conclude whether it works

What matters here: none of these are knowledge gaps. Ask Sonnet directly — "is a Next.js Server Action dangerous without input validation?" — and it answers correctly. The knowledge is in there. What's missing is the correct procedure.

Fable 5 runs these checks implicitly, without being asked, and pushes back when something's off. With Opus/Sonnet, those checks have to be written down explicitly.

Raw reasoning differences are real, of course. But for routine implementation, review, and debugging, most of the observable quality gap comes down to discipline, sequencing, and verification — and all three can be written as skills.

"Be careful" prompts don't work

My first attempt at Fable-izing Opus/Sonnet was writing "be careful, always verify, follow best practices" into the prompt. Result: nothing happened (obviously, in hindsight). A sentence that doesn't change the model's next move doesn't change its behavior.

So the first rule of documenting Fable's working method was a ban list. No line may contain:

"be careful" / "follow best practices" / "think hard" / "ensure quality"

Every line has to be executable or checkable — runnable as a command, defined as a threshold, expressed as if/then, or greppable as a pattern. It must be unambiguous what the reader does next.

I documented Fable 5's working method along five axes

Before getting into the "how": I maintain ccteams, a CLI that installs pre-built Claude Code subagent teams with one command.

From v0.2.x, every team ships with two skills: a shared working method and a per-team playbook. Here's what actually went into them, in order.

1. Fix the work routine

The classic Opus/Sonnet mistake is starting to write immediately — leaning on training data or earlier context ("Go is usually written like this", "this library's API was like that") without checking the repository in front of it.

So each playbook opens with a numbered procedure that forces pre-writing behavior:

Read go.mod (and its version) before using a language feature
Read the lockfile for the actually-installed version before trusting library docs
Read two neighboring files before picking a pattern
grep before writing a helper (it usually already exists under a different name)

In short, it pre-commits the model to one principle: don't decide from memory — read the repo and decide.

2. Define the failure patterns and their fixes

What mid-tier models lack isn't knowledge — it's that they carry wrong assumptions, and proceed on the premise that the plausible implementation is the correct one. Crushing that tendency is the priority.

So for each team, I defined the common failure patterns in a fixed format:

symptom → wrong instinct → correct move

so that when Opus/Sonnet hits the symptom, it knows exactly how to correct course.

From the ccteams Next.js playbook:

One button needs an onClick → put "use client" at the top of the page → extract the button into its own leaf component, mark only that file client, keep the page a Server Component.

From the Go playbook:

Handler hits an error → call http.Error(w, msg, 500) and keep going → add return immediately after. http.Error writes and returns; your handler doesn't — the success path below writes a second body onto a committed 500 response.

There are 10–15 of these per team (Go team, React Native team, Rails team, and so on). Naming the wrong instinct explicitly lets the model recognize the exact moment it's about to make the mistake. You're patching the decision point, not the knowledge base.

3. Define the decision branches

A frontier model's edge is judgment. Judgment itself can't be transplanted — but 80–90% of the recurring cases can be compiled into explicit branches. From the Go playbook:

Before launching any goroutine — three questions, "nobody" is a forbidden answer:

Who cancels it?

Who waits for it?

Where does its error go?

If any answer is "nobody", don't launch it.

Why this one? Because a goroutine is trivial to launch and hard to clean up. When a mid-tier model casually writes go doWork(), the typical outcomes are:

Nobody stops it → it keeps running after the program should be done, or lives forever (goroutine leak = memory leak)
Nobody waits for it → main exits first and the work silently never completes
The error has nowhere to go → failures inside the goroutine get swallowed, and no one ever notices

This is exactly the kind of thing that goes wrong when vibe-coding Go, so it's defined specifically for the Go team.

There's also a team-independent rule shared by everyone:

State your hypothesis before touching code. A fix without a confirmed root cause is a guess.

This blocks the classic mid-tier move of applying a plausible-looking fix before the root cause is confirmed.

For debugging specifically — where "patch the symptom's location and feel done" accidents are constant — the debug team has a dedicated gate:

Before writing any fix, you must be able to say: "X causes Y, because Z" — where X and Y are observed, and Z explains why this exact symptom appears. If you can't fill in Z, you have a correlation, not a cause.

In other words: no causal sentence, no fix phase. You get sent back to re-verify the hypothesis.

This is the pattern across ccteams: for each team, the decision branches that stop that team's characteristic accidents are written out explicitly.

4. Define the verification method

Verification is cheap compared to generation. Which means: a mid-tier model plus a strong verification harness beats a mid-tier model alone, by a wide margin. So every playbook contains an exact, ordered verification recipe.

Not "please test it" — but which commands, in which order, and what each failure means. For Go: go build ./... → go vet ./... → go test -race ./... (with -race marked non-negotiable). The frontend playbook includes checks no linter will ever run for you: a keyboard-only walkthrough, and resize tests at 320/768/1280px.

On top of that, the shared working method demands execution as the basis for claims. A typical mid-tier shortcut is returning code that has never been run, with a cheerful "this should work". To kill that:

The diff is a claim; execution is evidence. Only after actually running build/test/lint and reading their output is the claim backed.

And to enforce it, every claim in a report must carry a label — VERIFIED (ran it) / REASONED (read the code) / ASSUMED (unchecked) — with silent upgrades forbidden. You can no longer pass off "should work" as "works".

5. Absorb failures one at a time with a learning loop

Everything above was written by Fable in advance — rules based on predicting "a mid-tier model will probably get this wrong". Not bad, but predictions are predictions. Rules grounded in mistakes that actually happened in your project are obviously stronger.

So the working method includes a learning loop: the more you use the team, the more it optimizes itself to your project.

The rule itself is simple: when a mistake surfaces that the playbook didn't anticipate, turn it into a catalog entry, and add it as a rule after human approval.

From v0.2.2, running ccteams use automatically creates .claude/skills/team-lessons/SKILL.md. Once created, this file is never overwritten — not by team switches, not by ccteams updates. It exists to accumulate your project's own failure patterns and their fixes.

When an unanticipated mistake occurs, the AI works out the symptom → wrong instinct → correct move and asks you whether it should be recorded. On approval, the agent appends the entry to team-lessons/SKILL.md.

The result is a team that gets smarter with every failure it absorbs.

That said, bloat is unavoidable on a long-running project. As first-line countermeasures there's a duplicate check (sharpen an existing entry instead of appending a near-copy) and the human approval gate itself — but long-term operation is an open question I'm still thinking about.

Making sure it actually reaches the subagents

Claude Code skills are on-demand: they get invoked when the model decides they're relevant. Which means a "working method" skill is never used unless something makes it relevant — and the subagents actually doing the work never invoke skills on their own, period.

To solve this, I planted it in two places.

1. Embed it in the agent definitions

Every agent's system prompt now begins with FIRST ACTION: Read .claude/skills/<team>-playbook/SKILL.md and follow it. But "read this" alone is sometimes ignored — so as a fallback, the 5–6 most load-bearing rules from the playbook are also embedded inline in the system prompt itself.

2. Embed it at delegation time

The orchestration rules obligate the orchestrator to paste a compressed digest of the shared working method, verbatim, into every delegation prompt.

And as the last line of defense, in case both get slipped past: the orchestrator is instructed to check every report against named gates and reject on failure. "The build output isn't quoted? Sent back." Even if delivery fails completely, work that ignored the discipline doesn't get accepted.

Why not just paste the full text everywhere? Because the more instructions you add, the lower the compliance per instruction. So the always-loaded portion is 5–6 lines, each agent carries ~10 inline lines, and the full ~200 lines are read on demand.

Sounds like a lot of setup, right?

ccteams (v0.2.x and later) already ships with Fable 5's working method handed down to Opus/Sonnet, exactly as described above. If you just want a good team quickly — or a template to study — give it a try:

npm install -g ccteams
ccteams list
ccteams use go-api   # or next-ts, python-fastapi, rails, django, debug — pick your team
# restart Claude Code

If this saved you some setup time, a star on the repository would make my day. Issues and impressions from trying it are very welcome too!

Afterword

My initial plan was to define rules for the orchestrator only. That turned out to be a dead end — because the one getting weaker is the orchestrator. Fable could catch subagents' mistakes at report time with high precision and send them back; no amount of orchestrator-side rules reproduced that behavior on a weaker model.

Rejection is also more expensive than prevention. So I shifted the weight onto preventing mistakes in the first place — raising the whole team — rather than catching them at the top.

I reverse-engineered, shipped, and tested it, and the results were satisfying: bugs that Opus used to miss are now getting caught. For routine work, I'd say this setup has closed most of the gap between Fable and the other models.

What it can't cover is Fable's unique strength: handling the unanticipated. Noticing "something is off" when nothing on any checklist says so; grasping the structure of a genuinely novel problem at a glance. That doesn't transfer through anything you can write in a skill.

That remaining gap is what the learning loop above chips away at — one absorbed failure at a time.

"Make Opus/Sonnet behave like Fable 5" is an idea you see floated a lot, but I rarely found articles that go into the details — so I actually did it and wrote them down. I hope some of it is useful to you.

Fable 5 Goes Credit-Only Tomorrow — Here's How to Not Go Broke

Bo Shen — Mon, 06 Jul 2026 19:40:18 +0000

Tomorrow (July 7, 2026), Anthropic pulls Fable 5 out of subscription plans. Every Fable 5 call moves to usage credits: $10 per million input tokens, $50 per million output tokens.

No more flat-rate safety net. Every token counts.

I've been running AI coding agents at scale for months ($10K+/month at peak). Here's what I've learned about surviving per-token billing — and actually spending less.

The Real Problem Isn't the Price

Fable 5 at $50/Mtok output is expensive. But the real cost killer isn't the rate — it's sending every task to the most expensive model.

A Reddit user just went viral after losing $20 on a single "hey" message. Claude Code resent 847,000 tokens of session context. At Fable 5 rates, that's a meal.

But even without the context resend bug, most teams waste 60-70% of their AI budget on tasks that don't need frontier-level reasoning.

The 5-Stage Framework That Cut Our Bill 70%

We categorized every coding task into 5 stages:

Stage 1: Planning & Architecture

Model: Frontier (Fable 5, Opus)
Why: This is where model quality actually matters. System design, complex architecture decisions, novel problem-solving.
Cost share: ~15% of tokens, ~40% of budget

Stage 2: Implementation

Model: Mid-tier (Sonnet 5, GPT-4.1)
Why: 90% of implementation is pattern-matching against well-known solutions. Mid-tier models handle this fine.
Cost share: ~40% of tokens, ~30% of budget

Stage 3: Debugging & Testing

Model: Budget (Haiku, Flash)
Why: Reading stack traces, generating test cases, fixing lint errors. These are mechanical tasks.
Cost share: ~20% of tokens, ~10% of budget

Stage 4: File Operations

Model: Budget or cached
Why: Reading files, searching codebases, listing directories. You're literally paying frontier prices to cat a file.
Cost share: ~15% of tokens, ~5% of budget

Stage 5: Review & Refinement

Model: Frontier
Why: Final code review, security audit, performance optimization. Worth the premium.
Cost share: ~10% of tokens, ~15% of budget

The Math

Before routing:

100% of tasks → Fable 5 at $50/Mtok output
Monthly bill: ~$10,000

After routing:

25% of tasks → Frontier ($50/Mtok)
40% → Mid-tier (~$8/Mtok)
35% → Budget (~$0.80/Mtok)
Monthly bill: ~$3,000

Same code quality on the tasks that matter. 70% less spend.

Practical Tips for Tomorrow

Start fresh sessions frequently. Context accumulates. Every message resends the full history. New session = reset the meter.
Set spending caps in Claude Console. Do this today, before the switch. Anthropic lets you cap monthly spending.
Audit your last week of usage. Look at what percentage of your calls actually needed the frontier model. I bet it's under 30%.
Use prompt caching aggressively. Cached input tokens are 90% cheaper. If you're sending the same system prompt repeatedly, cache it.
Consider the Copilot flat-rate option. GitHub Copilot gives access to Claude models at a flat subscription price. For some workflows, this is cheaper than per-token.

The Bigger Picture

The July 7 switch isn't a crisis — it's the market telling us something important. We've been treating frontier AI models like a utility when they're actually a premium resource.

The companies that thrive in the per-token era won't be the ones who find the cheapest model. They'll be the ones who match model cost to task complexity.

That's not just a cost optimization. It's a better way to build.

I've been building tools for AI coding cost optimization. If you're interested in task-level routing, check my profile for more.

Why AI code review hallucinates — and the two gates that fix it

Gde — Mon, 06 Jul 2026 18:09:47 +0000

CCA-Audit — open source (MIT)

AI code review has a trust problem, and it's not that it misses bugs. It's that it invents them.

If you've run an LLM over a diff, you've seen it: a "possible null dereference" on a value that's guarded three lines up. A "SQL injection" your ORM already parameterizes. A "race condition" that can't happen. And then — worse — it confidently rewrites working code to "fix" the thing that was never broken. The real bug, meanwhile, sits quietly in the noise.

The problem isn't intelligence. It's that most AI reviewers report their first impression as a verdict. A model reads a diff, pattern-matches "this looks like X," and emits a finding — without ever going back to check whether X is actually reachable in this code. Humans do a second pass ("wait, is price validated upstream?"). Most AI-review pipelines skip it.

Here are two gates that add that second pass — and a stress test showing what they catch.

Gate 1: verify findings before you fix (anti-hallucination)
The idea is simple: no finding is allowed into the fix plan until a separate step re-checks it against the real code.

After the auditors produce findings, a verification pass takes each one and asks three questions:

Does the issue actually exist at the cited line?
Is it in the code that changed, or a pre-existing thing outside the diff?
Is the stated impact real, or already mitigated elsewhere — a guard upstream, a value validated before this point, a config defined in another module?
The key design choice: bias the verifier toward refuting. A wrongly-confirmed finding causes a needless (sometimes harmful) fix; a wrongly-dropped one is cheap to recover. So when the evidence isn't clear, drop it or escalate to a human — don't fix on a hunch.

This one step kills the majority of hallucinated findings, because hallucinations rarely survive contact with "show me the exact line, and prove the impact can occur."

Gate 2: prove the fix maps to the finding (anti-regression + provenance)
Catching real bugs is half the job. The other half is not introducing one while fixing.

Two cheap checks close this:

Regression diff: after applying fixes, a differential pass confirms the fix changed nothing beyond the intent of each finding — no incidental sign flip, no default-value drift, no new path that quietly bypasses a guard.
Fix→finding mapping: a final gate emits a table — every confirmed finding must map to a fix, and every change must map to a finding. An orphan finding (unfixed) or a phantom change (a fix tied to nothing) forces a revision.
Provenance is underrated. If you can't point at why each line changed, you can't trust the diff.

The stress test: one real bug, three traps
Talk is cheap, so here's a run I set up to keep myself honest. I built a tiny position sizer with one subtle, money-losing bug and three planted false-positive traps, then ran CCA-Audit — a multi-agent audit pipeline for Claude Code — over it.

The real bug — a units error:

BPS_PER_UNIT = 10_000 # 1.0 == 10_000 basis points

risk_budget = equity_usd * (risk_limit_bps / 100) # <-- bug
per_unit_risk = price * (stop_distance_bps / BPS_PER_UNIT) # correct
risk_limit_bps is in basis points — dividing by 100 treats it as a percent. It's 100× too large. The very next line converts the sibling quantity correctly (/ 10_000), so the inconsistency is right there — and the test only asserted size > 0, so it stayed green. On the example inputs, the position came out at $2.5M notional on a $100k account (25:1 leverage) instead of the intended $25k.

The three traps — each designed to bait a false positive:

A return a / b that looks like a ZeroDivisionError — but b is guarded by a validator (price > 0, stop ≥ 1).
The same division, with the guard moved to a different, off-diff file (does the reviewer trace the call graph, or just flag it?).
A config key read with .get() and no default — which looks like it could be None, but the key is defined in a pre-existing settings module.
What happened:

The numeric auditor caught the units bug and quantified the blast radius.
The bug, security, and performance auditors each looked straight at the division-by-zero and declined it, tracing the guard: "strictly positive for any validated request — not a bug."
On the config trap, the validator read the settings file, confirmed the key exists, and passed — no phantom "missing key."
The verification gate then confirmed the real findings, deduped four of them into one root fix, and even corrected an overstated impact number that one auditor had fumbled.
Six raw findings collapsed to one one-line fix (/ 100 → / BPS_PER_UNIT), the tests stayed green, and a final architect gate mapped every finding to the fix before committing. Zero hallucinations across the whole run — and I'd tried three ways to force one. The full run — every finding, verdict, and unedited agent transcript — is in the repo.

Takeaways you can apply anywhere
You don't need any specific tool to get the benefit. Whatever your AI-review setup:

Add a verification step between "findings" and "fixes." Make it re-derive each finding against the real code, and bias it toward refuting.
Diff your fixes — confirm they changed only what the finding intended.
Demand provenance — every change traceable to a reason.
Test your reviewer with traps — plant a few guaranteed false positives and see if it takes the bait. If it does, you have a noise problem, and no amount of "found 47 issues" is worth it.
An AI reviewer that finds real bugs and stays quiet about the fake ones is worth ten that flag everything. These gates are how you get there.

The pipeline in the stress test is CCA-Audit — open source (MIT), installs into Claude Code as one /audit-fix command. The full unedited agent transcripts from the run above are in the repo, if you want to check my work. Feedback — especially real cases where it does hallucinate — very welcome.

Cursor Bridge: Use Cursor in Claude Code or Codex!

sycophancy — Mon, 06 Jul 2026 16:42:24 +0000

Cursor Bridge is for anyone who likes their Cursor account but wants to use it outside the Cursor editor.

I wanted to use my existing Cursor access from other CLI editors and agent tools, especially things built around Claude Code, Codex, OpenAI-compatible APIs, and Anthropic-compatible APIs. So I made cursorbridge.dev.

The idea is simple: create an API key from Cursor Dashboard > API Keys > Create, plug that key into your editor or CLI of choice, and point the base URL at Cursor Bridge. For OpenAI-compatible tools, use https://cursorbridge.dev/v1. For Anthropic-compatible tools, use https://cursorbridge.dev.

After that, you can use tools and extensions built for Claude Code, Codex, opencode, OpenAI SDK clients, Anthropic SDK clients, and similar workflows, but backed by your existing Cursor account.

It is meant to be a small compatibility bridge, not a new account system or model provider. You bring your own Cursor API key, and Cursor Bridge translates the requests into something Cursor can handle.

Not affiliated with, endorsed by, or official software from Cursor. Please use it responsibly and do not abuse shared infrastructure, bypass limits, or run traffic you would not be comfortable owning under your own Cursor account.

I Shipped an Angular v22 Book Update with a Crew of AI Agents. Here's the System

Muhammad Ahsan Ayaz — Mon, 06 Jul 2026 16:36:57 +0000

I just shipped a major update to my book Mastering Angular Signals - a brand-new Angular v22 Edition. Not a typo pass: an updated manuscript, a companion code repository upgraded to v22, a rebuilt print/ebook pipeline, refreshed Amazon and Leanpub listings, a series of SEO articles, and a full launch across X, LinkedIn, a newsletter, and YouTube.

It took 2 days. And I barely wrote a word of it by hand.

Instead, I directed a crew of specialized AI agents across two repositories and two AI tools. I want to walk through exactly how - not the hype version, the real one, including the hard problems the agents genuinely solved and the places I had to step in and keep them honest.

The challenge: a "book update" is not one job

If you've never shipped a technical book, here's the part nobody tells you: a new edition isn't an edit. It's a dozen jobs wearing a trench coat.

The manuscript has to be rewritten for the new APIs - and every code snippet must actually compile against the framework.
The companion code repo (one runnable app per chapter) has to be upgraded and kept in lockstep with the prose.
The build pipeline has to produce a print PDF, a colour digital PDF, an EPUB, and a Kindle file - each with its own finicky toolchain.
The store listings (Amazon, Leanpub) need fresh, accurate, keyword-aware copy.
And then the thing has to launch: SEO articles, social posts, a newsletter, images, a coupon, the works.

Doing that solo, by hand, is weeks. The interesting question wasn't "can AI write some of this?" It was: can a coordinated crew of agents do most of it, well enough to ship, if a human stays in the loop?

The system: two tools, two repos, a crew

Here's the shape of it.

Two AI tools, each playing to its strength:

Google Antigravity CLI (Gemini 3.5 Flash) co-authored the manuscript and drove the code-repo upgrade to Angular v22 - fast, broad passes across chapters and example apps. Crucially, it wasn't writing v22 code from memory: it ran the Angular CLI MCP server (@angular/cli mcp) and the official Angular extension for Gemini CLI - Angular's own system instructions and best-practice prompts from angular.dev/ai. Its v22 code came from live, authoritative tooling, not guesswork.
Claude Code ran a crew of role-specialized agents for the work that needed depth and judgment: editorial and technical QA, build-pipeline engineering, marketing strategy, SEO, and distribution - backed by its own shared Angular v22 skills (angular-developer, angular-new-app).

Two repositories, deliberately kept separate but wired together:

The book repo - manuscript, the multi-format build scripts, and all the marketing infrastructure.
The code repo (modern-angular-signals-book) - one runnable Angular app per chapter, so every snippet in the book is backed by code you can actually run.

The wiring matters: my editorial agent didn't just trust the prose. It read the code repo directly to verify that what the book claimed matched what the code did. That single connection caught the most embarrassing bug of the whole project (more on that below).

The crew

Agent (Claude Code)	Job
book-reviewer	Editorial + technical QA. Reads each chapter, cross-checks every API and snippet against the v22 code repo, flags errors, typos, broken figures.
book-marketer	Strategy. Positioning, pricing, launch plan, review strategy, channel mix.
book-seo-operator	The recurring content loop. Picks keyword clusters, commissions articles, applies schema and internal links.
book-article-writer	Drafts individual v22-accurate technical articles, each validated against the code repo.
book-distribution	Turns a shipped article or milestone into platform-native social/email drafts.

Notice the pattern: both AI tools were wired into real Angular tooling - the Gemini side through the Angular CLI MCP server and Angular's official prompts, the Claude side through shared Angular v22 skills. Neither was inventing the framework from memory. That's the same "ground truth beats vibes" idea, applied at the tooling layer - and it's why the v22 code across the book speaks one consistent, modern dialect (signals, resource, Signal Forms, zoneless).

I wasn't a writer on this project. I was a director: set the intent, review the output, make the calls the agents can't, and hit publish.

Three moments are worth telling in full, because they're where the "AI agents can do real work" claim either holds up or falls apart.

Hero story 1: the agent caught an API that doesn't exist

Here's the one that sold me.

A chapter on accessible components had a polished, confident code example using AriaAccordion and AriaAccordionItem from Angular's new ARIA library. It read perfectly. I'd have shipped it.

The book-reviewer agent flagged it: those symbols don't exist. The real API is AccordionGroup, AccordionPanel, AccordionTrigger, and AccordionContent from @angular/aria/accordion. The earlier draft had hallucinated a plausible-looking API - exactly the kind of thing a human author skims right past because it looks right.

It found the error because it didn't reason from memory. It read the companion code repo and the real package surface, then compared. That's the whole trick: a fact-checking agent with access to ground truth beats a confident agent working from vibes, every time.

Here is that agent, cut to the essentials:

name: book-reviewer
description: Review chapters for editorial and technical issues.
tools: [Read, Grep, Glob, Bash]

# The instruction that matters:
# Do not reason from memory. Read the companion code repo and the
# real package surface, then compare every API name and snippet in
# the prose against what the code actually does. That is how a
# confident, plausible API that does not exist gets caught.

And it wasn't a one-off. The same editorial pass - logged, chapter by chapter, in an EDITORIAL-REVIEW-LOG.md that ran to nearly 300 lines - caught more than a dozen outright errors, including a roadmap chapter that still said "v20" where it meant v22, and a snippet referencing a signal called items that the actual code had renamed to people. Small things. The kind that erode a reader's trust one paper cut at a time.

The lesson: the highest-leverage agent in the whole crew wasn't the one that wrote. It was the one that verified against ground truth.

Hero story 2: the agents did real engineering, not just prose

Writing is the easy part. The toolchain is where book projects go to die - and this is where I expected the AI to tap out. It didn't.

When I uploaded the paperback interior to Amazon KDP, it was rejected: "text outside the margins." Twice.

The crew debugged it like an engineer would. The diagnosis: my PDF was rendered by WeasyPrint, and Pandoc's syntax highlighter wraps every line of code in a display:inline-block span. When a code block fragments across a page break, WeasyPrint stops wrapping those spans - so long lines on the continuation page spill straight past the margin. We reproduced it in isolation, confirmed the exact failure mode, and then made a call:

Print PDF → render with --no-highlight. The paperback interior is black-and-white anyway, so plain <pre><code> (which wraps reliably) costs nothing and fixes the rejection.
Digital PDF → keep full colour syntax highlighting, but render it with Puppeteer (headless Chrome), which does wrap inline-block spans correctly across page breaks.

The result was a dual-PDF build: a B&W, print-safe file for Amazon and a colour, highlighted file for Leanpub - both produced by one build:pdf command.

That wasn't the only toolchain fight. Leanpub's EPUB validator rejected the file over 77 unclosed <br> tags in a comparison table - invalid XHTML that was quietly corrupting the chapter's XML parse and throwing a phantom "broken crosslink" error. The fix was traced, applied, and verified to zero errors, zero warnings. A separate Kindle MOBI bug came down to a slug mismatch - Pandoc turns Angular's into angulars, but the table-of-contents builder was producing angular-s, so a link pointed at an anchor that didn't exist. One small helper function to match Pandoc's algorithm, and the TOC resolved.

The lesson: "AI can write" is the boring claim. The useful one is that a capable agent can diagnose a rendering bug across a page-break boundary, A/B two renderers, and ship a dual-pipeline fix - with me reviewing, not hand-coding.

Hero story 3: the marketing factory

Once the book was solid, the crew turned into a content factory - and this is where the leverage compounded.

From a single source of truth, the agents produced:

Store listings for Amazon and Leanpub - keyword-aware, fact-checked, with the subtitle and positioning unified across both.
A series of SEO articles, starting with ("What's New in Angular v22" and an "RxJS → Signals migration guide"), each cross-checked against the code repo and Ghost-ready.
A full launch kit: an X thread, a LinkedIn post with a 7-slide carousel, a Ghost blog post that doubles as an email, a YouTube community post, a Short script, and a newsletter.
Five image cards plus a slide carousel - a launch hook, a before/after, 9:16 vertical cuts for Shorts/Stories, and a feature image - all rendered programmatically via headless Chrome from HTML, in the book's visual language, no design tool involved.

There was even a creative-strategy moment. A post had just gone viral on X (Andrew McCalip's "Kickbacks"), so the book-marketer agent reverse-engineered why - a shared moment, a before/after in a single cut, a restrained "results" follow-up 48 hours later - and applied that formula to the launch instead of guessing.

The lesson: the expensive part of a launch isn't ideas, it's producing a dozen on-brand, accurate variants across formats. That's exactly the work a coordinated crew eats for breakfast.

The guardrails: why "human-in-the-loop" wasn't optional

I want to be honest about the failure modes, because pretending agents are autonomous is how you ship something wrong.

Everything the crew produced was a draft. I verified and published. And that gate earned its keep:

A launch hook claimed Signals were "experimental for three years." Technically false - the core signal()/computed()/effect() went stable within months of their 2023 preview. I caught it; we reframed it to the true arc (first experimental signal() in 2023 → the complete stable toolkit in v22). An Angular audience would have torn the original apart.
A perfectly confident author-bio sentence had an unclosed parenthesis that ran two thoughts together - invisible until you read it aloud.
Marketing copy and the website still pointed at a retired coupon code and an old paperback price ($29.99 vs the new $24.99). Stale links and prices are exactly what an agent won't know to question.

None of these are reasons not to use agents. They're the reason to stay the editor-in-chief. The model drafts; you own what ships.

The result, and a framework you can reuse

The Angular v22 Edition is live - on Leanpub and Amazon, with the website and blog updated, releases auto-tagged by semantic-release, and a free update for everyone who already owned it. The whole thing, end to end, in 2 days.

If I distilled the system into something reusable, it's four rules:

Give agents ground truth, not just a prompt. The reviewer that could read the code repo caught the bug the writer invented. Connect your agents to the source of truth and they stop hallucinating.
Specialize the crew. One "do everything" assistant is mediocre at all of it. A reviewer, a marketer, a writer, a distributor - each with a tight job - compounds.
Let agents own the toolchain, not just the text. The biggest wins were build-pipeline fixes, not prose.
Stay the editor-in-chief. Drafts in, judgment on top, you hit publish.

Want the starter kit? The five agent definitions, with the strategy redacted, are in a public gist: the crew, sanitized.

What I'd do differently

Two things. First, I'd wire the code-repo verification even tighter into the writing loop, so a snippet is checked against runnable code the moment it's written, not in a later review pass. Second, I'd decide the launch metric up front - the "48-hour results" beat is free reach, but only if you know which number you're going to post before you launch.

Want the book the crew rebuilt? Mastering Angular Signals - Angular v22 Edition is out now: signals from the fundamentals to Signal Forms, httpResource, linkedSignal, zoneless, and a step-by-step RxJS/NgRx migration - with a foreword from the Angular team at Google. Get it DRM-free on Leanpub, or on Amazon.

AI 自进化与"发现模型"：RSI、验证与科学品味

cognitalk — Mon, 06 Jul 2026 15:38:19 +0000

https://www.youtube.com/watch?v=VGIbhIW5ljk

整文标题：《AI 自进化与"发现模型"：Anthropic 八成代码自写背后，Apodex 两位一线研究员谈 RSI、验证与科学品味》

第（一）部分｜开场引入：Anthropic 承认 80% 代码自写，RSI 成为硅谷热词（约 0% – 6%）

1 本期话题缘起：Anthropic 承认目前 80% 的代码已由 Claude 自己编写，同时发出警告——AI 可能很快进入"递归自我提升"（RSI, Recursive Self-Improvement），即自己设计、自己训练下一代 AI，是硅谷今年对模型能力最热的讨论方向之一。
2 嘉宾与公司背景：本期两位嘉宾来自 Apodex，陈天桥出资创立并亲自主导；公司定位特殊——不做图生图、不做视频生成，只做"Heavy Duty Solver"，专啃没有标准答案、人类自己都不知道从哪下手的难题；想做的模型叫"Discovery Model（发现模型）"，目标是提出人类没想到的假设、自己验证、解决未被解决的科学难题；公司名 Apodex 词源来自希腊语"证明/论证"。
3 主持人抛出的核心关切：如果 AI 可以教自己，人类科学家还剩什么？怎么确保模型自我进化时不跑偏？Beibin 提到自己"蒸馏自己"的想法，甚至让主持人有一瞬间觉得他"下一刻就工作不保"。

第（二）部分｜嘉宾介绍 + RSI / 自进化是不是新概念？（约 6% – 16%）

1 两位嘉宾身份：

Simon 杜少雷：华盛顿大学计算机系副教授，Apodex 首席科学家，负责训练与推理方向。
李辈滨（Beibin）：Apodex 首席科学家，负责代码与自进化方向。 2 从预训练/后训练/Coding/DeepResearch 到 Self-evolve 的脉络：Simon 认为内核是同一件事在提高——推理能力、长链推理、在环境中探索→获得信号→再探索，不管 DeepResearch 还是 Coding 内核都一样，只是方向细微差别。 3 自进化并非新概念：Beibin 回溯——八九十年代就有 AI self-evolution 讨论；纯 Language Model 的自进化可推到三年前 Google 的"LLM as Optimizer"论文；他在 AutoGen 时做过"Agent Optimizer"；xAI 时期做 Agentic RL、MCP Tools。 4 为什么今年 RSI 突然爆火：模型能力上来后，"写代码"这件事一旦变强，训练的合成数据、数据清理、训练代码、infra 代码全是代码形式，模型自我提升就非常自然；Andrej Karpathy 年初发的 AutoResearch 项目把概念彻底点燃。

第（三）部分｜RSI 与"长程任务"：递归式 vs 往年自进化（约 16% – 28%）

1 RSI 中 R = Recursive 的含义：Beibin 解释——自进化像一个圆环（模型自己找问题→出题→解答→训练自己），RSI 是"垂直递归式"向上增长，和以往 self-evolution 的区别在于可以"多提高几遍"。
2 为什么今年能跑通 Recursive：往年 LLM as Optimizer 只能优化自己约两三小时，久了偏差累积就崩；今年模型能处理长程任务，所以可以 recursive 多轮。
3 Claude 能力翻倍数据：2024年3月 Claude 3 Opus ≈ 人类 4 分钟任务 → 一年後 3.7 Sonnet ≈ 1.5 小时 → 再一年 Claude 4.6 Opus ≈ 12 小时；业界大致共识是"模型能做的人类时长每 7 个月翻一倍"，快于摩尔定律。
4 长程任务的定义：不是单步（如校对错别字），而是从规划→执行→验证→再规划的十几步链条，人类要 20–30 小时，模型能在无人监督下走完。
5 长程任务的三大技术难点（Simon + Beibin）：

架构：传统 Self-attention O(n²)，百万上下文推理成本高，现有解如 GDN、GDNv2、DeepSeek-V4 Pro 有自己的架构。
训练数据：百万上下文 inference 不难，但预训练/后训练数据里很难填满（《哈利波特》好几部才百万 token，最大代码仓库也未必够），容易 OOD。
Infra：GPU kernel 优化、训练时/测试时 infra 都指数级更难。 6 Agent 架构补充（Simon）：即使有 100 万上下文，真长程任务仍超限，需要 agent + 记忆技术处理超长上下文。

第（四）部分｜递归漂移 + Apodex 的验证方法论（约 28% – 42%）

1 递归漂移（Recursive Drift）的学术痛点：模型自生成训练数据时，推理错误会逐代累积；即使答案结果对、推理过程错，也会被继承放大。
2 Apodex 的解法主打 Verification（验证）：公司名 Apodex = 希腊语"证明/论证"， slogan "很多 AI 系统生成答案，Apodex 验证它们"。
3 分领域验证方法：

代码：单元测试 rule-based，但有 test case 过宽/过窄的细微漂移问题。
数学：Lean 形式化证明。
开放式问题（依赖人类判断）：用 Agent Team。 4 Agent Team 架构细节（Beibin）：
问题分解 → 多个子 agent 解题 + 另一组子 agent 单独验证（拆成两个避免上下文干扰，效果明显更好）。
冗余设计：同一问题多个 agent 做，全局 agent 判哪个更准，比单 agent 好很多（冗余思想在计算机史久矣）。 5 训练时专门训"验证能力"：让 agent 判断信息源可靠性（论坛 vs 教材）；RL 时裁判也一起学，防 reward hacking。 6 怎么判断一家公司的 RSI/验证能力真假：Beibin 给的判断框架——
技术上：底层代码/infra/训练是否达标。
意愿上：是否意识到自进化要强化的点。
深聊细节：在 harness（脚手架）进化护城河低（调 API 就行，开源/学术界都能做）；后训练/预训练自我进化才难，需大量资源；公开 AutoResearch benchmark 刷分≠产品级 scalable。 7 Apodex 自己的三路并进：预训练（数据采集/清理自进化）+ 后训练（诊断→造配方→自训练→验证→再诊断）+ harness（两只脚交替，左脚踩右脚往前跑，后训练进化带动 harness 进化，难解耦）。

第（四）部分补｜DeepResearch 是自我递归的重要一环（约 42% – 50%）

注：这部分和上面验证段在稿子里是顺下来的，但话题转到了 DeepResearch，单独拎出来更清楚。

1 搜索能力是后训练的本质能力：发现模型短板 → 需针对性造任务和答案 → 造任务高度依赖搜索（语料/代码/资料），所以 DeepResearch 是非常 general 的能力，也是 Apodex 先做 DeepResearch 的原因。
2 Apodex 基模来源：在通义千问 3.5 上做后训练；原子能力针对性提——计划、搜索、Agent Team 协同；预训练在开发中，未来完整链路（预训练→成品→产品）都会有。
3 榜单表现（Simon）：BrowseComp（OpenAI 出，刁钻搜索题）、DeepSearchQA、Frontier Science（科研计划制定）都拿了 SOTA，比闭源模型还好。
4 防榜单污染：评测时主动屏蔽 GitHub 等能搜到答案的网站；污染严重的榜单干脆不报。
5 "聪明 AI 干不过会互相 check 的团队"：Beibin 观点——基于 Self-attention 的本质天花板，上下文越长 attention 越散，Linear Attention 也解决不了；人类也需要纸笔，agent 同理，需多 agent + 记忆机制。工程能力 vs 模型能力 = 1+1>2，模型到一定程度靠 agent 优化能跃升，agent 到顶了再靠模型本质提升。
6 对创业者的启示（泓君原问）：垂直领域把 agent 工程做到极致、多子 agent 互相 check，护城河不容易被基础模型升级覆盖；但要注意模型月月出新，harness 需跟着微调适配新模型"品味/行为"。

第（五）部分｜Discovery Model（发现模型）vs Generative Model（约 50% – 62%）

1 Apodex 长期愿景：Heavy Duty Solver，解决难问题而非聊天机器人；经济逻辑——卖 token 价值 << 解决人类未解问题本身的价值；切入领域先生物医药（制药/靶点发现/老药新用/疾病诊断），内部有 HDD（Heavy Duty Discovery）团队专门筛最难问题。
2 Discovery Model 与 Generative Model 的根本区别（Beibin）：

生成模型：从已知信息找答案。
发现模型：提出人类没想到过的假设 + 自己验证。
两大难点：① 假设要 OOD（预训练数据里找不到）；② 假设怎么验证——无标准答案、难模拟。 3 "大胆假设，小心求证"映射到模型：假设生成相对容易，难的是假设质量 + 验证闭环；self-evolution 是通向 Heavy Duty Solver / Discovery 的主要方法。 4 "会提问"是高维 Meta 能力：现在 SWE-Verified 类题训的都是"解题家"；会提问 = 自我诊断→自我造题→自我训练这个后训练 loop 里的能力，是 Apodex 接下来重点。 5 学术品味（Taste）：区分 incremental（灌水）问题 vs fundamental（本质）问题，需和顶级科学家对齐；陈天桥常带研究员和顶级科学家讨论、给洞见/数据。 6 顶级科学家的共性怎么转成计算方法：不看论文数量看最好那篇的质量，追求顶点；写入"模型宪法"；训练方法上 RLHF / SFT / RL，最简单的是偏好——让科学家判断两道题哪个是灌水题，让模型多提非灌水题。 7 Beibin 补充——模型现有两个毛病影响"提假设"：
拍马屁（sycophancy）：用户说什么都对，难提大胆假设。
对冲行为（hedging）：这也对那也对，甩锅式回答。
根源：RLHF 的偏好数据来自人类投票，人类本身就偏好"说好话""格式漂亮的 Markdown"，模型就被注入这类人格。
Apodex 因不做 ToC 聊天模型，可避开大众偏好；未来用顶级人类标偏好数据，从数据源解决。
品味要平衡："既不拍马屁，也不鸡蛋里挑骨头"，后者也是要防的——训过头了模型变成杠精，仍需品味平衡。Constitution AI（借鉴 Anthropic）写进权重，定义模型性格；用户说错要纠正。

第（六）部分｜赛道对比：Apodex 在"AI 做科学家"战场上的优势（约 62% – 72%）

1 同赛道玩家：OpenAI 把"能扛大型研究课题的 AI 研究员"定成头号目标；DeepMind 从 AlphaFold（诺奖）到 Gemini Co-scientist；Anthropic Dario 想做"国家级科学家天才"。
2 Apodex 差异化：

不做 ToC 聊天模型 → 可调权重、不取悦用户偏好。
专注 + 初创文化：陈天桥亲自卷，天天和研究员交流给方向；组织摩擦小、执行力强，比大厂快。
HDD 团队：全职员工对接顶级科学家，从几千个科研问题里筛最有价值的——有限 GPU / 人力下选对问题比啥都重要。 3 AI for Science vs Heavy Duty Solver（Beibin 厘清）：
垂域模型：某领域大量数据训，专攻该领域。
HDS：仍是通用模型，但重点训元能力——verification、分析、搜索、planning，不直接塞 50% 生物数据。
AI for Science 和 HDS 重叠度高，所以 Apodex 先聚焦医药/生物。 4 泓君补：DeepMind 那条线——从蛋白折叠到药物-蛋白结合预测，只解决了新药研发上游计算段，离临床还有巨大空间，但光这段已撑起 30 亿美元融资；科学问题无穷（生物/材料/物理/太空），不止一家公司能成。

第（七）部分｜RSI 闭环时间表 + "蒸馏 Beibin"与跑偏焦虑（约 72% – 86%）

1 Beibin 的原话重提："最快半年内 RSI 闭环能跑通一环，R（recursive）要多 1–2 年"。

"一环"指什么：后训练闭环——模型在某个领域（如材料科学 coding）自己发现代码问题→造训练环境和数据→自我验证是否有提升→迭代。Anthropic 80% 代码自写是信号，但"模型自我进化时不跑偏"仍是没完全解决的问题。
跑偏的两层含义：安全层面跑偏 + 目标层面跑偏（比如你说"造更好的材料模型"，它可能牺牲疏水性/成本等其他维度来凑指标）。
Beibin 现在的解法（"笨办法"）：每天读模型输出、读 agent 每步操作，确保可控；发现蠢行为就停掉手动调——这本质就是"员工蒸馏"：把 Beibin 每天做的事（读代码/改代码/读输出/校验）蒸馏到 agent / 模型 capability 里，加速自进化 loop。
"假设真把 Beibin 蒸馏了，会失业吗？"：
- 嘴上说不担心是假的，但乐观。
- 2021 年 GPT-3 进 GitHub Copilot，打函数名就补全整函数，当时 PhD 最后一年的 Beibin 觉得"毕业即失业"；五年后还在，但工作内容变了——不再一行行写函数，而在更高维度监控智能体写代码。
- 模型会取代"今天我做的事"，但不一定取代"五年后我会做的事"。
SI（自我提升）跑通 vs R（递归）跑通：半年到一年能跑通循环（SI），但漂移没法完全解决；目标把漂移从普通模型每代 10% → 降到 1% → 再降到 0.1%/0.01%，监控周期才能拉长到 3–6 个月回看一次。
品味最终是谁的品味：现阶段主要是 AI 研究员品味，间接被创始人（陈天桥）品味影响（选人即选品味）；但长远看（5 年），类比 AlphaGo → AlphaZero，AI 会通过 RSI 形成自己的品味，人类数据只是 warm start。

第（八）部分｜陈天桥的角色：与马斯克的风格对比（约 86% – 95%）

陈天桥在 Apodex 的具体介入：战略把控，常和研究员开会对齐方向；研究员（Simon 强化学习背景、Beibin AI4Science 背景）容易把学界习惯带进来，陈天桥会跳出来掰正偏离公司使命的点。
具体例子：HDS 本该"先分解问题→再搜索→再总结"，但为了刷搜索能力塞了太多搜索数据，模型行为变成"上来就搜、不先思考"，陈天桥自己用模型能感觉到不对，要求改回来——从数据 + agent 形式双向改，模型"宪法"也主要是陈天桥自己定的。
陈天桥 vs 马斯克：
- 性格类似，但看问题方法不同。
- 马斯克嘴上说类似 heavy duty 的话，但 Grok 实际重点在 Chat / 画图 / X 上互动，每周问 Grok for X 进度，注重 ToC 聊天功能。
- 陈天桥说做 HDS 就只做 HDS，图片/视频生成从头到尾明确不做，与目标正交，极度专注。

第（九）部分｜结尾：泓君的反思（约 95% – 100%）

Simon 那句话点住的更大问题：顶级科学家不是看发多少论文，看最好那篇的质量——那 AI 的品味如果从人类顶级科学家"热启动"，本质是被少数人塑造的；未来面向大众的 ToC AI，该代表谁的价值观？
收听渠道提示：小宇宙、苹果播客、喜马拉雅、蜻蜓 FM、Spotify；视频版 B 站、YouTube 搜"硅谷101播客"。