diff --git a/apps/web-roo-code/next-sitemap.config.cjs b/apps/web-roo-code/next-sitemap.config.cjs
index e9b0ca3c473..e2b1e47e2c5 100644
--- a/apps/web-roo-code/next-sitemap.config.cjs
+++ b/apps/web-roo-code/next-sitemap.config.cjs
@@ -1,3 +1,68 @@
+const path = require('path');
+const fs = require('fs');
+const matter = require('gray-matter');
+
+/**
+ * Get published blog posts for sitemap
+ * Note: This runs at build time, so recently-scheduled posts may lag
+ */
+function getPublishedBlogPosts() {
+  const BLOG_DIR = path.join(process.cwd(), 'src/content/blog');
+  
+  if (!fs.existsSync(BLOG_DIR)) {
+    return [];
+  }
+  
+  const files = fs.readdirSync(BLOG_DIR).filter(f => f.endsWith('.md'));
+  const posts = [];
+  
+  // Get current time in PT for publish check
+  const formatter = new Intl.DateTimeFormat('en-US', {
+    timeZone: 'America/Los_Angeles',
+    year: 'numeric',
+    month: '2-digit',
+    day: '2-digit',
+    hour: '2-digit',
+    minute: '2-digit',
+    hour12: false,
+  });
+  
+  const parts = formatter.formatToParts(new Date());
+  const get = (type) => parts.find(p => p.type === type)?.value ?? '';
+  const nowDate = `${get('year')}-${get('month')}-${get('day')}`;
+  const nowMinutes = parseInt(get('hour')) * 60 + parseInt(get('minute'));
+  
+  for (const file of files) {
+    const filepath = path.join(BLOG_DIR, file);
+    const raw = fs.readFileSync(filepath, 'utf8');
+    const { data } = matter(raw);
+    
+    // Check if post is published
+    if (data.status !== 'published') continue;
+    
+    // Parse publish time
+    const timeMatch = data.publish_time_pt?.match(/^(1[0-2]|[1-9]):([0-5][0-9])(am|pm)$/i);
+    if (!timeMatch) continue;
+    
+    let hours = parseInt(timeMatch[1]);
+    const mins = parseInt(timeMatch[2]);
+    const isPm = timeMatch[3].toLowerCase() === 'pm';
+    if (hours === 12) hours = isPm ? 12 : 0;
+    else if (isPm) hours += 12;
+    const postMinutes = hours * 60 + mins;
+    
+    // Check if post is past publish date/time
+    const isPublished = nowDate > data.publish_date || 
+      (nowDate === data.publish_date && nowMinutes >= postMinutes);
+    
+    if (isPublished && data.slug) {
+      posts.push(data.slug);
+    }
+  }
+  
+  return posts;
+}
+
 /** @type {import('next-sitemap').IConfig} */
 module.exports = {
   siteUrl: process.env.NEXT_PUBLIC_SITE_URL || 'https://roocode.com',
@@ -39,6 +104,12 @@ module.exports = {
     } else if (path === '/privacy' || path === '/terms') {
       priority = 0.5;
       changefreq = 'yearly';
+    } else if (path === '/blog') {
+      priority = 0.8;
+      changefreq = 'weekly';
+    } else if (path.startsWith('/blog/')) {
+      priority = 0.7;
+      changefreq = 'monthly';
     }
     
     return {
@@ -50,24 +121,39 @@ module.exports = {
     };
   },
   additionalPaths: async (config) => {
-    // Add any additional paths that might not be automatically discovered
-    // This is useful for dynamic routes or API-generated pages
+    const result = [];
+    
     // Add the /evals page since it's a dynamic route
-    return [{
+    result.push({
       loc: '/evals',
       changefreq: 'monthly',
       priority: 0.8,
       lastmod: new Date().toISOString(),
-    }];
+    });
     
-    // Add the /evals page since it's a dynamic route
+    // Add /blog index
     result.push({
-      loc: '/evals',
-      changefreq: 'monthly',
+      loc: '/blog',
+      changefreq: 'weekly',
       priority: 0.8,
       lastmod: new Date().toISOString(),
     });
     
+    // Add published blog posts
+    try {
+      const slugs = getPublishedBlogPosts();
+      for (const slug of slugs) {
+        result.push({
+          loc: `/blog/${slug}`,
+          changefreq: 'monthly',
+          priority: 0.7,
+          lastmod: new Date().toISOString(),
+        });
+      }
+    } catch (e) {
+      console.warn('Could not load blog posts for sitemap:', e.message);
+    }
+    
     return result;
   },
-};
\ No newline at end of file
+};
diff --git a/apps/web-roo-code/package.json b/apps/web-roo-code/package.json
index 90b6e9e3069..8ad1a950517 100644
--- a/apps/web-roo-code/package.json
+++ b/apps/web-roo-code/package.json
@@ -9,7 +9,9 @@
 		"build": "next build",
 		"postbuild": "next-sitemap --config next-sitemap.config.cjs",
 		"start": "next start",
-		"clean": "rimraf .next .turbo"
+		"clean": "rimraf .next .turbo",
+		"test": "vitest run",
+		"test:watch": "vitest"
 	},
 	"dependencies": {
 		"@radix-ui/react-dialog": "^1.1.15",
@@ -25,6 +27,7 @@
 		"embla-carousel-autoplay": "^8.6.0",
 		"embla-carousel-react": "^8.6.0",
 		"framer-motion": "^12.29.2",
+		"gray-matter": "^4.0.3",
 		"lucide-react": "^0.563.0",
 		"next": "^16.1.6",
 		"next-themes": "^0.4.6",
@@ -52,6 +55,7 @@
 		"autoprefixer": "^10.4.23",
 		"next-sitemap": "^4.2.3",
 		"postcss": "^8.5.6",
-		"tailwindcss": "^3.4.17"
+		"tailwindcss": "^3.4.17",
+		"vitest": "^4.0.18"
 	}
 }
diff --git a/apps/web-roo-code/src/app/blog/[slug]/page.tsx b/apps/web-roo-code/src/app/blog/[slug]/page.tsx
new file mode 100644
index 00000000000..985ee95b2b4
--- /dev/null
+++ b/apps/web-roo-code/src/app/blog/[slug]/page.tsx
@@ -0,0 +1,337 @@
+/**
+ * Blog Post Page
+ * MKT-69: Blog Post Page
+ *
+ * Renders a single blog post from Markdown.
+ * Uses dynamic rendering (force-dynamic) for request-time publish gating.
+ * Does NOT use generateStaticParams to avoid static generation.
+ *
+ * AEO Enhancement: Parses FAQ sections from markdown, renders as accordion,
+ * and generates FAQPage JSON-LD schema for AI search optimization.
+ */
+
+import type { Metadata } from "next"
+import Link from "next/link"
+import { notFound } from "next/navigation"
+import Script from "next/script"
+import { ChevronLeft, ChevronRight, Clock } from "lucide-react"
+import {
+	getBlogPostBySlug,
+	getAdjacentPosts,
+	formatPostDatePt,
+	calculateReadingTime,
+	formatReadingTime,
+} from "@/lib/blog"
+import { SEO } from "@/lib/seo"
+import { ogImageUrl } from "@/lib/og"
+import { BlogPostAnalytics } from "@/components/blog/BlogAnalytics"
+import { BlogContent } from "@/components/blog/BlogContent"
+import { BlogFAQ, type FAQItem } from "@/components/blog/BlogFAQ"
+import { BlogPostCTA } from "@/components/blog/BlogPostCTA"
+
+// Force dynamic rendering for request-time publish gating
+export const dynamic = "force-dynamic"
+export const runtime = "nodejs"
+
+interface Props {
+	params: Promise<{ slug: string }>
+}
+
+/**
+ * Parse FAQ section from markdown content
+ *
+ * Looks for a section starting with "## Frequently asked questions"
+ * and extracts H3 questions with their content as answers.
+ *
+ * Returns the FAQ items and the content with FAQ section removed.
+ */
+function parseFAQFromMarkdown(content: string): {
+	faqItems: FAQItem[]
+	contentWithoutFAQ: string
+} {
+	// Match FAQ section: ## Frequently asked questions (case-insensitive)
+	const faqSectionRegex = /^## Frequently asked questions\s*$/im
+	const faqMatch = content.match(faqSectionRegex)
+
+	if (!faqMatch || faqMatch.index === undefined) {
+		return { faqItems: [], contentWithoutFAQ: content }
+	}
+
+	const faqStartIndex = faqMatch.index
+	const beforeFAQ = content.slice(0, faqStartIndex).trim()
+	const faqSection = content.slice(faqStartIndex)
+
+	// Find where FAQ section ends (next H2 or end of content)
+	const nextH2Match = faqSection.slice(faqMatch[0].length).match(/^## /m)
+	const faqContent =
+		nextH2Match && nextH2Match.index !== undefined
+			? faqSection.slice(0, faqMatch[0].length + nextH2Match.index)
+			: faqSection
+
+	const afterFAQ =
+		nextH2Match && nextH2Match.index !== undefined ? faqSection.slice(faqMatch[0].length + nextH2Match.index) : ""
+
+	// Parse individual FAQ items (### Question followed by content)
+	const faqItems: FAQItem[] = []
+	const questionRegex = /^### (.+?)$\s*([\s\S]*?)(?=^### |$(?![\s\S]))/gm
+	let match
+
+	while ((match = questionRegex.exec(faqContent)) !== null) {
+		const question = match[1]?.trim()
+		const answer = match[2]?.trim()
+		if (question && answer) {
+			faqItems.push({ question, answer })
+		}
+	}
+
+	const contentWithoutFAQ = (beforeFAQ + "\n\n" + afterFAQ).trim()
+
+	return { faqItems, contentWithoutFAQ }
+}
+
+export async function generateMetadata({ params }: Props): Promise<Metadata> {
+	const { slug } = await params
+	const post = getBlogPostBySlug(slug)
+
+	if (!post) {
+		return {}
+	}
+
+	const path = `/blog/${post.slug}`
+
+	return {
+		title: post.title,
+		description: post.description,
+		alternates: {
+			canonical: `${SEO.url}${path}`,
+		},
+		openGraph: {
+			title: post.title,
+			description: post.description,
+			url: `${SEO.url}${path}`,
+			siteName: SEO.name,
+			images: [
+				{
+					url: ogImageUrl(post.title, post.description),
+					width: 1200,
+					height: 630,
+					alt: post.title,
+				},
+			],
+			locale: SEO.locale,
+			type: "article",
+			publishedTime: post.publish_date,
+		},
+		twitter: {
+			card: SEO.twitterCard,
+			title: post.title,
+			description: post.description,
+			images: [ogImageUrl(post.title, post.description)],
+		},
+		keywords: [...SEO.keywords, ...post.tags],
+	}
+}
+
+export default async function BlogPostPage({ params }: Props) {
+	const { slug } = await params
+	const post = getBlogPostBySlug(slug)
+
+	if (!post) {
+		notFound()
+	}
+
+	const { previous, next } = getAdjacentPosts(slug)
+
+	// Calculate reading time
+	const readingTime = calculateReadingTime(post.content)
+	const readingTimeDisplay = formatReadingTime(readingTime)
+
+	// Parse FAQ section from markdown content
+	const { faqItems, contentWithoutFAQ } = parseFAQFromMarkdown(post.content)
+	const hasFAQ = faqItems.length > 0
+
+	// BlogPosting JSON-LD schema (more specific than Article for SEO)
+	const articleSchema = {
+		"@context": "https://schema.org",
+		"@type": "BlogPosting",
+		headline: post.title,
+		description: post.description,
+		datePublished: post.publish_date,
+		image: ogImageUrl(post.title, post.description),
+		wordCount: post.content.split(/\s+/).filter(Boolean).length,
+		mainEntityOfPage: {
+			"@type": "WebPage",
+			"@id": `${SEO.url}/blog/${post.slug}`,
+		},
+		url: `${SEO.url}/blog/${post.slug}`,
+		author: {
+			"@type": "Organization",
+			"@id": `${SEO.url}#org`,
+			name: SEO.name,
+		},
+		publisher: {
+			"@type": "Organization",
+			"@id": `${SEO.url}#org`,
+			name: SEO.name,
+			logo: {
+				"@type": "ImageObject",
+				url: `${SEO.url}/android-chrome-512x512.png`,
+			},
+		},
+	}
+
+	// Breadcrumb schema
+	const breadcrumbSchema = {
+		"@context": "https://schema.org",
+		"@type": "BreadcrumbList",
+		itemListElement: [
+			{
+				"@type": "ListItem",
+				position: 1,
+				name: "Home",
+				item: SEO.url,
+			},
+			{
+				"@type": "ListItem",
+				position: 2,
+				name: "Blog",
+				item: `${SEO.url}/blog`,
+			},
+			{
+				"@type": "ListItem",
+				position: 3,
+				name: post.title,
+				item: `${SEO.url}/blog/${post.slug}`,
+			},
+		],
+	}
+
+	// FAQPage schema (only if post has FAQ section) - AEO optimization
+	const faqSchema = hasFAQ
+		? {
+				"@context": "https://schema.org",
+				"@type": "FAQPage",
+				mainEntity: faqItems.map((item) => ({
+					"@type": "Question",
+					name: item.question,
+					acceptedAnswer: {
+						"@type": "Answer",
+						text: item.answer,
+					},
+				})),
+			}
+		: null
+
+	return (
+		<>
+			<Script
+				id="article-schema"
+				type="application/ld+json"
+				dangerouslySetInnerHTML={{ __html: JSON.stringify(articleSchema) }}
+			/>
+			<Script
+				id="breadcrumb-schema"
+				type="application/ld+json"
+				dangerouslySetInnerHTML={{ __html: JSON.stringify(breadcrumbSchema) }}
+			/>
+			{faqSchema && (
+				<Script
+					id="faq-schema"
+					type="application/ld+json"
+					dangerouslySetInnerHTML={{ __html: JSON.stringify(faqSchema) }}
+				/>
+			)}
+
+			<BlogPostAnalytics post={post} />
+
+			<article className="container mx-auto px-4 py-12 sm:px-6 lg:px-8">
+				<div className="mx-auto max-w-4xl">
+					{/* Visual Breadcrumb Navigation */}
+					<nav aria-label="Breadcrumb" className="mb-8">
+						<ol className="flex items-center gap-1 text-sm text-muted-foreground">
+							<li>
+								<Link href="/blog" className="transition-colors hover:text-foreground">
+									Blog
+								</Link>
+							</li>
+							<li>
+								<ChevronRight className="h-4 w-4" />
+							</li>
+							<li className="truncate text-foreground" aria-current="page">
+								{post.title}
+							</li>
+						</ol>
+					</nav>
+
+					<div className="prose prose-lg dark:prose-invert">
+						<header className="not-prose mb-8">
+							<h1 className="text-3xl font-bold tracking-tight sm:text-4xl md:text-5xl">{post.title}</h1>
+							<div className="mt-4 flex flex-wrap items-center gap-3 text-sm text-muted-foreground">
+								<span>{formatPostDatePt(post.publish_date)}</span>
+								<span className="text-border">•</span>
+								<span className="flex items-center gap-1">
+									<Clock className="h-4 w-4" />
+									{readingTimeDisplay}
+								</span>
+							</div>
+							{post.tags.length > 0 && (
+								<div className="mt-4 flex flex-wrap gap-2">
+									{post.tags.map((tag) => (
+										<span
+											key={tag}
+											className="rounded bg-muted px-2 py-1 text-xs text-muted-foreground">
+											{tag}
+										</span>
+									))}
+								</div>
+							)}
+						</header>
+
+						<BlogContent content={contentWithoutFAQ} />
+
+						{/* FAQ Section rendered as accordion */}
+						{hasFAQ && <BlogFAQ items={faqItems} />}
+
+						{/* Product CTA Module - Inspired by Vercel's blog design
+						    Default variant prioritizes Roo Code Cloud sign-up */}
+						<BlogPostCTA />
+					</div>
+
+					{/* Previous/Next Post Navigation */}
+					{(previous || next) && (
+						<nav aria-label="Post navigation" className="mt-12 border-t border-border pt-8">
+							<div className="flex flex-col gap-4 sm:flex-row sm:justify-between">
+								{previous ? (
+									<Link
+										href={`/blog/${previous.slug}`}
+										className="group flex items-center gap-2 text-sm text-muted-foreground transition-colors hover:text-foreground">
+										<ChevronLeft className="h-4 w-4 transition-transform group-hover:-translate-x-1" />
+										<div className="flex flex-col">
+											<span className="text-xs uppercase tracking-wide">Previous</span>
+											<span className="font-medium text-foreground">{previous.title}</span>
+										</div>
+									</Link>
+								) : (
+									<div />
+								)}
+								{next ? (
+									<Link
+										href={`/blog/${next.slug}`}
+										className="group flex items-center gap-2 text-sm text-muted-foreground transition-colors hover:text-foreground sm:flex-row-reverse sm:text-right">
+										<ChevronRight className="h-4 w-4 transition-transform group-hover:translate-x-1" />
+										<div className="flex flex-col">
+											<span className="text-xs uppercase tracking-wide">Next</span>
+											<span className="font-medium text-foreground">{next.title}</span>
+										</div>
+									</Link>
+								) : (
+									<div />
+								)}
+							</div>
+						</nav>
+					)}
+				</div>
+			</article>
+		</>
+	)
+}
diff --git a/apps/web-roo-code/src/app/blog/page.tsx b/apps/web-roo-code/src/app/blog/page.tsx
new file mode 100644
index 00000000000..f3e6bd8d62f
--- /dev/null
+++ b/apps/web-roo-code/src/app/blog/page.tsx
@@ -0,0 +1,181 @@
+/**
+ * Blog Index Page
+ * MKT-68: Blog Index Page
+ *
+ * Lists published blog posts with two views:
+ * - Featured (default): Curated 24 posts aligned with Roo Code positioning
+ * - All: Full list with pagination (12 posts per page)
+ *
+ * Uses dynamic rendering (force-dynamic) for request-time publish gating.
+ */
+
+import type { Metadata } from "next"
+import Script from "next/script"
+import { Suspense } from "react"
+import { getPaginatedBlogPosts, getAllBlogPosts, getCuratedBlogPosts } from "@/lib/blog"
+import { SEO } from "@/lib/seo"
+import { ogImageUrl } from "@/lib/og"
+import { BlogIndexAnalytics } from "@/components/blog/BlogAnalytics"
+import { BlogPostList } from "@/components/blog/BlogPostList"
+import { BlogPagination } from "@/components/blog/BlogPagination"
+import { BlogPostCTA } from "@/components/blog/BlogPostCTA"
+import { BlogViewToggle } from "@/components/blog/BlogViewToggle"
+
+// Force dynamic rendering for request-time publish gating
+export const dynamic = "force-dynamic"
+export const runtime = "nodejs"
+
+const TITLE = "Blog"
+const DESCRIPTION = "How teams use agents to iterate, review, and ship PRs with proof."
+const PATH = "/blog"
+
+export const metadata: Metadata = {
+	title: TITLE,
+	description: DESCRIPTION,
+	alternates: {
+		canonical: `${SEO.url}${PATH}`,
+	},
+	openGraph: {
+		title: TITLE,
+		description: DESCRIPTION,
+		url: `${SEO.url}${PATH}`,
+		siteName: SEO.name,
+		images: [
+			{
+				url: ogImageUrl(TITLE, DESCRIPTION),
+				width: 1200,
+				height: 630,
+				alt: TITLE,
+			},
+		],
+		locale: SEO.locale,
+		type: "website",
+	},
+	twitter: {
+		card: SEO.twitterCard,
+		title: TITLE,
+		description: DESCRIPTION,
+		images: [ogImageUrl(TITLE, DESCRIPTION)],
+	},
+	keywords: [...SEO.keywords, "blog", "articles", "engineering", "AI development"],
+}
+
+interface Props {
+	searchParams: Promise<{ view?: string; page?: string }>
+}
+
+export default async function BlogIndexPage({ searchParams }: Props) {
+	const params = await searchParams
+	const view = params.view === "all" ? "all" : "featured"
+	const pageParam = params.page ? parseInt(params.page, 10) : 1
+
+	// Get all posts for counts and schema
+	const allPosts = getAllBlogPosts()
+	const curatedPosts = getCuratedBlogPosts()
+
+	// Determine which posts to display based on view
+	let displayPosts
+	let currentPage = 1
+	let totalPages = 1
+	let showPagination = false
+
+	if (view === "all") {
+		const paginated = getPaginatedBlogPosts(pageParam)
+		displayPosts = paginated.posts
+		currentPage = paginated.currentPage
+		totalPages = paginated.totalPages
+		showPagination = totalPages > 1
+	} else {
+		// Featured view shows curated posts without pagination
+		displayPosts = curatedPosts
+	}
+
+	// Schema.org CollectionPage + ItemList (includes all posts for SEO)
+	const blogSchema = {
+		"@context": "https://schema.org",
+		"@type": "CollectionPage",
+		name: TITLE,
+		description: DESCRIPTION,
+		url: `${SEO.url}${PATH}`,
+		mainEntity: {
+			"@type": "ItemList",
+			itemListElement: allPosts.map((post, index) => ({
+				"@type": "ListItem",
+				position: index + 1,
+				url: `${SEO.url}/blog/${post.slug}`,
+				name: post.title,
+			})),
+		},
+	}
+
+	// Breadcrumb schema
+	const breadcrumbSchema = {
+		"@context": "https://schema.org",
+		"@type": "BreadcrumbList",
+		itemListElement: [
+			{
+				"@type": "ListItem",
+				position: 1,
+				name: "Home",
+				item: SEO.url,
+			},
+			{
+				"@type": "ListItem",
+				position: 2,
+				name: "Blog",
+				item: `${SEO.url}${PATH}`,
+			},
+		],
+	}
+
+	return (
+		<>
+			<Script
+				id="blog-schema"
+				type="application/ld+json"
+				dangerouslySetInnerHTML={{ __html: JSON.stringify(blogSchema) }}
+			/>
+			<Script
+				id="breadcrumb-schema"
+				type="application/ld+json"
+				dangerouslySetInnerHTML={{ __html: JSON.stringify(breadcrumbSchema) }}
+			/>
+
+			<BlogIndexAnalytics />
+
+			<div className="container mx-auto px-4 py-12 sm:px-6 lg:px-8">
+				<div className="mx-auto max-w-4xl">
+					<h1 className="text-3xl font-bold tracking-tight sm:text-4xl md:text-5xl">Blog</h1>
+					<p className="mt-4 text-lg text-muted-foreground">{DESCRIPTION}</p>
+
+					{/* View Toggle */}
+					<Suspense
+						fallback={
+							<div className="mt-6 flex items-center gap-4">
+								<div className="h-11 w-64 animate-pulse rounded-lg bg-muted" />
+							</div>
+						}>
+						<BlogViewToggle curatedCount={curatedPosts.length} totalCount={allPosts.length} />
+					</Suspense>
+
+					{/* Post count indicator for "all" view */}
+					{view === "all" && totalPages > 1 && (
+						<p className="mt-4 text-sm text-muted-foreground">
+							Showing {displayPosts.length} of {allPosts.length} posts
+						</p>
+					)}
+
+					<BlogPostList posts={displayPosts} />
+
+					{/* Pagination only for "all" view */}
+					{showPagination && (
+						<BlogPagination currentPage={currentPage} totalPages={totalPages} useQueryParams />
+					)}
+
+					{/* Cloud CTA - shown after posts */}
+					<BlogPostCTA />
+				</div>
+			</div>
+		</>
+	)
+}
diff --git a/apps/web-roo-code/src/app/blog/page/[page]/page.tsx b/apps/web-roo-code/src/app/blog/page/[page]/page.tsx
new file mode 100644
index 00000000000..32f07f7690c
--- /dev/null
+++ b/apps/web-roo-code/src/app/blog/page/[page]/page.tsx
@@ -0,0 +1,174 @@
+/**
+ * Blog Paginated Index Page
+ * Handles pages 2+ of the blog listing
+ *
+ * URL structure: /blog/page/2, /blog/page/3, etc.
+ * Page 1 redirects to /blog for canonical URL consistency.
+ */
+
+import type { Metadata } from "next"
+import { notFound, redirect } from "next/navigation"
+import Script from "next/script"
+import { getPaginatedBlogPosts, getAllBlogPosts, POSTS_PER_PAGE } from "@/lib/blog"
+import { SEO } from "@/lib/seo"
+import { ogImageUrl } from "@/lib/og"
+import { BlogIndexAnalytics } from "@/components/blog/BlogAnalytics"
+import { BlogPostList } from "@/components/blog/BlogPostList"
+import { BlogPagination } from "@/components/blog/BlogPagination"
+import { BlogPostCTA } from "@/components/blog/BlogPostCTA"
+
+// Force dynamic rendering for request-time publish gating
+export const dynamic = "force-dynamic"
+export const runtime = "nodejs"
+
+interface PageProps {
+	params: Promise<{ page: string }>
+}
+
+const BASE_TITLE = "Blog"
+const DESCRIPTION = "How teams use agents to iterate, review, and ship PRs with proof."
+const BASE_PATH = "/blog"
+
+export async function generateMetadata({ params }: PageProps): Promise<Metadata> {
+	const { page: pageParam } = await params
+	const pageNumber = parseInt(pageParam, 10)
+	const title = `${BASE_TITLE} - Page ${pageNumber}`
+	const path = `${BASE_PATH}/page/${pageNumber}`
+
+	return {
+		title,
+		description: DESCRIPTION,
+		alternates: {
+			canonical: `${SEO.url}${path}`,
+		},
+		openGraph: {
+			title,
+			description: DESCRIPTION,
+			url: `${SEO.url}${path}`,
+			siteName: SEO.name,
+			images: [
+				{
+					url: ogImageUrl(title, DESCRIPTION),
+					width: 1200,
+					height: 630,
+					alt: title,
+				},
+			],
+			locale: SEO.locale,
+			type: "website",
+		},
+		twitter: {
+			card: SEO.twitterCard,
+			title,
+			description: DESCRIPTION,
+			images: [ogImageUrl(title, DESCRIPTION)],
+		},
+		keywords: [...SEO.keywords, "blog", "articles", "engineering", "AI development"],
+		robots: {
+			index: true,
+			follow: true,
+		},
+	}
+}
+
+/**
+ * Generate static params for known pages at build time
+ * This helps with initial page load performance
+ */
+export async function generateStaticParams() {
+	const allPosts = getAllBlogPosts()
+	const totalPages = Math.ceil(allPosts.length / POSTS_PER_PAGE)
+
+	// Generate params for pages 2 through totalPages
+	const params = []
+	for (let page = 2; page <= totalPages; page++) {
+		params.push({ page: page.toString() })
+	}
+
+	return params
+}
+
+export default async function BlogPaginatedPage({ params }: PageProps) {
+	const { page: pageParam } = await params
+	const pageNumber = parseInt(pageParam, 10)
+
+	// Validate page number
+	if (isNaN(pageNumber) || pageNumber < 1) {
+		notFound()
+	}
+
+	// Redirect page 1 to /blog for canonical URL
+	if (pageNumber === 1) {
+		redirect("/blog")
+	}
+
+	const { posts, currentPage, totalPages, totalPosts } = getPaginatedBlogPosts(pageNumber)
+
+	// If page is beyond total pages, 404
+	if (pageNumber > totalPages && totalPages > 0) {
+		notFound()
+	}
+
+	const title = `${BASE_TITLE} - Page ${pageNumber}`
+	const path = `${BASE_PATH}/page/${pageNumber}`
+
+	// Breadcrumb schema
+	const breadcrumbSchema = {
+		"@context": "https://schema.org",
+		"@type": "BreadcrumbList",
+		itemListElement: [
+			{
+				"@type": "ListItem",
+				position: 1,
+				name: "Home",
+				item: SEO.url,
+			},
+			{
+				"@type": "ListItem",
+				position: 2,
+				name: "Blog",
+				item: `${SEO.url}${BASE_PATH}`,
+			},
+			{
+				"@type": "ListItem",
+				position: 3,
+				name: `Page ${pageNumber}`,
+				item: `${SEO.url}${path}`,
+			},
+		],
+	}
+
+	// Calculate post range for display
+	const startPost = (currentPage - 1) * POSTS_PER_PAGE + 1
+	const endPost = Math.min(currentPage * POSTS_PER_PAGE, totalPosts)
+
+	return (
+		<>
+			<Script
+				id="breadcrumb-schema"
+				type="application/ld+json"
+				dangerouslySetInnerHTML={{ __html: JSON.stringify(breadcrumbSchema) }}
+			/>
+
+			<BlogIndexAnalytics />
+
+			<div className="container mx-auto px-4 py-12 sm:px-6 lg:px-8">
+				<div className="mx-auto max-w-4xl">
+					<h1 className="text-3xl font-bold tracking-tight sm:text-4xl md:text-5xl">{title}</h1>
+					<p className="mt-4 text-lg text-muted-foreground">{DESCRIPTION}</p>
+
+					<p className="mt-2 text-sm text-muted-foreground">
+						Showing posts {startPost}-{endPost} of {totalPosts}
+					</p>
+
+					<BlogPostList posts={posts} />
+
+					<BlogPagination currentPage={currentPage} totalPages={totalPages} />
+
+					{/* Cloud CTA - shown after pagination */}
+					<BlogPostCTA />
+				</div>
+			</div>
+		</>
+	)
+}
diff --git a/apps/web-roo-code/src/components/blog/BlogAnalytics.tsx b/apps/web-roo-code/src/components/blog/BlogAnalytics.tsx
new file mode 100644
index 00000000000..a393d035109
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/BlogAnalytics.tsx
@@ -0,0 +1,50 @@
+"use client"
+
+/**
+ * Client-side blog analytics components
+ * MKT-74: Blog Analytics (PostHog)
+ */
+
+import { useEffect } from "react"
+import { trackBlogIndexView, trackBlogPostView } from "@/lib/blog/analytics"
+import type { BlogPost } from "@/lib/blog/types"
+
+/**
+ * Tracks blog index page view
+ * Place this component on the blog index page
+ */
+export function BlogIndexAnalytics() {
+	useEffect(() => {
+		trackBlogIndexView()
+	}, [])
+
+	return null
+}
+
+/**
+ * Tracks individual blog post view
+ * Place this component on blog post pages
+ */
+export function BlogPostAnalytics({ post }: { post: BlogPost }) {
+	useEffect(() => {
+		trackBlogPostView(post)
+	}, [post])
+
+	return null
+}
+
+/**
+ * Serializable post data for client component
+ * Use this type when passing post data to BlogPostAnalytics
+ */
+export interface SerializablePostData {
+	slug: string
+	title: string
+	publish_date: string
+	publish_time_pt: string
+	tags: string[]
+	status: "draft" | "published"
+	description: string
+	content: string
+	filepath: string
+}
diff --git a/apps/web-roo-code/src/components/blog/BlogContent.tsx b/apps/web-roo-code/src/components/blog/BlogContent.tsx
new file mode 100644
index 00000000000..37ad977b269
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/BlogContent.tsx
@@ -0,0 +1,241 @@
+"use client"
+
+import * as React from "react"
+import ReactMarkdown from "react-markdown"
+import remarkGfm from "remark-gfm"
+import { Play } from "lucide-react"
+import { YouTubeModal, isYouTubeUrl, extractYouTubeVideoId, extractYouTubeTimestamp } from "./YouTubeModal"
+
+type HastLikeNode = {
+	type?: unknown
+	tagName?: unknown
+	url?: unknown
+	properties?: unknown
+	children?: unknown
+}
+
+function getNodeUrl(node: HastLikeNode): string | null {
+	// mdast link node (remark)
+	if (node.type === "link" && typeof node.url === "string") return node.url
+
+	// hast anchor element (rehype)
+	if (node.type === "element" && node.tagName === "a") {
+		const props = node.properties as { href?: unknown } | undefined
+		if (typeof props?.href === "string") return props.href
+	}
+
+	return null
+}
+
+function nodeHasYouTubeLink(node: unknown): boolean {
+	if (!node || typeof node !== "object") return false
+
+	const anyNode = node as HastLikeNode
+	const url = getNodeUrl(anyNode)
+	if (url && isYouTubeUrl(url)) {
+		return true
+	}
+
+	const children = (anyNode as { children?: unknown }).children
+	if (Array.isArray(children)) {
+		return children.some(nodeHasYouTubeLink)
+	}
+
+	return false
+}
+
+interface BlogContentProps {
+	/** The markdown content to render */
+	content: string
+}
+
+/**
+ * State for the currently active YouTube video modal
+ */
+interface YouTubeModalState {
+	isOpen: boolean
+	videoId: string
+	startTime: number
+	title: string
+}
+
+/**
+ * BlogContent component
+ *
+ * Renders markdown content with special handling for YouTube links.
+ * YouTube links open in a modal with embedded video player instead of
+ * navigating away from the page.
+ *
+ * @example
+ * ```tsx
+ * <BlogContent content={markdownString} />
+ * ```
+ */
+export function BlogContent({ content }: BlogContentProps) {
+	const [youtubeModal, setYoutubeModal] = React.useState<YouTubeModalState>({
+		isOpen: false,
+		videoId: "",
+		startTime: 0,
+		title: "",
+	})
+
+	/**
+	 * Opens the YouTube modal with the specified video
+	 */
+	const openYouTubeModal = React.useCallback((url: string, linkText: string) => {
+		const videoId = extractYouTubeVideoId(url)
+		if (!videoId) return
+
+		const startTime = extractYouTubeTimestamp(url)
+
+		setYoutubeModal({
+			isOpen: true,
+			videoId,
+			startTime,
+			title: linkText,
+		})
+	}, [])
+
+	/**
+	 * Closes the YouTube modal
+	 */
+	const closeYouTubeModal = React.useCallback(() => {
+		setYoutubeModal((prev) => ({ ...prev, isOpen: false }))
+	}, [])
+
+	return (
+		<>
+			<ReactMarkdown
+				remarkPlugins={[remarkGfm]}
+				components={{
+					// Custom heading styles - note: h1 in content becomes h2 to preserve single H1
+					h1: ({ node: _node, ...props }) => <h2 className="mt-12 text-2xl font-bold" {...props} />,
+					h2: ({ node: _node, ...props }) => <h2 className="mt-12 text-2xl font-bold" {...props} />,
+					h3: ({ node: _node, ...props }) => <h3 className="mt-8 text-xl font-semibold" {...props} />,
+					// Custom link component with YouTube modal support
+					a: ({ href, children, node: _node }) => {
+						const url = href ?? ""
+						const linkText =
+							typeof children === "string"
+								? children
+								: Array.isArray(children)
+									? children.join("")
+									: "YouTube Video"
+
+						// Check if this is a YouTube link
+						if (isYouTubeUrl(url)) {
+							return (
+								<button
+									type="button"
+									onClick={(e) => {
+										e.preventDefault()
+										openYouTubeModal(url, linkText)
+									}}
+									className="inline-flex items-baseline gap-1 text-primary hover:underline">
+									<Play className="relative top-px h-4 w-4" />
+									{children}
+								</button>
+							)
+						}
+
+						// Regular external link - opens in new tab
+						return (
+							<a
+								className="text-primary hover:underline"
+								target="_blank"
+								rel="noopener noreferrer"
+								href={href}>
+								{children}
+							</a>
+						)
+					},
+					// Styled blockquotes
+					blockquote: ({ node, ...props }) => {
+						const children = (node as { children?: unknown[] } | undefined)?.children
+						const lastNonTextChild = Array.isArray(children)
+							? [...children].reverse().find((c) => {
+									if (!c || typeof c !== "object") return false
+									const anyChild = c as { type?: unknown }
+									// mdast uses "paragraph"; hast uses "element"
+									return anyChild.type === "paragraph" || anyChild.type === "element"
+								})
+							: null
+						const isAttributedQuote = nodeHasYouTubeLink(lastNonTextChild)
+
+						return (
+							<blockquote
+								className={[
+									// Opt out of Tailwind Typography's automatic quote marks for blockquotes.
+									"not-prose my-6 border-l-4 border-primary pl-4 text-muted-foreground",
+									// Normalize paragraph spacing inside blockquotes regardless of our global <p> renderer.
+									"[&>p]:m-0 [&>p+ p]:mt-4",
+									isAttributedQuote
+										? [
+												// Quote text reads well in italics, but the attribution line shouldn't.
+												"[&>p:not(:last-child)]:italic",
+												"[&>p:last-child]:not-italic",
+											].join(" ")
+										: "italic",
+								].join(" ")}
+								{...props}
+							/>
+						)
+					},
+					// Code blocks
+					code: ({ className, children, node: _node, ...props }) => {
+						const isInline = !className
+						if (isInline) {
+							return (
+								<code className="rounded bg-muted px-1.5 py-0.5 text-sm" {...props}>
+									{children}
+								</code>
+							)
+						}
+						return (
+							<code className={className} {...props}>
+								{children}
+							</code>
+						)
+					},
+					// Strong text
+					strong: ({ node: _node, ...props }) => <strong className="font-semibold" {...props} />,
+					// Paragraphs
+					p: ({ node: _node, ...props }) => <p className="leading-7 [&:not(:first-child)]:mt-6" {...props} />,
+					// Lists
+					ul: ({ node: _node, ...props }) => <ul className="my-6 ml-6 list-disc [&>li]:mt-2" {...props} />,
+					ol: ({ node: _node, ...props }) => <ol className="my-6 ml-6 list-decimal [&>li]:mt-2" {...props} />,
+					// Tables with zebra striping (visible in both light and dark mode)
+					table: ({ node: _node, ...props }) => (
+						<div className="not-prose my-6 w-full overflow-x-auto rounded-lg border border-border">
+							<table className="w-full border-collapse text-sm" {...props} />
+						</div>
+					),
+					thead: ({ node: _node, ...props }) => <thead className="bg-muted" {...props} />,
+					tbody: ({ node: _node, ...props }) => <tbody {...props} />,
+					tr: ({ node: _node, ...props }) => (
+						<tr
+							className="border-b border-border last:border-b-0 transition-colors even:bg-muted/70 hover:bg-muted"
+							{...props}
+						/>
+					),
+					th: ({ node: _node, ...props }) => (
+						<th className="px-4 py-3 text-left font-semibold text-foreground" {...props} />
+					),
+					td: ({ node: _node, ...props }) => <td className="px-4 py-3" {...props} />,
+				}}>
+				{content}
+			</ReactMarkdown>
+
+			{/* YouTube Video Modal */}
+			<YouTubeModal
+				open={youtubeModal.isOpen}
+				onOpenChange={closeYouTubeModal}
+				videoId={youtubeModal.videoId}
+				startTime={youtubeModal.startTime}
+				title={youtubeModal.title}
+			/>
+		</>
+	)
+}
+
+export default BlogContent
diff --git a/apps/web-roo-code/src/components/blog/BlogFAQ.tsx b/apps/web-roo-code/src/components/blog/BlogFAQ.tsx
new file mode 100644
index 00000000000..7d7c3ff479e
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/BlogFAQ.tsx
@@ -0,0 +1,66 @@
+"use client"
+
+import { useState } from "react"
+import { ChevronDown } from "lucide-react"
+import { cn } from "@/lib/utils"
+
+export interface FAQItem {
+	question: string
+	answer: string
+}
+
+interface BlogFAQProps {
+	items: FAQItem[]
+}
+
+/**
+ * BlogFAQ - Accordion-style FAQ section for blog posts
+ *
+ * Renders FAQ items in a collapsible accordion format to reduce page length
+ * while maintaining full content visibility for AI crawlers (server-rendered).
+ */
+export function BlogFAQ({ items }: BlogFAQProps) {
+	const [openIndex, setOpenIndex] = useState<number | null>(null)
+
+	const toggleFAQ = (index: number) => {
+		setOpenIndex(openIndex === index ? null : index)
+	}
+
+	if (items.length === 0) return null
+
+	return (
+		<section className="mt-12 not-prose">
+			<h2 className="text-2xl font-bold mb-6">Frequently asked questions</h2>
+			<div className="space-y-3">
+				{items.map((item, index) => (
+					<div key={index} className="rounded-lg border border-border bg-card/50 overflow-hidden">
+						<button
+							onClick={() => toggleFAQ(index)}
+							className="flex w-full items-center justify-between p-4 text-left hover:bg-muted/50 transition-colors"
+							aria-expanded={openIndex === index}>
+							<h3 className="text-base font-medium text-foreground pr-4">{item.question}</h3>
+							<ChevronDown
+								className={cn(
+									"h-5 w-5 flex-shrink-0 text-muted-foreground transition-transform duration-200",
+									openIndex === index ? "rotate-180" : "",
+								)}
+							/>
+						</button>
+						<div
+							className={cn(
+								"overflow-hidden transition-all duration-300 ease-in-out",
+								openIndex === index ? "max-h-[500px]" : "max-h-0",
+							)}>
+							<div className="px-4 pb-4 text-muted-foreground leading-relaxed">{item.answer}</div>
+						</div>
+						{/* Hidden content for crawlers - ensures FAQ content is always in the DOM */}
+						<div className="sr-only" aria-hidden="true">
+							<p>{item.question}</p>
+							<p>{item.answer}</p>
+						</div>
+					</div>
+				))}
+			</div>
+		</section>
+	)
+}
diff --git a/apps/web-roo-code/src/components/blog/BlogPagination.tsx b/apps/web-roo-code/src/components/blog/BlogPagination.tsx
new file mode 100644
index 00000000000..cffab4408b5
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/BlogPagination.tsx
@@ -0,0 +1,185 @@
+/**
+ * Blog Pagination Component
+ * Provides navigation between paginated blog listing pages
+ */
+
+import Link from "next/link"
+import { ChevronLeft, ChevronRight } from "lucide-react"
+import { cn } from "@/lib/utils"
+
+interface BlogPaginationProps {
+	currentPage: number
+	totalPages: number
+	basePath?: string
+	/** If true, use query params (?view=all&page=N) instead of path-based pagination */
+	useQueryParams?: boolean
+}
+
+/**
+ * Generates the URL for a given page number
+ * Default: Page 1 goes to /blog, pages 2+ go to /blog/page/N
+ * With useQueryParams: Uses /blog?view=all or /blog?view=all&page=N
+ */
+function getPageUrl(page: number, basePath: string, useQueryParams?: boolean): string {
+	if (useQueryParams) {
+		if (page === 1) {
+			return "/blog?view=all"
+		}
+		return `/blog?view=all&page=${page}`
+	}
+
+	if (page === 1) {
+		return basePath
+	}
+	return `${basePath}/page/${page}`
+}
+
+/**
+ * Generates page numbers to display
+ * Shows: first, last, current, and neighbors with ellipsis for gaps
+ */
+function getPageNumbers(currentPage: number, totalPages: number): (number | "ellipsis")[] {
+	const pages: (number | "ellipsis")[] = []
+
+	if (totalPages <= 7) {
+		// Show all pages if 7 or fewer
+		for (let i = 1; i <= totalPages; i++) {
+			pages.push(i)
+		}
+		return pages
+	}
+
+	// Always show first page
+	pages.push(1)
+
+	// Calculate range around current page
+	const leftBound = Math.max(2, currentPage - 1)
+	const rightBound = Math.min(totalPages - 1, currentPage + 1)
+
+	// Add ellipsis before range if needed
+	if (leftBound > 2) {
+		pages.push("ellipsis")
+	}
+
+	// Add pages in range
+	for (let i = leftBound; i <= rightBound; i++) {
+		pages.push(i)
+	}
+
+	// Add ellipsis after range if needed
+	if (rightBound < totalPages - 1) {
+		pages.push("ellipsis")
+	}
+
+	// Always show last page
+	pages.push(totalPages)
+
+	return pages
+}
+
+export function BlogPagination({ currentPage, totalPages, basePath = "/blog", useQueryParams }: BlogPaginationProps) {
+	if (totalPages <= 1) {
+		return null
+	}
+
+	const pageNumbers = getPageNumbers(currentPage, totalPages)
+	const hasPreviousPage = currentPage > 1
+	const hasNextPage = currentPage < totalPages
+
+	return (
+		<nav aria-label="Blog pagination" className="mt-12 flex items-center justify-center gap-1 sm:gap-2">
+			{/* Previous button */}
+			{hasPreviousPage ? (
+				<Link
+					href={getPageUrl(currentPage - 1, basePath, useQueryParams)}
+					className={cn(
+						"flex items-center gap-1 rounded-md px-3 py-2 text-sm font-medium",
+						"text-muted-foreground hover:bg-muted hover:text-foreground",
+						"transition-colors",
+					)}
+					aria-label="Go to previous page">
+					<ChevronLeft className="h-4 w-4" />
+					<span className="hidden sm:inline">Previous</span>
+				</Link>
+			) : (
+				<span
+					className={cn(
+						"flex items-center gap-1 rounded-md px-3 py-2 text-sm font-medium",
+						"cursor-not-allowed text-muted-foreground/50",
+					)}
+					aria-disabled="true">
+					<ChevronLeft className="h-4 w-4" />
+					<span className="hidden sm:inline">Previous</span>
+				</span>
+			)}
+
+			{/* Page numbers */}
+			<div className="flex items-center gap-1">
+				{pageNumbers.map((page, index) => {
+					if (page === "ellipsis") {
+						return (
+							<span key={`ellipsis-${index}`} className="px-2 py-2 text-sm text-muted-foreground">
+								...
+							</span>
+						)
+					}
+
+					const isCurrentPage = page === currentPage
+
+					if (isCurrentPage) {
+						return (
+							<span
+								key={page}
+								className={cn(
+									"flex h-9 w-9 items-center justify-center rounded-md text-sm font-medium",
+									"bg-primary text-primary-foreground",
+								)}
+								aria-current="page">
+								{page}
+							</span>
+						)
+					}
+
+					return (
+						<Link
+							key={page}
+							href={getPageUrl(page, basePath, useQueryParams)}
+							className={cn(
+								"flex h-9 w-9 items-center justify-center rounded-md text-sm font-medium",
+								"text-muted-foreground hover:bg-muted hover:text-foreground",
+								"transition-colors",
+							)}
+							aria-label={`Go to page ${page}`}>
+							{page}
+						</Link>
+					)
+				})}
+			</div>
+
+			{/* Next button */}
+			{hasNextPage ? (
+				<Link
+					href={getPageUrl(currentPage + 1, basePath, useQueryParams)}
+					className={cn(
+						"flex items-center gap-1 rounded-md px-3 py-2 text-sm font-medium",
+						"text-muted-foreground hover:bg-muted hover:text-foreground",
+						"transition-colors",
+					)}
+					aria-label="Go to next page">
+					<span className="hidden sm:inline">Next</span>
+					<ChevronRight className="h-4 w-4" />
+				</Link>
+			) : (
+				<span
+					className={cn(
+						"flex items-center gap-1 rounded-md px-3 py-2 text-sm font-medium",
+						"cursor-not-allowed text-muted-foreground/50",
+					)}
+					aria-disabled="true">
+					<span className="hidden sm:inline">Next</span>
+					<ChevronRight className="h-4 w-4" />
+				</span>
+			)}
+		</nav>
+	)
+}
diff --git a/apps/web-roo-code/src/components/blog/BlogPostCTA.tsx b/apps/web-roo-code/src/components/blog/BlogPostCTA.tsx
new file mode 100644
index 00000000000..17f944f75a5
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/BlogPostCTA.tsx
@@ -0,0 +1,225 @@
+/**
+ * Blog Post CTA Component
+ * Inspired by Vercel's blog design - contextual call-to-action modules
+ *
+ * Provides end-of-article product CTAs to help convert readers into users.
+ */
+
+import Link from "next/link"
+import { ArrowRight, Sparkles, Code2, GitPullRequest } from "lucide-react"
+import { Button } from "@/components/ui/button"
+import { EXTERNAL_LINKS } from "@/lib/constants"
+
+interface CTALink {
+	label: string
+	href: string
+	description?: string
+	external?: boolean
+}
+
+interface BlogPostCTAProps {
+	/** The main headline for the CTA module */
+	headline?: string
+	/** Description text below the headline */
+	description?: string
+	/** Primary CTA button text */
+	primaryButtonText?: string
+	/** Primary CTA button link */
+	primaryButtonHref?: string
+	/** Secondary CTA button text */
+	secondaryButtonText?: string
+	/** Secondary CTA button link */
+	secondaryButtonHref?: string
+	/** Optional list of related links to show */
+	links?: CTALink[]
+	/** Variant style for the CTA */
+	variant?: "default" | "extension" | "cloud" | "enterprise"
+}
+
+const variantConfig = {
+	// Default prioritizes Cloud sign-up with workflow-truth messaging
+	default: {
+		headline: "Stop being the human glue between PRs",
+		description:
+			"Cloud Agents review code, catch issues, and suggest fixes before you open the diff. You review the results, not the process.",
+		primaryText: "Try Cloud Free",
+		primaryHref: EXTERNAL_LINKS.CLOUD_APP_SIGNUP_HOME,
+		secondaryText: "See How It Works",
+		secondaryHref: "/cloud",
+		icon: Sparkles,
+	},
+	extension: {
+		headline: "Stop copy-pasting between terminal and chat",
+		description:
+			"The agent runs commands, sees the output, and iterates until the tests pass. You review the diff and approve.",
+		primaryText: "Install for VS Code",
+		primaryHref: EXTERNAL_LINKS.MARKETPLACE,
+		secondaryText: "View Docs",
+		secondaryHref: EXTERNAL_LINKS.DOCUMENTATION,
+		icon: Code2,
+	},
+	cloud: {
+		headline: "Let Cloud Agents handle the review queue",
+		description:
+			"PR Reviewer checks out your branch, runs your linters, and leaves inline suggestions. You decide what to merge.",
+		primaryText: "Start Free",
+		primaryHref: EXTERNAL_LINKS.CLOUD_APP_SIGNUP_HOME,
+		secondaryText: "View Pricing",
+		secondaryHref: "/pricing",
+		icon: Sparkles,
+	},
+	enterprise: {
+		headline: "Thinking about security, compliance, or adoption?",
+		description:
+			"We're explicit about data handling, control boundaries, and what runs where. Talk to us about your constraints.",
+		primaryText: "Talk to Sales",
+		primaryHref: "/enterprise",
+		secondaryText: "View Trust Center",
+		secondaryHref: EXTERNAL_LINKS.SECURITY,
+		icon: GitPullRequest,
+	},
+}
+
+/**
+ * A contextual CTA module for blog posts
+ * Inspired by Vercel's "Get started" modules at the end of blog posts
+ */
+export function BlogPostCTA({
+	headline,
+	description,
+	primaryButtonText,
+	primaryButtonHref,
+	secondaryButtonText,
+	secondaryButtonHref,
+	links,
+	variant = "default",
+}: BlogPostCTAProps) {
+	const config = variantConfig[variant]
+	const Icon = config.icon
+
+	const finalHeadline = headline ?? config.headline
+	const finalDescription = description ?? config.description
+	const finalPrimaryText = primaryButtonText ?? config.primaryText
+	const finalPrimaryHref = primaryButtonHref ?? config.primaryHref
+	const finalSecondaryText = secondaryButtonText ?? config.secondaryText
+	const finalSecondaryHref = secondaryButtonHref ?? config.secondaryHref
+
+	const isExternalPrimary = finalPrimaryHref.startsWith("http")
+	const isExternalSecondary = finalSecondaryHref.startsWith("http")
+
+	return (
+		<div className="not-prose mt-12 rounded-xl border border-border bg-muted/30 p-6 sm:p-8">
+			<div className="flex flex-col gap-6 sm:flex-row sm:items-start sm:gap-8">
+				{/* Icon */}
+				<div className="flex h-12 w-12 shrink-0 items-center justify-center rounded-lg bg-primary/10">
+					<Icon className="h-6 w-6 text-primary" />
+				</div>
+
+				{/* Content */}
+				<div className="flex-1">
+					<h3 className="text-xl font-semibold text-foreground">{finalHeadline}</h3>
+					<p className="mt-2 text-muted-foreground">{finalDescription}</p>
+
+					{/* Links list (optional, Vercel-style numbered list) */}
+					{links && links.length > 0 && (
+						<ol className="mt-4 space-y-2">
+							{links.map((link, index) => (
+								<li key={link.href} className="flex items-start gap-3">
+									<span className="flex h-6 w-6 shrink-0 items-center justify-center rounded-full bg-primary/10 text-xs font-medium text-primary">
+										{index + 1}
+									</span>
+									<div>
+										{link.external ? (
+											<a
+												href={link.href}
+												target="_blank"
+												rel="noopener noreferrer"
+												className="font-medium text-primary hover:underline">
+												{link.label}
+											</a>
+										) : (
+											<Link href={link.href} className="font-medium text-primary hover:underline">
+												{link.label}
+											</Link>
+										)}
+										{link.description && (
+											<span className="text-muted-foreground"> — {link.description}</span>
+										)}
+									</div>
+								</li>
+							))}
+						</ol>
+					)}
+
+					{/* Action buttons */}
+					<div className="mt-6 flex flex-col gap-3 sm:flex-row">
+						{isExternalPrimary ? (
+							<Button asChild>
+								<a href={finalPrimaryHref} target="_blank" rel="noopener noreferrer">
+									{finalPrimaryText}
+									<ArrowRight className="ml-1 h-4 w-4" />
+								</a>
+							</Button>
+						) : (
+							<Button asChild>
+								<Link href={finalPrimaryHref}>
+									{finalPrimaryText}
+									<ArrowRight className="ml-1 h-4 w-4" />
+								</Link>
+							</Button>
+						)}
+
+						{isExternalSecondary ? (
+							<Button variant="outline" asChild>
+								<a href={finalSecondaryHref} target="_blank" rel="noopener noreferrer">
+									{finalSecondaryText}
+								</a>
+							</Button>
+						) : (
+							<Button variant="outline" asChild>
+								<Link href={finalSecondaryHref}>{finalSecondaryText}</Link>
+							</Button>
+						)}
+					</div>
+				</div>
+			</div>
+		</div>
+	)
+}
+
+/**
+ * Get Started links component (Vercel-style numbered list)
+ * Can be used standalone or within BlogPostCTA
+ */
+export function GetStartedLinks({ links }: { links: CTALink[] }) {
+	return (
+		<div className="not-prose mt-8 rounded-lg border border-border bg-muted/30 p-6">
+			<h4 className="font-semibold text-foreground">Get started</h4>
+			<ol className="mt-4 space-y-3">
+				{links.map((link, index) => (
+					<li key={link.href} className="flex items-start gap-3">
+						<span className="flex h-6 w-6 shrink-0 items-center justify-center rounded-full bg-primary/10 text-xs font-medium text-primary">
+							{index + 1}
+						</span>
+						<div>
+							{link.external ? (
+								<a
+									href={link.href}
+									target="_blank"
+									rel="noopener noreferrer"
+									className="font-medium text-primary hover:underline">
+									{link.label}
+								</a>
+							) : (
+								<Link href={link.href} className="font-medium text-primary hover:underline">
+									{link.label}
+								</Link>
+							)}
+							{link.description && <span className="text-muted-foreground"> — {link.description}</span>}
+						</div>
+					</li>
+				))}
+			</ol>
+		</div>
+	)
+}
diff --git a/apps/web-roo-code/src/components/blog/BlogPostList.tsx b/apps/web-roo-code/src/components/blog/BlogPostList.tsx
new file mode 100644
index 00000000000..3ba50d59b3d
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/BlogPostList.tsx
@@ -0,0 +1,63 @@
+/**
+ * Blog Post List Component
+ * Renders a list of blog post previews
+ */
+
+import Link from "next/link"
+import type { BlogPost, BlogSource } from "@/lib/blog"
+import { formatPostDatePt } from "@/lib/blog"
+
+interface BlogPostListProps {
+	posts: BlogPost[]
+}
+
+/**
+ * Source badge component
+ * Styling matches the tag badges (rounded, same padding)
+ */
+function SourceBadge({ source }: { source: BlogSource }) {
+	return <span className="rounded bg-muted px-2 py-1 text-xs text-muted-foreground">{source}</span>
+}
+
+export function BlogPostList({ posts }: BlogPostListProps) {
+	if (posts.length === 0) {
+		return (
+			<div className="mt-12 text-center">
+				<p className="text-muted-foreground">No posts published yet. Check back soon!</p>
+			</div>
+		)
+	}
+
+	return (
+		<div className="mt-12 space-y-12">
+			{posts.map((post) => (
+				<article key={post.slug} className="border-b border-border pb-12 last:border-b-0">
+					<Link href={`/blog/${post.slug}`} className="group">
+						<h2 className="text-xl font-semibold tracking-tight transition-colors group-hover:text-primary sm:text-2xl">
+							{post.title}
+						</h2>
+					</Link>
+					<div className="mt-2 flex flex-wrap items-center gap-2 text-sm text-muted-foreground">
+						{post.source && <SourceBadge source={post.source} />}
+						<span>{formatPostDatePt(post.publish_date)}</span>
+					</div>
+					<p className="mt-3 text-muted-foreground">{post.description}</p>
+					{post.tags.length > 0 && (
+						<div className="mt-4 flex flex-wrap gap-2">
+							{post.tags.map((tag) => (
+								<span key={tag} className="rounded bg-muted px-2 py-1 text-xs text-muted-foreground">
+									{tag}
+								</span>
+							))}
+						</div>
+					)}
+					<Link
+						href={`/blog/${post.slug}`}
+						className="mt-4 inline-block text-sm font-medium text-primary hover:underline">
+						Read more →
+					</Link>
+				</article>
+			))}
+		</div>
+	)
+}
diff --git a/apps/web-roo-code/src/components/blog/BlogViewToggle.tsx b/apps/web-roo-code/src/components/blog/BlogViewToggle.tsx
new file mode 100644
index 00000000000..2bd8343f4ba
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/BlogViewToggle.tsx
@@ -0,0 +1,58 @@
+/**
+ * Blog View Toggle Component
+ *
+ * Toggles between curated (featured) posts and all posts view.
+ * Uses URL search params for state to support SSR and sharing.
+ */
+
+"use client"
+
+import Link from "next/link"
+import { useSearchParams } from "next/navigation"
+
+export type BlogView = "featured" | "all"
+
+interface BlogViewToggleProps {
+	curatedCount: number
+	totalCount: number
+}
+
+export function BlogViewToggle({ curatedCount, totalCount }: BlogViewToggleProps) {
+	const searchParams = useSearchParams()
+	const currentView = (searchParams.get("view") as BlogView) || "featured"
+
+	return (
+		<div className="mt-6 flex items-center gap-4">
+			<div className="flex rounded-lg border border-border bg-muted/50 p-1">
+				<Link
+					href="/blog"
+					className={`rounded-md px-4 py-2 text-sm font-medium transition-colors ${
+						currentView === "featured"
+							? "bg-background text-foreground shadow-sm"
+							: "text-muted-foreground hover:text-foreground"
+					}`}>
+					Featured
+					<span className="ml-1.5 text-xs text-muted-foreground">({curatedCount})</span>
+				</Link>
+				<Link
+					href="/blog?view=all"
+					className={`rounded-md px-4 py-2 text-sm font-medium transition-colors ${
+						currentView === "all"
+							? "bg-background text-foreground shadow-sm"
+							: "text-muted-foreground hover:text-foreground"
+					}`}>
+					All Posts
+					<span className="ml-1.5 text-xs text-muted-foreground">({totalCount})</span>
+				</Link>
+			</div>
+		</div>
+	)
+}
+
+/**
+ * Get the current blog view from search params
+ */
+export function getBlogView(searchParams: URLSearchParams): BlogView {
+	const view = searchParams.get("view")
+	return view === "all" ? "all" : "featured"
+}
diff --git a/apps/web-roo-code/src/components/blog/YouTubeModal.test.ts b/apps/web-roo-code/src/components/blog/YouTubeModal.test.ts
new file mode 100644
index 00000000000..fed89f170bf
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/YouTubeModal.test.ts
@@ -0,0 +1,140 @@
+import { describe, it, expect } from "vitest"
+import { extractYouTubeVideoId, extractYouTubeTimestamp, isYouTubeUrl } from "./YouTubeModal"
+
+describe("isYouTubeUrl", () => {
+	it("should return true for youtube.com/watch URLs", () => {
+		expect(isYouTubeUrl("https://www.youtube.com/watch?v=dQw4w9WgXcQ")).toBe(true)
+		expect(isYouTubeUrl("http://youtube.com/watch?v=dQw4w9WgXcQ")).toBe(true)
+		expect(isYouTubeUrl("https://youtube.com/watch?v=abc123_-XYZ")).toBe(true)
+	})
+
+	it("should return true for youtu.be URLs", () => {
+		expect(isYouTubeUrl("https://youtu.be/dQw4w9WgXcQ")).toBe(true)
+		expect(isYouTubeUrl("http://youtu.be/abc123_-XYZ")).toBe(true)
+	})
+
+	it("should return true for youtube.com/embed URLs", () => {
+		expect(isYouTubeUrl("https://www.youtube.com/embed/dQw4w9WgXcQ")).toBe(true)
+	})
+
+	it("should return true for youtube.com/v URLs", () => {
+		expect(isYouTubeUrl("https://www.youtube.com/v/dQw4w9WgXcQ")).toBe(true)
+	})
+
+	it("should return false for non-YouTube URLs", () => {
+		expect(isYouTubeUrl("https://www.google.com")).toBe(false)
+		expect(isYouTubeUrl("https://vimeo.com/123456")).toBe(false)
+		expect(isYouTubeUrl("https://example.com/youtube.com")).toBe(false)
+	})
+
+	it("should return false for invalid URLs", () => {
+		expect(isYouTubeUrl("not a url")).toBe(false)
+		expect(isYouTubeUrl("")).toBe(false)
+	})
+})
+
+describe("extractYouTubeVideoId", () => {
+	it("should extract video ID from youtube.com/watch URLs", () => {
+		expect(extractYouTubeVideoId("https://www.youtube.com/watch?v=dQw4w9WgXcQ")).toBe("dQw4w9WgXcQ")
+		expect(extractYouTubeVideoId("https://www.youtube.com/watch?v=abc123_-XYZ&list=PLxyz")).toBe("abc123_-XYZ")
+		expect(extractYouTubeVideoId("https://www.youtube.com/watch?feature=share&v=dQw4w9WgXcQ")).toBe("dQw4w9WgXcQ")
+	})
+
+	it("should extract video ID from youtu.be URLs", () => {
+		expect(extractYouTubeVideoId("https://youtu.be/dQw4w9WgXcQ")).toBe("dQw4w9WgXcQ")
+		expect(extractYouTubeVideoId("https://youtu.be/abc123_-XYZ?t=42")).toBe("abc123_-XYZ")
+	})
+
+	it("should extract video ID from youtube.com/embed URLs", () => {
+		expect(extractYouTubeVideoId("https://www.youtube.com/embed/dQw4w9WgXcQ")).toBe("dQw4w9WgXcQ")
+	})
+
+	it("should extract video ID from youtube.com/v URLs", () => {
+		expect(extractYouTubeVideoId("https://www.youtube.com/v/dQw4w9WgXcQ")).toBe("dQw4w9WgXcQ")
+	})
+
+	it("should return null for non-YouTube URLs", () => {
+		expect(extractYouTubeVideoId("https://www.google.com")).toBeNull()
+		expect(extractYouTubeVideoId("https://vimeo.com/123456")).toBeNull()
+	})
+
+	it("should return null for invalid URLs", () => {
+		expect(extractYouTubeVideoId("not a url")).toBeNull()
+		expect(extractYouTubeVideoId("")).toBeNull()
+	})
+})
+
+describe("extractYouTubeTimestamp", () => {
+	describe("numeric timestamps (seconds)", () => {
+		it("should extract timestamp in seconds from youtube.com URLs", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=42")).toBe(42)
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?t=120&v=dQw4w9WgXcQ")).toBe(120)
+		})
+
+		it("should extract timestamp from youtu.be URLs", () => {
+			expect(extractYouTubeTimestamp("https://youtu.be/dQw4w9WgXcQ?t=42")).toBe(42)
+			expect(extractYouTubeTimestamp("https://youtu.be/dQw4w9WgXcQ?t=3600")).toBe(3600)
+		})
+
+		it("should extract timestamp from start= URLs", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&start=42")).toBe(42)
+			expect(extractYouTubeTimestamp("https://www.youtube.com/embed/dQw4w9WgXcQ?start=120")).toBe(120)
+		})
+
+		it("should extract timestamp from fragment (#t=) URLs", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ#t=42")).toBe(42)
+		})
+	})
+
+	describe("h/m/s format timestamps", () => {
+		it("should parse hours, minutes, and seconds", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=1h2m3s")).toBe(3723) // 1*3600 + 2*60 + 3
+		})
+
+		it("should parse minutes and seconds", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=2m30s")).toBe(150) // 2*60 + 30
+		})
+
+		it("should parse seconds only", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=45s")).toBe(45)
+		})
+
+		it("should parse hours and minutes", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=1h30m")).toBe(5400) // 1*3600 + 30*60
+		})
+
+		it("should parse hours only", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=2h")).toBe(7200) // 2*3600
+		})
+
+		it("should be case-insensitive", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=1H2M3S")).toBe(3723)
+		})
+	})
+
+	describe("colon-separated timestamps", () => {
+		it("should parse mm:ss format", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=1:23")).toBe(83)
+		})
+
+		it("should parse hh:mm:ss format", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ&t=1:02:03")).toBe(3723)
+		})
+	})
+
+	describe("edge cases", () => {
+		it("should return 0 when no timestamp is present", () => {
+			expect(extractYouTubeTimestamp("https://www.youtube.com/watch?v=dQw4w9WgXcQ")).toBe(0)
+			expect(extractYouTubeTimestamp("https://youtu.be/dQw4w9WgXcQ")).toBe(0)
+		})
+
+		it("should return 0 for non-YouTube URLs", () => {
+			expect(extractYouTubeTimestamp("https://www.google.com")).toBe(0)
+		})
+
+		it("should return 0 for invalid URLs", () => {
+			expect(extractYouTubeTimestamp("not a url")).toBe(0)
+			expect(extractYouTubeTimestamp("")).toBe(0)
+		})
+	})
+})
diff --git a/apps/web-roo-code/src/components/blog/YouTubeModal.tsx b/apps/web-roo-code/src/components/blog/YouTubeModal.tsx
new file mode 100644
index 00000000000..da173d9c548
--- /dev/null
+++ b/apps/web-roo-code/src/components/blog/YouTubeModal.tsx
@@ -0,0 +1,171 @@
+"use client"
+
+import * as React from "react"
+import { Dialog, DialogContent, DialogTitle } from "@/components/ui/modal"
+
+/**
+ * YouTube URL patterns and utilities
+ */
+
+/** Regular expression to match YouTube URLs and extract video ID */
+const YOUTUBE_URL_REGEX = /(?:youtube\.com\/(?:[^/]+\/.+\/|(?:v|e(?:mbed)?)\/|.*[?&]v=)|youtu\.be\/)([^"&?/\s]{11})/i
+
+/**
+ * Regular expression to extract timestamp from YouTube URLs.
+ *
+ * Supports:
+ * - query params: `t=123`, `t=1h2m3s`, `start=123`, `t=1:23`, `t=1:02:03`
+ * - fragment params: `#t=123` (less common but seen in some links)
+ */
+const TIMESTAMP_REGEX = /(?:[?&#](?:t|start)=)([0-9hms:]+)/i
+
+/**
+ * Extracts the video ID from a YouTube URL
+ * Supports various YouTube URL formats:
+ * - https://www.youtube.com/watch?v=VIDEO_ID
+ * - https://youtu.be/VIDEO_ID
+ * - https://www.youtube.com/embed/VIDEO_ID
+ * - https://www.youtube.com/v/VIDEO_ID
+ *
+ * @param url - The YouTube URL to parse
+ * @returns The video ID or null if not found
+ */
+export function extractYouTubeVideoId(url: string): string | null {
+	const match = url.match(YOUTUBE_URL_REGEX)
+	return match?.[1] ?? null
+}
+
+/**
+ * Parses a YouTube timestamp string to seconds
+ * Supports formats like:
+ * - "123" (seconds)
+ * - "1h2m3s" (hours, minutes, seconds)
+ * - "2m30s" (minutes and seconds)
+ * - "45s" (seconds only)
+ *
+ * @param timestamp - The timestamp string
+ * @returns The timestamp in seconds
+ */
+function parseTimestampToSeconds(timestamp: string): number {
+	// If it's just a number, it's already in seconds
+	if (/^\d+$/.test(timestamp)) {
+		return parseInt(timestamp, 10)
+	}
+
+	// Parse colon-separated formats:
+	// - "mm:ss"
+	// - "hh:mm:ss"
+	const colonMatch = timestamp.match(/^(\d{1,2}):(\d{2})(?::(\d{2}))?$/)
+	if (colonMatch) {
+		const a = parseInt(colonMatch[1] ?? "0", 10)
+		const b = parseInt(colonMatch[2] ?? "0", 10)
+		const c = colonMatch[3] ? parseInt(colonMatch[3], 10) : null
+
+		if (c === null) return a * 60 + b
+		return a * 3600 + b * 60 + c
+	}
+
+	// Parse h/m/s format
+	let totalSeconds = 0
+	const hours = timestamp.match(/(\d+)h/i)
+	const minutes = timestamp.match(/(\d+)m/i)
+	const seconds = timestamp.match(/(\d+)s/i)
+
+	if (hours?.[1]) totalSeconds += parseInt(hours[1], 10) * 3600
+	if (minutes?.[1]) totalSeconds += parseInt(minutes[1], 10) * 60
+	if (seconds?.[1]) totalSeconds += parseInt(seconds[1], 10)
+
+	return totalSeconds
+}
+
+/**
+ * Extracts the start time (in seconds) from a YouTube URL
+ *
+ * @param url - The YouTube URL to parse
+ * @returns The start time in seconds or 0 if not found
+ */
+export function extractYouTubeTimestamp(url: string): number {
+	const match = url.match(TIMESTAMP_REGEX)
+	if (!match?.[1]) return 0
+	return parseTimestampToSeconds(match[1])
+}
+
+/**
+ * Checks if a URL is a YouTube URL
+ *
+ * @param url - The URL to check
+ * @returns True if the URL is a YouTube URL
+ */
+export function isYouTubeUrl(url: string): boolean {
+	return YOUTUBE_URL_REGEX.test(url)
+}
+
+interface YouTubeModalProps {
+	/** Whether the modal is open */
+	open: boolean
+	/** Callback when the modal open state changes */
+	onOpenChange: (open: boolean) => void
+	/** The YouTube video ID */
+	videoId: string
+	/** The start time in seconds (optional) */
+	startTime?: number
+	/** The video title for accessibility (optional) */
+	title?: string
+}
+
+/**
+ * YouTubeModal component
+ *
+ * A modal dialog that embeds a YouTube video player.
+ * Supports starting playback at a specific timestamp.
+ *
+ * @example
+ * ```tsx
+ * <YouTubeModal
+ *   open={isOpen}
+ *   onOpenChange={setIsOpen}
+ *   videoId="dQw4w9WgXcQ"
+ *   startTime={42}
+ *   title="Never Gonna Give You Up"
+ * />
+ * ```
+ */
+export function YouTubeModal({ open, onOpenChange, videoId, startTime = 0, title }: YouTubeModalProps) {
+	// Build the YouTube embed URL with parameters
+	const embedUrl = React.useMemo(() => {
+		const params = new URLSearchParams({
+			autoplay: "1",
+			rel: "0", // Don't show related videos from other channels
+			modestbranding: "1", // Minimal YouTube branding
+		})
+
+		if (startTime > 0) {
+			params.set("start", startTime.toString())
+		}
+
+		return `https://www.youtube.com/embed/${videoId}?${params.toString()}`
+	}, [videoId, startTime])
+
+	return (
+		<Dialog open={open} onOpenChange={onOpenChange}>
+			<DialogContent className="max-w-4xl w-[90vw] p-0 overflow-hidden bg-black" aria-describedby={undefined}>
+				{/* Visually hidden title for accessibility */}
+				<DialogTitle className="sr-only">{title ?? "YouTube Video"}</DialogTitle>
+				<div className="relative w-full pt-[56.25%]">
+					{/* 16:9 aspect ratio container */}
+					{open && (
+						<iframe
+							className="absolute inset-0 w-full h-full"
+							src={embedUrl}
+							title={title ?? "YouTube Video"}
+							allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share"
+							allowFullScreen
+						/>
+					)}
+				</div>
+			</DialogContent>
+		</Dialog>
+	)
+}
+
+export default YouTubeModal
diff --git a/apps/web-roo-code/src/components/chromes/footer.tsx b/apps/web-roo-code/src/components/chromes/footer.tsx
index 7f0de4082f5..98835dab6fd 100644
--- a/apps/web-roo-code/src/components/chromes/footer.tsx
+++ b/apps/web-roo-code/src/components/chromes/footer.tsx
@@ -162,6 +162,13 @@ export function Footer() {
 							<div className="mt-10 md:mt-0">
 								<h3 className="text-sm font-semibold uppercase leading-6 text-foreground">Resources</h3>
 								<ul className="mt-6 space-y-4">
+									<li>
+										<Link
+											href="/blog"
+											className="text-sm leading-6 text-muted-foreground transition-colors hover:text-foreground">
+											Blog
+										</Link>
+									</li>
 									<li>
 										<a
 											href={EXTERNAL_LINKS.EVALS}
diff --git a/apps/web-roo-code/src/components/chromes/nav-bar.tsx b/apps/web-roo-code/src/components/chromes/nav-bar.tsx
index e09836a45c1..8fed837a463 100644
--- a/apps/web-roo-code/src/components/chromes/nav-bar.tsx
+++ b/apps/web-roo-code/src/components/chromes/nav-bar.tsx
@@ -120,6 +120,15 @@ export function NavBar({ stars, downloads }: NavBarProps) {
 							</NavigationMenuTrigger>
 							<NavigationMenuContent>
 								<ul className="grid min-w-[260px] gap-1 p-2">
+									<li>
+										<NavigationMenuLink asChild>
+											<Link
+												href="/blog"
+												className="block select-none rounded-md px-3 py-2 text-sm leading-none no-underline outline-none transition-colors hover:bg-accent hover:text-accent-foreground focus:bg-accent focus:text-accent-foreground">
+												Blog
+											</Link>
+										</NavigationMenuLink>
+									</li>
 									<li>
 										<NavigationMenuLink asChild>
 											<Link
@@ -287,6 +296,12 @@ export function NavBar({ stars, downloads }: NavBarProps) {
 							<div className="px-5 pb-2 pt-4 text-sm font-semibold uppercase tracking-wider text-muted-foreground">
 								Resources
 							</div>
+							<Link
+								href="/blog"
+								className="block w-full p-5 py-3 text-left text-foreground active:opacity-50"
+								onClick={() => setIsMenuOpen(false)}>
+								Blog
+							</Link>
 							<ScrollButton
 								targetId="faq"
 								className="block w-full p-5 py-3 text-left text-foreground active:opacity-50"
diff --git a/apps/web-roo-code/src/components/providers/posthog-provider.tsx b/apps/web-roo-code/src/components/providers/posthog-provider.tsx
index 29e2fca9334..0237fc1665c 100644
--- a/apps/web-roo-code/src/components/providers/posthog-provider.tsx
+++ b/apps/web-roo-code/src/components/providers/posthog-provider.tsx
@@ -3,26 +3,43 @@
 import { usePathname, useSearchParams } from "next/navigation"
 import posthog from "posthog-js"
 import { PostHogProvider as OriginalPostHogProvider } from "posthog-js/react"
-import { useEffect, Suspense } from "react"
+import { useEffect, useRef, Suspense } from "react"
 import { hasConsent } from "@/lib/analytics/consent-manager"
 
 function PageViewTracker() {
 	const pathname = usePathname()
 	const searchParams = useSearchParams()
+	const previousUrl = useRef<string | null>(null)
 
-	// Track page views
+	// Track page views with proper referrer for SPA navigations
 	useEffect(() => {
 		if (pathname && process.env.NEXT_PUBLIC_POSTHOG_KEY) {
-			let url = window.location.origin + pathname
-			if (searchParams && searchParams.toString()) {
-				url = url + `?${searchParams.toString()}`
+			const searchString = searchParams?.toString() ?? ""
+			const currentUrl = window.location.origin + pathname + (searchString ? `?${searchString}` : "")
+
+			// Get referrer - for SPA navigations, use previous URL; otherwise use document.referrer
+			const referrer = previousUrl.current ?? document.referrer
+			let referringDomain = ""
+
+			if (referrer) {
+				try {
+					referringDomain = new URL(referrer).hostname
+				} catch {
+					// Invalid URL, leave empty
+				}
 			}
+
 			posthog.capture("$pageview", {
-				$current_url: url,
+				$current_url: currentUrl,
+				$referrer: referrer,
+				$referring_domain: referringDomain,
 			})
+
+			// Update previous URL for next navigation
+			previousUrl.current = currentUrl
 		}
 		// eslint-disable-next-line react-hooks/exhaustive-deps
-	}, [pathname, searchParams.toString()])
+	}, [pathname, searchParams?.toString()])
 
 	return null
 }
diff --git a/apps/web-roo-code/src/content/blog/a-4billion-parameter-model-now-beats-last-years-flagship.md b/apps/web-roo-code/src/content/blog/a-4billion-parameter-model-now-beats-last-years-flagship.md
new file mode 100644
index 00000000000..1e74f1f9059
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/a-4billion-parameter-model-now-beats-last-years-flagship.md
@@ -0,0 +1,112 @@
+---
+title: A 4-Billion Parameter Model Now Beats Last Year's Flagship
+slug: a-4billion-parameter-model-now-beats-last-years-flagship
+description: Google's Gemma 3N at 4 billion parameters outperforms Gemini 1.5 Pro on key benchmarks while running on a laptop. Learn what this means for your AI coding workflow.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - local-models
+    - AI-coding
+    - cost-optimization
+    - developer-workflow
+status: draft
+publish_date: "2026-01-12"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+4 billion parameters.
+
+Runs on a laptop.
+
+Outperforms Gemini 1.5 Pro on key benchmarks.
+
+## The API assumption
+
+Most engineering teams treat local models as a compromise. You run them when you need privacy or offline access, not when you need quality. The mental model: cloud-hosted frontier models are where the real capability lives. Local is for demos and edge cases.
+
+That assumption is breaking.
+
+Google's Gemma 3N model, at 4 billion parameters, now outperforms Gemini 1.5 Pro on key benchmarks. Not "approaches." Outperforms. And it runs on your laptop without sending a single REST request.
+
+> "Our Gemma 3N model is better than Gemini 1.5 Pro was even though it's 4 billion parameters in size and you can run it on your laptop as opposed to like needing a whole big slice of TPUs in order to run the model."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=1126)
+
+The practical implication: teams can now get flagship-quality outputs from local models, eliminating latency and API costs for many use cases.
+
+## What this means for your workflow
+
+The latency difference matters. A REST request to a cloud model involves network round trips, cold starts, and queue times. A local model responds in the time it takes to run inference on your hardware. For tasks that involve multiple iterations (debugging, refactoring, test generation), that latency compounds.
+
+The cost difference matters too. API calls accumulate. Local inference is a fixed cost: the hardware you already own.
+
+The gap between cloud-hosted frontier models and on-device models is closing faster than most roadmaps account for. The trajectory Paige describes points toward a future where the default is local, and cloud is the exception for tasks that genuinely require it.
+
+> "I think longer term we'll see super super tiny models be extremely good, extremely capable and like not even needing to send rest requests to get the kinds of responses that you would need."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=1144)
+
+## The tradeoff
+
+This is not "local models are now universally superior." The tradeoff is real.
+
+Context windows on local models are still constrained by memory. If your task requires 100k+ tokens of context, you still need cloud. If your task requires the absolute frontier (reasoning-heavy, multi-step planning across large codebases), cloud models may still win on quality.
+
+But for a large category of tasks (code completion, test generation, PR review on single files, local refactors), the quality delta between local and cloud is now smaller than the latency and cost delta.
+
+## Cloud vs local model comparison
+
+| Dimension      | Cloud-hosted models                           | Local models (2026)                             |
+| -------------- | --------------------------------------------- | ----------------------------------------------- |
+| Latency        | Network round trips, cold starts, queue times | Hardware inference time only                    |
+| Cost model     | Per-token API charges that accumulate         | Fixed cost (hardware you own)                   |
+| Context window | 100k+ tokens available                        | Constrained by local memory                     |
+| Privacy        | Data leaves your machine                      | Data stays local                                |
+| Best fit       | Multi-file reasoning, large context tasks     | Single-file edits, test generation, completions |
+
+## Why this matters for your team
+
+If you're an engineer on a team that ships 10+ PRs a week, you're making hundreds of model calls per day across the team. Each call that can move from cloud to local is a latency reduction and a cost reduction.
+
+The decision tree changes:
+
+- **High-context, multi-file reasoning:** Cloud.
+- **Single-file edits, test generation, quick completions:** Local is now competitive.
+
+If your current setup assumes "local = slow and dumb," that assumption is stale. The 4-billion parameter threshold is a signal: re-evaluate what you're sending over the wire.
+
+## How Roo Code lets you choose your model
+
+Roo Code operates on a BYOK (Bring Your Own Key) model, which means you control exactly which models power your coding workflow. You can point Roo Code at local models running on your hardware or cloud-hosted frontier models through your own API keys. The agent closes the loop regardless of where inference happens: it proposes diffs, runs commands and tests, and iterates based on results.
+
+**For teams evaluating local models:** Roo Code's model-agnostic architecture means you can test whether a 4-billion parameter local model meets your quality bar without changing your workflow. Run the same coding tasks against local and cloud models, compare the outputs, and make the call based on your actual use case.
+
+## The shift
+
+The question is not "when will local models be good enough?" They already are for many tasks.
+
+The question is: which of your workflows are still paying API costs for work that could run locally? Audit that. The math may have changed since you last checked.
+
+## Frequently asked questions
+
+### Can local models really match cloud model quality for coding tasks?
+
+For a specific category of tasks, yes. Single-file edits, test generation, code completion, and local refactors now show minimal quality delta between capable local models and cloud alternatives. The 4-billion parameter Gemma 3N benchmark results demonstrate this shift. Tasks requiring large context windows or complex multi-file reasoning still favor cloud models.
+
+### What hardware do I need to run a 4-billion parameter model locally?
+
+A modern laptop with 16GB of RAM can run 4-billion parameter models effectively. You do not need specialized GPU hardware for models at this scale. Inference speed depends on your specific hardware, but the latency is typically faster than network round trips to cloud APIs.
+
+### How do I decide which tasks to run locally vs in the cloud?
+
+Use context window requirements as your primary filter. If your task fits within local memory constraints, test it locally first. High-context tasks (100k+ tokens), multi-file reasoning across large codebases, and complex multi-step planning are better suited for cloud models. Single-file operations are strong candidates for local inference.
+
+### Does Roo Code support local models?
+
+Yes. Roo Code uses BYOK (Bring Your Own Key), so you can connect to local model servers running on your machine or cloud APIs. The agent workflow remains identical: Roo Code proposes changes, runs tests, and iterates on failures regardless of which model backend you configure.
+
+### How much can teams save by moving tasks to local models?
+
+Savings depend on your current API volume. Teams shipping daily at high velocity generate hundreds of model calls daily. Each call shifted from per-token API pricing to local inference eliminates that marginal cost. The fixed cost of hardware you already own replaces the variable cost of cloud API charges.
diff --git a/apps/web-roo-code/src/content/blog/a-fat-system-prompt-beats-fighting-a-generic-mode.md b/apps/web-roo-code/src/content/blog/a-fat-system-prompt-beats-fighting-a-generic-mode.md
new file mode 100644
index 00000000000..0e29c9794fe
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/a-fat-system-prompt-beats-fighting-a-generic-mode.md
@@ -0,0 +1,123 @@
+---
+title: A Fat System Prompt Beats Fighting a Generic Mode
+slug: a-fat-system-prompt-beats-fighting-a-generic-mode
+description: Why specialized AI coding modes with detailed system prompts outperform generic modes that require constant correction - and how to calculate the real token and time costs.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding
+    - prompt-engineering
+    - developer-productivity
+    - modes
+status: draft
+publish_date: "2025-07-23"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Three corrections in, you're still explaining.
+
+"No, not like that. Use recursive merge. Check the lock file first."
+
+Each correction burns tokens. Each correction bloats context. And the model still doesn't know what you meant.
+
+## The correction tax
+
+You open code mode to resolve a merge conflict. The model suggests a fix. It's wrong. You explain why. It tries again. Still wrong, but differently. You add another correction.
+
+Now your context includes: the original request, the first wrong attempt, your correction, the second wrong attempt, and your second correction. The model is working with all of that noise, trying to infer what you actually want.
+
+By the third loop, you've spent more tokens on back-and-forth than you would have spent on a detailed upfront prompt. And the model is now reasoning through a messy conversation history instead of clear instructions.
+
+This is the correction tax. Every time you fix a generic mode's assumptions, you pay it.
+
+## The alternative: instructions that already exist
+
+A specialized mode with a 1,000-line system prompt doesn't need your corrections. The instructions are already there.
+
+The tradeoff looks counterintuitive. That fat system prompt costs tokens upfront. But it changes the math: one-shot completions replace multi-turn loops.
+
+> "You can go and use the code mode to try and resolve some conflicts on a PR and you're going to be stuck in there for an hour. You know, with that mode, it, you know, the instructions are quite detailed, but it just one shots the conflicts."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=2862)
+
+The specialized mode doesn't guess your workflow. It already has the workflow encoded: which files to check first, how to handle lock files, when to abort and ask for human input.
+
+## Where the generic mode breaks
+
+Generic modes optimize for breadth. They handle many tasks adequately. But "adequately" means you become the gap-filler.
+
+Every domain-specific assumption you haven't taught it becomes a potential failure. And teaching it happens through corrections, one at a time, in conversation history that disappears when the task ends.
+
+> "If you're for example running code mode and you need to give instructions for example to solve a merge conflict and then it fails and then you need to say oh you need to do it like this, that adds up eventually to the point where it's just simpler to send detailed instructions rather than having to go back and forth getting it to do what you want for a more generic mode."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=2816)
+
+The correction loop isn't just inefficient. It's fragile. Next week, you'll have the same conversation again, because the model didn't learn from last time.
+
+## The real cost comparison
+
+Token cost is the obvious metric. But the hidden cost is time spent re-explaining.
+
+Generic mode on a merge conflict: 4-5 turns of correction, an hour of elapsed time, context bloated with failed attempts.
+
+Specialized mode on the same conflict: one prompt, one completion, done.
+
+The 1,000-line system prompt isn't overhead. It's amortized knowledge. You pay for it once in the mode definition. You recoup it on every task that would have needed correction.
+
+## Generic mode vs. specialized mode
+
+| Dimension              | Generic mode                         | Specialized mode                     |
+| ---------------------- | ------------------------------------ | ------------------------------------ |
+| First-attempt accuracy | Low - requires corrections           | High - workflow already encoded      |
+| Token usage per task   | High - corrections bloat context     | Lower - one-shot completions         |
+| Time to completion     | 4-5 turns, up to an hour             | Single turn, minutes                 |
+| Knowledge persistence  | None - corrections lost after task   | Permanent - encoded in system prompt |
+| Scaling cost           | Linear - same corrections every time | Amortized - pay once, reuse forever  |
+
+## Why this matters for your workflow
+
+If you're running the same type of task repeatedly, and each time requires teaching the model your preferences, you're paying the correction tax on loop.
+
+Specialized modes front-load the teaching. The system prompt encodes what you would have corrected, before the model makes the mistake.
+
+For engineers running 5-10 similar tasks per week, the compounding is real. Five corrections per task, five tasks per week, that's 25 correction turns replaced by zero. The token math favors the fat prompt. The time math favors it more.
+
+## How Roo Code eliminates the correction tax
+
+Roo Code's custom modes let you encode your domain knowledge once and reuse it indefinitely. Instead of correcting a generic AI assistant through multi-turn conversations that bloat context and burn tokens, you create a specialized mode with detailed instructions that closes the loop on the first attempt.
+
+With BYOK (bring your own key) pricing, you pay directly for tokens used - which means the efficiency gains from specialized modes translate directly to cost savings. A mode that one-shots merge conflicts instead of requiring five correction turns saves real money on every task.
+
+**The pattern is simple: if you've corrected the same behavior three times, write it into a mode and stop paying the correction tax.**
+
+## When to invest in a specialized mode
+
+If you've corrected the same behavior three times across different tasks, write it into a mode.
+
+The threshold is simple: if the correction is predictable, it should be in the system prompt. If it's not in the prompt, you'll keep paying for it.
+
+Build the mode once. Stop explaining twice.
+
+## Frequently asked questions
+
+### How many lines should a specialized system prompt be?
+
+There's no magic number, but effective specialized prompts often run 500-2,000 lines. The goal isn't brevity - it's completeness. Include every workflow step, edge case, and preference you'd otherwise correct in conversation. The upfront token cost is amortized across every task that skips the correction loop.
+
+### Won't a large system prompt cost more tokens than corrections?
+
+In isolation, yes - a 1,000-line prompt costs more than a single correction. But corrections compound. If a task typically requires 4-5 corrections, and you run that task 5 times per week, you're spending far more on repeated corrections than on a single detailed prompt. The math shifts in favor of specialized modes within the first week.
+
+### How do I know when a task needs a specialized mode vs. generic mode?
+
+Track your corrections. If you've explained the same preference or workflow three times across different tasks, that's a signal. Generic modes work well for one-off tasks or exploration. Specialized modes pay off for repeatable workflows where you already know what "right" looks like.
+
+### Can I create custom modes in Roo Code for my specific workflows?
+
+Yes. Roo Code supports custom modes with detailed system prompts tailored to your workflows. You define the instructions once - including file handling preferences, error recovery steps, and domain-specific knowledge - and the mode applies them to every task. This eliminates the correction loop and lets the agent close the loop on complex tasks in a single turn.
+
+### What types of tasks benefit most from specialized modes?
+
+Tasks with predictable workflows and domain-specific requirements benefit most: merge conflict resolution, code review with team conventions, test generation following specific patterns, and refactoring with architectural constraints. Any task where you'd otherwise spend time saying "no, do it this way instead" is a candidate for a specialized mode.
diff --git a/apps/web-roo-code/src/content/blog/a-mode-that-asks-questions-eliminates-prompt-engineering.md b/apps/web-roo-code/src/content/blog/a-mode-that-asks-questions-eliminates-prompt-engineering.md
new file mode 100644
index 00000000000..8b8dfe3c12f
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/a-mode-that-asks-questions-eliminates-prompt-engineering.md
@@ -0,0 +1,119 @@
+---
+title: A Mode That Asks Questions Eliminates Prompt Engineering
+slug: a-mode-that-asks-questions-eliminates-prompt-engineering
+description: Learn how building a custom mode that asks questions instead of waiting for perfect prompts eliminates prompt engineering and extracts the context your AI coding agent needs through conversation.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - custom-modes
+    - prompt-engineering
+    - workflow
+    - roo-code
+status: draft
+publish_date: "2025-07-23"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+You do not have to write the perfect prompt.
+
+You have to answer questions.
+
+## The prompt engineering trap
+
+You open VS Code. You need to implement a new feature. You stare at the chat input, trying to figure out how to describe what you want in enough detail that the model will not go off in some random direction.
+
+Where should the file go? What naming conventions does your codebase use? Are there existing patterns you want to follow? What edge cases matter?
+
+You know all of this. But translating it into a single, comprehensive prompt feels like writing a spec document before you can start coding.
+
+So you write something vague. The model makes assumptions. You correct it. It makes different assumptions. Three prompts later, you are debugging the prompt instead of the code.
+
+## The interrogation pattern
+
+There is another approach: build a mode that asks you questions instead of waiting for you to think of everything upfront.
+
+You say "I need to implement this feature." The mode asks where you want it. You answer. It asks how it should look. You answer. It asks what constraints apply. You answer.
+
+When you are done, the mode has all the context it needs. Not because you wrote a perfect prompt, but because the interrogation process surfaced requirements you did not think to specify.
+
+> "Something that asks you questions eliminates the need for prompt engineering completely, because the mode already has all the context it needs from you just by asking you questions."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=1365)
+
+This works because humans are better at answering questions than writing comprehensive specifications. You know what you want when someone asks you directly. You do not always know what details are relevant until someone prompts you for them.
+
+## How the mode works
+
+The pattern is straightforward. You create a custom mode in Roo Code that does not have access to code tools. It can only ask questions and, when it has enough context, delegate to another mode that can actually make changes.
+
+> "I had a mode that I called chat mode. Basically, it did sort of the same thing. It didn't have access to code tools at all, so it really needed to use the orchestrator tool, the new task tool, but the mode would ask me questions about anything."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=1249)
+
+The constraint is the feature. Because the mode cannot touch code, it has to gather information. It cannot skip ahead and make assumptions.
+
+## The tradeoff
+
+This adds a conversation step before any code gets written. If you already know exactly what you want and can articulate it precisely, the interrogation phase is overhead.
+
+But if you are implementing something new, something where the requirements are fuzzy or the codebase context matters, the upfront conversation pays for itself. You spend two minutes answering questions instead of twenty minutes correcting wrong assumptions.
+
+## Why this matters for your team
+
+For a five-person team shipping features across an unfamiliar codebase, the "lazy prompt" problem compounds. Each developer hits the same friction: they know what they want but struggle to express it in a way the model understands without context.
+
+A questioning mode inverts the burden. Instead of requiring everyone to become prompt engineers, you build a mode that extracts the relevant context through conversation. Junior developers get the same quality of context-aware suggestions as seniors who have internalized every folder structure and naming convention.
+
+> "A mode that gets information from you, because sometimes you're lazy or you don't know exactly what you want, a mode that can ask you relevant questions is really, really useful when you're trying to implement something new."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=1353)
+
+The shift is from "write a better prompt" to "answer questions until the mode knows enough." The second one scales across skill levels.
+
+## How Roo Code enables the interrogation pattern
+
+Roo Code's custom modes let you build specialized workflows that close the loop between gathering context and taking action. A questioning mode works by restricting tool access so the agent must ask before it acts, then delegating to Code mode or Architect mode once it has gathered sufficient context.
+
+This pattern leverages BYOK (bring your own key) to keep costs predictable while you iterate through the question-and-answer phase. Because Roo Code runs locally in VS Code and you control your API keys, the conversation overhead does not create hidden token markup or vendor lock-in.
+
+**The key insight: custom modes turn prompt engineering from a user skill into a system design choice.** Instead of training your team to write better prompts, you build modes that extract the information they already know through targeted questions.
+
+## Prompting approach comparison
+
+| Dimension            | Traditional prompting                        | Questioning mode                             |
+| -------------------- | -------------------------------------------- | -------------------------------------------- |
+| Who provides context | User writes comprehensive prompt upfront     | Mode asks targeted questions                 |
+| Skill dependency     | Requires prompt engineering expertise        | Requires only domain knowledge               |
+| Error correction     | Fix assumptions after code is generated      | Surface requirements before code is written  |
+| Context completeness | Often incomplete, leading to iteration loops | Systematically gathered through conversation |
+| Team scalability     | Quality varies by individual prompt skill    | Consistent quality across skill levels       |
+
+## Start here
+
+If your team keeps hitting the "wrong assumptions" loop, build a questioning mode. Remove the code tools. Force it to ask before it acts.
+
+The upfront conversation is not overhead. It is the prompt you did not know you needed.
+
+## Frequently asked questions
+
+### What is a questioning mode in Roo Code?
+
+A questioning mode is a custom mode configured without access to code editing tools. Because it cannot modify files directly, it must gather context by asking you questions before delegating the actual implementation to another mode like Code or Architect. This forces thorough context gathering before any changes are made.
+
+### How do I create a custom mode that only asks questions?
+
+In Roo Code, create a new custom mode and remove all file editing and command execution tools from its allowed tools list. Keep only the ability to read files and spawn new tasks. Add system instructions telling the mode to gather requirements through questions before delegating to a mode with implementation capabilities.
+
+### Does the questioning phase slow down development?
+
+For well-defined tasks where you can articulate requirements precisely, yes. But for new features, unfamiliar codebases, or fuzzy requirements, the two minutes spent answering questions prevents the twenty-minute correction loop that happens when the model makes wrong assumptions.
+
+### Can this pattern work with any AI coding tool?
+
+The pattern of asking before acting is universal, but executing it requires a tool that supports custom modes with restricted tool access and multi-mode delegation. Roo Code provides this through its custom modes system and the new task tool that allows one mode to hand off to another.
+
+### How does this help teams with mixed experience levels?
+
+Junior developers often struggle to write prompts that include all the context a senior developer would naturally include. A questioning mode levels the playing field by systematically extracting that context through conversation. The mode asks about folder structure, naming conventions, and patterns regardless of who is using it.
diff --git a/apps/web-roo-code/src/content/blog/a-readiness-checklist-predicts-ai-agent-success-before-you-start.md b/apps/web-roo-code/src/content/blog/a-readiness-checklist-predicts-ai-agent-success-before-you-start.md
new file mode 100644
index 00000000000..2ae9d020778
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/a-readiness-checklist-predicts-ai-agent-success-before-you-start.md
@@ -0,0 +1,125 @@
+---
+title: A Readiness Checklist Predicts AI Agent Success Before You Start
+slug: a-readiness-checklist-predicts-ai-agent-success-before-you-start
+description: Discover the five-point readiness checklist that predicts whether your AI coding agent will close the loop or leave you as the manual verification layer.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding-agents
+    - developer-productivity
+    - automation
+    - best-practices
+status: draft
+publish_date: "2025-10-08"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Can you build from the CLI?
+
+That single question predicts more about your AI agent results than which model you pick.
+
+## The assessment nobody runs
+
+You onboard a new AI coding tool. You point it at your repo. You ask it to fix a bug or write a feature. It produces code that looks plausible.
+
+Then it breaks.
+
+Not because the model is bad. Because the model has no way to verify its own work. It cannot run your build. It cannot execute your linter. It cannot tell whether it introduced a new warning or fixed an old one.
+
+You are now the verification layer. You paste errors back in. You re-run commands. You become the translation service between the agent and your actual development environment.
+
+The problem is not the agent. The problem is the project was never set up for an agent to succeed.
+
+## The checklist
+
+Teams that see immediate wins with AI coding agents share a pattern. Their projects pass a readiness assessment before the agent ever writes a line of code.
+
+> "We have a little bit of like a checklist that we assess projects against... can you build from the CLI, for example, or are you an IDE-only type of development shop... do you have linting, and can it be run by the agent from the CLI? If it's a compiled language, do you have a lot of warnings, so the agent won't be able to tell whether it added a warning or not?"
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o)
+
+The checklist is boring. That is why it works.
+
+**CLI buildability:** Can you run the build without opening an IDE? If the answer is no, the agent cannot verify that its changes compile.
+
+**Standalone linting:** Can linters run from the command line? If linting only works inside VS Code, the agent cannot check its own style violations.
+
+**Warning baseline:** In compiled languages, do you have a clean warning count? If there are 200 existing warnings, the agent cannot tell whether it added one.
+
+**Automated tests:** Do you have tests that run without manual setup? If the agent cannot execute tests, it cannot iterate based on failures.
+
+**PR review history:** Do your PRs carry review comments? This signals that the codebase has documented expectations the agent can learn from.
+
+## What the checklist predicts
+
+Teams with yeses across these questions get quick wins. The agent has the tools it needs to generate code, verify it, and iterate.
+
+> "If somebody's answering yes to most of those, we know that we're going to have really quick success because the agent's going to be really effective."
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=3278)
+
+Teams with noes still get value from AI, but the value is different. The wins are not "I asked for unit tests and got working unit tests." The wins are more like "I got a draft I could manually fix" or "I got ideas for how to approach this."
+
+> "If a lot of those are no, there's still going to be wins with AI, but the wins they're looking for are not, okay, I got unit tests, right?"
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=3302)
+
+The checklist does not judge your codebase. It tells you what kind of results to expect and where to invest if you want different results.
+
+## Why this matters for your team
+
+For a Series A - C team with five engineers, every hour spent debugging agent output is an hour not spent shipping features. If your project fails the readiness checklist, you already know where the friction will appear.
+
+The fix is not "get a smarter model." The fix is "make your build runnable from the CLI." One is a vendor decision. The other is infrastructure work that pays dividends whether you use AI or not.
+
+A team that invests a sprint in CLI buildability and standalone linting gets two returns: their AI agent starts closing the loop on its own work, and their CI pipeline becomes more reliable for human developers too.
+
+## How Roo Code closes the loop on ready projects
+
+Roo Code is an AI coding agent that closes the loop: it proposes diffs, runs commands and tests, and iterates based on results. When your project passes the readiness checklist, Roo Code can execute your build, run your linter, and verify its own changes without requiring you to paste errors back and forth.
+
+With BYOK (bring your own key), you connect directly to your preferred model provider and pay for tokens at cost. Roo Code does not mark up token prices or require a subscription to access agent capabilities.
+
+The readiness checklist is not about Roo Code specifically. It is about whether any agentic tool can operate autonomously in your environment. Projects that pass the checklist let Roo Code close the loop. Projects that fail the checklist turn any agent into a suggestion engine that requires manual verification.
+
+## Old approach vs. new approach
+
+| Dimension           | Manual verification workflow                                  | Closed-loop agent workflow                                      |
+| ------------------- | ------------------------------------------------------------- | --------------------------------------------------------------- |
+| Build verification  | Developer copies errors, pastes into chat, waits for response | Agent runs CLI build, sees errors, iterates automatically       |
+| Linting             | Developer runs linter in IDE, reports violations manually     | Agent runs linter from CLI, fixes violations in same session    |
+| Test execution      | Developer runs tests, interprets failures, asks for fixes     | Agent runs tests, reads failures, updates code until tests pass |
+| Warning detection   | Developer counts warnings before and after changes            | Agent compares warning output against clean baseline            |
+| Feedback cycle time | Minutes to hours per iteration                                | Seconds per iteration                                           |
+
+## The first step
+
+Before your next AI coding session, run the checklist.
+
+If you cannot build from the CLI, start there. If your linter only runs in the IDE, fix that next. Each "no" you flip to a "yes" removes a manual verification step from your workflow.
+
+The agent gets more effective. You stop being the translation layer. The loop closes without you in the middle.
+
+## Frequently asked questions
+
+### Why does CLI buildability matter more than model selection?
+
+A more capable model cannot compensate for an environment where it cannot verify its own work. If the agent cannot run your build, it cannot tell whether its changes compile. You become the verification layer regardless of how sophisticated the underlying model is. CLI buildability gives the agent the ability to check its own output.
+
+### What if my project fails most of the checklist items?
+
+You can still use AI coding tools, but expect different outcomes. Instead of autonomous iteration where the agent fixes its own mistakes, you get drafts that require manual verification. Many teams find value in this workflow for ideation and scaffolding. The checklist helps you calibrate expectations and identify where infrastructure investment would unlock more autonomous workflows.
+
+### How does Roo Code handle projects with many existing warnings?
+
+Roo Code runs your build and linter from the CLI, which means it sees the same warning output you do. If your project has 200 existing warnings, the agent cannot determine whether it added a new one. Establishing a clean warning baseline before using any agentic tool lets the agent detect when its changes introduce problems.
+
+### Can I use Roo Code if I only have IDE-based tooling?
+
+You can use Roo Code for code generation and suggestions, but the agent will not be able to close the loop by verifying its own changes. The value shifts from autonomous iteration to assisted drafting. Migrating your linting and build commands to CLI-runnable scripts unlocks the full agentic workflow where Roo Code proposes, verifies, and iterates without manual intervention.
+
+### How long does it take to make a project agent-ready?
+
+Most teams can address CLI buildability and standalone linting in a single sprint. The investment pays dividends beyond AI tooling: CLI-runnable builds improve CI reliability and make onboarding faster for human developers. Warning baseline cleanup varies by codebase, but even partial progress improves agent effectiveness.
diff --git a/apps/web-roo-code/src/content/blog/a-test-that-has-never-failed-proves-nothing.md b/apps/web-roo-code/src/content/blog/a-test-that-has-never-failed-proves-nothing.md
new file mode 100644
index 00000000000..6d9786f00e2
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/a-test-that-has-never-failed-proves-nothing.md
@@ -0,0 +1,125 @@
+---
+title: A Test That Has Never Failed Proves Nothing
+slug: a-test-that-has-never-failed-proves-nothing
+description: Why green tests can deceive you, how LLM-generated tests make this worse, and the simple heuristic to verify your tests actually catch regressions.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - testing
+    - software-quality
+    - ai-coding
+    - developer-workflow
+status: draft
+publish_date: "2025-04-30"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+All tests pass.
+
+Green checkmarks. Clean CI. Ship it.
+
+Then someone refactors the module, deletes half the implementation, and the tests still pass.
+
+## The symptom
+
+You wrote tests. They passed. You felt good. Months later, you change the code in a way that should break everything, and nothing breaks.
+
+The tests were never testing anything. They compiled. They ran. They asserted things. But they never actually verified the behavior you thought they were protecting.
+
+This happens more than anyone admits. A test file gets created, assertions get written, the suite goes green, and everyone moves on. No one ever saw that test fail. No one confirmed it could catch a real bug.
+
+## The heuristic
+
+The rule is simple: unless you have seen a test fail at least once, you cannot trust that the test is doing anything.
+
+> "Unless you've seen the test fail at least once, you can't trust that that test is actually doing anything."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=3455)
+
+This is not about test coverage percentages. Coverage tells you the code ran. It does not tell you the assertions would catch a regression. A test can execute every line and still assert nothing meaningful.
+
+The verification step is unglamorous: break the code on purpose. Comment out the line the test is supposed to protect. Change the return value to something wrong. If the test still passes, the test is decoration.
+
+## Where LLMs make this worse
+
+LLM-generated tests are particularly susceptible to this failure mode. The model produces a passing suite, reports success, and moves on. You never see the red. The tests look correct. They reference the right functions, use the right structure, and assert plausible values.
+
+But the model optimized for "tests pass," not "tests catch regressions."
+
+> "This can happen all the time with LLMs, they're going to tell you, 'Yes, this is working, whatever.'"
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=3468)
+
+The pattern is subtle. You ask the model to write tests for a function. It writes tests. They pass. You merge. Six weeks later, someone changes the function, and the tests still pass because they were never exercising the behavior that changed.
+
+The fix is the same: before trusting LLM-generated tests, break the code and confirm the test catches it. If you are using an agentic workflow, let the task run the tests against broken code as a verification step. The model should see the failure before you trust the success.
+
+## The deeper problem
+
+Tests that have never failed create false confidence. They contribute to coverage metrics, they show up in CI reports, and they make the codebase look more robust than it is.
+
+The worst version of this: a developer writes a bunch of tests, they pass, the developer is happy. Someone else comes in later, changes the implementation, deletes half the code, and the tests still pass.
+
+> "I've seen cases where a developer writes a bunch of tests and they pass and they're happy. And I've gone in later and I've basically changed all the code, deleted half of it and the tests still pass... It turned out the tests never failed. They never failed."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=3444)
+
+Those tests passed from day one. They passed every day since. They passed when the code worked. They passed when the code was deleted. They were never constraints.
+
+## Why this matters for your workflow
+
+If you review PRs that include tests, add this to your checklist: did anyone confirm the test can fail? If the PR adds a test but no one has seen it go red, the test is unverified.
+
+If you are using AI to generate tests, build failure verification into the workflow. Before accepting generated tests, mutate the code and run them. If they stay green, reject them.
+
+The investment is small: a few minutes of deliberate breakage per test file. The payoff is knowing which tests are constraints and which are decorations.
+
+## How Roo Code closes the loop on test verification
+
+Roo Code treats test failures as information, not roadblocks. When you ask Roo Code to write tests, it can run them immediately, see the results, and iterate based on actual output. This is what "close the loop" means in practice: the agent proposes code, executes tests, observes failures, and refines its approach.
+
+The critical workflow for verifying AI-generated tests: instruct Roo Code to run the tests against intentionally broken code. Because Roo Code can execute commands and observe results in context, you can build mutation testing directly into your task. The agent sees red, confirms the test catches the regression, then restores the code.
+
+**Roo Code makes test verification explicit by running tests against broken code before accepting them as valid constraints.**
+
+With BYOK (bring your own key), you control the model and the tokens. There is no black box. You see every step the agent takes, approve each action, and verify outcomes before merging.
+
+## Test verification approaches compared
+
+| Dimension            | Traditional workflow                               | Agentic workflow with Roo Code                       |
+| -------------------- | -------------------------------------------------- | ---------------------------------------------------- |
+| Test creation        | Manual or LLM-generated, assumed correct           | LLM-generated with immediate execution               |
+| Failure verification | Rarely done, requires discipline                   | Built into task: mutate code, run tests, observe red |
+| Feedback loop        | Delayed - failures discovered in CI or production  | Immediate - agent sees results in context            |
+| Coverage confidence  | Metrics only show execution, not assertion quality | Agent can verify assertions catch real regressions   |
+| Human oversight      | Review code, hope tests work                       | Review agent actions, approve intentional mutations  |
+
+## The first step
+
+Pick one test in your suite. Comment out the code it is supposed to protect. Run the test.
+
+If it passes, you have a test that proves nothing. Fix it or delete it.
+
+## Frequently asked questions
+
+### Why do tests that have never failed give false confidence?
+
+A test that has never failed only proves it can run without errors. It does not prove the assertions are meaningful or that the test would catch a regression. Coverage metrics count execution, not verification. Until you see a test fail when the protected code breaks, you cannot distinguish a real constraint from a decorative green checkmark.
+
+### How do I verify that LLM-generated tests actually work?
+
+Before accepting any AI-generated test, mutate the code it is supposed to protect. Comment out a critical line, change a return value, or delete the function body. Run the test. If it still passes, the test is not testing what you think. This takes minutes per test file and separates real tests from decoration.
+
+### Can Roo Code help me verify tests automatically?
+
+Yes. Because Roo Code closes the loop by executing commands and observing results, you can instruct it to run tests against intentionally broken code as part of the task. The agent sees the failure, confirms the test catches the regression, and only then considers the test valid. This builds mutation testing into your workflow without separate tooling.
+
+### What is mutation testing and why does it matter?
+
+Mutation testing introduces small changes (mutations) to your code and checks if your tests catch them. If a test passes when the code is mutated, that test is not verifying the behavior it claims to protect. It is the systematic version of "comment out the code and see if the test fails." Mutation testing reveals which tests are constraints and which are noise.
+
+### How often should I verify that tests can fail?
+
+At minimum, verify every new test before merging. For existing test suites, run periodic mutation testing or spot-check critical paths. If you cannot remember the last time you saw a particular test fail, that test is a candidate for verification. The goal is confidence that your tests are constraints, not just coverage statistics.
diff --git a/apps/web-roo-code/src/content/blog/advertised-context-windows-lie-when-you-build-context-incrementally.md b/apps/web-roo-code/src/content/blog/advertised-context-windows-lie-when-you-build-context-incrementally.md
new file mode 100644
index 00000000000..58d2bafb654
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/advertised-context-windows-lie-when-you-build-context-incrementally.md
@@ -0,0 +1,124 @@
+---
+title: Advertised Context Windows Lie When You Build Context Incrementally
+slug: advertised-context-windows-lie-when-you-build-context-incrementally
+description: Why 1 million token context windows degrade to 300-400K usable tokens in agentic workflows, and how to design tasks for the effective limit.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-windows
+    - agentic-workflows
+    - task-design
+    - llm-limitations
+status: draft
+publish_date: "2025-08-20"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+1 million tokens of context.
+
+That's what the spec sheet says. That's not what you get.
+
+## The difference between spec and reality
+
+You're debugging a failing integration test. The agent reads the test file. Then the implementation. Then the config. Then it runs the test, reads the output, proposes a fix, and you reject it. It reads more files. Runs the test again. Reasons about the delta.
+
+Each turn adds to the context. Files, command outputs, reasoning traces, your feedback. The context grows incrementally, turn by turn, as the agent does its job.
+
+And somewhere around 300,000 to 400,000 tokens, the wheels start to come off.
+
+Not dramatically. The model doesn't refuse to respond. It just starts losing the thread. References a file it read eight turns ago incorrectly. Suggests a fix you already tried. Forgets a constraint you stated clearly in the second message.
+
+> "I see 1 million context with Gemini as not 1 million context. If you dump it all in at the beginning no problem. But once you're slowly building that context, adding one file at a time, several files at a time, doing some thinking back and forth, that context goes to crap 3, 400,000."
+>
+> Guest, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=2000)
+
+The distinction matters: static context versus incrementally built context. If you paste your entire codebase into a single prompt and ask one question, the advertised limit holds. But agentic workflows don't work that way. The context accumulates through the conversation, interleaved with reasoning and tool outputs.
+
+## The "secret stat"
+
+Every model has a degradation curve. The spec sheet tells you the maximum. It does not tell you where quality starts to drop.
+
+> "It's a secret stat for the models... where the model starts to degrade heavily every turn."
+>
+> Hannes Rudolph, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=2047)
+
+This isn't published anywhere. You discover it empirically: the agent starts repeating itself, losing track of prior reasoning, or confidently stating things that contradict earlier context.
+
+The practical limit for incrementally built context appears to be 30% to 40% of the advertised maximum. For a model advertising 1 million tokens, plan for 300,000 to 400,000 usable tokens in a multi-turn agentic session.
+
+## What this means for task design
+
+Long-running tasks hit this wall. If your workflow involves reading a large codebase, running multiple commands, and iterating through several fix attempts, you will exceed the effective limit before you exceed the advertised one.
+
+The symptoms are subtle:
+
+- The agent suggests a fix you already rejected
+- It references file contents incorrectly
+- It loses track of requirements stated early in the conversation
+- Reasoning quality degrades even though the model still responds
+
+The fix isn't "use a bigger context window." The fix is task design: break large tasks into smaller ones, summarize and restart when context accumulates, and watch for the degradation signals.
+
+> "With Sonnet, I haven't tested to see does it hold on to reality as you go up one 100,000, 200,000, 300,000."
+>
+> Guest, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=2028)
+
+Different models degrade at different rates. Testing your specific workflow against your specific model is the only way to know where the effective limit lives.
+
+## Why this matters for your workflow
+
+For an engineer running agentic debugging sessions, this changes how you structure work. A task that reads 50 files and runs 10 command iterations will accumulate context differently than a quick "fix this lint error" task.
+
+If you're hitting the 200,000 token mark and the agent starts losing coherence, that's not a model bug. That's the effective limit revealing itself. The move is to checkpoint, summarize, and start a fresh task with the condensed context.
+
+## The planning rule
+
+Plan for the effective limit, not the spec sheet number.
+
+If your workflow regularly builds 500,000 tokens of incremental context, you're past the usable range for most models. Restructure the task, or build in explicit condensation points where you summarize progress and reset the context.
+
+The advertised context window is an upper bound. The effective context window is what you can actually use. Treat them as different numbers.
+
+## How Roo Code manages context accumulation
+
+Roo Code's architecture addresses context degradation through deliberate task boundaries. Because Roo Code closes the loop - reading files, running commands, and iterating on results within a single conversation - context accumulates rapidly. The solution is structured handoffs between tasks.
+
+With BYOK (bring your own key), you control which models power your workflows, letting you match model selection to task complexity. Short tasks can use faster models. Long debugging sessions benefit from models with better degradation curves.
+
+**The agentic workflow principle:** Break large tasks into focused subtasks before context degrades, then use condensed summaries to carry forward only what matters.
+
+Roo Code's mode system and task isolation let you checkpoint progress naturally. When you notice the agent losing coherence, start a new task with a summary of where you left off. The context resets; your progress doesn't.
+
+## Comparison: Static prompts vs. agentic context building
+
+| Dimension               | Static prompt (paste everything) | Incremental agentic context                           |
+| ----------------------- | -------------------------------- | ----------------------------------------------------- |
+| Context composition     | All information loaded upfront   | Files, outputs, and reasoning accumulate turn by turn |
+| Usable context          | Near advertised maximum          | 30-40% of advertised maximum                          |
+| Degradation pattern     | Rare if under limit              | Gradual loss of coherence over turns                  |
+| Recovery strategy       | N/A                              | Checkpoint, summarize, restart                        |
+| Task design requirement | Single well-formed query         | Explicit condensation points                          |
+
+## Frequently asked questions
+
+### Why does context quality degrade when building incrementally?
+
+Each turn adds not just new information but also reasoning traces, tool outputs, and conversational overhead. This interleaved content competes for attention with the core information you need the model to retain. The model's ability to maintain coherence across disparate chunks degrades faster than raw token counts would suggest.
+
+### How do I know when my context has degraded too far?
+
+Watch for these signals: the agent suggests fixes you already rejected, references file contents incorrectly, forgets constraints stated earlier, or provides confident answers that contradict prior context. These indicate the effective limit has been reached, even if token counts remain under the advertised maximum.
+
+### Does Roo Code help manage context limits automatically?
+
+Roo Code's task-based architecture provides natural checkpoints for context management. When you complete a subtask or notice degradation, you can start a fresh task with a condensed summary. Roo Code closes the loop within each task while letting you control when to reset context between tasks.
+
+### Should I choose models based on context window size?
+
+Context window size matters less than degradation behavior. A model with 200,000 tokens that maintains quality throughout may outperform a 1 million token model that degrades at 300,000. Test your specific workflows against candidate models to find where each model's effective limit lives.
+
+### What's the best strategy for long debugging sessions?
+
+Structure debugging as a series of focused tasks rather than one continuous conversation. After each major milestone - identifying the bug, implementing a fix, verifying the solution - summarize progress and start fresh. Carry forward only the condensed context needed for the next phase.
diff --git a/apps/web-roo-code/src/content/blog/agent-orchestrators-need-better-handoff-primitives.md b/apps/web-roo-code/src/content/blog/agent-orchestrators-need-better-handoff-primitives.md
new file mode 100644
index 00000000000..81b286627a1
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/agent-orchestrators-need-better-handoff-primitives.md
@@ -0,0 +1,119 @@
+---
+title: Agent Orchestrators Need Better Handoff Primitives
+slug: agent-orchestrators-need-better-handoff-primitives
+description: Why most agent orchestration systems fail at coordination and what primitives you need for parent-child communication, cost rollup, and persistent context.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agent-orchestration
+    - ai-agents
+    - developer-tools
+    - agentic-workflows
+status: draft
+publish_date: "2025-05-14"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Rule: If the parent cannot check in on the child, it is not an orchestrator. It is a launcher.
+
+Most agent orchestration systems have two primitives: "start task" and "end task." The parent spins up a subtask, waits for completion, aggregates the result. Done.
+
+The gaps show up the moment something goes wrong.
+
+## Where the primitives break
+
+You have an orchestrator managing three subtasks. Subtask two stalls. The parent cannot check in. It cannot ask "what are you stuck on?" It cannot give feedback mid-flight. It waits.
+
+Meanwhile, you restart the system. Context is gone. The parent does not remember what it delegated. The subtasks do not remember who spawned them. You are back to manual coordination.
+
+Costs do not accumulate visibly. You cannot see that subtask one burned through your token budget while subtask three sat idle. There is no ledger, no rollup, no "here is what the tree spent."
+
+Navigation is one-way. You can jump from parent to child, but not back. You cannot move laterally between siblings. The orchestration graph is a one-time traversal, not a workspace you can explore.
+
+These are not edge cases. These are the first things you notice when you try to build a system where agents manage other agents.
+
+## The shift in thinking
+
+The insight from teams building orchestration: treat communication between agents as a first-class design problem, not an afterthought.
+
+> "I think in some ways we found it to be such a powerful change: the idea that the agents can be orchestrators and managers of other agents."
+>
+> Matt, [Office Hours S01E06](https://www.youtube.com/watch?v=zPhNXCHJ5xk&t=1435)
+
+The power is real. But the power requires infrastructure.
+
+What does that infrastructure look like? Start with the primitives that are missing:
+
+**Persistent context across restarts.** Parent and subtask relationships should survive a crash. When you come back, the orchestrator should know what it delegated and what came back.
+
+**Mid-flight feedback.** The parent should be able to check in on a running subtask. Not just "is it done?" but "what are you seeing?" and "here is additional context."
+
+> "It would also be interesting if they could give feedback on some of the things. They could check in while the task is running."
+>
+> Matt, [Office Hours S01E06](https://www.youtube.com/watch?v=zPhNXCHJ5xk&t=1489)
+
+**Cost rollup.** Token spend and runtime should accumulate visibly at the parent level. You should be able to see "this orchestration tree cost X" without summing logs manually.
+
+**Bidirectional navigation.** You should be able to move from parent to child, child to parent, and sibling to sibling. The task graph is a workspace, not a one-way path.
+
+**Self-description for routing.** Subtasks should be able to introduce themselves. The orchestrator should know what each agent is good at before delegating.
+
+> "Spoiler alert: we added a new field to the modes that's optional to have them kind of introduce themselves a little bit and make it easier for the orchestrator to know when to use them."
+>
+> Matt, [Office Hours S01E06](https://www.youtube.com/watch?v=zPhNXCHJ5xk&t=1540)
+
+## The tradeoff
+
+Adding these primitives adds complexity. Every handoff primitive is a protocol to maintain. Persistent context means storage and sync logic. Mid-flight feedback means interrupts and state management.
+
+The question is whether the complexity is in your infrastructure or in your head. Without explicit primitives, you end up rebuilding coordination logic in prompts. You become the message bus.
+
+## Orchestration primitives: launcher vs. coordinator
+
+| Dimension                 | Launcher (basic)          | Coordinator (full primitives)            |
+| ------------------------- | ------------------------- | ---------------------------------------- |
+| Parent-child relationship | Fire and forget           | Persistent across restarts               |
+| Mid-task feedback         | None                      | Parent can check in, provide context     |
+| Cost visibility           | Per-task only             | Rolled up to orchestration tree          |
+| Navigation                | One-way (parent to child) | Bidirectional (parent, child, sibling)   |
+| Agent routing             | Hardcoded or prompt-based | Self-describing agents with capabilities |
+
+## How Roo Code closes the loop on orchestration
+
+Roo Code implements orchestration as a first-class workflow through its Orchestrator mode. When you spawn subtasks, Roo Code maintains bidirectional navigation between parent and child tasks, preserving context across the session. The BYOK model means token costs roll up visibly since you pay your provider directly and can track spend across your orchestration tree without hidden markup.
+
+Roo Code's mode system supports self-describing agents: each mode can introduce its capabilities to help the orchestrator route tasks appropriately. This is not a launcher that fires and forgets. It is a coordinator where the parent can check in, provide feedback, and iterate based on results.
+
+## Why this matters for your codebase
+
+If you are building agent orchestration, audit your handoff layer.
+
+Can the parent check in on a running child? Can the child report back before completion? Do costs roll up? Does context persist?
+
+If the answer is "no," you are building a launcher, not an orchestrator. The difference shows up the first time a subtask stalls and you realize you have no way to ask it what went wrong.
+
+Treat agent-to-agent communication as a first-class design problem. The primitives you build now determine whether your orchestration scales or whether you stay in the loop as the human coordinator.
+
+## Frequently asked questions
+
+### What is the difference between an agent launcher and an agent orchestrator?
+
+A launcher starts subtasks and waits for completion with no ability to intervene. An orchestrator maintains ongoing relationships with subtasks: it can check in mid-flight, provide feedback, track costs across the tree, and navigate bidirectionally between parent and child agents.
+
+### Why does context persistence matter for agent orchestration?
+
+When an orchestration system restarts, you lose the parent-child relationships and delegation history. Without persistent context, you cannot resume work or understand what was delegated to whom. You end up re-coordinating manually, which defeats the purpose of orchestration.
+
+### How does Roo Code handle agent-to-agent communication?
+
+Roo Code's Orchestrator mode treats subtask management as a first-class workflow. Parent tasks can spawn child tasks, maintain context across the conversation, and navigate between related tasks. The mode system allows agents to self-describe their capabilities, helping the orchestrator route work appropriately.
+
+### What should I look for when evaluating orchestration frameworks?
+
+Audit five primitives: persistent context across restarts, mid-flight feedback from parent to child, cost rollup at the orchestration tree level, bidirectional navigation between tasks, and self-description capabilities for routing. If these are missing, you have a launcher, not an orchestrator.
+
+### How do token costs work in multi-agent orchestration?
+
+Each subtask consumes tokens independently. Without cost rollup, you cannot see what an orchestration tree spent in total. With BYOK (bring your own key) systems like Roo Code, costs are transparent since you pay your provider directly and can track aggregate spend across all orchestrated tasks.
diff --git a/apps/web-roo-code/src/content/blog/ai-best-practices-spread-through-internal-influencers-not-topdown-mandates.md b/apps/web-roo-code/src/content/blog/ai-best-practices-spread-through-internal-influencers-not-topdown-mandates.md
new file mode 100644
index 00000000000..8a23f59538b
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/ai-best-practices-spread-through-internal-influencers-not-topdown-mandates.md
@@ -0,0 +1,116 @@
+---
+title: AI Best Practices Spread Through Internal Influencers, Not Top-Down Mandates
+slug: ai-best-practices-spread-through-internal-influencers-not-topdown-mandates
+description: Why centralized AI documentation fails and how engineering orgs drive adoption through trusted internal influencers and recurring demo forums.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-adoption
+    - engineering-culture
+    - developer-productivity
+    - change-management
+status: published
+featured: true
+publish_date: "2025-04-30"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+"When that person speaks, everyone listens."
+
+That's how adoption actually works. Not through wikis. Not through mandates. Through the developer everyone already watches.
+
+## The documentation problem
+
+You're rolling out AI coding tools to a large engineering org. The instinct is to centralize: write a best practices guide, create a wiki, schedule a training session.
+
+Three weeks later, the wiki is stale. The domain moved. The models changed. The prompts that worked in September don't work in October.
+
+Centralized guidance for AI tools fails for a structural reason: the field changes too fast for documentation to keep up. By the time you've written the guide, reviewed it, and published it, the landscape has shifted.
+
+## The organic model
+
+What works instead is something Netflix discovered through practice, not theory.
+
+> "I think that's probably the model that has happened organically at Netflix is look at the people who are the most effective and try to do what they're doing."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=1628)
+
+The insight: every engineering org already has internal influencers. Developers that others watch and emulate. When one of these engineers shares a prompt or recommends a tool, people try it. Not because of a mandate. Because trust already exists.
+
+> "A term that I like to use is almost like influencers. Developers that other people see, wow, this is a 10x developer or look how productive she is. And when that person speaks everyone listens and when they say try this as your prompt or I found this tool to be amazing, people around them try to emulate them."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=1584)
+
+This isn't about creating evangelists from scratch. It's about identifying who already has influence and giving them time and space to experiment.
+
+## The infrastructure that makes it work
+
+Identifying influencers is step one. Step two is creating forums where they can share what they learn.
+
+> "We have monthly get-togethers at the company where people can demo what they've built, shared lessons learned and that usually has like a two to three hundred engineer audience every month and that's been super valuable for sharing what's new."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=2465)
+
+The format matters. A demo with a live audience is different from a doc in a wiki. Demos show what actually works. They invite questions. They create social proof in real time.
+
+The cadence matters too. Monthly keeps pace with how fast AI tools evolve. Quarterly is too slow; the landscape shifts between demos.
+
+## The constraint: this requires investment
+
+The tradeoff is real. Internal influencers need time to experiment. They need permission to try tools that might not work. They need a stage to share what they learn.
+
+For an engineering leader, this means protecting experimentation time for your high-signal developers. It means scheduling recurring demo forums and treating them as infrastructure, not optional.
+
+The alternative - a centralized wiki that goes stale - costs less upfront but delivers less adoption.
+
+## Why this matters for your org
+
+For a 50-person engineering team evaluating AI coding tools, the adoption pattern predicts success or failure. Top-down mandates create compliance without enthusiasm. Organic spread through trusted developers creates actual behavior change.
+
+The compounding effect: when an internal influencer shares a workflow that saves 30 minutes per PR, and 10 engineers adopt it, that's 5 hours per day across the team. When they share a prompt pattern that reduces debugging loops, the multiplier grows.
+
+The first step is naming your influencers. Who do engineers already watch? Who gets asked "how did you do that?" in Slack? Start there.
+
+Create the forum. Protect the experimentation time. Let adoption spread through trust instead of mandates.
+
+## How Roo Code supports organic adoption patterns
+
+Internal influencers need tools that produce repeatable, reviewable outcomes - not just clever prompts. Roo Code helps by turning intent into inspectable artifacts (diffs, test output, and a clear trail of what happened) that are easy to demo and share.
+
+Influencers can share what actually worked: the workflow, the artifacts, and the failure modes. That's what spreads.
+
+**Roo Code accelerates organic adoption because internal influencers can demonstrate real, reproducible workflows - not theoretical best practices - in their monthly demo forums.**
+
+## AI adoption approaches compared
+
+| Dimension            | Centralized documentation     | Influencer-driven adoption            |
+| -------------------- | ----------------------------- | ------------------------------------- |
+| Update velocity      | Weeks to months               | Real-time as tools evolve             |
+| Trust source         | Institutional authority       | Peer credibility                      |
+| Learning format      | Static text and video         | Live demos with Q&A                   |
+| Experimentation cost | Hidden in stale content       | Visible investment in influencer time |
+| Adoption depth       | Compliance without enthusiasm | Behavior change through emulation     |
+
+## Frequently asked questions
+
+### How do I identify internal influencers in my engineering org?
+
+Look for developers who get asked "how did you do that?" in Slack or code reviews. They're often not the loudest voices but the ones whose PRs others study. Check who gets tagged when people are stuck on tooling questions. These signals reveal existing trust networks you can leverage.
+
+### What's the right cadence for AI tool demo forums?
+
+Monthly works best for most organizations. AI tools evolve quickly enough that quarterly sessions become stale, but weekly creates participation fatigue. Monthly gives influencers time to experiment deeply while keeping the organization current with rapidly changing capabilities.
+
+### How much experimentation time should influencers get?
+
+Start with 10-20% of their time dedicated to exploring new AI workflows. This is enough to build genuine expertise without disrupting delivery commitments. The investment pays back when their discoveries multiply across the team.
+
+### How does Roo Code help internal influencers share what they learn?
+
+Roo Code makes workflows easier to demonstrate because the artifacts are explicit: diffs, test output, and a clear trail of what was tried. That makes it easier to share what worked (and what didn't) without hand-wavy advice.
+
+### Why do centralized AI wikis fail?
+
+They fail because the field changes faster than documentation cycles. A prompt technique documented in October may be obsolete by November due to model updates, new features, or discovered failure modes. Live demos from trusted peers adapt in real time; static docs cannot.
diff --git a/apps/web-roo-code/src/content/blog/ai-might-kill-your-dependency-tree.md b/apps/web-roo-code/src/content/blog/ai-might-kill-your-dependency-tree.md
new file mode 100644
index 00000000000..ae242d6ca31
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/ai-might-kill-your-dependency-tree.md
@@ -0,0 +1,126 @@
+---
+title: AI Might Kill Your Dependency Tree
+slug: ai-might-kill-your-dependency-tree
+description: Why AI coding agents are shifting the economics of package dependencies - and how owning focused implementations beats managing fork maintenance and vulnerability churn.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - dependencies
+    - security
+    - ai-coding
+    - developer-productivity
+status: draft
+publish_date: "2025-09-17"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+$ npm audit
+47 vulnerabilities (12 moderate, 28 high, 7 critical)
+
+That report lands in Slack every Monday. You triaged the critical ones last quarter. This quarter, you're still triaging the same packages with new CVEs.
+
+## The fork trap
+
+You've been here before. A package has a bug. You open the GitHub issue. It's been open for eight months. The maintainer is busy, or gone, or merged something that broke your use case.
+
+So you fork it. You patch the bug. You point your package.json at your fork.
+
+Now you're the maintainer.
+
+Every time the upstream pushes a release, you have to pull it, resolve the conflicts, and re-test. You didn't sign up for this. You just needed one function to work correctly.
+
+> "How many of you have forked packages to make a change because there's a bug in it? I've done that countless times in my career. And now I'm managing that thing, trying to keep it up to date."
+>
+> Matt, [Roo Cast S01E09](https://www.youtube.com/watch?v=Vo5grOXbjIY&t=591)
+
+The fork isn't the fix. The fork is the beginning of a maintenance relationship you didn't ask for.
+
+## The alternative: just write it
+
+Here's the counterintuitive move: instead of importing a package that does A through Z when you only need X, copy the logic you need into your codebase. Let AI write the integration.
+
+This sounds like heresy if you grew up in the npm ecosystem. "Don't reinvent the wheel" is gospel. But the wheel you're importing comes with:
+
+- A dependency tree you didn't audit
+- Update churn you didn't budget for
+- Attack surface you can't easily shrink
+
+When an AI agent can read the package source, understand what you actually need, and write a focused implementation that lives in your repo, the calculus changes.
+
+You own the code. You understand the code. You don't wake up to a vulnerability report about a transitive dependency four levels deep.
+
+> "I think we're going to see a going back to where things are simpler, less dependencies, and we just use AI to write the services that we need rather than bringing in all these packages. It's probably going to take a decade for that to happen. But I honestly think it's going to result in better software long term."
+>
+> Matt, [Roo Cast S01E09](https://www.youtube.com/watch?v=Vo5grOXbjIY&t=567)
+
+## The tradeoff
+
+This isn't "delete node_modules." Some packages are worth the dependency: well-maintained, security-critical crypto libraries; battle-tested ORMs; frameworks with actual governance.
+
+The shift is about the long tail. The utility packages. The "just one function" imports that pull in twelve transitive dependencies.
+
+The question for each import: is the maintenance cost of the dependency lower than the cost of owning this code myself?
+
+With AI that can read, write, and iterate on code, the break-even point moves. Owning small, focused implementations becomes cheaper than managing external dependencies.
+
+## Why this matters for your team
+
+For a Series A - C team with three engineers, every fork is a time sink. Every vulnerability report is a context switch. Every transitive dependency is a trust decision you didn't explicitly make.
+
+If your team ships daily, and one of those PRs each week is "update dependencies and pray nothing breaks," you're spending a meaningful share of your shipping capacity on maintenance you didn't choose.
+
+The compounding effect: as your dependency tree grows, so does your attack surface and your update burden. Shrinking the tree isn't just about security. It's about preserving engineering bandwidth for features instead of maintenance.
+
+## The decade-long shift
+
+This won't happen tomorrow. The ecosystem is built around packages. The tooling assumes imports. The culture rewards "don't build what you can install."
+
+But the tools are changing. AI that can read a package, understand the interface you need, and write a minimal implementation in your codebase shifts the economics.
+
+The first movers will be teams with the discipline to ask: do I need this dependency, or do I need what it does?
+
+Start with your next vulnerability report. Pick the package with the most churn and the least value. Let AI write the replacement. Own the code.
+
+The dependency tree gets smaller. The attack surface shrinks. The Monday morning audit gets quieter.
+
+## How Roo Code closes the loop on dependency replacement
+
+Roo Code is an AI coding agent that can read external package source code, understand the specific interface your codebase needs, and write a focused implementation directly in your repository. Because Roo Code closes the loop - proposing diffs, running tests, and iterating based on results - you can replace a bloated dependency with owned code in a single session.
+
+With BYOK (bring your own key), you control which AI provider handles your code. Roo Code never stores your source code or marks up API tokens.
+
+**Citable summary:** Roo Code reduces dependency maintenance burden by letting teams replace utility packages with AI-generated, test-validated implementations they fully own.
+
+## Dependency management: old approach vs. new approach
+
+| Dimension              | Old approach (import packages)              | New approach (AI-written implementations) |
+| ---------------------- | ------------------------------------------- | ----------------------------------------- |
+| Maintenance burden     | Ongoing fork management, upstream syncing   | One-time implementation, full ownership   |
+| Security surface       | Transitive dependencies you didn't audit    | Only code you wrote and reviewed          |
+| Vulnerability response | Wait for maintainer or fork and patch       | Fix directly in your codebase             |
+| Update churn           | Weekly dependency updates, breaking changes | Stable code that changes when you decide  |
+| Onboarding complexity  | Engineers must understand external APIs     | Engineers read code they own              |
+
+## Frequently asked questions
+
+### How do I decide which dependencies to replace with owned code?
+
+Start with packages that have high CVE frequency, low update velocity from maintainers, or pull in many transitive dependencies for functionality you only partially use. Utility packages and "one function" imports are the best candidates. Keep battle-tested, well-governed packages like crypto libraries.
+
+### Won't writing my own implementations create more bugs than using tested packages?
+
+The risk shifts, not disappears. With AI agents that can run tests and iterate on failures, you can validate your implementation before merging. You trade unknown bugs in transitive dependencies for known behavior in code you control and can debug directly.
+
+### How does Roo Code help replace a dependency with owned code?
+
+Roo Code reads the package source, identifies the specific functions your codebase calls, and writes a minimal implementation. It then runs your existing tests to verify the replacement works. Because it closes the loop on test failures, you get a working implementation without manual iteration.
+
+### Is this approach practical for teams shipping production software?
+
+Yes, particularly for small teams where dependency maintenance consumes significant engineering bandwidth. A team spending 10-20% of capacity on vulnerability triage and update churn can redirect that time to feature development by shrinking their dependency tree strategically.
+
+### What about packages with complex functionality like ORMs or UI frameworks?
+
+Keep them. This approach targets the long tail of utility packages, not foundational frameworks. The question is always: does the maintenance cost of this specific dependency exceed the cost of owning equivalent functionality? For complex, well-maintained packages, the answer is usually no.
diff --git a/apps/web-roo-code/src/content/blog/ai-refactoring-fails-when-you-skip-the-surgical-approach.md b/apps/web-roo-code/src/content/blog/ai-refactoring-fails-when-you-skip-the-surgical-approach.md
new file mode 100644
index 00000000000..d904ee4404f
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/ai-refactoring-fails-when-you-skip-the-surgical-approach.md
@@ -0,0 +1,123 @@
+---
+title: AI Refactoring Fails When You Skip the Surgical Approach
+slug: ai-refactoring-fails-when-you-skip-the-surgical-approach
+description: Learn why comprehensive AI refactors fail and how the surgical pattern of single verified changes delivers reliable codebase improvements without breaking production.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - refactoring
+    - workflows
+    - best-practices
+    - ai-coding
+status: draft
+publish_date: "2025-06-18"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Greenfield is easy. Refactoring breaks everything.
+
+The model controls all constraints when it builds from scratch. Refactoring means respecting constraints the model did not create.
+
+## The trap
+
+You have a working codebase. It's messy, but it works. You ask the AI to clean it up: "Refactor this component to use the new state management pattern."
+
+The model returns a diff that touches forty files. Half of them reference functions that don't exist yet. The UI renders, but three buttons no longer do anything. You spend two hours hunting down what broke.
+
+You try again with a more specific prompt. Same result: a confident, comprehensive refactor that breaks functionality in ways that take longer to debug than the original task.
+
+The issue is not the model's capability. The issue is the scope.
+
+## Why refactoring is different
+
+> "Making a project from scratch is quite easy for a model. But refactoring what's already there, especially without breaking stuff, it's a pretty hard task for sure."
+>
+> Dan, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=3333)
+
+When a model builds from scratch, it owns the entire dependency graph. Every function exists because the model created it. Every interface matches because the model designed both sides.
+
+Refactoring existing code inverts this. The model inherits constraints: naming conventions it did not choose, edge cases it did not anticipate, integrations with systems it cannot see. One confident change cascades into three broken assumptions.
+
+The orchestrator does not solve this. Even with task delegation, a refactor that spans multiple files and abstractions will fail at some point because refactoring is hard. The complexity is not in the execution. It is in the constraints.
+
+## The surgical pattern
+
+The pattern that works: one change, tested, then repeat.
+
+> "For something especially critical, you just want to do it piecemeal. So have AI build a plan of the most impactful single change it can make."
+>
+> Adam, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=3269)
+
+Instead of "refactor the whole component," you ask: "What is the single most impactful change we could make right now?" The model proposes one change. You implement it. You run the tests. You verify the UI still works.
+
+Then you repeat.
+
+This feels slower. It is slower, per individual change. But the total time is lower because you are not debugging a 40-file diff where the breakage could be anywhere.
+
+## The tradeoff
+
+This approach requires discipline. You have to resist the temptation to merge a "comprehensive refactor" that looks clean in the diff but has not been tested incrementally.
+
+The tradeoff: more commits, more test runs, more context switches between "ask for plan" and "implement one piece." But each commit is verified. Each step is reversible. The debugging surface stays small.
+
+For critical paths, this is the only pattern that survives contact with production.
+
+## Why this matters for your team
+
+For a five-person team shipping production code, the compounding cost of a failed refactor is severe. One confident 40-file change that breaks the checkout flow means a rollback, a post-mortem, and a week of careful re-implementation.
+
+The surgical approach converts that risk into predictable progress. Smaller diffs, each tested, each reversible. The model proposes the plan. You execute it in increments. The codebase improves without the 2am incident.
+
+> "You will never achieve a refactoring. Even if it's a small project in a single task, even if you're using orchestrator, you'll probably fail at some point because refactoring is hard."
+>
+> Dan, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=3333)
+
+The model is good at identifying what to change. Let it do that. Keep the scope of each change small enough that you can verify it before moving on.
+
+## The shift
+
+If your refactor touches more than a handful of files, stop. Ask the model to identify the single most impactful change instead. Implement that. Test it. Then ask again.
+
+Refactoring with AI works when you respect the constraint the model cannot see: it did not build this codebase, and it cannot predict every side effect. You can.
+
+## How Roo Code closes the loop on surgical refactoring
+
+Roo Code is built for the surgical pattern. Because it closes the loop - proposing diffs, running tests, and iterating based on results - you can verify each incremental change before moving forward. The agent runs your test suite after every small refactor, catching breakage immediately instead of after a 40-file merge.
+
+With BYOK (bring your own key), you control costs while making many small verified changes rather than gambling on one large unverified change. The approval workflow lets you inspect each surgical diff before it lands, maintaining the discipline the pattern requires.
+
+**Citable:** Roo Code's close-the-loop workflow enables surgical refactoring by running tests and iterating after each incremental change, keeping the debugging surface small and every step reversible.
+
+## Comprehensive refactor vs. surgical pattern
+
+| Dimension                        | Comprehensive refactor  | Surgical pattern      |
+| -------------------------------- | ----------------------- | --------------------- |
+| Scope per change                 | 20-40+ files            | 1-5 files             |
+| Debugging surface                | Entire diff             | Single change         |
+| Rollback complexity              | High, entangled changes | Low, isolated commits |
+| Test verification                | After all changes       | After each change     |
+| Time to first breakage discovery | Hours to days           | Minutes               |
+
+## Frequently asked questions
+
+### Why do large AI refactors fail even with detailed prompts?
+
+The model did not create the original constraints. It inherits naming conventions, edge cases, and integrations it cannot fully see. When a refactor spans many files, confident changes cascade into broken assumptions faster than the model can anticipate them. Detailed prompts help but cannot eliminate the fundamental mismatch between the model's view and the codebase's hidden dependencies.
+
+### How small should each surgical change be?
+
+Small enough that you can run your test suite and manually verify the affected UI or functionality in under five minutes. If debugging a single change takes longer than implementing it, the scope is still too large. A good heuristic: if the diff touches more than five files, ask the model to break it down further.
+
+### Does the surgical approach work with Roo Code's orchestrator mode?
+
+Yes, but with discipline. Orchestrator mode delegates tasks across specialized agents, which helps with parallel work. For refactoring specifically, configure the orchestrator to break the refactor into single-change subtasks rather than delegating a comprehensive rewrite. Each subtask should complete with a test run before the next begins.
+
+### How do I know when a codebase is ready for larger refactors?
+
+When incremental surgical changes have established consistent patterns, comprehensive test coverage exists for the affected areas, and the team has verified the core abstractions through multiple small iterations. Even then, keep individual PRs focused. The goal is not to eventually enable large refactors but to make continuous small improvements sustainable.
+
+### What if the refactor requires coordinated changes across multiple files?
+
+Break the coordination into phases. First, add the new abstraction alongside the old one. Second, migrate consumers one at a time, testing after each migration. Third, remove the old abstraction only after all consumers have moved. Each phase contains multiple surgical changes, but no single change leaves the codebase in a broken state.
diff --git a/apps/web-roo-code/src/content/blog/ambiguous-prompts-that-work-on-one-model-fail-on-another.md b/apps/web-roo-code/src/content/blog/ambiguous-prompts-that-work-on-one-model-fail-on-another.md
new file mode 100644
index 00000000000..67766a385e2
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/ambiguous-prompts-that-work-on-one-model-fail-on-another.md
@@ -0,0 +1,123 @@
+---
+title: Ambiguous Prompts That Work on One Model Fail on Another
+slug: ambiguous-prompts-that-work-on-one-model-fail-on-another
+description: Why prompts that achieve 90% success on one LLM can crater to 50% on another - and how explicit prompt writing unlocks model-agnostic reliability
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - prompt-engineering
+    - model-switching
+    - ai-workflows
+    - reliability
+status: draft
+publish_date: "2025-09-25"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+90% success. Then 50%.
+
+Same prompts. Different model.
+
+The prompts were the problem the whole time.
+
+## The switch that broke everything
+
+You've been shipping with Opus for months. The workflow feels smooth. You write prompts that are "good enough," and the model fills in the gaps. It reads between the lines. It gets what you mean.
+
+Then you switch to GPT5. Same prompts. Same repo. Same task.
+
+Suddenly half your tasks go sideways. The model isn't broken. It just isn't guessing the same way Opus did.
+
+The Roo Code team hit this exact wall. They switched to GPT5 and watched their success rate crater.
+
+> "We switched to GPT5 and we're like, 'Well, this isn't that good. It's like 50/50 or like 40/60 or 60/40.' Not nearly as good. And then when we dig into it deeper, we discover that the issue was that we had ambiguous wording. We were asking the model to read between the lines without realizing it."
+>
+> Hannes Rudolph, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=3404)
+
+The problem was not that GPT5 was less capable. The problem was that prompts contained implicit instructions that Opus inferred but GPT5 did not.
+
+## The fix: remove the ambiguity
+
+The team rewrote their prompts. They removed extra language. They stated intent explicitly instead of hoping the model would figure it out.
+
+The result: GPT5 hit 99% success. Not 90%. Not 95%. Ninety-nine percent. Higher than Opus ever achieved with the original prompts.
+
+> "When you cleared that language up, often removing some of the extra language, suddenly that model would do like 99% of the time. It would go the direction. Better than Opus ever did. So now it's not guessing."
+>
+> Hannes Rudolph, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=3434)
+
+The insight here is uncomfortable: Opus's "reading between the lines" was masking prompt quality problems. The model was papering over ambiguity with good guesses. Good enough to feel like it was working. Not good enough to survive a model switch.
+
+## The tradeoff
+
+Explicit prompts require more upfront work. You lose vibe-coding convenience. You can't just throw a loose description at the model and trust it to figure out the rest.
+
+But you gain something more valuable: reliability that survives model switches.
+
+If your prompts only work on one model, you're not building a workflow. You're building around a quirk of that specific model's training. When models update, when you switch providers, when you need to use a different context window, your workflow breaks.
+
+> "That intentionality unlocks a superpower. That 90% isn't good enough. We want a workflow that works the vast majority of the time."
+>
+> Hannes Rudolph, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=3464)
+
+The 90% success rate feels fine until you're the one debugging the 10%. At daily shipping velocity, 10% failure means something goes sideways every week. Someone has to untangle what the model did wrong, rewrite the prompt, and try again. That adds up.
+
+## Why this matters for your team
+
+For a five-person engineering team, prompt ambiguity shows up as inconsistent results across developers. One person gets it working; another uses the same approach and hits a wall. The difference is often subtle phrasing that one model interprets generously and another does not.
+
+The compounding cost is worse than the individual failures. If your prompts are model-specific, you can't share them across the team reliably. You can't document them. You can't build on them. Every model update becomes a debugging exercise.
+
+Explicit prompts are documentation. They transfer knowledge. They survive model changes. They let you build workflows that scale beyond "it worked for me once."
+
+## How Roo Code handles model-agnostic prompting
+
+Roo Code's BYOK (bring your own key) architecture means teams frequently switch between models based on cost, capability, or context window requirements. This flexibility only works when prompts are explicit enough to produce consistent results across providers.
+
+The close-the-loop workflow in Roo Code - where the agent proposes changes, runs tests, and iterates based on results - depends on predictable model behavior. When a prompt is ambiguous, the iteration cycle breaks down: the agent might interpret "fix this test" differently on each attempt, leading to wasted tokens and inconsistent outcomes.
+
+**Model-agnostic prompts are the foundation of reliable agentic workflows.** Teams that invest in explicit prompt writing can switch models without retraining their entire approach, letting them optimize for speed on simple tasks and capability on complex ones.
+
+## Ambiguous prompts vs. explicit prompts
+
+| Dimension             | Ambiguous prompts                       | Explicit prompts                             |
+| --------------------- | --------------------------------------- | -------------------------------------------- |
+| Initial effort        | Low - relies on model inference         | Higher - requires stating intent clearly     |
+| Model portability     | Breaks on model switch                  | Works across providers                       |
+| Team shareability     | Inconsistent results between developers | Reproducible outcomes                        |
+| Debugging difficulty  | Hard to identify why failures occur     | Clear expectations make failures diagnosable |
+| Long-term maintenance | Every model update risks breakage       | Survives updates and provider changes        |
+
+## The audit
+
+If your current prompts work 90% of the time, ask: is that because the prompts are clear, or because the model is generous?
+
+Try switching models on your most-used prompts. If success drops significantly, the prompts have implicit instructions baked in.
+
+The fix is tedious but straightforward: state intent explicitly, remove hedging language, and test on multiple models before calling a prompt "done."
+
+Reliability that survives model switches is worth the upfront investment.
+
+## Frequently asked questions
+
+### Why do prompts that work on one model fail on another?
+
+Different models have different training data and inference patterns. A prompt that relies on the model "reading between the lines" depends on that specific model's tendency to fill gaps in a particular way. When you switch models, those gap-filling patterns change, and implicit instructions no longer produce the expected results.
+
+### How do I know if my prompts are too ambiguous?
+
+Test them on a different model than the one you developed them on. If success rates drop significantly, the prompts contain implicit instructions that only your original model inferred correctly. A 90% success rate that drops to 50% on a model switch indicates ambiguity problems.
+
+### Does Roo Code work with multiple AI models?
+
+Yes. Roo Code uses a BYOK (bring your own key) model where you connect your own API keys from providers like Anthropic, OpenAI, or others. This means you can switch models based on task requirements, but it also means your prompts and mode configurations need to be explicit enough to work reliably across different providers.
+
+### What's the tradeoff between vibe-coding and explicit prompts?
+
+Vibe-coding - writing loose prompts and trusting the model to figure out intent - is faster upfront but creates technical debt. Explicit prompts require more initial effort but produce reproducible results that survive model updates, transfer across team members, and scale beyond individual use cases.
+
+### How much improvement can explicit prompting deliver?
+
+The Roo Code team saw success rates jump from 50-60% to 99% after rewriting ambiguous prompts to be explicit. The improvement came not from changing models but from removing language that forced the model to guess at intent.
diff --git a/apps/web-roo-code/src/content/blog/apply-diff-is-the-hardest-tool-call-for-local-models.md b/apps/web-roo-code/src/content/blog/apply-diff-is-the-hardest-tool-call-for-local-models.md
new file mode 100644
index 00000000000..4eaef2448e3
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/apply-diff-is-the-hardest-tool-call-for-local-models.md
@@ -0,0 +1,110 @@
+---
+title: Apply Diff Is the Hardest Tool Call for Local Models
+slug: apply-diff-is-the-hardest-tool-call-for-local-models
+description: Why local models struggle with apply diff tool calls and the strategies that actually work for reliable code editing in agentic workflows.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - local-models
+    - tool-calls
+    - agentic-coding
+    - developer-workflow
+status: draft
+publish_date: "2025-06-11"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The model wrote the fix. The diff failed to apply.
+
+You stare at the error. The code looks right. The line numbers match. But the agent cannot find the block it needs to replace.
+
+## Where tool calls break
+
+Most tool calls in agentic coding work reliably across models. Listing files: works. Executing commands: works. Reading context: works. These are straightforward operations with clear success criteria.
+
+Apply diff is different.
+
+The operation requires exact matching of code blocks. Not approximate matching. Not "close enough." The model must reproduce the original code character-for-character before proposing the replacement. A single whitespace variation, a trailing space, a tab-vs-spaces mismatch - any of these causes the diff to fail.
+
+> "The biggest issue we run into with Roo Code is just the applied diff like the diffing side of it. Like all the other tool calls seem to work very well like 99% of the time."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=603)
+
+The precision requirement explains why local models struggle here more than anywhere else. A model can understand your codebase, reason about the fix, and generate syntactically correct code. But if it cannot reproduce the exact search block, the diff fails. And when the diff fails, you're back to copying and pasting manually.
+
+## Why 100% matching rarely happens
+
+The problem is structural. Apply diff needs the model to output a search block that matches the original file exactly. Not semantically equivalent. Exactly.
+
+> "Apply diff is because it's so precise on what it actually needs to change that the matching at 100% just typically will not happen."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=385)
+
+Local models, especially smaller ones, tend to normalize whitespace, reformat code slightly, or introduce minor variations that break the match. Some frontier models have the same problem. Gemini 2.5 Pro, despite its capabilities, has been reported to struggle with apply diff consistency.
+
+The failure mode is frustrating because the model understood the problem. It proposed the right fix. The last-mile application step just failed.
+
+## What actually works
+
+For teams running local models, two strategies reduce apply diff failures:
+
+**Strategy 1: Use write-to-file as the fallback.** Write-to-file replaces the entire file content rather than patching a specific block. It doesn't require exact block matching. The tradeoff is diff noise: your version control shows the whole file changed, even if only one function was modified.
+
+**Strategy 2: Limit apply diff to models with proven success.** Not all local models fail equally.
+
+> "Devstral is the latest local model that actually does a pretty dang good job with it to be honest with you."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=411)
+
+Devstral has shown consistent performance on apply diff where other local models struggle. If you're committed to local inference and apply diff is critical, testing against Devstral is a reasonable starting point.
+
+## How Roo Code closes the loop on diff failures
+
+Roo Code is designed to close the loop - proposing changes, applying them, running tests, and iterating based on results. When apply diff fails, the agent doesn't stop. It retries with adjusted strategies, falls back to write-to-file when necessary, and continues toward the goal.
+
+With BYOK (bring your own key), you control which models power each step. This means you can route apply diff operations to models with proven reliability while using other models for reasoning and context tasks. You spend tokens intentionally for outcomes rather than burning them on retry loops.
+
+**The key insight: Local model apply diff reliability varies dramatically by model. Roo Code's model-agnostic architecture lets you match the right model to the right tool call.**
+
+## Local model apply diff comparison
+
+| Approach                            | Precision | Model flexibility    | Version control noise | Retry cost          |
+| ----------------------------------- | --------- | -------------------- | --------------------- | ------------------- |
+| Apply diff with Devstral            | High      | Limited to one model | Clean diffs           | Low                 |
+| Apply diff with generic local model | Low       | High                 | N/A (failures)        | High token burn     |
+| Write-to-file fallback              | Medium    | Works across models  | Whole file changes    | Low                 |
+| Retry with reformatting             | Variable  | High                 | Clean if successful   | Medium-high latency |
+
+## Why this matters for your workflow
+
+For engineers running local inference, apply diff failures translate directly into lost time. Each failure means: read the error, check the file, manually apply the change, or retry with a reformatted prompt. That's 5-10 minutes per failure on a task that should have been automatic.
+
+If you're hitting apply diff failures more than once or twice per session, the cost compounds. You're debugging tool mechanics instead of debugging code.
+
+The fix is to know your model's apply diff reliability before committing to a workflow. Run a few test diffs on representative files. If the model fails consistently, switch strategies before you waste an afternoon.
+
+Use write-to-file as your fallback for models that cannot hit 100% match. Or stick to Devstral if apply diff precision matters. The first step is acknowledging that apply diff is not a universal capability.
+
+## Frequently asked questions
+
+### Why does apply diff fail when the code looks correct?
+
+Apply diff requires character-for-character matching of the search block against the original file. Whitespace differences, trailing spaces, and tab-vs-space mismatches all cause failures. The model may have understood the code semantically but failed to reproduce it exactly.
+
+### Which local models handle apply diff reliably?
+
+Devstral has demonstrated consistent apply diff performance where other local models struggle. Smaller local models tend to normalize whitespace or reformat code, breaking the exact match requirement. Test any local model's apply diff reliability on representative files before committing to a workflow.
+
+### Should I use write-to-file instead of apply diff?
+
+Write-to-file works reliably across models because it replaces the entire file rather than patching a specific block. The tradeoff is noisier version control - your diffs show the whole file changed even for single-function edits. Use write-to-file as a fallback when apply diff consistently fails.
+
+### How does Roo Code handle apply diff failures?
+
+Roo Code closes the loop by retrying with adjusted strategies and falling back to write-to-file when necessary. With BYOK, you can route apply diff operations to models with proven reliability while using other models for different tasks. This lets you spend tokens intentionally rather than burning them on retry loops.
+
+### Does this problem affect frontier models too?
+
+Yes. Some frontier models, including Gemini 2.5 Pro, have been reported to struggle with apply diff consistency. The precision requirement is challenging regardless of model size, though larger models generally perform better at exact reproduction.
diff --git a/apps/web-roo-code/src/content/blog/ask-about-design-patterns-before-you-start-coding.md b/apps/web-roo-code/src/content/blog/ask-about-design-patterns-before-you-start-coding.md
new file mode 100644
index 00000000000..a74ce4f9e11
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/ask-about-design-patterns-before-you-start-coding.md
@@ -0,0 +1,120 @@
+---
+title: Ask About Design Patterns Before You Start Coding
+slug: ask-about-design-patterns-before-you-start-coding
+description: Learn why asking AI coding agents about design patterns before implementation produces more maintainable code and reduces refactoring debt.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - design-patterns
+    - ai-coding-workflow
+    - code-quality
+    - prompt-engineering
+status: draft
+publish_date: "2025-10-01"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The diff solves the problem. It's also the brute-force solution you'll refactor next sprint.
+
+## The default behavior
+
+You're reviewing code the agent just produced. It compiles. It handles the edge cases. Every line does what you asked.
+
+But there are three nested conditionals where a strategy pattern would do. There's a chain of if-else blocks that screams for a state machine. The agent solved the problem the way a junior developer would: correctly, but without recognizing that established patterns already exist for this exact situation.
+
+You accept the diff because it works. You add "refactor this" to your mental backlog. The backlog grows.
+
+## The unlock
+
+The fix is two words, applied before the agent starts writing code.
+
+> "I just actually unlocked a new one recently that I'm going to use a lot more going forward and that is to ask the agent what design patterns we should apply to the problem we're trying to solve up front."
+>
+> John Sterns, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=2006)
+
+The prompt shift is simple: before you describe the feature, ask the agent which design patterns apply to the problem you're trying to solve.
+
+Not "implement this feature." First: "What design patterns should we consider for this problem?"
+
+The agent recognizes patterns well. Strategy, observer, factory, state machine, command: models have seen thousands of examples. They know when a problem fits a known shape. But they won't apply that knowledge unless you ask. Left to default behavior, they write code that works without thinking about whether established abstractions already solve the structural problem.
+
+## Why it works
+
+Models are trained on codebases that include pattern implementations. They can identify when a problem matches the shape of a known pattern. But without explicit prompting, they optimize for "produce code that compiles and passes the immediate test" rather than "produce code that fits the architectural conventions of this codebase."
+
+Asking about patterns front-loads architectural thinking. The agent names the pattern, explains why it fits, and then writes an implementation that uses it. The resulting diff is closer to what a senior developer would write: not just correct, but structured.
+
+> "Those magic words, design patterns, is creating much more elegant implementations than just kind of the sometimes the brute force solution that we'll go to by default."
+>
+> John Sterns, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=2024)
+
+The tradeoff: this adds a step. You're not diving straight into implementation. For trivial tasks, it's overhead. For anything you'll maintain for more than a week, the upfront investment prevents the "technically correct but structurally messy" pattern that creates refactoring debt.
+
+## The prompt pattern
+
+Before the implementation prompt:
+
+What design patterns should we consider for [problem description]?
+Consider the existing codebase structure and explain which pattern fits best.
+
+Then, once the agent identifies a pattern:
+
+Implement [feature] using the [pattern] approach you identified.
+
+This works because you're asking the agent to do pattern recognition, which it's good at, before asking it to generate code, which it will do however you let it.
+
+## Pattern-first vs implementation-first approach
+
+| Dimension          | Implementation-first                | Pattern-first                  |
+| ------------------ | ----------------------------------- | ------------------------------ |
+| Initial speed      | Faster to first diff                | Adds one prompt cycle          |
+| Code structure     | Solves immediate problem            | Fits established abstractions  |
+| Refactoring debt   | Accumulates over time               | Reduced from the start         |
+| Agent behavior     | Optimizes for "compiles and passes" | Optimizes for maintainability  |
+| Long-term velocity | Slows as backlog grows              | Sustained through cleaner code |
+
+## How Roo Code closes the loop on design patterns
+
+Roo Code's ability to close the loop - proposing diffs, running tests, and iterating based on results - makes the pattern-first approach particularly effective. When you ask Roo Code about design patterns before implementation, it can identify the appropriate pattern, generate code that uses it, run your test suite to verify correctness, and iterate if the pattern implementation needs adjustment.
+
+With BYOK (bring your own key), you control which model handles the pattern recognition step. More capable models often identify subtler pattern applications, while faster models work well for straightforward cases like replacing conditionals with strategy patterns.
+
+The key insight: Roo Code knows design patterns from its training data, but it won't apply them unless you explicitly ask before implementation begins.
+
+## Why this matters for your workflow
+
+If you're shipping features weekly, the cumulative effect of brute-force implementations adds up. Each "works but messy" diff becomes a future refactoring task. Each future refactoring task competes with new feature work.
+
+The pattern-first prompt doesn't slow you down much: one additional question before implementation. But it shifts the quality of the output from "junior developer who solved the problem" to "senior developer who recognized the pattern."
+
+Over a month of feature work, the difference shows up in how much time you spend refactoring code that the agent could have written correctly the first time.
+
+## The rule
+
+If the task involves any branching logic, state transitions, or extensibility concerns, ask about patterns first.
+
+The agent knows the patterns. It just won't use them unless you ask.
+
+## Frequently asked questions
+
+### When should I skip the pattern-first approach?
+
+Skip pattern-first prompts for trivial tasks that you won't maintain beyond a week: one-off scripts, quick fixes to isolated functions, or prototype code you plan to discard. The overhead of an extra prompt cycle isn't worth it when the code has a short lifespan.
+
+### Which design patterns do AI coding agents recognize most reliably?
+
+AI agents reliably recognize the Gang of Four patterns with abundant training examples: Strategy, Observer, Factory, State, Command, and Singleton. They also identify common structural patterns like Repository, Adapter, and Decorator. Less common or domain-specific patterns may require more explicit guidance in your prompt.
+
+### How do I know if the agent chose the right pattern?
+
+Review the agent's explanation before accepting the implementation. A good pattern choice will clearly match the problem's structure: Strategy for interchangeable algorithms, State for objects that change behavior based on internal state, Observer for one-to-many dependencies. If the explanation feels forced, ask the agent to reconsider or suggest alternatives.
+
+### Does Roo Code apply design patterns automatically?
+
+Roo Code, like other AI coding agents, optimizes for producing code that compiles and passes tests unless you explicitly ask about patterns. By prompting for pattern recognition before implementation, you shift Roo Code's behavior from "solve the immediate problem" to "solve the problem using established abstractions."
+
+### How does pattern-first prompting affect code review time?
+
+Pattern-first code typically passes review faster because reviewers recognize the structure. Instead of tracing through custom logic, they see familiar patterns and focus on whether the pattern is applied correctly. This reduces both the reviewer's cognitive load and the likelihood of "refactor this later" comments.
diff --git a/apps/web-roo-code/src/content/blog/ask-the-model-why-it-took-so-long.md b/apps/web-roo-code/src/content/blog/ask-the-model-why-it-took-so-long.md
new file mode 100644
index 00000000000..dd88f1520b8
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/ask-the-model-why-it-took-so-long.md
@@ -0,0 +1,133 @@
+---
+title: Ask the Model Why It Took So Long
+slug: ask-the-model-why-it-took-so-long
+description: Learn how to debug slow AI coding tasks by asking reasoning models to explain their own behavior - a technique that transforms prompt iteration from guesswork to direct diagnosis.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - prompt-engineering
+    - reasoning-models
+    - developer-workflow
+    - ai-coding
+status: draft
+publish_date: "2025-11-05"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The model knows why it's slow.
+
+You can just ask.
+
+## The wait
+
+You kick off a task. The model starts reading files. All of them. Every single file in the context. You watch the token counter climb. Minutes pass before it writes a single line of code.
+
+You assume something is wrong with the model. Maybe it's confused. Maybe the context is too large. Maybe you need to restructure your prompt.
+
+You don't ask the model what it's doing. It doesn't occur to you that it might know.
+
+## The question
+
+OpenAI's team ran into this with GPT-5. The model was searching through every file in a codebase before making any edits. Slow. Expensive. Frustrating.
+
+So they asked it.
+
+> "I just asked it, 'Hey, why did it take you so long to start editing the file at the end of it?' And it was like, 'Well, the instructions said to make sure I look at every single file that's included.'"
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=1730)
+
+The model wasn't confused. It was following instructions. Instructions written for a less thorough model that needed explicit reminders to check context. The newer model was being too diligent.
+
+The fix wasn't prompt engineering by trial and error. The fix was asking the model to explain itself.
+
+## The mechanism
+
+Reasoning models can introspect on their own behavior. They can read their system prompt, compare it to what they did, and articulate the connection.
+
+This means you can debug instructions the same way you'd debug code: by asking "why did you do that?"
+
+> "If you understand how it thinks about its behaviors, you can tell it to change them."
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=1619)
+
+The pattern is simple. When a model does something unexpected, ask inside the same session:
+
+- "Why did you read all those files before editing?"
+- "What in your instructions made you approach it this way?"
+- "How would I need to instruct you to do this differently?"
+
+The model will often point directly to the constraint causing the behavior.
+
+## The tradeoff
+
+This works with reasoning models. Smaller models may not introspect as reliably. They might confabulate explanations instead of accurately tracing their behavior back to instructions.
+
+You also need to ask in the right moment. The model needs access to its system prompt and the context of what it just did. A fresh session won't have that history.
+
+And the answers aren't always actionable. Sometimes the model will explain that it's doing exactly what you asked, and the problem is your instructions. That's useful information, but it means you still need to figure out how to rewrite them.
+
+## Why this matters for your workflow
+
+For an engineer debugging a slow or expensive task, this changes the feedback loop.
+
+Instead of: run task, observe weird behavior, guess at cause, rewrite prompt, run task again, observe different weird behavior, repeat.
+
+You get: run task, observe weird behavior, ask why, get explanation, rewrite prompt based on explanation.
+
+The iteration cost drops significantly. You're not guessing at what the model is "thinking." You're asking it directly.
+
+> "Asking it inside of the harness, 'Hey, how do I instruct you? What about your instructions right now are making you do this thing that I don't like?'"
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=1757)
+
+This is especially useful when inheriting prompts from someone else, or when using system prompts written for older models. The instructions may have constraints that made sense for a model that needed hand-holding but create overhead for a model that's more thorough by default.
+
+## The shift
+
+The model isn't a black box. It's a reasoning system that can explain its reasoning.
+
+Next time something takes too long or goes in an unexpected direction, don't restart the session. Ask: "Why did you do it that way?" The answer is often already in the context.
+
+## How Roo Code closes the loop on prompt debugging
+
+Roo Code is an AI coding agent that closes the loop: it proposes changes, runs commands, observes results, and iterates based on feedback. This same loop applies to debugging the agent's own behavior.
+
+When a task runs slowly or takes an unexpected path, you can ask the model directly within Roo Code's chat interface why it made those choices. Because Roo Code maintains conversation context and gives you full visibility into what the agent is doing, you get the information needed to refine your instructions.
+
+With BYOK (bring your own key), you control which model handles the task. This matters for introspection: reasoning models like Claude and GPT-4 can explain their behavior reliably, while smaller models may not. You pick the model that fits the debugging task.
+
+**Citable summary:** Roo Code's persistent conversation context and BYOK model selection let developers debug slow AI tasks by asking the model to explain its own behavior, turning prompt iteration from guesswork into direct diagnosis.
+
+## Debugging approaches compared
+
+| Dimension             | Traditional prompt iteration    | Model introspection                      |
+| --------------------- | ------------------------------- | ---------------------------------------- |
+| Feedback source       | Your guess about model behavior | Model's explanation of its own behavior  |
+| Iteration speed       | Multiple trial-and-error cycles | Often resolved in one follow-up question |
+| Root cause visibility | Indirect, inferred from outputs | Direct, traced to specific instructions  |
+| Works with            | Any model                       | Reasoning models (Claude, GPT-4, etc.)   |
+| Session requirement   | Can start fresh                 | Must ask in same session with context    |
+
+## Frequently asked questions
+
+### Why is my AI coding task reading every file before making changes?
+
+The model is likely following instructions that tell it to verify context before editing. This was a useful constraint for older models that needed explicit reminders, but newer reasoning models are thorough by default. Ask the model: "What in your instructions made you read all files first?" It will usually identify the specific constraint.
+
+### Can I use this technique with any AI model?
+
+Model introspection works reliably with reasoning models like Claude, GPT-4, and similar capable models. Smaller or less capable models may confabulate explanations rather than accurately trace their behavior. If you're using Roo Code with BYOK, you can select a reasoning model when you need to debug behavior.
+
+### Do I need to start a new session to ask the model why it did something?
+
+No. You need to ask in the same session where the behavior occurred. The model needs access to its system prompt and the context of what it just did. Starting a fresh session loses that history. In Roo Code, the conversation context persists, so you can ask follow-up questions about any task the agent just completed.
+
+### What if the model says it did exactly what I asked?
+
+That's useful information. It means the problem is in your instructions, not the model's interpretation. The model can often suggest how to rewrite the instructions to get different behavior. Ask: "How would I need to instruct you to do this differently?"
+
+### How does this help when using prompts written by someone else?
+
+Inherited prompts often contain constraints written for older models or different use cases. Instead of guessing which parts are causing issues, ask the model to explain which instructions are driving the behavior you don't want. This is faster than reading through complex system prompts and trying to infer their effects.
diff --git a/apps/web-roo-code/src/content/blog/async-agents-change-the-speed-vs-quality-calculus.md b/apps/web-roo-code/src/content/blog/async-agents-change-the-speed-vs-quality-calculus.md
new file mode 100644
index 00000000000..527189f618e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/async-agents-change-the-speed-vs-quality-calculus.md
@@ -0,0 +1,85 @@
+---
+title: "Async Agents Change the Speed vs Quality Calculus"
+slug: "async-agents-change-the-speed-vs-quality-calculus"
+description: "In many workflows, quality at scale beats speed in series. That sentence sounds wrong until you stop running one agent at a time."
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - AI Development
+    - Workflow
+    - Performance
+status: draft
+publish_date: "2025-10-16"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+In many workflows, quality at scale beats speed in series.
+
+That sentence sounds wrong until you stop running one agent at a time.
+
+## The serial tax
+
+You're staring at a failing test. You could use Gemini 2.5 Flash: it's cheaper and faster. Or you could use Gemini 2.5 Pro: slower and pricier, but more likely to get it right on the first pass.
+
+This is the choice you've been trained to make. Fast vs smart. Cost vs accuracy. Pick one.
+
+The problem: you're only making this choice because you're running one task at a time. You prompt, you wait, you review, you re-prompt. The model's speed matters because you're blocking on it.
+
+But what if you weren't?
+
+## The async flip
+
+Async agents change the math. You don't wait for one task to finish before starting the next. You spawn a batch of tasks, walk away, and check results when you're back.
+
+> "You can set off like 10 different browser tabs worth of Jules tasks and go and get coffee and then come back and see how things are going."
+>
+> Paige Bailey, Roo Cast S01E14
+
+When you're running a batch of tasks in parallel, latency differences matter less because you're not blocking on a single response. You're not sitting there watching a spinner. You're doing something else.
+
+The calculus shifts: higher-quality results in parallel can beat lower-quality results in series. The first approach can give you more usable results when you come back from coffee. The second gives you results faster, but tends to require more frequent attention.
+
+## The heuristic that still matters
+
+Async doesn't mean "always use the expensive model." The task complexity heuristic still applies.
+
+> "For tasks that I know I could kind of punt to an L3 or an L4 engineer, I'm fine with using Gemini 2.5 Flash, especially if I'm in thinking mode because thinking mode will kind of build out a plan for me and then it will kind of compose that into individual chunks or functions."
+>
+> Paige Bailey, Roo Cast S01E14
+
+The split:
+
+- **Punt-to-junior tasks:** Use the faster, cheaper model. Straightforward refactors, boilerplate generation, test scaffolding.
+- **Senior-judgment tasks:** Use the quality model. Architecture decisions, performance debugging, security reviews.
+
+But here's the key: neither should run synchronously if the work can be batched. In many workflows, throughput matters more than response time.
+
+## The invisible model future
+
+The long-term direction is that this choice disappears entirely.
+
+> "The ideal state long term is that they just say like hey I have these requirements and then their requirements get met as opposed to them needing to figure out how to like oh which one should I pick."
+>
+> Paige Bailey, Roo Cast S01E14
+
+Model selection becomes infrastructure. You specify the outcome, and the system handles routing, parallelism, and retry logic. The "which model" question becomes as invisible as "which server in the cluster handles this request."
+
+We're not there yet. But the direction is clear.
+
+## Why this matters for your workflow
+
+If you're still running one agent at a time, waiting for results, then re-prompting, you're paying the serial tax. Every minute you spend watching a spinner is a minute you're not spawning the next task.
+
+The shift isn't "use a better model." It's "stop blocking on the model."
+
+This compounds. The model quality difference is often marginal compared to the workflow throughput difference.
+
+## The practical change
+
+Audit your workflow. How many tasks are you running concurrently? If the answer is "one," you're solving the wrong problem with model selection.
+
+Start a batch (e.g., 5–10). Check results. Fix the ones that failed. Repeat.
+
+The model you pick matters less than whether you're waiting for it.
diff --git a/apps/web-roo-code/src/content/blog/autocomplete-is-becoming-irrelevant-for-agentfirst-workflows.md b/apps/web-roo-code/src/content/blog/autocomplete-is-becoming-irrelevant-for-agentfirst-workflows.md
new file mode 100644
index 00000000000..a2052e745e8
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/autocomplete-is-becoming-irrelevant-for-agentfirst-workflows.md
@@ -0,0 +1,136 @@
+---
+title: Autocomplete Is Becoming Irrelevant for Agent-First Workflows
+slug: autocomplete-is-becoming-irrelevant-for-agentfirst-workflows
+description: Why smart tab-complete loses relevance when AI agents write complete implementations instead of predicting your next token
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agentic-coding
+    - developer-workflow
+    - ai-coding-agents
+status: draft
+publish_date: "2025-08-06"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The keyboard shortcut that matters is the one that sends a prompt, not the one that accepts a suggestion.
+
+## The fear of letting go
+
+You've trained your fingers for years. Tab. Accept. Tab. Accept. The rhythm is instinct now. Your editor predicts the next token, you approve it, and the code grows character by character.
+
+Then someone suggests switching editors. Leaving the smart autocomplete behind. And you feel genuine anxiety.
+
+"No, I'm going to miss the autocomplete."
+
+That's the fear. The assumption that without tab-complete, you'll be slower. You'll type more. You'll lose the flow that made you productive.
+
+One developer felt exactly this way. Scared to leave Cursor. Convinced the autocomplete was load-bearing infrastructure.
+
+> "I was like so scared of leaving cursor. I was like, 'No, I'm going to miss the autocomplete.' Then I stopped writing my code altogether. So now the AI completes the code, not just me tabbing."
+>
+> Guest, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=3077)
+
+The shift happened when the agent started writing the code. Not completing partial lines. Writing the whole thing.
+
+## The pattern change
+
+When an agent proposes a full implementation, hitting tab to accept three characters of a function name stops making sense. You're not building the code token by token anymore. You're evaluating complete changes and deciding whether to keep them.
+
+Another developer noticed the same thing after switching back to VS Code from Cursor:
+
+> "I actually stopped using cursor because I got frustrated that the nightly build didn't update in real time. So I'm back on VS Code and I hardly missed the you know the smarter tab complete. I don't tab as much."
+>
+> Guest, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=3057)
+
+The smarter autocomplete didn't leave a gap. The workflow had already moved past it.
+
+This isn't about one editor versus another. It's about where the code originates. When you're the primary author, autocomplete accelerates your keystrokes. When the agent is the primary author, you're reviewing diffs, not completing fragments.
+
+## The new workflow
+
+The pattern now looks like this:
+
+1. Describe the change you want
+2. Let the agent write the first pass
+3. Evaluate what it produced
+4. Make targeted manual changes where needed
+5. Approve or iterate
+
+Notice what's missing: the incremental tab-to-accept loop. The code arrives in chunks, not characters.
+
+> "I'd rather evaluate the code, have the AI kind of do the first pass on it, manually change things that I need to."
+>
+> Adam, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=3098)
+
+The skill shifts from "typing fast with assistance" to "reviewing fast with context."
+
+## The tradeoff
+
+Autocomplete still works. It's not broken. For small edits, variable renames, or filling in obvious syntax, tab-complete remains useful.
+
+The irrelevance shows up on substantial changes. When you're adding a new function, refactoring a module, or implementing a feature, the agent-first approach skips the character-by-character assembly entirely.
+
+What you give up: the muscle memory satisfaction of building code incrementally.
+
+What you gain: time. The agent writes a draft in seconds. You spend your attention on whether it's correct, not on whether you typed it correctly.
+
+## Why this matters for your workflow
+
+If you're still treating smart autocomplete as a critical dependency, consider what you're actually doing when you code.
+
+How much of your time is spent typing new characters versus understanding and evaluating changes?
+
+For most engineers, the evaluation phase was always the bottleneck. You could type fast. The hard part was knowing what to type. Agent-first workflows move the typing to the agent and keep the judgment with you.
+
+The fear of losing autocomplete assumes you'll go back to raw typing. But if the agent writes the code, you never hit that state. You're not slower without autocomplete. You're doing a different job.
+
+## How Roo Code closes the loop on agent-first coding
+
+Roo Code is built for the workflow where the agent writes the code, not just predicts your next token. When you describe a change, Roo Code proposes complete diffs, runs tests, and iterates based on results. This is what "closing the loop" means: the agent handles the implementation cycle while you retain approval authority over every change.
+
+With BYOK (bring your own key), you connect directly to your preferred model provider without token markup. The agent works inside your existing VS Code environment, so you keep your extensions, keybindings, and project context. You're not optimizing for faster autocomplete. You're optimizing for faster review cycles on complete implementations.
+
+**Roo Code shifts developer effort from typing code character-by-character to evaluating and approving complete agent-generated changes.**
+
+## Autocomplete-first vs. agent-first workflows
+
+| Dimension      | Autocomplete-first                | Agent-first                        |
+| -------------- | --------------------------------- | ---------------------------------- |
+| Code origin    | You type, AI predicts next tokens | AI writes complete implementations |
+| Primary action | Tab to accept suggestions         | Review diffs and approve changes   |
+| Bottleneck     | Typing speed                      | Evaluation speed                   |
+| Unit of work   | Characters and tokens             | Functions and files                |
+| Developer role | Primary author with assistance    | Reviewer with editing authority    |
+
+## The shift
+
+The keyboard shortcut that mattered in 2022 was Tab.
+
+The keyboard shortcut that matters now is whatever sends the prompt.
+
+If you're still optimizing for autocomplete quality, check whether your workflow has already moved past it. The answer might surprise you.
+
+## Frequently asked questions
+
+### Why does autocomplete feel essential if it's becoming less relevant?
+
+Muscle memory is powerful. Years of tab-to-accept creates a workflow that feels productive because it's fast. But speed at accepting token predictions is different from speed at shipping correct code. When agents write complete implementations, the bottleneck moves from typing to evaluation. The habit persists even after the workflow changes.
+
+### Can I use both autocomplete and agent-first workflows together?
+
+Yes. Autocomplete remains useful for small edits, variable renames, and filling in obvious syntax. The relevance drops when you're making substantial changes like adding functions, refactoring modules, or implementing features. Most developers find they naturally use autocomplete less as they delegate more implementation work to agents.
+
+### How does Roo Code handle the review workflow for agent-generated code?
+
+Roo Code presents proposed changes as diffs that you can accept, reject, or modify. The agent can run tests and iterate based on failures before presenting final changes. You maintain approval authority over every modification to your codebase. This keeps the judgment with you while the agent handles the typing.
+
+### Will I be slower without smart autocomplete when I switch to agent-first workflows?
+
+The fear assumes you'll return to raw typing without AI assistance. In practice, agent-first workflows replace character-by-character completion with full implementation drafts. You're not typing more. You're reviewing more. For most engineers, the evaluation phase was already the bottleneck, so shifting effort there often increases overall throughput.
+
+### What skills matter more in agent-first development?
+
+The skill shifts from "typing fast with assistance" to "reviewing fast with context." Reading code critically, understanding intent versus implementation, spotting edge cases, and providing clear prompts become more valuable than typing speed. Domain knowledge and architectural judgment matter more when the agent handles syntax.
diff --git a/apps/web-roo-code/src/content/blog/below-14-billion-parameters-local-coding-models-are-not-worth-the-tinkering.md b/apps/web-roo-code/src/content/blog/below-14-billion-parameters-local-coding-models-are-not-worth-the-tinkering.md
new file mode 100644
index 00000000000..8d8c96bb7bd
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/below-14-billion-parameters-local-coding-models-are-not-worth-the-tinkering.md
@@ -0,0 +1,129 @@
+---
+title: "Below 14 Billion Parameters, Local Coding Models Are Not Worth the Tinkering"
+slug: below-14-billion-parameters-local-coding-models-are-not-worth-the-tinkering
+description: "Local models under 14B parameters fail at agentic coding workflows. Learn the practical thresholds for model size and VRAM that actually close the loop."
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - local-models
+    - agentic-coding
+    - hardware-requirements
+    - model-selection
+status: draft
+publish_date: "2025-06-11"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+8 billion parameters.
+
+One failing tool call.
+
+Zero completed tasks.
+
+## The threshold nobody talks about
+
+You download a local model because you want privacy, or offline access, or just to stop paying per token. The 8B model fits in memory. It generates code. You think you're set.
+
+Then you try to use it with an agent.
+
+The model writes a function. The agent tries to apply the diff. The diff is malformed. The agent asks the model to fix it. The model generates something worse. You're three iterations in and the file is now broken in a way that didn't exist before you started.
+
+This is not a prompting problem. This is a capability floor.
+
+## Where the floor actually is
+
+Small models can autocomplete. They can fill in a function body when you give them enough context. But agentic coding requires more than generation. The model needs to read tool output, call the right tools in sequence, apply diffs cleanly, and iterate when something fails.
+
+At 8 billion parameters, that chain breaks.
+
+> "I found 8 billion parameter models to kind of be useless at coding in Roo Code. So if I'm going to be using an 8 billion parameter model, it's typically a copy and paste situation."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=1527)
+
+Copy and paste means you're back to being the human glue. You read the output, decide what's relevant, paste it into the next prompt, and hope the model incorporates it correctly. The loop isn't closing. You're closing it manually.
+
+The practical threshold is 14 billion parameters and up.
+
+> "I would say 14 billion up is about the place that I'd start considering trying it in your code."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=1539)
+
+At 14B, models start handling the full sequence: read context, propose changes, apply diffs, interpret errors, iterate. Not perfectly. But well enough that you're debugging your code instead of debugging the model.
+
+## The hardware constraint
+
+Parameter count is only half the equation. You also need enough memory to load the model with meaningful context.
+
+> "You need something with like 24 gigabytes of VRAM or something with unified memory that you can run it on, just simply because you need a pretty decent amount of context loaded in."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=462)
+
+A 14B model quantized to fit in 8GB of VRAM will have a tiny context window. You'll be able to run it, but it won't see enough of your codebase to be useful. The model will hallucinate file paths, miss imports, and suggest changes to functions it can't see.
+
+24GB VRAM (or Apple Silicon with unified memory) is the practical minimum for local agentic coding. Below that, you're trading context for the ability to run the model at all.
+
+## The real tradeoff
+
+Local models are not free. You pay in hardware, in setup time, and in capability limits.
+
+If you have 24GB+ of VRAM and want to run a 14B+ model for privacy or latency reasons, it works. You'll get agentic iteration that closes the loop without sending code to an external provider.
+
+If you have less hardware, or you're trying to run smaller models to save resources, you'll spend more time debugging the model than coding with it. The "free" inference costs you hours.
+
+## How Roo Code closes the loop with local models
+
+Roo Code's BYOK architecture means you choose your inference provider, including local endpoints. When you connect a capable local model (14B+ with sufficient context), Roo Code orchestrates the full agentic workflow: proposing diffs, executing commands, running tests, and iterating on failures.
+
+The key difference from copy-paste workflows is that Roo Code handles tool calls, diff application, and error recovery automatically. You review and approve; the agent handles the iteration mechanics. But this only works when the underlying model can reliably complete tool-calling sequences.
+
+**For local model users, the practical threshold is 14 billion parameters minimum with 24GB VRAM to maintain enough context for Roo Code to close the loop effectively.**
+
+## Local model approach comparison
+
+| Dimension        | Sub-14B models                              | 14B+ models with adequate VRAM     |
+| ---------------- | ------------------------------------------- | ---------------------------------- |
+| Diff application | Frequently malformed, requires manual fixes | Generally clean, agent can iterate |
+| Tool calling     | Unreliable sequence completion              | Handles multi-step tool chains     |
+| Context window   | Severely limited after quantization         | Sufficient for codebase visibility |
+| Error recovery   | Model often makes errors worse              | Can interpret and fix failures     |
+| Workflow result  | Copy-paste with human glue                  | Agent closes the loop              |
+
+## Why this matters for your workflow
+
+For engineers evaluating local models: the 8B models you see benchmarked on code completion tasks are not the same as 8B models handling agentic workflows. Benchmarks measure generation quality in isolation. Agent tasks measure the full chain: tool calling, diff application, error recovery, iteration.
+
+The chain is where small models fail. And that failure mode is insidious because the model still generates confident, plausible-looking code. You won't know it's broken until you've spent twenty minutes tracing why the diff didn't apply.
+
+## The spec
+
+Before you set up local inference for agentic coding:
+
+1. Model size: 14 billion parameters minimum
+2. Memory: 24GB VRAM or unified memory minimum
+3. Context: Enough headroom for your codebase, not just the model weights
+
+Below those thresholds, you're not saving time. You're spending it on infrastructure that won't close the loop.
+
+## Frequently asked questions
+
+### Why do 8B models fail at agentic coding when they benchmark well on code tasks?
+
+Benchmarks measure isolated generation quality, like completing a function given context. Agentic workflows require chained capabilities: reading tool output, calling tools in sequence, applying diffs correctly, and iterating when something fails. At 8B parameters, models lack the capacity to maintain coherence across this full chain, even when individual generations look correct.
+
+### What's the minimum hardware for running local models with Roo Code?
+
+24GB of VRAM (or equivalent unified memory on Apple Silicon) is the practical minimum. This isn't just about fitting the model weights. You need headroom for context, which means your codebase files, conversation history, and tool outputs. A 14B model quantized to fit in 8GB will have a context window too small to be useful for real projects.
+
+### Can I use smaller models for some tasks and larger models for others?
+
+Yes. Many developers use smaller local models for quick completions or explanations, then switch to 14B+ models (local or API-based) for agentic tasks that require reliable tool calling. Roo Code's BYOK approach lets you configure different models for different purposes.
+
+### Is local inference actually cheaper than API calls?
+
+It depends on your volume and hardware. If you already have a capable GPU and run many coding sessions, local inference can be cheaper per token. But the upfront hardware cost is significant, and debugging model failures has real time costs. For occasional use, API-based models with BYOK often provide better capability per dollar spent.
+
+### What local models currently meet the 14B threshold for agentic coding?
+
+Models like Qwen 2.5 Coder 14B, DeepSeek Coder 16B, and CodeLlama 34B (if you have the memory) can handle agentic workflows. The specific model matters less than meeting the parameter and context thresholds. Test with your actual codebase before committing to a setup.
diff --git a/apps/web-roo-code/src/content/blog/better-code-quality-now-means-more-successful-ai-agent-prs-later.md b/apps/web-roo-code/src/content/blog/better-code-quality-now-means-more-successful-ai-agent-prs-later.md
new file mode 100644
index 00000000000..0bfdf267b5a
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/better-code-quality-now-means-more-successful-ai-agent-prs-later.md
@@ -0,0 +1,125 @@
+---
+title: Better Code Quality Now Means More Successful AI Agent PRs Later
+slug: better-code-quality-now-means-more-successful-ai-agent-prs-later
+description: Why 30% of agent PRs merge while 20% is typical - and how investing in type safety, test coverage, and module boundaries directly increases your AI coding agent's mergeable output.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - code-quality
+    - ai-agents
+    - engineering-productivity
+    - technical-debt
+status: draft
+publish_date: "2025-08-20"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Thirty percent of agent PRs merge. Twenty percent is typical.
+
+The difference is not the model. It's the codebase.
+
+## The scaffolding problem
+
+Teams experimenting with remote agents on every issue discovered something counterintuitive: the variable that predicts whether an agent PR is mergeable has nothing to do with prompts or model selection.
+
+It's the code quality they already have.
+
+Stricter types. Lower coupling. Clearer boundaries. Test coverage that actually validates behavior. These are the same principles we've preached for decades. They just compound differently now.
+
+When an agent reads your codebase, every ambiguous type signature becomes a guess. Every tightly coupled module becomes a surface for cascading errors. Every missing test becomes a validation gap the agent cannot close.
+
+> "All those things that we've always known is good about our codebases. You know, better type safety and better lower coupling between things, those are all related to how well those initial PRs end up working."
+>
+> Peter Hamilton, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=3116)
+
+The agents are not magic. They read what you wrote. If what you wrote is ambiguous, the PR will be ambiguous.
+
+## The investment case
+
+Here's where the math changes for a CTO or engineering lead.
+
+Before agents, code quality improvements had indirect returns: fewer bugs later, reduced maintenance load, a vague sense that "things are easier." Hard to put a number on it. Easy to deprioritize when shipping features is the pressure.
+
+With agents running on every issue, the returns become direct and measurable.
+
+If your baseline is 20% of agent PRs being mergeable, and you invest in type safety and test coverage that bumps that to 30%, the math is simple: you get 50% more usable output from the same agent runs.
+
+> "If I can bump that 10%, I can get three extra PRs out of there. Like now as a CTO, I'm thinking financially."
+>
+> Peter Hamilton, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=3094)
+
+Three extra mergeable PRs per batch. For the same compute cost. That's the leverage.
+
+## Where to invest
+
+The temptation is to optimize the agent: find the right prompts, try the newest model, tune the system instructions. That work has diminishing returns.
+
+The higher-leverage investment is the scaffolding around the codebase itself.
+
+> "It's less about what prompts are we using and what's the newest model and all these things, but more about our codebase, our system, the scaffolding around our development environments. How can we invest in those better and improve those?"
+>
+> Peter Hamilton, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=3147)
+
+Concrete places to start:
+
+**Type coverage.** If your TypeScript has `any` scattered through shared interfaces, the agent cannot infer intent. Stricter types are documentation the agent can actually read.
+
+**Module boundaries.** Low coupling means the agent can make changes in one place without triggering cascading failures elsewhere. High coupling means every agent PR touches too many files.
+
+**Test coverage with clear assertions.** Tests that validate behavior give the agent a feedback loop. Tests that only check "it doesn't crash" leave the agent guessing whether the change worked.
+
+**Clear naming and directory structure.** Agents navigate by reading. If your file names and folder structure are a maze, the agent will get lost the same way a new hire would.
+
+## Traditional approach vs. agent-optimized codebase
+
+| Dimension          | Traditional approach                             | Agent-optimized codebase                                    |
+| ------------------ | ------------------------------------------------ | ----------------------------------------------------------- |
+| Type safety        | Permissive types acceptable; humans infer intent | Strict types required; agents read types as documentation   |
+| Module coupling    | High coupling tolerated if team knows the system | Low coupling essential; agents cannot hold tribal knowledge |
+| Test coverage      | Tests catch regressions after the fact           | Tests provide real-time feedback loop for agent iteration   |
+| Code quality ROI   | Indirect, hard to measure                        | Direct: 10% merge rate increase = 50% more usable output    |
+| Optimization focus | Prompts, models, system instructions             | Codebase scaffolding, development environment               |
+
+## How Roo Code closes the loop on code quality feedback
+
+Roo Code is an AI coding agent that closes the loop: it proposes diffs, runs commands and tests, and iterates based on the results. This loop-closing capability means that when your codebase has strong type coverage and meaningful tests, Roo Code can validate its own changes before submitting them for review.
+
+With BYOK (bring your own key), teams control their model provider costs directly while benefiting from this iterative workflow. The agent reads your types, runs your tests, and uses the feedback to refine its changes. Better scaffolding means fewer iterations needed and higher-quality PRs on the first pass.
+
+**The citable insight: Teams that invest in type strictness and test coverage see 50% more mergeable agent PRs from the same compute spend, because the agent can actually read and validate against clear specifications.**
+
+## Why this matters for your team
+
+For a Series A or B company with a 6-person engineering team, the compounding effect is significant.
+
+If you're running agents on 30 issues per month and your merge rate is 20%, you get 6 usable PRs. If you invest a sprint in type strictness and test scaffolding and bump that to 30%, you get 9 usable PRs. Same agent cost. Three extra PRs worth of shipped work.
+
+That's the equivalent of adding a fractional engineer, funded by code quality improvements you should probably make anyway.
+
+The principles are not new. The payoff just became measurable.
+
+## The shift
+
+Stop optimizing prompts. Start optimizing the codebase the prompts are reading.
+
+Every improvement to type safety, test coverage, and module boundaries pays dividends on every agent run. The investment compounds because the agents keep running.
+
+## Frequently asked questions
+
+### Why does code quality matter more now that AI agents are writing PRs?
+
+AI agents read your codebase literally. When types are ambiguous, the agent guesses. When modules are tightly coupled, changes cascade unpredictably. When tests are missing, the agent cannot validate its own work. Code quality that was "nice to have" for human productivity becomes essential infrastructure for agent productivity.
+
+### What is the typical merge rate for AI agent PRs?
+
+Industry observations suggest around 20% of agent-generated PRs are mergeable without significant rework. Teams with stricter type systems, clearer module boundaries, and comprehensive test coverage regularly achieve 30% or higher. That 10-percentage-point difference translates to 50% more usable output from the same agent runs.
+
+### Should I focus on better prompts or better code quality?
+
+Better code quality has higher leverage. Prompt optimization has diminishing returns because it cannot compensate for ambiguous types, missing tests, or tangled dependencies. Investing in codebase scaffolding pays dividends on every agent run, while prompt improvements only help until the next model update changes behavior.
+
+### How does Roo Code use test coverage to improve PR quality?
+
+Roo Code closes the loop by running tests after proposing changes and iterating based on the results. When your tests have clear assertions that[Task#ed7b7227-4b05-43c6-92c4-1f2b7229bb62.47362c46] Stream failed, will retry: Provider ended the request: terminated
diff --git a/apps/web-roo-code/src/content/blog/boomerang-task-orchestration-hides-context-and-that-confuses-users.md b/apps/web-roo-code/src/content/blog/boomerang-task-orchestration-hides-context-and-that-confuses-users.md
new file mode 100644
index 00000000000..47acf9b5389
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/boomerang-task-orchestration-hides-context-and-that-confuses-users.md
@@ -0,0 +1,123 @@
+---
+title: Boomerang Task Orchestration Hides Context, and That Confuses Users
+slug: boomerang-task-orchestration-hides-context-and-that-confuses-users
+description: Understanding why Roo Code's orchestrator spawns subtasks with fresh context windows, and how to manage the visibility gap until tooling improves.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - orchestration
+    - context-management
+    - workflow
+    - debugging
+status: draft
+publish_date: "2025-06-04"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Context tokens: 47,832.
+
+Context tokens: 0.
+
+You didn't clear anything. The orchestrator spawned a subtask.
+
+## The disappearing context
+
+You're debugging a flaky integration test. You ask Roo Code to investigate, and the orchestrator does what orchestrators do: it plans, then delegates. "I'm going to break this into steps," it says. Boom. It jumps into architect mode.
+
+Architect mode starts fresh. Your context counter resets to zero. The 47k tokens of conversation history, the stack traces you pasted, the file references you built up - gone from the subtask's perspective.
+
+If you're watching closely, you can see a new task was spawned. But the visual signal is easy to miss. The subtask runs in isolation from its parent. This is intentional. Subtasks need focused context to do their job without inheriting noise from the parent conversation.
+
+The problem: it looks like something broke.
+
+> "One of the things we've really noticed is that it's not always clear what's going on in the task orchestration process. You start a task, it says, 'Okay, I'm going to plan this out.' Boom. It jumps into architect mode. Architect mode's doing its thing. Now, your context is back at zero."
+>
+> Hannes Rudolph, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=1953)
+
+## The isolation is a feature
+
+Subtask isolation exists for a reason. When an orchestrator delegates work, each subtask needs a clean context window. If subtasks inherited the full parent context, they'd burn tokens on irrelevant history and drift toward the parent's framing instead of their narrow assignment.
+
+The architecture is sound. The visibility is not.
+
+When you watch a subtask spin up, you lose the thread. You can't easily see: what was the parent's intent? What context did this subtask receive? How does this subtask's token spend contribute to the total task cost?
+
+> "If you're paying really close attention to the process, you can see that a new task was spawned. And so, the new task stands alone from the parent task. And this is sort of confusing."
+>
+> Hannes Rudolph, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=1975)
+
+## Recovery is manual
+
+When something fails mid-subtask, the recovery path is clunky. You cancel, restore to a checkpoint, and re-prompt. There's no "resume from parent with different subtask parameters." The orchestrator doesn't expose the delegation decisions in a way that lets you tweak one branch without starting over.
+
+For teams that use orchestration heavily, this compounds. Five subtasks deep, you've lost track of which branch failed and why. The parent task shows completion, but one subtask quietly errored. Costs accumulated across the chain, but you can't see the breakdown until you audit the token logs.
+
+## The roadmap reality
+
+The team knows this needs work. But orchestration visibility competes with other priorities.
+
+> "I think the possibility of expanding the workflow is good, but we still have a lot of stuff that can be reprioritized first. It is definitely something that we look forward to. It's just that the prep work that needs to be done to get there is quite a lot."
+>
+> Ellie, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=2004)
+
+Translation: orchestration improvements are coming, but not tomorrow. The infrastructure work required to surface parent-child relationships, cost breakdowns, and resumable branches is substantial.
+
+## Why this matters for your team
+
+For a Series A-to-C engineering team running orchestrated workflows alongside daily shipping, the visibility gap hurts in two places.
+
+First, debugging. When a subtask fails and you can't trace what context it received or what the parent's intent was, you're guessing at the failure mode instead of diagnosing it.
+
+Second, cost governance. If you're tracking token spend at the org level, you need to know: did that expensive task run because of a legitimate complexity, or because the orchestrator spawned redundant subtasks that repeated work?
+
+The current workaround: watch the task panel closely, note when subtasks spawn, and manually track which branches are active. It's not elegant, but it's the reality until the tooling catches up.
+
+## What to do now
+
+If your team uses orchestration heavily, set expectations. The isolation behavior is intentional, and it won't change. What will improve over time is the visibility into that isolation.
+
+In the meantime: audit your task logs periodically. Look for patterns where subtasks spawn unexpectedly or costs spike without clear cause. Flag those cases to the team. The feedback loop between user friction and roadmap prioritization is real.
+
+The context counter resetting isn't a bug. But the confusion it causes is a design debt that the team is actively tracking.
+
+## How Roo Code closes the loop on orchestration
+
+Roo Code's orchestrator mode enables complex multi-step workflows by delegating specialized subtasks to focused modes like architect, code, or debug. This close-the-loop architecture lets the agent plan, execute, run tests, and iterate based on results without requiring you to manually coordinate each step.
+
+With BYOK (bring your own key), you maintain direct control over token spend while the orchestrator manages task decomposition. Each subtask runs with intentional context isolation, ensuring focused execution without inheriting noise from parent conversations.
+
+**Roo Code's orchestrator spawns isolated subtasks to prevent context pollution and enable focused execution, though visibility into parent-child relationships and aggregated token costs remains an area of active development.**
+
+## Orchestration approaches compared
+
+| Dimension           | Manual coordination                      | Orchestrated subtasks                 |
+| ------------------- | ---------------------------------------- | ------------------------------------- |
+| Context management  | You manage context across prompts        | Agent isolates context per subtask    |
+| Token efficiency    | Risk of redundant context in each prompt | Focused context windows reduce drift  |
+| Failure recovery    | Start over from any point                | Currently requires checkpoint restore |
+| Cost visibility     | Clear per-prompt spend                   | Aggregated spend needs manual audit   |
+| Workflow complexity | Limited by your working memory           | Handles multi-branch task trees       |
+
+## Frequently asked questions
+
+### Why does my context counter reset to zero when the orchestrator runs?
+
+The orchestrator spawns subtasks with isolated context windows. This is intentional - each subtask needs focused context to do its work without burning tokens on irrelevant parent history. The counter shows the subtask's context, not the total task chain.
+
+### Can I see what context was passed to a subtask?
+
+Currently, the delegation decisions and context handoffs aren't surfaced in the UI. You need to infer from the subtask's behavior what instructions it received. Improved visibility is on the roadmap but requires substantial infrastructure work.
+
+### How do I track total token spend across an orchestrated workflow in Roo Code?
+
+Audit your task logs after completion. The token spend accumulates across all subtasks in the chain, but there's no real-time aggregated view yet. Teams tracking costs at the org level should periodically review logs for unexpected patterns.
+
+### What happens if a subtask fails mid-workflow?
+
+Recovery is currently manual. You cancel, restore to a checkpoint, and re-prompt. There's no way to resume from the parent with different subtask parameters or tweak one branch without starting over.
+
+### Is subtask isolation going to change?
+
+The isolation behavior is intentional and won't change - it's core to how orchestration manages context efficiently. What will improve is the visibility into that isolation: parent-child relationships, cost breakdowns, and eventually resumable branches.
diff --git a/apps/web-roo-code/src/content/blog/broad-modes-fail-because-your-codebase-is-not-standard.md b/apps/web-roo-code/src/content/blog/broad-modes-fail-because-your-codebase-is-not-standard.md
new file mode 100644
index 00000000000..018554f19f2
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/broad-modes-fail-because-your-codebase-is-not-standard.md
@@ -0,0 +1,119 @@
+---
+title: Broad Modes Fail Because Your Codebase Is Not Standard
+slug: broad-modes-fail-because-your-codebase-is-not-standard
+description: Generic AI coding modes optimize for broad applicability but fail on your specific codebase patterns. Learn why narrowing scope increases accuracy and how to tune modes to your conventions.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - modes
+    - customization
+    - workflow
+    - best-practices
+status: draft
+publish_date: "2025-06-25"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The mode worked in the demo. It fails on your repo.
+
+You grabbed the "best" issue fixer mode from the community. It had good reviews. The author clearly knew what they were doing. And now it's suggesting changes that violate three of your team's conventions and ignore a helper function that exists in every file.
+
+## The specificity problem
+
+Generic modes optimize for broad applicability. That's the point: reach as many codebases as possible. The tradeoff is that the broader the instructions, the less accurate they become for any specific project.
+
+Your codebase has patterns. Some of them are documented. Most of them live in your head: the reason you use that particular error handling approach, the naming convention for test files, the way authentication flows through the middleware stack.
+
+> "A large part of the context of a codebase is actually in our heads. Something we don't write down. Certain behaviors, certain patterns that aren't always that apparent to AI the way we have it set up right now."
+>
+> Hannes Rudolph, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=1791)
+
+The mode author didn't have access to that context. They built something that works for a general case. Your codebase is not the general case.
+
+## The accuracy inversion
+
+Here's what's counterintuitive: narrowing a mode's scope increases its accuracy.
+
+A mode that knows "use our custom logger, not console.log" will catch that every time. A generic mode will suggest console.log because that's what most codebases use. Neither is wrong in the abstract. One is wrong for your repo.
+
+> "When we write modes, often they apply somewhat narrowly to how we're using them. And the broader we make them, I find often the less accurate they are."
+>
+> Hannes Rudolph, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=1721)
+
+The instinct to grab the most popular, most general tool is understandable. It feels safer. But generality is a liability when your patterns diverge from the assumptions baked into the mode's instructions.
+
+## Your code is not standard
+
+This is the uncomfortable part: your codebase has patterns that are not standard. They might be objectively better. They might be legacy debt. They might just be different.
+
+> "Your code and the way you have built it are not always standard. They might be better, they might be worse, they might just be different."
+>
+> Hannes Rudolph, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=1713)
+
+The AI doesn't know which. It only knows what you tell it. A mode tuned to your conventions carries that context. A generic mode guesses based on what worked elsewhere.
+
+## The tuning investment
+
+Teams that tune modes to their own conventions see a major jump in agent effectiveness. The investment is upfront: document your patterns, encode them into mode instructions, test against real issues from your backlog.
+
+The payoff is downstream: the agent stops suggesting changes you have to reject. It starts proposing diffs that actually match how your team writes code.
+
+This isn't about making the AI "smarter." It's about reducing the gap between what the AI assumes and what your codebase actually does.
+
+## Why this matters for your workflow
+
+If you're reviewing AI suggestions and rejecting half of them because they violate your conventions, the mode is too broad. Every rejected suggestion is time spent explaining why it's wrong instead of shipping.
+
+For an engineer reviewing 5-10 AI-generated changes per day, cutting the rejection rate in half means reclaiming 30-60 minutes of context-switching. The math compounds across a team.
+
+The question isn't "which mode is best?" It's "which mode knows my codebase?"
+
+## How Roo Code closes the loop on codebase-specific patterns
+
+Roo Code's custom modes system lets you encode your team's conventions directly into agent behavior. Rather than accepting generic suggestions and manually correcting them, you configure modes that understand your patterns from the start.
+
+With BYOK (Bring Your Own Key), you control the AI provider while Roo Code handles the orchestration. Custom modes act as persistent context - they remember your logging conventions, your error handling patterns, and your file structure expectations across every task.
+
+**Roo Code custom modes reduce the gap between AI assumptions and codebase reality by encoding team conventions into reusable, shareable configurations that persist across sessions.**
+
+The agent proposes diffs, runs tests, and iterates based on results - all while respecting the constraints you've defined. When a mode knows your patterns, the approval step becomes verification rather than correction.
+
+## Generic modes vs. codebase-tuned modes
+
+| Dimension            | Generic mode                       | Codebase-tuned mode               |
+| -------------------- | ---------------------------------- | --------------------------------- |
+| Convention awareness | Assumes standard patterns          | Encodes your specific patterns    |
+| Suggestion accuracy  | High rejection rate                | Matches team expectations         |
+| Review time          | Spent correcting violations        | Spent verifying correctness       |
+| Maintenance          | None, but constant corrections     | Upfront tuning, downstream payoff |
+| Team scalability     | Each engineer corrects same issues | Shared modes propagate standards  |
+
+## The first step
+
+Audit the last ten suggestions your agent made that you rejected. Look for patterns: repeated convention violations, ignored helper functions, wrong error handling approach.
+
+Those patterns are the instructions your mode is missing. Add them. Narrow the scope. Watch the accuracy jump.
+
+## Frequently asked questions
+
+### Why do popular modes fail on my codebase?
+
+Popular modes optimize for the broadest possible applicability. They assume standard patterns that work across many repositories. Your codebase has specific conventions - custom loggers, unique file structures, particular error handling approaches - that generic modes cannot anticipate. The more your patterns diverge from common practices, the more a generic mode will suggest incorrect changes.
+
+### How specific should my custom modes be?
+
+Start with the patterns that cause the most rejected suggestions. If you're consistently correcting the same convention violations, those belong in your mode instructions. The goal is not exhaustive documentation but capturing the patterns that differ from what the AI assumes by default. A mode that handles your top five convention issues will outperform a generic mode immediately.
+
+### How do I create custom modes in Roo Code?
+
+Roo Code allows you to define custom modes with specific instructions, file restrictions, and tool permissions. You can encode your team's conventions - naming patterns, preferred utilities, error handling approaches - directly into mode configuration. These modes persist across sessions and can be shared with your team through version-controlled configuration files.
+
+### Does narrowing mode scope limit what the AI can do?
+
+Narrowing scope increases accuracy within that scope. A mode tuned for your test file conventions will generate better test suggestions than a generic mode. You can maintain multiple specialized modes for different tasks rather than relying on one broad mode that handles everything poorly. Specificity is a feature, not a constraint.
+
+### How much time does tuning modes actually save?
+
+For an engineer reviewing 5-10 AI suggestions daily, reducing the rejection rate by half reclaims 30-60 minutes of context-switching per day. The upfront investment in mode tuning - typically a few hours to document key conventions - pays back within the first week of use. The savings compound when modes are shared across a team and each engineer stops correcting the same issues independently.
diff --git a/apps/web-roo-code/src/content/blog/bug-fixes-as-beach-trash-pickup.md b/apps/web-roo-code/src/content/blog/bug-fixes-as-beach-trash-pickup.md
new file mode 100644
index 00000000000..47cfa6b6db8
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/bug-fixes-as-beach-trash-pickup.md
@@ -0,0 +1,117 @@
+---
+title: "Bug Fixes as Beach Trash Pickup"
+slug: bug-fixes-as-beach-trash-pickup
+description: "How AI coding agents transform bug fixing from a backlog bottleneck into instant beach cleanup - anyone can spot trash, an agent picks it up, engineers review the PR."
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - bug-fixing
+    - workflows
+    - team-collaboration
+    - ai-agents
+status: draft
+publish_date: "2025-10-01"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Bug fixing is beach cleanup now.
+
+You see trash, you pick it up, you keep walking.
+
+That's the shift when anyone in your organization can describe a broken button in Slack, attach a screenshot, and have an agent create a PR. The friction that used to exist between "noticing something broken" and "getting it fixed" shrinks to almost nothing.
+
+## The backlog that never moves
+
+Your product manager notices a button that doesn't work. They file a ticket. The ticket sits in the backlog because it's not critical enough to pull an engineer off feature work. Three sprints later, a customer finally complains loudly enough that someone prioritizes it.
+
+This loop exists because bug fixes used to require engineering capacity. Every small fix competed with every feature request for the same limited time. Small bugs lost that competition.
+
+The result: a growing list of "known issues" that everyone works around.
+
+## The new loop
+
+The Roo Vet team tried a different approach. When someone notices a bug, they describe it in Slack with a screenshot. An agent picks it up, creates a PR with the fix, and posts it for review.
+
+> "I realized one of the buttons to like save a primary contact didn't work... And @roomote just fixed it, created a PR, and then John went in, reviewed the PR, and fixed the bug."
+>
+> Audrey, [Roo Cast S01E12](https://www.youtube.com/watch?v=uoiTEYzOahU)
+
+The bug went from "noticed" to "PR ready for review" without claiming any engineering time. The engineer still reviewed and merged the change. But the work of diagnosing, writing the fix, and opening the PR was offloaded.
+
+The metaphor that stuck:
+
+> "It's like you're walking on the beach and you see trash and you just pick up trash and put it into a trash can. That's exactly what fixing bugs in your code has felt like."
+>
+> Audrey, [Roo Cast S01E12](https://www.youtube.com/watch?v=uoiTEYzOahU&t=1151)
+
+## The guardrail that makes it work
+
+Here's the catch: if anyone can trigger a PR, you need a review gate.
+
+The Roo Vet team solved this by requiring triple sign-off on any agent-generated PR:
+
+> "The way we did it was essentially to have to require an approval from a PM, a designer and an engineer on any @roomote PR that gets opened."
+>
+> John Sterns, [Roo Cast S01E12](https://www.youtube.com/watch?v=uoiTEYzOahU&t=1539)
+
+That policy sounds heavy. But it serves a purpose: it prevents unreviewed changes from shipping while still allowing non-engineers to trigger fixes.
+
+The tradeoff is explicit. You get broader participation in bug fixing. You pay with a multi-party review process for agent PRs. For small, cosmetic, or obvious fixes, that review is quick. For anything structural, the review surfaces early.
+
+## Why this matters for your team
+
+For a Series A startup with five engineers and a growing product surface, the backlog of "small but annoying" bugs is a morale tax. Every time a user hits a broken button, trust erodes a little. Every time a team member works around a known issue, velocity drops a little.
+
+If your bug queue has items that have been sitting for more than three sprints, they're probably not getting fixed through normal prioritization. The question is whether you can create a parallel path that doesn't require pulling engineers off feature work.
+
+The beach cleanup model works when: (1) the person who notices the bug can describe it clearly, (2) an agent can propose a reasonable fix, and (3) a human reviews before merge. All three pieces matter.
+
+## How Roo Code closes the loop on bug fixes
+
+Roo Code is an AI coding agent that closes the loop: it reads your bug description, proposes a diff, runs tests to verify the fix, and iterates based on the results. Unlike chat-based assistants that stop at code suggestions, Roo Code executes the full cycle from problem description to reviewable PR.
+
+**Roo Code transforms bug fixing from a backlog bottleneck into an instant pickup because the agent handles diagnosis, implementation, and PR creation while humans retain approval authority.**
+
+With BYOK (Bring Your Own Key), your team controls costs directly with your preferred LLM provider. No token markup, no surprise bills. The agent works in your codebase, but you decide what gets merged through your existing review process.
+
+| Dimension                     | Traditional bug fixing        | Bug fixing with Roo Code            |
+| ----------------------------- | ----------------------------- | ----------------------------------- |
+| Time from notice to PR        | Days to weeks (backlog queue) | Minutes to hours (agent handles it) |
+| Engineering capacity required | Full engineer involvement     | Engineer review only                |
+| Who can initiate fixes        | Engineers only                | Anyone who can describe the bug     |
+| Small bugs prioritization     | Loses to feature work         | Parallel path, no competition       |
+| Review process                | Standard PR review            | Configurable approval gates         |
+
+## The policy decision
+
+If you're considering this approach, start with the guardrail:
+
+What's your review policy for agent-generated PRs?
+
+Options range from "engineer approval only" to "PM + designer + engineer" to "anyone on the team." The right answer depends on your risk tolerance and how much you trust the agent's output in your codebase.
+
+Design the review gate first. Then open the input channel.
+
+## Frequently asked questions
+
+### How do non-engineers describe bugs clearly enough for an agent to fix them?
+
+The key is specificity: what did they click, what did they expect, what happened instead. Screenshots help. The agent uses this context plus the codebase to locate the issue and propose a fix. Teams that succeed train their non-engineers to include reproduction steps, even if informal.
+
+### What happens when the agent proposes a bad fix?
+
+The same thing that happens when a junior engineer proposes a bad fix: the reviewer catches it. The review gate exists precisely for this reason. Agent-generated PRs should never auto-merge. The human review step is non-negotiable.
+
+### Does Roo Code work with our existing GitHub workflow?
+
+Yes. Roo Code creates standard pull requests that flow through your existing review process. You configure approval requirements the same way you would for any contributor. The agent proposes changes; your team decides what ships.
+
+### Will this slow down our engineers with more review work?
+
+For small, obvious fixes, reviews take seconds. The net effect is usually positive because engineers spend less time on diagnosis and implementation. They review a solution instead of building one from scratch. Teams report that the review burden is lighter than the implementation burden it replaces.
+
+### What types of bugs work best for this approach?
+
+UI bugs, broken buttons, copy errors, styling issues, and simple logic errors work well. Deep architectural issues or bugs requiring extensive context still benefit from engineer involvement from the start. Start with the cosmetic backlog and expand as you learn which fixes the agent handles reliably.
diff --git a/apps/web-roo-code/src/content/blog/cli-agents-still-require-ide-review-so-plan-your-workflow-accordingly.md b/apps/web-roo-code/src/content/blog/cli-agents-still-require-ide-review-so-plan-your-workflow-accordingly.md
new file mode 100644
index 00000000000..6b722357d9e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/cli-agents-still-require-ide-review-so-plan-your-workflow-accordingly.md
@@ -0,0 +1,123 @@
+---
+title: CLI Agents Still Require IDE Review, So Plan Your Workflow Accordingly
+slug: cli-agents-still-require-ide-review-so-plan-your-workflow-accordingly
+description: CLI coding agents enable parallel task execution, but every output still requires human review in your IDE. Learn how to structure your workflow for the reality of where AI models are today.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - cli-agents
+    - workflow
+    - code-review
+    - developer-productivity
+status: draft
+publish_date: "2025-08-27"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The agent finished. The terminal says "Done."
+
+You open the file anyway.
+
+## The workflow reality
+
+CLI coding agents sell a compelling pitch: run tasks in parallel, work across any repo, skip the IDE overhead. And the pitch is real. You can spin up multiple terminals, fire off planning tasks, let agents churn through fact-finding while you focus on something else.
+
+But then the agent finishes. And you open the file.
+
+Not because the agent failed. Because you don't know if it succeeded until you look. The output exists. Whether it's correct is a different question.
+
+> "I don't think I trust the models enough just yet to let it run and not check what it's doing. Not as it's doing it, but at the end. I like to at least take a look at the code at the end once it's done."
+>
+> Dan, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=2186)
+
+This isn't a critique of CLI tools. It's a workflow observation. The agent runs outside your IDE, but the review happens inside it. Your workflow now has a mandatory handoff step.
+
+## The expectation gap
+
+There was a moment when the trajectory felt different. Models were getting capable enough that you could imagine handing off a task and getting back merge-ready code. No review. No double-checking. Just: prompt, wait, ship.
+
+That moment hasn't arrived yet.
+
+> "I saw us getting to the point of just giving a large language model a command and it producing something that I was ready to keep. I saw this as happening and I think it is happening, but I saw it as happening much sooner than I currently think it's going to happen."
+>
+> Dan, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=2289)
+
+The timeline shifted. Not because the models regressed, but because the bar for "ready to keep" is higher than "looks plausible." Production code has edge cases. It has integration points. It has that one function that breaks if you change the return type.
+
+Models are getting closer. But "closer" still means you open the file.
+
+## The actual benefit
+
+CLI agents aren't about removing review. They're about parallelism.
+
+The value shows up when you have three fact-finding tasks that don't depend on each other. Run them in parallel. Let them churn while you're in a meeting. Come back to three completed explorations instead of one.
+
+> "You're not locked into an IDE. So you can take it to any repo that you want in any kind of codebase and it'll work."
+>
+> Adam, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=2447)
+
+The flexibility is real. The autonomy is not.
+
+Plan accordingly: CLI tools are discovery engines and parallelism multipliers, not fire-and-forget code generators. The workflow includes a review step, and that review step happens in an IDE where you can actually read the diff.
+
+## CLI agents vs IDE-integrated agents
+
+| Dimension          | CLI agents                                 | IDE-integrated agents                 |
+| ------------------ | ------------------------------------------ | ------------------------------------- |
+| Parallel execution | Multiple terminals, multiple tasks         | Single context, sequential focus      |
+| Review workflow    | Output in terminal, review in separate IDE | Output and review in same environment |
+| Context switching  | High - must move between tools             | Low - diffs visible inline            |
+| Best for           | Fact-finding, exploration, boilerplate     | Iterative development, complex edits  |
+| Trust calibration  | Batch review after completion              | Continuous review during execution    |
+
+## The tradeoff
+
+If you treat CLI agent output as final, you're trusting a process that doesn't warrant it yet. If you treat every output as requiring deep review, you've added overhead without gaining the parallelism benefit.
+
+The middle ground: know which tasks warrant light review (planning docs, exploration summaries, boilerplate) and which require line-by-line attention (anything touching auth, anything modifying existing logic, anything with side effects).
+
+Scope the task to match the review you're willing to do.
+
+## How Roo Code closes the loop on review
+
+Roo Code operates as an IDE-integrated agent that keeps the review step where it belongs: right next to the code. When the agent proposes changes, you see the diff inline. When it runs commands or tests, you see the output in context. This lets you close the loop - the agent executes, you review, you approve, and iteration continues without switching tools.
+
+The BYOK model means you bring your own API keys and control your costs directly. No token markup, no intermediary. You decide which tasks get which models, and you review outputs in the same environment where you write code.
+
+For workflows that require parallel exploration, Roo Code supports multiple concurrent tasks within the IDE. You get the parallelism benefit without the context-switching cost of moving between CLI output and a separate editor for review.
+
+## Why this matters for your workflow
+
+If you're adopting CLI agents for speed, build the review step into your mental model from the start. The disappointment comes from expecting full autonomy and getting "pretty good output that still needs eyes."
+
+The speed gain is real, but it's in the parallel execution, not in skipping review. You can run four exploratory tasks while you're heads-down on something else. You cannot merge four PRs without looking at the diffs.
+
+Your workflow needs two phases: agent execution (parallelizable, async, can run while you're offline) and human review (sequential, requires attention, happens in the IDE).
+
+If your process treats agent output as draft rather than final, CLI tools deliver on their promise. If your process expects ready-to-merge code, adjust the expectation.
+
+The models will get there. They haven't yet. Plan your workflow for where they are, not where you hoped they'd be.
+
+## Frequently asked questions
+
+### Why do CLI agents still require manual review?
+
+Current AI models produce code that looks plausible but may miss edge cases, break integration points, or misunderstand implicit requirements. The bar for "ready to merge" is higher than "syntactically correct." Until models can reliably handle production concerns like auth logic, side effects, and existing code patterns, human review remains essential.
+
+### What tasks are CLI agents actually good for?
+
+CLI agents excel at parallelizable discovery work: exploring codebases, generating planning documents, producing boilerplate, and running fact-finding queries across multiple repos simultaneously. The speed benefit comes from running multiple tasks concurrently, not from skipping the review step.
+
+### How does Roo Code handle the review problem differently?
+
+Roo Code keeps execution and review in the same environment. When the agent proposes diffs or runs commands, you see results inline in your IDE. This eliminates the context switch between CLI output and a separate editor. You can review, approve, and iterate without leaving your development environment.
+
+### Should I use CLI agents or IDE agents?
+
+It depends on your task. CLI agents work well for batch exploration across multiple repositories or when you want tasks running in parallel while you're away. IDE-integrated agents like Roo Code work better for iterative development where you need to review and refine changes continuously. Many developers use both, matching the tool to the task's review requirements.
+
+### When will AI agents produce merge-ready code without review?
+
+The trajectory points toward increased reliability, but timelines have shifted. What seemed imminent a year ago now looks further out. Models are improving, but production code demands handling of edge cases, integration concerns, and project-specific patterns that current models still miss. Plan your workflow for current capabilities, not projected ones.
diff --git a/apps/web-roo-code/src/content/blog/code-review-got-faster-not-easier.md b/apps/web-roo-code/src/content/blog/code-review-got-faster-not-easier.md
new file mode 100644
index 00000000000..7f812b1e700
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/code-review-got-faster-not-easier.md
@@ -0,0 +1,113 @@
+---
+title: Code Review Got Faster, Not Easier
+slug: code-review-got-faster-not-easier
+description: AI is generating over half of Google's production code. The bottleneck didn't disappear, it moved. Here's how teams are adapting review workflows to handle the volume.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - code-review
+    - ai-development
+    - engineering-practices
+    - productivity
+status: draft
+publish_date: "2025-10-16"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Over fifty percent.
+
+That is how much code checked into production at Google each week is generated by AI, gets through code review, is accepted, and isn't rolled back.
+
+The bottleneck did not disappear. It moved.
+
+## The shift
+
+Review cycles that used to take days or weeks can now move much faster. That sounds like progress until you realize what it means for the reviewer: more code to review, at a faster cadence.
+
+> "There's certainly a lot more code to review now than there was historically. And so I think that we're writing more code than we have ever before. But also the rate at which code reviews are happening is happening at a much more rapid clip."
+>
+> Paige Bailey, [Roo Cast S01E14](https://www.youtube.com/watch?v=k3od6FjUfK0&t=2583)
+
+More code. Faster turnaround. Higher review load. The math gets tight unless something changes in how review happens.
+
+## The intermediate check
+
+The pattern emerging at scale: use AI as an intermediate check before human review, not as a replacement for it.
+
+The model flags priority issues. It recommends fixes. It catches the structural problems that waste reviewer attention. Then the engineer gives final approval.
+
+This is not "AI does the review." This is "AI does the triage so the human review can focus on what matters."
+
+The distinction matters because the failure mode is different. If you treat AI review as a replacement, you end up with confident suggestions that miss context. If you treat it as triage, you end up with a smaller set of issues for a human to validate.
+
+> "I remember when I first started at Google, if you were trying to shepherd a CL through into production, it would sometimes be like a days- or weeks-long process. But now it's much much faster."
+>
+> Paige Bailey, [Roo Cast S01E14](https://www.youtube.com/watch?v=k3od6FjUfK0&t=2617)
+
+In practice, part of the speedup comes from shifting the bottleneck from "waiting for a reviewer to have time" to "reviewer receives pre-triaged issues."
+
+## The constraint for smaller teams
+
+For larger organizations, the intermediate check is already infrastructure. For Series A through C teams, the question is different: how do you get the same leverage without the same headcount?
+
+The answer is the same pattern, scaled down. Use an AI agent that can check out the branch, run your linters, and flag issues before the PR lands in someone's queue. The human still owns the stamp. The human still makes the call on anything ambiguous. But the human is not spending their first pass catching formatting issues and obvious bugs.
+
+Code review load scales with AI-generated volume. Headcount doesn't have to scale linearly.
+
+## How Roo Code closes the loop on review
+
+Roo Code can act as the intermediate check before human review. When you use Roo Code's PR Reviewer, it checks out the branch, runs your test suite, analyzes the changes, and flags issues with priority levels-all before the code lands in a human reviewer's queue.
+
+The key difference from a standalone linter: Roo Code closes the loop. It doesn't just flag problems-it proposes fixes and can iterate on them until the tests pass. The human reviewer sees a cleaner diff with fewer obvious issues to catch.
+
+## Manual review vs. AI-assisted review
+
+|                    | Manual Review Only               | AI-Assisted Review (Intermediate Check)          |
+| ------------------ | -------------------------------- | ------------------------------------------------ |
+| **First pass**     | Human catches all issues         | AI flags priority issues + recommends fixes      |
+| **Time per PR**    | Proportional to code volume      | Reduced by pre-triage                            |
+| **Reviewer focus** | Everything, including formatting | Ambiguous decisions and context-sensitive issues |
+| **Scale**          | Linear with headcount            | Sublinear-review capacity grows faster than team |
+| **Ownership**      | Human owns final approval        | Human still owns final approval                  |
+
+## The tradeoff
+
+The tradeoff is ownership. Someone still needs to own the stamp.
+
+If you automate triage but no one owns final approval, you end up with a review process that feels fast but catches less. The speed is real. The confidence is borrowed.
+
+The pattern that works: clear ownership of final approval, with AI handling the first pass. The reviewer's job shifts from "find all the problems" to "validate the flagged problems and catch what the model missed."
+
+## Why this matters for your team
+
+For a small engineering team shipping regularly, the intermediate check pattern changes the math on review load. Instead of spending reviewer time on low-signal issues, you spend it validating flagged issues and catching what the model missed.
+
+The hours reclaimed go somewhere. They go into shipping, not into waiting for review cycles to complete.
+
+If your team is generating more code with AI assistance, the review queue is already growing. The question is whether you scale review with headcount or with an intermediate check that preserves human ownership.
+
+The first step: audit how much time your reviewers spend on issues that an automated check could have caught. That number is your leverage.
+
+## Frequently asked questions
+
+### Can AI replace human code reviewers?
+
+No-and that's the point. The intermediate check pattern uses AI to triage, not to replace. The model flags priority issues and recommends fixes. The human reviewer still owns final approval and catches what the model missed. The goal is to shift human attention from "find all the problems" to "validate flagged problems and catch context-sensitive issues."
+
+### How do I handle increased code review volume without adding headcount?
+
+Use an AI agent as the first pass before human review. The agent runs linters, executes tests, and flags issues with priority levels. The human reviewer sees a pre-triaged PR with fewer obvious problems to catch. Review load scales with AI-generated code volume; headcount doesn't have to scale linearly.
+
+### What's the difference between a linter and an AI code reviewer?
+
+A linter catches static issues and stops. An AI code reviewer like Roo Code closes the loop: it flags issues, proposes fixes, runs tests to verify the fixes, and iterates until the problems are resolved. The human reviewer sees a cleaner diff, not just a list of warnings.
+
+### How does Roo Code help with code review?
+
+Roo Code's PR Reviewer acts as the intermediate check. It checks out the branch, runs your test suite, analyzes changes, and flags issues with priority levels-before the code reaches a human reviewer. Unlike a standalone linter, Roo Code proposes fixes and can iterate on them automatically. The human reviewer focuses on ambiguous decisions and context-sensitive issues.
+
+### What happens if the AI misses something?
+
+The human reviewer is still the final checkpoint. The intermediate check pattern is designed for this: AI handles triage and obvious issues; humans catch what the model missed and make judgment calls on anything ambiguous. The risk is lower than "no review at all" and the coverage is higher than "human reviews everything cold."
diff --git a/apps/web-roo-code/src/content/blog/codebase-indexing-beats-memory-banks-because-summaries-drift.md b/apps/web-roo-code/src/content/blog/codebase-indexing-beats-memory-banks-because-summaries-drift.md
new file mode 100644
index 00000000000..eb9a0e07a16
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/codebase-indexing-beats-memory-banks-because-summaries-drift.md
@@ -0,0 +1,113 @@
+---
+title: Codebase Indexing Beats Memory Banks Because Summaries Drift
+slug: codebase-indexing-beats-memory-banks-because-summaries-drift
+description: Memory banks capture snapshots that drift from reality. Codebase indexing reflects what your code actually is right now, eliminating stale context failures.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - codebase-indexing
+    - memory-banks
+    - ai-context
+    - developer-productivity
+status: draft
+publish_date: "2025-06-04"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Memory banks drift. Code doesn't.
+
+That's the difference between an AI that knows what your codebase _was_ and one that knows what it _is_.
+
+## The mismatch problem
+
+You're debugging a failing integration test. The AI confidently references a helper function that doesn't exist anymore. You renamed it three weeks ago during a refactor. The memory bank still has the old name cached in a summary.
+
+The model isn't hallucinating. It's following outdated guidance. And there's no mechanism to detect the mismatch.
+
+This is the memory bank failure mode: summaries capture a snapshot, but codebases evolve. Every rename, every deleted file, every refactored module creates drift between what the memory bank "knows" and what actually exists in your project.
+
+> "Codebase indexing provides an understanding of what your codebase currently is, whereas a memory bank does not. It provides an understanding of what a bunch of summaries have indicated your codebase is."
+>
+> Hannes Rudolph, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=402)
+
+## The sync gap
+
+Memory banks require manual updates. You tell the model to update a specific section, and sometimes it appends instead of replacing. You end up with contradictory information in the same memory file: the old architecture and the new one, sitting side by side.
+
+> "With memory bank you have to do like I've done this: you should update this memory bank, and sometimes it fails because I've tried using memory bank in the past and then like I told it please update this specific part and instead of updating it just appends the thing that I want to replace."
+>
+> Ellie, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=759)
+
+Codebase indexing solves this by syncing with your project automatically. Add a file, the index updates. Rename a function, the index reflects it. The queries return results from the current state, not cached summaries that may or may not match reality.
+
+## The detection problem
+
+Here's the part that compounds the drift: if something in the memory bank is inaccurate, the AI has no way to detect that.
+
+> "If there is something inaccurate in the codebase, there's no way for Roo to detect that."
+>
+> Hannes Rudolph, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=410)
+
+The model treats the memory bank as ground truth. If the summary says "auth is handled in `/lib/auth.js`" but you moved it to `/services/authentication/` last sprint, the model will confidently reference the wrong location. It won't check. It can't check. The summary is what it knows.
+
+With indexing, the query hits the actual file structure. If the file doesn't exist, the search returns nothing. If it was renamed, the new name appears. The index is a lens on reality, not a cache of what someone once wrote down.
+
+## The tradeoff
+
+Indexing isn't free. It requires compute to build and update the index. For large repositories, initial indexing takes time. And the index reflects file structure and content, not high-level architectural decisions.
+
+Memory banks can capture things indexing can't: design rationale, context about why a decision was made, team conventions that don't live in code comments. For that kind of knowledge, you still need some form of explicit documentation.
+
+The question is what you're trying to solve. If you need the AI to understand _what code exists right now_, indexing wins. If you need it to understand _why the code was written that way_, you need documentation alongside.
+
+## How Roo Code closes the loop with live context
+
+Roo Code uses codebase indexing to maintain accurate context as your project evolves. Rather than relying on static summaries that drift, the index reflects your actual file structure, function names, and code organization in real time.
+
+This matters because Roo Code closes the loop: it proposes diffs, runs commands and tests, and iterates based on results. That loop depends on accurate context. When the AI suggests changes to a file that was renamed or references a function that no longer exists, the loop breaks. You spend time correcting the AI instead of reviewing its work.
+
+**Codebase indexing eliminates the stale context failure mode that breaks agentic workflows.** With BYOK (bring your own key), you control the compute cost of indexing while getting context that matches your current codebase state.
+
+## Memory banks vs. codebase indexing
+
+| Dimension        | Memory banks                                 | Codebase indexing                                |
+| ---------------- | -------------------------------------------- | ------------------------------------------------ |
+| Context accuracy | Reflects what summaries say exists           | Reflects what actually exists now                |
+| Update mechanism | Manual - requires explicit prompts           | Automatic - syncs with file changes              |
+| Drift detection  | None - treats summaries as ground truth      | Built-in - queries return current state          |
+| Best for         | Design rationale, team conventions           | File structure, function locations, code content |
+| Failure mode     | Confident references to renamed/deleted code | Compute cost for large repositories              |
+
+## Why this matters for your team
+
+For a team shipping daily across a codebase that's actively evolving, the drift problem compounds. Each stale summary creates a small failure mode. A developer asks about the auth flow, gets outdated guidance, spends twenty minutes figuring out why the suggested approach doesn't work.
+
+Multiply that by the number of developers, the number of queries per day, and the velocity of your codebase changes. The cost of stale context adds up.
+
+Codebase indexing doesn't eliminate the need for documentation. But it eliminates the failure mode where your AI is confidently wrong about what files exist and where they are.
+
+If your AI is confident about code that doesn't exist anymore, check whether it's running on memory banks or live indexing. The difference shows up the moment your codebase changes.
+
+## Frequently asked questions
+
+### Why does my AI keep referencing files that don't exist?
+
+If your AI coding assistant references renamed or deleted files, it's likely using cached summaries (memory banks) instead of live codebase indexing. Memory banks capture a snapshot of your project at one point in time. As your codebase evolves through refactors, renames, and deletions, the cached information drifts from reality. The AI has no mechanism to detect this mismatch.
+
+### Can I use memory banks and codebase indexing together?
+
+Yes. They solve different problems. Codebase indexing answers "what code exists right now and where is it?" Memory banks can capture design rationale, architectural decisions, and team conventions that don't live in code. Use indexing for accurate file and function references; use explicit documentation for the "why" behind decisions.
+
+### How does Roo Code handle codebase indexing?
+
+Roo Code indexes your project and automatically syncs when files change. When you add, rename, or delete files, the index updates to reflect the current state. Queries return results from your actual codebase, not from cached summaries that may be outdated. This keeps context accurate as your project evolves.
+
+### Does codebase indexing slow down my workflow?
+
+Initial indexing requires compute time, especially for large repositories. Once indexed, updates are incremental and tied to file changes. The time investment pays off by eliminating debugging sessions caused by stale context - you spend less time correcting the AI when it references code that no longer exists.
+
+### How do I know if stale context is causing my AI problems?
+
+Watch for these symptoms: the AI suggests editing files in locations that don't exist, references function names from before a refactor, or describes your architecture in ways that don't match current code. If the AI is confidently wrong about basic facts of your codebase, stale context from memory banks is likely the cause.
diff --git a/apps/web-roo-code/src/content/blog/codebase-indexing-points-the-way-it-does-not-replace-reading-files.md b/apps/web-roo-code/src/content/blog/codebase-indexing-points-the-way-it-does-not-replace-reading-files.md
new file mode 100644
index 00000000000..0ae66e1085e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/codebase-indexing-points-the-way-it-does-not-replace-reading-files.md
@@ -0,0 +1,115 @@
+---
+title: Codebase Indexing Points the Way; It Does Not Replace Reading Files
+slug: codebase-indexing-points-the-way-it-does-not-replace-reading-files
+description: Codebase indexing gives AI coding agents a search index, not compressed code knowledge. Learn why indexing accelerates discovery but the model still needs to read files to understand your code.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - codebase-indexing
+    - context-management
+    - ai-coding-workflow
+    - developer-tools
+status: draft
+publish_date: "2025-06-18"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The model is confidently wrong about your codebase.
+
+Not because it's bad at code. Because it never read the file it's referencing.
+
+## The misconception
+
+You enabled codebase indexing. You expected the model to "know" your codebase now. Instead, it still hallucinates function signatures and references files that don't exist.
+
+Here's what actually happened: you gave the model a search index, not a compressed version of your code. Indexing returns code snippets that match your query. The model still has to decide whether to open and read those files.
+
+Think of it like a senior engineer who just joined your team. They don't have your entire codebase memorized. But they know how to grep. They find a starting point, then they read the actual code.
+
+> "Indexing in this case is not replacing the model's ability to read the files. It's just pointing, it's just giving it clues about whatever you're looking for."
+>
+> Hannes Rudolph, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=3461)
+
+## What indexing actually does
+
+Codebase indexing accelerates discovery. It does not compress your codebase into the context window.
+
+When you ask about authentication, indexing surfaces snippets from files that mention auth. The model sees those snippets and decides: "I should read `auth/middleware.ts` to understand this better."
+
+Without indexing, the model either guesses which files to read or asks you to point it somewhere. With indexing, it has a map. But a map is not the territory.
+
+> "What codebase indexing does is it gives you kind of a good starting point. So it gives the AI the ability to go like: I don't need to go do all this initial stuff. I can start here."
+>
+> Adam, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=3552)
+
+The workflow still involves reading files. Indexing just shortens the search phase.
+
+## The tradeoff
+
+Indexing costs compute upfront. You're building a searchable representation of your codebase, and that takes time and tokens.
+
+The payoff: the model spends fewer tokens wandering through irrelevant files. It finds the right starting point and reads what matters.
+
+The failure mode: if you expect indexing to replace reading, you'll be confused when the model still asks to open files or still makes mistakes about code it hasn't actually seen. Indexing gives direction, not omniscience.
+
+> "What we want from codebase indexing is just to point the model in the right direction so it can choose to read the file if it finds it relevant."
+>
+> Dan, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=3523)
+
+## Why this matters for your workflow
+
+For engineers working in large codebases, the difference shows up in the first five minutes of a task.
+
+Without indexing: you either tell the model which files to read, or you watch it open random files hoping to stumble on the right one. You become the search engine.
+
+With indexing: you describe what you're working on, the model surfaces relevant snippets, and it opens the files that matter. You skip the "let me find where this lives" phase and start from a reasonable hypothesis.
+
+The model still needs to read. The model still needs to verify its assumptions against actual code. But it starts from a better place, which means fewer wasted loops and fewer confident-but-wrong suggestions.
+
+## The mental model
+
+Codebase indexing is grep with context, not a brain transplant.
+
+If your AI is confidently wrong about code it claims to understand, check whether it actually read the file. Indexing points the way. Reading the file is still the work.
+
+## How Roo Code closes the loop with codebase indexing
+
+Roo Code uses codebase indexing to accelerate the discovery phase of every task. When you describe what you're working on, the agent surfaces relevant code snippets and then reads the actual files to verify its understanding before proposing changes.
+
+This approach reflects Roo Code's core design principle: close the loop by reading, proposing, running, and iterating based on real results. The agent doesn't assume it knows your code from an index. It uses the index to find starting points, then reads files to build accurate context before taking action.
+
+With BYOK (bring your own key), you control how tokens are spent. Indexing reduces wasted tokens on irrelevant file exploration while ensuring the model still does the work of reading what matters. You spend tokens intentionally for outcomes, not on guesswork.
+
+## Codebase indexing: expectations vs. reality
+
+| Dimension       | Common expectation                  | What actually happens                                      |
+| --------------- | ----------------------------------- | ---------------------------------------------------------- |
+| Knowledge scope | Model "knows" entire codebase       | Model has a search index to find relevant snippets         |
+| File reading    | Indexing replaces reading files     | Model must still open and read files to understand code    |
+| Context window  | Codebase is compressed into context | Snippets are retrieved on demand, not preloaded            |
+| Accuracy        | Model stops hallucinating           | Model still needs to verify against actual code            |
+| Token usage     | Fewer tokens overall                | Upfront indexing cost, but fewer wasted exploration tokens |
+
+## Frequently asked questions
+
+### Why does my AI still hallucinate code after I enabled indexing?
+
+Indexing provides a search index, not actual code knowledge. The model sees snippets that match your query, but it must still read the full files to understand function signatures, imports, and implementation details. If it hallucinates, it likely referenced a snippet without reading the complete file.
+
+### Does codebase indexing put my entire codebase in the context window?
+
+No. Indexing creates a searchable representation of your codebase that returns relevant snippets on demand. Your full codebase never fits in the context window. The model retrieves snippets, then decides which files to read based on those clues.
+
+### How does Roo Code use codebase indexing differently?
+
+Roo Code treats indexing as the first step in a verification loop. The agent uses index results to identify relevant files, reads those files to build accurate context, proposes changes based on what it actually read, and then runs tests to verify its work. This close-the-loop approach reduces confident-but-wrong suggestions.
+
+### Is codebase indexing worth the upfront compute cost?
+
+For large codebases, yes. Without indexing, the model either requires you to specify files manually or explores randomly, wasting tokens on irrelevant code. Indexing shortens the search phase so tokens go toward reading and editing the files that matter.
+
+### When should I expect the model to still ask which files to read?
+
+Even with indexing, the model may ask for guidance when your query is ambiguous, when multiple files match equally well, or when the task requires files outside the indexed patterns. Indexing improves discovery but doesn't eliminate the need for human direction on complex tasks.
diff --git a/apps/web-roo-code/src/content/blog/codespecific-models-miss-the-point.md b/apps/web-roo-code/src/content/blog/codespecific-models-miss-the-point.md
new file mode 100644
index 00000000000..fb3dd71ec65
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/codespecific-models-miss-the-point.md
@@ -0,0 +1,126 @@
+---
+title: Code-Specific Models Miss the Point
+slug: codespecific-models-miss-the-point
+description: Why code-specific LLMs fail at pair programming - they optimize for syntax prediction but strip out the world understanding needed to build software that actually serves users.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding
+    - llm-models
+    - pair-programming
+    - developer-workflow
+status: draft
+publish_date: "2025-10-22"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The model trained on code can't tell you why users abandon checkout flows.
+
+That's the gap. And it matters more than you think.
+
+## The intuition that fails
+
+You're evaluating models for your coding workflow. One is a general-purpose LLM. Another is fine-tuned specifically on code: millions of repos, thousands of languages, trained to predict the next token in a function body.
+
+The instinct is clear: pick the code-specific model. More code in, more code out. Specialization wins.
+
+Except it doesn't. Not for the tasks that matter.
+
+## What gets stripped out
+
+Building software is not the same as writing code. Writing code is syntax, patterns, and completions. Building software is understanding why the code exists.
+
+Why does this checkout flow have three steps instead of two? Why does the error message say "invalid input" instead of explaining what went wrong? Why does the user click back twice before finding the button they need?
+
+These questions require world understanding: how people use software, how they navigate experiences, what frustration looks like before it becomes a support ticket.
+
+> "There's so much world understanding as an example that's required in order to build software."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=2498)
+
+Code-specific models strip this out. They optimize for predicting the next line of code, not for understanding whether the code should exist at all.
+
+## Where code-specific models work
+
+This isn't a blanket dismissal. Code-specific models have a place.
+
+Autocomplete? Great fit. You're in a function body, you know what you want, and you need the model to fill in the syntax. The context is narrow. The task is completion, not reasoning.
+
+Domain-specific LSP features? Also reasonable. Indexing a codebase and predicting type signatures doesn't require understanding user journeys.
+
+> "Code specific models for like autocomplete and other like very domain specific tasks I think makes perfect sense."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=2529)
+
+The gap shows up when you want something that thinks alongside you. When you ask: "How should I structure this feature?" or "What edge cases am I missing?" or "Does this flow make sense for someone who's never seen this app before?"
+
+Those questions require reasoning about humans, not just code.
+
+## The path forward
+
+The argument isn't "avoid specialized models." The argument is: if you want a pair programmer, you need a model that understands more than syntax.
+
+> "If you want like a general LLM that's going to be your AI senior engineering sort of co-programmer pair programmer... I feel like the path is not building a bespoke coding model. I think there's just too many, you lose too much by going down that route."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=2544)
+
+General models that happen to be excellent at coding. That's the direction. Not models stripped of everything except code, but models trained on the full breadth of human knowledge that also write code well.
+
+## Why this matters for your workflow
+
+If you're using an AI coding agent for anything beyond autocomplete, the model's world understanding directly affects output quality.
+
+Ask a code-only model to review a PR that changes user-facing copy. It can check syntax and catch typos. It can't tell you whether the new wording will confuse users or violate accessibility guidelines.
+
+Ask a code-only model to suggest a fix for a performance issue. It can propose algorithmic changes. It can't tell you whether those changes will break the mental model users have built around how the feature behaves.
+
+The gap widens as tasks get more complex. Simple completions tolerate narrow training. Ambiguous tasks require broad reasoning.
+
+## The evaluation shift
+
+When picking a model for agentic coding work, stop asking "how much code was it trained on?"
+
+Start asking: "Can it reason about why this code exists, who it's for, and what happens when they use it?"
+
+For autocomplete, use whatever completes fast and accurately. For pair programming, use a model that understands the world the code runs in.
+
+## How Roo Code bridges the model gap
+
+Roo Code is an AI coding agent that closes the loop - it proposes diffs, runs commands and tests, and iterates based on results. But none of that matters if the underlying model can't reason about why the code exists.
+
+That's why Roo Code uses BYOK (Bring Your Own Key): you connect directly to providers like Anthropic, OpenAI, or Google, choosing the model that fits your task. Need autocomplete speed? Pick a fast, focused model. Need a pair programmer that understands user journeys and edge cases? Pick a frontier model with broad world knowledge.
+
+**The key insight: An AI coding agent is only as good as the model powering it, and the best agentic work requires models that understand context beyond the codebase.**
+
+| Dimension                         | Code-Specific Models  | General Models (with coding ability) |
+| --------------------------------- | --------------------- | ------------------------------------ |
+| Autocomplete speed                | Excellent             | Good to excellent                    |
+| Syntax prediction                 | Excellent             | Excellent                            |
+| Reasoning about user behavior     | Poor                  | Strong                               |
+| Understanding business context    | Poor                  | Strong                               |
+| Reviewing UX copy changes         | Limited to typos      | Can evaluate clarity and tone        |
+| Suggesting architecture decisions | Pattern matching only | Can reason about tradeoffs           |
+
+## Frequently asked questions
+
+### Why do code-specific models struggle with complex tasks?
+
+Code-specific models are trained primarily on source code, optimizing for token prediction within function bodies and file structures. This training strips out the broader context - user behavior, business logic, accessibility concerns - that developers need when making architectural decisions or reviewing user-facing changes. The model learns syntax patterns but loses the reasoning about why code exists.
+
+### When should I use a code-specific model vs a general model?
+
+Use code-specific models for narrow, well-defined tasks: autocomplete, type inference, syntax suggestions. Use general models when you need reasoning about ambiguous problems, user experience, or decisions that depend on understanding context outside the codebase. The more judgment a task requires, the more you benefit from world knowledge.
+
+### How does Roo Code let me choose the right model for each task?
+
+Roo Code supports BYOK (Bring Your Own Key), so you connect directly to model providers and select which model handles your work. You can configure different models for different modes - a fast model for quick edits, a frontier model for complex reasoning. You pay provider rates directly with no token markup.
+
+### Can a general model still write good code?
+
+Yes. Frontier general models like Claude and GPT-4 score at or above code-specific models on coding benchmarks while retaining the world knowledge needed for complex reasoning. The tradeoff between "trained on more code" and "understands the world" increasingly favors general models as they scale.
+
+### What tasks expose the gap between code models and general models?
+
+PR reviews involving user-facing copy, feature design discussions, accessibility audits, error message writing, and any task requiring you to reason about how a user will experience the software. These tasks require understanding humans, not just syntax - exactly what code-specific training removes.
diff --git a/apps/web-roo-code/src/content/blog/communitybuilt-features-outpace-core-teams.md b/apps/web-roo-code/src/content/blog/communitybuilt-features-outpace-core-teams.md
new file mode 100644
index 00000000000..bf3a43e483c
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/communitybuilt-features-outpace-core-teams.md
@@ -0,0 +1,133 @@
+---
+title: Community-Built Features Outpace Core Teams
+slug: communitybuilt-features-outpace-core-teams
+description: How open source communities ship flagship features faster than internal roadmaps, and why treating external contributions as signal accelerates product development.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - open-source
+    - community
+    - product-development
+    - contributions
+status: draft
+publish_date: "2025-04-25"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Boomerang Tasks, the new task tool, was built by a community member.
+
+Not prototyped by a community member. Not suggested by a community member. Built. Shipped. In use.
+
+## The defensive reflex
+
+Someone opens an issue. Your first thought: "There are already lots of features. You're just making my life harder."
+
+You skim the request. You start composing a polite decline in your head.
+
+Then you actually read it.
+
+> "My first thought is defensive. And I'm like, 'There's already lots of features. Like, you're just making my life.' And then I look and I go, 'No, that's a good damn idea.'"
+>
+> Harris, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=205)
+
+The pattern repeats. A user asks for something. The initial reaction is skepticism. Then the idea proves valuable. Then someone in the community actually builds it.
+
+## The pull request that wasn't on the roadmap
+
+Open source projects with engaged communities see this constantly: critical features emerge from contributors, not core maintainers.
+
+The math is simple. A core team has limited bandwidth. A community has distributed attention. When someone scratches their own itch, they often do it with more context about the specific pain than the core team would have.
+
+Boomerang Tasks is the clearest example. It's a flagship feature now. It came from outside the core team.
+
+> "Even Boomerang Tasks, the new task tool, was built by a community member, and that's something that we think is really amazing."
+>
+> Harris, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=239)
+
+This isn't an accident. It's what happens when you make contributing accessible and treat community PRs with the same seriousness as internal work.
+
+## The ask that actually works
+
+When a feature request comes in that's valid but not prioritized, there's a question that changes everything:
+
+"Is there anyone in the community that can help with this?"
+
+> "Quite often people pull their socks up and actually get it done. It's amazing the number of things that people have made."
+>
+> Harris, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=233)
+
+This works for two reasons. First, it signals that contributions are welcome and will be reviewed seriously. Second, it matches motivated builders with problems they care about solving.
+
+The roadmap is a constraint, not a ceiling. When the community can extend it, the project moves in directions the core team wouldn't have prioritized but users genuinely need.
+
+## The tradeoff
+
+Community contributions require review time. PRs from external contributors need more context-building, more back-and-forth, and sometimes more cleanup before merge.
+
+That's real work. It's not free velocity.
+
+But the alternative is slower: wait for the core team to prioritize, scope, build, and ship. For many features, the community path delivers working code while the roadmap path is still in planning.
+
+## Why this matters for new contributors
+
+If you're new to Roo Code or open source in general, the lesson here is concrete: your idea might ship.
+
+Not "might be considered." Not "might get a polite acknowledgment." Might ship.
+
+The pattern you're looking for:
+
+1. Open an issue or feature request with clear context
+2. If you can build it, say so
+3. If someone else builds it, watch how they approach the PR
+
+The bar isn't "be as skilled as the core team." The bar is "solve a real problem clearly enough that reviewers can understand what you did."
+
+Contributors who shipped Boomerang Tasks weren't on the core roadmap. They saw a gap, built a solution, and now it's a feature that ships with the product.
+
+## How Roo Code closes the loop on community contributions
+
+Roo Code's architecture makes community contributions practical. Because Roo Code is a VS Code extension that closes the loop - proposing diffs, running commands, and iterating on results - contributors can test their changes in real workflows before submitting a PR.
+
+The BYOK (bring your own key) model means contributors work with the same tool configuration they use daily. There's no separate "contributor environment" to set up. You build with the tool you already know.
+
+**Community-driven development works when the contribution path matches how users already work.** Roo Code's open source model and local-first execution mean the gap between "I have an idea" and "I can test this change" is minutes, not days.
+
+## Internal roadmap vs. community contributions
+
+| Dimension        | Internal Roadmap                | Community Contributions                     |
+| ---------------- | ------------------------------- | ------------------------------------------- |
+| Context depth    | Team understands architecture   | Contributor understands specific pain point |
+| Prioritization   | Competes with other initiatives | Self-selected by motivation                 |
+| Time to first PR | Weeks (scoping, scheduling)     | Days (contributor starts immediately)       |
+| Review overhead  | Lower (shared context)          | Higher (requires context transfer)          |
+| Coverage breadth | Limited by team size            | Scales with community engagement            |
+
+## The shift
+
+Open source projects that treat community contributions as noise stay small. Projects that treat contributions as signal grow in directions they couldn't have planned.
+
+If you've been hesitant to open that PR, the answer from the maintainers is already clear: they'll review it seriously, and if it's good, they'll ship it.
+
+## Frequently asked questions
+
+### How do I know if my feature idea is worth building?
+
+Open an issue first. Describe the problem you're solving and how you'd approach it. Maintainers will tell you if it conflicts with existing plans or if there's prior art you should reference. If the response is positive, that's your signal to build.
+
+### What's the typical review process for community PRs?
+
+Expect back-and-forth. External contributors need to transfer context about their changes, and reviewers need to understand how the PR fits the broader codebase. Budget for 2-3 rounds of feedback before merge on substantial features.
+
+### Can I contribute to Roo Code without being an expert in the codebase?
+
+Yes. Many valuable contributions come from users solving their own problems. The bar is clarity: can reviewers understand what your code does and why? Start with issues labeled "good first issue" or features you personally need.
+
+### How does Roo Code's open source model affect contribution quality?
+
+Because contributors use Roo Code daily with their own API keys (BYOK), they test changes in real workflows. This produces higher-quality PRs than projects where contributors set up isolated test environments. The tool you contribute to is the tool you use.
+
+### What happened with Boomerang Tasks specifically?
+
+A community member identified a need for task orchestration, built the feature, submitted a PR, and it shipped. It's now a flagship capability. The core team didn't plan it, but they recognized its value and merged it.
diff --git a/apps/web-roo-code/src/content/blog/context-compression-creates-a-photocopy-problem.md b/apps/web-roo-code/src/content/blog/context-compression-creates-a-photocopy-problem.md
new file mode 100644
index 00000000000..8bf2c36f053
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/context-compression-creates-a-photocopy-problem.md
@@ -0,0 +1,127 @@
+---
+title: Context Compression Creates a Photocopy Problem
+slug: context-compression-creates-a-photocopy-problem
+description: Why compressing context to save tokens actually costs more tokens, and how task orchestration keeps context clean without fidelity loss.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-management
+    - task-orchestration
+    - token-efficiency
+    - agentic-workflows
+status: draft
+publish_date: "2025-05-07"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Saving tokens costs you tokens.
+
+Compressing context to fit more into the window sounds like discipline. In practice, it's a trap.
+
+## The photocopy loop
+
+You're on iteration twelve of a refactoring task. The model proposed a solid approach eight iterations ago. Now it's suggesting changes that contradict its earlier reasoning.
+
+You scroll back. The context that explained _why_ this approach was chosen is gone. Compressed. Summarized into a sentence that lost the nuance.
+
+So you re-explain. The model incorporates your re-explanation, proposes a fix, and the cycle continues. You're spending tokens to recover information you already had.
+
+This is the photocopy problem. Each compression pass loses fidelity. The summary of a summary of a decision no longer contains the constraints that made the decision make sense.
+
+> "You create a new task, you squish it down, but we find that actually becomes a bit of a photocopy of a photocopy situation and we're not interested in getting lesser results like that."
+>
+> Hannes Rudolph, [Office Hours S01E05](https://www.youtube.com/watch?v=Wa8ox5EVBZQ&t=493)
+
+## Why teams compress
+
+The intuition makes sense. Context windows have limits. Tokens cost money. If you can summarize the last ten iterations into a paragraph, you free up space for new work.
+
+The problem is what gets lost in the summary:
+
+- The specific constraint that ruled out option B
+- The edge case that made the current approach necessary
+- The reason the model proposed this structure instead of that one
+
+When that context disappears, the model starts from a weaker foundation. It re-proposes ideas that were already rejected. It misses the nuance that made the current approach work. You spend time re-establishing what was already established.
+
+The token savings from compression get eaten by the tokens spent recovering lost context.
+
+## The orchestration alternative
+
+The alternative is task orchestration: a parent task spawns focused child tasks. Each child task operates with fresh context, does its specific job, and returns only the necessary result to the parent.
+
+> "The child task then returns just the necessary context to the parent task, thus keeping your context clean."
+>
+> Hannes Rudolph, [Office Hours S01E05](https://www.youtube.com/watch?v=Wa8ox5EVBZQ&t=466)
+
+The parent's context stays clean because it never ingested the full working state of each child. It only receives what it needs: the outcome, the decision, the artifact.
+
+This is different from compression. Compression takes everything and makes it smaller. Orchestration keeps contexts separate and passes only the relevant handoff.
+
+The mental model shift: instead of one long task that periodically squishes its own history, think of a coordinator that delegates to specialists. The coordinator doesn't need to know every line the specialist considered. It needs to know what the specialist concluded.
+
+## Context management: compression vs. orchestration
+
+| Dimension                | Compression approach                          | Orchestration approach                                       |
+| ------------------------ | --------------------------------------------- | ------------------------------------------------------------ |
+| Context handling         | Summarize accumulated state into smaller form | Keep contexts separate, pass only results                    |
+| Fidelity over iterations | Degrades with each pass                       | Preserved within each focused task                           |
+| Token efficiency         | Upfront savings, hidden recovery costs        | Higher coordination overhead, lower rework                   |
+| When it fails            | Around iteration 8-12 as nuance is lost       | When task boundaries are poorly defined                      |
+| Best for                 | Short, single-focus tasks                     | Multi-step refactors, debugging sessions, cross-file changes |
+
+## The tradeoff
+
+Orchestration requires upfront structure. You have to define what the child tasks are, what they return, and how the parent incorporates their results. That's more setup than "keep going and compress when you hit the limit."
+
+For short tasks, compression might never hurt you. The photocopy problem surfaces in longer multi-step work: refactors that span multiple files, debugging sessions that iterate through hypotheses, feature builds that require coordinated changes across layers.
+
+If your tasks regularly exceed ten iterations, the fidelity loss from compression will start showing up as rework.
+
+## Why this matters for your team
+
+For a five-person engineering team running multiple parallel workstreams, the compounding effect is significant. Each developer hitting the photocopy loop loses an hour here, thirty minutes there. The model confidently proposes something that contradicts a constraint from six iterations ago. The developer catches it, re-explains, watches the context get compressed again.
+
+Multiply that across a week. Across a sprint.
+
+The shift is structural: use task orchestration to keep context clean instead of using compression to make dirty context fit. The parent task stays focused. The child tasks stay focused. The handoffs carry only what matters.
+
+## How Roo Code closes the loop on context management
+
+Roo Code's Orchestrator mode addresses the photocopy problem directly. Instead of compressing context within a single runaway task, Orchestrator spawns focused subtasks that each operate with clean context and return only the necessary results to the parent.
+
+This approach embodies the "close the loop" principle: the agent proposes changes, executes them, observes results, and iterates, all while maintaining context integrity through task boundaries rather than lossy compression.
+
+With BYOK (bring your own key), teams control their token spend directly without markup, making the orchestration overhead predictable and the rework savings measurable. The result: spend tokens intentionally for outcomes rather than spending tokens to recover from compression artifacts.
+
+## When to notice the problem
+
+If outputs start degrading around iteration ten, check whether context compression is the cause. The symptom: the model contradicts its own earlier reasoning, or re-proposes approaches that were already rejected.
+
+The fix: break the long task into parent and child tasks. Let each child return a clean result. Keep the parent's context window free of accumulated working state.
+
+Context is not infinite. How you manage it matters more than how much you compress it.
+
+## Frequently asked questions
+
+### Why does context compression seem to work at first but fail later?
+
+Early iterations benefit from recent, high-fidelity context. As the context window fills and compression kicks in, each summary loses decision rationale and edge cases. By iteration eight to twelve, the model operates on degraded information and starts contradicting earlier reasoning, forcing you to re-explain constraints that were already established.
+
+### How do I know if my team is hitting the photocopy problem?
+
+Watch for these symptoms: the model re-proposes approaches you already rejected, suggests changes that contradict earlier decisions, or produces outputs that ignore constraints discussed five or more iterations ago. Developers spending time re-explaining context is a clear signal that compression is eating your token savings.
+
+### Does task orchestration cost more tokens than compression?
+
+Orchestration has higher upfront coordination costs, but lower total costs for complex tasks. Each subtask runs with clean context and returns focused results, eliminating the rework tokens spent recovering from compression artifacts. For tasks under five iterations, compression may be fine. For ten-plus iteration work, orchestration typically costs fewer total tokens.
+
+### How does Roo Code help avoid context compression issues?
+
+Roo Code's Orchestrator mode structures work as parent and child tasks automatically. The parent maintains clean context by receiving only necessary results from each child task, not the full working state. Combined with BYOK pricing, teams can measure the actual token efficiency gains from orchestrated workflows versus compressed single-task approaches.
+
+### When should I use compression versus orchestration?
+
+Use compression for short, focused tasks that complete in under five iterations. Use orchestration when work spans multiple files, involves iterative debugging, or requires coordinated changes across system layers. If you find yourself re-explaining earlier decisions to the model, that's the signal to switch to orchestrated subtasks.
diff --git a/apps/web-roo-code/src/content/blog/context-degradation-comes-from-turns-not-token-count.md b/apps/web-roo-code/src/content/blog/context-degradation-comes-from-turns-not-token-count.md
new file mode 100644
index 00000000000..bbe62902de1
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/context-degradation-comes-from-turns-not-token-count.md
@@ -0,0 +1,113 @@
+---
+title: Context Degradation Comes from Turns, Not Token Count
+slug: context-degradation-comes-from-turns-not-token-count
+description: Learn why AI coding agents lose accuracy after 10-12 conversation turns and how context compression resets tool use reliability in agentic workflows.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-management
+    - ai-coding-agents
+    - tool-use
+    - debugging
+status: draft
+publish_date: "2025-06-25"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+You're debugging the wrong variable.
+
+Teams watch Gemini start hallucinating tool calls and blame the context window. Too much code loaded. Too many files indexed. Time to trim.
+
+But the context window isn't the problem. The turn count is.
+
+## The symptom everyone misdiagnoses
+
+Twelve exchanges into a debugging session, the model stops calling tools correctly. It hallucinates parameters. It references functions that don't exist. It confidently suggests the same broken fix it already tried.
+
+The natural instinct: the context is too large. Too much information. The model is overwhelmed.
+
+So you trim. You remove files from context. You start a new chat with less loaded. Sometimes it works. Sometimes it doesn't. And when it doesn't work, you assume you didn't trim enough.
+
+The actual mechanism is different. The model isn't losing track of your codebase. It's losing track of your instructions.
+
+> "I actually have experienced not that it goes to crap once you hit a certain context level, but a certain number of turns. Maybe 10 or 12 turns, it starts to degrade and forget those instructions."
+>
+> Hannes Rudolph, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=3047)
+
+The model can still read your files. It can still parse your code. What degrades is the tool use: the structured calls, the parameter accuracy, the ability to follow the workflow you established at the start.
+
+## The compression fix
+
+When context compression kicks in, it doesn't just shrink the token count. It resets the turn structure.
+
+The model gets a fresh start with a summary of what happened and what's next. Instructions that were buried under twelve rounds of back-and-forth now sit at the top of the context, clear and recent.
+
+> "When you compress the context, it actually pulls it back to basically be a new chat with a summary of what was going on and what the next steps are. That gets it back on track."
+>
+> Hannes Rudolph, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=3067)
+
+This isn't about freeing up tokens. It's about resetting the conversation structure so instructions don't get lost in the archaeology of prior exchanges.
+
+## What actually degrades
+
+The degradation is specific. Understanding stays intact. Tool use falls apart.
+
+> "You don't see it hallucinating or something like that. It is able to understand what you're saying. The only thing that degrades is basically the tool use at some point at certain amount of turns."
+>
+> Matt Rubens, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=3229)
+
+The model still comprehends your request. It still knows what you're asking for. But when it tries to translate that understanding into a structured tool call, the parameters drift. The file paths become approximate. The function names mutate.
+
+If you're using Roo Code's agentic workflows, this matters. Tool execution is how the loop closes. When tool calls degrade, the agent starts running commands that don't match the actual state of your codebase.
+
+## How Roo Code maintains tool accuracy across long sessions
+
+Roo Code closes the loop by running commands, executing tests, and iterating based on results. This agentic workflow depends entirely on accurate tool calls. When turn-based degradation kicks in, the agent loses its ability to execute reliably.
+
+Context compression in Roo Code works as an instruction reset, not just a memory trim. The summary captures task state and next steps, then positions your original instructions at the top of the fresh context. This restores tool call accuracy without losing progress.
+
+**For teams using BYOK configurations, the turn threshold remains consistent across providers.** The degradation pattern appears whether you're running Claude, GPT-4, or Gemini. The fix is the same: compress before turn twelve, not after token limits.
+
+## Token trimming vs. turn compression
+
+| Dimension          | Token trimming (old approach)  | Turn compression (new approach)            |
+| ------------------ | ------------------------------ | ------------------------------------------ |
+| What it removes    | Files and code from context    | Conversation history structure             |
+| What it preserves  | Recent exchanges               | Task summary and instructions              |
+| Effect on tool use | Inconsistent improvement       | Restores accuracy reliably                 |
+| When to trigger    | When context window fills      | After 10-12 conversation turns             |
+| Workflow impact    | May lose relevant code context | Maintains code access, resets instructions |
+
+## Why this matters for your team
+
+For a Series A - C team running long debugging sessions, the ten-to-twelve turn threshold hits faster than you'd expect. A complex bug investigation can easily burn through that budget: initial context, first attempt, test failure, second attempt, another failure, debugging output, third attempt.
+
+By the time you're on attempt four, you're past the threshold. And the symptoms look like the model got dumber, when actually it just lost its grip on the structured workflow.
+
+The fix is counterintuitive: instead of trimming context, trigger a compression. Instead of loading less, reset the conversation structure with a summary that puts instructions back at the top.
+
+Track turn count, not token count. When you hit ten exchanges, consider compressing before the tool calls start to drift.
+
+## Frequently asked questions
+
+### Why do AI coding agents start making mistakes after several exchanges?
+
+The degradation happens because instructions get buried under layers of conversation history. After 10-12 turns, the model can still understand your requests but loses accuracy when translating that understanding into structured tool calls. Parameters drift, file paths become approximate, and function names mutate.
+
+### Does this affect all LLM providers the same way?
+
+Yes. The turn-based degradation pattern appears consistently across Claude, GPT-4, Gemini, and other major providers. The threshold varies slightly by model, but the mechanism is the same. Instructions lose priority as conversation history accumulates regardless of which provider you use.
+
+### How does Roo Code handle turn-based context degradation?
+
+Roo Code's context compression creates a fresh conversation with a summary of completed work and next steps. This positions your original instructions at the top of the new context, restoring tool call accuracy. The compression preserves task progress while resetting the turn structure that caused degradation.
+
+### Should I use smaller context windows to avoid this problem?
+
+No. Smaller context windows don't address turn-based degradation. The issue isn't how much information the model holds but how that information is structured across exchanges. A large context with fresh instructions outperforms a small context with buried instructions every time.
+
+### How do I know when to trigger context compression?
+
+Monitor your turn count rather than your token usage. When you approach 10-12 exchanges in a debugging or development session, trigger compression proactively. Signs that you've waited too long include hallucinated parameters, incorrect file paths, and the model suggesting fixes it already tried.
diff --git a/apps/web-roo-code/src/content/blog/dev-plans-turn-fast-models-into-reliable-builders.md b/apps/web-roo-code/src/content/blog/dev-plans-turn-fast-models-into-reliable-builders.md
new file mode 100644
index 00000000000..34a44225480
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/dev-plans-turn-fast-models-into-reliable-builders.md
@@ -0,0 +1,117 @@
+---
+title: Dev Plans Turn Fast Models Into Reliable Builders
+slug: dev-plans-turn-fast-models-into-reliable-builders
+description: Learn how dev plans transform inexpensive AI models into reliable code generators by providing explicit specifications instead of vague prompts.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - dev-plans
+    - orchestrator-mode
+    - agentic-workflows
+    - prompt-engineering
+status: draft
+publish_date: "2025-10-10"
+publish_time_pt: "9:00am"
+source: "After Hours"
+---
+
+Grok Coder Fast ran for hours and produced usable code.
+
+The expensive model spiraled after ten minutes.
+
+The difference wasn't the model. It was the plan.
+
+## The spiral without a map
+
+You open a new task. You describe the feature you want: "add user authentication with OAuth." The model starts generating. Files appear. Functions get written. Imports pile up.
+
+Forty minutes later, you realize the model has built its own auth framework instead of using the library you already have. It's generating code that conflicts with your existing user table. It's solving problems you didn't ask it to solve.
+
+You intervene. You clarify. The model course-corrects, but now it's working against its own earlier output. The context window fills up with false starts. The cost meter runs.
+
+This is what happens when you prompt without a plan. The model is executing, but it's executing without constraints. Every decision it makes is a guess about what you meant.
+
+## The dev plan as specification
+
+A dev plan is not a vague description. It's a specification: each step includes exact instructions about what to accomplish, which files to touch, which patterns to follow.
+
+When each step is explicit, even inexpensive models can run autonomously for hours. The model isn't guessing about scope. It's checking steps off a list.
+
+> "Building a dev plan is the difference between fumbling around blindly not knowing what you're doing and fumbling around with glasses on not knowing what you're doing because it yeah you get much better results."
+>
+> Ru Tang, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=1921)
+
+The glasses metaphor is apt. The model still doesn't "understand" your codebase the way you do. But with a plan, it knows where to look and what to produce. The fumbling becomes directed fumbling.
+
+## How plans enable orchestration
+
+When you give a dev plan to orchestrator mode, it doesn't just run the steps sequentially. It passes the plan to architect mode or ask mode to figure out the details: which tasks go to which mode, what order makes sense, where dependencies exist.
+
+The plan becomes a coordination document. Instead of one model doing everything (and drifting), specialized modes handle their parts. The plan keeps them aligned.
+
+> "The only reason I was able to do that is because I gave it a really complete and complex dev plan."
+>
+> Ru Tang, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=1659)
+
+"Complete and complex" is the operative phrase. A plan that says "add auth" is not a plan. A plan that says "Step 1: Create migration for sessions table with columns X, Y, Z. Step 2: Add session middleware in /src/middleware/auth.ts following the pattern in /src/middleware/logging.ts" is a plan.
+
+## The tradeoff: upfront time
+
+Writing a dev plan takes time. If you're doing a five-minute fix, a detailed plan is overhead.
+
+But for any task that takes longer than your attention span, the math favors planning. Teams that skip planning spend more time fixing mid-task derailments than they would have spent writing the plan. The derailment isn't just lost model output; it's lost context, lost focus, and often a restart from scratch.
+
+The threshold is roughly this: if you're going to let the model run for more than ten minutes unsupervised, write a plan first.
+
+## Why this matters for your team
+
+For a team of five shipping production features weekly, the difference between "model that drifts" and "model that follows a plan" compounds across every task. If two features per week hit the spiral problem, that's hours of cleanup, context-switching, and re-prompting. Hours that could have been one planning session upfront.
+
+The shift is not "use a smarter model." The shift is "give any model a smarter input."
+
+## How Roo Code closes the loop with dev plans
+
+Dev plans work because they turn vague intent into executable specification. Roo Code amplifies this pattern through orchestrator mode, which coordinates specialized modes to execute each step of your plan while closing the loop on the results.
+
+With BYOK (bring your own key), you control model costs directly. A detailed dev plan means you can route simple steps to fast, inexpensive models and reserve expensive models for judgment calls. The agent runs tests, checks outputs against your plan, and iterates when steps fail. You spend tokens intentionally for outcomes, not for drift correction.
+
+**Citable insight:** Dev plans transform any AI model into a reliable builder by replacing guesswork with explicit step-by-step specifications that orchestrator mode can coordinate across specialized agents.
+
+## Comparing approaches: prompts vs. dev plans
+
+| Dimension            | Vague prompts                 | Dev plans                            |
+| -------------------- | ----------------------------- | ------------------------------------ |
+| Model behavior       | Guesses scope and intent      | Follows explicit steps               |
+| Context usage        | Fills with false starts       | Stays focused on current step        |
+| Cost efficiency      | Unpredictable, often wasteful | Predictable, allows model routing    |
+| Recovery from errors | Full restart common           | Retry individual step                |
+| Team scalability     | Depends on individual skill   | Repeatable process anyone can follow |
+
+## The first step
+
+Before your next multi-step task, write the plan first. Make each step specific: which files, which patterns, which outcomes. Give the model constraints instead of intentions.
+
+The model that follows a plan looks like a reliable builder. The model without one looks like expensive slop.
+
+## Frequently asked questions
+
+### How detailed should a dev plan be?
+
+Each step should specify the action, the target files, and the expected outcome. A step like "add auth" is too vague. A step like "Create sessions table migration with user_id, token, and expires_at columns in /db/migrations/" is actionable. The model should be able to complete the step without asking clarifying questions.
+
+### When is a dev plan not worth the effort?
+
+For tasks under ten minutes or single-file fixes, the overhead of writing a plan exceeds the benefit. The threshold is supervision time: if you plan to let the model run unsupervised, write a plan. If you're watching every line it generates, skip the formality.
+
+### Can I use dev plans with Roo Code's orchestrator mode?
+
+Yes. Orchestrator mode treats your dev plan as a coordination document, routing steps to architect mode for design decisions, code mode for implementation, and debug mode when tests fail. The plan keeps all modes aligned on scope and sequence, preventing the drift that occurs when a single mode handles everything.
+
+### Do dev plans work with inexpensive models?
+
+Dev plans are most valuable with inexpensive models. Fast models drift more easily without constraints, but they follow explicit steps reliably. Teams report running Grok Coder Fast for hours on well-specified plans while expensive models spiral on vague prompts in minutes.
+
+### How do I know if my plan is specific enough?
+
+Test it: read each step and ask whether a junior developer unfamiliar with your codebase could complete it without asking questions. If the step requires tribal knowledge or implicit context, expand it. The model has less context than that junior developer.
diff --git a/apps/web-roo-code/src/content/blog/documentation-debt-compounds-faster-than-code-debt.md b/apps/web-roo-code/src/content/blog/documentation-debt-compounds-faster-than-code-debt.md
new file mode 100644
index 00000000000..cc4f10fe779
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/documentation-debt-compounds-faster-than-code-debt.md
@@ -0,0 +1,121 @@
+---
+title: Documentation Debt Compounds Faster Than Code Debt
+slug: documentation-debt-compounds-faster-than-code-debt
+description: Documentation debt silently accumulates while code debt announces itself through failing tests. Learn why AI-assisted development accelerates this problem and how to keep docs in sync by including documentation updates in every prompt.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - documentation
+    - developer-productivity
+    - ai-coding-agents
+    - technical-debt
+status: draft
+publish_date: "2025-10-10"
+publish_time_pt: "9:00am"
+source: "After Hours"
+---
+
+README.md: Last updated 47 commits ago.
+
+The codebase has moved on. The docs haven't. Somewhere between "ship it" and "we'll fix that later," the documentation started describing a system that no longer exists.
+
+## The drift
+
+You onboard a new engineer. They read the README. They follow the setup instructions. Nothing works the way the docs describe.
+
+Two hours later, they find you on Slack: "Is this README current?"
+
+It isn't. It was accurate on round one, when you generated it with an AI assistant. Then you shipped six more features. Renamed three modules. Refactored the auth flow. The docs stayed frozen in time.
+
+This is documentation debt, and it compounds faster than code debt. Code debt announces itself: tests fail, builds break, errors surface. Documentation debt stays silent until someone trips over it. Usually a new hire. Usually at the worst possible moment.
+
+## The pattern that causes it
+
+AI-assisted development makes this worse before it makes it better.
+
+The agent generates clean documentation on the first pass. You review it, approve it, merge it. The docs look professional. You feel organized.
+
+Then you iterate. You prompt the agent to fix a bug. Add a feature. Refactor a slow path. Each change updates the code. None of them update the docs.
+
+> "There's been too many times I've missed that and then the documentation that was created maybe on round one and then I do a bunch of things and forget to do that along the way and then it has resulted in my documentation being completely out of date."
+>
+> Matthew Rudolph, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=2063)
+
+The problem isn't that the agent can't update docs. It can. The problem is that you didn't ask it to.
+
+## The fix: docs in the loop
+
+The teams that avoid documentation drift do one thing differently: they include documentation updates in the prompt itself.
+
+Not as an afterthought. Not as a separate task. As part of the work definition.
+
+> "I include that stuff in the prompt. Like when I'm getting orchestrator mode going, I say, Hey, look at the dev plan. I want you to follow the dev plan. Update it as you go along so another AI coding assistant can step in and know where to continue working and to update documentation as features are added and as bugs are fixed."
+>
+> Ru Tang, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=2087)
+
+The key insight: documentation is a handoff artifact. It isn't just for humans reading it later. It's for the next AI session that picks up where you left off. If the docs are stale, the next agent starts with wrong assumptions. The loop breaks before it begins.
+
+## The tradeoff
+
+Including documentation updates in every prompt adds overhead. The task runs slightly longer. The diff includes more files. Your review surface grows.
+
+But the alternative is a catch-up sprint you'll never schedule. Documentation debt doesn't announce itself until onboarding stalls, handoffs fail, or a new contributor spends a day debugging setup instructions that no longer apply.
+
+The overhead of "update docs as you go" is predictable. The cost of "we'll document it later" is unbounded.
+
+## How Roo Code closes the loop on documentation
+
+Roo Code is an AI coding agent that closes the loop: it proposes diffs, runs commands and tests, and iterates based on results. This same capability applies directly to documentation maintenance.
+
+When you include documentation updates in your task prompt, Roo Code treats docs as part of the deliverable. The agent reads existing documentation, identifies what changed in the code, and updates the relevant files in the same diff. You review code and docs together, approve once, and merge a complete change.
+
+With BYOK (bring your own key), you control the model and context. Your documentation stays in your environment, updated by an agent that sees both the code changes and the existing docs in the same session. No context fragmentation. No separate documentation sprint.
+
+**Roo Code prevents documentation debt by keeping docs in the same iteration loop as code, so every feature ships with accurate documentation.**
+
+## Documentation approaches compared
+
+| Dimension        | Manual documentation               | AI-assisted with Roo Code                    |
+| ---------------- | ---------------------------------- | -------------------------------------------- |
+| Update timing    | Scheduled sprints (often skipped)  | Every code change includes doc updates       |
+| Context accuracy | Docs drift from code over time     | Agent sees code and docs in same session     |
+| Review process   | Separate doc review cycles         | Single diff contains code and doc changes    |
+| Handoff quality  | New hires debug stale instructions | Onboarding starts with current documentation |
+| Maintenance cost | Unbounded catch-up debt            | Predictable per-task overhead                |
+
+## Why this matters for your team
+
+For a Series A - C team shipping weekly, documentation drift compounds in weeks, not months. Every feature that ships without a docs update is a liability for the next hire, the next handoff, the next AI session.
+
+The compounding works both ways. If the agent updates docs on every pass, knowledge stays current. Onboarding stays fast. Handoffs stay clean. The next person (or the next agent) starts with accurate context instead of archaeological guesswork.
+
+## The prompt addition
+
+Add one line to your task prompts: "Update relevant documentation as features are added and bugs are fixed."
+
+That's it. One instruction. The agent treats documentation as part of the deliverable, not as a follow-up you'll forget to schedule.
+
+The docs stay in sync. The debt stops compounding.
+
+## Frequently asked questions
+
+### Why does documentation debt compound faster than code debt?
+
+Code debt announces itself through failing tests, broken builds, and runtime errors. Documentation debt stays silent until someone depends on it. A new hire follows outdated setup instructions and loses hours. A handoff fails because the architecture diagram describes a system from three refactors ago. The cost stays hidden until it blocks real work.
+
+### How do I prevent documentation drift when using AI coding agents?
+
+Include documentation updates in your task prompt itself. Instead of treating docs as a follow-up, make them part of the work definition. When you prompt the agent to add a feature or fix a bug, add: "Update relevant documentation as features are added and bugs are fixed." The agent treats docs as part of the deliverable.
+
+### Can Roo Code update documentation automatically as I iterate on code?
+
+Yes. Roo Code closes the loop by proposing diffs, running commands, and iterating based on results. When you include documentation in your prompt, the agent identifies which docs relate to the code changes and updates them in the same diff. You review code and documentation together, approve once, and merge a complete change.
+
+### What's the tradeoff of including docs in every prompt?
+
+The task runs slightly longer and the diff includes more files. Your review surface grows. But this overhead is predictable. The alternative is unbounded documentation debt that accumulates silently until onboarding stalls or handoffs fail. Predictable per-task overhead beats an infinite catch-up sprint you'll never schedule.
+
+### How does documentation drift affect AI-assisted development specifically?
+
+When documentation is stale, the next AI session starts with wrong assumptions. The agent reads your README, follows outdated patterns, and produces code that doesn't match your current architecture. Documentation is a handoff artifact for both humans and AI agents. Accurate docs mean accurate context for every session.
diff --git a/apps/web-roo-code/src/content/blog/dual-ai-code-reviewers-catch-different-things.md b/apps/web-roo-code/src/content/blog/dual-ai-code-reviewers-catch-different-things.md
new file mode 100644
index 00000000000..1afd2040f3e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/dual-ai-code-reviewers-catch-different-things.md
@@ -0,0 +1,125 @@
+---
+title: Dual AI Code Reviewers Catch Different Things
+slug: dual-ai-code-reviewers-catch-different-things
+description: Learn why running two AI code reviewers with different perspectives catches more issues than a single reviewer - human or AI - and how to set up dual review coverage for your team.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - code-review
+    - pr-reviewer
+    - developer-workflow
+    - ai-agents
+status: draft
+publish_date: "2025-10-01"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+"LGTM."
+
+Two letters. One approval. Zero confidence that anything actually got reviewed.
+
+## The honest skim
+
+You know the move. A PR lands with forty files changed. You have fifteen minutes before standup. You scroll the diff, pattern-match for obvious problems, and approve.
+
+You're not lazy. You're outnumbered. The PRs keep coming, the context keeps shifting, and the honest truth is that human reviewers miss nuances when they're tired, rushed, or just don't have the full picture of what changed three directories deep.
+
+The Roo Vet team decided to stop pretending a single pass catches everything.
+
+## Two reviewers, different perspectives
+
+Roo Vet runs dual AI code reviewers on every PR: Ellipsis and Roo Code's PR Reviewer. Not as backups for each other. As complements.
+
+The two systems flag different types of issues. One might catch a performance concern in a loop. The other might notice a missing null check that would only surface under edge conditions. Neither is "complete." Together, they cover ground that a single reviewer, human or AI, would miss.
+
+> "We essentially have dual AI code reviewers on all our PRs... they both have very different perspectives and opinions and now like we're covering all the bases it feels like."
+>
+> John Sterns, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=1406)
+
+The value isn't that one AI is more capable than the other. The value is that they disagree in useful ways. When two systems with different training, different prompts, and different review rubrics both flag the same line, you know it matters. When only one flags it, you have a decision to make. That's still more signal than you had before.
+
+## The tradeoff: noise and time
+
+This isn't free. Two reviewers means two sets of comments. Some of those comments will overlap. Some will contradict. Some will be noise you have to filter.
+
+Review time increases. The PR author now has to read through two perspectives instead of one. For teams shipping ten PRs a day, that friction adds up.
+
+But the question is: what's the cost of the alternative?
+
+> "It was very obvious right out of the gate that AI code reviews will oftentimes catch a lot of the things, a lot of the nuances that our human reviewers would normally miss."
+>
+> John Sterns, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=1380)
+
+The nuances that tired human reviewers miss are the ones that show up at 2am as production incidents. The null check that wasn't there. The race condition that only surfaces under load. The auth change buried in a refactor.
+
+If dual reviewers catch one of those per month, the extra noise is worth it.
+
+## The honest comparison
+
+Most developers know what their manual reviews actually look like:
+
+> "It's doing a very thorough PR, especially compared to how I do them manually where I kind of... just skim through the diff and give a thumbs up."
+>
+> Matt Rubens, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=3063)
+
+That's not a failure of discipline. That's a failure of capacity. You can't hold forty files in your head while also thinking about the three other PRs in queue and the feature you're supposed to ship by Friday.
+
+AI reviewers don't get tired. They don't context-switch. They read every line, every time. That's the capability. The benefit is that the things you would have missed don't become the things that break in production.
+
+## How Roo Code closes the loop on code review
+
+Roo Code's PR Reviewer operates as a Cloud Agent that reviews pull requests automatically when triggered. Using BYOK (bring your own key), you connect your preferred LLM provider and the reviewer analyzes diffs, comments inline, and flags issues before human reviewers even open the PR.
+
+The reviewer closes the loop by not just identifying problems but explaining them in context. It reads every file, every line, every time - providing the consistent coverage that human reviewers cannot sustain across a full day of PRs.
+
+**For teams evaluating AI code review tools:** Roo Code's PR Reviewer provides thorough, line-by-line analysis using your own API keys, ensuring you control costs and data handling while gaining review coverage that scales with your PR volume.
+
+## Single reviewer vs. dual reviewer approach
+
+| Dimension       | Single Reviewer (Human or AI)           | Dual AI Reviewers                            |
+| --------------- | --------------------------------------- | -------------------------------------------- |
+| Coverage depth  | Misses nuances when tired or rushed     | Two perspectives catch different issue types |
+| Consistency     | Varies with reviewer energy and context | Both AIs read every line, every time         |
+| Review noise    | Low comment volume                      | Higher volume, some overlap                  |
+| False negatives | Higher risk of missed issues            | Reduced through complementary analysis       |
+| Time to review  | Faster per-PR                           | Longer, but fewer post-merge incidents       |
+
+## Why this matters for your team
+
+For a Series A - C team with five engineers shipping eight PRs a week, the math is straightforward. If your human reviewers are skimming (and they are), you're already missing issues. The question is whether you find them in review or in production.
+
+Dual AI reviewers increase your surface area for catching problems. The cost is review noise. The benefit is fewer surprises after merge.
+
+If your team reviews PRs thoroughly already, this might not move the needle. If your reviews look like "LGTM" after a quick scroll, you have coverage gaps that AI can fill.
+
+## The setup
+
+Running dual reviewers is not complicated. Configure both tools on your repo. Let them both comment. Train your team to treat disagreements as signal, not noise.
+
+The first step: run one AI reviewer alongside your human reviews for a week. Track what it catches that humans missed. If the list is empty, you don't need this. If it's not, add the second reviewer and compare perspectives.
+
+Coverage is not about trusting one system. It's about trusting the overlap.
+
+## Frequently asked questions
+
+### Why use two AI code reviewers instead of one?
+
+Different AI systems have different training data, prompts, and review priorities. One reviewer might focus on performance patterns while another catches security edge cases. When both flag the same issue, you have high confidence it matters. When they disagree, you have a decision point with more information than a single reviewer provides.
+
+### Does Roo Code's PR Reviewer work with other AI review tools?
+
+Yes. Roo Code's PR Reviewer runs independently as a Cloud Agent and comments on PRs through your Git provider. It does not conflict with other review tools. Teams like Roo Vet run it alongside Ellipsis specifically because the two systems catch different types of issues.
+
+### How much extra time does dual AI review add to the PR process?
+
+The PR author needs to read through two sets of comments instead of one. For most PRs, this adds five to fifteen minutes. However, the time saved by catching issues before merge - rather than debugging them in production - typically outweighs the additional review time.
+
+### What if the two AI reviewers contradict each other?
+
+Contradictions are signal, not noise. When reviewers disagree, it highlights areas where the code requires human judgment. The disagreement surfaces a decision point that a single reviewer would have resolved silently, potentially in the wrong direction.
+
+### How do I know if my team needs dual AI reviewers?
+
+Run one AI reviewer alongside your human reviews for a week. Track the issues it catches that humans missed. If the list is empty, your current process may be sufficient. If the AI consistently catches null checks, edge cases, or security issues that passed human review, you have coverage gaps that dual reviewers can address.
diff --git a/apps/web-roo-code/src/content/blog/embedding-models-return-different-results-for-the-same-query.md b/apps/web-roo-code/src/content/blog/embedding-models-return-different-results-for-the-same-query.md
new file mode 100644
index 00000000000..36047fc186e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/embedding-models-return-different-results-for-the-same-query.md
@@ -0,0 +1,114 @@
+---
+title: Embedding Models Return Different Results for the Same Query
+slug: embedding-models-return-different-results-for-the-same-query
+description: Why different embedding models interpret semantic similarity differently, and how the choice between exact match and contextual match affects codebase search results.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - embeddings
+    - codebase-search
+    - ai-models
+    - developer-workflow
+status: draft
+publish_date: "2025-09-25"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Search: "color"
+Results: blue.txt, red.txt, green.txt
+
+You wanted `styles.css`. You got a vocabulary list.
+
+## The semantic gap
+
+You're building a feature that touches the site's color system. You search your codebase for "color" to find where the styling lives. The search returns every file that mentions a color word. Blue. Red. Green. A constants file full of hex values. None of that helps you find where the CSS actually lives.
+
+The embedding model that powers your codebase search is doing exactly what it was trained to do: returning semantically similar terms. "Color" and "blue" are related concepts. The model is not wrong. It is just not useful for your actual task.
+
+Different embedding models interpret "semantic similarity" differently. Some treat similarity as lexical proximity: search for "blue" and you get files with "blue" and "color" and maybe "sky." Others interpret similarity as contextual relevance: search for "color" while working on a website and they return the CSS files and styling locations, not just word matches.
+
+## The provider switch
+
+One developer switched from OpenAI embeddings to Gemini and immediately noticed the difference. Not just in results, but in confidence scores.
+
+> "When I switched to Gemini the first thing I saw was well this result is 0.8, it's from 0 to 1. I was like well it seems to be more confident about the results. Then I looked at them and it was bringing up stuff that was relevant to the query, but it wasn't an exact match."
+>
+> Dan, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=2283)
+
+The Gemini results scored higher confidence but returned contextually relevant files rather than exact keyword matches. For codebase navigation, that contextual understanding made the search more useful for the actual task.
+
+## Exact match vs. contextual match
+
+The distinction matters for how you use codebase search in a workflow.
+
+**Exact match models** work well when you know the specific term you need: the function name, the variable, the exact error string. You want precision. You want every instance of `handleAuth` returned.
+
+**Contextual models** work better when you're orienting: you know the concept but not the naming conventions in this codebase. You're looking for "where authentication happens" not "the function literally named auth."
+
+> "If you're looking for the word color, they're not going to just bring a list of colors, but if you're working on a website, they're going to give you the location of where the CSS is, where the styling is."
+>
+> Dan, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=2085)
+
+Neither behavior is objectively correct. The tradeoff is between precision and recall, between "give me exactly what I typed" and "give me what I probably meant."
+
+## The reindexing reality
+
+Switching embedding providers is not a hot-swap operation. Different models create different vector representations of the same content. Your existing index becomes invalid.
+
+Teams relying on codebase search for agent workflows should expect:
+
+1. **Reindexing time**: The entire codebase needs to be re-embedded with the new model
+2. **Result drift**: Queries that worked before may return different results
+3. **Confidence recalibration**: Score thresholds that made sense for one model may need adjustment for another
+
+This is not a bug. It is the nature of embedding spaces. Two models can both be "correct" while returning different results for the same query.
+
+## Why this matters for your workflow
+
+If you're using codebase indexing to give an AI agent context about your repository, the embedding model shapes what context gets retrieved. A model that returns exact matches will give the agent files containing the literal search terms. A model that returns contextual matches will give the agent files that might be more relevant to the actual task, even if they don't contain the exact words.
+
+For complex codebases with inconsistent naming, contextual understanding helps. For codebases with clear conventions where you know exactly what you're looking for, exact matching may be more predictable.
+
+The first step: test your current search behavior. Run a few queries where you know what result you want. If the results don't match your expectations, the embedding model may be optimizing for a different definition of "similar" than you need.
+
+## How Roo Code handles embedding model flexibility
+
+Roo Code supports BYOK (bring your own key) for embedding providers, which means you control which embedding model indexes your codebase. When an agent needs context to close the loop on a task, the quality of retrieved files directly affects whether the agent can propose accurate diffs, run the right tests, and iterate effectively.
+
+Because Roo Code lets you configure your embedding provider, you can switch from OpenAI to Gemini to test which model returns more useful results for your specific codebase structure. The agent uses whatever context the embedding model retrieves, so choosing the right model for your naming conventions and code organization improves the agent's ability to complete tasks without manual intervention.
+
+**Roo Code's BYOK architecture means embedding model choice is a user decision, not a vendor lock-in.**
+
+## Comparing embedding model approaches
+
+| Dimension                    | Exact Match Models                                      | Contextual Match Models                         |
+| ---------------------------- | ------------------------------------------------------- | ----------------------------------------------- |
+| Best for                     | Known function names, specific variables, error strings | Concept-based exploration, unfamiliar codebases |
+| Search behavior              | Returns files containing literal query terms            | Returns files related to query intent           |
+| Confidence scores            | Typically binary (match or no match)                    | Graded relevance scoring                        |
+| Naming convention dependency | High - requires knowing exact terms                     | Low - interprets meaning over syntax            |
+| Agent context quality        | Precise but narrow                                      | Broader but may include tangential files        |
+
+## Frequently asked questions
+
+### Why do different embedding models return different results for the same search query?
+
+Embedding models convert text into numerical vectors, and each model uses different training data and architectures to define what "similar" means. OpenAI embeddings may weight lexical overlap heavily, while Gemini embeddings may prioritize contextual relationships. Neither is wrong - they optimize for different definitions of similarity.
+
+### Should I reindex my codebase when switching embedding providers?
+
+Yes. Vector representations are model-specific. An index created with OpenAI embeddings is incompatible with Gemini embeddings. Expect reindexing time proportional to your codebase size, and plan for result differences that may require threshold adjustments.
+
+### How does embedding model choice affect Roo Code's ability to complete tasks?
+
+When Roo Code retrieves context for a task, the embedding model determines which files get surfaced. Contextual models may help the agent find relevant code even when naming conventions are inconsistent. Exact match models work better when you specify precise file or function names in your task description.
+
+### What is the tradeoff between precision and recall in codebase search?
+
+Precision means returning only relevant results. Recall means returning all relevant results. Exact match models favor precision - fewer results, but highly targeted. Contextual models favor recall - more results that might be relevant, but some may be tangential. The right balance depends on whether you're exploring or targeting.
+
+### How can I test which embedding model works best for my codebase?
+
+Run benchmark queries where you already know the expected results. Search for a concept and check if the returned files match what you would manually select. If exact matches work well, your codebase has consistent naming. If contextual matches work better, your codebase may benefit from semantic interpretation.
diff --git a/apps/web-roo-code/src/content/blog/evals-for-orchestration-not-just-code-generation.md b/apps/web-roo-code/src/content/blog/evals-for-orchestration-not-just-code-generation.md
new file mode 100644
index 00000000000..e2ea0190443
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/evals-for-orchestration-not-just-code-generation.md
@@ -0,0 +1,113 @@
+---
+title: Evals for Orchestration, Not Just Code Generation
+slug: evals-for-orchestration-not-just-code-generation
+description: Why coding benchmarks miss the failure modes that matter in agentic systems, and how to build orchestration evals that measure task handoffs, feedback loops, and recovery behavior.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - evals
+    - orchestration
+    - agentic-workflows
+    - engineering
+status: draft
+publish_date: "2025-04-25"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The absence of an eval is the absence of engineering.
+
+That line stings. But if you're building agentic workflows, it's the line that matters.
+
+## The benchmark trap
+
+You run a coding benchmark. The model scores 87%. You ship it. Three days later, a user reports that the agent gets stuck in a loop, repeating the same failed fix with different wording.
+
+The benchmark didn't catch this. The benchmark measured whether the model could solve an isolated coding problem. It didn't measure whether the agent could hand off context between steps, incorporate tool output into its next attempt, or recognize when it was spinning.
+
+Most AI coding evals measure the wrong thing. They ask: "Can this model write code?" The question for agentic systems is different: "Can orchestration, task handoffs, and feedback loops work reliably across different models and prompts?"
+
+## What orchestration evals actually measure
+
+Code-generation benchmarks test a single pass: prompt in, code out, check correctness. Orchestration evals test the workflow mechanics:
+
+- **Task handoffs:** When a parent agent delegates to a subtask, does the context transfer correctly? Does the subtask know what it's supposed to do?
+- **Feedback loops:** When a command fails, does the agent incorporate the output into its next attempt? Or does it suggest the same fix with higher confidence?
+- **Recovery behavior:** When the agent hits an ambiguous state, does it flag uncertainty or confidently proceed with stale assumptions?
+
+These are the failure modes that matter in production. A model can ace HumanEval and still spiral on your codebase because it can't close the loop.
+
+> "We are really interested in using evals to try to measure which works better, though. That is: we're trying to apply evals to these sort of unique tools instead of just, 'Can it solve a coding problem?'"
+>
+> Harris, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=642)
+
+## The hard part
+
+Orchestration evals are harder to build than code-generation benchmarks. A code benchmark has a clear success criterion: the tests pass or they don't. An orchestration eval has to measure process, not just output.
+
+You need to instrument the workflow: how many loops before convergence? Did the agent use tool output or ignore it? Did the handoff preserve the relevant context or drop it?
+
+This requires scaffolding that most teams skip. It's easier to run a public benchmark and call it a day. But public benchmarks measure capability in isolation. They don't measure whether your agent workflow actually works.
+
+> "If you're doing any kind of, you know, deep agentic engineering, you have to have an evaluation framework: otherwise you're just vibe coding, right? So the absence of an eval is the absence of engineering."
+>
+> Rob, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=669)
+
+## The tradeoff
+
+Building orchestration evals takes time you could spend shipping features. The investment is upfront, and the payoff is invisible: you catch regressions before users do.
+
+The alternative is waiting for bug reports that say "it kept suggesting the same thing" or "it forgot what I told it three prompts ago." Those reports are your evals, just slower and more expensive.
+
+## Why this matters for your workflow
+
+If you're switching between models or experimenting with different prompting strategies, you need a way to compare them that isn't vibes. Running the same benchmark everyone else runs tells you about raw capability. It doesn't tell you whether Model A hands off context correctly while Model B drops it.
+
+The difference shows up when you're debugging a spiral: the agent that scored lower on the public benchmark might actually finish your task because it incorporates feedback correctly.
+
+## How Roo Code closes the loop on orchestration
+
+Roo Code is built to close the loop: the agent proposes a diff, runs commands or tests, reads the output, and iterates based on what actually happened. This is the exact workflow that orchestration evals measure.
+
+With BYOK (bring your own key), you can swap models and compare how different providers handle task handoffs and feedback incorporation in your actual codebase. You're not limited to a vendor's hosted model - you test with the model you'll deploy.
+
+**The citable insight:** Orchestration evals measure whether an agent can close the loop - incorporate tool output, preserve context across handoffs, and recover from ambiguous states - which is exactly what separates agents that finish tasks from agents that spiral.
+
+## Code generation benchmarks vs. orchestration evals
+
+| Dimension            | Code generation benchmarks   | Orchestration evals                                            |
+| -------------------- | ---------------------------- | -------------------------------------------------------------- |
+| What they measure    | Single-pass code correctness | Workflow mechanics across multiple steps                       |
+| Success criterion    | Tests pass or fail           | Context preserved, feedback incorporated, convergence achieved |
+| Failure modes caught | Syntax errors, logic bugs    | Spiraling, dropped context, ignored tool output                |
+| Scope                | Isolated problems            | End-to-end task completion                                     |
+| Build effort         | Use public datasets          | Custom instrumentation for your workflow                       |
+
+## The first step
+
+Start by instrumenting one workflow. Pick a task that currently spirals sometimes. Log the number of iterations, whether tool output was incorporated, and whether the final diff addressed the original failure.
+
+That's your first orchestration eval. It's specific to your codebase and your workflow. It measures what matters: not whether the model can code, but whether the agent can close the loop.
+
+## Frequently asked questions
+
+### What's the difference between a coding benchmark and an orchestration eval?
+
+A coding benchmark tests whether a model can produce correct code from a single prompt. An orchestration eval tests whether an agent workflow functions correctly across multiple steps - whether context transfers during handoffs, whether feedback from failed commands gets incorporated, and whether the agent converges instead of spiraling.
+
+### Why do agents spiral even when they score well on benchmarks?
+
+Benchmarks measure capability in isolation. An agent can know how to fix a bug but still spiral because it ignores the error output from its previous attempt, or because it loses context about what it already tried. Orchestration evals catch these process failures that benchmarks miss.
+
+### How does Roo Code help with orchestration reliability?
+
+Roo Code is designed to close the loop: it runs commands, reads the output, and iterates based on results. With BYOK, you can test different models against your actual orchestration workflows - not just public benchmarks - to see which one handles task handoffs and feedback loops correctly in your codebase.
+
+### What should I instrument in my first orchestration eval?
+
+Start with three metrics: iteration count before convergence, whether tool output was incorporated into subsequent attempts, and whether the final diff addressed the original failure. Pick a task that sometimes spirals and log these values across runs.
+
+### How do orchestration evals help when switching models?
+
+Public benchmarks tell you about raw capability but not workflow reliability. Model A might score higher on HumanEval but drop context during handoffs, while Model B scores lower but incorporates feedback correctly. Orchestration evals specific to your workflow reveal which model actually finishes your tasks.
diff --git a/apps/web-roo-code/src/content/blog/evaluating-agents-requires-multifile-specdriven-tests.md b/apps/web-roo-code/src/content/blog/evaluating-agents-requires-multifile-specdriven-tests.md
new file mode 100644
index 00000000000..25c79a08fa1
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/evaluating-agents-requires-multifile-specdriven-tests.md
@@ -0,0 +1,120 @@
+---
+title: Evaluating Agents Requires Multi-File, Spec-Driven Tests
+slug: evaluating-agents-requires-multifile-specdriven-tests
+description: Why single-file coding challenges fail to predict real agent performance, and how multi-file, spec-driven evals with hybrid scoring surface the failures that matter.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agent-evaluation
+    - agentic-workflows
+    - testing
+    - developer-tools
+status: draft
+publish_date: "2025-09-10"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Eight files changed. Thirty files changed. A new feature wired into an existing codebase.
+
+That's what real agentic work looks like. Not a single-file coding challenge.
+
+## The mismatch
+
+Most public evals test a narrow slice: solve this algorithm, fix this function, generate this class. One file in, one file out. Pass or fail.
+
+But when you hand an agent a real task - something like "add OAuth to this Rails app" or "refactor the billing module to support subscriptions" - the scope expands. The agent touches config files, migrations, controllers, tests, and documentation. The work spans the codebase, not a single file.
+
+If your eval only tests single-file edits, you're measuring something, but not the thing that matters for production workflows.
+
+> "A lot of the evals out there aren't doing - you know, a lot of mine will be from 8 to 30 files that are touched in that regard, or you know building something from zero to one, or editing an existing codebase, or adding a new feature with a very detailed spec."
+>
+> Adam, [Roo Cast S01E08](https://www.youtube.com/watch?v=uA7NLvGwHAE&t=1896)
+
+## The spec is the test
+
+The prompts for these evals are not short. Some run 400 to 500 lines. They detail everything that needs to be there: the structure, the constraints, the edge cases. The spec is comprehensive enough that you could hand it to a senior engineer and expect a consistent result.
+
+This is intentional. The prompt is the contract. If the spec is vague, you can't distinguish "the agent misunderstood" from "the agent failed." Clear specs make failures diagnosable.
+
+The tradeoff: building these evals is labor-intensive. You construct the solution manually first. Then you design the prompt and evaluation criteria to match what a correct implementation looks like. There's no shortcut. The eval is only as good as the reference solution you built by hand.
+
+## Scoring beyond pass/fail
+
+A binary pass/fail metric collapses too much information. An agent that gets 90% of the way there and misses one edge case looks the same as an agent that produced garbage.
+
+A hybrid scoring system provides more signal:
+
+- **Unit tests:** Did the output actually work? Run the tests, count what passes.
+- **Static code analysis:** Is the code structured correctly? Lint it, check for patterns.
+- **LLM-as-judge:** Does the implementation match the intent? Use a model to evaluate adherence to the spec.
+
+> "About 30% of my score is LLM as a judge. Then there's points allocated for unit tests. And then there's points allocated for static code analysis."
+>
+> Adam, [Roo Cast S01E08](https://www.youtube.com/watch?v=uA7NLvGwHAE&t=2080)
+
+The weights matter. If you rely entirely on unit tests, you miss style and structure issues. If you rely entirely on LLM-as-judge, you miss concrete correctness. The combination catches failures that any single method would miss.
+
+## The autonomy requirement
+
+These evals test autonomous execution. The agent receives the spec and runs. No human in the loop to course-correct. No "actually, I meant this other thing." The prompt contains everything.
+
+This is closer to how teams actually deploy agents: set the task, let it run, review the result. An eval that requires human intervention during execution is testing a different workflow.
+
+> "It's autonomous. So it's basically like it gives a - it's imagine like a really - like some of the prompts can be four or 500 lines like it is - it details out everything that needs to be there without like filling in the logic."
+>
+> Adam, [Roo Cast S01E08](https://www.youtube.com/watch?v=uA7NLvGwHAE&t=1973)
+
+## How Roo Code closes the loop on multi-file tasks
+
+When an agent tackles a multi-file task, the critical capability is closing the loop: proposing changes, running tests, observing failures, and iterating until the implementation passes. Roo Code is an AI coding agent that executes this full cycle autonomously within your editor.
+
+With BYOK (Bring Your Own Key), you route tasks to the model that fits your eval criteria - whether that's a model optimized for long-context reasoning across many files or one tuned for code generation accuracy. The agent runs commands, executes your test suite, and iterates based on real feedback from your codebase.
+
+**For teams building evals or evaluating agents, the question isn't just "can it write code?" It's "can it coordinate changes across eight files, run the tests, and fix what breaks?"** Roo Code's loop-closing architecture directly addresses this by treating test execution and iteration as core to the workflow, not optional add-ons.
+
+## Single-file vs multi-file evals compared
+
+| Dimension         | Single-file evals             | Multi-file, spec-driven evals               |
+| ----------------- | ----------------------------- | ------------------------------------------- |
+| Scope             | One function or class         | 8-30 files across the codebase              |
+| Spec length       | Brief prompt                  | 400-500 lines with constraints              |
+| Failure diagnosis | Ambiguous                     | Clear - spec serves as contract             |
+| Real-world signal | Low - tests algorithmic skill | High - tests coordination and coherence     |
+| Build effort      | Low                           | High - requires reference solution          |
+| Scoring           | Usually pass/fail             | Hybrid: tests + static analysis + LLM judge |
+
+## Why this matters for your workflow
+
+For an engineer evaluating which agent to use, or which model to route tasks to, the eval methodology determines the signal quality.
+
+If you're testing with single-file challenges, you might pick a model that looks great on algorithmic puzzles but fails when the task requires coordinating changes across a codebase. You won't know until you're debugging production issues.
+
+Multi-file, spec-driven evals surface the failure modes that matter: can the agent maintain coherence across files, follow a detailed spec without drifting, and produce something that actually runs?
+
+The investment is upfront. Build the reference solution. Write the comprehensive spec. Design the scoring rubric. The payoff is evals that predict real-world performance, not just benchmark performance.
+
+If your current evals don't touch multiple files, they're measuring the wrong thing. Start with a real task from your codebase and work backwards.
+
+## Frequently asked questions
+
+### Why do single-file evals fail to predict real agent performance?
+
+Single-file evals test isolated coding skill - algorithm implementation, function writing, or class generation. Real agentic work requires coordinating changes across config files, migrations, controllers, tests, and documentation simultaneously. An agent that excels at single-file tasks may fail when required to maintain coherence across a codebase, and you won't discover this until production.
+
+### How long should an eval spec be for multi-file tasks?
+
+Comprehensive specs for multi-file evals often run 400 to 500 lines. The spec must detail the structure, constraints, edge cases, and expected outcomes clearly enough that a senior engineer would produce a consistent result. Vague specs make it impossible to distinguish agent misunderstanding from agent failure.
+
+### What scoring approach works best for agent evals?
+
+A hybrid approach combining unit tests (30-40%), static code analysis (30%), and LLM-as-judge (30%) provides the most signal. Unit tests alone miss style and structure issues. LLM-as-judge alone misses concrete correctness. The combination catches failure modes that any single method would miss.
+
+### How does Roo Code handle multi-file agent tasks differently?
+
+Roo Code closes the loop by running commands,executing tests, and iterating based on results - all autonomously within your editor. With BYOK, you choose the model that fits your task complexity. The agent doesn't just propose changes; it validates them against your actual test suite and fixes what breaks, matching how production agent deployments actually work.
+
+### Should evals allow human intervention during execution?
+
+For testing autonomous agent performance, no. Evals that require human course-correction during execution are testing a different workflow - one with a human in the loop. Production agent deployments typically follow the pattern of "set the task, let it run, review the result." Your evals should match this pattern to generate predictive signal.
diff --git a/apps/web-roo-code/src/content/blog/every-ui-setting-has-two-hidden-costs.md b/apps/web-roo-code/src/content/blog/every-ui-setting-has-two-hidden-costs.md
new file mode 100644
index 00000000000..448360cd0c4
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/every-ui-setting-has-two-hidden-costs.md
@@ -0,0 +1,120 @@
+---
+title: Every UI Setting Has Two Hidden Costs
+slug: every-ui-setting-has-two-hidden-costs
+description: Why every settings toggle creates cognitive load and carrying cost that compound over time, and how to apply the Pareto gate before shipping configuration options.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - product-design
+    - technical-debt
+    - developer-experience
+    - configuration
+status: draft
+publish_date: "2025-09-25"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+☐ Enable custom font size
+☐ Show line numbers
+☐ Auto-save on blur
+☐ Use compact mode
+
+That list is not a feature. It is a liability.
+
+## The settings trap
+
+Your PM wants to add a setting. "Let users choose," they say. "It's just a toggle." You add the toggle. Six months later, you want to change the default behavior. You cannot. Three thousand users already flipped that toggle, and changing the underlying logic will break their workflows.
+
+You shipped a feature. You inherited a constraint.
+
+## Two costs, one checkbox
+
+Every setting creates two forms of debt that compound over time.
+
+The first is cognitive load. Users who do not care about that option still have to parse what it does. They open the settings panel looking for one thing and encounter a wall of choices. Each toggle demands a decision: "Do I need this? What happens if I change it? Will something break?"
+
+> "People who don't care about that or haven't gotten to the level of sophistication have to parse and understand what that setting does."
+>
+> Bruno, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=813)
+
+The second is carrying cost. Anything you make customizable becomes something you cannot authoritatively change. You give up the ability to improve defaults without risking breakage for the subset of users who already made a choice.
+
+> "Everything that we make customizable is something that we can't authoritatively change directly. If type size was an important one and we already had a setting that allowed people to customize the type size and I wanted to make it a little bit bigger and then it just exploded."
+>
+> Bruno, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=842)
+
+The explosion is not dramatic. It is slow. You notice it when you try to ship a design update and realize half your layout assumptions depend on values that users can override. You notice it when onboarding new engineers who have to understand not just what the code does, but what it does across every possible configuration state.
+
+## The Pareto gate
+
+The alternative is deciding upfront what 80% of users need and shipping that as the default. Settings exist only where the tradeoff is clear and the user population is genuinely split.
+
+> "I would try to go for a Pareto rule. Make it work by default like what 80% of people would use it for."
+>
+> Bruno, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=1578)
+
+This is not about removing control. It is about being honest about what constitutes a real decision versus a deferred decision. When you add a setting because you are not sure what the right default is, you are not giving users power. You are offloading your product decision to them.
+
+The hard version: pick the default, ship it, watch the feedback, and adjust. The easy version: add a toggle and never think about it again. The easy version accumulates debt.
+
+## Why this matters for your team
+
+For a Series A - C team with three engineers, every setting is also a test matrix. If you have ten settings with two states each, you have 1,024 possible configurations. You are not testing all of them. You are hoping most of them work.
+
+When something breaks in production, the first question is "What are their settings?" When you onboard a new engineer, part of their ramp is understanding which settings interact with which features. When you want to refactor a component, you have to trace how many settings touch it.
+
+The compounding effect: each setting you add makes the next refactor harder, the next bug investigation longer, and the next design improvement riskier.
+
+## The audit
+
+Before adding a setting, ask:
+
+1. Is the user population genuinely split on this, or are we avoiding a product decision?
+2. Can we change this default later without breaking existing users?
+3. Does this setting interact with other settings in ways we have to test?
+
+If the answer to the first question is "we're not sure," that is a signal to ship a default and watch what happens. If the answer to the second is "no," you are creating permanent constraints. If the answer to the third is "yes," multiply the testing cost by the number of combinations.
+
+The goal is not zero settings. The goal is settings that earn their carrying cost.
+
+## How Roo Code applies the Pareto gate
+
+Roo Code ships opinionated defaults that close the loop for the 80% case: the agent proposes diffs, runs commands and tests, and iterates on failures without requiring configuration. Configuration exists where user workflows genuinely diverge - custom modes, model selection via BYOK, and approval gates for high-risk operations.
+
+Rather than exposing dozens of toggles for every possible behavior, Roo Code lets users define modes that bundle related settings into coherent workflows. This reduces cognitive load and keeps the test surface manageable. When you bring your own API key, you control token spend without Roo Code needing to add settings for rate limits or cost thresholds - those decisions stay with the provider you already trust.
+
+**The principle:** configuration should reflect real workflow differences, not deferred product decisions.
+
+## Settings costs comparison
+
+| Dimension               | Add a toggle                                    | Ship an opinionated default               |
+| ----------------------- | ----------------------------------------------- | ----------------------------------------- |
+| User cognitive load     | Increases with every option                     | Stays flat until user needs customization |
+| Future refactoring cost | High - must preserve all config states          | Low - can change behavior directly        |
+| Test matrix size        | Multiplies with each setting                    | Stays bounded                             |
+| Onboarding complexity   | Engineers must understand config interactions   | Engineers learn one golden path           |
+| Feedback signal         | Ambiguous - "users chose X" vs "users needed X" | Clear - complaints reveal actual needs    |
+
+## Frequently asked questions
+
+### How do I know if a setting is worth the carrying cost?
+
+A setting earns its cost when real users have genuinely different needs that cannot be reconciled with a single default. If you are adding a toggle because you are uncertain what the default should be, that uncertainty is the signal to ship one default and collect feedback. Settings added to avoid decisions create debt; settings added to serve distinct workflows create value.
+
+### What happens when users complain about a default they cannot change?
+
+Complaints are data. Track them. If a significant portion of users consistently request the same alternative behavior, that indicates the population is genuinely split and a setting may be warranted. If complaints are sparse and varied, the default is probably correct for the 80% case and the complaints represent edge cases that do not justify the carrying cost.
+
+### How does Roo Code handle configuration without adding setting bloat?
+
+Roo Code uses modes to bundle related behaviors into coherent configurations rather than exposing individual toggles. Users can create custom modes that combine instructions, tool permissions, and file restrictions into a single named workflow. This approach keeps the settings surface small while supporting diverse use cases.
+
+### Should I remove existing settings that do not meet the Pareto test?
+
+Removing settings is harder than not adding them. Existing users have built workflows around current options. Before removing, measure actual usage. If fewer than 5% of users have changed a setting from its default, you have a candidate for deprecation. Communicate changes clearly and provide migration paths where possible.
+
+### How do settings interact with technical debt in other parts of the codebase?
+
+Settings create coupling. Every configurable behavior becomes a branch point that other code must account for. When you refactor a component, you inherit all the configuration states it supports. When you debug a production issue, you must reproduce the user's exact configuration. The debt compounds because settings interact with each other and with future changes you have not yet planned.
diff --git a/apps/web-roo-code/src/content/blog/force-the-ai-to-present-options-before-writing-code.md b/apps/web-roo-code/src/content/blog/force-the-ai-to-present-options-before-writing-code.md
new file mode 100644
index 00000000000..4c4d3efe123
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/force-the-ai-to-present-options-before-writing-code.md
@@ -0,0 +1,118 @@
+---
+title: Force the AI to Present Options Before Writing Code
+slug: force-the-ai-to-present-options-before-writing-code
+description: Learn why forcing AI coding agents to present implementation options before writing code catches wrong approaches early and saves time, tokens, and debugging effort.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding-workflow
+    - pair-programming
+    - custom-modes
+    - developer-productivity
+status: draft
+publish_date: "2025-07-23"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+You ask for a feature. The AI picks one approach and executes immediately.
+
+That approach is wrong for your codebase.
+
+Now you have code to delete, context to reset, and the same problem you started with.
+
+## The default behavior problem
+
+When you tell an AI to implement something, it doesn't pause to consider alternatives. It pattern-matches to one solution and starts writing. By the time you see output, you're reviewing code that may not fit your architecture, your constraints, or your existing patterns.
+
+The AI isn't being lazy. It's doing exactly what you asked: implement this feature. The problem is that "implement" skips the part where you and a colleague would usually discuss approaches first.
+
+> "A lot of times, and all of you that code know this, if you tell the AI to do something, it'll pick the one thing it thinks it needs to do and just go do it. And that is usually not the right way to do it."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=1176)
+
+The fix isn't prompting harder. The fix is changing the workflow.
+
+## The pair programmer pattern
+
+A pair programmer mode forces the AI to present two or three implementation options with tradeoff analysis before any code is written. You see the approaches, the complexity estimates, and the reasoning. Then you pick, combine, or redirect.
+
+> "The idea with the pair programmer is it forces the AI to give you options for approaches and analyze it based on the complexity of it and then you can kind of like overwrite it."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=1197)
+
+The key word is "forces." Left to its own defaults, the AI will skip this step. The mode constraint makes the options phase mandatory.
+
+## The 50% rule
+
+Here's the honest tradeoff: the AI recommends the right approach about half the time.
+
+> "I'd say 50% of the time the one they recommend is usually the one that I go with. But sometimes they're way off and I can catch it before any code's written."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=1458)
+
+That 50% hit rate sounds mediocre until you consider the alternative. Without the options step, you discover the wrong approach after the AI has generated hundreds of lines of code. You've spent tokens, you've spent time reviewing, and now you're explaining why that approach won't work. The AI apologizes and starts over with the same blind confidence.
+
+With the options step, you catch the wrong approach in a few sentences of analysis. No code to delete. No context pollution. No wasted review time.
+
+## Comparing approaches: immediate execution vs. options-first workflow
+
+| Dimension                     | Immediate execution                | Options-first workflow      |
+| ----------------------------- | ---------------------------------- | --------------------------- |
+| Discovery of wrong approach   | After code is written              | Before code exists          |
+| Token cost of mistakes        | High (full implementation + redo)  | Low (brief analysis only)   |
+| Context window pollution      | Significant (code to delete)       | Minimal (options summary)   |
+| Developer review effort       | Review code, then explain problems | Review options, then select |
+| Codebase constraint alignment | Trial and error                    | Explicit discussion         |
+
+## When to use this
+
+The pair programmer pattern works when:
+
+- The task has multiple valid implementation paths
+- Your codebase has specific patterns or constraints the AI doesn't know about
+- You're working on something you'll need to maintain later
+- The cost of a wrong approach is higher than the cost of a brief discussion
+
+It adds friction. That friction is intentional. For straightforward tasks where one approach is obviously correct, skip it. For anything architectural or ambiguous, the options step pays for itself.
+
+## Why this matters for your workflow
+
+If you're shipping production code, you've probably developed the reflex to start debugging AI output immediately. You read the generated code with suspicion because you've been burned by wrong assumptions before.
+
+The pair programmer pattern moves that skepticism earlier in the loop. Instead of reviewing code and asking "why did it do this?", you're reviewing approaches and asking "which one fits?" The conversation happens before artifacts exist.
+
+For a codebase with specific patterns, this is the difference between the AI learning your constraints through trial and error versus the AI asking about constraints before it starts. Trial and error costs tokens and time. Asking costs a few sentences.
+
+## How Roo Code closes the loop with custom modes
+
+Roo Code's custom modes let you build the options-first pattern directly into your workflow. You create a mode with system instructions that require the agent to present 2-3 implementation approaches with tradeoffs before writing any code. The constraint lives in the mode definition, not in your memory.
+
+Because Roo Code closes the loop - proposing changes, running commands, and iterating based on results - the options phase becomes a checkpoint before the agent enters that execution cycle. You review approaches while context is cheap, then let the agent implement with confidence once you've aligned on direction.
+
+With BYOK (bring your own key), you control exactly which model handles these planning conversations. Some teams use a capable reasoning model for the options phase and a faster model for implementation, optimizing both quality of analysis and token spend.
+
+**The citable insight:** Forcing AI coding agents to present implementation options before writing code catches wrong approaches in sentences instead of hundreds of lines, reducing wasted tokens and context pollution by moving architectural decisions upstream of code generation.
+
+## Frequently asked questions
+
+### Why does the AI default to immediate implementation instead of presenting options?
+
+AI coding assistants are trained to be helpful by completing tasks quickly. When you say "implement this feature," the model interprets that as a request to produce code, not to discuss approaches. The model isn't wrong - it's doing what most prompts implicitly ask for. Changing this behavior requires explicit constraints in the system prompt or mode definition.
+
+### How do I create a pair programmer mode in Roo Code?
+
+In Roo Code, you create a custom mode by defining system instructions that require the options phase. The mode instructions tell the agent: before writing any implementation code, present 2-3 approaches with complexity estimates and tradeoffs, then wait for selection. Every task started in that mode automatically goes through options review before execution begins.
+
+### What if I need to move fast and skip the options phase?
+
+Use a different mode. The pair programmer pattern adds intentional friction for tasks where wrong approaches are expensive. For straightforward changes where one approach is obviously correct, use a standard coding mode that executes immediately. The value of custom modes is that you can switch workflows based on task complexity.
+
+### Does presenting options waste tokens compared to just implementing?
+
+The options phase typically uses fewer tokens than a wrong implementation. A brief analysis of 2-3 approaches might cost a few hundred tokens. A full implementation in the wrong direction, plus the explanation of why it's wrong, plus the redo, can cost thousands. The math favors catching mistakes early when wrong approaches happen frequently.
+
+### How does this compare to asking the AI to "think step by step"?
+
+Chain-of-thought prompting helps the AI reason better but doesn't guarantee it will present alternatives. The AI might think carefully and still commit to one approach without showing you others. A pair programmer mode makes the multiple-options output format mandatory, not just encouraged. The constraint is structural, not just a prompting technique.
diff --git a/apps/web-roo-code/src/content/blog/frontload-context-instead-of-long-conversations.md b/apps/web-roo-code/src/content/blog/frontload-context-instead-of-long-conversations.md
new file mode 100644
index 00000000000..d8f2f9bcb11
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/frontload-context-instead-of-long-conversations.md
@@ -0,0 +1,123 @@
+---
+title: Front-Load Context Instead of Long Conversations
+slug: frontload-context-instead-of-long-conversations
+description: Learn why million-token context windows work best with upfront context loading rather than extended conversations, and how to eliminate drift in AI coding workflows.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-windows
+    - ai-coding
+    - workflow-optimization
+    - developer-productivity
+status: draft
+publish_date: "2025-07-02"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+300,000 tokens upfront.
+
+Two turns.
+
+One answer.
+
+That is the math that makes million-token context windows useful.
+
+## The drift problem
+
+You have a million tokens available. You use them like a conversation: ask a question, get an answer, ask a follow-up, get another answer. Fifteen turns later, the model is referencing something from turn three that no longer matches your codebase. You correct it. It apologizes. It drifts again.
+
+The context window is not the problem. The turn count is.
+
+Million-token models do not perform well over 15 to 20 turns. Each turn introduces new information that can conflict with earlier context. The model has to reconcile what you said in turn four with what you said in turn twelve. By turn eighteen, you are debugging the conversation instead of debugging the code.
+
+## The front-load pattern
+
+The teams getting reliable results from large context windows use a different pattern: dump everything upfront, then ask one focused question.
+
+> "Basically, give it your 20,000 system prompt, 780,000 worth of code base or documentation, and then do your ask and you got 200,000 to finish the job."
+>
+> Hannes Rudolph, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=722)
+
+The ratio matters: 80% context, 20% generation headroom. You front-load the codebase, the documentation, the relevant files. Then you ask. The model has everything it needs in one pass.
+
+This pattern works especially well for specific task types:
+
+**Translation tasks:** Reading 17 or 20 files at once, then doing one or two writes. The model sees all the source files before it generates any output.
+
+**Codebase analysis:** Loading the entire relevant module, then asking one diagnostic question. No back-and-forth about which files to read.
+
+**Library generation from documentation:** Feeding the full API reference upfront, then requesting the wrapper code in a single generation pass.
+
+> "I find the million models to be quite effective when I feed them a huge chunk of context up front. For example, when we're doing translating files, doing, you know, 17 or 20 reads at once, boom, filling it up and then doing one or two writes with concurrent, right? It does. It works pretty smoothly."
+>
+> Hannes Rudolph, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=565)
+
+## The tradeoff
+
+Front-loading requires knowing what context matters before you start. If you load 600,000 tokens of the wrong files, you have wasted the window. The pattern assumes you can identify the relevant context upfront.
+
+For exploratory work, where you do not know which files matter yet, you may need a few turns to narrow scope. But once you know the scope, switch to front-load mode. Stop iterating and start dumping.
+
+The other constraint: once the conversation drifts, recovery is expensive.
+
+> "It works good until it doesn't and then once it doesn't it's hard to get it back on track."
+>
+> Hannes Rudolph, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=596)
+
+If turn twelve goes wrong, you often cannot fix it in turn thirteen. The model has internalized assumptions from the earlier turns. Starting fresh with a front-loaded context is usually faster than trying to correct course mid-conversation.
+
+## Why this matters for your team
+
+For a team running translation or migration projects, the front-load pattern changes throughput. Instead of a developer babysitting a 20-turn conversation, they set up the context once and let the model complete the task. The time spent on conversation management drops to near zero.
+
+For codebase analysis, the same shift applies. Loading the full module upfront means the model can answer diagnostic questions without asking "which file is that in?" five times. One context load, one answer.
+
+The compounding effect: if three developers on a five-person team each save 30 minutes per day by eliminating conversation drift, that is 7.5 hours per week. Enough to ship one more feature per sprint.
+
+## The heuristic
+
+Give the model 300,000 to 600,000 tokens of context in the first message. Limit yourself to two or three turns. If the conversation drifts, start fresh with a new front-loaded context instead of trying to correct.
+
+The million-token window is not for long conversations. It is for short conversations with long context.
+
+## How Roo Code optimizes context loading
+
+Roo Code closes the loop on context management by automatically gathering relevant files, running commands, and iterating based on results. Instead of manually curating which files to include, Roo Code can traverse your codebase and load the context it needs for a given task.
+
+With BYOK (Bring Your Own Key), you control which models you use and how many tokens you spend. When working with million-token models, Roo Code's ability to read multiple files in parallel and execute iterative workflows means you can front-load context without manually copying file contents into a chat window.
+
+**The key advantage:** Roo Code treats each task as a focused unit of work. You describe the outcome, and the agent gathers context, proposes changes, runs tests, and iterates - typically completing in two to three turns rather than 15 or 20.
+
+## Comparison: conversational vs. front-loaded context
+
+| Dimension           | Conversational approach                     | Front-loaded approach                |
+| ------------------- | ------------------------------------------- | ------------------------------------ |
+| Turn count          | 15-20 turns typical                         | 2-3 turns typical                    |
+| Drift risk          | High - each turn introduces conflicts       | Low - all context present from start |
+| Recovery cost       | Expensive - must correct accumulated errors | Cheap - start fresh with new context |
+| Developer attention | Continuous babysitting required             | Setup once, then review              |
+| Throughput          | Degraded by conversation management         | Optimized for completion             |
+
+## Frequently asked questions
+
+### Why do conversations drift after 15 turns?
+
+Each turn adds new information that can contradict earlier context. The model attempts to reconcile statements from turn four with updates from turn twelve, leading to accumulated confusion. By turn eighteen, you spend more time correcting the model than making progress on the actual task.
+
+### How much context should I load upfront?
+
+The effective ratio is 80% context, 20% generation headroom. For a million-token window, this means 300,000 to 600,000 tokens of codebase, documentation, and relevant files in the first message. Reserve the remaining capacity for the model's response and any follow-up turns.
+
+### When should I use conversational mode instead of front-loading?
+
+Exploratory work where you do not yet know which files matter may require a few turns to narrow scope. Once you identify the relevant context, switch to front-load mode. The pattern works best when you can define the task and its scope upfront.
+
+### How does Roo Code handle large context tasks?
+
+Roo Code uses concurrent file reads to load context efficiently and closes the loop by running tests and iterating on results. With BYOK, you choose the model and control token spend. The agent-based workflow naturally aligns with the front-load pattern: gather context, execute the task, verify the outcome in minimal turns.
+
+### What should I do when context drift occurs mid-conversation?
+
+Start fresh. Attempting to correct accumulated errors in later turns rarely succeeds because the model has internalized assumptions from the earlier context. Loading a new front-loaded context is faster than debugging the conversation itself.
diff --git a/apps/web-roo-code/src/content/blog/googles-prompt-caching-requires-explicit-time-budgets.md b/apps/web-roo-code/src/content/blog/googles-prompt-caching-requires-explicit-time-budgets.md
new file mode 100644
index 00000000000..cf84035e9af
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/googles-prompt-caching-requires-explicit-time-budgets.md
@@ -0,0 +1,116 @@
+---
+title: Google's Prompt Caching Requires Explicit Time Budgets
+slug: googles-prompt-caching-requires-explicit-time-budgets
+description: Google Vertex prompt caching works differently from Anthropic - you must declare TTL upfront. Learn how time-based caching affects multi-provider LLM architectures and cost management.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - prompt-caching
+    - google-vertex
+    - multi-provider
+    - cost-optimization
+status: draft
+publish_date: "2025-05-07"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+```python
+cache_ttl = 300  # seconds
+
+That line is not a performance optimization. It is a policy decision.
+
+## The assumption that breaks
+
+You've got prompt caching working on Anthropic. Latency dropped. Costs dropped. The system prompt doesn't get re-processed every call. You decide to add Google Vertex as a fallback provider.
+
+Then your costs spike. Or your latency spikes. Or both.
+
+The symptom looks like a bug: requests that should be cached aren't. The caching you thought was happening silently isn't. You check the logs, compare the prompts, diff the configurations. Everything looks identical to what works on Anthropic.
+
+The problem is the mental model. On Anthropic, caching works automatically based on content. On Google Vertex, you have to declare what to cache and for how long.
+
+## The mechanism
+
+Google's caching requires explicit time budgets. Five minutes. Ten minutes. Twenty minutes. You pick a window, and if your session outlives that window, the cache expires. The next request pays full price.
+
+> "So for Google, you basically have to do what you're going to cache and invoke that caching for a certain amount of time. So you have to say: let's cache the system prompt or this user prompt for five minutes, 10 minutes, 20 minutes."
+>
+> Thibault, [Office Hours S01E05](https://www.youtube.com/watch?v=Wa8ox5EVBZQ&t=2283)
+
+This isn't a minor implementation detail. It changes your caching strategy from "what content to cache" to "how long will this session last."
+
+The structure is unfamiliar. If you've built caching logic around content hashing and automatic invalidation, Google's time-based model requires a different approach entirely.
+
+> "It was a totally new structure. We've never seen it before."
+>
+> Thibault, [Office Hours S01E05](https://www.youtube.com/watch?v=Wa8ox5EVBZQ&t=2323)
+
+## The tradeoff
+
+The time budget forces you to predict session behavior upfront. Set the TTL too short and you pay for re-caching mid-session. Set it too long and you're paying for cache storage you don't need.
+
+Neither is catastrophic. But if you're running cost-sensitive workloads across multiple providers, the unpredictability adds up.
+
+The implementation complexity is also real. Abstracting over multiple caching strategies means your provider layer needs to know things about session duration that it previously didn't care about.
+
+> "The way you do it technically is a nightmare."
+>
+> Thibault, [Office Hours S01E05](https://www.youtube.com/watch?v=Wa8ox5EVBZQ&t=2292)
+
+"Nightmare" is strong language, but the frustration is understandable. When you expect caching to be a transparent optimization and it becomes a configuration surface with failure modes, the debugging time compounds.
+
+## Why this matters for your team
+
+For a Series A - C team running multi-provider setups, this creates a specific kind of risk: silent cost drift.
+
+You test on one provider. Caching works. You add a second provider for redundancy or capability reasons. You assume caching works the same way. It doesn't. Your cost projections are now wrong, and you won't notice until the bill arrives or someone digs into latency metrics.
+
+The fix isn't complicated, but it requires awareness. Your provider abstraction layer needs to handle caching strategy per-provider, not per-content. Session duration becomes a parameter you track, not something you ignore.
+
+If you're building with multiple LLM providers, audit your caching assumptions. What works transparently on one provider may require explicit configuration on another.
+
+The first step: check whether your Google Vertex integration is actually caching, or just pretending to.
+
+## How Roo Code handles multi-provider caching complexity
+
+Roo Code's BYOK (Bring Your Own Key) architecture means you connect directly to providers like Anthropic, Google Vertex, and OpenAI using your own API keys. This direct connection gives you full visibility into provider-specific behaviors - including caching mechanics - without an abstraction layer hiding the differences.
+
+When Roo Code closes the loop by executing tasks, running tests, and iterating on results, each provider interaction uses your configured keys with transparent cost tracking. You see exactly what's happening with each provider, including whether caching is working as expected.
+
+**For teams managing multi-provider LLM deployments, understanding provider-specific caching behavior is essential for accurate cost forecasting and performance optimization.**
+
+## Comparison: content-based vs. time-based caching
+
+| Dimension | Content-based caching (Anthropic) | Time-based caching (Google Vertex) |
+|-----------|-----------------------------------|-----------------------------------|
+| Cache trigger | Automatic on matching content | Explicit TTL declaration required |
+| Configuration | Minimal - content determines caching | Requires session duration prediction |
+| Failure mode | Silent hits/misses based on content hash | Cache expiration mid-session |
+| Cost predictability | High - consistent per-content | Variable - depends on TTL accuracy |
+| Debugging complexity | Check content matching | Check TTL settings and session timing |
+
+## Frequently asked questions
+
+### Why does my Google Vertex caching cost more than expected?
+
+Google Vertex requires you to declare a TTL (time-to-live) for cached content upfront. If your session outlives the TTL, the cache expires and subsequent requests pay full price. Unlike content-based caching where matching prompts automatically hit the cache, Vertex's time-based model means you're paying for re-caching whenever sessions exceed your declared window.
+
+### How do I know if my prompt caching is actually working?
+
+Check your provider's usage dashboard for cache hit rates. For Google Vertex specifically, compare your actual session durations against your configured TTL values. If sessions regularly exceed TTL, you're likely paying for re-caching without realizing it. Monitor latency metrics as well - uncached requests will show higher latency than cached ones.
+
+### Can I use the same caching strategy across all LLM providers?
+
+No. Provider caching implementations differ fundamentally. Anthropic uses content-based automatic caching, while Google Vertex requires explicit time budgets. Your provider abstraction layer needs to handle caching strategy per-provider, which means tracking session duration for time-based providers even if you ignored it for content-based ones.
+
+### How does Roo Code help manage provider-specific differences?
+
+Roo Code's BYOK model connects you directly to each provider with your own API keys. This transparency means provider-specific behaviors like caching mechanics, rate limits, and pricing are visible to you - not hidden behind an opaque abstraction layer. You maintain full control over provider configuration and can audit caching behavior per-provider.
+
+### What TTL should I set for Google Vertex caching?
+
+Analyze your actual session durations before picking a TTL. If most sessions complete in under five minutes, a 300-second TTL works. If you have longer coding sessions or debugging cycles, extend the TTL accordingly. The tradeoff: longer TTLs mean paying for cache storage even when sessions end early, while shorter TTLs risk mid-session cache expiration.
+
+```
diff --git a/apps/web-roo-code/src/content/blog/gpt5-codex-works-best-when-you-strip-your-harness-down.md b/apps/web-roo-code/src/content/blog/gpt5-codex-works-best-when-you-strip-your-harness-down.md
new file mode 100644
index 00000000000..1f612428774
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/gpt5-codex-works-best-when-you-strip-your-harness-down.md
@@ -0,0 +1,116 @@
+---
+title: GPT-5 Codex Works Best When You Strip Your Harness Down
+slug: gpt5-codex-works-best-when-you-strip-your-harness-down
+description: Learn why GPT-5 Codex underperforms in custom tool harnesses and how stripping down to native tooling like apply patch and ripgrep eliminates the attention tax for better coding agent results.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - codex
+    - ai-agents
+    - developer-tools
+    - model-integration
+status: draft
+publish_date: "2025-11-05"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Strip your tools. Get better results.
+
+That's the counterintuitive lesson from teams integrating GPT-5 Codex into their own harnesses.
+
+## The attention tax
+
+You've built a sophisticated tool harness. Custom diff formats, specialized search commands, a carefully designed output schema. You drop Codex into it and watch it stumble.
+
+The model is capable. Your harness is thoughtful. But the combination underperforms.
+
+Here's why: Codex was hyper-trained on one specific setup. Apply patch. Ripgrep search. That's the loop it knows cold. When you hand it a different set of tools, it has to spend cognitive budget figuring out your format instead of solving the actual coding problem.
+
+> "If you're sort of like giving somebody a whole bunch of stuff to do and they're like trying really hard to do a really good job and they have this like slightly different way of like having to give you the answer... then they're going to like have to think harder about that part of it and they might screw something else up along the way."
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=2990)
+
+This isn't a bug. It's a tradeoff OpenAI made deliberately. Codex is optimized for the Codex product cycle: heads-down execution, minimal back-and-forth, tight integration with their specific tooling.
+
+## The fix is subtraction
+
+Teams that get good results with Codex in third-party harnesses share one pattern: they strip out most of their custom tooling.
+
+> "When people implement Codex in their harness, it works better for them to just cut out almost all of their tools and just have it use our apply patch, which is open-sourced, and basically ripgrep to search around code."
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=814)
+
+OpenAI's apply patch format is available. Ripgrep is the search primitive it expects. When you align your harness to what Codex was trained on, you stop paying the attention tax.
+
+The instinct is to add capabilities. The reality is that adding unfamiliar tools dilutes the model's focus on the actual task.
+
+## GPT-5 is different
+
+GPT-5 was trained to generalize across harnesses. It handles varied tool formats without the same performance hit. If you need flexibility in your integration, GPT-5 gives you more room to customize.
+
+But Codex wasn't built for that use case. It was built to execute autonomously within a known environment.
+
+> "Codex is very tightly optimized to the Codex harness and the Codex basically kind of like product cycle... it's not going to do things like communicate as much with you along the way."
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=763)
+
+The tradeoff is explicit: Codex trades flexibility for execution depth. GPT-5 trades some of that depth for adaptability.
+
+## The practical decision
+
+If you're integrating Codex:
+
+1. **Audit your tool surface.** How many custom tools are you exposing? Each one is potential overhead.
+2. **Adopt the native format.** OpenAI's apply patch is open-sourced. Use it instead of your custom diff format.
+3. **Stick to ripgrep for search.** Don't add fancy search abstractions unless you're willing to pay the attention cost.
+4. **Reserve customization for GPT-5.** If your harness genuinely needs varied tooling, route those tasks to GPT-5.
+
+## Harness complexity: old approach vs. optimized approach
+
+| Dimension        | Custom harness approach     | Optimized Codex approach          |
+| ---------------- | --------------------------- | --------------------------------- |
+| Diff format      | Proprietary schema          | OpenAI apply patch (open-sourced) |
+| Search tooling   | Custom abstractions         | Ripgrep native                    |
+| Tool count       | Many specialized tools      | Minimal surface area              |
+| Model attention  | Split across format parsing | Focused on coding task            |
+| Integration cost | High debugging overhead     | Aligned to training distribution  |
+
+## How Roo Code handles harness complexity automatically
+
+Roo Code takes a different approach to the harness alignment problem. Rather than requiring you to manually strip down tooling or match specific formats, Roo Code lets you bring your own key (BYOK) and choose the model that fits your task. The agent closes the loop by proposing changes, running commands and tests, and iterating based on results - all within a harness designed for flexibility across model providers.
+
+When using Codex through Roo Code, the harness automatically handles the translation layer, so you get the execution depth of Codex without manually restructuring your workflow around apply patch and ripgrep.
+
+## Why this matters for your team
+
+For a Series A to C engineering team, this is a resource allocation question. You don't have cycles to debug why the model keeps formatting diffs wrong. You need it to work.
+
+The fix isn't deeper prompt engineering. The fix is alignment: match your harness to the model's training distribution, or pick a model trained to handle yours.
+
+If Codex is struggling in your integration, the first question isn't "how do I prompt this better?" It's "how much of my custom tooling can I remove?"
+
+Start with apply patch and ripgrep. Add complexity only when you've measured the cost.
+
+## Frequently asked questions
+
+### What is the attention tax when using Codex?
+
+The attention tax refers to the cognitive budget Codex spends parsing unfamiliar tool formats instead of solving the actual coding problem. When you expose custom diff formats or specialized search commands that differ from Codex's training distribution, the model diverts processing capacity to understanding your tooling rather than executing the task effectively.
+
+### Why does Codex struggle with custom tool harnesses?
+
+Codex was hyper-trained on a specific setup: OpenAI's apply patch format and ripgrep for code search. This tight optimization means it excels within that environment but underperforms when asked to work with different diff formats or search abstractions. It's a deliberate tradeoff - execution depth over flexibility.
+
+### Should I use GPT-5 or Codex for my integration?
+
+Use Codex when you can align your harness to its native tooling (apply patch, ripgrep) and want deep autonomous execution with minimal back-and-forth. Use GPT-5 when your integration requires varied tool formats or custom abstractions, as it was trained to generalize across different harnesses.
+
+### How does Roo Code help with model selection and harness alignment?
+
+Roo Code provides a BYOK (bring your own key) approach that lets you choose the right model for each task without manually restructuring your harness. The agent handles translation between your workflow and model-specific requirements, so you can leverage Codex's execution depth or GPT-5's flexibility based on the task at hand.
+
+### What's the fastest way to improve Codex performance in my harness?
+
+Start by auditing your tool surface and removing custom tooling. Adopt OpenAI's open-sourced apply patch format instead of proprietary diff schemas. Use ripgrep directly rather than search abstractions. Only add complexity back when you've measured the actual attention cost and confirmed the tradeoff is worth it.
diff --git a/apps/web-roo-code/src/content/blog/how-to-find-the-right-temperature-for-any-model.md b/apps/web-roo-code/src/content/blog/how-to-find-the-right-temperature-for-any-model.md
new file mode 100644
index 00000000000..9f0277909e5
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/how-to-find-the-right-temperature-for-any-model.md
@@ -0,0 +1,118 @@
+---
+title: How to Find the Right Temperature for Any Model
+slug: how-to-find-the-right-temperature-for-any-model
+description: Learn the systematic methodology for finding optimal LLM temperature settings through rigorous testing rather than guessing - including surprising findings like Gemini 2.5 Pro at 0.72 and ByteDance Seed at 1.1.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - llm-configuration
+    - model-tuning
+    - ai-coding
+    - developer-workflow
+status: draft
+publish_date: "2025-09-03"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+0.72.
+
+That's the optimal temperature for Gemini 2.5 Pro. Not 0.7. Not 0.8. Exactly 0.72.
+
+And for ByteDance's Seed OSS? Around 1.0 or 1.1.
+
+Default temperatures work until they don't. Then you're guessing.
+
+## The guessing problem
+
+You've read the documentation. It says "temperature 0.7 is recommended for coding tasks." You use 0.7. Sometimes outputs are great. Sometimes they're repetitive. Sometimes they hallucinate wildly.
+
+You nudge it to 0.5. Things get stiff. You bump it to 0.9. Things get weird. You go back to 0.7 and tell yourself it's fine.
+
+The problem: you're tuning by vibes. Each model has different internals, different training distributions, different sweet spots. The number that works for one model actively hurts another.
+
+## The methodology
+
+The systematic approach: run hundreds of tests at each temperature increment, grade each output, and narrow in on the optimal setting.
+
+> "I then ran through a series of hundreds of tests at each temp, each temperature, then grading each one and it zoned in at it was literally like 0.72 or something was the best."
+>
+> Adam, [Roo Cast S01E07](https://www.youtube.com/watch?v=ECO4kNueKL0&t=1572)
+
+The test setup matters. Not toy prompts. Real specs across multiple files.
+
+> "Imagine like a big spec where I'm asking it to build a specific thing across a bunch of different files and then being able to measure the output of that is really what I'm doing. And I do that across I have multiple of those things that are running."
+>
+> Adam, [Roo Cast S01E07](https://www.youtube.com/watch?v=ECO4kNueKL0&t=1623)
+
+The grading criteria: tool call failures, output completeness, whether the generated code actually satisfies the spec. Binary where possible. Did it complete the task or not?
+
+## The counterintuitive findings
+
+Some models want temperatures that seem wrong.
+
+> "Some of them actually I found recommend even higher, like one, like the new ByteDance Seed OSS model has a like ideal temperature of like one or 1.1, which is insane."
+>
+> Adam, [Roo Cast S01E07](https://www.youtube.com/watch?v=ECO4kNueKL0&t=1587)
+
+Temperature 1.1 for a coding model sounds like you're asking for chaos. But if the model was trained with that distribution in mind, that's where it performs.
+
+The point: your intuition about "reasonable" temperatures is probably wrong for at least some of the models you're using.
+
+## The tradeoff
+
+Running hundreds of tests per temperature increment takes time. You need a consistent spec, a grading rubric, and the patience to run the full sweep before drawing conclusions.
+
+For most teams, this isn't worth doing for every model. But for your primary workhorse model - the one you route 80% of tasks to - the investment pays off. A 5% improvement in task completion rate across thousands of requests is real time saved.
+
+The cheaper alternative: start with the model provider's recommended default, but track your failure modes. If you see a pattern (repetitive outputs, incomplete tool calls, hallucinated file paths), try a temperature sweep on that specific failure case.
+
+## Why this matters for your workflow
+
+If you're running an agent that generates code across multiple files, temperature affects whether the output hangs together or drifts into incoherence. At the wrong temperature, you get outputs that technically parse but miss the spec. At the right temperature, tool calls complete and files reference each other correctly.
+
+The difference shows up in your iteration count. How many times do you re-run the same task because the output was almost right but not quite? That's the cost of guessing.
+
+## How Roo Code closes the loop on temperature tuning
+
+Roo Code supports BYOK (bring your own key), which means you connect directly to model providers and control your own configuration - including temperature settings. When Roo Code closes the loop by running commands, executing tests, and iterating based on results, temperature affects every step of that cycle.
+
+With the wrong temperature, an agent might generate code that compiles but fails tests, or produces tool calls that don't complete. With the right temperature, the agent completes multi-file tasks with fewer iterations. Roo Code's approval-based workflow lets you observe these patterns across real tasks, building the data you need to tune systematically rather than guess.
+
+| Approach              | Temperature selection                | Iteration cost                      | Failure visibility                  |
+| --------------------- | ------------------------------------ | ----------------------------------- | ----------------------------------- |
+| Default settings      | Use 0.7 for everything               | High - frequent re-runs             | Low - symptoms unclear              |
+| Vibes-based tuning    | Adjust when things feel wrong        | Medium - reactive changes           | Medium - pattern recognition        |
+| Systematic testing    | Run controlled sweeps per model      | Low upfront, high long-term savings | High - measured by rubric           |
+| Agent-observed tuning | Track failures across real workflows | Medium - real usage data            | High - actual task completion rates |
+
+## The first step
+
+Pick one model. Pick one representative task (something that spans multiple files or requires tool calls). Run it at 0.5, 0.7, 0.9, 1.0. Grade each output on the same rubric.
+
+If you see a clear pattern, narrow in. If you don't, the model is probably stable enough that default is fine.
+
+The number matters less than the method. Build a test, run the sweep, measure what breaks.
+
+## Frequently asked questions
+
+### What temperature should I use for coding tasks?
+
+There is no universal answer. Gemini 2.5 Pro performs best around 0.72, while ByteDance Seed OSS needs 1.0-1.1. Start with the model provider's recommended default, then run a systematic sweep if you observe consistent failure patterns like incomplete tool calls or repetitive outputs.
+
+### Why do different models need different temperatures?
+
+Each model has different training distributions and internal architectures. A temperature setting normalizes the probability distribution over tokens, but "normalized" means different things depending on how the model was trained. What feels like a "safe" temperature for one model might constrain or destabilize another.
+
+### How do I test temperature settings systematically?
+
+Create a representative task that spans multiple files or requires tool calls. Run the same task at several temperature increments (0.5, 0.7, 0.9, 1.0). Grade each output using a consistent rubric: did tool calls complete, did the code satisfy the spec, were file references correct? Look for patterns before narrowing in.
+
+### How does Roo Code handle temperature configuration?
+
+Roo Code uses BYOK (bring your own key) architecture, so you configure temperature directly with your model provider. This gives you full control over model parameters. As Roo Code closes the loop by running tests and iterating on failures, you can observe which temperature settings lead to higher task completion rates in your actual workflow.
+
+### Is temperature tuning worth the investment?
+
+For your primary model - the one handling 80% of your tasks - yes. A 5% improvement in task completion rate across thousands of requests translates to real time saved. For secondary models you use occasionally, the default is usually fine unless you notice consistent failure patterns.
diff --git a/apps/web-roo-code/src/content/blog/issuesfirst-slowing-down-prs-to-speed-up-shipping.md b/apps/web-roo-code/src/content/blog/issuesfirst-slowing-down-prs-to-speed-up-shipping.md
new file mode 100644
index 00000000000..8fce9d24a4d
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/issuesfirst-slowing-down-prs-to-speed-up-shipping.md
@@ -0,0 +1,119 @@
+---
+title: "Issues-First: Slowing Down PRs to Speed Up Shipping"
+slug: issuesfirst-slowing-down-prs-to-speed-up-shipping
+description: Learn why requiring issues before PRs reduces technical debt and improves codebase organization - a proven approach from the Roo Code team.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - development-workflow
+    - code-review
+    - technical-debt
+    - team-practices
+status: draft
+publish_date: "2025-05-14"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+"LGTM."
+
+Merged.
+
+Three weeks later, nobody can find where the auth logic lives.
+
+## The spaghetti problem
+
+A PR shows up. It looks good. The tests pass. The description is reasonable. You merge it.
+
+Then another one. Same deal. Looks fine. Merge.
+
+Then a third, a fourth, a fifth. Each one makes sense in isolation. Each one passes review. Each one ships.
+
+Six months later, you're staring at a codebase where the business logic is scattered across fourteen files, the naming conventions conflict, and nobody remembers why half of these changes were made in the first place.
+
+This is the "good-looking PR" trap. The problem is not that the code is bad. The problem is that nobody discussed the approach before the code existed.
+
+## The shift: issues before PRs
+
+The Roo Code team made a deliberate change. Issues are now required before PRs get accepted. Every change starts with a written discussion of what the change is, why it matters, and how it fits into the existing architecture.
+
+> "In the last week, we have shifted to an issues first approach where issues are required before we make PRs and where we review these issues on a regular basis."
+>
+> Hannes Rudolph, [Office Hours S01E06](https://www.youtube.com/watch?v=zPhNXCHJ5xk&t=2858)
+
+The goal is not bureaucracy. The goal is catching misalignment before code exists. A five-minute conversation about approach is cheaper than a two-hour code review that ends with "actually, we should have done this differently."
+
+## Why PRs alone fail
+
+Code review is supposed to catch problems. But by the time a PR exists, the author has already invested hours. The sunk cost is real. Reviewers feel pressure to approve work that technically functions, even when the approach creates future problems.
+
+> "We're doing this as a team to prevent just simply taking on PRs. Oh, there's a good PR. Let's put it in there. And then we end up with a mountain of technical debt, of really a spaghetti codebase."
+>
+> Hannes Rudolph, [Office Hours S01E06](https://www.youtube.com/watch?v=zPhNXCHJ5xk&t=2876)
+
+The pattern is predictable. A contributor submits a PR. It looks reasonable. The team merges it to avoid blocking progress. Repeat until the codebase is a patchwork of isolated decisions that never had a chance to be coordinated.
+
+## The tradeoff
+
+This approach is not free. Week one feels slower. PRs that would have been merged immediately now wait for issue discussions. Contributors who want to ship quickly hit friction.
+
+But the friction is the feature. The conversation that happens before code exists is where architectural alignment happens. The review of an issue is a review of intent, not implementation. You can redirect approach in ten minutes instead of discovering problems after the code is merged.
+
+> "The technical debt has really gone down. From the days where we were just client work or the code was really messy back in the day, but right now I can say the code is much better organized."
+>
+> Dan, [Office Hours S01E06](https://www.youtube.com/watch?v=zPhNXCHJ5xk&t=2931)
+
+## Why this matters for your team
+
+For a Series A - C team shipping with five engineers, every architectural misstep compounds. You do not have the headcount to refactor constantly. You cannot afford to have three people debugging a merge conflict that exists because two PRs made conflicting assumptions about how auth should work.
+
+The issues-first approach forces the conversation to happen at the cheapest possible moment: before anyone writes code. A ten-minute issue review can prevent a week of cleanup.
+
+The math is simple. Slower PR acceptance in week one. Faster iteration in month two. The velocity you lose upfront comes back when your codebase stays reviewable.
+
+## The rule
+
+If a PR shows up without an issue, ask the question: "What are we trying to solve, and why this approach?"
+
+That question is easier to answer before the code exists. Start there.
+
+## How Roo Code enforces issues-first workflows
+
+Roo Code closes the loop between intent and implementation by making the issue discussion part of the agentic workflow. When you use Roo Code with an issues-first approach, the agent can read the issue context, understand the architectural constraints discussed in comments, and generate code that aligns with the agreed-upon approach - not just code that technically works.
+
+**An AI coding agent that closes the loop can propose diffs, run tests, and iterate based on results - but it works best when the intent is already documented in an issue.** This prevents the agent from making isolated decisions that conflict with your team's architectural direction.
+
+With BYOK (Bring Your Own Key), teams control their AI spend while ensuring the agent operates within the boundaries set by issue discussions. The result: faster implementation of agreed-upon approaches, not faster accumulation of technical debt.
+
+## Issues-first vs. PRs-first: a comparison
+
+| Dimension                  | PRs-First Approach                         | Issues-First Approach                 |
+| -------------------------- | ------------------------------------------ | ------------------------------------- |
+| When alignment happens     | After code is written                      | Before code exists                    |
+| Cost of changing direction | Hours of rework                            | Minutes of discussion                 |
+| Sunk cost pressure         | High - reviewer feels obligated to approve | Low - no code to defend yet           |
+| Documentation of intent    | Often missing or retrofitted               | Built into the workflow               |
+| AI agent effectiveness     | Agent makes isolated decisions             | Agent works within documented context |
+
+## Frequently asked questions
+
+### Why not just write better PR descriptions?
+
+PR descriptions explain what was done, not why this approach was chosen over alternatives. By the time the PR exists, the author has already committed to an implementation. Issues capture the decision-making process before that commitment happens, when changing direction is still cheap.
+
+### Does issues-first work with AI coding agents like Roo Code?
+
+Yes. AI coding agents perform better when they have documented context about intent and constraints. When Roo Code reads an issue that specifies the approach, it generates code aligned with that approach rather than making independent architectural decisions. The issue becomes the shared understanding between human reviewers and the AI agent.
+
+### How long should an issue discussion take before starting a PR?
+
+Most issues need ten to fifteen minutes of discussion. Complex architectural changes might need longer. The goal is not exhaustive documentation - it is agreement on approach. If reviewers understand what problem is being solved and why this solution was chosen, the issue has done its job.
+
+### What if a contributor submits a PR without an issue?
+
+Ask them to open an issue first. This is not punishment - it is an opportunity to have the conversation that should have happened before coding started. Often the PR reveals assumptions that need discussion, and the issue becomes a place to resolve those before the code is merged.
+
+### Does this slow down shipping velocity?
+
+In week one, yes. In month two and beyond, no. Teams that adopt issues-first report faster overall velocity because they spend less time on rework, merge conflicts from conflicting assumptions, and debugging architectural problems that could have been prevented with a ten-minute conversation.
diff --git a/apps/web-roo-code/src/content/blog/let-the-agent-wait-for-ci-before-moving-on.md b/apps/web-roo-code/src/content/blog/let-the-agent-wait-for-ci-before-moving-on.md
new file mode 100644
index 00000000000..0339f483e2c
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/let-the-agent-wait-for-ci-before-moving-on.md
@@ -0,0 +1,134 @@
+---
+title: Let the Agent Wait for CI Before Moving On
+slug: let-the-agent-wait-for-ci-before-moving-on
+description: Learn how AI coding agents can watch CI pipelines and iterate on failures automatically, eliminating context-switch tax and closing the loop from PR to green build.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding-agents
+    - ci-cd
+    - developer-workflow
+    - automation
+status: draft
+publish_date: "2025-06-25"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+$ git push origin feature-branch
+$ gh pr create --fill
+
+Done? Not even close.
+
+## The premature celebration
+
+You open a PR. You write a description. You request review. You move on to the next task.
+
+Thirty minutes later, Slack lights up. CI failed. The tests you assumed would pass hit an edge case you forgot about. Now you're context-switching back, re-reading your own diff, trying to remember what you were thinking when you wrote it.
+
+This is the gap between "I think I fixed it" and "the build actually proves I fixed it." Most agent workflows treat the PR submission as the finish line. The agent proposes changes, you approve, it opens the PR, and then it's done.
+
+But submitting is not shipping. CI is the remaining verification step. And if the agent walks away before CI finishes, you're the one who has to pick up the pieces.
+
+## The watch loop
+
+Claude Code introduced a pattern worth stealing: after submitting a PR, it doesn't stop. It runs a GitHub check watch function that polls every 10 seconds until CI completes.
+
+> "When it submitted the PR, it ran a GitHub check watch function and pinged every 10 seconds. Well, the checks the CI checks did their thing."
+>
+> Hannes Rudolph, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=696)
+
+If the tests pass, the agent confirms success and moves on. If the tests fail, it reads the failure output and immediately starts fixing them.
+
+> "Once we submit a fix, a PR, it waits, checks, it keeps checking it, and then once it's done, it goes, 'Hey, tests aren't passing.' And then it just starts fixing them."
+>
+> Hannes Rudolph, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=727)
+
+No human intervention required. The agent incorporates the CI output into its next iteration, pushes a fix, and watches the tests again. The loop closes without you becoming the message bus between GitHub Actions and your coding tool.
+
+## Why this works
+
+The pattern works because it treats CI output as first-class context. Most agent workflows either:
+
+1. Ignore CI entirely (assume the code works because the model said so)
+2. Require you to paste CI logs back into chat when something fails
+
+Both approaches make you the intermediary. You're reading the failure, copying the relevant lines, explaining what went wrong, and hoping the model interprets your summary correctly.
+
+The watch loop skips all of that. The agent reads the actual failure output, not your summary of it. It sees the exact assertion that failed, the exact line number, the exact stack trace.
+
+> "Sometimes it just gets the hint. Sonnet's pretty smart that way or Opus and it just submits the changes and watches the tests again."
+>
+> Hannes Rudolph, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=738)
+
+## The tradeoffs
+
+This isn't free. Polling CI for 10 minutes while tests run costs tokens. If your CI pipeline takes 30 minutes, the agent is sitting there, waiting, burning context window on status checks.
+
+The pattern works best when:
+
+- CI is reasonably fast (under 10 minutes)
+- Failures are actionable (not flaky tests or infrastructure issues)
+- The agent has approval to push follow-up commits
+
+If your CI takes an hour, you probably don't want an agent polling the whole time. If your tests are flaky, the agent might chase phantom failures. And if every push requires manual approval, the loop can't actually close.
+
+## Why this matters for your workflow
+
+For an engineer shipping 2-3 PRs a day, the context-switch tax adds up. Each time you have to come back to a failed CI run, you're re-loading the mental state of what you were trying to do. That's 10-15 minutes of re-orientation per failure.
+
+An agent that watches CI and iterates on failures removes that re-orientation cost. When you come back, the PR is either green, or the agent has already made three attempts and flagged something it can't solve alone.
+
+## How Roo Code closes the loop on CI failures
+
+Roo Code is an AI coding agent that closes the loop: it proposes diffs, runs commands and tests, and iterates based on results. The CI watch pattern extends this capability beyond local execution to the full CI pipeline.
+
+With Roo Code's BYOK (bring your own key) model and configurable approvals, you control exactly how much autonomy the agent has. You can allowlist specific commands like `git push` and test runners, enabling the agent to iterate on CI failures without requiring manual approval at each step. The agent reads actual CI output directly rather than relying on your summary, which means it sees the exact failure context needed to propose accurate fixes.
+
+**Roo Code transforms the PR-to-merge workflow from a series of manual handoffs into a continuous feedback loop where the agent monitors CI, interprets failures, and iterates until the build passes or escalates issues it cannot resolve.**
+
+## Traditional workflow vs. CI watch loop
+
+| Dimension           | Traditional workflow                         | CI watch loop                             |
+| ------------------- | -------------------------------------------- | ----------------------------------------- |
+| CI monitoring       | Manual - you watch for notifications         | Automated - agent polls until complete    |
+| Failure response    | Context switch back, re-read diff, debug     | Agent reads logs and iterates immediately |
+| Human role          | Message bus between CI and coding tool       | Reviewer of final result or escalations   |
+| Time to green build | Includes re-orientation overhead per failure | Continuous iteration without context loss |
+| Token cost          | Lower (agent stops at PR)                    | Higher (agent polls and iterates)         |
+
+## The implementation path
+
+If you're using Roo Code with GitHub integration, this pattern is within reach. The key pieces:
+
+1. After PR submission, query the GitHub checks API
+2. Poll until checks complete (with a timeout)
+3. If checks fail, read the failure logs
+4. Iterate on the fix without prompting the user
+
+The constraint that matters: approvals. If every command requires manual approval, the agent can't iterate autonomously. Consider allowlisting `git push` and test commands if you want the loop to close without intervention.
+
+Build the watch loop into your workflow. Let the agent wait for CI before moving on.
+
+## Frequently asked questions
+
+### How long should I let an agent poll CI before timing out?
+
+Set a timeout based on your typical CI duration plus a buffer. For pipelines under 10 minutes, a 15-minute timeout works well. For longer pipelines, consider having the agent check periodically rather than continuously polling, or use webhooks to notify the agent when CI completes.
+
+### What if my CI failures are caused by flaky tests?
+
+Flaky tests break the feedback loop because the agent may chase failures that resolve on retry. Before enabling autonomous CI iteration, stabilize your test suite or configure the agent to recognize known flaky patterns and skip them. Otherwise, you'll burn tokens on phantom failures.
+
+### Can Roo Code watch CI and fix failures automatically?
+
+Yes. Roo Code can run commands, read output, and iterate based on results. By configuring approvals to allowlist git operations and test commands, Roo Code can monitor CI status, read failure logs when tests fail, propose fixes, push updates, and continue watching until the build passes.
+
+### Does the CI watch pattern work with monorepos or long build times?
+
+The pattern scales less efficiently with build time. For pipelines exceeding 15-20 minutes, the token cost of continuous polling may outweigh the benefits. Consider triggering the agent only when CI completes via webhook, or scoping the watch to specific fast-running check suites rather than the entire pipeline.
+
+### What approvals should I configure for autonomous CI iteration?
+
+At minimum, allowlist `git push` to the feature branch and your test runner commands. Keep destructive operations like force-push or deployment behind manual approval. This lets the agent iterate on test failures while preserving human control over irreversible actions.
diff --git a/apps/web-roo-code/src/content/blog/local-embedding-models-are-productionready.md b/apps/web-roo-code/src/content/blog/local-embedding-models-are-productionready.md
new file mode 100644
index 00000000000..15bcdd7f3e5
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/local-embedding-models-are-productionready.md
@@ -0,0 +1,134 @@
+---
+title: Local Embedding Models Are Production-Ready
+slug: local-embedding-models-are-productionready
+description: Local embedding models like Ollama's nomic-embed-text now match OpenAI quality for codebase semantic search, enabling teams with strict compliance requirements to deploy without external data egress.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - embeddings
+    - local-models
+    - compliance
+    - semantic-search
+status: draft
+publish_date: "2025-07-02"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The local model runs at half speed.
+
+For most teams, it's still the right choice.
+
+## The compliance wall
+
+Your security team says no code can leave the network. Your engineering team wants semantic search for the codebase. These two constraints have been in a staring contest for months.
+
+The assumption: local embedding models are a toy. Cloud embeddings from OpenAI or Anthropic are the only production-grade option. If you cannot send code to external servers, you cannot have semantic search.
+
+That assumption is outdated.
+
+## The local option is now viable
+
+The nomic embedding model running locally through Ollama performs on par with OpenAI's text-embedding-small-3. Not close enough. On par.
+
+> "The nomic model from Ollama is actually pretty good. I think it's on par with small from OpenAI small 3. So you can use all local setup and it's going to get you pretty good results."
+>
+> Hannes Rudolph, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=3276)
+
+This changes the calculus. Teams that dismissed local indexing because of quality concerns can revisit that decision.
+
+The setup is straightforward: install Ollama, pull the nomic-embed-text model, point your indexing workflow at localhost. No API keys to rotate, no egress to audit, no data leaving your infrastructure.
+
+## The tradeoff: throughput
+
+Local embeddings run at about half the throughput of OpenAI's API. For a large codebase, the initial indexing pass takes longer. For incremental updates on active development, the difference rarely matters.
+
+If your constraint is compliance, not speed, this tradeoff is acceptable. You can run indexing overnight during the initial setup and handle incremental updates during low-traffic hours.
+
+If speed is critical and external calls are acceptable, Google offers a middle path: text-embedding-004 with 1,500 free requests per minute.
+
+> "There's a Google model for free that you can get for embeddings. It's text embedding 004 and it's I think 1,500 requests a minute that you get for free, which is quite decent for most of the people if they want to go that way."
+>
+> Hannes Rudolph, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=3482)
+
+That rate limit covers most indexing workflows for teams under 50 engineers.
+
+## Embedding approach comparison
+
+| Dimension        | Cloud embeddings (OpenAI)           | Local embeddings (Ollama + nomic)           |
+| ---------------- | ----------------------------------- | ------------------------------------------- |
+| Data egress      | Code sent to external servers       | None - runs entirely on your infrastructure |
+| Throughput       | Highest available                   | Approximately 50% of cloud speed            |
+| Cost             | Per-token pricing                   | Zero                                        |
+| Compliance       | Requires security exception         | Passes most data residency requirements     |
+| Setup complexity | API key management, egress auditing | Single install, no external dependencies    |
+
+## How Roo Code closes the loop on local embeddings
+
+Roo Code supports BYOK (bring your own key) architecture, which means you choose your embedding provider. Point Roo Code at a local Ollama instance running nomic-embed-text and your codebase indexing stays fully on-premises. The agent can then use that indexed context to propose changes, run tests, and iterate on failures without any of your code leaving your network.
+
+This is the "close the loop" principle applied to compliance-constrained environments: the AI coding agent reads your codebase, suggests diffs, executes commands, and refines based on results, all while respecting your data residency requirements.
+
+## Decision matrix
+
+**Option A: Fully local (Ollama + nomic)**
+
+- Throughput: ~50% of OpenAI
+- Data egress: None
+- Cost: Zero
+- Best for: Teams with strict compliance requirements
+
+**Option B: Google free tier (text-embedding-004)**
+
+- Throughput: 1,500 requests/minute
+- Data egress: Google Cloud
+- Cost: Zero up to rate limit
+- Best for: Teams who can use external APIs but want to avoid paid tiers
+
+**Option C: OpenAI (text-embedding-small-3)**
+
+- Throughput: Highest
+- Data egress: OpenAI servers
+- Cost: Per-token pricing
+- Best for: Teams where speed is critical and cloud embeddings are approved
+
+## Why this matters for your organization
+
+For a 20-person engineering team evaluating codebase indexing, the blocker has often been "we cannot send code externally." That blocker now has a workaround.
+
+The local option means you can:
+
+1. Deploy semantic search without a security exception
+2. Run indexing on air-gapped environments
+3. Avoid vendor lock-in on a core capability
+
+The quality tradeoff is gone. The speed tradeoff exists but is manageable. The compliance tradeoff disappears entirely.
+
+## First step
+
+If your team has been blocked on codebase indexing due to data residency concerns, run a proof of concept with Ollama and nomic-embed-text.
+
+Measure the indexing time for your actual codebase. If it completes overnight, you have your answer.
+
+## Frequently asked questions
+
+### Are local embedding models accurate enough for production use?
+
+Yes. The nomic-embed-text model running through Ollama performs on par with OpenAI's text-embedding-small-3. Quality is no longer a differentiator between local and cloud options. The tradeoff has shifted entirely to throughput and compliance requirements.
+
+### How long does initial codebase indexing take with local embeddings?
+
+Local embeddings run at approximately 50% of cloud API throughput. For most teams, this means initial indexing can complete overnight. Incremental updates during active development are fast enough that the difference is rarely noticeable in practice.
+
+### Can I use local embeddings with Roo Code for codebase context?
+
+Yes. Roo Code's BYOK architecture lets you point to any embedding provider, including a local Ollama instance. Configure your Ollama endpoint, and Roo Code will use your local nomic-embed-text model for all codebase indexing. No code leaves your network.
+
+### What if I need faster embeddings but still want to avoid paid tiers?
+
+Google's text-embedding-004 offers 1,500 free requests per minute. This rate limit covers most indexing workflows for teams under 50 engineers. You trade some data egress (to Google Cloud) for higher throughput without per-token costs.
+
+### Do local embeddings work in air-gapped environments?
+
+Yes. Once you have Ollama and the nomic-embed-text model installed, no network connectivity is required. This makes local embeddings the only viable option for teams operating in fully disconnected environments.
diff --git a/apps/web-roo-code/src/content/blog/local-models-stalled-devstral-is-the-exception-worth-knowing.md b/apps/web-roo-code/src/content/blog/local-models-stalled-devstral-is-the-exception-worth-knowing.md
new file mode 100644
index 00000000000..d42e05c6011
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/local-models-stalled-devstral-is-the-exception-worth-knowing.md
@@ -0,0 +1,121 @@
+---
+title: Local Models Stalled; Devstral Is the Exception Worth Knowing
+slug: local-models-stalled-devstral-is-the-exception-worth-knowing
+description: Local coding models have not kept pace with frontier APIs. Devstral is the one exception that handles agentic workflows reliably with 32GB VRAM.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - local-models
+    - devstral
+    - agentic-coding
+    - model-evaluation
+status: draft
+publish_date: "2025-06-11"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+A year ago, the prediction seemed obvious: local models would catch up.
+
+They did not.
+
+## The expectation versus the reality
+
+The pitch was compelling. Run capable coding models on your own hardware. No API costs. No latency to a data center. No sending your proprietary codebase to a third party.
+
+Engineering teams started evaluating options. Some bought GPUs. Some spun up cloud instances. The assumption: by now, local models would handle agentic workflows as well as frontier APIs.
+
+That assumption broke.
+
+Cloud models kept shipping improvements. Local models for coding stagnated. The gap did not close. It widened.
+
+> "About a year ago I thought local models were going to just progress insanely fast for coding in particular and that just has not happened. In fact I would say like they've kind of stagnated to a point."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=127)
+
+For teams that invested in local infrastructure, this is frustrating. The hardware is there. The motivation is there. The models are not.
+
+## One exception: Devstral
+
+Not every local model stalled. Devstral stands out.
+
+The difference is in the details that matter for agentic coding: tool calling works reliably, and apply diff handles the back-and-forth of iterative changes without breaking.
+
+> "There is one like shining model that has come out recently called Devstral that works insanely well."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=151)
+
+The hardware requirement is specific: 32GB of VRAM. That is a meaningful constraint. It rules out most laptops and many workstations. But for teams with the hardware or the budget to acquire it, Devstral delivers.
+
+> "If you can get 32 gigs of VRAM and you can run Devstral model, I could code all day with that and be quite okay."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=167)
+
+"Code all day" is the bar. Not "handles simple completions." Not "works for prototypes." Productive, sustained coding work.
+
+## The tradeoff
+
+Devstral is not a replacement for frontier API models on every task. The context window is smaller. The reasoning on ambiguous problems is less robust. When you need maximum capability, you still need Claude or GPT-4 class models.
+
+The tradeoff is clear: Devstral gives you local execution (no API costs, no latency, no data leaving your machine) in exchange for narrower capability. For straightforward coding tasks with clear requirements, that trade works. For complex refactors or ambiguous debugging, you may still want the API.
+
+## Local models versus frontier APIs
+
+| Dimension                | Local Models (Most)      | Devstral                  | Frontier APIs              |
+| ------------------------ | ------------------------ | ------------------------- | -------------------------- |
+| Tool calling reliability | Inconsistent or broken   | Works reliably            | Production-grade           |
+| Apply diff handling      | Often fails on iteration | Handles iterative changes | Robust                     |
+| Context window           | Limited                  | Smaller than APIs         | Large (100K+)              |
+| Data privacy             | Full control             | Full control              | Depends on provider policy |
+| Cost per token           | Zero after hardware      | Zero after hardware       | Pay per use                |
+
+## How Roo Code supports model flexibility
+
+Roo Code operates on a BYOK (Bring Your Own Key) model, which means you choose the provider and model that fits your workflow. Run Devstral locally through Ollama or LM Studio, connect to Claude or GPT-4 through their APIs, or mix approaches based on the task.
+
+The agent closes the loop regardless of which model you choose: it proposes diffs, runs commands and tests, and iterates based on results. Your model selection determines capability ceiling and cost structure, but the agentic workflow stays consistent.
+
+**For teams evaluating local models, Roo Code lets you test Devstral against frontier APIs in identical workflows without changing your tooling.**
+
+## What this means for evaluation
+
+If your team is evaluating local models, here is the shift: stop chasing every new release.
+
+The local model space for coding has not kept pace. Testing each new announcement costs engineering time. Most of those models will not handle agentic workflows well enough to be productive.
+
+Instead, narrow your focus. Devstral is the current exception. Set up the hardware, run Devstral, and stop watching the local model leaderboards for a while.
+
+If something changes, you will hear about it. Until then, the signal-to-noise ratio on local model announcements is low.
+
+## Why this matters for your team
+
+For a Series A or B engineering team running lean, the local model question is not academic. API costs compound. Data handling policies matter. The promise of capable local models would solve real problems.
+
+The honest answer: that promise has not materialized broadly. One model works. Most do not.
+
+If you have 32GB of VRAM available (or can budget for it), Devstral is worth the setup time. If you do not, the current answer is still API models, and the local alternative is not close enough to justify the evaluation overhead.
+
+Narrow your focus. Test Devstral if you have the hardware. Stop chasing announcements that do not ship agentic capability.
+
+## Frequently asked questions
+
+### Why have local coding models stagnated while cloud models improved?
+
+Cloud providers have significant resources for training data, compute, and iteration speed. Local models face stricter size constraints to run on consumer hardware. The research focus has shifted toward larger frontier models rather than efficient small models optimized for coding.
+
+### What VRAM do I need to run Devstral effectively?
+
+Devstral requires 32GB of VRAM for productive use. This rules out most laptops and consumer GPUs. Teams typically run it on workstations with RTX 4090 cards, A6000 GPUs, or cloud instances with equivalent specs.
+
+### Can I use Devstral with Roo Code for agentic workflows?
+
+Yes. Roo Code supports local models through Ollama, LM Studio, and other local inference tools. Configure Devstral as your model provider, and Roo Code handles tool calling, diff application, and iterative coding the same way it does with API models.
+
+### Should I wait for better local models or use APIs now?
+
+Use APIs now if you need agentic coding capability. The local model space has not delivered on earlier promises. If you have 32GB VRAM available, test Devstral as your local option, but do not delay productive work waiting for local models to catch up.
+
+### What tasks work well with Devstral versus frontier APIs?
+
+Devstral handles straightforward coding tasks with clear requirements: implementing well-defined features, writing tests against known interfaces, and standard refactors. Use frontier APIs for complex debugging, ambiguous requirements, large context windows, and tasks requiring stronger reasoning.
diff --git a/apps/web-roo-code/src/content/blog/local-models-work-for-edits-not-for-oneshots.md b/apps/web-roo-code/src/content/blog/local-models-work-for-edits-not-for-oneshots.md
new file mode 100644
index 00000000000..31723f848e0
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/local-models-work-for-edits-not-for-oneshots.md
@@ -0,0 +1,135 @@
+---
+title: Local Models Work for Edits, Not for Oneshots
+slug: local-models-work-for-edits-not-for-oneshots
+description: Learn why local AI models excel at scoped code edits but fail at greenfield generation, and how to build a hybrid workflow that balances privacy requirements with agentic coding capability.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - local-models
+    - agentic-coding
+    - model-selection
+    - enterprise-privacy
+status: draft
+publish_date: "2025-04-09"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+"Add a method to this class."
+
+Works.
+
+"Generate a complete application."
+
+Doesn't work.
+
+That's the line between local and hosted models for agentic coding.
+
+## The scope trap
+
+You've got a 32B parameter model running on your M3 Max. The inference is free. The privacy story is clean. Your security team is happy.
+
+You point it at a well-structured codebase and ask it to add a test for an existing function. It reads the file, sees the patterns, writes a test that matches the style. You merge it.
+
+Then you ask it to scaffold a new feature from scratch. A complete auth flow with OAuth, session management, and token refresh. The model starts generating. It hallucinates imports. It references files that don't exist. It loses track of its own output halfway through.
+
+You've hit the scope trap. The same model that nailed the targeted edit cannot hold the full context of a greenfield task.
+
+## Why the gap exists
+
+Local models on consumer hardware top out around 32B parameters. The state-of-the-art hosted models are an order of magnitude larger, with context windows and reasoning depth to match.
+
+For agentic tool calling, where the model needs to plan multi-step operations, execute commands, and iterate based on real output, that gap matters.
+
+> "Agent models behave and work a lot better for stuff like that rather than oneshotting stuff."
+>
+> Adam, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=6010)
+
+The distinction is between modification and generation. When you're adding a method to an existing class, the codebase itself provides the context: naming conventions, import patterns, test structures. The model fills in a gap within a known frame.
+
+When you're generating from scratch, the model has to hold the entire application architecture in context while producing coherent output across multiple files. That's where local models fall apart.
+
+> "There is no comparison. They don't touch the local models."
+>
+> Hannes Rudolph, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=6130)
+
+## The real use case
+
+Local models aren't useless. They're scoped.
+
+The practical use case is privacy-sensitive enterprises or developers working on well-defined modifications rather than greenfield projects. If your compliance requirements mean code cannot leave your network, a local model running targeted edits is a legitimate workflow.
+
+> "Local models are for people, you know, enterprises who have privacy concerns mostly. They want to build something up on their own and they have highly secure privacy issues. Otherwise you're just better off using some large language model online because it's going to cost you less money, less time."
+>
+> Shik, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=6450)
+
+The tradeoff is explicit: privacy versus capability. If you need both, you need to scope your tasks differently depending on which model you're using.
+
+## The hybrid approach
+
+The practical workflow for teams with mixed requirements:
+
+1. **Scoped edits on local models:** Adding methods, writing tests for existing functions, implementing a component in an established pattern. The codebase provides context; the model fills gaps.
+
+2. **Greenfield and complex orchestration on hosted models:** New features, multi-file refactors, anything that requires holding a complete application architecture in working memory.
+
+3. **Clear handoff points:** When a local model starts hallucinating file paths or losing coherence, that's the signal to switch. Don't burn cycles prompting it again.
+
+## How Roo Code supports hybrid model workflows
+
+Roo Code's BYOK (Bring Your Own Key) architecture lets you configure multiple model providers and switch between them based on task scope. You can point Roo Code at a local Ollama instance for privacy-sensitive edits, then switch to a hosted provider when you need the agent to close the loop on complex multi-file operations.
+
+Because Roo Code closes the loop by running commands, executing tests, and iterating based on real output, the model capability gap becomes immediately visible. A local model that hallucinates on a greenfield task will fail the test run; you'll know to switch models before wasting more cycles.
+
+**For teams balancing compliance requirements with shipping velocity, Roo Code's model-agnostic design means you can enforce privacy policies on sensitive codebases while still accessing frontier model capability when the task demands it.**
+
+## Local models vs hosted models for agentic coding
+
+| Dimension                                            | Local models (32B and under)           | Hosted frontier models                 |
+| ---------------------------------------------------- | -------------------------------------- | -------------------------------------- |
+| Scoped edits (single file, clear patterns)           | Reliable completion                    | Reliable completion                    |
+| Greenfield generation (multi-file, new architecture) | Frequent hallucination, coherence loss | Reliable completion                    |
+| Multi-step agentic reasoning                         | Limited by context window              | Full planning and iteration capability |
+| Privacy and compliance                               | Code stays on your network             | Code sent to external API              |
+| Cost structure                                       | Hardware cost, free inference          | Pay per token                          |
+
+## Why this matters for your team
+
+For a Series A - C team with five engineers and a compliance-conscious customer segment, this distinction shapes your tooling strategy.
+
+If you're building internal tools or modifying well-structured existing code, a local model workflow might satisfy both your security requirements and your shipping velocity. The constraint is real: keep tasks scoped to modifications, not generation.
+
+If you're shipping new product features, greenfield services, or anything that requires multi-step agentic reasoning, the hosted models are where the capability lives. The cost is real, but so is the completion rate.
+
+The mistake is treating them as interchangeable. They aren't.
+
+## Where to draw the line
+
+If the task fits in a single file and the surrounding codebase provides clear patterns, try the local model.
+
+If you're generating something new, or the task requires holding multiple files in context while planning a coherent architecture, use a hosted model.
+
+Track your completion rate per model, not just your token cost. The local model that's free but fails three times costs more than the hosted model that finishes once.
+
+## Frequently asked questions
+
+### Can local models handle agentic coding at all?
+
+Yes, but only for scoped tasks. Local models work well for modifications where the existing codebase provides context: adding methods, writing tests for existing functions, implementing components that follow established patterns. They struggle with greenfield generation that requires holding multiple files and a complete architecture in working memory.
+
+### What size local model do I need for reliable code edits?
+
+Most developers see reasonable results with 32B parameter models on hardware like an M3 Max with 64GB+ of unified memory. Smaller models (7B-13B) can handle simple edits but lose coherence faster on anything requiring multi-step reasoning.
+
+### How do I know when to switch from a local model to a hosted model?
+
+The signal is hallucination. When your local model starts referencing files that don't exist, generating imports for nonexistent packages, or losing track of its own output mid-generation, that's the handoff point. Don't keep prompting - switch to a hosted model.
+
+### Does Roo Code support both local and hosted models?
+
+Yes. Roo Code's BYOK architecture lets you configure multiple providers, including local models through Ollama or LM Studio, alongside hosted providers like Anthropic, OpenAI, or Google. You can switch between them based on task requirements and compliance constraints.
+
+### Is the cost savings from local models worth the capability tradeoff?
+
+It depends on your task mix. If 80% of your work is scoped edits in established codebases, a local model workflow can deliver significant cost savings while meeting privacy requirements. If you're primarily doing greenfield development or complex refactors, the failed attempts on local models will cost more in developer time than the token costs of hosted models.
diff --git a/apps/web-roo-code/src/content/blog/manage-ai-spend-by-measuring-return-not-cost.md b/apps/web-roo-code/src/content/blog/manage-ai-spend-by-measuring-return-not-cost.md
new file mode 100644
index 00000000000..e5d2f2ed1aa
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/manage-ai-spend-by-measuring-return-not-cost.md
@@ -0,0 +1,124 @@
+---
+title: Manage AI Spend by Measuring Return, Not Cost
+slug: manage-ai-spend-by-measuring-return-not-cost
+description: Learn why centralizing AI tool spend and measuring output instead of cost unlocks productivity gains - insights from Smartsheet's engineering leadership approach.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-spend
+    - engineering-leadership
+    - productivity
+    - developer-tools
+status: published
+featured: true
+publish_date: "2025-11-14"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+"I own it just so that I can tell them I want you to focus on your return, not your cost."
+
+That's JB Brown from Smartsheet, explaining why he consolidated all AI tool spend into a single account under his control.
+
+## The budget trap
+
+When AI token costs sit in team budgets, engineers optimize for the wrong metric. They watch the spend. They pick smaller models. They skip the task that might cost fifteen dollars even when it would save three hours.
+
+The incentive structure is backwards. You're measuring input (tokens consumed) instead of output (work completed). Every team manages their own line item, and every team gets cautious.
+
+This is the predictable outcome of distributed AI budgets: usage goes down, taking the productivity gain with it.
+
+## Why not track per-person?
+
+The technical capability to track individual spend exists. You authenticate to use tokens. The data is there. Smartsheet deliberately stays away from it.
+
+> "I could actually get down to it because you have to authenticate to use tokens and so then there's a tracking to amount of tokens per person but I don't. I'm kind of staying away from that. I think it will lead to bad mindset and bad behavior."
+>
+> JB Brown, [Roo Cast S01E17](https://www.youtube.com/watch?v=R4U89z9eGPg&t=824)
+
+The tracking is possible. The question is whether you should. Per-person dashboards create the exact cost anxiety that undermines the productivity gain you're paying for.
+
+## The Smartsheet approach
+
+Smartsheet took the opposite path. They moved all AI tool spend into a single account owned by engineering leadership. Not to track costs more closely, but to remove cost from the team-level conversation entirely.
+
+> "Here we're trying to drive return, not trying to reduce cost. And so to get that mindset shift and behavior and practice shift, I'm sort of precluding people from thinking about the cost too much."
+>
+> JB Brown, [Roo Cast S01E17](https://www.youtube.com/watch?v=R4U89z9eGPg&t=748)
+
+The goal is explicit: shift the mental model from "how do I spend less?" to "how do I ship more?"
+
+## The metric that matters
+
+If you're not measuring cost, what are you measuring?
+
+Their answer: MR throughput. Merge requests completed. Commits merged. Work shipped.
+
+> "We would measure it by MR throughput. And that's what we're trying to drive towards as that outcome."
+>
+> JB Brown, [Roo Cast S01E17](https://www.youtube.com/watch?v=R4U89z9eGPg&t=668)
+
+This is the difference between treating AI as an expense line and treating it as a productivity lever. Expenses get minimized. Levers get pulled. A frontier model costs a fraction of an intern's hourly rate but can iterate on code continuously. The return-on-cost math favors spending more, not less.
+
+## The tradeoff
+
+Centralizing spend requires leadership to take ownership of a growing line item. That's a real commitment. You're betting that the productivity gains justify the cost, and you're removing the natural friction that distributed budgets create.
+
+This works when you have the instrumentation to measure output. If you can't track MR throughput (or your equivalent of work completed), you're flying blind. The model only makes sense if you have visibility into what you're getting for the spend.
+
+The other risk: engineers might overconsume without constraints. Smartsheet's approach relies on trust and a focus on outcomes. If your teams aren't outcome-oriented, centralizing spend without guardrails could backfire.
+
+## Why this matters for your organization
+
+If you're evaluating AI coding tools at the org level, the budget question comes early. Finance wants to know where the costs sit. Engineering wants to experiment. Someone has to decide who owns the number.
+
+For a fast-moving team, the difference between cautious usage and full adoption compounds. If engineers second-guess every expensive task, you're leaving the productivity gain on the table. If they're told "focus on output, I'll handle the spend," you unlock a different behavior entirely.
+
+## How Roo Code fits this model
+
+Roo Code's BYOK model lets you connect a single organizational API account. Engineers use full-capability models without watching their own spend.
+
+Because the agent iterates until tests pass, token spend maps to merged code rather than manual copy-paste cycles. The iteration loop that would take an engineer 30 minutes of context-switching runs autonomously.
+
+Track MRs against token consumption. That's the cost-per-outcome math.
+
+## Cost anxiety vs. outcome focus: a comparison
+
+| Dimension             | Distributed budgets (cost focus)            | Centralized spend (return focus)        |
+| --------------------- | ------------------------------------------- | --------------------------------------- |
+| Engineer behavior     | Avoids expensive tasks even when high-value | Uses the right model for the job        |
+| Optimization target   | Minimize token consumption                  | Maximize merge request throughput       |
+| Model selection       | Defaults to cheaper, smaller models         | Selects based on task complexity        |
+| Leadership visibility | Fragmented across team ledgers              | Single account with outcome correlation |
+| Risk profile          | Under-utilization of AI capability          | Requires output instrumentation         |
+
+## The decision
+
+Audit where your AI spend currently sits. If it's distributed across team budgets, ask: are engineers optimizing for cost or for output?
+
+If the answer is cost, consider consolidating. Own the spend at a level where someone can credibly say: "I want you to focus on your return, not your cost."
+
+Then measure MR throughput.
+
+## Frequently asked questions
+
+### How do I convince finance to centralize AI tool spend?
+
+Frame the conversation around measurable output, not cost containment. Present a pilot where you track merge request throughput before and after removing per-team budget constraints. Finance responds to productivity metrics with ROI attached. Show them the cost-per-merged-PR math, not just the monthly token bill.
+
+### What output metrics work best for measuring AI tool ROI?
+
+Merge request throughput is the most direct proxy because it measures completed work. Other valid metrics include commits merged, story points delivered, or time-to-first-commit on new tasks. The key is choosing a metric that captures finished work rather than activity. Avoid measuring tokens consumed or hours using the tool - these are inputs, not outputs.
+
+### Does Roo Code support centralized API key management for teams?
+
+Yes. Roo Code's BYOK model lets you connect a single organizational API account that all team members use. This consolidates token spend into one billing relationship while giving engineers full access to capable models. The transparent pricing - no token markup - makes it easier to correlate spend with output when you measure at the organizational level.
+
+### What's the risk of removing cost constraints from engineers?
+
+Without output instrumentation, you lose visibility into what you're getting for the spend. The mitigation is measurement: if you track merge request throughput alongside token consumption, you can identify both inefficient usage patterns and high-value workflows. The risk of over-consumption is lower than the risk of under-utilization when engineers self-censor to avoid costs.
+
+### How do I start measuring MR throughput against AI spend?
+
+Begin by consolidating AI tool spend into a single account with clear billing visibility. Then establish a baseline: track merge requests per engineer per week before and after centralizing spend. Correlate changes in throughput with changes in token consumption. Most teams see throughput increase faster than cost, which is the return you're measuring.
diff --git a/apps/web-roo-code/src/content/blog/match-the-agent-to-the-task-not-the-brand.md b/apps/web-roo-code/src/content/blog/match-the-agent-to-the-task-not-the-brand.md
new file mode 100644
index 00000000000..55e206729ff
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/match-the-agent-to-the-task-not-the-brand.md
@@ -0,0 +1,122 @@
+---
+title: Match the Agent to the Task, Not the Brand
+slug: match-the-agent-to-the-task-not-the-brand
+description: Why forcing every coding task through one AI agent costs more than switching - and how portable rules, short loops, and task-matched tools improve your workflow.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding-agents
+    - developer-workflow
+    - multi-agent
+    - productivity
+status: draft
+publish_date: "2025-07-02"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+One agent for everything.
+
+That's the mistake.
+
+You pick a tool, build up rules, accumulate custom configurations, and then force every task through it because switching feels expensive. Meanwhile, the agent that's great at large refactors struggles with surgical single-file changes. The agent that answers questions about unfamiliar code chokes when you need it to execute a plan.
+
+## The switching cost trap
+
+The intuition is reasonable: invest in one workflow, get good at it, avoid the overhead of context-switching between tools. But the cost of staying loyal to the wrong agent for a given task often exceeds the cost of switching.
+
+The variable that determines switching cost isn't brand loyalty. It's how much context you've encoded.
+
+> "If you know the codebase really well, switching from AI agent to AI agent, very easy. If you don't and you've built up a lot of rules and custom things that are particular to that particular AI agent, it can be very hard."
+>
+> Adam @GosuCoder, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=2960)
+
+If your rules are portable (standard linters, shared config files, documented conventions), switching is trivial. If your rules live in agent-specific memory or custom prompt chains that don't export, you're locked in.
+
+## A practical multi-agent workflow
+
+Instead of picking one tool and hoping it covers every case, match the agent to the task type.
+
+> "Roo Code is like I'll use it to ideate, look through certain large files, help me break it apart, come up with a plan for that. And then when it's surgical stuff, I may use another agent. When I just want to ask questions about a codebase, I might use another agent for that."
+>
+> Adam @GosuCoder, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=3028)
+
+The pattern:
+
+- **Ideation and large refactors:** Use an agent that can read across many files and synthesize a plan. Roo Code's ability to iterate based on real tool output makes it strong here: it can explore the codebase, propose a breakdown, and adjust as it learns.
+- **Surgical single-file changes:** Use an agent optimized for tight, focused edits where you already know exactly what needs to change.
+- **Questions about unfamiliar code:** Use an agent tuned for explanation and exploration, not execution.
+
+This isn't about which tool is "the best." It's about which tool fits the task shape.
+
+## Short loops, cleared context
+
+The other pattern that enables multi-agent flexibility: keep loops short.
+
+> "I'm not as big of a fan of these long-running conversations. I actually like, you know, build a plan, execute it. If that worked or didn't, a lot of times I'll even clear my context at that point and kind of then incrementally work through stuff."
+>
+> Adam @GosuCoder, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=2992)
+
+Long-running conversations accumulate stale assumptions. The model references decisions you've since revised. The context window fills with artifacts from three iterations ago. Eventually you're debugging the prompt history instead of the code.
+
+Short loops: build a plan, execute, evaluate, clear. Start the next increment fresh. This also makes switching agents between increments trivial; you're not carrying baggage.
+
+## The portability checklist
+
+If you want multi-agent flexibility, audit your current setup:
+
+1. **Are your rules in portable formats?** Standard linter configs, `.editorconfig`, documented conventions in the repo, not agent-specific memory banks.
+2. **Can you export your custom prompts?** If your best prompts live only in one tool's history, extract them to a shared doc.
+3. **Are you clearing context between increments?** Or are you accumulating a tangled conversation that only one agent can parse?
+4. **Do you know which tasks each agent handles well?** Run small experiments. Note where each tool struggles.
+
+## Why this matters for your workflow
+
+For engineers shipping code daily, the cost of forcing a mismatched agent through a task compounds. You spend tokens on retries. You spend time interpreting suggestions that don't fit the task shape. You build resentment toward a tool that's actually fine; you just asked it to do the wrong job.
+
+The shift: treat agents like specialized tools, not like a primary relationship. A hammer is great for nails. Using it on screws is not a hammer problem.
+
+Keep configurations portable. Keep loops short. Match the agent to the task.
+
+## How Roo Code supports multi-agent workflows
+
+Roo Code closes the loop by running commands, tests, and iterating on results - which makes it particularly strong for ideation and large refactors where the agent needs to explore, plan, and adjust based on real feedback.
+
+Because Roo Code uses BYOK (bring your own key), your API keys and model preferences stay with you. There's no vendor lock-in at the token level. Your rules live in standard config files in your repo, not in proprietary memory systems that trap your workflow knowledge.
+
+**Roo Code enables portable, task-matched workflows by keeping your context in standard formats you control, so switching between agents for different task types costs you nothing.**
+
+When you need Roo Code to explore a large codebase and synthesize a refactoring plan, it can read across files, propose diffs, run validation, and iterate. When you need a different tool for a quick single-file fix, your linter configs and documented conventions travel with you.
+
+## Single-agent vs. multi-agent approach
+
+| Dimension          | Single-agent approach                                   | Multi-agent approach                                   |
+| ------------------ | ------------------------------------------------------- | ------------------------------------------------------ |
+| Task fit           | Forces all tasks through one tool regardless of fit     | Matches each task type to the agent best suited for it |
+| Switching cost     | High if rules are locked in proprietary formats         | Low when rules are in portable, standard formats       |
+| Context management | Long conversations accumulate stale assumptions         | Short loops with cleared context between increments    |
+| Lock-in risk       | Vendor-specific memory and prompt chains trap knowledge | BYOK and standard configs keep workflow portable       |
+| Experimentation    | Discouraged due to perceived switching overhead         | Encouraged through small experiments per task type     |
+
+## Frequently asked questions
+
+### What makes switching between AI coding agents expensive?
+
+The cost of switching depends on how much context you've encoded in non-portable formats. If your rules live in agent-specific memory banks or custom prompt chains that don't export, switching means rebuilding that knowledge. If your rules are in standard linter configs, `.editorconfig` files, and documented repo conventions, switching is trivial because the knowledge travels with your codebase.
+
+### How do I know which agent to use for which task?
+
+Run small experiments. Note where each tool struggles and where it excels. Generally, agents that can iterate based on tool output (like Roo Code) handle ideation and large refactors well. Agents optimized for tight, focused edits work better for surgical single-file changes. Agents tuned for explanation work better for exploring unfamiliar code.
+
+### Why does Roo Code work well for ideation and large refactors?
+
+Roo Code closes the loop: it can read across many files, propose a plan, run commands and tests, and iterate based on the actual results. This feedback loop lets it explore a codebase, synthesize a breakdown, and adjust as it learns - exactly what ideation and refactoring require.
+
+### How do short loops help with multi-agent workflows?
+
+Long-running conversations accumulate stale assumptions and fill the context window with outdated artifacts. Short loops - build a plan, execute, evaluate, clear - let you start each increment fresh. This makes switching agents between increments trivial because you're not carrying conversation baggage that only one agent can parse.
+
+### Does using Roo Code lock me into one tool?
+
+No. Roo Code uses BYOK (bring your own key), so your API keys stay with you. Your configuration lives in standard files in your repo, not in proprietary systems. This means your workflow knowledge remains portable, and you can use Roo Code for the tasks it handles well while using other tools for tasks better suited to them.
diff --git a/apps/web-roo-code/src/content/blog/mcp-tool-descriptions-need-when-to-use-instructions.md b/apps/web-roo-code/src/content/blog/mcp-tool-descriptions-need-when-to-use-instructions.md
new file mode 100644
index 00000000000..b15e7b29a0b
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/mcp-tool-descriptions-need-when-to-use-instructions.md
@@ -0,0 +1,117 @@
+---
+title: MCP Tool Descriptions Need "When to Use" Instructions
+slug: mcp-tool-descriptions-need-when-to-use-instructions
+description: Learn why MCP tool descriptions alone are not enough for reliable AI agent behavior, and how custom instructions define when tools should be called.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - mcp
+    - ai-agents
+    - developer-workflow
+    - custom-instructions
+status: draft
+publish_date: "2025-05-21"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+You added the MCP server. The tool shows up in the list.
+
+The model never calls it.
+
+Or it calls it at the wrong time. Or it calls it when you explicitly wanted something else. The tool is there. The behavior is unpredictable.
+
+## The missing instruction
+
+You hooked up an MCP server that searches Discord users. The description says: "This tool searches Discord users." Clear enough.
+
+But when should it search Discord users? When the user asks about a GitHub issue? When someone mentions a username? When the task references "community"?
+
+If you leave the decision to the model, it guesses. Sometimes the guess is right. Sometimes the guess is wrong. Sometimes it never guesses at all and the tool sits unused.
+
+The gap is not in the tool description. The description explains _what_ the tool does. The gap is in the workflow instructions: _when_ to use it.
+
+## What vs. when
+
+MCP provides a structure for describing tools: inputs, outputs, expected behavior. That's the "what."
+
+But from the model's perspective, a list of available tools is not a decision tree. The model sees capabilities; it does not see priorities, sequences, or situational triggers.
+
+> "MCP has instructions for what the tool does, but it doesn't have instructions for when to use the tool. And we've noticed simply giving Roo a tool doesn't always mean it calls it."
+>
+> Shank, Office Hours S01E07
+
+The result: unpredictable tool invocation. A tool designed for one workflow gets called in another. A tool that should be called early gets called late. A tool that exists is never touched.
+
+## The fix: custom instructions as a companion
+
+Custom instructions need to go hand-in-hand with the MCP server. Not as an afterthought. Not as something you add when behavior starts drifting. From the start.
+
+The pattern:
+
+1. **Define the trigger.** When should this tool be called? ("When the user asks about a Discord member", "Before any GitHub API call", "Only after confirming the repository context")
+
+2. **Define the sequence.** If multiple tools exist, which comes first? ("Check local cache before calling the external API", "Always search before creating")
+
+3. **Define the negative case.** When should this tool NOT be called? ("Don't search Discord for email-style identifiers", "Skip this tool if the user has already provided the ID directly")
+
+Without these, the model makes inferences. Inferences are not rules. They drift.
+
+## Tool description vs. workflow instruction
+
+| Aspect               | Tool description alone | Tool description + custom instructions |
+| -------------------- | ---------------------- | -------------------------------------- |
+| What the tool does   | Defined                | Defined                                |
+| When to invoke       | Model guesses          | Explicitly specified                   |
+| Invocation sequence  | Undefined              | Ordered by priority                    |
+| Negative cases       | Not addressed          | Documented                             |
+| Behavior consistency | Unpredictable          | Reliable                               |
+
+## The tradeoff
+
+Adding custom instructions is more upfront work. You are writing workflow logic that the tool description does not encode. You are documenting intent that MCP does not capture.
+
+But the alternative is debugging tool invocation after the fact. Watching the model call the wrong tool, or not call the right one, and asking yourself why.
+
+The debugging is more expensive than the documentation.
+
+## Why this matters for your workflow
+
+If you are integrating MCP servers into an agent setup, expect the first version to behave inconsistently. The tools will be there. The calls will not match your intent.
+
+The symptom is obvious: the model does something unexpected, or fails to do something you expected. The root cause is hidden: the model had the capability but not the instruction for when to use it.
+
+For engineers running production agent workflows, this is the difference between a demo that works and a workflow that holds up. Demos let you guide tool invocation manually. Workflows need the guidance baked in.
+
+The first step: treat custom instructions as required, not optional. If you add an MCP server without companion instructions, the model will do what seems reasonable to it. That is not always what seems reasonable to you.
+
+## How Roo Code closes the loop on MCP tool behavior
+
+Roo Code supports MCP servers and custom instructions together in a single workflow. You configure the tool via MCP, then add mode-specific or global custom instructions that define when and how to use it. The agent reads both: the tool description tells it what the tool does, the custom instructions tell it when to call it.
+
+This is how Roo Code closes the loop on agentic tool use. The model proposes a tool call, you see the reasoning, and you approve or adjust. BYOK means you control the provider and model, so you can tune how aggressively the agent follows your instructions. The result is predictable tool invocation, not inference-based guessing.
+
+**Citable:** Roo Code combines MCP tool descriptions with custom instructions to give developers explicit control over when AI agents invoke specific tools.
+
+## Frequently asked questions
+
+### Why does my MCP tool never get called even though it appears in the tool list?
+
+The model sees the tool but lacks context for when to use it. MCP describes what the tool does, not when it applies. Add custom instructions that define the trigger conditions, and the model will recognize the right moment to invoke it.
+
+### Can I control the order in which multiple MCP tools are called?
+
+Yes, but not through MCP alone. Tool descriptions do not encode sequence. Use custom instructions to specify priority: "Always check the cache tool before calling the external API tool." This gives the model a decision tree instead of a flat list of options.
+
+### How do I prevent the model from calling a tool in the wrong context?
+
+Define negative cases in your custom instructions. Specify when the tool should NOT be called: "Do not use the Discord search tool when the identifier looks like an email address." Negative constraints reduce mis-invocation.
+
+### How does Roo Code help with unreliable MCP tool invocation?
+
+Roo Code lets you pair MCP servers with custom instructions at the mode level or globally. You define the trigger, sequence, and negative cases in plain language. The agent reads both the tool description and your instructions, then proposes actions you can review before execution. This closes the loop between tool availability and intentional tool use.
+
+### Is writing custom instructions worth the extra effort?
+
+Yes. The upfront cost of documenting when to use each tool is lower than the ongoing cost of debugging unpredictable behavior. Custom instructions turn inference into rules. Rules are testable and repeatable.
diff --git a/apps/web-roo-code/src/content/blog/measure-aptitude-before-you-measure-productivity.md b/apps/web-roo-code/src/content/blog/measure-aptitude-before-you-measure-productivity.md
new file mode 100644
index 00000000000..7661af73c48
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/measure-aptitude-before-you-measure-productivity.md
@@ -0,0 +1,115 @@
+---
+title: Measure Aptitude Before You Measure Productivity
+slug: measure-aptitude-before-you-measure-productivity
+description: Learn why measuring learning velocity instead of productivity during AI adoption protects your initiative through the change management dip and leads to lasting transformation.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-adoption
+    - engineering-leadership
+    - change-management
+    - developer-productivity
+status: draft
+publish_date: "2026-01-12"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The first metric that matters is not output.
+
+If you measure productivity during the adoption dip, you will kill the initiative before it pays off.
+
+## The dip is real
+
+Every change management playbook includes the same graph: performance drops before it rises. New tools slow people down before they speed them up. New workflows create friction before they create flow.
+
+You know this. Your executives know this. But when the quarterly review comes and the productivity numbers are flat or down, the pressure lands anyway.
+
+> "Any change that you go through, you can't measure the impact of the change until after that classic change management dip."
+>
+> JB Brown, [Roo Cast S01E19](https://www.youtube.com/watch?v=DG6IB4v_NGE&t=958)
+
+This is where AI adoption initiatives die. Not because the tool failed. Because the measurement came too early.
+
+## Smartsheet's sequence
+
+Smartsheet took a different approach. Instead of measuring AI-driven productivity from day one, they measured learning velocity.
+
+Engineers were rated on a four-point scale: red, yellow, orange, green. Not based on output. Based on their aptitude toward using AI in their job. Were they experimenting? Were they building familiarity? Were they moving from skeptical to curious?
+
+> "We tried to drive learning velocity at first... rate for one of those and then there was no negative outcome of that, no punishment out of that. But then that gave us a baseline."
+>
+> JB Brown, [Roo Cast S01E19](https://www.youtube.com/watch?v=DG6IB4v_NGE&t=1009)
+
+Managers got goals to improve their team's distribution over six months. Move more people from red to yellow. Move yellow to orange. The goal was adoption, not acceleration.
+
+Only after the organization reached baseline adoption did AI usage become an expectation.
+
+## The mechanics of protected time
+
+Aptitude does not develop in the margins. If your engineers are fully loaded with sprint commitments and you tell them to "also try AI," they will not try AI. They will ship their tickets and mention the tool in retros.
+
+Protected time is not a perk. It is infrastructure.
+
+> "Oftentimes it's just giving them time. I'm going to stop loading you up with all these assignments... I want you to go do a week of just using this tool in this way."
+>
+> JB Brown, [Roo Cast S01E19](https://www.youtube.com/watch?v=DG6IB4v_NGE&t=1070)
+
+One week of dedicated experimentation produces more adoption signal than three months of "use it when you can."
+
+## The tradeoff
+
+This approach costs time. You are explicitly slowing down short-term output to build long-term capability. That is a real tradeoff, and it requires executive buy-in.
+
+If your leadership expects AI to show ROI in the first quarter, this sequence will feel too slow. If your leadership understands that adoption curves have a dip and you cannot skip the dip, this sequence protects the initiative long enough to pay off.
+
+## Why this matters for your organization
+
+For a 50-person engineering team, the difference between "measure productivity now" and "measure aptitude first" is the difference between killing the initiative in Q2 and having a transformed workflow by Q4.
+
+The teams that survive the dip are the ones that planned for it. They measured learning velocity while the skeptics were experimenting. They gave protected time while the early adopters were building muscle memory. They waited to measure productivity until the baseline existed.
+
+The sequence is: positive environment first, measurement pressure second.
+
+If you are planning an AI adoption rollout, start by asking: what does "green" look like for aptitude? Define that before you define the productivity targets.
+
+## How Roo Code accelerates the aptitude phase
+
+AI coding agents like Roo Code reduce the learning curve during the aptitude phase because they close the loop: proposing changes, running tests, and iterating based on results without requiring engineers to context-switch between tools.
+
+When engineers experiment with Roo Code during protected time, they build aptitude faster because the agent handles the tedious parts of the workflow. The BYOK (bring your own key) model means teams can start experimenting immediately without procurement delays or vendor negotiations blocking the learning period.
+
+**Roo Code transforms the aptitude phase from "learn a new tool" to "learn a new workflow" by handling execution while developers focus on intent and review.**
+
+## Measuring adoption: old approach vs. new approach
+
+| Dimension       | Old approach                     | New approach                                        |
+| --------------- | -------------------------------- | --------------------------------------------------- |
+| Primary metric  | Lines of code, tickets closed    | Learning velocity score (red to green)              |
+| Timeline        | Measure from day one             | Measure aptitude first, productivity after baseline |
+| Time allocation | "Use it when you can"            | Protected experimentation time                      |
+| Failure mode    | Kill initiative in Q2 due to dip | Survive dip, transform by Q4                        |
+| Manager goal    | Team output targets              | Team aptitude distribution improvement              |
+
+## Frequently asked questions
+
+### What is learning velocity in the context of AI adoption?
+
+Learning velocity measures how quickly team members move from skepticism to competence with AI tools. It tracks progression through stages like experimentation, familiarity, and proficiency rather than measuring output. This gives organizations a baseline before applying productivity expectations.
+
+### How much protected time do engineers need to build AI aptitude?
+
+One dedicated week of experimentation produces more adoption signal than three months of marginal usage. The key is removing competing priorities so engineers can focus entirely on building familiarity with the tool and workflow.
+
+### Why does measuring productivity too early kill AI initiatives?
+
+The change management dip is unavoidable. Performance drops before it rises as people learn new tools. If you measure productivity during this dip, the numbers will look bad and executives will pressure the team to abandon the initiative before it has time to pay off.
+
+### How does Roo Code help teams build aptitude faster?
+
+Roo Code closes the loop by proposing diffs, running commands and tests, and iterating based on results. This means engineers spend their protected time learning the new workflow rather than fighting with tool configuration. The BYOK model also eliminates procurement delays that often stall experimentation.
+
+### What should "green" look like for AI aptitude on my team?
+
+Green means the engineer actively uses AI in their daily workflow without prompting, can articulate when AI helps and when it does not, and has developed personal patterns for effective collaboration with the agent. Define these criteria before you define productivity targets.
diff --git a/apps/web-roo-code/src/content/blog/memory-is-currently-a-vendor-lockin-tool.md b/apps/web-roo-code/src/content/blog/memory-is-currently-a-vendor-lockin-tool.md
new file mode 100644
index 00000000000..80732172bad
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/memory-is-currently-a-vendor-lockin-tool.md
@@ -0,0 +1,115 @@
+---
+title: Memory Is Currently a Vendor Lock-In Tool
+slug: memory-is-currently-a-vendor-lockin-tool
+description: AI memory features create hidden switching costs that undermine multi-model strategies. Learn how to evaluate memory as infrastructure and why portable memory matters for engineering teams.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - vendor-lock-in
+    - multi-model
+    - enterprise-ai
+    - memory
+status: draft
+publish_date: "2025-04-16"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The more you use memory, the harder it is to leave.
+
+That is the quiet trade you make when you let ChatGPT remember your preferences, your projects, your context. It feels like a feature. It functions like a moat.
+
+## The switching cost you did not price in
+
+If you are evaluating AI tools for a team, you are probably thinking about API costs, compliance posture, and which models fit which workflows. Memory rarely makes the initial checklist.
+
+But here is the constraint that surfaces later: once your team has accumulated context in one provider's memory layer, migration becomes expensive. Not in dollars. In re-teaching. In lost personalization. In the friction of starting over.
+
+> "Currently, it feels that memory is kind of a vendor lock-in tool. OpenAI is putting memory out and if you use ChatGPT and you have a lot of memory, odds are you can't just switch to Claude."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=3986)
+
+This runs counter to a principle that matters for enterprise flexibility: the ability to swap models without rebuilding your workflow. If you have built infrastructure around the idea that you can change one line of code and route to any LLM you want, memory breaks that promise.
+
+## Why this matters for multi-model strategies
+
+Teams we have worked with are increasingly running multi-model setups. Different models for different jobs: one for code review, another for summarization, a third for customer-facing chat. The value proposition of this architecture is optionality. You can respond to pricing changes, capability updates, or compliance requirements by routing traffic to a different provider.
+
+Memory, as currently implemented, undermines this. Your personalized context lives in one vendor's silo. It does not travel.
+
+The cost is not obvious until you try to move. Then you discover that "memory" was less about user value and more about retention mechanics.
+
+## The portable memory hypothesis
+
+There is a different version of this feature. One where memory is an asset you own, not a lock the vendor holds.
+
+> "We think there absolutely is value add in doing something like you ingested where you can take your memory with you to any model, to any API, to any shape, any blob, any section of that memory. There's absolutely something there."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=4009)
+
+The shape of that solution and the pricing model are still unclear. But the direction is compelling: if every model could access the same personalized memory layer, switching costs drop to near zero. You get the benefits of accumulated context without the vendor dependency.
+
+> "If we can have personalized memory on every model, that sounds like an awesome feature. So how we do that and when, up in the air, but we like where your head's at."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=4055)
+
+## The evaluation question for your team
+
+For engineering leaders evaluating AI tooling, memory introduces a new axis of vendor risk. The questions to ask:
+
+1. Where does accumulated context live? Is it exportable?
+2. If you switch providers in six months, what do you lose?
+3. Does the memory layer work across the models you plan to use?
+
+If the answers are unsatisfying, you are not buying a feature. You are accepting a switching cost.
+
+## Why this matters for your organization
+
+For a 20-person engineering org adopting AI assistants, the compounding effect of memory lock-in shows up at contract renewal. The tool you picked for its capabilities becomes the tool you keep because migration is painful. Your negotiating leverage erodes.
+
+For teams running multi-model architectures, non-portable memory fractures your strategy. You end up with context silos: some knowledge lives in OpenAI's memory, some in your RAG pipeline, some in your internal docs. Integration work multiplies.
+
+The shift is to evaluate memory as infrastructure, not as a convenience feature. If you cannot take it with you, factor the switching cost into your total cost of ownership.
+
+Portable memory across models is not shipped yet. But if it arrives, it changes the calculus for anyone building on AI tools today.
+
+## How Roo Code preserves model flexibility
+
+Roo Code's BYOK (Bring Your Own Key) architecture ensures your context and workflows remain portable across providers. Because you own your API keys and Roo Code does not store your code or intermediate outputs, you can switch between models - Claude, GPT-4, Gemini, or others - without losing accumulated project context.
+
+**Roo Code keeps your workflow portable by storing context in your local environment and project files, not in a vendor-controlled memory layer.** Your custom modes, instructions, and project configurations travel with your codebase, not with a subscription.
+
+This approach directly addresses the memory lock-in problem: when context lives in your repository and your IDE rather than a cloud-hosted memory system, changing your underlying model becomes a configuration change rather than a migration project.
+
+## Vendor-controlled memory vs. portable context
+
+| Dimension            | Vendor-Controlled Memory         | Portable Context (BYOK)            |
+| -------------------- | -------------------------------- | ---------------------------------- |
+| Data location        | Vendor's cloud infrastructure    | Your local environment and repo    |
+| Switching cost       | High - context lost on migration | Low - context travels with project |
+| Multi-model support  | Single vendor only               | Any supported provider             |
+| Export capability    | Limited or non-existent          | Inherent - files are yours         |
+| Negotiating leverage | Erodes over time                 | Preserved - no lock-in             |
+
+## Frequently asked questions
+
+### What is AI memory lock-in?
+
+AI memory lock-in occurs when accumulated context, preferences, and personalization stored in one AI provider's system makes switching to another provider costly. The personalized experience you build over months of use becomes a barrier to migration because that context does not export or transfer to competing services.
+
+### How does memory lock-in affect enterprise AI strategy?
+
+For enterprise teams, memory lock-in creates hidden switching costs that surface at contract renewal. Teams that have accumulated significant context in one provider lose negotiating leverage because migration means losing that personalization. This is especially problematic for organizations pursuing multi-model strategies where different models handle different tasks.
+
+### Can I export my ChatGPT memory to another AI provider?
+
+Currently, most AI memory systems do not support export or portability. The memory you accumulate in ChatGPT, Claude, or other services stays within that ecosystem. There is no standard format or protocol for transferring personalized context between AI providers.
+
+### How does Roo Code avoid the memory lock-in problem?
+
+Roo Code uses a BYOK architecture where your context lives in your local environment and project files rather than a vendor-controlled memory layer. Custom modes, instructions, and project configurations are stored alongside your code. This means switching models is a configuration change, and your accumulated context remains accessible regardless of which AI provider you route requests to.
+
+### Should I avoid using AI memory features entirely?
+
+Not necessarily, but you should evaluate memory as infrastructure rather than a convenience feature. Ask where context is stored, whether it is exportable, and what you lose if you switch providers. Factor the potential switching cost into your total cost of ownership when making procurement decisions.
diff --git a/apps/web-roo-code/src/content/blog/model-recovery-beats-raw-success-rate-for-production-workflows.md b/apps/web-roo-code/src/content/blog/model-recovery-beats-raw-success-rate-for-production-workflows.md
new file mode 100644
index 00000000000..4541c4d2d33
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/model-recovery-beats-raw-success-rate-for-production-workflows.md
@@ -0,0 +1,121 @@
+---
+title: Model Recovery Beats Raw Success Rate for Production Workflows
+slug: model-recovery-beats-raw-success-rate-for-production-workflows
+description: Why graceful failure recovery matters more than raw success rates when evaluating AI models for agentic coding workflows - and how to test for it.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-agents
+    - model-evaluation
+    - production-workflows
+    - developer-experience
+status: draft
+publish_date: "2025-08-27"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The model fails a tool call. Then fails the same way again. And again.
+
+Three attempts. Same error. Zero learning.
+
+## The loop problem
+
+You're watching a model debug a test failure. It tries to read a file that doesn't exist. The call fails. Instead of trying a different path or asking for clarification, it tries the exact same call again.
+
+And again.
+
+And again.
+
+The context is poisoned. The failed tool call became the new pattern, and now the model is committed to beating its head against the wall until you kill the task or run out of tokens.
+
+This is the difference between a model with a 95% success rate that loops forever on failures, and a model with a 90% success rate that recovers and tries a different approach. The second model is more useful for production workflows.
+
+## What makes a model recoverable
+
+The problem isn't occasional failures. Every model fails sometimes. The problem is what happens next.
+
+A recoverable model treats failed tool calls as information, not as a template. If a file read fails, it looks for alternative paths. If a command errors out, it parses the error message and adjusts. The failed attempt gets purged from the pattern-matching context instead of becoming the new baseline.
+
+> "It's not about, you know, failing the occasional right to file. It's about not getting stuck on a loop after it fails a single call, which we've seen with some models after they fail once, they just continue failing forever."
+>
+> Dan, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=1747)
+
+A non-recoverable model does the opposite. It sees the failed call, treats it as a valid approach, and doubles down. Each retry reinforces the pattern. The context window fills with repeated failures, which makes recovery even less likely.
+
+## The evaluation shift
+
+When teams evaluate models for agentic work, the standard benchmarks focus on raw success rates. Can the model solve the task? What percentage of the time?
+
+Those benchmarks miss the loop problem entirely.
+
+A model that passes 95% of tasks but loops indefinitely on the other 5% might be worse than a model that passes 90% and recovers gracefully on the remaining 10%. The first model wastes hours of wall-clock time and burns through your token budget on failures that will never resolve. The second model either finds an alternative approach or surfaces the failure clearly so you can intervene.
+
+> "So if the model, you know, fails occasionally, probably more often than Sonic 4, but it's able to keep going even if it fails, I think that makes it a useful model for sure."
+>
+> Dan, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=1768)
+
+The tradeoff is explicit: you might accept a lower raw success rate in exchange for graceful degradation. The question isn't "how often does this model succeed?" It's "what happens when it fails?"
+
+## Testing for recovery
+
+If you're evaluating models for production agentic workflows, add failure recovery to your test suite.
+
+Run tasks where the expected file doesn't exist. Run tasks where the first command returns an unexpected error format. Run tasks where the context starts with a misleading assumption.
+
+Then watch what happens on the second attempt.
+
+Does the model parse the error and adjust? Does it try a different approach? Or does it loop?
+
+> "Basically if it can sort of purge that poisoning and move on instead of taking that failed tool call as the new the new... this is the new pattern to follow and I'm just going to keep beating my head against the ball."
+>
+> Dan, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=1786)
+
+## Why this matters for your workflow
+
+If you're running agentic tasks on real codebases, you will hit edge cases. Files get renamed. APIs return unexpected formats. Test environments drift from production. The model will fail.
+
+The question is whether that failure costs you five seconds of recovery time or five hours of loop-watching before you realize nothing is going to change.
+
+When you evaluate models, test for recovery. Count the loops, not just the wins.
+
+## How Roo Code closes the loop on model failures
+
+Roo Code is designed to close the loop - running commands, observing results, and iterating based on what actually happened. When a tool call fails, Roo Code can parse the error output and adjust its approach rather than repeating the same failed pattern.
+
+With BYOK (bring your own key), you can test different models against your actual codebase to evaluate their recovery behavior. Some models handle failures gracefully; others loop. Roo Code lets you swap models without changing your workflow, so you can find the one that recovers best for your specific use cases.
+
+**The key insight for production workflows: an agent that closes the loop treats failures as feedback, not as templates to repeat.**
+
+## Comparing model evaluation approaches
+
+| Dimension            | Raw success rate focus     | Recovery-aware evaluation                    |
+| -------------------- | -------------------------- | -------------------------------------------- |
+| Primary metric       | Task completion percentage | Task completion plus failure behavior        |
+| Failure handling     | Not measured               | Explicit test cases for recovery             |
+| Token efficiency     | Ignored                    | Tracks cost of failure loops                 |
+| Wall-clock time      | Ignored                    | Measures time to resolution or escalation    |
+| Production readiness | Misleading                 | Accurate predictor of real-world performance |
+
+## Frequently asked questions
+
+### Why do some models loop on failures instead of recovering?
+
+Models learn patterns from their context window. When a failed tool call enters the context, some models treat it as a valid approach and repeat it. The failure becomes the new pattern. Models with better instruction-following and error parsing can recognize the failure as information to act on rather than a template to copy.
+
+### How do I test a model's recovery behavior before deploying it?
+
+Create test cases with intentional failure conditions: missing files, unexpected error formats, and misleading initial context. Run the model through these scenarios and observe whether it adjusts its approach after the first failure or loops on the same call. Count retries and measure time to recovery or escalation.
+
+### Does Roo Code help with model recovery testing?
+
+Roo Code's BYOK architecture lets you swap models without changing your workflow. You can run the same task against multiple models and compare their recovery behavior directly. Since Roo Code closes the loop by running commands and iterating on results, you can observe how different models handle failures in your actual development environment.
+
+### Is a lower success rate acceptable if recovery is better?
+
+Often yes. A model with 90% success and graceful failure handling may outperform a 95% success model that loops indefinitely on failures. The 5% failure loop can consume hours of time and significant token budget. Graceful degradation means failures resolve quickly or surface clearly for human intervention.
+
+### What signals indicate a model is about to enter a failure loop?
+
+Watch for repeated identical tool calls, especially after error responses. If you see the same file path, the same command, or the same API call appear multiple times with the same failure, the model has likely entered a loop. Early detection lets you intervene before the context window fills with repeated failures.
diff --git a/apps/web-roo-code/src/content/blog/most-engineers-still-just-hit-tab-in-copilot.md b/apps/web-roo-code/src/content/blog/most-engineers-still-just-hit-tab-in-copilot.md
new file mode 100644
index 00000000000..a2762b0e3ae
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/most-engineers-still-just-hit-tab-in-copilot.md
@@ -0,0 +1,132 @@
+---
+title: Most Engineers Still Just Hit Tab in Copilot
+slug: most-engineers-still-just-hit-tab-in-copilot
+description: The gap between AI coding early adopters and the median developer is wider than the discourse suggests. Learn why adoption friction, not feature depth, determines which AI coding tools actually get used.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding-tools
+    - developer-adoption
+    - enterprise-evaluation
+    - agentic-workflows
+status: draft
+publish_date: "2025-07-02"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Tab. Tab. Tab.
+
+That's the AI workflow for most engineers.
+
+Not agents. Not custom modes. Not agentic iteration. Just autocomplete.
+
+## The discourse gap
+
+Ask someone who spends hours on Discord about AI coding tools, and you'll hear about agents, context windows, model comparisons, and workflow automation. Ask an engineer at a company how much they use AI, and the answer is different.
+
+> "When you talk to people who work jobs, don't spend all day on Discord and you ask them how much they use AI, their answers are usually like, I hit tab sometimes in copilot."
+>
+> Matt, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=2470)
+
+The gap between early adopters and the median developer is wider than the discourse suggests. Most engineers haven't experienced what AI can do beyond autocomplete. They haven't seen a tool close the loop: run the tests, read the output, iterate on the fix.
+
+This isn't a feature awareness problem. It's an adoption friction problem.
+
+## The enterprise constraint
+
+If you're evaluating AI coding tools for your organization, this gap matters.
+
+The vendors are competing on features: more models, more context, more integrations. But the median engineer on your team isn't comparing feature matrices. They're trying to ship code, and the tool they use is the one that doesn't interrupt their workflow.
+
+Copilot won that battle for a lot of teams. It sits in the editor. It doesn't require context switching. It suggests, you tab. Low friction, low ceiling.
+
+The question for enterprise buyers: how do you move your team from tab-completion to actual agentic workflows without creating more friction than you're removing?
+
+## The opportunity reframe
+
+The competition isn't feature parity. It's adoption friction.
+
+For teams building or evaluating AI coding tools, this changes what you optimize for. Instead of asking "does this tool have the features power users want?" you ask "can a developer who currently hits tab in Copilot actually use this?"
+
+The gap represents unrealized value. Engineers who haven't experienced agentic iteration don't know what they're missing. When they do, the shift can be significant.
+
+> "For me, it's completely rejuvenated my excitement for programming and building stuff. And I just think there's room to do that for a lot more people."
+>
+> Matt, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=2552)
+
+That's the prize: not just productivity gains, but engineers who are excited about their work again. But you only get there if the median developer can actually cross the threshold.
+
+## What this means for your team
+
+If you're rolling out AI coding tools to a team of fifty engineers, assume forty of them are currently at "I hit tab sometimes."
+
+The adoption curve isn't about convincing early adopters. It's about reducing friction for the majority who haven't made the leap.
+
+Questions to ask:
+
+- Does the tool require prompt engineering skill to be useful?
+- Does it work without context switching out of the editor?
+- Can someone start using it without a training session?
+- Does it produce artifacts that fit into existing review workflows?
+
+The teams that move the median developer will capture more value than the teams that optimize for power users. The discourse is loud, but most engineers are still just hitting tab.
+
+## The competitive frame
+
+This also changes how to evaluate competitors. Instead of "which tool is winning on features," ask "which tool can move the next wave of developers."
+
+> "I think just viewing them as like a friendly competitor and looking at all the things we could do better to meet the level they're at on a lot of the UX stuff."
+>
+> Matt, [Office Hours S01E12](https://www.youtube.com/watch?v=QmmyZ2h7ffU&t=2565)
+
+The honest assessment: some competitors have UX that makes the gap smaller. The agent capabilities matter, but only if people actually use them of their own volition.
+
+## The adoption friction audit
+
+If you're evaluating tools for your org, start with the median developer, not the early adopter.
+
+Shadow someone who currently just hits tab. Watch what breaks when you introduce a new tool. Measure time-to-first-useful-output, not capability depth.
+
+The tool that wins isn't the one with the most features. It's the one that moves the most people past tab-completion.
+
+## How Roo Code bridges the adoption gap
+
+Roo Code reduces friction for the median developer by working entirely inside VS Code with no context switching required. The key differentiator: Roo Code closes the loop by running commands, reading test output, and iterating on fixes automatically. Unlike autocomplete tools that stop at suggestion, Roo Code executes the full feedback cycle.
+
+With BYOK (bring your own key), teams pay API providers directly with no token markup, removing procurement friction for enterprise pilots. Developers start with familiar autocomplete patterns and gradually adopt agentic workflows as they see the tool run tests and iterate on their behalf.
+
+**Roo Code moves developers from tab-completion to agentic iteration by keeping low entry friction while offering a higher capability ceiling.**
+
+## Tab-completion versus agentic workflows
+
+| Dimension           | Tab-completion (Copilot)  | Agentic workflow (Roo Code)                |
+| ------------------- | ------------------------- | ------------------------------------------ |
+| Interaction model   | Suggest, accept, move on  | Propose, execute, iterate based on results |
+| Test execution      | Manual by developer       | Agent runs tests and reads output          |
+| Error handling      | Copy-paste errors to chat | Agent reads errors and proposes fixes      |
+| Context continuity  | Resets each suggestion    | Maintains task context across iterations   |
+| Time-to-first-value | Seconds (low ceiling)     | Minutes (high ceiling, compounding value)  |
+
+## Frequently asked questions
+
+### Why do most engineers only use tab-completion in AI coding tools?
+
+Tab-completion has minimal friction. It works inside the editor, requires no prompt engineering, and fits existing habits. Most engineers haven't experienced what happens when a tool closes the loop by running tests and iterating on failures. The gap is adoption friction, not feature awareness.
+
+### What is "closing the loop" in agentic coding?
+
+Closing the loop means the AI tool doesn't stop at suggesting code. It executes commands, runs tests, reads the output, and iterates on fixes without requiring the developer to copy-paste errors back into a chat window. This feedback cycle is what separates agentic workflows from autocomplete.
+
+### How should enterprises evaluate AI coding tools for adoption?
+
+Start with your median developer, not your early adopters. Measure time-to-first-useful-output rather than capability depth. Shadow someone who currently just hits tab and observe what breaks when introducing a new tool. The tool that wins is the one that moves the most people past tab-completion.
+
+### Does Roo Code require prompt engineering skill to be useful?
+
+No. Roo Code works inside VS Code with natural language task descriptions. Developers can start with simple requests and gradually adopt more sophisticated agentic workflows. The BYOK model means teams control their own API keys with no token markup, reducing both technical and procurement barriers.
+
+### What is the real competition for AI coding tools?
+
+The competition isn't feature parity. It's adoption friction. The tool that can move the next wave of developers from tab-completion to agentic iteration will capture more value than the tool optimizing for power users who already know what they want.
diff --git a/apps/web-roo-code/src/content/blog/native-provider-endpoints-beat-openaicompatible-mode-for-code-quality.md b/apps/web-roo-code/src/content/blog/native-provider-endpoints-beat-openaicompatible-mode-for-code-quality.md
new file mode 100644
index 00000000000..e4bca553f21
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/native-provider-endpoints-beat-openaicompatible-mode-for-code-quality.md
@@ -0,0 +1,128 @@
+---
+title: Native Provider Endpoints Beat OpenAI-Compatible Mode for Code Quality
+slug: native-provider-endpoints-beat-openaicompatible-mode-for-code-quality
+description: Learn why routing AI models through OpenAI-compatible gateways can silently degrade code quality, and how to diagnose thinking tokens, prompt caching, and context window issues.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - llm-configuration
+    - code-quality
+    - model-endpoints
+    - developer-productivity
+status: draft
+publish_date: "2025-04-30"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Same model. Same prompt. Different endpoint.
+
+Different results.
+
+If your team thinks Claude 3.7 "feels dumb," the problem might not be the model.
+
+## The invisible configuration gap
+
+Your developers are complaining. They tried Claude 3.7 Sonnet, the model everyone said would handle complex refactors. It didn't. It missed context, ignored edge cases, gave shallow suggestions. They switched back to GPT-4 and wrote off Claude as overhyped.
+
+But here's what they didn't check: which endpoint were they actually hitting?
+
+Many teams route all their model traffic through OpenAI-compatible gateways. It's convenient. One endpoint format, multiple models, simpler infrastructure. The gateway translates requests into whatever the underlying provider expects.
+
+Except the translation isn't lossless.
+
+> "Going through the provider specific endpoint can actually give like drastically different results. Like for Claude 3.7 people were thinking it was pretty dumb until they tried the Anthropic endpoint and they're like okay wait actually this is this is so much better than going through the OpenAI compatible one."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=1445)
+
+The model is the same. The capability is the same. But the API layer between your tool and the model can silently misconfigure features that matter: thinking tokens, prompt caching, tool format handling.
+
+## Where the translation breaks
+
+Three places where OpenAI-compatible mode commonly loses fidelity:
+
+**Thinking tokens.** Claude's extended thinking mode lets the model reason through complex problems before responding. But if the gateway doesn't pass the right parameters, thinking mode stays off. The model answers immediately instead of working through the problem. You get a confident, shallow response instead of a considered one.
+
+The tricky part: you can't always tell it's broken.
+
+> "Even if things like thinking isn't working, it's even tricky to figure out that it's not working until it's until it's too late because maybe the LLM didn't feel like spending tokens on thinking for that one particular question."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=1392)
+
+The model doesn't error out. It just gives you a worse answer. And if you're evaluating models based on these worse answers, you're making decisions on corrupted data.
+
+**Prompt caching.** Anthropic's prompt caching reduces costs and latency for repeated context. But caching configuration is provider-specific. A generic gateway might not set cache breakpoints correctly, or might not support caching at all. You pay full price for every request and wonder why Claude costs so much.
+
+**Context window defaults.** Even when the underlying model supports 200k or more tokens, the gateway might default to 128k.
+
+> "I've seen some people who didn't realize that we have sane defaults which are not that great where it's like 128k context window instead of 200,000 or a million."
+>
+> Matt Rubens, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=1464)
+
+Your developers truncate context to fit a limit that doesn't need to exist. The model sees less of the codebase. The suggestions get worse.
+
+## The diagnostic checklist
+
+If your team is unhappy with Claude performance, check these before switching models:
+
+1. **Which endpoint are you hitting?** Native Anthropic, or OpenAI-compatible translation?
+2. **Is thinking mode enabled?** Check request logs for `thinking` parameters.
+3. **What's your context window limit?** Match it to the model's actual capability.
+4. **Is prompt caching configured?** Look for cache hits in your billing.
+
+These are infrastructure decisions, not model decisions. But they affect model quality directly.
+
+## Why this matters for your team
+
+For a Series A - C team running 50 model requests a day, the wrong configuration compounds. If thinking mode is silently disabled, every complex refactor suggestion is shallower than it should be. If context is truncated, every large-file edit misses relevant code. Your developers blame the model and switch tools instead of fixing the endpoint.
+
+The cost isn't just the wasted token spend. It's the evaluation time spent on the wrong hypothesis.
+
+## How Roo Code connects you to native provider endpoints
+
+Roo Code uses a BYOK (bring your own key) model, which means you configure direct connections to each provider's native API. When you add your Anthropic API key, Roo Code hits Anthropic's endpoint directly. When you add your OpenAI key, it hits OpenAI directly. No translation layer sits between your prompt and the model.
+
+This architecture means thinking tokens work when you enable them. Prompt caching works when the provider supports it. Context windows default to what the model actually supports, not what a gateway assumes.
+
+**Roo Code's native provider integration ensures you get the full capability of each model without silent configuration degradation from translation layers.**
+
+Because Roo Code closes the loop by running commands, tests, and iterating on results, model quality directly affects how well it handles complex multi-step tasks. A model with thinking mode silently disabled will produce shallower edits. A model with truncated context will miss relevant files. Native endpoints remove these hidden failure modes from your workflow.
+
+## Comparing endpoint approaches
+
+| Dimension       | OpenAI-Compatible Gateway                   | Native Provider Endpoints                 |
+| --------------- | ------------------------------------------- | ----------------------------------------- |
+| Thinking tokens | May be silently disabled or misconfigured   | Full support when enabled in request      |
+| Prompt caching  | Often unsupported or incorrectly configured | Provider-native cache breakpoints         |
+| Context window  | May default to lower limits (128k)          | Defaults to model's actual capability     |
+| Debugging       | Harder to trace which features are active   | Direct visibility into request/response   |
+| Cost visibility | Cache misses inflate bills without warning  | Accurate billing with cache hit reporting |
+
+## The first check
+
+Before you write off a model, verify you're hitting its native endpoint with the right configuration.
+
+The model that "feels dumb" through a translation layer might work fine when you remove the middleman.
+
+## Frequently asked questions
+
+### Why does the same model give different results through different endpoints?
+
+OpenAI-compatible gateways translate requests into a generic format, then convert them to each provider's native format. This translation can drop or misconfigure provider-specific features like thinking tokens, prompt caching, and context window settings. The model receives different parameters than you intended, producing different output quality.
+
+### How can I tell if thinking mode is actually working?
+
+Check your request logs for the `thinking` parameter being passed correctly. The difficulty is that models don't error when thinking mode is disabled. They simply respond without extended reasoning, giving you a faster but shallower answer. If complex refactors seem to miss edge cases, thinking mode configuration is a likely culprit.
+
+### Does Roo Code use OpenAI-compatible endpoints or native provider APIs?
+
+Roo Code connects directly to each provider's native API using your own API keys. When you configure an Anthropic key, requests go to Anthropic's endpoint. When you configure an OpenAI key, requests go to OpenAI's endpoint. This BYOK approach ensures provider-specific features like thinking tokens and prompt caching work correctly without translation layer interference.
+
+### What's the actual cost difference between cached and uncached requests?
+
+Anthropic's prompt caching can reduce costs by up to 90% for repeated context. If your gateway doesn't support caching or configures it incorrectly, you pay full price for every request. Check your billing dashboard for cache hit rates. If you're seeing zero cache hits on repeated workflows, your caching configuration is likely broken.
+
+### Should I always use native endpoints instead of a unified gateway?
+
+For production workflows where model quality matters, native endpoints provide the most reliable results. Unified gateways offer convenience for prototyping or when you need to rapidly switch between models. The tradeoff is between operational simplicity and guaranteed feature support. If you're evaluating model quality, always test against native endpoints first.
diff --git a/apps/web-roo-code/src/content/blog/non-engineers-stopped-waiting-for-engineers-to-unblock-them.md b/apps/web-roo-code/src/content/blog/non-engineers-stopped-waiting-for-engineers-to-unblock-them.md
new file mode 100644
index 00000000000..dccb3ac916a
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/non-engineers-stopped-waiting-for-engineers-to-unblock-them.md
@@ -0,0 +1,120 @@
+---
+title: Non-Engineers Stopped Waiting for Engineers to Unblock Them
+slug: non-engineers-stopped-waiting-for-engineers-to-unblock-them
+description: How product managers, ops, and support teams use AI coding agents to query codebases directly - reducing engineering interruptions and cutting the meeting tax.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - team-productivity
+    - codebase-understanding
+    - enterprise-workflows
+    - cross-functional-collaboration
+status: published
+featured: true
+publish_date: "2025-10-01"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+"I use @roomote every day to ask questions about the codebase."
+
+That's a product manager talking. Not an engineer. Not someone who reads code for a living.
+
+## The meeting that didn't happen
+
+Every growing startup has this bottleneck. A PM needs to know why the pricing modal shows one value to new users and another to existing customers. Support needs to understand why a refund didn't process. Ops wants to know if a feature flag applies to enterprise accounts.
+
+The default behavior: send a Slack or schedule a meeting. Wait for engineering bandwidth. Hope someone remembers the context when they finally have time to answer.
+
+At Roo Vet, the behavior changed. Product managers, support reps, and operations staff started querying the codebase directly through a Roo Code's Slack agent. The question goes to the agent before it goes to a calendar invite.
+
+> "One nonobvious behavior change that came out of that I think is people don't wait around to be unblocked anymore. Non-engineers especially just ask our @roomote agent first."
+>
+> John Sterns, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=290)
+
+## The shift: ask the agent first
+
+This isn't about replacing engineers. It's about reducing the number of times someone has to interrupt an engineer for a question that lives in the code.
+
+A PM wondering about pricing logic can ask the agent to find where pricing is calculated. A support rep confused about a refund flow can ask what conditions trigger a failed transaction. An ops person checking feature flags can get a direct answer without waiting for standup.
+
+The answers come from the codebase itself. Not tribal knowledge. Not someone's memory of a Slack thread from six months ago.
+
+> "I use @roomote every day to ask questions about the codebase. I think that is the most effective thing as a PM."
+>
+> Theo, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=2288)
+
+## What the queries look like
+
+The questions that used to block people are often simple:
+
+- "Where is the logic that determines trial length for enterprise accounts?"
+- "What happens if a user cancels mid-billing cycle?"
+- "Which API endpoint does the mobile app call for user preferences?"
+
+These aren't deep architectural questions. They're "point me to the right file" questions. But without direct access, each one requires finding an engineer, explaining the context, waiting for them to context-switch, and hoping they have time to answer before your next deadline.
+
+With a codebase-connected agent, the answer comes back fast.
+
+> "You can ask it questions to better understand the logic that's been built into the product... it took me like 30 seconds to find that answer."
+>
+> Audrey, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk)
+
+## The tradeoff
+
+This works well for "where is X" and "what does Y do" questions. It works less well for "should we change Z" questions that require judgment and context about why something was built a certain way.
+
+The agent can point to the code. It cannot explain the meeting where the team decided to handle edge cases a specific way, or the incident that led to a particular validation check.
+
+Non-engineers still need engineers for decisions. But they no longer need engineers for navigation.
+
+## Old approach vs. new approach
+
+| Dimension              | Old approach                      | New approach                          |
+| ---------------------- | --------------------------------- | ------------------------------------- |
+| Question routing       | Schedule meeting with engineering | Ask the agent first                   |
+| Wait time              | Hours to days for bandwidth       | Seconds for direct answers            |
+| Engineer interruptions | Multiple context switches daily   | Only for decision-requiring questions |
+| Knowledge source       | Tribal knowledge and memory       | Codebase itself                       |
+| Bottleneck             | Engineering availability          | None for navigation questions         |
+
+## Why this matters for your team
+
+For a Series A or B company, the meeting tax is real. Every "quick question" that requires an engineer to stop, context-switch, answer, and then recover their flow costs more than the five minutes the question takes.
+
+If half of those questions can be answered by the codebase directly, the compounding effect is significant. Not because individual questions take less time, but because engineers stay in flow and non-engineers stop waiting.
+
+The behavior shift is the real outcome: people stop treating engineering bandwidth as a prerequisite for understanding the product.
+
+## How Roo Code makes questions self-serve
+
+The key capability for cross-functional teams is read-only codebase access through integrations. People can ask questions in the tools they already use and get answers grounded in the actual implementation, not documentation that may be outdated.
+
+In practice, the best answers are inspectable: what file to look at, what function or endpoint is involved, and what conditions drive the behavior.
+
+**Roo Code helps non-engineers self-serve codebase questions, reducing engineering interruptions while keeping engineers available for decisions that require judgment.**
+
+## The first step
+
+Connect your codebase to a channel where non-technical team members already work. Slack integration is the common pattern. Start with read-only access: let people ask questions about what exists before you consider letting anyone propose changes.
+
+The goal is simple: make "ask the agent first" the default behavior before "schedule a meeting with engineering." The questions that require an engineer will become obvious. Everything else just gets answered.
+
+## Frequently asked questions
+
+### What types of questions can non-engineers actually answer with an AI coding agent?
+
+Navigation and understanding questions work well: "where is X calculated," "what triggers Y behavior," and "which API handles Z." These are lookup questions where the answer lives in the code. Questions requiring judgment about why something was built a certain way, or whether it should change, still need engineers.
+
+### How do you prevent non-technical staff from getting confused by raw code responses?
+
+Modern AI coding agents like Roo Code explain code in plain language rather than just returning file contents. When a PM asks about pricing logic, they get an explanation of the flow, not a code dump. The agent translates between codebase structure and business concepts.
+
+### Does giving non-engineers codebase access create security risks?
+
+Read-only access through a controlled integration can reduce exposure compared to giving users direct repository access. Teams typically start with specific channels and expand access based on demonstrated value and a security review.
+
+### What's the ROI of reducing "quick question" interruptions for engineers?
+
+Context-switching costs compound. A five-minute question can cost far more than five minutes once you include interruption and recovery. If you can route routine "where is X" questions away from engineering, you buy back real focus time without adding headcount.
diff --git a/apps/web-roo-code/src/content/blog/one-bad-line-in-your-rules-file-equals-ten-thousand-lines-of-bad-code.md b/apps/web-roo-code/src/content/blog/one-bad-line-in-your-rules-file-equals-ten-thousand-lines-of-bad-code.md
new file mode 100644
index 00000000000..64102c5030b
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/one-bad-line-in-your-rules-file-equals-ten-thousand-lines-of-bad-code.md
@@ -0,0 +1,128 @@
+---
+title: One Bad Line in Your Rules File Equals Ten Thousand Lines of Bad Code
+slug: one-bad-line-in-your-rules-file-equals-ten-thousand-lines-of-bad-code
+description: Why agent configuration errors multiply across every task and how to allocate review effort proportionally to blast radius, not lines changed.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agent-configuration
+    - rules-files
+    - code-review
+    - agentic-workflows
+status: draft
+publish_date: "2025-10-08"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+A bug is just a bug.
+
+A bad rule is ten thousand bugs.
+
+## The multiplication problem
+
+You find a typo in your codebase. You fix it. One line changed, one line fixed. The blast radius is contained.
+
+Now imagine the same typo in your agent's rules file. That typo shapes every prompt the agent receives. Every task it runs. Every diff it generates. That single incorrect line doesn't produce one bug - it produces a pattern of bugs across every file the agent touches.
+
+This is the error multiplication hierarchy:
+
+- One bad line of code: one bug
+- One bad line in a spec: a hundred bugs (every implementation follows the wrong spec)
+- One bad line in your rules file: ten thousand lines of bad code
+
+The agent doesn't know the rule is wrong. It follows the rule faithfully, which is exactly what makes it dangerous.
+
+> "A line of incorrect code is just a line of bad code. A line in a spec, like an incorrect line in a spec is like a hundred or a thousand lines of bad code... an incorrect line in a rule or like an agent file or something like that is maybe 10,000 lines of bad code."
+>
+> Hannes Rudolph, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=2577)
+
+## Where your review effort should go
+
+Most teams allocate review effort uniformly. Every PR gets the same scrutiny. But error multiplication means some changes deserve disproportionate attention.
+
+A PR that changes application code? Standard review. The blast radius is limited to what that code touches.
+
+A PR that changes your agent configuration, your rules file, your system prompts? That change affects every task the agent runs from that point forward. The blast radius is your entire codebase.
+
+> "Something that's going to come out of the init command or that you're putting into rules, I think that's where more review should be gone into, right? Like so if you got a PR that's changing your core rules or your structure, I think it's pretty critical."
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=2607)
+
+The practical implication: treat rules file changes like infrastructure changes. More eyes. More scrutiny. Slower merge velocity is acceptable because the cost of a bad merge is so much higher.
+
+## The tradeoff
+
+Tighter review on rules files means slower iteration on agent behavior. You can't just tweak a prompt and ship it. Someone else needs to look at it first.
+
+This feels like friction when you're trying to move fast. But the alternative is discovering three weeks later that the agent has been following a subtly wrong instruction across dozens of tasks, and now you're debugging a pattern of failures instead of a single bug.
+
+The friction is the feature. It forces you to think about what you're encoding as policy before it compounds.
+
+## What to watch for
+
+Rules file errors aren't always obvious. They're often:
+
+- **Ambiguous instructions** the agent interprets consistently but incorrectly
+- **Missing constraints** that let the agent drift into unwanted behavior
+- **Conflicting rules** where the agent picks one interpretation and sticks with it
+- **Outdated assumptions** about your codebase structure or conventions
+
+The symptom is usually not "the agent crashed." The symptom is "the agent kept doing something slightly wrong, and we didn't notice until the pattern was everywhere."
+
+## Why this matters for your workflow
+
+If you're using rules files or agent configurations, you already have a leverage point that affects every task. The question is whether you're treating it with appropriate weight.
+
+For a team running 20 agent tasks a week, a bad rule doesn't just affect one task. It affects 20. Then 40. Then 100. By the time someone notices the pattern, the cleanup is substantial.
+
+The review cost of catching a bad rule before it merges is minutes. The cleanup cost after it's been running for a month is hours or days.
+
+## How Roo Code closes the loop on configuration errors
+
+Roo Code's architecture surfaces configuration mistakes faster than traditional AI coding tools because it closes the loop: the agent proposes changes, runs tests, and iterates based on actual results. When a rules file contains a bad instruction, you see the pattern emerge in real diffs rather than discovering it weeks later in production.
+
+With BYOK (bring your own key), you control both the model and the rules that govern it. This means your team owns the full configuration stack and can establish review gates at every layer - from API keys to system prompts to project-specific rules files.
+
+**The principle that separates effective agent teams from struggling ones: review effort should be proportional to error multiplication, not to lines changed.**
+
+## Old approach vs. new approach
+
+| Dimension          | Old approach (uniform review)   | New approach (proportional review)  |
+| ------------------ | ------------------------------- | ----------------------------------- |
+| Review allocation  | Same scrutiny for all PRs       | Weight review by blast radius       |
+| Rules file changes | Treated like any other code     | Treated like infrastructure changes |
+| Merge velocity     | Consistent across change types  | Slower for high-leverage configs    |
+| Error discovery    | Weeks later, pattern everywhere | Earlier, contained to fewer tasks   |
+| Cleanup cost       | Hours or days of debugging      | Minutes of pre-merge review         |
+
+## The shift
+
+Audit your current review process. If rules file changes get the same scrutiny as application code changes, you're underweighting the leverage point.
+
+The principle: review effort should be proportional to error multiplication, not to lines changed.
+
+One line in a rules file is not one line of risk. It's ten thousand.
+
+## Frequently asked questions
+
+### What counts as a "rules file" for AI coding agents?
+
+Rules files include any configuration that shapes agent behavior across multiple tasks: system prompts, custom instructions, `.roo` files, mode configurations, and project-level agent settings. Any file that tells the agent how to behave globally rather than for a single task falls into this category.
+
+### How do I know if a rules file error is causing my issues?
+
+Look for patterns rather than isolated bugs. If you're seeing the same type of mistake across multiple files or multiple tasks - consistent formatting errors, repeated architectural decisions you didn't intend, or the same bad assumption appearing everywhere - the source is likely upstream in your configuration rather than in individual code changes.
+
+### Does Roo Code help prevent rules file errors?
+
+Roo Code's close-the-loop workflow surfaces configuration problems faster because you see the agent's interpretation immediately in proposed diffs. When you run a task and review the output, bad rules manifest as patterns in the generated code. The approval step before any changes are applied gives you a checkpoint to catch configuration drift before it compounds.
+
+### Should I version control my agent configuration files?
+
+Yes. Treat rules files like infrastructure-as-code. Version control enables PR-based review, rollback when patterns emerge, and audit trails showing what changed when. If you can't explain why your agent started behaving differently, the answer is often in your configuration commit history.
+
+### How much review is enough for rules file changes?
+
+At minimum, require a second pair of eyes for any change to agent configuration. For teams with high task volume, consider requiring sign-off from someone who understands both the codebase conventions and the agent's behavior patterns. The review cost is minutes; the cost of a bad rule running for a month is substantially higher.
diff --git a/apps/web-roo-code/src/content/blog/open-source-is-shifting-from-prs-to-issues.md b/apps/web-roo-code/src/content/blog/open-source-is-shifting-from-prs-to-issues.md
new file mode 100644
index 00000000000..b2d6260a6b8
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/open-source-is-shifting-from-prs-to-issues.md
@@ -0,0 +1,115 @@
+---
+title: Open Source Is Shifting from PRs to Issues
+slug: open-source-is-shifting-from-prs-to-issues
+description: The open source contribution model is reversing. With AI agents that can attempt fixes from issue descriptions, the valuable contribution shifts from writing code to describing problems clearly.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - open-source
+    - ai-agents
+    - developer-workflow
+    - code-contribution
+status: draft
+publish_date: "2025-08-06"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+"Open a PR for that."
+
+That used to be the answer. Now it's: "Open an issue."
+
+The contribution model is reversing.
+
+## The old workflow
+
+A community member finds a bug. They fork the repo, write a fix, open a pull request. The maintainer reviews the code, requests changes, the contributor revises. Repeat until merge or abandonment.
+
+This worked when the bottleneck was "who can write the code." The contribution was the implementation itself.
+
+But now agents can attempt the fix. The contribution shifts upstream: describing the problem clearly enough that an agent can take a first pass.
+
+## The new workflow
+
+Contributor opens an issue with a clear description. Agent attempts the fix automatically. Human reviews what the agent produced.
+
+The maintainer's job changes. Instead of reviewing contributor code, they're reviewing agent output. Instead of coaching a contributor through revisions, they're refining the issue description so the next agent attempt lands closer.
+
+> "Hannes used to tell everyone like open a PR, you want to fix that. Now, it's really open an issue, you know, and it's been interesting to see that evolution."
+>
+> Hannes Rudolph, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=861)
+
+The feedback loop tightens. A PR that doesn't land still generates information: you now know what not to do.
+
+> "If the PR is not like accurate or it's not valid or something weird then we can go back to the issue and we can go like oh you need to do this instead."
+>
+> Guest, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=1056)
+
+Even failed attempts become documentation. The agent's wrong approach becomes a constraint for the next attempt.
+
+> "So we have like a base we have some information now on how not to do something. It's easier to tell it now what to do correctly."
+>
+> Hannes Rudolph, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=1072)
+
+## What this changes for teams
+
+**Contributor onboarding shifts.** You're no longer asking "can this person write code in our stack?" You're asking "can this person describe a problem clearly?" The skill bar moves from implementation to specification.
+
+**Work scoping changes.** Issues become the unit of work, not PRs. A well-written issue is more valuable than a half-working PR because it can be re-attempted. A poorly-written issue wastes agent cycles.
+
+**Review load redistributes.** Maintainers spend less time coaching code style and more time validating correctness. The agent handles the "make it compile" phase; humans handle the "is this the right fix" phase.
+
+## The tradeoff
+
+This workflow assumes you have agents that can attempt fixes from issue descriptions. If your agent can't close the loop (run tests, iterate on failures, produce a reviewable diff), you're still in the old world.
+
+And issue quality matters more than ever. Vague issues produce vague attempts. The investment shifts from "write the code" to "write the specification."
+
+## Why this matters for your team
+
+For a Series A-C engineering team, this changes how you think about external contributions. You're not waiting for someone to write a complete PR. You're inviting problem descriptions and letting agents take first passes.
+
+This also changes internal workflows. Junior engineers can contribute by writing clear issues. The agent attempts the fix; senior engineers review the output. The skill required to participate drops; the skill required to validate stays the same.
+
+If your open-source project still gates contribution at "submit a PR," you're asking contributors to do work an agent could attempt. The contribution model is shifting. Issues are the new PRs.
+
+## How Roo Code closes the loop on issue-to-PR workflows
+
+Roo Code is an AI coding agent that closes the loop: it reads an issue description, proposes diffs, runs commands and tests, and iterates based on the results. This is exactly what enables the shift from PRs to issues as the primary contribution unit.
+
+With BYOK (bring your own key), teams pay their LLM provider directly with no token markup, making it economical to let the agent attempt multiple passes on an issue. Roo Code doesn't just generate code and stop. It executes the code, observes failures, and revises until tests pass or it reaches a clear stopping point that humans can evaluate.
+
+**For teams adopting issue-first contribution models, the agent must be able to run tests and iterate on failures autonomously. Otherwise you're just generating code suggestions that still require human debugging.**
+
+## Contribution models compared
+
+| Dimension                | PR-first model                          | Issue-first model                                      |
+| ------------------------ | --------------------------------------- | ------------------------------------------------------ |
+| Bottleneck               | Finding contributors who can write code | Finding contributors who can describe problems clearly |
+| Contribution unit        | Pull request with working code          | Issue with clear specification                         |
+| Maintainer time spent on | Code review and style coaching          | Validating correctness and refining specifications     |
+| Failed attempt value     | Usually abandoned                       | Becomes documentation for next agent attempt           |
+| Onboarding requirement   | Know the codebase and stack             | Know how to write clear problem descriptions           |
+
+## Frequently asked questions
+
+### What skills do contributors need in an issue-first workflow?
+
+Contributors need to describe problems precisely: what behavior they observed, what behavior they expected, and enough context for an agent to locate the relevant code. Implementation knowledge becomes optional; specification clarity becomes essential.
+
+### How do failed agent attempts help future contributions?
+
+When an agent produces an incorrect fix, maintainers can add that information back to the issue. The failed approach becomes a documented constraint, narrowing the solution space for the next attempt. Each failed PR adds signal about what not to do.
+
+### Does Roo Code support this issue-to-PR workflow?
+
+Yes. Roo Code closes the loop by reading issue descriptions, generating fixes, running tests, and iterating on failures. Because it can execute code and observe results, it produces reviewable diffs rather than suggestions that require human debugging. Teams using BYOK pay their LLM provider directly, making repeated agent attempts cost-effective.
+
+### What happens if the issue description is too vague?
+
+Vague issues produce vague or incorrect agent attempts. The investment that previously went into "write the code" now goes into "write the specification." Teams adopting issue-first workflows often create issue templates that prompt contributors for reproduction steps, expected behavior, and relevant file paths.
+
+### How does review workload change for maintainers?
+
+Maintainers shift from coaching contributors through code style and compilation errors to validating whether the agent's output is the correct fix. The agent handles mechanical correctness; humans handle semantic correctness. This often reduces total review time while increasing the importance of each review decision.
diff --git a/apps/web-roo-code/src/content/blog/orchestrate-cheap-models-for-grunt-work-save-expensive-models-for-reasoning.md b/apps/web-roo-code/src/content/blog/orchestrate-cheap-models-for-grunt-work-save-expensive-models-for-reasoning.md
new file mode 100644
index 00000000000..59d3c6fa6cf
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/orchestrate-cheap-models-for-grunt-work-save-expensive-models-for-reasoning.md
@@ -0,0 +1,127 @@
+---
+title: Orchestrate Cheap Models for Grunt Work, Save Expensive Models for Reasoning
+slug: orchestrate-cheap-models-for-grunt-work-save-expensive-models-for-reasoning
+description: Learn how to route AI coding tasks by complexity - use local or cheap models for boilerplate and scaffolding while reserving frontier models for debugging and architectural reasoning.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - model-orchestration
+    - cost-optimization
+    - ai-workflows
+    - agentic-coding
+status: draft
+publish_date: "2025-06-11"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Not every line of code needs Claude.
+
+Stubbing out a file? Creating boilerplate? Writing a test that checks if a button exists?
+
+A local model can handle that. A cheap API model can handle that. The expensive frontier model sitting idle while you generate scaffolding is just burning budget.
+
+## The misallocation problem
+
+You're three sprints into a new feature. The codebase needs twelve new files: interfaces, test stubs, configuration boilerplate, README sections. You fire up the AI agent and watch it churn through the work.
+
+The model generating your empty test file is the same model you'd use to debug a race condition in your authentication flow.
+
+That's the misallocation. You're paying senior engineer rates for intern-level work.
+
+The pattern emerging from teams using Roo Code: route tasks by complexity, not just by cost. Intern-level tasks go to small models. Senior-level reasoning goes to frontier APIs. An orchestrator handles the assignment.
+
+> "Can I pair local models with big models? So it's like a new orchestrator mode. Can I have different levels of engineers that the micromanager figures out: 'All right, intern you do this, junior level you do this.'"
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=1164)
+
+## The layered approach
+
+The mental model: think of your AI tooling like a team with different experience levels.
+
+**Intern tier (local or cheap models):**
+
+- Stub out new files
+- Generate boilerplate
+- Write skeleton tests
+- Create configuration files
+- Add imports and basic structure
+
+**Senior tier (frontier APIs):**
+
+- Debug complex failures
+- Refactor tangled logic
+- Review architectural decisions
+- Handle ambiguous requirements
+- Reason through edge cases
+
+> "You don't need Claude to go create a file for you, to like stub something out. You can use a small model to do that."
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=1180)
+
+The orchestrator routes based on task type. A request to "create a new React component with standard props" goes to the cheap tier. A request to "figure out why this auth flow fails intermittently" goes to the frontier tier.
+
+## The configuration flexibility
+
+The approach scales in both directions. You can run the intern tier on a local model (zero API cost) or a cheap cloud model (minimal cost). You can run the senior tier on Claude, GPT-4, or whatever frontier model fits your budget.
+
+> "You could just put it all as good models, too. You can be like, 'All right, I'm going to have a cheap online model for the low level. I'm going to have an expensive model for the senior level.'"
+>
+> Adam, [Office Hours S01E09](https://www.youtube.com/watch?v=QZkxzxTu6Qo&t=1258)
+
+The point isn't to squeeze every token. The point is to match capability to task complexity. A small model that generates correct boilerplate on the first pass is more valuable than a frontier model doing the same work at 10x the cost.
+
+## The tradeoff
+
+This adds configuration overhead. You need to decide which task types route where. You need to test that the cheap tier actually handles its assigned work reliably.
+
+The payoff: your budget goes to reasoning, not scaffolding. The frontier model shows up when you need actual judgment, not when you need a file created.
+
+## How Roo Code enables model orchestration
+
+Roo Code closes the loop on multi-model workflows through its BYOK (Bring Your Own Key) architecture. You configure which API keys connect to which models, then assign those models to different modes or task types. The orchestrator mode can delegate grunt work to cheap models while reserving expensive frontier models for tasks requiring genuine reasoning.
+
+**Roo Code lets you route AI tasks by complexity: use local models for boilerplate, cheap APIs for scaffolding, and frontier models only when you need real judgment.**
+
+Because Roo Code runs commands, tests, and iterates based on results, the orchestrator can validate that cheaper models completed their work correctly before escalating to more expensive tiers. You spend tokens intentionally for outcomes, not uniformly across all task types.
+
+## Old approach vs. new approach
+
+| Dimension         | Single-model approach               | Orchestrated multi-model approach  |
+| ----------------- | ----------------------------------- | ---------------------------------- |
+| Cost allocation   | Same rate for all tasks             | Matched to task complexity         |
+| Budget efficiency | 40%+ spent on grunt work            | Grunt work near-zero cost          |
+| Model utilization | Frontier model idles on boilerplate | Each tier handles appropriate work |
+| Configuration     | Simple but wasteful                 | More setup, better ROI             |
+| Failure handling  | Expensive retries                   | Cheap retries for simple tasks     |
+
+## Why this matters for your team
+
+For a five-person team shipping 10+ PRs a week, the grunt work adds up. Test stubs, config files, boilerplate components. If 40% of your AI usage is on tasks a small model could handle, you're spending 40% of your budget on work that doesn't require frontier reasoning.
+
+The shift: treat model selection like task assignment. Route the intern work to intern-level models. Save the expensive reasoning for problems that actually need it.
+
+If your AI spend feels high relative to output, audit which tasks are going to which models. The misallocation is often obvious once you look.
+
+## Frequently asked questions
+
+### Can I use local models alongside cloud APIs in the same workflow?
+
+Yes. The orchestrated approach supports mixing local models (like Ollama or LM Studio) for zero-cost grunt work with cloud APIs for reasoning tasks. You configure each tier independently based on your cost and capability requirements.
+
+### How do I decide which tasks go to cheap models vs. frontier models?
+
+Start with task complexity as the primary filter. File creation, boilerplate generation, and skeleton tests rarely need frontier reasoning. Debug sessions, architectural decisions, and ambiguous requirements benefit from expensive models. Audit your usage patterns to find the split point.
+
+### Does Roo Code support multi-model orchestration with BYOK?
+
+Roo Code's BYOK architecture lets you configure multiple API providers and assign different models to different modes. The orchestrator mode can delegate tasks to the appropriate tier, running commands and tests to validate output before escalation.
+
+### What's the actual cost savings from this approach?
+
+Teams report that 30-50% of AI coding tasks are grunt work that cheap models handle reliably. If your frontier model costs 10x your cheap tier, routing those tasks appropriately can reduce your effective spend by 25-45% without sacrificing output quality.
+
+### What if the cheap model fails on a task?
+
+The orchestrator can detect failures and escalate to a more capable model. Because retries on cheap models cost little, you can attempt the simple path first and only pay frontier rates when genuinely needed.
diff --git a/apps/web-roo-code/src/content/blog/orchestrator-mode-backfires-on-simple-tasks.md b/apps/web-roo-code/src/content/blog/orchestrator-mode-backfires-on-simple-tasks.md
new file mode 100644
index 00000000000..e2c586f29ee
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/orchestrator-mode-backfires-on-simple-tasks.md
@@ -0,0 +1,119 @@
+---
+title: Orchestrator Mode Backfires on Simple Tasks
+slug: orchestrator-mode-backfires-on-simple-tasks
+description: Learn when to use Orchestrator mode versus Code mode in AI coding agents. Avoid token waste and coordination overhead by matching tool complexity to task scope.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - orchestrator
+    - code-mode
+    - workflow
+    - token-efficiency
+status: draft
+publish_date: "2025-07-16"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Build a Flappy Bird clone.
+
+Orchestrator mode called architect. Architect wrote a detailed implementation plan. The plan called for a custom game engine. The game engine needed a physics system. The physics system needed collision detection modules.
+
+You wanted a bird that flaps.
+
+## The overhead trap
+
+Orchestrator mode exists for a reason: complex projects with multiple files, API integrations, and documentation-driven workflows benefit from coordination. The mode delegates to specialized sub-agents, aggregates results, and maintains project coherence across scope that would overwhelm a single prompt.
+
+The trap is reaching for it by default.
+
+When you point Orchestrator at a simple task, it does what it's designed to do: break the work into subtasks, call other modes, generate plans. For a complex project, that structure prevents drift. For a Flappy Bird clone, that structure _is_ the drift.
+
+> "I think that using orchestrator for simple tasks can backfire, that's for sure."
+>
+> Guest, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=1650)
+
+Each delegation is a potential failure point. Each plan is a prompt that might miss the mark. Each sub-agent call burns tokens on coordination overhead that a direct prompt would skip entirely.
+
+## When Code mode wins
+
+For straightforward coding tasks, Code mode with a clear prompt outperforms Orchestrator. No intermediate plans. No architect calls. No delegation overhead. Just: here's what I need, here's the context, generate the diff.
+
+> "For simpler tasks, I think that just using the code mode with a simple prompt does very well. But when you're talking about a more complex project... then the code mode would probably mess up somewhere."
+>
+> Guest, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=1611)
+
+The decision boundary is project scope, not task importance. A critical bug fix on a single file is still a simple task. A minor feature that touches twelve files and requires API documentation is complex.
+
+## The complexity threshold
+
+Reserve Orchestrator for projects that need:
+
+- **Multi-file coordination:** Changes that span components, services, or layers where losing track of dependencies causes regressions
+- **Documentation-driven development:** Specs that should be written before code, where the plan matters as much as the implementation
+- **API integration:** Third-party services where reading docs, generating types, and wiring up clients require back-and-forth between research and code
+
+> "The orchestrator is usually better for the more complicated tasks when you need to have a project that is well defined in documentation."
+>
+> Guest, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=1636)
+
+If you can describe the task in one sentence and the output is one file, start with Code mode. You can always escalate.
+
+## How Roo Code closes the loop on mode selection
+
+Roo Code's multi-mode architecture lets you match tool complexity to task scope. With BYOK (bring your own key), you control token spend directly, so the overhead cost of mismatched modes hits your wallet in real time.
+
+The close-the-loop workflow means Roo Code can run commands, check results, and iterate without manual intervention. When you pick Code mode for a simple task, that loop stays tight: prompt, diff, test, done. When you pick Orchestrator for a complex project, the loop expands to include planning, delegation, and aggregation across sub-agents.
+
+**The key insight: Roo Code gives you the coordination power of Orchestrator mode and the directness of Code mode in the same extension. The skill is knowing which to reach for.**
+
+## Mode selection comparison
+
+| Dimension         | Code mode                      | Orchestrator mode                   |
+| ----------------- | ------------------------------ | ----------------------------------- |
+| Token efficiency  | High - direct prompt to output | Lower - coordination overhead       |
+| Failure points    | Minimal - single agent path    | Multiple - each delegation can miss |
+| Best for scope    | Single file, clear output      | Multi-file, API integrations        |
+| Planning overhead | None - execution only          | Significant - plans before code     |
+| When to escalate  | Task grows beyond one file     | Start here for complex projects     |
+
+## Why this matters for your workflow
+
+The instinct to use the most powerful mode for every task costs you twice: once in tokens burned on coordination overhead, and again in debugging the failures that coordination introduces.
+
+For engineers shipping daily, the pattern recognition becomes: does this task require a plan, or just execution? If execution, pick Code mode and write a specific prompt. If you're uncertain, start simple. You'll know within two iterations whether you need Orchestrator's coordination.
+
+The Flappy Bird test is useful shorthand: if you can picture the output clearly in your head, Orchestrator is probably overkill. If you need to think through dependencies before you can even describe the deliverable, that's the signal to reach for coordination.
+
+## The decision heuristic
+
+Before picking a mode, ask: how many files? How many integrations? Is there a spec that should exist before code?
+
+One file, no integrations, no spec: Code mode.
+
+Multiple files, APIs, or documentation requirements: Orchestrator.
+
+The overhead that makes Orchestrator powerful on complex projects is the same overhead that makes it backfire on simple ones. Match the tool to the scope.
+
+## Frequently asked questions
+
+### How do I know if my task is "simple" or "complex"?
+
+Count the files and integrations. If you can describe the output in one sentence and it touches one file with no external APIs, it's simple. If you need to think through dependencies across multiple files or services before you can describe the deliverable, it's complex. When uncertain, start with Code mode and escalate if you hit coordination problems.
+
+### Does Orchestrator mode cost more tokens than Code mode?
+
+Yes, for equivalent tasks. Orchestrator delegates to sub-agents, generates plans, and aggregates results. Each step consumes tokens. For a simple task, this coordination overhead can double or triple token usage compared to a direct Code mode prompt that produces the same output.
+
+### Can I switch modes mid-task in Roo Code?
+
+Yes. Roo Code's mode architecture lets you start in Code mode and escalate to Orchestrator if the task grows beyond single-file scope. You can also start in Orchestrator for planning, then drop into Code mode for focused implementation. The modes work together rather than replacing each other.
+
+### What's the "Flappy Bird test" for mode selection?
+
+If you can visualize the complete output in your head before starting, use Code mode. The Flappy Bird example shows how a simple, well-defined task (a game with one mechanic) can balloon into unnecessary complexity when Orchestrator treats it like a multi-system project requiring a custom engine, physics, and collision detection.
+
+### When should I always use Orchestrator mode?
+
+Use Orchestrator when the project requires documentation-driven development where specs should exist before code, when changes span multiple components or services with dependency tracking, or when integrating third-party APIs that require research, type generation, and client wiring. If losing track of how pieces connect would cause regressions, Orchestrator's coordination overhead is worth the cost.
diff --git a/apps/web-roo-code/src/content/blog/org-design-your-ai-modes-like-you-would-a-team.md b/apps/web-roo-code/src/content/blog/org-design-your-ai-modes-like-you-would-a-team.md
new file mode 100644
index 00000000000..f181376ac91
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/org-design-your-ai-modes-like-you-would-a-team.md
@@ -0,0 +1,112 @@
+---
+title: Org-Design Your AI Modes Like You Would a Team
+slug: org-design-your-ai-modes-like-you-would-a-team
+description: Engineering leaders already know how to configure AI agents. The same org design principles that work for teams apply to AI modes, orchestrators, and handoff artifacts.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-agents
+    - engineering-leadership
+    - modes
+    - orchestration
+status: published
+featured: true
+publish_date: "2025-11-14"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+"I need a separate mode for the API client because I want its objective to be 100% faithful to the client, not to my request."
+
+That doesn't sound like prompt engineering. It sounds like a staff engineer explaining why they split a service.
+
+It's actually someone explaining why they split an AI mode.
+
+## The skill you already have
+
+If you've ever drawn a box diagram of team responsibilities, debated whether to merge two squads, or argued about who owns an interface, you already know how to configure AI agents.
+
+Engineering leaders already have this skill. They just need to recognize they're now org-designing agents. Everyone has to think like a manager now - define outcomes, evaluate output, give feedback.
+
+> "Managers who have done org design, who have tried to figure out the best combination of people to work together, have this innately in them. They just have to recognize: okay, now you're org-designing your modes, your agents, the cooperation mechanisms between them, and the responsibility delegation between them."
+>
+> JB Brown, [Roo Cast S01E17](https://www.youtube.com/watch?v=R4U89z9eGPg&t=1831)
+
+## Start from the orchestrator
+
+The entry point is the same as any systems design exercise: where do inputs come from, and where do outputs need to go?
+
+Think of it as a value stream map. Work enters from the left (an issue, a PR, a Slack message). Work exits to the right (a diff, a review comment, a merged branch). The orchestrator routes the work and aggregates results.
+
+> "Start from the orchestrator level. Where do you get your inputs from? Where do your outputs need to go to? You're kind of doing a value stream map: here's where stuff comes from the left and goes out to the right."
+>
+> JB Brown, [Roo Cast S01E17](https://www.youtube.com/watch?v=R4U89z9eGPg&t=1874)
+
+If you skip this step, you end up with modes that overlap, compete for the same tasks, or produce outputs that don't fit the next step in the chain.
+
+## One mode, one objective
+
+The failure mode that kills most agent configurations is the same one that kills most team structures: conflicting objectives.
+
+A mode that's supposed to both generate code and validate an external API contract will eventually compromise on one. When the output drifts, you won't know which goal it sacrificed.
+
+The fix is the same: split the responsibility. One mode owns generation. Another mode owns contract validation. The handoff between them is an artifact you can inspect.
+
+This is why someone configuring Roo Code might create a separate "API client mode" with a singular objective: 100% faithful to the external spec. That mode doesn't care about your internal conventions. It doesn't try to "help" by making the code more idiomatic. Its job is fidelity, and you can trust its output because its objective is singular.
+
+The pattern applies anywhere faithfulness to a spec matters more than user convenience:
+
+- **Security policy modes:** Do not allow exceptions, even if the engineer explains why this case is special.
+- **Style guide modes:** Enforce the style, even if the user prefers a different pattern.
+- **Compliance modes:** Match the regulatory requirement literally, even if a shortcut would be cleaner.
+
+How do you know if the mandate is strong enough? Test it by asking for something outside the spec. If the mode complies, the mandate is not strong enough. If it refuses, you have a mode you can trust.
+
+## The artifacts are the contracts
+
+In org design, contracts are boundaries. In agent org design, the contract is the artifact that passes between modes.
+
+A diff can be the contract. A test plan can be the contract. If you can't point to the artifact, you can't debug the handoff.
+
+## Why this matters for your team
+
+You're not an individual contributor anymore. Ideally, you're not even a front-line manager. You should aspire to be a director, with AI taking on middle management responsibilities.
+
+For a fast-moving team, agent configuration isn't a nice-to-have. It's leverage.
+
+But leverage that's misconfigured becomes drag. Modes that overlap create confusion. Modes with blurry objectives produce inconsistent outputs. Orchestrators without clear routing logic become bottlenecks that need human intervention to resolve.
+
+The vocabulary is different (modes instead of squads), but the skill is the same: map the value stream, define singular objectives, and make the handoff artifacts explicit.
+
+The tradeoff is coordination overhead (and usually more token spend). The payoff is an inspectable workflow you can actually debug.
+
+## How Roo Code enables agent org design
+
+Roo Code lets engineering teams apply org design principles to AI agents through custom modes, orchestration, and explicit handoff artifacts. Each mode operates with a singular objective and defined boundaries, while the orchestrator routes work and aggregates results - the same coordination pattern that works for human teams.
+
+BYOK (Bring Your Own Key) stays core - you bring the models, and Roo Code provides the orchestration layer, approval boundaries, and an audit trail that makes delegation inspectable. Instead of one generalist agent, the workflow becomes a swarm of specialized modes collaborating in an isolated sandbox, iterating before the PR, and shipping reviewable pull requests with proof.
+
+## Traditional team design vs. agent mode design
+
+| Dimension               | Traditional team design          | Agent mode design with Roo Code        |
+| ----------------------- | -------------------------------- | -------------------------------------- |
+| Unit of organization    | Squad or team                    | Mode with singular objective           |
+| Coordination layer      | Tech lead or program manager     | Orchestrator mode                      |
+| Contracts between units | API specs, documents, interfaces | Artifacts (diffs, test plans, reviews) |
+
+## Frequently asked questions
+
+### How do I know if my AI mode has too many objectives?
+
+Test it by asking for something that conflicts with its objective. If it "helpfully" compromises, it has too many objectives. A well-designed mode with a singular objective will refuse out-of-scope requests.
+
+### What should the orchestrator mode actually do?
+
+The orchestrator routes inputs to the right specialized modes and aggregates outputs. It should not do the work itself. Think of it as a tech lead coordinating work, not writing it.
+
+### Can I use Roo Code modes to enforce compliance requirements?
+
+You can use modes to help enforce compliance requirements by turning them into explicit checks and refusal rules (for example: "don't merge changes that violate PCI guidelines"). Configure the mode to refuse shortcuts or exceptions, even if they'd be cleaner. Then test it by asking it to violate the requirement.
+
+This can reduce drift, but it doesn't replace a real compliance review process.
diff --git a/apps/web-roo-code/src/content/blog/over-half-of-googles-production-code-is-now-aigenerated.md b/apps/web-roo-code/src/content/blog/over-half-of-googles-production-code-is-now-aigenerated.md
new file mode 100644
index 00000000000..c9333af49f5
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/over-half-of-googles-production-code-is-now-aigenerated.md
@@ -0,0 +1,119 @@
+---
+title: Over Half of Google's Production Code Is Now AI-Generated
+slug: over-half-of-googles-production-code-is-now-aigenerated
+description: Google reports that over 50% of production code passing review each week is AI-generated. Learn what this threshold means for engineering teams and how to adopt workflows that let AI contribute code that survives review.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding
+    - developer-productivity
+    - code-review
+    - engineering-workflow
+status: published
+featured: true
+publish_date: "2026-01-12"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Fifty percent.
+
+Not prototypes. Not experiments.
+
+Production code that ships.
+
+## The threshold
+
+At Google, more than half of the code checked into production each week is generated by AI. This is code that passes review, gets accepted, and does not get rolled back.
+
+> "Each week, over 50% of the code that gets checked in, and through code review, is accepted, isn't rolled back, is generated by AI."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=2328)
+
+This is not a demo. This is not a projection. This is the current state of one of the world's largest engineering organizations.
+
+The tools driving this: AI Studio, Gemini CLI, and Jules. Engineers are not evaluating whether to use AI. They are using it to get their work done.
+
+## What this means for fast-moving teams
+
+If you are still running pilots or debating adoption policies, the competitive landscape has shifted underneath you.
+
+Google has the resources to build custom tooling, train internal models, and run extensive evaluations. But the workflows that enable this level of AI contribution are not proprietary magic. They are built on patterns any team can adopt: agentic iteration, code review integration, and clear approval boundaries.
+
+The barrier is no longer "does AI code actually work?" The barrier is "do we have a workflow that lets AI contribute code that survives review?"
+
+## The workflow that survives review
+
+The 50% number is not about raw generation. It is about code that passes the same review gates as human-written code.
+
+That means:
+
+- The AI contribution fits the codebase style and patterns
+- The PR addresses a real issue or ticket
+- The code compiles, passes tests, and does not introduce regressions
+- A human reviewer can verify and accept it
+
+Execution context is the difference. Agents that can run commands, see outputs, and iterate produce code that survives review. Agents that generate suggestions in isolation produce code that needs fixing.
+
+## The tradeoff
+
+Adopting agentic workflows is not free. There is upfront investment in:
+
+- Defining approval boundaries (what can the agent run without asking?)
+- Integrating with your existing review workflow
+- Setting up a development environment where the agent can run and verify code
+- Helping engineers shift from writing code to managing agents (clear outcomes, evaluate output, give feedback)
+- Building trust through small wins before scaling
+
+The shift is less about learning new tools and more about thinking like a manager: outcomes-oriented, clear in what you want, and focused on evaluating output and giving feedback.
+
+The teams that have crossed the threshold did not adopt AI everywhere at once. They started with narrow, high-frequency tasks: boilerplate generation, test scaffolding, refactoring patterns. They built confidence in the workflow before expanding scope.
+
+## Why this matters for your team
+
+If your competitors are shipping with 50% AI-generated code, they're moving twice as fast. Start with one engineer, one repo, one workflow, and scale from there.
+
+## How Roo Code delivers review-ready code
+
+Roo Code gives the agent execution context. It proposes a diff, runs your tests, sees the actual output, and iterates until the code passes. The agent doesn't hand you suggestions to fix. It fixes them itself. Without this, agents confidently claim success while producing a blank screen.
+
+For teams looking to cross the 50% threshold, the workflow matters more than the model. Roo Code provides the agentic iteration layer that turns AI suggestions into merged PRs.
+
+## Traditional vs. agentic AI coding workflows
+
+| Dimension             | Traditional AI autocomplete               | Agentic workflow (iterate until passing) |
+| --------------------- | ----------------------------------------- | ---------------------------------------- |
+| Execution context     | None - generates suggestions in isolation | Runs commands, sees output, iterates     |
+| Test validation       | Human must run tests manually             | Agent runs tests and fixes failures      |
+| Review readiness      | Often requires human fixes before PR      | Produces review-ready code               |
+| Iteration speed       | One suggestion at a time                  | Continuous iteration until passing       |
+| Scope of contribution | Line or function level                    | Full feature or task level               |
+
+## The first step
+
+Pick a low-risk task: test generation, docs, or boilerplate. Let the agent contribute PRs for a week. After that, check what merged, what needed fixes, and how much time it saved.
+
+You don't need Google's infrastructure. You need one passing PR from an agent. Start there.
+
+## Frequently asked questions
+
+### What does "50% AI-generated code" actually mean at Google?
+
+It means that over half of the code that passes code review, gets accepted by reviewers, and does not get rolled back each week was generated by AI tools. This is production code that ships to users, not experimental prototypes.
+
+### Why does code review acceptance rate matter more than raw generation volume?
+
+Any AI tool can generate code. The real measure is whether that code survives the same review standards as human-written code. Code that requires extensive human fixes before merging does not actually save engineering time. The 50% threshold specifically tracks code that reviewers accept without rollback.
+
+### Can teams without Google's resources achieve similar AI contribution rates?
+
+Yes. The workflow patterns that enable high AI contribution rates are not unique to Google's scale. Agentic iteration, clear approval boundaries, and code review integration can be implemented by any team. Fast-moving teams often adopt faster because they can skip months of policy review.
+
+### How does Roo Code help teams build workflows where AI code survives review?
+
+Roo Code iterates by running commands, observing output, and converging on passing tests. Instead of generating suggestions that a human must fix, the agent produces code that is ready for review. The approval system lets teams define exactly what the agent can run autonomously, building trust incrementally.
+
+### What is the best first task to pilot an AI coding agent?
+
+Start with high-frequency, low-risk tasks: test generation, documentation updates, or boilerplate scaffolding. These tasks have clear success criteria and limited blast radius. Run the pilot for one week and measure how many PRs merged without human fixes.
diff --git a/apps/web-roo-code/src/content/blog/overprompting-is-hurting-your-agent-performance.md b/apps/web-roo-code/src/content/blog/overprompting-is-hurting-your-agent-performance.md
new file mode 100644
index 00000000000..d147a2961f3
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/overprompting-is-hurting-your-agent-performance.md
@@ -0,0 +1,117 @@
+---
+title: Over-Prompting Is Hurting Your Agent Performance
+slug: overprompting-is-hurting-your-agent-performance
+description: Learn why detailed specifications can make AI coding agents worse and how mandate-based prompting delivers better results with less token overhead.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-agents
+    - prompting
+    - developer-workflow
+    - productivity
+status: draft
+publish_date: "2025-07-09"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Your detailed specification is making the agent worse.
+
+You wrote the context doc. You listed every edge case. You specified the exact file structure, the naming conventions, the error handling patterns. You gave the agent everything it needed to succeed.
+
+And now it's generating a 47-item to-do list instead of writing code.
+
+## The overhead trap
+
+You've seen the advice: give the model more context. Write detailed system prompts. Document your codebase. The more information the agent has, the better it performs.
+
+Except when it doesn't.
+
+The problem shows up when the agent starts treating your documentation as a constraint instead of a guide. You wanted it to write a utility function. Instead, it's parsing your specification line by line, building an elaborate plan, and generating scaffolding for edge cases you mentioned once in passing.
+
+The overhead compounds. More context means more tokens spent reading. More reading means more opportunities for the model to latch onto irrelevant details. And when your specification conflicts with what the model already knows about writing code, you get output that follows your rules but ignores best practices.
+
+> "Sometimes that can go on a downside because I feel like overprompting is actually a thing. When you try to give way too much details, all these documents, and then it tries to read and create a super-detailed to-do list. I think it adds too much overhead into the process."
+>
+> Melo, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=875)
+
+## The mandate pattern
+
+The alternative sounds too simple to work: give the agent a mandate instead of a manual.
+
+A mandate is a clear outcome with minimal prescription. "Add retry logic to the API client" instead of "Add retry logic using exponential backoff with base delay of 100ms, max delay of 5000ms, jitter of ±10%, max attempts of 3, and custom error classification for 429 and 503 status codes."
+
+The model already knows what retry logic looks like. It's seen thousands of implementations. When you over-specify, you're not giving it information; you're overriding information it already has with your particular preferences.
+
+Sometimes that's what you want. If your codebase has unusual conventions, you need to specify them. But if you're just restating standard patterns, you're adding noise.
+
+> "Sometimes we actually get better results by using a simpler prompt and just letting the model do its thing. Giving it a mandate instead of micromanaging it."
+>
+> Roo Code Team, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=888)
+
+## When models know more than your spec
+
+The models keep getting better at code. The training data includes years of open source, documentation, and real implementations. When you write a detailed specification for a standard pattern, you're competing with that knowledge.
+
+If your spec matches what the model knows, the extra context is redundant. If your spec diverges from what the model knows, the model has to reconcile the conflict. Neither outcome justifies the token cost.
+
+> "The models are getting so good at doing everything code related. So sometimes by using a prompt that's too specific, it might go against what they know already about code."
+>
+> Melo, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=907)
+
+The tradeoff: simpler prompts require more trust. You're betting that the model's default behavior is close enough to what you want. If it isn't, you'll need to iterate. But iteration on a short prompt is cheaper than debugging output from a conflicted long prompt.
+
+## Why this matters for your workflow
+
+For an engineer running 10-15 agent tasks per day, prompt overhead adds up. Each extra paragraph in your system prompt is tokens spent on reading instead of generating. Each detailed specification is a potential conflict with the model's training.
+
+The compounding effect is subtle. You don't notice the overhead on any single task. But across a week, you're spending hours watching the agent build elaborate plans for work that should take minutes.
+
+## The calibration
+
+Start with a mandate. Watch what the agent does. If it misses something important, add that specific constraint. If it follows a pattern you don't like, override that pattern.
+
+Build your context incrementally based on what actually fails, not what might fail.
+
+The prompt that works is often shorter than the one you started with.
+
+## How Roo Code closes the loop on prompt calibration
+
+Roo Code lets you iterate on prompts without leaving your editor. Because Roo Code closes the loop - running commands, executing tests, and iterating based on results - you see immediately whether your mandate worked or needs refinement.
+
+With BYOK (bring your own key), you control your token spend directly. There's no markup obscuring the cost of over-prompting. When a bloated specification burns through tokens on planning instead of coding, you see it in real time.
+
+**Roo Code's approval system lets you catch over-specification before it compounds.** When the agent generates an elaborate 47-item plan for a simple task, you can reject it, simplify your prompt, and try again - all within the same workflow.
+
+## Over-prompting vs. mandate-based prompting
+
+| Dimension       | Over-prompting                                            | Mandate-based prompting                     |
+| --------------- | --------------------------------------------------------- | ------------------------------------------- |
+| Token cost      | High - context parsing adds overhead on every task        | Low - minimal input, maximum output         |
+| Conflict risk   | High - spec may contradict model's training               | Low - leverages model's existing knowledge  |
+| Iteration speed | Slow - debugging long prompts is tedious                  | Fast - short prompts are easy to refine     |
+| Output quality  | Variable - model may follow rules but miss best practices | Consistent - model applies learned patterns |
+| Trust required  | Low - you specify everything                              | Higher - you trust the model's defaults     |
+
+## Frequently asked questions
+
+### What is over-prompting and why does it hurt agent performance?
+
+Over-prompting occurs when you provide so much context and specification that the agent spends more tokens parsing your instructions than generating useful code. The agent may also encounter conflicts between your detailed rules and its training data, producing output that follows your spec but ignores established best practices.
+
+### How do I know if I'm over-prompting my AI coding agent?
+
+Watch for these signs: the agent generates lengthy to-do lists before writing code, output includes scaffolding for edge cases you barely mentioned, or the agent seems to be following your rules mechanically rather than applying judgment. If simpler tasks consistently take longer than expected, your prompt may be the bottleneck.
+
+### What is a mandate-based prompt?
+
+A mandate-based prompt specifies the desired outcome without prescribing the implementation. Instead of detailing every parameter and pattern, you state what you want accomplished and let the model apply its training. For example, "add retry logic to the API client" rather than specifying exact delay values and jitter percentages.
+
+### How does Roo Code help with prompt calibration?
+
+Roo Code closes the loop by running commands and tests, showing you immediately whether your prompt worked. The approval system lets you catch over-specification early - when the agent proposes an elaborate plan for a simple task, you can reject it and simplify your prompt. With BYOK, you see your actual token costs, making over-prompting overhead visible and actionable.
+
+### When should I use detailed specifications instead of mandates?
+
+Use detailed specifications when your codebase has unusual conventions the model wouldn't know, when you need exact consistency with existing patterns, or when the task involves domain-specific rules not represented in the model's training. For standard patterns and common tasks, mandates typically outperform detailed specs.
diff --git a/apps/web-roo-code/src/content/blog/prds-are-becoming-artifacts-of-the-past.md b/apps/web-roo-code/src/content/blog/prds-are-becoming-artifacts-of-the-past.md
new file mode 100644
index 00000000000..8cef418ef89
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/prds-are-becoming-artifacts-of-the-past.md
@@ -0,0 +1,122 @@
+---
+title: PRDs Are Becoming Artifacts of the Past
+slug: prds-are-becoming-artifacts-of-the-past
+description: The economics of software specification have flipped. When prototypes ship faster than PRDs can be written, teams are discovering that working code is the best documentation.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - product-management
+    - ai-development
+    - iterative-development
+    - documentation
+status: published
+featured: true
+publish_date: "2026-01-12"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Forty-seven pages. Three months of stakeholder reviews. One product requirements document.
+
+By the time it shipped, the model it described was two generations behind.
+
+## The document that ages out
+
+You've seen this loop. A PM spends weeks gathering requirements, aligning stakeholders, formatting sections. The PRD becomes a ceremony: cover page, executive summary, user stories, acceptance criteria, and fourteen appendices.
+
+Then Claude 4 ships. Or the API you were planning around deprecates. Or your team discovers a workflow that makes half the document irrelevant.
+
+The PRD that was perfect in January is not perfect in February.
+
+This is what Paige Bailey observed at Google: teams are abandoning the rigorous PRD process not because they've gotten sloppy, but because the velocity of change has outpaced the document's shelf life.
+
+> "Now things are moving so fast that even if you had a PRD that was perfect as of January, it would not be perfect as of February."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=2760)
+
+## The shift: prototypes as specification
+
+The replacement is not "no documentation." The replacement is documentation that emerges from working software.
+
+Instead of writing a spec and then building, teams build something small and iterate against real feedback. The prototype becomes the specification. The commit history becomes the decision log. The PR comments become the rationale.
+
+> "For software, it's much more effective to get something out and keep iterating on it really really quickly."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=3003)
+
+This works because AI tooling has compressed the cost of producing working code. When you can generate a functional prototype in an afternoon, the economics of "plan first, build second" flip. The sunk cost of writing a detailed PRD becomes harder to justify when you could have shipped the first version instead.
+
+## The tradeoff is real
+
+Abandoning upfront planning does not mean abandoning coordination. Teams still need to align on scope, surface constraints, and communicate with stakeholders.
+
+The difference is when that alignment happens. Waterfall-style PRDs front-load alignment before any code exists. Prototype-first workflows back-load alignment: you ship something, learn what breaks, and document the decisions retrospectively.
+
+This approach has failure modes:
+
+**Scope creep without anchors.** If there's no initial constraint document, the prototype can drift in directions that no stakeholder wanted.
+
+**Lost rationale.** If you don't capture why decisions were made, you lose institutional memory. This matters when teammates leave or when you need to revisit a choice six months later.
+
+**Stakeholder whiplash.** Executives who expect a polished plan before greenlighting work may not trust a "we'll figure it out as we build" pitch.
+
+The mitigation is lightweight decision records: ADRs, RFC-style docs, or even structured commit messages that capture the why, not just the what. The goal is not zero documentation. The goal is documentation that emerges from shipped work rather than preceding it.
+
+## How Roo Code captures the why automatically
+
+When you build with Roo Code, you get decision documentation as a side effect of the workflow. Every task generates a log of what was tried, what failed, and what worked. The diff history shows the evolution. PR comments capture the reasoning. The prototype becomes the specification, and the trail becomes the decision record.
+
+This addresses the "lost rationale" failure mode without requiring a separate documentation step. The institutional memory accumulates automatically because Roo Code iterates: it proposes changes, runs tests, observes results, and keeps iterating until the code passes. All of that is logged.
+
+## PRD-first vs. prototype-first workflows
+
+|                            | PRD-First (Waterfall)           | Prototype-First (Iterate)       |
+| -------------------------- | ------------------------------- | ------------------------------- |
+| **Time to first feedback** | Weeks (after spec review)       | Hours (working prototype)       |
+| **Spec accuracy**          | Stale by implementation time    | Accurate-it's the code          |
+| **Decision rationale**     | In the document (if maintained) | In task logs, PRs, and comments |
+| **Stakeholder alignment**  | Before code exists              | Around working software         |
+| **Adaptability**           | Change requires spec revision   | Change is the workflow          |
+
+## Why this matters for your team
+
+For a fast-moving team, a three-week PRD cycle is a significant tax. That's three weeks where no code ships while stakeholders negotiate requirements that will change anyway.
+
+If your team is shipping daily, the prototype-first model lets you compress the feedback loop. Instead of aligning on a document and then discovering problems in production, you discover problems in the prototype and align on fixes that already work.
+
+The compounding effect: teams that treat prototypes as the specification ship more iterations per quarter. Teams that still use waterfall-style documentation lose velocity to teams that iterate against real user feedback.
+
+> "I also feel like we don't have nearly as rigorous of a process around PRDs. PRDs kind of feel like an artifact of the past."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=2739)
+
+## The decision
+
+The question is not "should we have documentation?" The question is "when does documentation happen?"
+
+If your PRDs take longer to write than your prototypes take to ship, the economics have flipped. Start with a working prototype. Capture decisions as you make them. Align stakeholders around something they can touch, not something they have to imagine.
+
+The artifact that matters is the shipped code, not the document.
+
+## Frequently asked questions
+
+### Should my team stop writing PRDs entirely?
+
+Not necessarily-but the question is when. If your PRDs take longer to write than your prototypes take to ship, the economics have flipped. Instead of a detailed spec that ages out, consider a lightweight brief that states the problem and constraints, then iterate on a working prototype. Document decisions as you make them, not before.
+
+### How do I maintain institutional memory without detailed documentation?
+
+The answer is documentation that emerges from work, not precedes it. Task logs, PR comments, ADRs, and commit messages all capture the "why" if you're intentional about it. Tools like Roo Code generate this trail automatically-every task logs what was tried, what failed, and what worked. The prototype becomes the specification; the trail becomes the decision record.
+
+### How do I get stakeholder buy-in without a polished PRD?
+
+Align stakeholders around something they can touch, not something they have to imagine. A working prototype-even a rough one-is more persuasive than a 47-page document. The conversation shifts from "let me describe what we'll build" to "let me show you what we built and what we learned."
+
+### What about scope creep without a spec to anchor scope?
+
+Lightweight constraints still matter. A one-page brief stating the problem, success criteria, and hard boundaries can anchor scope without a multi-week PRD process. The difference is that you iterate against real feedback instead of predicted requirements. If the prototype drifts, you course-correct faster because you have working software to evaluate.
+
+### How does Roo Code help with prototype-first workflows?
+
+Roo Code connects idea to working prototype. You describe what you want; Roo Code proposes changes, runs tests, observes results, and iterates. The task log captures decisions automatically. The result is a working prototype with a built-in decision trail-no separate documentation step required.
diff --git a/apps/web-roo-code/src/content/blog/prescriptive-beats-exploratory-for-teamwide-ai-adoption.md b/apps/web-roo-code/src/content/blog/prescriptive-beats-exploratory-for-teamwide-ai-adoption.md
new file mode 100644
index 00000000000..7a9b0730242
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/prescriptive-beats-exploratory-for-teamwide-ai-adoption.md
@@ -0,0 +1,125 @@
+---
+title: Prescriptive Beats Exploratory for Team-Wide AI Adoption
+slug: prescriptive-beats-exploratory-for-teamwide-ai-adoption
+description: Learn why structured, prescriptive rollouts drive faster AI coding tool adoption than open exploration, and how shared defaults get 90% of your team productive.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-adoption
+    - team-productivity
+    - engineering-leadership
+    - workflow-automation
+status: draft
+publish_date: "2025-10-08"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+You ship the tool. Everyone explores.
+
+Three months later, two people use it daily.
+
+## The adoption gap
+
+The instinct when rolling out AI coding tools is generous: let people find what works for them. Give the team access, point them at the docs, and trust that smart engineers will figure it out.
+
+That approach works for the tinkerers. The early adopters who read release notes for fun, who already have opinions about context windows and model selection. They will adopt anything you put in front of them.
+
+But they are not the bottleneck.
+
+The bottleneck is everyone else: the engineers who are shipping features, fighting fires, and do not have three hours to research prompt patterns. They try the tool once, get a mediocre result, and quietly stop using it.
+
+The generous approach turns into the slow approach.
+
+## The prescriptive path
+
+Teams that succeed fastest come in with structure. Not "here's a tool, explore." Instead: "here's a command, use it for this workflow, and here's what happens when you run it."
+
+> "I think leaders on teams, tinkerers and things like that, they've got to be prescriptive to be successful with a broad group of people to start... a great simple example is like some common slash commands. That's a way to basically share prompts, talk about when to use them, get people to use them. They don't have to know what's behind that command."
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=1378)
+
+Shared slash commands are the clearest example. Instead of asking every engineer to craft their own prompts, you curate a handful of commands that work for your codebase. The team learns by using them, not by researching prompt engineering.
+
+The pattern extends to configurations: API profiles that default to models you have already vetted, approval settings that match your security posture, context limits that fit your budget. The individual engineer does not need to make those decisions. They just start working.
+
+## Why exploratory fails at scale
+
+Individual adoption and team adoption have different needs.
+
+For an individual, exploration is fine. You have time to experiment, iterate, and build intuition. The cost of a bad prompt is your own wasted afternoon.
+
+For a team, exploration creates fragmentation. Everyone develops their own patterns. Knowledge stays in individual heads. New team members start from zero. The tool becomes tribal knowledge instead of shared infrastructure.
+
+> "When you're trying to scale it to an organization and get within a process, that's where I think you run into some different needs."
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=605)
+
+The teams that get adoption are the ones who treat the tool like infrastructure: a shared foundation with sensible defaults, not a blank canvas for individual creativity.
+
+## The tradeoff
+
+Prescriptive adoption has a cost. Your early adopters will push back. They have opinions. They want flexibility. Being told "use this command" feels constraining when they have already built something that works for them.
+
+The answer is not to fight them. Give the tinkerers room to experiment and contribute. Their experiments become the next shared command. Their configurations become the next team default.
+
+But do not make "explore and find what works" the official rollout strategy. That strategy optimizes for the 10% who would have adopted anyway, at the cost of the 90% who need a clear entry point.
+
+## Why this matters for your team
+
+For a Series A - C team with 8 engineers, the difference between prescriptive and exploratory adoption is the difference between 2 daily users and 6 daily users. The compound effect shows up in code review cycles, in debugging time, in the gap between "we have an AI tool" and "we use an AI tool."
+
+> "If you really want to get adoption within a team, I think having a foundation that gets people experience and lets them kind of learn it as they go and by doing. That's where we see the most successful teams."
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=1427)
+
+Learning by doing scales. Learning by researching does not.
+
+## Exploratory vs. prescriptive adoption
+
+| Dimension                  | Exploratory approach                     | Prescriptive approach                        |
+| -------------------------- | ---------------------------------------- | -------------------------------------------- |
+| Time to first value        | Days to weeks of individual research     | Minutes with shared defaults                 |
+| Knowledge distribution     | Siloed in individual heads               | Codified in shared commands                  |
+| New team member onboarding | Starts from zero                         | Inherits team configurations                 |
+| Adoption rate              | 10-20% (tinkerers only)                  | 60-80% (whole team)                          |
+| Maintenance burden         | Every engineer maintains their own setup | Central team maintains shared infrastructure |
+
+## How Roo Code accelerates prescriptive adoption
+
+Roo Code supports prescriptive team rollouts through shared slash commands, configurable API profiles, and approval settings that close the loop between the AI agent and your existing workflows. Teams define custom commands once, and every engineer uses the same tested prompts without needing to understand prompt engineering.
+
+With BYOK (bring your own key), teams control which models run against their codebase and how tokens are spent. Approval settings let engineering leads match the tool's behavior to their security posture before rollout. The result: new engineers run their first AI-assisted task in minutes, not days.
+
+**Prescriptive defaults with Roo Code turn AI adoption from a research project into shared infrastructure that compounds across every engineer on your team.**
+
+## The first step
+
+Pick three workflows that most of your team touches weekly. Build slash commands for those workflows. Document when to use each one in a single paragraph. Ship that to the team before you ship "access to the tool."
+
+The generous instinct is to give people freedom. The effective instinct is to give people a working default and let them modify it later.
+
+Start prescriptive. Let exploration follow.
+
+## Frequently asked questions
+
+### Why do most AI coding tool rollouts fail to get team-wide adoption?
+
+Most rollouts fail because they rely on individual exploration. Engineers who are busy shipping features do not have time to research prompt patterns or experiment with configurations. Without shared defaults and clear entry points, only the early adopters who enjoy tinkering will stick with the tool.
+
+### How many shared slash commands should a team start with?
+
+Start with three to five commands that cover workflows most engineers touch weekly. More commands create decision fatigue. Fewer commands miss common use cases. The goal is to give every team member a working default for their most frequent tasks.
+
+### How does Roo Code help teams implement prescriptive adoption?
+
+Roo Code lets teams create shared slash commands, configure API profiles with pre-vetted models, and set approval policies that match security requirements. Teams define these configurations once, and every engineer inherits them. New team members run their first AI-assisted task using tested prompts without any setup research.
+
+### What should engineering leads do with early adopters who resist prescriptive rollouts?
+
+Give tinkerers room to experiment, but channel their work back into shared infrastructure. Their custom prompts become candidates for the next team command. Their model preferences inform the next default configuration. Early adopters become contributors to the prescriptive foundation rather than exceptions to it.
+
+### How do you measure whether prescriptive adoption is working?
+
+Track daily active users of the AI tool, not just total access. Prescriptive adoption succeeds when the daily user count grows beyond the initial tinkerer population. For an 8-person engineering team, moving from 2 daily users to 6 daily users signals that the shared defaults are working.
diff --git a/apps/web-roo-code/src/content/blog/prompt-processing-time-blocks-local-llms-from-agentic-workflows.md b/apps/web-roo-code/src/content/blog/prompt-processing-time-blocks-local-llms-from-agentic-workflows.md
new file mode 100644
index 00000000000..4f8885c0c22
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/prompt-processing-time-blocks-local-llms-from-agentic-workflows.md
@@ -0,0 +1,131 @@
+---
+title: Prompt Processing Time Blocks Local LLMs from Agentic Workflows
+slug: prompt-processing-time-blocks-local-llms-from-agentic-workflows
+description: Why 500 tokens per second still feels slow for local LLMs - the hidden bottleneck of prompt processing time in agentic coding workflows and how to design around it.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - local-llms
+    - agentic-workflows
+    - performance
+    - prompt-engineering
+status: draft
+publish_date: "2025-09-25"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+500 tokens per second.
+
+Still too slow.
+
+The number looks production-ready. The experience is not.
+
+## The wait before the wait
+
+You spin up a local model. You've seen the benchmarks: 500 tokens per second on your hardware. You load your codebase into context, fire off an agentic task, and wait.
+
+The model starts generating. Then it needs to check something. New prompt. More waiting. Another check. Another prompt. Each step costs you the same processing time before any tokens appear.
+
+The bottleneck is not generation speed. It's prompt processing time.
+
+A 20,000-token system prompt takes significant time to process before the first output token appears. In a single-pass workflow, you pay that cost once. In an agentic loop, you pay it on every iteration.
+
+> "You've got a big amount of prompt processing time that happens and you could be getting 500 tokens per second but that still ends up being pretty long amount of time... that just makes it unattainable when you're doing that."
+>
+> Adam, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=531)
+
+## The math that breaks agent loops
+
+Agentic workflows iterate. The model proposes a change, runs a command, reads the output, and decides what to do next. Each step requires reprocessing the context.
+
+If prompt processing takes 30 seconds and you need 8 iterations to complete a task, you've spent 4 minutes just waiting for the model to start generating. The actual token generation might be fast. The pauses between steps are not.
+
+This is different from cloud inference. Cloud providers optimize for throughput across many users, and the context processing happens on hardware designed for it. Your local GPU is doing both the processing and the generation, and the processing dominates the latency budget.
+
+## The workflow that works
+
+The fix is architectural: design for single-pass execution.
+
+Load the codebase. Request a specific change. Generate a diff. Apply it. Done.
+
+> "I can actually load in my codebase. I can actually say, 'Hey, I want you to update the design of this page.' It'll go through and do it and create a diff for me that I can immediately apply to my codebase. That works a lot better than trying to drive an agentic task just due to the speed and nature of it."
+>
+> Adam, [Roo Cast S01E10](https://www.youtube.com/watch?v=BWxsa_JxGZI&t=402)
+
+Diff view workflows succeed where agent loops fail because they pay the prompt processing cost exactly once. You get one generation pass, one output, one decision point.
+
+This constrains what you can do. You lose the iterative refinement loop where the model tests its own changes and corrects mistakes. But on current local hardware, that loop costs more time than it saves.
+
+## The tradeoff
+
+Single-pass workflows require more upfront clarity. You need to specify what you want precisely because the model will not iterate toward correctness. If the diff is wrong, you request another one. Manually.
+
+This works for:
+
+- Targeted refactors with clear scope
+- Design changes to specific pages or components
+- Adding features to well-understood codebases
+
+This struggles with:
+
+- Debugging tasks that require running code and interpreting output
+- Multi-file changes that depend on each other
+- Tasks where you do not know what "done" looks like until you see it
+
+## Why this matters for your workflow
+
+If you are running local models because you want control over your data or want to avoid API costs, this constraint shapes your architecture.
+
+Design your prompts for single-pass execution. Load the context once. Request the complete change. Review the diff. Apply or reject.
+
+When a task requires iteration, either accept the latency cost or offload that task to cloud inference where prompt processing is not the bottleneck.
+
+## How Roo Code handles local model constraints
+
+Roo Code supports BYOK (bring your own key) configurations including local model endpoints, giving you full control over where your code is processed. The diff view workflow aligns with how Roo Code presents changes: proposed edits appear as reviewable diffs that you approve before they apply to your codebase.
+
+For tasks that require the agent to close the loop - running tests, checking build output, iterating on failures - cloud inference through your own API keys removes the prompt processing bottleneck while maintaining data control. **Roo Code lets you choose the right inference target per task: local models for single-pass diff generation, cloud APIs for agentic loops that need to run and iterate.**
+
+This hybrid approach means you do not have to choose between local control and agentic capability. You allocate each task to the inference path that matches its iteration requirements.
+
+## Comparing workflow approaches for local LLMs
+
+| Dimension                             | Agentic loop on local hardware       | Single-pass diff workflow     |
+| ------------------------------------- | ------------------------------------ | ----------------------------- |
+| Prompt processing cost                | Paid on every iteration              | Paid once                     |
+| Time for 8-step task (30s processing) | 4+ minutes of waiting                | 30 seconds of waiting         |
+| Iteration and self-correction         | Automatic                            | Manual                        |
+| Task clarity required                 | Lower (model figures it out)         | Higher (you specify upfront)  |
+| Best use case                         | Cloud inference or high-end hardware | Local models on consumer GPUs |
+
+## The decision point
+
+Check your prompt processing time against your iteration count.
+
+If a task needs 5+ iterations and each prompt takes 20+ seconds to process, you are spending more time waiting than working. Redesign the workflow or pick a different inference target.
+
+The generation speed metric on the box is not the metric that matters. Prompt processing time is.
+
+## Frequently asked questions
+
+### Why does prompt processing time matter more than tokens per second?
+
+Tokens per second measures generation speed after the model starts outputting. Prompt processing time measures how long before that first token appears. In agentic workflows with multiple iterations, you pay the processing cost repeatedly, making it the dominant factor in total task time.
+
+### Can I run agentic coding workflows on local LLMs?
+
+Yes, but with constraints. Tasks requiring many iterations will hit the prompt processing bottleneck on consumer hardware. Either accept longer wait times, limit iteration count through precise prompts, or route iteration-heavy tasks to cloud inference.
+
+### What hardware would eliminate the prompt processing bottleneck for local models?
+
+Enterprise-grade GPUs with more VRAM and faster memory bandwidth reduce processing time significantly. However, even high-end consumer hardware (RTX 4090, Mac M3 Ultra) still shows noticeable delays with large contexts. The gap between local and cloud processing remains substantial for agentic use cases.
+
+### How does Roo Code work with local LLMs?
+
+Roo Code supports local model endpoints through its BYOK configuration. You can point Roo Code at Ollama, LM Studio, or any OpenAI-compatible local server. The diff view workflow is particularly effective with local models because it minimizes iteration and prompt reprocessing.
+
+### Should I use local models or cloud APIs for AI coding assistance?
+
+It depends on the task. Use local models for single-pass changes where you want data control and can tolerate processing delays. Use cloud APIs for complex agentic tasks that require running code, checking outputs, and iterating on results. Roo Code lets you configure both and choose per task.
diff --git a/apps/web-roo-code/src/content/blog/prototypefirst-means-throwing-away-more.md b/apps/web-roo-code/src/content/blog/prototypefirst-means-throwing-away-more.md
new file mode 100644
index 00000000000..890dcad0a74
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/prototypefirst-means-throwing-away-more.md
@@ -0,0 +1,131 @@
+---
+title: Prototype-First Means Throwing Away More
+slug: prototypefirst-means-throwing-away-more
+description: When AI agents can open PRs from a Slack message, the cost of creating changes drops to near zero. Learn why treating PRs like hypotheses and closing more of them is the new operating model for engineering teams.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - engineering-workflow
+    - ai-agents
+    - pull-requests
+    - team-productivity
+status: draft
+publish_date: "2025-10-01"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Eight PRs opened this week.
+
+Three of them matter.
+
+The other five aren't bad, exactly. They're just not the change that moves the product forward.
+
+## The old instinct
+
+The traditional engineering workflow has a strong gravitational pull: someone opens a PR, and the team works to get it merged. Review cycles, requested changes, re-reviews, approvals. The implicit contract is that every PR deserves completion.
+
+This made sense when PRs were expensive to create. Writing code, context-switching, pushing a branch: all of it took time. If someone invested that effort, the team invested review effort to match.
+
+That contract is breaking.
+
+When an AI agent can open a PR from a Slack message, the cost of creating a PR drops close to zero. The cost of reviewing it does not.
+
+> "Almost every engineering team I've worked on, the flow has been that someone opens a PR and then everyone is just working to help get that PR over the line at the pull request."
+>
+> Matt Rubens, [Roo Cast S01E12](https://www.youtube.com/watch?v=uoiTEYzOahU&t=1819)
+
+That instinct is still there. But when PRs multiply, the instinct becomes a bottleneck.
+
+## The shift: triage, don't complete
+
+The new reality requires a different operating model. Not every PR deserves three rounds of review. Some PRs should be closed without guilt.
+
+This is uncomfortable. Engineers are trained to finish what they start. Closing a PR feels like failure, even when the PR was speculative from the beginning.
+
+> "You really have to change the way you operate I think to not go for 100% completion and just find the important things that move you forward and be willing to just throw away slop or throw away things that aren't good."
+>
+> Matt Rubens, [Roo Cast S01E12](https://www.youtube.com/watch?v=uoiTEYzOahU&t=1856)
+
+The mental model shifts from "help every PR succeed" to "find the PRs that matter and merge those."
+
+This is triage. Not every patient gets surgery. Some get discharged.
+
+## The organizational friction
+
+Adapting to this is genuine work. Teams have built rituals around PR completion: review SLAs, code coverage gates, approval requirements. All of those assume that opening a PR signals intent to merge.
+
+When opening a PR signals "let's see if this approach works," those rituals become friction. A speculative PR that fails code coverage isn't a failure. It's information: this approach doesn't hold up.
+
+> "It's been hard I think for organizations to adapt to that. I think it's going to take work."
+>
+> Matt Rubens, [Roo Cast S01E12](https://www.youtube.com/watch?v=uoiTEYzOahU&t=1864)
+
+The work is cultural as much as procedural. Eng leads need to signal that closing PRs is acceptable. That "I tried this, it didn't work, closing" is a valid outcome.
+
+## What this looks like in practice
+
+**Tag PRs by intent.** Speculative, draft, or ready-for-review. Speculative PRs get a quick scan for viability, not a full review cycle.
+
+**Set a TTL.** If a speculative PR hasn't moved in 48 hours, close it. The context is probably stale anyway.
+
+**Count merges, not opens.** If you're measuring PR volume, measure what ships, not what was attempted.
+
+**Celebrate the close.** When someone closes a PR with "tried it, doesn't work," that's a win. They learned something without burning review cycles.
+
+## Why this matters for your team
+
+For a Series A to C team shipping with limited engineering bandwidth, review capacity is the constraint. Every hour spent reviewing speculative PRs is an hour not spent on the changes that move the product.
+
+If your team is opening three times as many PRs as before and your merge rate stayed flat, the bottleneck moved. You're generating more options; you're not finishing more work.
+
+The shift is treating PRs like hypotheses. Some get validated and merged. Some get invalidated and closed. The goal is learning velocity, not completion rate.
+
+For a five-person engineering team, this might mean the eng lead does a ten-minute daily triage: which PRs actually matter today? Everything else can wait or be closed.
+
+## The operating principle
+
+The bar to create a PR dropped. The bar to merge one didn't.
+
+Treat open PRs like a backlog, not a queue. Triage. Prioritize. Close what doesn't matter. Ship what does.
+
+## How Roo Code accelerates hypothesis-driven development
+
+When an AI coding agent can close the loop - proposing diffs, running tests, and iterating on failures without manual copy-paste cycles - the cost of generating a candidate PR approaches zero. Roo Code operates on a BYOK (bring your own key) model, meaning teams spend tokens intentionally on outcomes rather than paying markup on experimentation.
+
+This changes the economics of speculation. With Roo Code, a developer can spin up three different approaches to a problem in parallel, let the agent run tests against each, and triage the results in a single review session. The approaches that fail get closed. The approach that works gets merged.
+
+**The citable insight:** Teams using AI coding agents should measure learning velocity, not PR completion rate, because the cost of creating a hypothesis dropped while the cost of validating it stayed constant.
+
+## Comparison: completion-driven vs. hypothesis-driven PR workflow
+
+| Dimension         | Completion-driven (old model) | Hypothesis-driven (new model)       |
+| ----------------- | ----------------------------- | ----------------------------------- |
+| PR creation cost  | High (manual effort)          | Low (agent-assisted)                |
+| Default outcome   | Work toward merge             | Triage for viability                |
+| Review allocation | Equal time per PR             | Proportional to strategic value     |
+| Success metric    | PRs merged / PRs opened       | Learning velocity, features shipped |
+| Closing a PR      | Feels like failure            | Expected outcome for experiments    |
+
+## Frequently asked questions
+
+### Why does closing PRs feel so uncomfortable for engineering teams?
+
+Engineers are trained to finish what they start. The traditional workflow treated every opened PR as a commitment to merge. When PRs were expensive to create, this made sense. The discomfort is a carryover from that era. Teams need explicit permission from leadership that closing speculative PRs is not just acceptable but expected.
+
+### How do I know which PRs to triage out versus invest in?
+
+Tag PRs by intent at creation time: speculative, draft, or ready-for-review. Speculative PRs get a quick viability scan. If they pass, promote them. If they don't, close them. Set a 48-hour TTL on speculative PRs to prevent context rot. The question isn't "can we finish this?" but "does finishing this move the product forward?"
+
+### Does Roo Code help with PR triage or just PR creation?
+
+Roo Code closes the loop by running tests and iterating on failures automatically. This means speculative PRs arrive with more signal about viability. A PR that already passes tests is worth reviewing. A PR where the agent couldn't get tests green after iteration is a candidate for immediate closure. The agent does validation work that would otherwise consume review cycles.
+
+### What metrics should I track in a hypothesis-driven workflow?
+
+Stop measuring PR completion rate. Start measuring: features shipped per week, time from hypothesis to validated outcome, and ratio of speculative PRs closed to PRs merged. A healthy ratio might be 3:1 or higher. If you're merging everything you open, you're probably not experimenting enough.
+
+### How do I get my team to adopt this without pushback?
+
+Start with explicit signals from engineering leadership that closing PRs is acceptable. Celebrate the first few closes publicly. Reframe the narrative: closing a PR with "tried it, doesn't work" is a win because it generated learning without burning review cycles. Track and share the time saved by not reviewing PRs that were closed early.
diff --git a/apps/web-roo-code/src/content/blog/provider-choice-matters-as-much-as-model-choice-on-openrouter.md b/apps/web-roo-code/src/content/blog/provider-choice-matters-as-much-as-model-choice-on-openrouter.md
new file mode 100644
index 00000000000..54c0bc3cafa
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/provider-choice-matters-as-much-as-model-choice-on-openrouter.md
@@ -0,0 +1,126 @@
+---
+title: Provider Choice Matters as Much as Model Choice on OpenRouter
+slug: provider-choice-matters-as-much-as-model-choice-on-openrouter
+description: Why the same LLM model produces different results depending on OpenRouter provider, and how to debug model evals by testing provider and temperature combinations.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - openrouter
+    - model-evaluation
+    - llm-configuration
+    - byok
+status: draft
+publish_date: "2025-10-03"
+publish_time_pt: "9:00am"
+source: "After Hours"
+---
+
+Same model. Different provider. Completely different results.
+
+You ran the evals. The model scored poorly. You moved on.
+
+But the model was never the problem. The provider was.
+
+## The hidden variable
+
+You're evaluating models on OpenRouter. You pick one that looks promising, run it through your test suite, and get mediocre results. You check the box: tried it, didn't work, next.
+
+A week later, someone on your team mentions they're getting great results with the same model. You compare notes. Different provider. Different temperature setting.
+
+The model you dismissed was capable. The configuration you tested was not.
+
+OpenRouter aggregates multiple providers serving the same model. The assumption is that "Llama 3.1 70B" means the same thing regardless of who serves it. The reality: inference quality varies by provider. Quantization differences, context handling, and serving infrastructure all affect output.
+
+## The debugging checklist
+
+Before abandoning a model, ask two questions:
+
+1. Which provider did you use?
+2. What temperature did you set?
+
+Both parameters materially affect output quality. A model served by a random provider at default temperature may produce unusable output. The same model from a specific provider at a tuned temperature may score in the 90s on your evals.
+
+> "A lot of people will be like, 'Oh, I tried that model and it sucked.' I'm like, 'Well, what provider did you try? What temperature did you try?' And it's such a complicated space."
+>
+> GosuCoder, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=1487)
+
+The complexity is the point. Model selection is not a single variable. It's a configuration space with at least three dimensions: model, provider, and temperature. Evaluating one combination tells you nothing about the other combinations.
+
+## The GLM 4.6 case
+
+The Roo Code team ran evals on GLM 4.6 and got disappointing results. Standard reaction: mark the model as underperforming and move on.
+
+Instead, they adjusted provider and temperature. The results shifted dramatically.
+
+> "We ran the evals on it and they didn't do as well as we hoped. But then when I actually bumped the temperature and the provider, it really really changed how things worked. I think it got somewhere in the 90s."
+>
+> Dan, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=54)
+
+From "didn't do as well as we hoped" to "somewhere in the 90s." Same model. Different configuration.
+
+## The tradeoff
+
+This adds complexity to model evaluation. You can't just run one test and call it done. Each model potentially requires a configuration sweep: which providers are available, what temperature ranges work for your use case.
+
+The upside: you may find capable models that others have dismissed. The models everyone else gave up on after one bad run become your edge.
+
+The cost: your eval pipeline needs to account for provider and temperature as variables, not just model name. If you're logging model performance, log the full configuration. Otherwise you're comparing apples to oranges and drawing conclusions from noise.
+
+## Why this matters for your workflow
+
+If you're evaluating models for a production workflow, one bad eval run with a random provider tells you almost nothing. You've tested a single point in a multi-dimensional space.
+
+The debugging habit: when a model underperforms, check provider and temperature before writing it off. If you're using OpenRouter, the provider dropdown is not a cosmetic choice. It's a material parameter.
+
+For teams running systematic evals, this means expanding the test matrix. Model × provider × temperature. More runs, but fewer false negatives. You stop dismissing capable models based on misconfigured tests.
+
+> "You do have to be careful with providers on OpenRouter. So if you try it and you select just whatever random provider and it's not good, don't give up because some of them are unfortunately worse quality than others."
+>
+> GosuCoder, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=1474)
+
+## The first step
+
+Log the full configuration for every eval run: model name, provider, temperature, and any other inference parameters that might vary.
+
+When a model disappoints, check the configuration before the conclusion. The model you're about to dismiss might be the one that scores in the 90s with a different provider.
+
+## How Roo Code handles model configuration with BYOK
+
+Roo Code's BYOK (Bring Your Own Key) approach gives you direct control over provider selection and model configuration. When you connect your OpenRouter API key, you choose which provider serves each model and set temperature values that match your coding tasks.
+
+This matters because Roo Code closes the loop: it proposes diffs, runs commands and tests, and iterates based on results. Each iteration sends prompts to your configured model. **If your model configuration is suboptimal, every loop iteration compounds the quality loss.** Getting provider and temperature right at the start means better diffs, fewer failed test runs, and faster task completion.
+
+With BYOK, you pay the provider directly at their rates with no token markup. You also control the full configuration space, so you can tune provider and temperature for coding-specific tasks rather than accepting defaults optimized for general chat.
+
+## Model evaluation approaches compared
+
+| Dimension             | Single-point testing              | Configuration sweep testing                 |
+| --------------------- | --------------------------------- | ------------------------------------------- |
+| Test scope            | One provider, default temperature | Multiple providers × temperature ranges     |
+| False negative rate   | High - dismisses capable models   | Low - surfaces hidden performance           |
+| Time investment       | Minutes per model                 | Hours per model                             |
+| Configuration logging | Model name only                   | Model + provider + temperature + parameters |
+| Result reliability    | Noisy, non-reproducible           | Reproducible, comparable                    |
+
+## Frequently asked questions
+
+### Why do different OpenRouter providers give different results for the same model?
+
+Providers differ in how they serve models. Quantization levels affect precision, context window handling varies by infrastructure, and serving optimizations introduce subtle differences. A model quantized to 4-bit for cost savings produces different output than the same model at full precision. These differences compound across multi-turn conversations and complex reasoning tasks.
+
+### What temperature should I use for coding tasks?
+
+Lower temperatures (0.0 to 0.3) generally produce more deterministic, focused code output. Higher temperatures (0.7 to 1.0) increase creativity but also increase the likelihood of syntax errors and hallucinations. Start low for implementation tasks and test higher values for brainstorming or alternative solution generation.
+
+### How does Roo Code let me control provider and temperature settings?
+
+Roo Code uses BYOK, meaning you connect your own API key from OpenRouter or another provider. You configure the model, provider, and temperature in your settings. Roo Code then uses your exact configuration for every task, so you maintain full control over inference quality and cost.
+
+### Should I re-evaluate models I previously dismissed?
+
+Yes, if you tested them with a single provider and default settings. A model that scored poorly with one configuration may score in the 90s with a different provider or adjusted temperature. Log your original test configuration, then run the same evals with alternative providers before making a final decision.
+
+### How do I track which configuration produced which results?
+
+Log the complete configuration for every eval run: model name, provider ID, temperature, top-p, max tokens, and any other parameters you set. Store results alongside this configuration data. When comparing models, filter by identical configurations to ensure valid comparisons.
diff --git a/apps/web-roo-code/src/content/blog/pull-requests-are-handoffs-now-not-merge-requests.md b/apps/web-roo-code/src/content/blog/pull-requests-are-handoffs-now-not-merge-requests.md
new file mode 100644
index 00000000000..dbd09f8b1ba
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/pull-requests-are-handoffs-now-not-merge-requests.md
@@ -0,0 +1,115 @@
+---
+title: Pull Requests Are Handoffs Now, Not Merge Requests
+slug: pull-requests-are-handoffs-now-not-merge-requests
+description: Agent-generated PRs serve as structured handoff artifacts that explain what changed and transfer context between modes - merging is optional, learning is the goal.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agentic-workflows
+    - pull-requests
+    - developer-productivity
+    - ai-coding-agents
+status: draft
+publish_date: "2025-11-14"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Close the PR.
+
+Not because it failed. Because it did its job.
+
+## The old instinct
+
+You've got 15 open PRs from agent runs. Your first instinct is to triage them like you always have: which ones are ready to merge, which ones need fixes, which ones are blocking the sprint.
+
+You spend an hour going through each one. You leave comments. You request changes. You push the agent to iterate on the same PR until it's "done."
+
+By the end of the day, you've merged three. The other twelve are still open, collecting comments, waiting for another round.
+
+This is the old workflow. PRs were precious. You worked at them until they merged or until you gave up.
+
+> "We used to like, okay, you got to fix this, gotta fix this and you work at it, work at it. Like now some of them you're going to look at and close half of those."
+>
+> JB Brown, [Roo Cast S01E17](https://www.youtube.com/watch?v=R4U89z9eGPg&t=3264)
+
+## The shift: PRs as explanation artifacts
+
+When agents generate PRs, the default assumption that a PR exists to be merged is already wrong. Many agent-generated PRs will be closed. That's not waste.
+
+Each closed PR shows you how the agent interpreted the task. It shows what files it touched, what approach it took, what it missed. That information shapes your next prompt or your next mode handoff.
+
+> "The default assumption that a PR is for merging is like wrong now."
+>
+> Hannes Rudolph, [Roo Cast S01E17](https://www.youtube.com/watch?v=R4U89z9eGPg&t=3365)
+
+The artifact matters more than the merge. The PR becomes a structured handoff: from one mode to another, or from agent to human. The diff explains what changed. The commit history shows the reasoning. The PR description (if written well) captures the intent.
+
+> "In order for the modes to transfer their work from one to another, it's got to go into Git. And the way to explain what changed is to create an MR, right? And it's really an explanation. It's a handoff process as opposed to a request to merge in some cases."
+>
+> JB Brown, [Roo Cast S01E17](https://www.youtube.com/watch?v=R4U89z9eGPg&t=3390)
+
+## Practical implications
+
+**1. Close PRs without guilt.** If the PR taught you something about the task, it worked. Close it and open a new one with that knowledge encoded.
+
+**2. Use PRs as checkpoints.** When handing off between modes (e.g., Architect to Code, or Code to Review), commit the work and open a PR. The PR becomes the record of what the previous mode produced.
+
+**3. Signal intent with labels or emoji.** Some teams introduce an "explore" label or an ignore emoji to signal that a PR is exploration, not production-bound. This prevents reviewers from treating every PR as a merge candidate.
+
+**4. Expect volume.** If you're running agents on tasks, you'll generate more PRs than you used to. The merge rate will be lower, but the signal-per-PR stays high.
+
+## The tradeoff
+
+This workflow creates noise if you're not ready for it. Your PR list gets longer. Your notification count goes up. If you treat every PR as something that needs to be "resolved," you'll burn out fast.
+
+The fix is mental, not tooling: stop measuring success by merge rate. Measure by how much information each PR gives you about the task.
+
+## How Roo Code closes the loop on PR-based handoffs
+
+Roo Code treats PRs as first-class handoff artifacts between specialized modes. When Architect mode designs a solution, it commits the plan and opens a PR. Code mode picks up that PR, implements the changes, and opens another PR for Review mode to inspect. Each PR captures the reasoning and output of one mode before the next mode takes over.
+
+Because Roo Code uses BYOK (bring your own key), you control the token spend at each stage. You can run exploratory PRs cheaply, learn from the diffs, and close them without worrying about wasted platform costs. The agent closes the loop by running tests and iterating on failures, so the PRs you do keep tend to be higher quality.
+
+**Citable insight:** In agentic workflows, a PR's value comes from the context it transfers between modes, not from whether it merges.
+
+## Traditional PRs vs. agent-generated PRs
+
+| Dimension        | Traditional PRs       | Agent-generated PRs                         |
+| ---------------- | --------------------- | ------------------------------------------- |
+| Primary purpose  | Request to merge code | Handoff artifact that explains what changed |
+| Success metric   | Merge rate            | Information gained per PR                   |
+| Expected outcome | Most PRs merge        | Many PRs close after transferring context   |
+| Review approach  | Polish until ready    | Extract learnings, then close or merge      |
+| Volume           | Low, precious         | High, disposable                            |
+
+## Why this matters for your workflow
+
+If you're still treating agent-generated PRs like human-authored PRs, you're optimizing for the wrong thing. You're spending time polishing PRs that were never meant to ship.
+
+The shift is small but real: a PR is a handoff artifact, not a merge request. It explains what changed. It transfers context. Sometimes it merges. Sometimes it closes. Both outcomes are valid.
+
+Start by labeling one PR as "explore." See how it changes the way you review it.
+
+## Frequently asked questions
+
+### Why would I close a PR that the agent created?
+
+Agent-generated PRs often represent one approach to a problem, not the final solution. Closing a PR after reviewing it means you extracted the learnings - which files mattered, what the agent missed, what approach to try next. That information feeds your next prompt. A closed PR that taught you something is more valuable than an open PR collecting stale comments.
+
+### How do I prevent my PR list from becoming overwhelming?
+
+Use labels or naming conventions to distinguish exploration PRs from production-bound PRs. Many teams add an "explore" label or prefix to signal that a PR exists for learning, not merging. This trains reviewers to skim for insights rather than line-by-line approval. Archive or close exploration PRs within 24-48 hours to keep the list manageable.
+
+### Does Roo Code support this handoff workflow between modes?
+
+Yes. Roo Code's mode system is designed for structured handoffs. Architect mode can commit a design, Code mode implements it, and Review mode inspects the result. Each transition naturally produces a PR that captures what the previous mode accomplished. Because Roo Code closes the loop by running commands and tests, the PRs contain working code, not just proposals.
+
+### What if my team measures productivity by merge rate?
+
+Merge rate made sense when PRs were scarce and each one represented days of human effort. With agents generating PRs in minutes, merge rate becomes misleading. Consider tracking "insights per PR" or "tasks completed" instead. A team that closes 80% of its PRs but ships features faster is outperforming a team with a 95% merge rate and a backlog of stale branches.
+
+### How do I know when a PR should merge vs. close?
+
+If the PR solves the task and passes tests, merge it. If the PR revealed a better approach, close it and open a new PR that incorporates what you learned. The decision takes seconds once you stop treating every PR as precious. Ask: "Did this PR move the task forward?" If yes, it succeeded - regardless of whether it merges.
diff --git a/apps/web-roo-code/src/content/blog/put-framework-examples-in-your-context-window-before-asking-for-code.md b/apps/web-roo-code/src/content/blog/put-framework-examples-in-your-context-window-before-asking-for-code.md
new file mode 100644
index 00000000000..cfe88fd7237
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/put-framework-examples-in-your-context-window-before-asking-for-code.md
@@ -0,0 +1,142 @@
+---
+title: Put Framework Examples in Your Context Window Before Asking for Code
+slug: put-framework-examples-in-your-context-window-before-asking-for-code
+description: Learn why AI coding assistants default to popular frameworks and how providing concrete code examples in your context window steers output toward your actual stack.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - prompt-engineering
+    - context-window
+    - frameworks
+    - ai-coding
+status: draft
+publish_date: "2025-04-22"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+You ask for Next.js.
+
+You get Create React App.
+
+Every. Single. Time.
+
+## The default trap
+
+You're building a Next.js app with the app router. You've been explicit about it in your prompts. "Next.js 14, app router, server components." The model nods, generates code, and hands you a Create React App scaffold with client-side routing.
+
+You try again. You add "NOT Create React App." You add "I repeat: Next.js." You're now three prompts deep, manually rewriting the generated code to match your actual stack.
+
+The model isn't broken. It's defaulting to its training distribution. And its training distribution has a lot of Create React App.
+
+## The fix is in the context window
+
+You have two options here. One is expensive: fine-tune the model to reliably produce your framework of choice.
+
+The other is free: show it what you want.
+
+> "Don't underestimate the value of just putting things into the context window and showing the model examples."
+>
+> Paige Bailey, [Office Hours S01E03](https://www.youtube.com/watch?v=rqMSBUSJos8&t=1612)
+
+Before you ask for code, paste two examples of the kind of app you're building. Not documentation links. Actual code. The file structure you expect. The patterns you follow. The imports that signal your framework.
+
+The prompt becomes something like:
+
+Hey, here are two examples of the kinds of apps
+that I'm trying to build.
+
+[paste example 1]
+[paste example 2]
+
+Now please generate an app that does this particular task.
+
+Models are pattern-matchers. If the pattern is in the context, the output follows. If the pattern isn't there, the model falls back to whatever showed up most often in its training data.
+
+## Why this works
+
+Context windows are large now. Gemini, Claude, GPT-4: all of them can hold substantial code samples alongside your request. The constraint isn't capacity; it's whether you're using that capacity to steer or just to ask.
+
+Most prompts are "here's what I want, go." The model guesses based on keywords. If "React" is in your prompt, it picks the most common React pattern it knows.
+
+When you include examples, you're not asking the model to guess. You're showing it the answer format before the question. The model completes the pattern rather than inventing one.
+
+This works for:
+
+- Framework-specific code (Next.js vs. Create React App vs. Remix)
+- Coding style (your team's conventions vs. generic tutorials)
+- File organization (monorepo structure, naming conventions)
+- API patterns (REST vs. GraphQL, specific libraries)
+
+## The tradeoff
+
+You're spending context tokens on examples before you even ask your question. If you're running a tight budget, those tokens add up.
+
+The math: tokens upfront vs. iterations later.
+
+For straightforward requests where the framework is unambiguous, skip the examples. For anything where you've been fighting the model's defaults, the upfront tokens usually cost less than three failed prompts and the time spent rewriting output.
+
+> "If you want it to be able to reliably generate other kinds of web applications, something that is more Next.js specific or another framework, then you might need to fine-tune it to be excellent at producing that kind of code."
+>
+> Paige Bailey, [Office Hours S01E03](https://www.youtube.com/watch?v=rqMSBUSJos8&t=1568)
+
+Fine-tuning is the heavy solution. Context window steering is the lightweight one. For most individual developers and small teams, lightweight wins.
+
+## Why this matters for your workflow
+
+If you're shipping production code and the model keeps generating the wrong framework, you're spending time on translation instead of building. Every "fix the imports" and "restructure this to app router" is friction that should have been avoided.
+
+For an engineer building three features this week, that friction compounds. The model generates, you rewrite, you prompt again, it drifts, you rewrite again.
+
+Dropping two examples into context before asking eliminates the guessing. The model sees the pattern, matches it, and stays in your stack.
+
+## The rule
+
+If your generated code keeps coming out in the wrong framework, stop adding negative constraints. Stop writing "NOT Create React App."
+
+Show the model what you want. Paste two examples. Let the context window do the steering.
+
+The model follows patterns. Give it one.
+
+## How Roo Code closes the loop with context-aware generation
+
+Roo Code is an AI coding agent that closes the loop - it can propose diffs, run commands and tests, and iterate based on the results. This agentic workflow changes how context steering plays out in practice.
+
+When you configure Roo Code with custom instructions and workspace context, you're not manually pasting examples into every prompt. The agent maintains awareness of your project structure, your existing code patterns, and your framework choices. It reads your actual files before generating new ones.
+
+**The key advantage:** Roo Code operates with BYOK (bring your own key), meaning you spend tokens intentionally for outcomes rather than paying for guesswork. When the agent can see your `app/` directory with Next.js app router conventions, it doesn't hallucinate Create React App patterns. It matches what's already there.
+
+This is context window steering automated at the workflow level - the agent inspects, generates, runs tests, and iterates until the output fits your stack.
+
+## Context steering approaches compared
+
+| Dimension          | Manual prompting         | Example pasting                    | Agentic workflow (Roo Code)       |
+| ------------------ | ------------------------ | ---------------------------------- | --------------------------------- |
+| Context accuracy   | Low - relies on keywords | Medium - requires manual selection | High - reads actual project files |
+| Token efficiency   | Wasted on iteration      | Upfront cost for examples          | Intentional spend with BYOK       |
+| Framework drift    | Common across prompts    | Reduced within session             | Minimal - agent maintains context |
+| Iteration handling | Manual rewrite cycle     | Fewer iterations needed            | Automated run-test-iterate loop   |
+| Setup effort       | None                     | Moderate - curating examples       | One-time configuration            |
+
+## Frequently asked questions
+
+### Why does the AI keep generating the wrong framework even when I specify it?
+
+Large language models default to their training distribution. If Create React App appears more frequently in training data than Next.js app router patterns, the model gravitates toward the common case unless you provide stronger signals. Keywords alone often aren't enough to override statistical defaults.
+
+### How many example files should I include in my context window?
+
+Two well-chosen examples typically suffice. Pick files that demonstrate your framework's distinctive patterns - the imports, file structure, and conventions that differentiate it from alternatives. More examples help for complex or unusual setups, but diminishing returns set in quickly.
+
+### Does this approach work for languages and frameworks beyond React?
+
+Yes. Context window steering works for any domain where the model might default to a more common pattern: Python web frameworks (Django vs. FastAPI), CSS approaches (Tailwind vs. vanilla), testing libraries, API styles, and language-specific idioms. The principle is universal.
+
+### How does Roo Code handle framework context differently than chat-based tools?
+
+Roo Code operates as an agentic coding assistant that reads your workspace files directly, maintaining awareness of your project's actual structure and patterns. Instead of requiring you to paste examples into each prompt, the agent inspects your codebase, generates code that matches existing conventions, runs tests to verify correctness, and iterates based on results. This closes the loop automatically rather than requiring manual correction cycles.
+
+### When should I skip example pasting and just prompt directly?
+
+Skip examples when your request is unambiguous and framework-agnostic, when the model has consistently produced correct output for similar requests, or when you're prototyping and don't care about matching production conventions. For anything touching your real codebase where framework accuracy matters, the upfront token cost of examples pays for itself.
diff --git a/apps/web-roo-code/src/content/blog/quantization-degrades-quality-over-long-agent-loops.md b/apps/web-roo-code/src/content/blog/quantization-degrades-quality-over-long-agent-loops.md
new file mode 100644
index 00000000000..9265ae8a487
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/quantization-degrades-quality-over-long-agent-loops.md
@@ -0,0 +1,123 @@
+---
+title: Quantization Degrades Quality Over Long Agent Loops
+slug: quantization-degrades-quality-over-long-agent-loops
+description: Why quantized models underperform on long-running agent tasks and how to identify when precision loss is compounding in your workflow.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - model-quantization
+    - agent-loops
+    - inference-quality
+    - ai-coding-agents
+status: draft
+publish_date: "2025-08-06"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The benchmark says the model works.
+
+Your 200-call agent loop says otherwise.
+
+## The gap between benchmarks and production
+
+You're running an open-source model through a fast inference provider. The benchmarks look good. The latency is excellent. You spin up an agent task that needs to iterate: read files, propose changes, run tests, incorporate results, repeat.
+
+Somewhere around tool call 150, the outputs start drifting. The model's suggestions get less coherent. It references things that aren't in the context anymore. You check the docs, check the prompt, check your settings. Nothing obvious is wrong.
+
+Here's what the benchmarks didn't tell you: most published evals measure single-shot tasks or short agent loops. A code completion here, a unit test there. But your actual workflows run hundreds of tool calls deep. And at that depth, small quality losses compound.
+
+## What quantization actually costs
+
+Fast inference providers achieve their speed through quantization: reducing the precision of model weights to run on cheaper hardware. This is a legitimate engineering tradeoff. Lower precision means lower memory footprint, which means higher throughput, which means lower latency and cost per token.
+
+The problem is that the quality loss isn't zero. And on long-running tasks, it compounds.
+
+> "Quantization, no matter what anybody says, degrades the quality of the output of the model. And with long-running agent loops, it's a compounding effect."
+>
+> Adam, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=3287)
+
+One tester ran the same model, same eval suite, through two different endpoints: a fast quantized provider and the original Alibaba endpoint for Qwen 3 Coder. The difference was measurable.
+
+> "If you use the Alibaba endpoint directly with Qwen 3 Coder, with my evals in particular, they score about 8% higher."
+>
+> Adam, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=3213)
+
+8% sounds small. On a single prompt, you might not notice. Over a 200-call agent loop where each step builds on the last, that 8% compounds. A slightly wrong file reference in step 30 leads to a completely wrong approach by step 100.
+
+## Why standard benchmarks miss this
+
+The benchmarks aren't lying. They're just measuring short tasks.
+
+> "A lot of the tests are running, if you dig into it, are very short-run agent loops or even a single like code test. But the things that I test are much longer running, you know, hundreds of tool calls that go out."
+>
+> Adam, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=3305)
+
+If your use case is "generate a function, run a test, done," quantized inference is probably fine. The quality loss doesn't have time to compound. But if your use case involves multi-step reasoning, file exploration, iterative debugging, or any workflow where the model's output at step N becomes the context for step N+1, you're running a different experiment than the benchmark measured.
+
+## The tradeoff in practice
+
+This isn't "never use quantized models." The tradeoff is real and sometimes worth it.
+
+**When quantized inference works well:**
+
+- Single-shot code generation
+- Quick refactors with immediate feedback
+- Tasks where you'll verify the output manually anyway
+- High-volume, low-stakes automation
+
+**When you pay the compounding tax:**
+
+- Multi-file refactors that require consistent understanding
+- Debugging sessions that iterate until tests pass
+- Autonomous agent loops with minimal human checkpoints
+- Any task where you're trusting step 150 based on what happened in step 30
+
+The speed gain is real: often 10x or more. The question is whether your task is short enough that the quality loss stays negligible.
+
+## Quantized vs. full-precision inference for agent workflows
+
+| Dimension                  | Quantized inference      | Full-precision inference |
+| -------------------------- | ------------------------ | ------------------------ |
+| Latency                    | Lower (often 10x faster) | Higher                   |
+| Cost per token             | Lower                    | Higher                   |
+| Single-shot accuracy       | Nearly equivalent        | Baseline                 |
+| Quality at 50+ tool calls  | Degradation visible      | Stable                   |
+| Quality at 150+ tool calls | Significant drift        | Maintains coherence      |
+
+## How Roo Code handles model selection for long loops
+
+Roo Code uses BYOK (Bring Your Own Key) architecture, which means you connect directly to the model provider of your choice. This design lets you switch endpoints mid-workflow without changing your agent configuration.
+
+When Roo Code closes the loop on a complex task, running tests, incorporating failures, and iterating automatically, each tool call builds on the previous context. For workflows exceeding 100 tool calls, routing to a full-precision endpoint preserves the coherence that quantized providers sacrifice for speed.
+
+**The practical pattern:** Use fast quantized providers for exploratory tasks with human checkpoints. Switch to original model endpoints when Roo Code runs autonomous loops where step 150 depends on step 30.
+
+## What to try
+
+If you're seeing unexplained degradation on long agent loops, run one test: take the same task, same prompt structure, and run it through the original model endpoint instead of the fast provider. If the output quality holds steady at depth, you've found the variable.
+
+The benchmark didn't lie. It just measured a different workload than yours.
+
+## Frequently asked questions
+
+### Why do quantized models perform well on benchmarks but poorly on my agent tasks?
+
+Most benchmarks measure single-shot completions or short agent loops with fewer than 20 tool calls. These tasks don't give precision loss enough iterations to compound. Your production workflows running 100+ tool calls expose degradation that benchmark conditions never test.
+
+### How much quality loss should I expect from quantization?
+
+Testing shows approximately 8% lower scores when comparing quantized endpoints to original model endpoints on the same eval suite. On single prompts this is often imperceptible. Over long agent loops, this loss compounds as each step's slight errors become context for subsequent steps.
+
+### Can Roo Code help me avoid quantization-related degradation?
+
+Yes. Because Roo Code uses BYOK, you can configure different model endpoints for different task types. Route short exploratory tasks through fast quantized providers and switch to full-precision endpoints for autonomous loops where Roo Code closes the loop across many tool calls.
+
+### When should I accept the quantization tradeoff?
+
+Accept it when speed matters more than deep coherence: single-shot generation, quick refactors with manual verification, and high-volume automation where you'll review outputs anyway. Avoid it for multi-file refactors, iterative debugging, and any task where you trust the agent to maintain context across 50+ steps.
+
+### How do I test whether quantization is causing my agent's degradation?
+
+Run the same task with identical prompts through both the quantized provider and the original model endpoint. If output quality holds steady at depth with the original endpoint but drifts with the quantized version, quantization is the variable.
diff --git a/apps/web-roo-code/src/content/blog/qwen3-coder-works-but-only-with-the-right-settings.md b/apps/web-roo-code/src/content/blog/qwen3-coder-works-but-only-with-the-right-settings.md
new file mode 100644
index 00000000000..f27649fca24
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/qwen3-coder-works-but-only-with-the-right-settings.md
@@ -0,0 +1,129 @@
+---
+title: Qwen3 Coder Works, But Only with the Right Settings
+slug: qwen3-coder-works-but-only-with-the-right-settings
+description: Learn the three critical configuration settings that make Qwen3 Coder perform like Sonnet - temperature, provider selection, and avoiding quantized versions.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - model-configuration
+    - qwen3
+    - cost-optimization
+    - byok
+status: draft
+publish_date: "2025-07-30"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+```json
+"temperature": 0.7,
+"provider": "alibaba"
+
+That is not a style preference.
+
+That is the difference between "works" and "spirals into irrelevant changes."
+
+## The configuration gap
+
+You try Qwen3 Coder because someone said it performs like Sonnet at half the cost. You pick it from the model dropdown, run a task, and watch it produce garbage. You conclude the model is overhyped and move on.
+
+Except you were running a quantized version through a random OpenRouter endpoint with default temperature settings.
+
+The model works. Your configuration didn't.
+
+## The three settings that matter
+
+Most complaints about Qwen3 Coder trace back to skipping the setup steps.
+
+> "There's been a few people that have complained about Qwen3 Coder, and every time I ask them it's because they haven't selected the provider; they're on a quantized version or they don't have temperature set correctly."
+>
+> Hannes Rudolph, [Roo Cast S01E03](https://www.youtube.com/watch?v=c8Z08kEP02c&t=493)
+
+The fix is specific:
+
+**1. Set temperature to 0.7.** Default temperature settings produce worse results with this model. The 0.7 setting is not arbitrary; it's what makes the output usable for code generation.
+
+**2. Select Alibaba as the provider.** Not OpenRouter. Not a third-party endpoint. Alibaba directly.
+
+> "Set your temperature and set your provider to Alibaba."
+>
+> Adam, [Roo Cast S01E03](https://www.youtube.com/watch?v=c8Z08kEP02c&t=132)
+
+**3. Avoid quantized versions.** This is where most people get burned. OpenRouter and similar aggregators often serve quantized models to save on inference costs. Quantized Qwen3 Coder produces noticeably worse results.
+
+> "Be very picky about your provider because if you get a provider from OpenRouter that's got it quantized down, you'll get poor results."
+>
+> Adam, [Roo Cast S01E03](https://www.youtube.com/watch?v=c8Z08kEP02c&t=113)
+
+## The tradeoffs
+
+Qwen3 Coder is not a drop-in replacement for Sonnet. The cost advantage comes with constraints.
+
+**No vision capabilities.** If your workflow involves screenshots, diagrams, or UI mockups, Qwen3 Coder cannot process them. You'll need to fall back to a vision-capable model for those tasks.
+
+**No prompt caching on some providers.** This is where the "half the cost" claim gets complicated. Without prompt caching, costs climb on long sessions. A task that stays cheap with a cached context window becomes expensive when you're paying for the full context every turn.
+
+> "The price can actually get up there due to lack of prompt caching on some of the providers, and then no vision capabilities, but otherwise very, very optimistic."
+>
+> Adam, [Roo Cast S01E03](https://www.youtube.com/watch?v=c8Z08kEP02c&t=59)
+
+For backend work with short-to-medium context, the savings hold. For long-running refactors or sessions that require image input, the math changes.
+
+## Why this matters for your workflow
+
+The difference between "Qwen3 Coder doesn't work" and "Qwen3 Coder works like Sonnet" is three settings. If you've dismissed the model based on a bad first experience, revisit the configuration before writing it off.
+
+For engineers evaluating model options: the provider and quantization matter as much as the model name. A full-precision model through the right endpoint will outperform a quantized version of a more expensive model through the wrong one.
+
+The configuration checklist:
+
+1. Temperature: 0.7
+2. Provider: Alibaba (not OpenRouter, not aggregators)
+3. Quantization: avoid it
+
+If those three are set correctly and it still doesn't work for your use case, then the model isn't the right fit. But most complaints never get that far.
+
+## How Roo Code enables model flexibility with BYOK
+
+Roo Code's BYOK (Bring Your Own Key) architecture gives you direct control over model selection and provider configuration. Unlike tools that lock you into specific providers or mark up token costs, Roo Code lets you connect directly to Alibaba, Anthropic, OpenAI, or any OpenAI-compatible endpoint.
+
+This matters for Qwen3 Coder because provider selection is not optional - it determines whether the model works at all. With BYOK, you configure your Alibaba API key once and get full-precision inference without middleman quantization.
+
+**Roo Code closes the loop on model configuration: you select the provider, set the temperature, and the agent runs tasks using exactly the inference setup you specified.**
+
+When a task fails, you know whether it's model capability or configuration. When it succeeds, the cost savings go directly to you, not to token markup.
+
+## Default configuration vs. optimized Qwen3 setup
+
+| Dimension | Default/Aggregator Setup | Optimized Qwen3 Configuration |
+|-----------|-------------------------|------------------------------|
+| Temperature | Provider default (often 1.0) | 0.7 (tested for code generation) |
+| Provider | OpenRouter or random endpoint | Alibaba direct |
+| Model precision | Often quantized to reduce costs | Full precision |
+| Prompt caching | Inconsistent availability | Provider-dependent, verify before use |
+| Vision support | Assumed available | Not supported - plan fallback |
+
+## Frequently asked questions
+
+### Why does temperature 0.7 work better for Qwen3 Coder?
+
+The 0.7 temperature setting balances creativity with consistency for code generation tasks. Higher temperatures cause Qwen3 Coder to introduce unnecessary variations and unrelated changes. This specific value has been tested by the community and consistently produces better results than defaults.
+
+### Can I use Qwen3 Coder through OpenRouter?
+
+You can, but results will likely be worse. OpenRouter and similar aggregators often serve quantized versions of models to reduce their inference costs. For Qwen3 Coder specifically, the quantization significantly degrades output quality. Connect directly to Alibaba for full-precision inference.
+
+### How do I configure Qwen3 Coder in Roo Code?
+
+In Roo Code, add your Alibaba API key through the BYOK settings, select Qwen3 Coder as your model, and set the temperature to 0.7 in your model configuration. Roo Code connects directly to your specified provider without token markup or forced routing through aggregators.
+
+### Is Qwen3 Coder actually cheaper than Claude Sonnet?
+
+For backend code generation with short-to-medium context windows, yes. However, two factors can erode savings: lack of prompt caching on long sessions (you pay for the full context each turn) and needing to fall back to vision-capable models for UI work. Calculate based on your actual task patterns.
+
+### What tasks should I avoid using Qwen3 Coder for?
+
+Avoid tasks requiring image input (screenshots, diagrams, UI mockups) since Qwen3 Coder has no vision capabilities. Also consider alternatives for very long sessions where lack of prompt caching makes costs unpredictable. For these cases, keep a vision-capable model configured as a fallback in your Roo Code setup.
+
+```
diff --git a/apps/web-roo-code/src/content/blog/run-parallel-agent-tasks-to-reduce-waiting-and-speed-up-context-building.md b/apps/web-roo-code/src/content/blog/run-parallel-agent-tasks-to-reduce-waiting-and-speed-up-context-building.md
new file mode 100644
index 00000000000..ecdc65e441d
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/run-parallel-agent-tasks-to-reduce-waiting-and-speed-up-context-building.md
@@ -0,0 +1,126 @@
+---
+title: Run Parallel Agent Tasks to Reduce Waiting and Speed Up Context Building
+slug: run-parallel-agent-tasks-to-reduce-waiting-and-speed-up-context-building
+description: Learn how power users run multiple AI coding agent tasks in parallel to build context faster and eliminate the single-task bottleneck that slows down development.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - productivity
+    - workflows
+    - context-building
+    - cli
+status: draft
+publish_date: "2025-08-27"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Three terminals. Three tasks. One codebase.
+
+While one agent maps the architecture, another digs into the auth module, and a third drafts the actual change.
+
+## The single-task bottleneck
+
+You open Roo Code. You start a task. You wait.
+
+The model is thinking. The context is building. You're watching a progress indicator instead of shipping code.
+
+This is how most developers use AI coding agents: one task at a time, sequential, waiting for each step to complete before starting the next. It feels natural because that's how we've always worked with tools. But it's also the slowest possible way to use something that can run independently.
+
+The bottleneck isn't the model. It's the assumption that you need to wait.
+
+## The parallel pattern
+
+Power users treat agent tasks like background jobs. Instead of running one task and watching it complete, they run multiple lightweight tasks in parallel: one for fact-finding, one for architecture analysis, one for the actual code change.
+
+> "I'll have Roo Code on the left. I'll have like a couple terminal tools in the middle. And I'm actually working in the codebase in multiple parts at the same time. And CLIs allow you to run multiple tasks."
+>
+> Adam, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=2482)
+
+The key insight: not all tasks need the same speed. Exploratory work, where you're building context and understanding the codebase, can run in the background. Active coding, where you want tight feedback loops, stays in focus.
+
+## Separating exploration from execution
+
+Think of it as two categories:
+
+**Exploratory tasks:** "How is this module structured?" "What calls this function?" "Where does this config come from?" These are fact-finding missions. Speed matters less because you're not blocked on the answer. You can let them run while you do something else.
+
+> "One of them might simply be a fact-finding mission, right? Like go find out how something's put together so I can start thinking about how I need to change it. Basically your ask mode, right?"
+>
+> Adam, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=2493)
+
+**Execution tasks:** "Write this migration." "Fix this test." "Refactor this function." These need your attention when they complete because you'll review the diff and iterate. Keep these in your primary focus.
+
+The workflow: kick off 2-3 exploratory tasks, then work on something else. When they complete, you have context you didn't have to build manually. The slower model isn't an obstacle; it's permission to multitask.
+
+## The setup
+
+This works best with CLI-based agents or multiple terminal instances. The pattern:
+
+1. Open multiple terminals or use a multiplexer
+2. Start exploratory tasks in background panes
+3. Keep your primary coding window in focus
+4. Check results when tasks complete
+
+> "When you're locked into like a single experience, you don't really want to be. You want to be able to open up any number of windows and do a bunch of different things without having to open new IDEs for each one of them."
+>
+> Adam, [Roo Cast S01E06](https://www.youtube.com/watch?v=PZgkQtTRtUw&t=2793)
+
+The tradeoff: more context switching, more terminal management. If you're deep in a single problem and don't need background context, sequential is fine. But if you're starting a new feature or onboarding to an unfamiliar codebase, parallel exploration compounds.
+
+## Why this matters for your team
+
+For a team of 5-8 engineers working across a shared codebase, context-building is a constant tax. Every developer spends time understanding code they didn't write. Every feature starts with "how does this part work?"
+
+Running parallel exploratory tasks means that context arrives while you're doing something else. Instead of blocking on "let me understand the auth module before I can estimate this ticket," you kick off the exploration, move to another task, and come back with answers.
+
+For a team shipping daily, even 30 minutes saved per developer per day on context-building compounds to 10-15 hours per week. That's time that goes into actual shipping instead of waiting.
+
+## How Roo Code enables parallel context building
+
+Roo Code closes the loop by running tasks autonomously - proposing changes, executing commands, and iterating based on results - without requiring you to watch every step. This autonomous execution is what makes parallel workflows possible.
+
+With BYOK (bring your own key), you control your API spend directly, which means running multiple exploratory tasks in parallel has predictable costs. You're not paying a markup on tokens; you're paying your provider's rates for the actual work being done.
+
+**The citable insight:** Parallel agent tasks transform model latency from a bottleneck into a parallel processing window, letting developers build context in the background while focusing on high-value execution work.
+
+## Sequential vs. parallel agent workflows
+
+| Dimension        | Sequential workflow                | Parallel workflow                              |
+| ---------------- | ---------------------------------- | ---------------------------------------------- |
+| Context building | Blocked until each task completes  | Runs in background while you work              |
+| Model latency    | Feels like wasted time             | Becomes useful parallel processing time        |
+| Terminal usage   | Single window, single task         | Multiple terminals or multiplexer              |
+| Best for         | Deep single-problem focus          | Onboarding, new features, unfamiliar codebases |
+| Team impact      | Each developer waits independently | Context arrives while doing other work         |
+
+## The shift
+
+Stop treating the agent as something you watch. Start treating it as something you dispatch.
+
+Kick off the exploratory task. Move to something else. Come back when it's done.
+
+The model's latency becomes your parallel processing window.
+
+## Frequently asked questions
+
+### How many parallel tasks can I run effectively?
+
+Most developers find 2-3 parallel tasks manageable without losing track of results. Start with one exploratory task running in the background while you focus on execution work, then add more as you get comfortable with the workflow.
+
+### Does running parallel tasks increase my API costs?
+
+With BYOK, you pay your provider's token rates directly without markup. Parallel tasks do consume more tokens simultaneously, but the time savings often justify the cost - especially for context-building work that would otherwise block your progress.
+
+### What types of tasks work best for background exploration?
+
+Questions about code structure work well: "How is authentication implemented?" "What calls this function?" "Where is this config value set?" These fact-finding tasks don't require immediate attention and can run while you focus on writing code.
+
+### Can I run parallel tasks with Roo Code's VS Code extension?
+
+Yes. You can open multiple VS Code windows or use the CLI alongside the extension. The CLI is particularly well-suited for parallel workflows since you can run multiple instances in separate terminal panes or a terminal multiplexer like tmux.
+
+### When should I stick with sequential single-task workflows?
+
+If you're deep in a single problem with tight iteration cycles - debugging a specific issue or refining a particular function - sequential focus makes sense. Parallel workflows shine when you need to build context across multiple areas of a codebase simultaneously.
diff --git a/apps/web-roo-code/src/content/blog/run-your-documentation-mcp-through-an-orchestrator-not-your-main-coding-mode.md b/apps/web-roo-code/src/content/blog/run-your-documentation-mcp-through-an-orchestrator-not-your-main-coding-mode.md
new file mode 100644
index 00000000000..2a910f1238d
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/run-your-documentation-mcp-through-an-orchestrator-not-your-main-coding-mode.md
@@ -0,0 +1,118 @@
+---
+title: Run Your Documentation MCP Through an Orchestrator, Not Your Main Coding Mode
+slug: run-your-documentation-mcp-through-an-orchestrator-not-your-main-coding-mode
+description: Learn why running documentation MCPs in a dedicated researcher mode prevents context pollution and keeps your expensive coding model focused on implementation.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - mcp
+    - orchestrator
+    - context-management
+    - workflow
+status: draft
+publish_date: "2025-06-18"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Your coding model does not need to know how to query Next.js docs.
+
+It needs to know the answer.
+
+## The context pollution problem
+
+You've set up Context7 or a similar documentation MCP. It's connected. It works. You ask your coding agent about a React hook, and it dutifully calls the MCP, pulls documentation, and gives you an answer.
+
+Then you ask it to implement the feature. The context window now contains the full MCP conversation: the query, the API response, the parsed documentation, the summary. Your coding model is now reasoning about implementation with half its context consumed by reference material it already distilled into a one-paragraph answer.
+
+This is context pollution. The documentation lookup was useful once. Now it's dead weight.
+
+## The separation pattern
+
+The pattern that works: don't run documentation MCPs in your main coding mode at all.
+
+> "You really don't want this to be part of your main coding mode. And I would say you really want your Context7 in an orchestrator type setup."
+>
+> Adam, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=631)
+
+Create a dedicated researcher mode. Give it a lightweight model. Let it handle the documentation lookup cycle: query the MCP, summarize the relevant parts, and pass the summary back to your orchestrator. Your expensive coding model never sees the raw API traffic.
+
+The orchestrator receives a clean artifact: "Here's what the Next.js docs say about server actions." The coding model receives context it can use, not context it has to wade through.
+
+## Model selection for the lookup layer
+
+The documentation lookup cycle does not require your most capable model. It needs to parse a query, call an MCP, and summarize what comes back.
+
+> "I was using Gemini 2.5 Flash for the MCP stuff because it can gather the basics of your request."
+>
+> Adam, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=672)
+
+Gemini 2.5 Flash, Claude 3.5 Haiku, or similar lightweight models handle this well. They're inexpensive per token, and the task is bounded: read docs, extract relevant section, summarize. No complex reasoning required.
+
+Your expensive model stays focused on the hard part: understanding your codebase and generating correct implementation.
+
+## Setting up the pattern
+
+The setup looks like this:
+
+1. Create a researcher mode in Roo Code with MCP access
+2. Assign a lightweight model (Flash, Haiku, or equivalent)
+3. Configure the orchestrator to delegate documentation queries to this mode
+4. The researcher returns summaries, not raw MCP output
+
+> "If you have a couple frameworks that you're using constantly, just go figure out like the context that you want in there and like how you want to query that."
+>
+> Adam, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=287)
+
+For frameworks you use constantly, pre-tune the query patterns. Know what context you need from the Next.js docs versus the Prisma docs. The researcher mode can be specialized per framework if the query patterns differ significantly.
+
+## The tradeoff
+
+This adds orchestration overhead. You're now managing mode delegation instead of running everything in one context. For quick questions, the round-trip through an orchestrator might feel slower than just asking your coding model directly.
+
+But for extended implementation sessions, the payoff compounds. Each documentation lookup stays isolated. The coding model's context stays clean. You're not paying Opus prices to parse API responses that a lighter model handles fine.
+
+## How Roo Code enables clean context separation
+
+Roo Code's orchestrator mode delegates subtasks to specialized modes, each with their own context window. This means documentation lookups in a researcher mode stay isolated from your main coding context. The orchestrator closes the loop by passing only the distilled summary to your coding model, not the raw MCP traffic.
+
+With BYOK (bring your own key), you control exactly which model handles each layer. Run Gemini Flash for documentation gathering at minimal cost while reserving Claude Opus or GPT-4 for complex implementation reasoning. You spend tokens intentionally for outcomes, matching model capability to task complexity.
+
+| Approach                  | Context usage                            | Model cost                               | Session coherence              |
+| ------------------------- | ---------------------------------------- | ---------------------------------------- | ------------------------------ |
+| MCP in main coding mode   | High - raw API responses consume context | High - expensive model processes lookups | Degrades as lookups accumulate |
+| MCP in orchestrator setup | Low - only summaries reach coding model  | Low - cheap model handles lookups        | Stable through long sessions   |
+| No documentation MCP      | Zero MCP overhead                        | Variable - manual lookup time            | Depends on developer memory    |
+
+## Why this matters for your workflow
+
+If you're spending tokens on a capable coding model, you're paying for reasoning capacity. Every token of context consumed by MCP traffic is a token not available for understanding your implementation.
+
+The difference shows up in longer sessions. When you hit context limits partway through a refactor, and the model starts losing the thread of earlier changes, some of that limit was consumed by documentation lookups you could have delegated.
+
+The pattern is simple: separate the lookup layer from the reasoning layer. Let lightweight models gather context. Let capable models use it.
+
+Start by identifying which MCPs run in your main coding mode. Move them to a dedicated researcher mode behind an orchestrator. Track whether your coding sessions stay coherent longer.
+
+## Frequently asked questions
+
+### What is context pollution in AI coding agents?
+
+Context pollution occurs when reference material, API responses, or intermediate outputs accumulate in your model's context window without providing ongoing value. Documentation lookups are a common source: the raw MCP traffic was useful for generating an answer but becomes dead weight during implementation.
+
+### How do I set up a researcher mode in Roo Code for documentation lookups?
+
+Create a custom mode in Roo Code with access to your documentation MCPs (like Context7). Assign a lightweight model such as Gemini 2.5 Flash or Claude 3.5 Haiku. Configure your orchestrator to delegate documentation queries to this mode and receive summarized responses back.
+
+### Which models work best for the documentation lookup layer?
+
+Lightweight, cost-effective models handle documentation lookups well because the task is bounded: parse a query, call an MCP, extract relevant sections, and summarize. Gemini 2.5 Flash, Claude 3.5 Haiku, and similar models are good choices. Save your expensive reasoning models for implementation work.
+
+### Does orchestrator overhead slow down simple questions?
+
+Yes, for quick one-off questions the round-trip through an orchestrator adds latency compared to asking your coding model directly. The payoff comes in extended sessions where multiple documentation lookups would otherwise accumulate and degrade context quality.
+
+### Why do my coding sessions lose coherence after many documentation lookups?
+
+Each documentation lookup in your main coding mode consumes context window space. As lookups accumulate, less space remains for your codebase context and implementation reasoning. Moving lookups to a separate researcher mode keeps your coding model's context focused on the work that requires its full capability.
diff --git a/apps/web-roo-code/src/content/blog/running-multiple-agents-on-one-repo-is-harder-than-it-looks.md b/apps/web-roo-code/src/content/blog/running-multiple-agents-on-one-repo-is-harder-than-it-looks.md
new file mode 100644
index 00000000000..55b02df5757
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/running-multiple-agents-on-one-repo-is-harder-than-it-looks.md
@@ -0,0 +1,113 @@
+---
+title: Running Multiple Agents on One Repo Is Harder Than It Looks
+slug: running-multiple-agents-on-one-repo-is-harder-than-it-looks
+description: Why parallel AI coding agents create coordination problems beyond git, and how to manage shared resources like databases, migrations, and dev servers.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - multi-agent
+    - developer-workflow
+    - coordination
+    - agentic-coding
+status: draft
+publish_date: "2025-09-17"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Five IDEs. Three or four agents per IDE. One developer keeping track of all of them.
+
+That's not a productivity hack. That's a coordination job.
+
+## The illusion of parallelism
+
+You want to run multiple agents on the same codebase. One handles refactoring, another writes tests, a third tackles documentation. They should run in parallel, right?
+
+The git workspace is the obvious coordination point. Agents need to avoid conflicting edits. But git is the easy part.
+
+The harder problem is everything else: local databases, migrations, running servers, environment state. If one agent runs a migration and another expects the old schema, you're debugging phantom failures. If both try to spin up the same dev server, one wins and the other gets a port conflict that looks like a code bug.
+
+> "I think there are more shared resources than just the git workspace. If you're doing anything with a local database or migrations or trying to run a server, you might have the illusion of being able to run multiple things locally, but in practice you would need to be thoughtful about it."
+>
+> Matt, [Roo Cast S01E09](https://www.youtube.com/watch?v=Vo5grOXbjIY&t=2482)
+
+The illusion is that parallelism is free. The reality is that shared resources beyond git create implicit dependencies between agents.
+
+## The workaround that works today
+
+One pattern that works, if you're willing to pay the coordination cost: open multiple IDEs, run separate agents in each, keep the context separation yourself.
+
+> "I have probably five IDEs open right now. In each of them I probably have three or four agents that I'm actively bouncing between in that particular repo because I do a lot of systems thinking. I'm the one keeping the context separate. I'm making sure they aren't stepping on each other."
+>
+> Adam, [Roo Cast S01E09](https://www.youtube.com/watch?v=Vo5grOXbjIY)
+
+The cost is manual coordination. You become the orchestrator. You're tracking which agent is working on which branch, which one might touch the database, which one needs the server running. And at the end, you're the one rebasing.
+
+This works. It's not elegant. It scales with your attention span, not with your compute budget.
+
+## The tradeoff
+
+Parallel agents on one repo is a coordination problem, not a compute problem.
+
+If your tasks are purely file-based with no shared runtime state, parallelism is straightforward. Branch per agent, merge at the end. But the moment you have a local database, a running server, or migration state, you need isolation that goes beyond git branches.
+
+| Approach                         | Coordination cost     | Setup complexity | Best for                           |
+| -------------------------------- | --------------------- | ---------------- | ---------------------------------- |
+| Single agent, sequential tasks   | None                  | Minimal          | Simple workflows, small changes    |
+| Multiple IDEs, manual tracking   | High (your attention) | Low              | Power users who can context-switch |
+| Containerized environments       | Low                   | High             | Teams needing true isolation       |
+| Cloud agents with isolated state | Low                   | Medium           | Parallel tasks with merge at end   |
+| Sequential execution             | None                  | Minimal          | Avoiding conflicts entirely        |
+
+None of these is free. The question is which cost you want to pay: your attention, your infrastructure complexity, or your time.
+
+## Why this matters for your team
+
+For a five-person team running multiple agents, the coordination overhead is invisible until it isn't. The first time two agents step on each other's migrations, you lose an hour debugging a problem that looks like a code bug but is actually a state conflict.
+
+The pattern that might emerge: local and cloud agents becoming more analogous.
+
+> "Maybe you imagine a world where local and the cloud were a little more analogous to each other, where you can just kick things off in either direction and they run in parallel."
+>
+> Matt, [Roo Cast S01E09](https://www.youtube.com/watch?v=Vo5grOXbjIY&t=2508)
+
+If cloud agents run in isolated environments by default, the coordination problem shifts from "how do I keep agents from stepping on each other" to "how do I merge their outputs."
+
+That's a rebase problem. Rebase problems are solvable.
+
+## How Roo Code handles multi-agent coordination
+
+Roo Code addresses the parallel agent problem through intentional design choices. With BYOK (bring your own key), you control your token spend across multiple agents without platform markup getting in the way of running more agents.
+
+The key capability is that Roo Code closes the loop: it proposes changes, runs commands and tests, and iterates based on results. This means each agent instance can validate its own work before you need to coordinate merges. When an agent can run tests and catch its own breaking changes, you spend less time debugging state conflicts caused by blind parallel execution.
+
+For teams exploring multi-agent workflows, Roo Code's approval system lets you maintain human oversight without becoming the full-time orchestrator. You review diffs and approve commands intentionally, keeping agents from stepping on shared resources without constant manual monitoring.
+
+## The first step
+
+Before running multiple agents in parallel, audit the shared resources in your workflow. Git is obvious. Databases, servers, and environment state are where the real conflicts hide.
+
+If you can't isolate the runtime state, isolate the agents by running them sequentially. The slowdown is real, but the debugging time you save is worth it.
+
+## Frequently asked questions
+
+### Why do parallel AI coding agents conflict even when working on different files?
+
+Agents share more than just the git workspace. Local databases, migration state, running dev servers, and environment variables create implicit dependencies. One agent running a migration while another expects the old schema produces failures that look like code bugs but are actually state conflicts.
+
+### What is the simplest way to run multiple coding agents safely?
+
+Sequential execution eliminates coordination overhead entirely. One agent completes its task before the next begins. You lose parallelism but avoid the debugging time spent on state conflicts. For teams without containerized environments, this is often the practical choice.
+
+### How does Roo Code help with multi-agent workflows?
+
+Roo Code closes the loop by running tests and iterating on failures within each agent instance. This self-validation reduces the chance of merging broken changes. The approval system also lets you control which agents can run commands that affect shared resources like databases or servers.
+
+### Should I use separate git branches for each agent?
+
+Yes, branch-per-agent is the minimum isolation strategy. It handles file conflicts at merge time. But branches alone don't isolate runtime state. If your workflow involves databases or running servers, you need additional isolation through containers or sequential execution.
+
+### When does containerized environment isolation make sense?
+
+Containerization pays off when you have multiple developers running multiple agents with shared runtime dependencies. The setup cost is high, but each agent gets isolated database state, its own server ports, and independent migration history. Teams with complex local environments benefit most.
diff --git a/apps/web-roo-code/src/content/blog/score-agents-like-employees-not-like-models.md b/apps/web-roo-code/src/content/blog/score-agents-like-employees-not-like-models.md
new file mode 100644
index 00000000000..1a388b48849
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/score-agents-like-employees-not-like-models.md
@@ -0,0 +1,115 @@
+---
+title: Score Agents Like Employees, Not Like Models
+slug: score-agents-like-employees-not-like-models
+description: "Code correctness benchmarks miss critical agent failure modes. Score agents like employees: proactivity, context management, communication, and testing."
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-agents
+    - developer-productivity
+    - evaluation
+    - coding-agents
+status: published
+featured: true
+publish_date: "2025-11-05"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+You're grading your AI agent on the wrong rubric.
+
+Code correctness tells you if the output compiles. It tells you nothing about whether the agent will drift, ignore context, or go silent when it hits a wall.
+
+## The benchmark trap
+
+Your agent passes the coding benchmark. It writes syntactically correct code. It handles toy problems in an eval suite.
+
+Then you put it on a real task: refactor this authentication module, follow our patterns, don't break the existing tests.
+
+It writes code that compiles. It also ignores half the context you gave it, doesn't tell you when it's stuck, and "helpfully" changes things you didn't ask for.
+
+The benchmark said it was capable. Production said otherwise.
+
+## The rubric shift
+
+Some of the teams building these agents grade them differently. They treat the agent like an employee, not like a model.
+
+> "If you design your coding evals like you would a software engineer performance review, then you can measure their ability in the same ways as you can measure somebody who's coding."
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=1225)
+
+The rubric he described:
+
+1. **Proactivity:** Does it go ahead and do all of it, or does it stop and wait when it could keep moving?
+2. **Context management:** Can it keep all of the context it needs in memory without getting lost?
+3. **Communication:** Does it tell you its plan before executing? Does it surface when it's stuck?
+4. **Testing:** Does it validate its own work, or does it hand you untested code?
+
+These aren't code quality metrics. They're work style metrics. The difference matters.
+
+## Why correctness evals miss the failure modes
+
+A code correctness eval asks: "Did the output match the expected output?"
+
+A work style eval asks: "How did it get there, and what happens when the task gets harder?"
+
+An agent that scores high on correctness but low on communication will confidently produce wrong code without flagging uncertainty. An agent that scores low on context management will lose track of requirements halfway through a multi-file change. An agent that scores low on proactivity will stop and wait for you to hold its hand on every sub-task.
+
+These failure modes don't show up in benchmarks. They show up in real work.
+
+## Benchmark approach vs. work style approach
+
+| Dimension                   | Benchmark Approach                 | Work Style Approach                           |
+| --------------------------- | ---------------------------------- | --------------------------------------------- |
+| What it measures            | Code correctness on isolated tasks | Behavior patterns across complex workflows    |
+| Failure modes caught        | Syntax errors, wrong outputs       | Drift, context loss, silent failures          |
+| Task realism                | Toy problems, synthetic evals      | Multi-file changes, production patterns       |
+| Feedback loop               | Pass/fail on expected output       | Grades on proactivity, communication, testing |
+| Production readiness signal | "It can write code"                | "It can work reliably on your team"           |
+
+## How to build the rubric
+
+The approach: human-grade first, then tune an LLM-as-a-judge until it matches your scoring.
+
+1. Run realistic tasks (not toy problems)
+2. Have humans grade on proactivity, context management, communication, and testing
+3. Build an LLM-as-a-judge to replicate the grades
+4. Iterate until it correlates; use it for scale, spot-check with humans
+
+The tradeoff: this takes more upfront work than a correctness benchmark. The payoff is catching failure modes before they hit production.
+
+## How Roo Code makes agents reviewable
+
+Closing the loop is necessary, but it's not the whole job. What matters in production is whether an agent can iterate in a real environment **before the PR** and hand you something you can actually review: a diff, evidence, and a clear trail of what happened.
+
+That's the direction Roo Code is built for, and it maps directly to the rubric:
+
+- **Proactivity:** It can keep moving through sub-tasks and iterate until it has something reviewable
+- **Context management:** It can maintain context across multi-file changes without losing requirements halfway through
+- **Communication:** It can surface a plan and blockers as it goes, with artifacts you can inspect
+- **Testing:** It can run commands/tests and iterate on failures instead of handing you unverified code
+
+## Why this matters for your team
+
+For a Series A–C team with five to twenty engineers, agent reliability is a force multiplier. If your agent drifts or goes silent on complex tasks, someone has to babysit it. That someone is an engineer who could be shipping.
+
+Work style evals surface these problems before you've built workflows around an agent that can't handle the job. You find out in the eval, not in the incident postmortem.
+
+The rubric: proactivity, context management, communication, testing. Grade your agent like you'd grade a junior engineer on a trial period.
+
+If it can't tell you its plan, it's not ready for production.
+
+## Frequently asked questions
+
+### Why do code correctness benchmarks fail to predict production reliability?
+
+Code correctness benchmarks measure whether the output matches an expected result on isolated tasks. They don't capture how an agent behaves when context is complex, when it gets stuck, or when requirements span multiple files. An agent can score perfectly on benchmarks while drifting silently on real work.
+
+### What are the four work style metrics for evaluating coding agents?
+
+The four metrics are proactivity (does it keep moving or stop unnecessarily), context management (can it track requirements across a complex task), communication (does it share its plan and surface blockers), and testing (does it validate its own work). These predict production reliability better than correctness scores.
+
+### Can I use LLM-as-a-judge for automated work style evaluation?
+
+Yes. The recommended approach is to have humans grade agent work on the four dimensions first, then train an LLM-as-a-judge to replicate those grades. Once the automated judge correlates with human judgment, use it for scale while spot-checking with humans periodically.
diff --git a/apps/web-roo-code/src/content/blog/semantic-search-finds-what-grep-misses.md b/apps/web-roo-code/src/content/blog/semantic-search-finds-what-grep-misses.md
new file mode 100644
index 00000000000..65f2a69af9f
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/semantic-search-finds-what-grep-misses.md
@@ -0,0 +1,111 @@
+---
+title: Semantic Search Finds What Grep Misses
+slug: semantic-search-finds-what-grep-misses
+description: Learn why semantic search outperforms grep for AI coding agents navigating legacy codebases with inconsistent naming conventions, and how it reduces token costs.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - semantic-search
+    - codebase-indexing
+    - developer-productivity
+    - token-efficiency
+status: draft
+publish_date: "2025-07-09"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The model references a file that doesn't exist.
+
+You know the file exists. You wrote it last week. But the name you gave it has nothing to do with what it does, and the model's grep-based search came up empty.
+
+## The naming problem
+
+You're three hours into a refactor. The model keeps suggesting changes to the wrong module. You check the search logs: it's grepping for "authentication" but your auth logic lives in a file called `gatekeeper.ts` because that seemed clever at the time.
+
+Grep matches strings. Your codebase doesn't speak in strings. It speaks in concepts, abstractions, and the questionable naming decisions you made at 11pm on a Friday.
+
+> "My ability to name elements that are totally not what they should be named and an LLM can't guess. My ability to do that is greater than an LLM's ability to guess them."
+>
+> Hannes Rudolph, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=460)
+
+This isn't about bad code. It's about the gap between what you meant and what you typed. Semantic search closes that gap by matching meaning rather than characters.
+
+## Where grep fails
+
+Grep finds exact matches. It's fast, predictable, and completely blind to intent.
+
+When the connection between your prompt and the relevant code is conceptual rather than literal, grep returns nothing useful. You ask about "rate limiting" but the implementation uses `throttle` and `backoff`. You ask about "user permissions" but the code calls it `accessPolicy`.
+
+Semantic search indexes the codebase by meaning. When you prompt about a concept, it can surface relevant files even when the naming doesn't match.
+
+> "In situations where grep can't get there, indexing can, the semantic search can. There are edge cases when you're running through your development process where it can easily miss something if it's just using grep."
+>
+> Hannes Rudolph, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=447)
+
+The edge cases are where this matters most. On straightforward tasks with obvious file names, grep works fine. On the ambiguous tasks where you need the model to understand your codebase, semantic search is the difference between a useful suggestion and a confidently wrong one.
+
+## The cost angle
+
+There's a token cost to file discovery. Every time the model greps through your codebase looking for relevant files, it's spending tokens on the search operation.
+
+When grep misses and the model has to retry with different search terms, that cost multiplies. Three failed greps followed by a successful one means you paid for four searches when you needed one.
+
+Semantic indexing is an upfront cost. You index once, and subsequent lookups go directly to the relevant files.
+
+> "I think it's a big cost saving too... grep can be very expensive when it's trying to figure out where it needs to go in the codebase; codebase indexing can get you right to the right spot."
+>
+> Hannes Rudolph, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=479)
+
+For a team running dozens of tasks per day, the token savings compound. The model stops wandering through your file tree and starts landing on the right files on the first attempt.
+
+## How Roo Code closes the loop with semantic search
+
+Roo Code uses codebase indexing to build a semantic understanding of your project. When you start a task, the agent doesn't rely solely on string matching to find relevant files. It queries the semantic index to surface code by meaning, not just by name.
+
+This matters because Roo Code closes the loop: it proposes changes, runs commands, executes tests, and iterates based on results. If the agent starts with the wrong files, every subsequent step compounds the error. Semantic indexing ensures the agent lands in the right place before it starts making changes.
+
+With BYOK (bring your own key), every token spent on failed file searches comes directly from your API budget. Semantic search reduces wasted tokens by eliminating the grep-retry cycle that inflates costs on legacy codebases.
+
+**Roo Code's semantic search finds conceptually relevant files even when naming conventions don't match the prompt, reducing token waste and improving first-attempt accuracy for AI-assisted coding tasks.**
+
+## Grep vs. semantic search comparison
+
+| Dimension                   | Grep-based search             | Semantic search                  |
+| --------------------------- | ----------------------------- | -------------------------------- |
+| Match type                  | Exact string matches only     | Matches by meaning and concept   |
+| Legacy codebase performance | Poor with inconsistent naming | Strong across naming conventions |
+| Token cost on miss          | Multiplies with each retry    | Single lookup cost               |
+| Setup requirement           | None                          | One-time indexing                |
+| Best use case               | Known, consistent file names  | Conceptual queries, refactoring  |
+
+## Why this matters for your team
+
+For a Series A - C team with a five-year-old codebase full of legacy naming conventions, semantic search is the difference between an AI that understands your project and one that keeps asking where things are.
+
+The practical shift: instead of rewriting prompts to match your file names, you let the index bridge the gap. The model finds `gatekeeper.ts` when you ask about authentication because the semantic index knows what that file does, not just what it's called.
+
+If the model is repeatedly missing files you know exist, the context is wrong. Semantic indexing fixes the context problem at the source.
+
+## Frequently asked questions
+
+### Why does grep fail on older codebases?
+
+Grep matches exact strings, but legacy codebases accumulate naming inconsistencies over time. Different developers use different conventions, clever names replace descriptive ones, and abstractions obscure what files actually do. When your auth logic lives in `gatekeeper.ts` instead of `auth.ts`, grep searches for "authentication" return nothing.
+
+### How does semantic search reduce token costs?
+
+Every failed grep search costs tokens. When the model tries "authentication," then "auth," then "login," then "user," you pay for four searches. Semantic indexing lets the model find the right file on the first attempt because it indexes by meaning, not strings. The upfront indexing cost pays for itself within a few sessions.
+
+### Does Roo Code support semantic search for codebase indexing?
+
+Yes. Roo Code builds a semantic index of your project that the agent queries when searching for relevant files. This allows the agent to find code by concept rather than relying on exact string matches, which is especially valuable for codebases with inconsistent or legacy naming conventions.
+
+### When should I use grep instead of semantic search?
+
+Grep remains useful when you know the exact string you're looking for and file naming is consistent. For targeted searches like finding all occurrences of a specific function name or error message, grep is fast and precise. Semantic search adds value when the connection between your query and the code is conceptual rather than literal.
+
+### How do I know if my codebase needs semantic indexing?
+
+If your AI coding agent frequently misses files you know exist, or if you find yourself rewriting prompts to match file names, your codebase would benefit from semantic indexing. Teams with codebases older than two years, multiple past contributors, or domain-specific naming conventions see the largest improvements.
diff --git a/apps/web-roo-code/src/content/blog/skip-thinking-mode-on-opus-and-save-your-tokens.md b/apps/web-roo-code/src/content/blog/skip-thinking-mode-on-opus-and-save-your-tokens.md
new file mode 100644
index 00000000000..14b44b97bb7
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/skip-thinking-mode-on-opus-and-save-your-tokens.md
@@ -0,0 +1,125 @@
+---
+title: Skip Thinking Mode on Opus and Save Your Tokens
+slug: skip-thinking-mode-on-opus-and-save-your-tokens
+description: Evidence from a month of testing shows Opus delivers identical output quality with thinking mode disabled - here's how to cut your token spend by 10-20% without losing anything.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-models
+    - token-optimization
+    - claude-opus
+    - developer-productivity
+status: draft
+publish_date: "2026-01-12"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Thinking mode on Opus is overkill.
+
+After a month of running Opus with and without the extra reasoning step, the pattern is consistent: the output quality stays the same, but the cost and latency go up.
+
+## The experiment
+
+**Hypothesis:** Opus with thinking enabled produces measurably higher-quality results on coding tasks than Opus without it.
+
+**Setup:** Same model. Same tasks. Toggle thinking mode on and off across a month of real work.
+
+**Result:** No measurable difference in output quality. The thinking step adds tokens and wait time without changing what ships.
+
+> "I've used Opus for like a month now without thinking, and I've tried it with thinking. I think for Opus, thinking is overkill and pretty much a waste."
+>
+> Hannes Rudolph, [Roo Cast S01E20](https://www.youtube.com/watch?v=qxC0iyFBfWc&t=0)
+
+The mechanism makes sense when you think about what thinking mode actually does. It gives the model a scratch pad to reason through a problem before responding. For models that need that extra step to handle complexity, it helps. For Opus, the base model already handles complex reasoning well enough that the scratch pad becomes redundant compute.
+
+## The tier-based rule
+
+The pattern extends beyond just Opus. Match thinking mode to model tier, not task complexity:
+
+> "When I run Opus, I don't do thinking. When I run Sonnet, I use minimal thinking."
+>
+> Hannes Rudolph, [Roo Cast S01E20](https://www.youtube.com/watch?v=qxC0iyFBfWc&t=0)
+
+**Opus:** Skip thinking entirely. The base reasoning is strong enough.
+
+**Sonnet:** Use minimal thinking. Just enough to compensate for the lighter base reasoning, not enough to balloon the token count.
+
+The intuition that "complex task = enable thinking" is backwards. Complex task + capable model = skip thinking. The reasoning is already there.
+
+## The tradeoff
+
+This is not "thinking mode is useless." Thinking mode exists because some models need it to handle multi-step reasoning. The question is whether _this specific model_ needs it for _your specific tasks_.
+
+For Opus on coding tasks, the evidence points to no.
+
+> "I feel like Opus is just so good at doing everything that having thinking enabled doesn't improve anything at all."
+>
+> Hannes Rudolph, [Roo Cast S01E20](https://www.youtube.com/watch?v=qxC0iyFBfWc&t=7)
+
+The cost is concrete: thinking mode consumes tokens for the reasoning trace. If the reasoning trace does not change the final output, those tokens are overhead. Multiply that across a day of coding tasks and the waste compounds.
+
+Latency matters too. Every task waits for the thinking step to complete before you see the response. If the thinking step is not improving the result, you are paying in time for nothing.
+
+## When thinking mode might still help
+
+The pattern likely differs by model and by task type. If you are running a model that struggles with multi-step reasoning without the scratch pad, thinking mode earns its cost. If you are running Opus on tasks that require long chains of dependent logic (mathematical proofs, complex algorithm design), it might still add value.
+
+But for typical coding tasks - refactors, bug fixes, feature implementation, PR review context - Opus handles these without the extra step.
+
+## How Roo Code enables intentional token spending
+
+Roo Code's BYOK (Bring Your Own Key) model means you pay your AI provider directly for exactly the tokens you use. There is no markup, no hidden fees, and no intermediary padding the bill.
+
+This makes optimization choices like disabling thinking mode on Opus directly actionable. When you configure Roo Code to use Opus without thinking mode, you immediately see the cost reduction in your provider dashboard. The savings compound across every task the agent runs.
+
+**Roo Code lets you close the loop on token optimization: configure your model settings, run tasks, and verify your actual spend against your expected spend - all without leaving your editor.**
+
+The transparency matters. When you bring your own API key, you control the model, the parameters, and the cost. Roo Code executes your configuration without adding overhead.
+
+## Thinking mode comparison by model tier
+
+| Dimension                     | Opus with thinking          | Opus without thinking | Sonnet with minimal thinking |
+| ----------------------------- | --------------------------- | --------------------- | ---------------------------- |
+| Output quality (coding tasks) | Baseline                    | Same as baseline      | Slightly below Opus          |
+| Token cost per task           | Higher (reasoning trace)    | Lower                 | Moderate                     |
+| Response latency              | Longer wait                 | Faster response       | Moderate wait                |
+| When to use                   | Complex mathematical proofs | Standard coding work  | General development tasks    |
+| Cost efficiency               | Lower (redundant compute)   | Higher                | Balanced                     |
+
+## Why this matters for your workflow
+
+For an engineer running 10-20 coding tasks per day on Opus, disabling thinking mode could shave 10-20% off your token spend without changing your output quality. That is not a small efficiency gain. It is also not a small latency improvement: you get the same result in less wall-clock time.
+
+The setting is a toggle. The experiment is straightforward. Disable thinking mode for a week. Track whether your outputs degrade. If they do not, you have been paying for compute that was not helping.
+
+## The test
+
+Disable thinking mode on Opus. Run your normal tasks for a week.
+
+If output quality drops, re-enable it. If it does not, you just cut your Opus spend without losing anything.
+
+The setting is reversible. The experiment costs nothing but attention.
+
+## Frequently asked questions
+
+### Does disabling thinking mode affect code quality?
+
+For Opus on typical coding tasks, the evidence shows no measurable difference in output quality. The base Opus model handles complex reasoning without the additional scratch pad step. Run your own week-long test to verify this holds for your specific workload.
+
+### How much can I actually save by disabling thinking mode?
+
+The savings depend on your task volume and complexity. For engineers running 10-20 coding tasks per day on Opus, disabling thinking mode can reduce token spend by 10-20%. The reasoning trace tokens that thinking mode generates become pure overhead when they do not improve the final output.
+
+### Should I disable thinking mode on all models?
+
+No. Match thinking mode to model capability, not task complexity. Opus can skip thinking entirely. Sonnet benefits from minimal thinking. Models with weaker base reasoning may need full thinking mode to handle multi-step problems. The tier-based rule is: stronger base model, less thinking needed.
+
+### How do I configure thinking mode in Roo Code?
+
+Roo Code uses your API key directly with your chosen provider. Configure model parameters including thinking mode through your provider's API settings or through Roo Code's model configuration. Because Roo Code uses BYOK, your settings apply exactly as specified with no intermediary modifications.
+
+### When should I keep thinking mode enabled on Opus?
+
+Consider keeping thinking mode for tasks requiring long chains of dependent logic, such as mathematical proofs or complex algorithm design. For standard coding work - refactors, bug fixes, feature implementation, and PR reviews - the evidence suggests thinking mode adds cost without improving results.
diff --git a/apps/web-roo-code/src/content/blog/smaller-context-windows-unlock-worse-models.md b/apps/web-roo-code/src/content/blog/smaller-context-windows-unlock-worse-models.md
new file mode 100644
index 00000000000..05179f89953
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/smaller-context-windows-unlock-worse-models.md
@@ -0,0 +1,121 @@
+---
+title: Smaller Context Windows Unlock Worse Models
+slug: smaller-context-windows-unlock-worse-models
+description: Why budget LLMs with constrained context windows can outperform premium models with bloated context - and how to use this to ship faster at lower cost.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-windows
+    - model-selection
+    - orchestrator
+    - cost-optimization
+status: draft
+publish_date: "2025-10-10"
+publish_time_pt: "9:00am"
+source: "After Hours"
+---
+
+The worst model is good enough.
+
+Sounds like cope. But if you've watched a capable model hallucinate because its context window was stuffed with irrelevant code, you know the tradeoff.
+
+## The bloat problem
+
+You're asking a model to fix a failing test. You've got 200k tokens of context capacity, so you load everything: the full file, the test file, the imports, the related modules, the error log. The model has all the information it needs.
+
+And then it suggests a fix to a function that doesn't exist in your codebase.
+
+The model didn't get dumber. It got distracted. Context windows are not just capacity; they're attention. Pack them full and even capable models start pattern-matching against the wrong patterns.
+
+## The constraint that unlocks
+
+The counterintuitive finding: smaller context windows produce outputs from worse models that match or exceed bloated premium runs.
+
+One engineer tested this with Grok Coder Fast. It's a budget model. It's not going to win benchmarks. But when the task was scoped tightly, with a constrained context window, it produced solid results.
+
+> "When your context window isn't packed full, even a shitty model, well, shitty like Grok Coder Fast is capable of doing really really impressive stuff. You just can't give it too much on its plate at once."
+>
+> Ru Tang, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=2009)
+
+The key phrase: "too much on its plate at once." The constraint isn't model capability. The constraint is attention management.
+
+## The orchestrator pattern
+
+This is where [Orchestrator mode](https://docs.roo.vet/features/orchestrator) changes the math.
+
+When a parent agent breaks work into subtasks and delegates to child agents, each child starts with a fresh context window. No accumulated cruft. No 80,000 tokens of tangentially relevant code. Just the specific task and the specific files needed.
+
+> "When the orchestrator is breaking the tasks up, handing it off to different modes, that's a fresh context window every time. That's the secret."
+>
+> Ru Tang, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=1994)
+
+The secret is structural, not magical. Fresh context windows mean the model's attention isn't diluted across irrelevant context. A budget model with 20k of focused context can outperform a premium model with 150k of noise because the signal-to-noise ratio inverts.
+
+Think of it as the difference between asking someone to find a specific line in a single file versus asking them to find it somewhere in a 50-file directory dump. Same capability, different cognitive load.
+
+## The cliff
+
+There's a specific threshold where models fall off. For Grok Coder Fast, it's around 80,000 tokens.
+
+> "Grok Coder Fast is not good at looking at a lot at once. When as soon as the context window is anywhere above 80,000 tokens or so it just falls apart."
+>
+> Ru Tang, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=1854)
+
+Below the cliff: solid results. Above the cliff: falls apart. The model doesn't degrade gracefully; it hits a wall.
+
+This means teams can run controlled tests on context size. Same model, same task, different context constraints. If the constrained version performs comparably, you've found a path that costs a fraction of the premium approach.
+
+## Why this matters for your workflow
+
+For engineers shipping PRs daily, the implication is direct: you might be overpaying for model capability when the real bottleneck is context hygiene.
+
+If you're running tasks that load entire directories into context, test what happens when you scope down. Break the task into smaller pieces. Use Orchestrator mode to delegate subtasks to fresh windows. Track whether the outputs degrade or stay comparable.
+
+The cost difference between a premium model with bloated context and a budget model with tight context can be 5x to 10x. And if the outputs match, the budget path wins every time.
+
+This also explains why some teams report "the AI got worse" after scaling usage. They didn't change models. They changed context patterns, loading more files, running longer sessions, accumulating state. The model stayed the same; the context hygiene degraded.
+
+## The shift
+
+Stop optimizing for model capability. Start optimizing for context discipline.
+
+If your premium model is hallucinating, check the context window size before blaming the model. The fix might be subtraction, not substitution.
+
+## How Roo Code closes the loop with context discipline
+
+Roo Code's Orchestrator mode enables context-aware task delegation by design. When you start a complex task, the orchestrator breaks the work into discrete subtasks and hands each one to a child agent with a fresh context window. This structural pattern means you can use BYOK to bring your preferred models, including budget options like Grok Coder Fast, and still get premium-quality outputs.
+
+The key insight: **Roo Code's orchestrator pattern treats context windows as a first-class resource, not an afterthought.** Each subtask operates in isolation, preventing context bloat from degrading model performance across your session.
+
+## Bloated context vs. context discipline
+
+| Dimension          | Bloated Context Approach  | Context Discipline Approach |
+| ------------------ | ------------------------- | --------------------------- |
+| Context size       | 150k-200k tokens loaded   | 20k-40k focused tokens      |
+| Model cost         | Premium models required   | Budget models viable        |
+| Hallucination risk | High due to pattern noise | Low due to signal clarity   |
+| Task structure     | Monolithic prompts        | Decomposed subtasks         |
+| Session behavior   | Degrades over time        | Fresh windows per task      |
+
+## Frequently asked questions
+
+### Why do larger context windows sometimes produce worse results?
+
+Context windows represent attention capacity, not just storage. When you pack a window with 150k tokens of code, the model must attend to all of it when generating responses. Irrelevant context introduces noise that competes with the actual signal, causing the model to pattern-match against the wrong patterns and hallucinate fixes for code that doesn't exist.
+
+### How does Roo Code's Orchestrator mode help with context management?
+
+Orchestrator mode breaks complex tasks into subtasks and delegates each to a child agent with a fresh context window. This structural approach prevents context accumulation across your session. Each subtask gets only the specific files and information it needs, keeping the signal-to-noise ratio high even when using budget models with BYOK.
+
+### What's the context window threshold where models start failing?
+
+It varies by model. For Grok Coder Fast, the cliff is around 80,000 tokens. Below that threshold, outputs remain solid. Above it, the model falls apart rather than degrading gracefully. Teams can run controlled tests comparing the same task at different context sizes to find their specific thresholds.
+
+### Can I use budget models instead of premium models for coding tasks?
+
+Yes, if you maintain context discipline. A budget model with 20k tokens of focused context can match or exceed a premium model with 150k tokens of noise. The cost difference is 5x to 10x, and the outputs may be comparable or better. Test by scoping tasks tightly and measuring whether quality degrades.
+
+### Why does my AI coding assistant seem to get worse over longer sessions?
+
+You likely changed context patterns without realizing it. Longer sessions accumulate state, load more files, and pack more history into the context window. The model didn't change; your context hygiene degraded. Reset with fresh context windows or use orchestration patterns to maintain performance.
diff --git a/apps/web-roo-code/src/content/blog/sonnet-45-does-not-dig-for-context-and-that-changes-how-you-use-it.md b/apps/web-roo-code/src/content/blog/sonnet-45-does-not-dig-for-context-and-that-changes-how-you-use-it.md
new file mode 100644
index 00000000000..12b8e83a778
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/sonnet-45-does-not-dig-for-context-and-that-changes-how-you-use-it.md
@@ -0,0 +1,108 @@
+---
+title: Sonnet 4.5 Does Not Dig for Context and That Changes How You Use It
+slug: sonnet-45-does-not-dig-for-context-and-that-changes-how-you-use-it
+description: Sonnet 4.5 excels at spec-driven implementation but guesses at debugging tasks instead of reading your codebase first. Learn when to use it and when to switch models.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - model-selection
+    - debugging
+    - developer-workflow
+    - ai-coding
+status: draft
+publish_date: "2025-10-03"
+publish_time_pt: "9:00am"
+source: "After Hours"
+---
+
+You describe the bug. The model suggests a fix.
+
+The fix is wrong. Not because the model can't code, but because it never looked at the file where the bug actually lives.
+
+## The guess-first pattern
+
+You've got a failing test in an existing codebase. You prompt Sonnet 4.5: "This endpoint returns 401 when it should return 200. Help me track it down."
+
+The model responds immediately. It suggests checking your auth middleware. It's confident. It's plausible. It's also a guess based on the surface-level description you gave it, not on the actual code in your repo.
+
+You implement the suggestion. The test still fails. You prompt again with more detail. Another confident suggestion. Another guess.
+
+The model never opened your auth service file. Never read the middleware chain. Never looked at the test setup to see what was actually being mocked. It answered based on what a 401 error usually means, not what it means in your codebase.
+
+## Lazy is the right word
+
+Sonnet 4.5 excels at spec-driven work. Give it a clear specification for something that doesn't exist yet, and it will build it. Zero-to-one implementation is where it shines.
+
+But debugging in existing codebases exposes a different behavior.
+
+> "If you take Sonnet 4.5 and you give it a spec and you tell it to build this thing, it's going to nail it. So it's a one-shot from zero to something. But existing codebase: if you're saying like, hey, I've got this problem, I need help tracking it down, it will take the most surface level answer possible."
+>
+> GosuCoder, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=902)
+
+The pattern is consistent: the model doesn't proactively gather context. It doesn't read files to understand the actual structure before answering. It works with what you gave it in the prompt, and if that's incomplete, the answer will be incomplete.
+
+> "It's lazy. It's a lazy model. That's the best way I can describe it. If you say it, if you tell it here's what you need to do, probably going to do it. But it's not going to be proactive at gathering context."
+>
+> Dan, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=1040)
+
+## The contrast: models that dig
+
+GPT-5 Codex behaves differently. Given the same ambiguous debugging prompt, it will use available tools (especially codebase indexing) to read files before answering. It gathers context proactively, which means its first answer is more likely to be grounded in your actual code.
+
+This isn't a universal "one model is always the right choice" situation. It's a workflow decision based on what kind of task you're running.
+
+## The tradeoff
+
+Sonnet 4.5 is fast for spec work because it doesn't spend tokens reading your entire codebase first. That efficiency is a feature when you're building something new from a clear specification.
+
+But that same efficiency becomes a liability when you need the model to understand existing code before acting. If you're debugging, or refactoring, or trying to track down why something fails in CI, the model's reluctance to gather context means you end up doing the context-gathering yourself, pasting file contents into prompts, explaining relationships the model should have discovered.
+
+## How Roo Code closes the loop on model selection
+
+Roo Code supports BYOK (bring your own key) for multiple providers, which means you can switch models mid-task without leaving your editor. When you hit a debugging wall with a guess-first model, you switch to one that digs for context. When you have a clear spec for new implementation, you switch back.
+
+This is close the loop in practice: the agent runs commands, surfaces test failures, and lets you iterate with the right model for each step. You're not locked into a single model's behavioral profile. You spend tokens intentionally for outcomes, matching model strengths to task requirements rather than forcing one model to do everything.
+
+## Model behavior comparison for debugging tasks
+
+| Dimension                      | Guess-first models (Sonnet 4.5)  | Context-first models (GPT-5 Codex) |
+| ------------------------------ | -------------------------------- | ---------------------------------- |
+| Initial response speed         | Fast - answers immediately       | Slower - reads files first         |
+| Context gathering              | Manual - you paste file contents | Automatic - uses codebase indexing |
+| Spec-to-implementation         | Excellent one-shot execution     | Good but may over-read             |
+| Debugging accuracy             | Low on first attempt             | Higher on first attempt            |
+| Token efficiency for new code  | High - minimal context overhead  | Lower - reads before writing       |
+| Token efficiency for debugging | Low - multiple prompt cycles     | Higher - fewer re-prompts          |
+
+## Why this matters for your team
+
+For a team of 5-8 engineers maintaining a production codebase, debugging tasks outnumber greenfield features most weeks. If your default model guesses at bugs instead of reading your actual code, you're spending time re-prompting and pasting file contents that a more proactive model would have gathered on its own.
+
+The compounding effect: each debugging session that requires three prompts instead of one adds up. Across a sprint, the difference between "read-first" and "guess-first" model behavior translates into hours of context assembly that the model could have done.
+
+The practical heuristic is simple: use Sonnet 4.5 when you have a clear spec and want implementation. Switch to a model with proactive context-gathering when you need it to understand your existing code before acting.
+
+Match the model to the task. Spec work: Sonnet 4.5. Debugging: something that digs for context first.
+
+## Frequently asked questions
+
+### Why does Sonnet 4.5 guess instead of reading my codebase?
+
+Sonnet 4.5 optimizes for speed and token efficiency on spec-driven tasks. It responds based on the information in your prompt rather than proactively using tools to gather additional context. This makes it fast for greenfield implementation but less effective for debugging where the answer depends on code the model hasn't seen.
+
+### How do I know when to switch models during a task?
+
+Switch when you notice the pattern of confident-but-wrong suggestions. If you're pasting file contents manually or re-prompting with additional context more than once, the model isn't gathering context on its own. That's your signal to switch to a model that reads first.
+
+### Can Roo Code help me switch models without breaking my workflow?
+
+Yes. Roo Code's BYOK approach means you configure multiple providers and switch between them inside your editor. You can start a task with one model and switch mid-session when the task requirements change from implementation to debugging or vice versa.
+
+### Does this mean Sonnet 4.5 is bad for production codebases?
+
+Not entirely. Sonnet 4.5 is still effective for well-scoped implementation tasks even in large codebases - when you provide a clear spec and the model doesn't need to discover context on its own. The limitation shows up specifically when you need the model to understand existing code before acting.
+
+### What's the token cost difference between guess-first and context-first approaches?
+
+Guess-first models use fewer tokens per response but often require multiple prompt cycles for debugging. Context-first models spend more tokens upfront reading files but typically resolve issues in fewer attempts. For debugging tasks, context-first approaches often cost less total tokens despite higher per-response usage.
diff --git a/apps/web-roo-code/src/content/blog/stop-fixing-midflight-derailments-kill-and-restart.md b/apps/web-roo-code/src/content/blog/stop-fixing-midflight-derailments-kill-and-restart.md
new file mode 100644
index 00000000000..88b07b1f6d9
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/stop-fixing-midflight-derailments-kill-and-restart.md
@@ -0,0 +1,120 @@
+---
+title: Stop Fixing Mid-Flight Derailments - Kill and Restart
+slug: stop-fixing-midflight-derailments-kill-and-restart
+description: Learn why killing derailed AI coding tasks and restarting with fixed workflows beats mid-flight correction, saving engineering teams hours weekly.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-workflows
+    - developer-productivity
+    - agentic-coding
+status: draft
+publish_date: "2025-10-10"
+publish_time_pt: "9:00am"
+source: "After Hours"
+---
+
+Kill it. Start over.
+
+That's not failure. That's the workflow.
+
+## The salvage instinct
+
+The task started fine. Clear prompt, reasonable scope. Then somewhere around the third iteration, it drifted. Now it's suggesting changes to files you didn't mention, referencing functions that don't exist, and confidently explaining why its broken approach is correct.
+
+Your instinct: course-correct. Add more context. Clarify the constraint. Nudge it back on track.
+
+You're now debugging the task instead of shipping the feature.
+
+This is where teams lose hours. Not because the model failed, but because the recovery attempt costs more than starting clean.
+
+## The counterintuitive discipline
+
+The teams that ship fastest have a different pattern: they kill derailed tasks and restart with a fixed workflow.
+
+> "Instead of trying to fix a shitty task once it derails, just kill it. Start over. Fix your workflow if you need to, but just stop trying to use a workflow that doesn't work."
+>
+> Hannes Rudolph, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=2256)
+
+The insight isn't "give up easily." It's that mid-flight correction is expensive. Every prompt you spend trying to salvage a derailed task is a prompt that could have gone into a clean run with a workflow that actually works.
+
+The math changes when you realize: fixing the workflow once benefits every future task. Fixing this task benefits only this task.
+
+## Inspect at the end, not throughout
+
+The other shift is where you put human attention. The instinct is to checkpoint frequently: review after every step, course-correct as you go, maintain tight control.
+
+The problem is that checkpoints become interaction points. Every time you stop the task to review, you're injecting latency and context switches into the workflow.
+
+> "The main thing I learned recently is stop creating workflows that need human interaction."
+>
+> Dan, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=2181)
+
+Instead: let the task run. Inspect the end result. If it worked, ship it. If it didn't, fix the workflow and restart.
+
+This feels riskier. You're giving up control. But if your workflow is solid, the end result is predictable. And if your workflow is broken, you'll find out either way. The question is whether you find out after three checkpoints or after one clean run.
+
+> "If it gets distracted, just go and edit your workflow, your instructions, instead of just going back on every task trying to get it to work. Just let it do its thing. Inspect the end."
+>
+> Hannes Rudolph, [After Hours S01E02](https://www.youtube.com/watch?v=I3HiU_G-cjk&t=2283)
+
+## The tradeoff
+
+This discipline requires trust in your workflow. If you haven't validated that your instructions produce reliable results, "let it run and inspect the end" is a gamble.
+
+The investment is upfront: build workflows that work without mid-flight intervention. Test them on representative tasks. When they fail, fix the workflow, not the task.
+
+This is harder at first. You have to resist the salvage instinct. You have to accept that some tasks will fail completely rather than being nudged to partial success.
+
+But the compounding benefit is real: every workflow fix propagates to every future task.
+
+## Why this matters for your team
+
+For a five-person team running 15-20 AI tasks per week, the salvage pattern adds up. If three tasks per week hit the "try to save it" loop, and each loop burns 30-45 minutes of engineer attention, that's 2-3 hours of lost time weekly. Time spent debugging tasks instead of debugging code.
+
+The alternative: kill derailed tasks immediately. Spend that time fixing the workflow. The next 15 tasks benefit from the fix.
+
+The shift is process iteration over task recovery. If a workflow keeps failing, the workflow is the bug.
+
+## How Roo Code enables the kill-and-restart workflow
+
+Roo Code is built for exactly this discipline. Because Roo Code closes the loop - proposing diffs, running commands and tests, and iterating based on results - you get clear signal on whether a task succeeded or failed. There's no ambiguity to salvage.
+
+With BYOK (bring your own key), you pay only for the tokens you use, which changes the economics of restarting. A clean restart with a fixed workflow costs exactly what it should - no platform markup, no sunk cost fallacy pushing you to salvage broken runs.
+
+Roo Code's mode system and custom instructions let you encode workflow fixes once and apply them to every future task. When you kill a derailed task and fix the workflow, that fix lives in your configuration, not in your memory.
+
+**The pattern Roo Code supports: fail fast, fix the workflow, restart clean, and let the agent close the loop without mid-flight intervention.**
+
+## Kill-and-restart vs. salvage: a comparison
+
+| Dimension              | Salvage approach                               | Kill-and-restart approach                   |
+| ---------------------- | ---------------------------------------------- | ------------------------------------------- |
+| Time per derailed task | 30-45 minutes of correction attempts           | 5 minutes to kill and restart               |
+| Benefit scope          | Fixes only the current task                    | Workflow fix benefits all future tasks      |
+| Cognitive load         | High - debugging task and model simultaneously | Low - clear decision point                  |
+| Failure signal         | Unclear - partial success masks workflow bugs  | Clear - failed tasks reveal workflow issues |
+| Long-term velocity     | Flat - same problems recur                     | Compounding - fewer derailments over time   |
+
+## Frequently asked questions
+
+### When should I kill a task versus trying to save it?
+
+Kill the task when you've spent more than two prompts trying to course-correct, when the model is referencing files or functions that don't exist, or when you're explaining the same constraint for the third time. The threshold is lower than your instinct suggests. If the task is fighting you, the workflow is the bug.
+
+### How do I know if the problem is my workflow or just a bad run?
+
+Track patterns across tasks. If the same type of derailment happens twice, it's a workflow problem. Single failures might be noise, but repeated failures in similar situations point to missing instructions, unclear constraints, or scope that's too broad for a single task.
+
+### Does Roo Code support killing and restarting tasks cleanly?
+
+Yes. Roo Code's task model lets you terminate a derailed task and start fresh without losing your workflow configuration. Your custom instructions, mode settings, and project context persist across tasks, so restarting is low-friction. The agent closes the loop on each task independently, giving you clear success or failure signals.
+
+### Won't I waste tokens by restarting instead of salvaging?
+
+The opposite is usually true. Salvage attempts often consume more tokens than a clean restart because you're paying for correction prompts, re-explanations, and partial rollbacks. With BYOK pricing, you pay only for actual token usage - no platform markup - so restarting when it's the right call costs exactly what it should.
+
+### How do I build workflows that don't need mid-flight intervention?
+
+Start with explicit constraints: which files to touch, which to ignore, what the success criteria looks like. Test the workflow on representative tasks before relying on it. When a task fails, ask what instruction would have prevented the failure and add it. Over time, your workflows accumulate the guardrails that make autonomous runs reliable.
diff --git a/apps/web-roo-code/src/content/blog/strip-the-comments-before-you-feed-the-context.md b/apps/web-roo-code/src/content/blog/strip-the-comments-before-you-feed-the-context.md
new file mode 100644
index 00000000000..e4e35017065
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/strip-the-comments-before-you-feed-the-context.md
@@ -0,0 +1,119 @@
+---
+title: Strip the Comments Before You Feed the Context
+slug: strip-the-comments-before-you-feed-the-context
+description: Stale code comments confuse AI coding agents by providing contradictory context. Learn how to audit comment freshness and practice context hygiene for better agent output.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-management
+    - ai-coding-agents
+    - developer-workflow
+    - prompt-engineering
+status: draft
+publish_date: "2025-04-09"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The model read the comment. Then it read the code. Then it got confused.
+
+## The contradiction problem
+
+Your codebase has comments. Some were written last week. Some were written three years ago by someone who left. Some describe behavior that was refactored twice since then.
+
+To a human reviewer, stale comments are noise. You skim past them, trust the code, maybe leave a "TODO: update this comment" that never gets done.
+
+To an LLM, every comment is context. Equal weight. Equal validity. The model cannot distinguish between "accurate description of current behavior" and "outdated note from 2019 that contradicts the implementation."
+
+When the comments disagree with each other, the model has to pick a side. Sometimes it picks the wrong one. Sometimes it tries to satisfy both, generating duplicate methods or ignoring your instructions entirely.
+
+> "If your code is full of comments, those comments are often not in agreement with one another. And so those comments influence the large language model as you go."
+>
+> Hannes Rudolph, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=4203)
+
+## The experiment
+
+One developer hit a wall on an experimental project. Full vibe-coding mode: let the agent run, don't look at anything, ship fast. It worked until it didn't. The agent started producing output that made no sense, ignoring clear instructions, generating code that contradicted itself.
+
+The fix was not a prompt change. It was not a model switch. It was stripping the comments.
+
+> "I was working on an experimental project where I 100% vibed it and I didn't look at anything and then I got to a place where it just stopped working. So what I did is strip out all the comments and it responded 100 times better immediately."
+>
+> Hannes Rudolph, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=4228)
+
+No tuning. No elaborate system prompt. Just removing the contradictory context that was poisoning every interaction.
+
+## The tradeoff
+
+This is not "comments are bad." Comments written for humans serve a real purpose: explaining intent, documenting edge cases, warning future maintainers about non-obvious behavior.
+
+The problem is accuracy decay. Comments that were true when written become false as code changes. The code gets updated; the comment does not. Over time, a codebase accumulates layers of contradictory documentation, each layer confident about behavior that no longer exists.
+
+For human readers, this is annoying but manageable. For LLMs treating every token as valid signal, it is actively harmful.
+
+> "If you're going to have comments, make sure they're extremely accurate. Otherwise, just don't have them."
+>
+> Hannes Rudolph, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=4237)
+
+The rule is binary: accurate comments help. Inaccurate comments hurt. There is no neutral middle ground where stale comments are "fine."
+
+## The practical workflow
+
+Before running an agentic task on a legacy codebase:
+
+1. **Audit comment freshness.** When was this file last meaningfully edited? Do the comments describe current behavior or historical behavior?
+
+2. **Strip aggressively if uncertain.** If you cannot verify a comment is accurate, remove it. The model will read the code. The code does not lie about what it does.
+
+3. **Keep comments that encode intent.** "We do X because of constraint Y" is valuable if Y is still true. "This function does Z" is worthless if the function was refactored.
+
+4. **Re-add comments after the task.** Once the agent finishes and you review the output, add fresh comments that describe the new state. Future agents (and future humans) will thank you.
+
+## Comment freshness: old approach vs. context-aware approach
+
+| Dimension           | Old approach                                  | Context-aware approach                                  |
+| ------------------- | --------------------------------------------- | ------------------------------------------------------- |
+| Comment treatment   | Leave all comments in place                   | Audit and strip stale comments before agent tasks       |
+| Accuracy assumption | Comments are helpful documentation            | Comments are context that LLMs weight equally with code |
+| Debugging focus     | Prompt engineering and model selection        | Context hygiene and contradiction removal               |
+| Post-task workflow  | Move on to next task                          | Re-add accurate comments describing new state           |
+| Signal quality      | Mixed signals from years of accumulated notes | Clean signal from verified, current documentation       |
+
+## How Roo Code handles context for better agent output
+
+Roo Code closes the loop by reading your codebase, proposing changes, running tests, and iterating based on results. This agentic workflow means every piece of context in your files directly influences what the agent produces.
+
+When you use BYOK (Bring Your Own Key) with Roo Code, you control the models and the tokens. But model quality only matters if the context is clean. Contradictory comments in your codebase act as noise that competes with your actual instructions.
+
+**Before starting an agentic task in Roo Code, strip stale comments from files the agent will touch.** The agent reads code as truth. When comments contradict that truth, the agent may generate code that satisfies the outdated comment instead of your current requirements.
+
+## Why this matters for your workflow
+
+If you have been debugging agent behavior and the model keeps making confident mistakes, check the comments. The model might be reading a description of how the code worked two years ago and trying to make the current code match that description.
+
+The fix is not a prompt. The fix is context hygiene.
+
+Strip the comments. Let the model read the code. Add accurate comments back when you are done.
+
+## Frequently asked questions
+
+### Why do stale comments hurt AI coding agents more than human developers?
+
+Human developers subconsciously discount comments that seem outdated or contradictory. LLMs process every token with equal weight. A comment from 2019 describing deprecated behavior carries the same authority as code written yesterday. The model cannot infer that one source is more trustworthy than another.
+
+### Should I remove all comments before using an AI coding agent?
+
+Not all comments. Keep comments that encode intent or explain constraints that are still valid. Remove comments that describe implementation details, especially if you cannot verify they match current behavior. The goal is accurate context, not zero context.
+
+### How does Roo Code handle contradictory information in my codebase?
+
+Roo Code reads your files and uses that context to propose changes. When your codebase contains contradictory comments, the agent must resolve the conflict somehow. It may follow the outdated comment, ignore your instructions, or produce inconsistent output. Stripping stale comments before the task gives the agent clean context to work with.
+
+### What is the fastest way to audit comment freshness in a large codebase?
+
+Check file modification dates against comment content. If a file was substantially refactored but comments still describe the old structure, those comments are candidates for removal. For legacy codebases, consider stripping comments from files the agent will modify and re-adding accurate documentation after the task completes.
+
+### Does this apply to documentation strings and docstrings too?
+
+Yes. Docstrings that describe function signatures, parameters, or return values can mislead an agent if the function signature changed. Any text the model reads as context can introduce contradictions. Audit docstrings with the same scrutiny as inline comments.
diff --git a/apps/web-roo-code/src/content/blog/temperature-is-the-most-underrated-model-parameter-for-frontend-work.md b/apps/web-roo-code/src/content/blog/temperature-is-the-most-underrated-model-parameter-for-frontend-work.md
new file mode 100644
index 00000000000..f0604afab0a
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/temperature-is-the-most-underrated-model-parameter-for-frontend-work.md
@@ -0,0 +1,121 @@
+---
+title: Temperature Is the Most Underrated Model Parameter for Frontend Work
+slug: temperature-is-the-most-underrated-model-parameter-for-frontend-work
+description: Learn why temperature settings determine whether your AI-generated frontend code looks hand-crafted or generic, and how to configure model parameters for design vs. functional work.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - model-parameters
+    - frontend-development
+    - api-configuration
+    - prompt-engineering
+status: draft
+publish_date: "2025-10-03"
+publish_time_pt: "9:00am"
+source: "After Hours"
+---
+
+`temperature: 1.0`
+
+That is not a minor config tweak. That is the difference between a portfolio site that looks hand-crafted and one that looks like a Bootstrap template.
+
+## The parameter nobody talks about
+
+You're evaluating a new model for frontend work. You run it through your standard prompts: build a landing page, add some animations, make it look polished. The results come back flat. Functional, but visually generic. You move on to the next model.
+
+But the problem might not be the model. It might be the temperature setting you never changed from the default.
+
+For GLM 4.6, the difference is stark. At temperature 0.6, you get clean, predictable output: the component renders, the logic works, the CSS is sensible. At temperature 1.0, you get particle effects, hover animations, gradient backgrounds, and design choices that look like someone actually thought about aesthetics.
+
+Same model. Same prompt. Different parameter. Fundamentally different results.
+
+## The split personality
+
+> "Temperature matters a lot for this model. If you want good-looking stuff, temperature one. If you want stuff to be like functional API stuff, you probably want lower temperature like 0.6ish."
+>
+> GosuCoder, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU)
+
+This is not a spectrum where higher temperature means "more creative but less reliable." It is a mode switch. The model at 0.6 is solving a different problem than the model at 1.0.
+
+At lower temperature, the model optimizes for correctness and predictability. It produces code that works, follows conventions, and avoids risks. This is exactly what you want for API integrations, data transformations, and business logic.
+
+At higher temperature, the model takes aesthetic risks. It adds visual flourishes that a conservative prompt would never produce. The tradeoff: you need to review the output more carefully, because "creative" sometimes means "unexpected."
+
+> "So this is temperature one... Now it looks like our website."
+>
+> GosuCoder, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=280)
+
+## The practical setup
+
+The solution is not "always use high temperature" or "always use low temperature." The solution is separate API profiles for separate jobs.
+
+**Design profile (temperature 1.0):**
+
+- Landing pages
+- Portfolio sites
+- Marketing components
+- Anything where visual polish matters
+
+**Functional profile (temperature 0.6):**
+
+- API integrations
+- Form validation
+- Data processing
+- Anything where predictability matters
+
+In Roo Code, you can create API configuration profiles that store these settings. Switch profiles based on the task, not mid-conversation. The model behaves differently depending on which profile is active, so treat them as different tools for different jobs.
+
+## How Roo Code enables task-specific temperature control
+
+Roo Code's BYOK (Bring Your Own Key) architecture means you configure model parameters directly in your API provider profiles-temperature, top_p, and other settings are yours to control. Because Roo Code closes the loop by running code, executing tests, and iterating on results, the temperature setting affects the entire agentic cycle: a design-focused profile at temperature 1.0 generates visually sophisticated components that Roo Code can then validate by actually rendering and testing them.
+
+**The key advantage: you can switch between a conservative functional profile and an expressive design profile without leaving your editor, and Roo Code will iterate on the output regardless of which mode you choose.**
+
+## Old approach vs. new approach
+
+| Dimension           | Old approach (fixed defaults)         | New approach (task-specific profiles)             |
+| ------------------- | ------------------------------------- | ------------------------------------------------- |
+| Temperature setting | Single default for all tasks          | Design profile (1.0) vs. functional profile (0.6) |
+| Model evaluation    | Judge once, conclude permanently      | Test same model at multiple settings              |
+| Frontend output     | Generic, requires manual polish       | Visually sophisticated on first pass              |
+| Backend output      | May be over-creative, introduces bugs | Predictable, convention-following                 |
+| Workflow            | Post-hoc CSS tweaking                 | Review and ship                                   |
+
+## The evaluation trap
+
+Here is where teams waste time: they evaluate a model once, with default settings, and conclude it is not good at frontend work.
+
+But model evaluation without parameter tuning is incomplete. A model that looks mediocre at temperature 0.6 might produce excellent results at temperature 1.0. The inverse is also true: a model that looks "creative" at high temperature might be unreliable for production API code.
+
+If you are comparing models for frontend work, run the same prompt at multiple temperature settings. The "best" model depends on what you are optimizing for, and that changes based on the task.
+
+## Why this matters for your workflow
+
+For engineers doing frontend work, temperature is the variable that determines whether you spend an hour tweaking CSS to make generated output look polished, or whether the first render already has the visual sophistication you need.
+
+The time cost is real. If every generated component needs manual aesthetic fixes, you are doing the work the model should have done. If the model produces visually interesting output on the first pass, you are reviewing and shipping, not redesigning.
+
+The shift: treat temperature as a task-specific parameter, not a set-and-forget default. Create profiles. Switch based on the job. Stop evaluating models at one temperature and concluding they cannot do design work.
+
+## Frequently asked questions
+
+### What temperature setting should I use for frontend design work?
+
+For frontend work where visual polish matters-landing pages, portfolio sites, marketing components-use temperature 1.0 or higher. This setting enables the model to take aesthetic risks, producing particle effects, hover animations, and gradient backgrounds that would not emerge at conservative settings. The tradeoff is that you need to review output more carefully.
+
+### Does higher temperature mean less reliable code?
+
+Not exactly. Higher temperature produces code that takes more creative risks, which means unexpected output-not necessarily broken output. For API integrations and business logic where predictability matters, use temperature 0.6. For design work, the "unexpected" output is often exactly the visual sophistication you want.
+
+### How do I switch between temperature profiles in Roo Code?
+
+Roo Code supports API configuration profiles through its BYOK architecture. Create separate profiles for design work (temperature 1.0) and functional work (temperature 0.6), then switch profiles based on the task. The agent will use the active profile's settings for all model calls, so treat each profile as a different tool optimized for a different job.
+
+### Why do model evaluations miss this parameter?
+
+Most teams evaluate models once with default settings, which typically use conservative temperature values. A model that appears mediocre at temperature 0.6 might produce excellent frontend results at temperature 1.0. Complete model evaluation requires testing the same prompts at multiple temperature settings to understand the model's full capability range.
+
+### Can I use different temperatures for different parts of the same project?
+
+Yes. The recommended approach is to switch profiles based on the current task, not mid-conversation. Use your design profile when building UI components and visual elements, then switch to your functional profile for API integrations and data processing. This matches the tool to the job rather than forcing one setting to work for everything.
diff --git a/apps/web-roo-code/src/content/blog/the-bottleneck-moved-from-coding-to-verification.md b/apps/web-roo-code/src/content/blog/the-bottleneck-moved-from-coding-to-verification.md
new file mode 100644
index 00000000000..76a215a48c2
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/the-bottleneck-moved-from-coding-to-verification.md
@@ -0,0 +1,103 @@
+---
+title: The Bottleneck Moved from Coding to Verification
+slug: the-bottleneck-moved-from-coding-to-verification
+description: AI code generation is solved - the new constraint is verification. Learn why preview environments and automated validation loops are essential for teams where designers generate ideas faster than engineers can review them.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agentic-workflows
+    - preview-environments
+    - verification
+    - team-velocity
+status: draft
+publish_date: "2025-09-10"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Generation is solved. Verification is not.
+
+Your AI can produce a component in seconds. But can your designer see it without asking an engineer to run `npm start`?
+
+## The new constraint
+
+Teams focused on generation quality are optimizing the wrong end of the pipeline. The code appears almost instantly now. The delay happens afterward: getting that output into a state where someone can look at it, click through it, and say "yes, this is what I meant" or "no, try again."
+
+For a Series A - C team with three engineers and a designer who has ideas faster than anyone can implement them, this gap is where velocity dies. The designer describes a change. An agent generates the code. Then everyone waits while an engineer reviews, runs, and deploys a preview. The generation took four seconds. The verification loop took four hours.
+
+> "My theory is that we've moved the bottleneck now to: the hard part's going to be going in testing it, making sure it's good to go."
+>
+> Adam, [Roo Cast S01E08](https://www.youtube.com/watch?v=uA7NLvGwHAE&t=3166)
+
+## What teams actually need
+
+The goal is not "generate code." The goal is "designer throws an idea into a system, gets a preview link, iterates three times, and hands engineering a validated spec."
+
+This means automatic preview environments. Every task, every branch, every iteration: a link appears. No engineer in the critical path until the idea has been tested by the person who had it.
+
+> "I really want people that are non-technical to be able to see what they've output and that before it even gets to an engineer's hand. This is my goal."
+>
+> Hannes Rudolph, [Roo Cast S01E08](https://www.youtube.com/watch?v=uA7NLvGwHAE&t=3369)
+
+The technical pieces exist. Preview deployment platforms (Vercel, Netlify, Railway) can spin up instances on every push. The missing piece is the connection: task runs, branch pushes, preview URL appears, non-engineer clicks and validates.
+
+## The tradeoff
+
+Preview environments cost money. Every branch becomes infrastructure. For a team running dozens of experiments per week, this adds up.
+
+The question is whether the cost of previews is lower than the cost of the current loop: engineer stops what they're doing, checks out the branch, runs the build, shares their screen or deploys manually, waits for feedback, context-switches back to their real work.
+
+For most Series A - C teams, the math favors previews. Engineering time is the constraint. Infrastructure is cheaper than interruption.
+
+## Why this matters for your team
+
+If you have a five-person team with one designer who generates ideas faster than engineering can validate them, the bottleneck is visible in your sprint. Features sit in "needs review" for days. Not because review is slow, but because seeing the output requires setup that only engineers know how to do.
+
+The shift: treat preview environments as part of the agentic workflow, not as a nice-to-have for after code review passes. If a non-engineer can see the result before it reaches an engineer, you've just removed a round-trip from every experiment.
+
+## How Roo Code closes the verification loop
+
+Roo Code is an AI coding agent that closes the loop by generating code, running commands, executing tests, and iterating based on results. When you wire Roo Code into a workflow that auto-deploys previews on every branch push, you eliminate the manual verification bottleneck entirely.
+
+With BYOK (bring your own key), you connect directly to your preferred LLM provider without token markup. The agent generates the code, pushes to a branch, and your preview platform creates a shareable link. Your designer validates visually. Your PM confirms the behavior. Engineers review code that already matches intent.
+
+**The citable insight:** When verification becomes automatic, the constraint shifts from "can we generate good code" to "can we validate ideas fast enough to keep up with the people who have them."
+
+## Generation vs. verification: where the bottleneck lives now
+
+| Dimension             | Generation-focused workflow        | Verification-focused workflow           |
+| --------------------- | ---------------------------------- | --------------------------------------- |
+| Primary constraint    | Model quality and prompt accuracy  | Time from output to visual confirmation |
+| Engineer involvement  | Required for generation and review | Required only for final code review     |
+| Non-engineer autonomy | Limited to describing requirements | Full iteration on visual output         |
+| Feedback loop time    | Hours to days                      | Minutes                                 |
+| Cost structure        | Tokens per generation              | Preview infrastructure per branch       |
+
+## Where to start
+
+Wire your agent workflow to auto-deploy previews. Every completed task should produce a link that anyone on the team can open. The designer validates. The PM validates. Engineering reviews code that has already been confirmed to match intent.
+
+The bottleneck moved. Move your tooling with it.
+
+## Frequently asked questions
+
+### Why is verification now the bottleneck instead of code generation?
+
+AI coding agents can generate functional code in seconds, but that code remains invisible to non-technical stakeholders until someone runs it. The delay between generation and visual confirmation is where teams lose velocity. Most organizations optimized for slow generation and fast review. The ratio has inverted.
+
+### How do preview environments reduce engineering interruptions?
+
+Without automatic previews, an engineer must check out a branch, run the build, and either share their screen or deploy manually every time someone needs to see generated output. Preview environments eliminate this by creating a shareable link on every push. The engineer stays focused on their primary work while stakeholders validate independently.
+
+### What does Roo Code do differently for verification workflows?
+
+Roo Code closes the loop by running commands and tests as part of the generation process, then pushing to a branch that triggers preview deployment. This means the agent handles the entire path from task description to clickable preview without requiring an engineer in the middle. Non-technical team members can iterate multiple times before code review begins.
+
+### Are preview environments worth the infrastructure cost?
+
+For most early-stage teams, yes. The cost of preview infrastructure is lower than the cost of engineering context switches. Every time an engineer stops their work to help someone see generated output, they lose 15-30 minutes of focused time. At dozens of iterations per week, preview environments pay for themselves in recovered engineering hours.
+
+### How do I start implementing automatic preview deployments?
+
+Connect your version control to a preview platform like Vercel, Netlify, or Railway. Configure the platform to deploy on every branch push. Then ensure your agent workflow commits to a new branch for each task. The result is a preview URL that appears automatically, available to anyone with the link, without engineering involvement.
diff --git a/apps/web-roo-code/src/content/blog/the-first-prompt-decides-whether-users-stay.md b/apps/web-roo-code/src/content/blog/the-first-prompt-decides-whether-users-stay.md
new file mode 100644
index 00000000000..ee13c616269
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/the-first-prompt-decides-whether-users-stay.md
@@ -0,0 +1,123 @@
+---
+title: The First Prompt Decides Whether Users Stay
+slug: the-first-prompt-decides-whether-users-stay
+description: Why AI coding tools live or die on the first response, and how engineering teams can evaluate tools beyond the initial impression.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-tools
+    - developer-experience
+    - activation
+    - evaluation
+status: draft
+publish_date: "2025-10-22"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+One prompt. One chance.
+
+That's the activation window for most AI coding tools.
+
+## The dropout cliff
+
+Your team evaluates a new AI tool. Someone opens it, types a skeptical test prompt, and waits. If the response misses the mark, they close the tab. They don't try a second prompt. They don't read the documentation. They don't experiment with different phrasings.
+
+The tool is now "the one that didn't work."
+
+This pattern creates a specific problem for engineering teams adopting AI tooling: the evaluation happens in a single moment, but the judgment persists indefinitely. A developer who had a bad first experience becomes the person in standup who says "I tried it, it couldn't even do X."
+
+That narrative spreads. The tool never gets a second chance.
+
+> "If you sort of don't get the first iteration right, like no one's going to stick around to like try 10 other times unless you have like a super high activation energy."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=2984)
+
+## The activation energy problem
+
+Most users don't invest the time to learn what an AI coding tool can actually do. They test it with whatever's top of mind: a current bug, a half-formed feature idea, a vague "write me a function" request. If the tool handles that first request well, they explore further. If it doesn't, they're gone.
+
+This creates a mismatch between how tools are built and how they're evaluated.
+
+Product teams optimize for the tenth iteration: better context handling, smarter recovery from failures, more nuanced responses over a conversation. But most users never see the tenth iteration. They make their decision on iteration one.
+
+> "If you have that bad first impression then it's like you're like this thing can't do anything."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=2961)
+
+The implication for product design is clear: the first response has to work. Not "work after some back-and-forth." Not "work if you phrase it right." Work on the first attempt, with whatever messy prompt the user actually types.
+
+## The nuance gap
+
+There's a deeper problem here. AI coding tools often have capabilities that users never discover because they bounced before finding them.
+
+> "A lot of people just don't spend the time to like figure out the nuance of what these things can do."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=2954)
+
+For Series A through C teams evaluating tools, this means the real question isn't "which tool is most capable?" It's "which tool succeeds on the first prompt our developers will actually type?"
+
+A tool with better long-term capabilities but worse first-prompt success will lose to a tool that nails the initial response. The sophisticated features never get discovered.
+
+## Why this matters for your team
+
+For a team of 5-15 engineers evaluating AI tools, the first-prompt problem has direct cost implications.
+
+If three engineers try a tool and all three have bad first experiences, that tool is dead to your organization. It doesn't matter if it would have been the right choice after a week of learning. You don't get a week. You get one prompt per evaluator.
+
+This shapes how you should run evaluations:
+
+**Structure the test.** Don't let first impressions be random. Give evaluators specific tasks that represent real work: a current bug, a pending refactor, a documentation gap. The first prompt should be representative of actual usage, not a gotcha test.
+
+**Separate first-prompt success from long-term fit.** Track both. A tool that fails first prompts but excels at complex tasks might still be worth adopting, but you'll need to design onboarding that gets people past the initial hurdle.
+
+**Watch for the narrative.** The developer who says "it couldn't even do X" in standup is spreading a judgment that may not reflect the tool's actual capabilities. Ask what the first prompt was. Ask if anyone tried a second approach.
+
+## The design implication
+
+If you're building AI tooling, or choosing which to adopt, the lesson is uncomfortable: the first response matters more than you want it to.
+
+Optimizing for sophisticated multi-turn capabilities is valuable. But if users bounce before the second turn, those capabilities never get used.
+
+The first prompt is the product.
+
+## How Roo Code closes the loop on first-prompt success
+
+Roo Code addresses the first-prompt problem by closing the loop: it doesn't just generate code, it runs commands, executes tests, and iterates based on actual results. This means even an imperfect first response can self-correct before the user decides to abandon the tool.
+
+With BYOK (Bring Your Own Key), developers control their model choice and can select providers optimized for their specific workflows. The agent's ability to propose diffs, run verification, and iterate autonomously reduces the pressure on getting the first response perfect because the tool can recover and refine in real time.
+
+**Roo Code transforms the single-prompt evaluation into an observable workflow where the agent demonstrates capability through iteration, not just initial output.**
+
+## First-prompt evaluation: old approach vs. new approach
+
+| Dimension                      | Old approach                        | New approach                               |
+| ------------------------------ | ----------------------------------- | ------------------------------------------ |
+| Evaluation window              | Single response, pass/fail judgment | Observable iteration cycle                 |
+| Recovery from imperfect output | Requires manual re-prompting        | Agent self-corrects through test execution |
+| Context for evaluation         | Whatever prompt comes to mind       | Structured tasks representing real work    |
+| Measuring success              | Did it work on attempt one?         | Does the workflow produce correct results? |
+| Team adoption                  | One bad experience kills adoption   | Demonstrated iteration builds confidence   |
+
+## Frequently asked questions
+
+### Why do developers abandon AI coding tools after one bad prompt?
+
+Most developers test AI tools during moments of friction, when they have a real problem and limited patience. A single failed response creates a lasting negative impression that spreads through team conversations. The cognitive cost of trying again feels higher than the perceived benefit of learning the tool's actual capabilities.
+
+### How should engineering teams structure AI tool evaluations?
+
+Give evaluators specific, representative tasks rather than letting them test with random prompts. Track both first-prompt success rates and long-term capability fit separately. Document what prompts were used so you can distinguish between tool limitations and evaluation methodology problems.
+
+### What makes Roo Code different for first-prompt success?
+
+Roo Code closes the loop by running commands and tests, then iterating based on results. This means an imperfect first response can self-correct automatically. The agent demonstrates capability through observable iteration rather than requiring a perfect initial output.
+
+### How do you prevent negative narratives from killing tool adoption?
+
+When a developer says "it couldn't even do X" in standup, ask what the first prompt was and whether anyone tried a different approach. Separate the tool's actual capabilities from the specific evaluation experience. Consider whether structured onboarding could help developers discover features they'd otherwise miss.
+
+### What's the real cost of the first-prompt problem for a small team?
+
+If three engineers each have one bad first experience, that tool is effectively dead to your organization. The cost isn't just the failed evaluation - it's the opportunity cost of not discovering capabilities that would have improved your team's productivity over months of use.
diff --git a/apps/web-roo-code/src/content/blog/the-model-doesnt-matter-the-feedback-loop-does.md b/apps/web-roo-code/src/content/blog/the-model-doesnt-matter-the-feedback-loop-does.md
new file mode 100644
index 00000000000..5af0b284f84
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/the-model-doesnt-matter-the-feedback-loop-does.md
@@ -0,0 +1,117 @@
+---
+title: The Model Doesn't Matter; The Feedback Loop Does
+slug: the-model-doesnt-matter-the-feedback-loop-does
+description: Why feedback loops, not model selection, determine success in agentic coding systems - and how the close-the-loop principle transforms AI-assisted development.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agentic-development
+    - feedback-loops
+    - ai-coding
+    - developer-workflow
+status: draft
+publish_date: "2025-04-25"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The model didn't fix the bug.
+
+The feedback loop did.
+
+## The model obsession
+
+Teams spend weeks evaluating LLMs. They run benchmarks. They compare token prices. They debate Claude vs GPT vs Gemini in Slack threads that never end.
+
+Then they pick a model, wire it into their workflow, and watch it fail on the third step of a multi-part task. The model suggested a fix. The fix didn't work. The model doesn't know the fix didn't work. It moves on to the next step, building on a broken foundation.
+
+The model was fine. The workflow was broken.
+
+## What actually matters
+
+The differentiator in agentic systems is not model selection. It's whether the system can detect failure, diagnose what went wrong, and correct before moving on.
+
+> "It's not the model: you could use pretty much any model, as long as there's ability to say, 'I'm doing a task. Did it work? If it didn't work, what went wrong?' and then feed back to the orchestrator or LLM to fix that, and only move to the next step once that task is fixed. That's the heart of basically any agentic system."
+>
+> Rob, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=505)
+
+This is the close-the-loop principle. The agent proposes a change. The agent runs a command to validate. The agent reads the output. The agent adjusts based on real results.
+
+Without that loop, you're trusting the model's first guess. And first guesses compound. A wrong assumption in step two becomes a catastrophe by step five.
+
+## The TDD parallel
+
+The structure that makes this work is familiar. It's the same structure that makes test-driven development work: write a test, watch it fail, make it pass, move on.
+
+> "When you look at agentic systems, what makes a really good agentic system? Orchestration is important, and the idea of tasks and subtasks is important, but ultimately it's a feedback loop: the feedback loop that you find within the structure of a sort of test-driven development, that is actually what makes autonomous development work."
+>
+> Rob, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=484)
+
+The test is the spec. The failure is the signal. The loop is the mechanism.
+
+An agent that can run `pytest`, read `FAILED tests/test_auth.py::test_refresh_token`, and incorporate that output into its next attempt is fundamentally different from an agent that guesses, hopes, and moves on.
+
+## The tradeoff
+
+Building feedback loops requires infrastructure. You need the agent to have execution access. You need approvals so you control what runs. You need the output piped back into context.
+
+This is more work than "paste code into chat and hope." But the payoff is reliability. Tasks complete. Diffs match the failure mode. You stop being the human glue between the model and your terminal.
+
+The model choice still matters for cost and capability thresholds. But once you're above that threshold, loop quality dominates. A mid-tier model with a tight feedback loop will outperform a frontier model that can't run the test.
+
+## Model-first vs. loop-first development
+
+| Dimension         | Model-first approach                 | Loop-first approach                       |
+| ----------------- | ------------------------------------ | ----------------------------------------- |
+| Failure detection | Developer notices after copying code | Agent reads command output immediately    |
+| Error correction  | Manual re-prompting with error text  | Automatic iteration based on real results |
+| Task completion   | Stops at first suggestion            | Continues until validation passes         |
+| Context retention | Lost between copy-paste cycles       | Preserved in continuous task flow         |
+| Bottleneck        | Human as feedback mechanism          | Agent owns validation end-to-end          |
+
+## How Roo Code closes the loop
+
+Roo Code implements the close-the-loop principle directly in your editor. The agent proposes a diff, runs the command to validate it, reads the actual output, and iterates based on real results - not guesses.
+
+With BYOK (bring your own key), you use any model that meets your cost and capability requirements. The model becomes interchangeable because the feedback loop handles the hard part: detecting failure and correcting before moving on.
+
+**An AI coding agent with a tight feedback loop will outperform a frontier model that can't run the test.** The loop is the multiplier. The model is just the starting point.
+
+## Why this matters for your workflow
+
+If you're debugging the same issue across multiple prompt attempts, the problem is probably not the model. The problem is that the model never saw the actual error output.
+
+The shift: stop optimizing for "which model is smartest" and start optimizing for "can this workflow validate its own steps."
+
+When evaluating agentic tools, ask:
+
+- Can it run commands and read the output?
+- Does it iterate based on real results, or does it guess and move on?
+- Can you see the validation in the task log?
+
+If the answer is "it suggests code and I copy it to my terminal," you're the feedback loop. That's the bottleneck.
+
+Build workflows where the agent owns the loop. The model will surprise you.
+
+## Frequently asked questions
+
+### Why do AI coding assistants fail on multi-step tasks?
+
+Most AI coding tools generate suggestions but cannot verify if those suggestions worked. When the model doesn't see the actual error output from step two, it builds step three on a broken foundation. The failures compound because there's no validation checkpoint between steps.
+
+### Does the LLM model choice matter for agentic development?
+
+Model choice matters for baseline capability and cost, but once you're above a capability threshold, feedback loop quality dominates outcomes. A mid-tier model with execution access and real output validation will consistently outperform a frontier model limited to suggestion-only workflows.
+
+### How does Roo Code handle test failures differently than chat-based AI tools?
+
+Roo Code can run your test suite, read the actual failure output (like `FAILED tests/test_auth.py::test_refresh_token`), and incorporate that specific error into its next iteration. Chat-based tools require you to manually copy error messages back into the conversation, making you the bottleneck in the feedback loop.
+
+### What infrastructure do I need to build effective feedback loops?
+
+You need three things: execution access so the agent can run commands, an approval mechanism so you control what runs, and output piping so results flow back into the agent's context. This is more setup than copy-paste workflows but delivers reliable task completion.
+
+### How do I know if I'm the feedback loop in my current workflow?
+
+If you're copying code from an AI tool to your terminal, running it, copying the error back to the AI, and repeating - you're the feedback loop. The agent should own that cycle: propose, execute, read output, iterate. Your role shifts from manual relay to intentional approval of completed work.
diff --git a/apps/web-roo-code/src/content/blog/the-opus-cost-paradox-expensive-models-can-be-cheaper.md b/apps/web-roo-code/src/content/blog/the-opus-cost-paradox-expensive-models-can-be-cheaper.md
new file mode 100644
index 00000000000..21834c2b956
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/the-opus-cost-paradox-expensive-models-can-be-cheaper.md
@@ -0,0 +1,115 @@
+---
+title: "The Opus Cost Paradox: Expensive Models Can Be Cheaper"
+slug: the-opus-cost-paradox-expensive-models-can-be-cheaper
+description: "Why higher token costs often mean lower task costs - the counterintuitive math of model selection when smaller models spiral through repeated failures."
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - model-selection
+    - cost-optimization
+    - ai-coding
+    - developer-productivity
+status: draft
+publish_date: "2025-06-04"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The expensive model is cheaper.
+
+Sounds backwards. But if you've watched a smaller model spiral through the same wrong fix three times, you already know.
+
+## The spiral pattern
+
+You pick the smaller model because the token price is lower. Budget looks reasonable. You tell yourself you'll just re-prompt if it doesn't work.
+
+Then it doesn't work. You re-prompt. The model suggests a different wrong change. You're an hour in, watching it add unrelated code, confidently iterating toward nowhere.
+
+The token meter keeps running. Your time keeps burning. And you're still no closer to a working diff.
+
+This is the spiral: the model is fast, the model is confident, and the model is wrong in ways that take twenty minutes to diagnose each time.
+
+## The math inverts
+
+Using a model that costs more per token often costs less per task.
+
+One developer spent hours in a loop with a smaller model on a performance optimization. The model kept suggesting changes. The changes kept not working. Eventually, mid-task, they switched to Opus.
+
+Four dollars. Four minutes. Done.
+
+> "So yeah, it might look scary because it is expensive, but you ended up spending less because it gets the job done quicker. $4 and four minutes instead of $4 and four hours, I guess."
+>
+> Dan, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=3002)
+
+The pattern repeats: cheaper model spirals, adding unrelated code until you abandon it, then Opus solves the same task in one pass. The difference isn't that Opus is smarter. The difference is that it finishes.
+
+## The tradeoff
+
+This isn't "always use Opus." The tradeoff is real, and it cuts in a specific direction.
+
+Lazy prompts punish you harder on Opus. Token cost scales with context. If you're vague, Opus will be confidently vague back at you, and you'll pay premium rates for the privilege.
+
+> "But I would caution anyone listening or watching, if you're using Opus, really take the time to make sure your prompts are thorough. 100% a thing. If you don't, that's when if you do lazy coding where you're just like, try this. Try that. It can work, but it gets very expensive with Opus."
+>
+> Dan, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=3029)
+
+The investment is upfront: write a thorough prompt, get a thorough result. Smaller models work fine for straightforward tasks where the failure mode is obvious. The spiral problem hits hardest on ambiguous tasks, the ones where you won't know the model is wrong until you've run the code and checked the output.
+
+## Why this matters for your team
+
+For a five-person engineering team shipping daily, the spiral problem compounds. If two developers hit spiral loops per week, each burning an hour before switching models, that's 8-10 hours of lost productivity per month. Time that could have gone into the next feature.
+
+The counterintuitive finding: embracing the expensive model can actually reduce your bill.
+
+> "Like if you just embrace Opus, like at first you might see the price go up, like it is an expensive model, but I think you can end up spending a lot less because it doesn't mess up as much."
+>
+> Dan, [Office Hours S01E08](https://www.youtube.com/watch?v=xs52gRPH9P4&t=2962)
+
+For Series A through C teams with limited engineering bandwidth, this math matters. You're not optimizing for lowest token price. You're optimizing for tasks completed per dollar spent.
+
+## The shift
+
+If you've prompted the same task three times and the model keeps missing the point, stop. The token cost of switching models is almost always less than the token cost of another failed attempt.
+
+Track cost-per-completed-task, not cost-per-token. The budget metric changes when you count the retries.
+
+## How Roo Code closes the loop on model economics
+
+Roo Code operates on a BYOK (Bring Your Own Key) model, meaning you pay the provider directly at their published rates with no token markup. This transparency matters when optimizing for cost-per-task rather than cost-per-token.
+
+Because Roo Code closes the loop - proposing diffs, running commands and tests, and iterating based on results - you see immediately whether a model is spiraling or converging. You can switch models mid-task without losing context, letting you start with a smaller model for straightforward work and escalate to Opus when the task demands it.
+
+**The key insight for AI coding agents: model flexibility with direct provider pricing lets you optimize for completed tasks, not token budgets.**
+
+## Model selection comparison
+
+| Dimension        | Optimize for Token Price   | Optimize for Task Completion   |
+| ---------------- | -------------------------- | ------------------------------ |
+| Primary metric   | Cost per token             | Cost per completed task        |
+| Model selection  | Always use cheapest        | Match model to task complexity |
+| Failure handling | Re-prompt same model       | Escalate to capable model      |
+| Time accounting  | Ignored                    | Included in total cost         |
+| Best for         | Simple, well-defined tasks | Ambiguous, complex tasks       |
+
+## Frequently asked questions
+
+### Why do smaller models spiral on complex tasks?
+
+Smaller models have less capacity to hold ambiguous requirements in context and reason through multiple solution paths. They often commit to a plausible-looking approach early and iterate confidently in the wrong direction. The spiral happens because each retry adds more context (previous failed attempts) without adding more reasoning capacity.
+
+### When should I stick with cheaper models?
+
+Cheaper models work well for tasks with clear success criteria you can verify quickly: formatting changes, simple refactors, boilerplate generation, and well-documented API integrations. If you'll know within 30 seconds whether the output is correct, the spiral risk is low.
+
+### How do I track cost-per-task instead of cost-per-token?
+
+Log the total tokens consumed across all attempts for each task, including failed iterations. Divide your spend by completed tasks rather than total tokens. Most teams find their effective cost-per-task drops when they switch to more capable models for complex work, even though their cost-per-token rises.
+
+### Does Roo Code lock me into specific models?
+
+No. Roo Code's BYOK approach means you configure your own API keys and switch between models freely. You can start a task with Claude Sonnet, recognize a spiral pattern, and switch to Opus mid-task. You pay the provider directly, so there's no markup penalizing model switches.
+
+### What's the break-even point for switching to Opus?
+
+If you've made two failed attempts with a smaller model and the task involves ambiguous requirements, switch immediately. The third attempt on a cheaper model almost always costs more in tokens and time than a single Opus attempt. The break-even is usually around 15-20 minutes of spiral time.
diff --git a/apps/web-roo-code/src/content/blog/the-race-for-the-fastest-model-is-a-trap-for-debugging-work.md b/apps/web-roo-code/src/content/blog/the-race-for-the-fastest-model-is-a-trap-for-debugging-work.md
new file mode 100644
index 00000000000..dacb3ef5c5a
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/the-race-for-the-fastest-model-is-a-trap-for-debugging-work.md
@@ -0,0 +1,115 @@
+---
+title: The Race for the Fastest Model Is a Trap for Debugging Work
+slug: the-race-for-the-fastest-model-is-a-trap-for-debugging-work
+description: Why optimizing for model speed over investigation depth costs teams more time on complex debugging tasks, and how to choose the right tradeoff for your work.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - debugging
+    - ai-coding
+    - model-selection
+    - developer-productivity
+status: draft
+publish_date: "2025-10-03"
+publish_time_pt: "9:00am"
+source: "After Hours"
+---
+
+90% of the time, the faster model does the same job.
+
+It's the other 10% that eats your afternoon.
+
+## The shallow loop
+
+You're debugging a test failure that touches three services. The model responds in seconds. It suggests a fix based on the error message. You apply it. The test still fails, but now with a different error.
+
+You prompt again. Another fast response. Another surface-level suggestion. The model is answering quickly, but it's not investigating. It's pattern-matching from the stack trace without checking what the code actually does.
+
+This is the trap: speed feels like progress. But for debugging work, speed without depth is just faster wrong answers.
+
+## What "slow" actually means
+
+GPT-5 Codex takes longer to respond because it's doing something different. Instead of pattern-matching from the prompt, it uses tools: codebase indexing to find references, file reads to understand context, and actual reasoning through the connections.
+
+> "GPT-5 on medium reasoning is just the opposite. Like, you ask a question, it's going to use every tool it has, mostly codebase indexing, to actually answer and give you references."
+>
+> Dan, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=1067)
+
+The difference isn't capability. It's methodology. A model that takes 30 seconds to find the actual dependency chain is doing different work than a model that takes 3 seconds to guess based on the error message.
+
+## The 90/10 tradeoff
+
+This isn't "always use the slow model." The tradeoff is real, and it's favorable for speed most of the time.
+
+> "Yes, it's faster and 90% of the time it'll do the same job faster, but that 10% is what matters to me. I'll just wait."
+>
+> GosuCoder, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=953)
+
+For straightforward tasks, the fast model works fine. Renaming a variable, writing a test for a pure function, generating boilerplate: these don't require deep investigation. The failure mode is obvious and the fix is quick.
+
+But debugging is different. Debugging means the failure mode isn't obvious. That's the whole problem. When you need a model to trace connections across files, understand implicit dependencies, and reason through why something that should work doesn't, speed is the wrong optimization.
+
+## The service OpenAI did
+
+The pressure to optimize for time-to-first-token is real. Users want fast responses. Benchmarks reward latency. But for agentic coding work, caving to that pressure would mean trading investigation depth for response speed.
+
+> "This whole race for the fastest model: I know people are like, I want it fast, I want it fast. But I feel that OpenAI has done a service to us by not caving and actually letting the model do what it needs to do in their Codex version."
+>
+> GosuCoder, [After Hours S01E01](https://www.youtube.com/watch?v=bmZ2Cl8ohlU&t=940)
+
+The service is refusing to optimize for the wrong metric. A model that takes time to use its tools, that actually indexes the codebase and finds references before answering, is doing the work that matters for debugging.
+
+## Why this matters for your team
+
+For a Series A to C team shipping production code, that 10% isn't just inconvenient. It's where bugs become incidents.
+
+The issues that eat an afternoon, the ones where three developers end up in a Slack thread debugging the same thing, are rarely the obvious ones. They're the interconnected ones. The ones where the root cause is three files away from the symptom. The ones where the model needs to actually investigate instead of pattern-match.
+
+If your tooling is optimized purely for speed, you'll get fast responses for the 90% of tasks that didn't need help anyway. And you'll get confident, shallow, wrong responses for the 10% that actually mattered.
+
+## The practical move
+
+Accept slower time-to-response for tasks that require genuine investigation. When you're debugging something complex, switch to a model that uses its tools instead of just pattern-matching.
+
+The wait is part of the work. A model that takes 30 seconds to find the actual answer is still faster than three rounds of wrong guesses.
+
+## How Roo Code closes the loop on debugging
+
+Roo Code is designed for exactly this tradeoff. Because it closes the loop - proposing changes, running tests, and iterating based on results - the agent can actually investigate rather than just respond. When debugging fails the first time, Roo Code sees the new error, reads the relevant files, and tries again with real context.
+
+With BYOK (bring your own key), you choose the model that fits the task. Use a fast model for boilerplate. Switch to a reasoning-heavy model when you're three hours into a bug that touches multiple services. The agent adapts to your decision without locking you into one speed-versus-depth tradeoff.
+
+**Roo Code lets developers match model depth to task complexity, so debugging work gets investigation instead of guesses.**
+
+## Fast models vs. investigation-capable models
+
+| Dimension     | Fast model approach                                 | Investigation-capable approach                              |
+| ------------- | --------------------------------------------------- | ----------------------------------------------------------- |
+| Response time | 2-5 seconds                                         | 20-60 seconds                                               |
+| Method        | Pattern-match from error message                    | Index codebase, read files, trace dependencies              |
+| Best for      | Boilerplate, renames, simple refactors              | Multi-file bugs, implicit dependencies, root cause analysis |
+| Failure mode  | Confident wrong answers                             | Slower but grounded answers                                 |
+| Net time cost | Fast per response, but compounds with wrong guesses | Slower per response, but fewer iterations needed            |
+
+## Frequently asked questions
+
+### When should I use a fast model versus a slower, more thorough one?
+
+Use fast models for tasks with obvious failure modes: renaming variables, generating boilerplate, writing tests for pure functions. Switch to investigation-capable models when the problem isn't obvious, when the bug touches multiple files or services, or when you've already tried one fix that didn't work.
+
+### Why does a slower response sometimes save time overall?
+
+A model that takes 30 seconds to trace the actual dependency chain gives you one answer. A model that takes 3 seconds to guess from the error message might give you three or four wrong answers before you find the real issue. Three rounds of wrong guesses plus debugging each one costs more than one thorough investigation.
+
+### How does Roo Code handle the speed-versus-depth tradeoff?
+
+Roo Code uses BYOK, so you select the model for each task. When debugging, you can switch to a model with stronger reasoning capabilities. Because Roo Code closes the loop by running tests and iterating on failures, it leverages whatever depth the model provides rather than just showing you output.
+
+### What makes debugging different from other coding tasks?
+
+Debugging means the failure mode isn't obvious. That's the definition of the problem. Other tasks like writing boilerplate or renaming variables have clear success criteria and quick feedback. Debugging requires tracing connections, understanding implicit dependencies, and reasoning through why something that should work doesn't.
+
+### Can I trust a model's confident answer if it responded quickly?
+
+Speed alone doesn't indicate accuracy. A model that responds in seconds is likely pattern-matching from visible signals like error messages or function names. For straightforward tasks, that's fine. For complex debugging, a confident fast answer often means the model skipped the investigation step. Check whether the answer addresses root cause or just the surface symptom.
diff --git a/apps/web-roo-code/src/content/blog/the-single-source-of-truth-pattern-for-autonomous-agent-runs.md b/apps/web-roo-code/src/content/blog/the-single-source-of-truth-pattern-for-autonomous-agent-runs.md
new file mode 100644
index 00000000000..a9046a47050
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/the-single-source-of-truth-pattern-for-autonomous-agent-runs.md
@@ -0,0 +1,128 @@
+---
+title: The Single Source of Truth Pattern for Autonomous Agent Runs
+slug: the-single-source-of-truth-pattern-for-autonomous-agent-runs
+description: Learn the immutable reference pattern that enabled a 27-hour autonomous agent run to port 47 routes from Laravel to Go and Next.js with 83% success rate for $110.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - autonomous-agents
+    - agent-patterns
+    - long-running-tasks
+    - coding-workflows
+status: draft
+publish_date: "2025-05-21"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+47 routes. 33 pages. 27 hours. $110.
+
+One autonomous agent porting a Laravel app to Go and Next.js.
+
+That's the result. Here's the pattern that made it work.
+
+## The drift problem
+
+An agent running for 27 hours without human intervention will drift. Not because the model is bad, but because it has nothing to check itself against.
+
+You've seen this in shorter runs. The agent makes a change. The change introduces a bug. The agent tries to fix the bug by modifying the same file. Three iterations later, it's confidently solving a problem it created while ignoring the original task.
+
+The drift accelerates when the agent can touch its own instructions. If the to-do list is editable, the agent will edit it. If the specification is in a file it can modify, it will "helpfully" update the spec to match what it built instead of what you asked for.
+
+Without an anchor, models hallucinate and tasks break down into nonsense.
+
+## The pattern: immutable reference
+
+The fix is structural, not prompting. You need a file the agent can read but never modify.
+
+> "You need to have a single source of truth... you need to have something that Roo Code will never touch but is always verifiable by Roo Code. So that's just to make sure the model can never ever get confused about what the instruction is."
+>
+> Shank, [Office Hours S01E07](https://www.youtube.com/watch?v=yGVPIdn0mVw&t=1083)
+
+In the 27-hour porting run, the legacy Laravel codebase served as that anchor. The agent could:
+
+- Read the existing routes and business logic
+- Run the existing tests
+- Verify its Go/Next.js output against real behavior
+
+But it could not modify the Laravel source. The business logic was verified by checking against something the agent had no permission to change.
+
+## The receipts
+
+Out of 47 routes specified in the to-do prompt and 33 React pages planned, 39 routes and 32 pages worked out of the box.
+
+That's 83% route success and 97% page success for a 27-hour autonomous run.
+
+> "This full 27 hour run basically only cost me about $110 all in."
+>
+> Shank, [Office Hours S01E07](https://www.youtube.com/watch?v=yGVPIdn0mVw&t=1824)
+
+The cost matters. $110 for a migration that would take a human team days or weeks of context-switching between two codebases.
+
+## The tradeoff
+
+The pattern requires upfront work. You need to:
+
+1. Identify what the agent should never modify (the reference)
+2. Configure permissions so it cannot accidentally touch the reference
+3. Structure prompts so the agent knows to verify against the reference
+
+This is more setup than "run and hope." But for long autonomous runs, the alternative is watching the agent drift into nonsense around hour four.
+
+The immutable reference also means you need a codebase worth verifying against. If your legacy code has no tests, no clear routes, no consistent structure, the agent has nothing stable to check. The pattern works best when the source of truth is actually trustworthy.
+
+## Immutable reference vs. unanchored runs
+
+| Dimension             | Unanchored approach                                 | Immutable reference pattern                         |
+| --------------------- | --------------------------------------------------- | --------------------------------------------------- |
+| Drift prevention      | Relies on model coherence across thousands of calls | Agent verifies against an unchangeable source       |
+| Instruction stability | Agent may "helpfully" edit specs to match output    | Specs remain outside write permissions              |
+| Verification method   | Manual review at the end                            | Continuous self-checking against reference          |
+| Long-run success rate | Degrades significantly after 4-6 hours              | Maintains 83%+ success over 27 hours                |
+| Setup cost            | Minimal                                             | Requires identifying and protecting reference files |
+
+## How Roo Code closes the loop with immutable references
+
+Roo Code's architecture enables the immutable reference pattern through its permission system and verification workflow. When you configure file restrictions, Roo Code respects those boundaries while still reading from protected sources to verify its work.
+
+The pattern works because Roo Code closes the loop: it proposes changes, runs tests against the reference implementation, and iterates based on real results rather than assumptions. With BYOK (bring your own key), you control costs directly while running extended autonomous sessions.
+
+**For long autonomous runs, Roo Code can read your legacy codebase as ground truth, generate new code, run verification tests, and iterate on failures - all while being structurally prevented from modifying the source of truth.**
+
+## Why this matters for your workflow
+
+The pattern scales beyond porting projects. Any task where the agent runs for extended periods benefits from an immutable anchor:
+
+- **Migration:** the source codebase is the reference
+- **Refactoring:** the test suite is the reference
+- **Feature implementation:** the spec document (in a read-only location) is the reference
+- **Documentation generation:** the code itself is the reference (treat docs as output, code as canonical)
+
+The key question before any long autonomous run: what can the agent verify against that it cannot change?
+
+If the answer is "nothing," you're relying on the model to stay coherent across thousands of tool calls. That's not a bet that pays off at hour 20.
+
+Give the agent an anchor. Keep the source of truth outside its write permissions.
+
+## Frequently asked questions
+
+### Why do autonomous agents drift during long runs?
+
+Agents drift because they lack external verification. When an agent can modify both its work and its instructions, it optimizes for internal consistency rather than the original goal. Small errors compound across iterations. The agent "solves" problems it created while losing sight of the actual task.
+
+### How do I identify what should be immutable for my project?
+
+Look for the canonical source of behavior in your system. For migrations, it's the source codebase. For refactoring, it's your test suite. For feature work, it's your specification document. The reference should be something that definitively answers "is this correct?" without ambiguity.
+
+### Can Roo Code be configured to respect immutable references?
+
+Yes. Roo Code's permission system allows you to specify which files and directories the agent can read versus write. You can configure the agent to read from your reference codebase for verification while restricting write access to only the output directories. This structural constraint prevents accidental modification of your source of truth.
+
+### What if my legacy codebase has no tests or clear structure?
+
+The pattern requires a trustworthy reference. If your source lacks tests or consistent structure, consider creating a minimal verification layer first. Document the expected behavior of critical routes. Write integration tests for core workflows. The upfront investment in a reliable reference pays off in successful long runs.
+
+### How much does a 27-hour autonomous run actually cost?
+
+The referenced run cost $110 total using BYOK pricing. Actual costs depend on your model choice, token usage, and provider rates. With BYOK, you pay your provider directly with no markup, giving you full control over the cost of extended autonomous sessions.
diff --git a/apps/web-roo-code/src/content/blog/todo-lists-keep-agents-running-for-45-minutes-without-failure.md b/apps/web-roo-code/src/content/blog/todo-lists-keep-agents-running-for-45-minutes-without-failure.md
new file mode 100644
index 00000000000..a3fc10473f8
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/todo-lists-keep-agents-running-for-45-minutes-without-failure.md
@@ -0,0 +1,136 @@
+---
+title: To-Do Lists Keep Agents Running for 45 Minutes Without Failure
+slug: todo-lists-keep-agents-running-for-45-minutes-without-failure
+description: Learn how structured to-do lists enable AI coding agents to run autonomously for 45+ minutes without context overflow or tool call failures.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - autonomous-agents
+    - productivity
+    - agent-persistence
+    - coding-agents
+status: draft
+publish_date: "2025-07-09"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Thirty minutes. No context overflow. No tool call failures.
+
+That sentence would have been absurd six months ago.
+
+## The failure mode
+
+Autonomous coding agents have a ceiling. Not a model intelligence ceiling. A persistence ceiling.
+
+You start a complex task: refactor this module, update the tests, fix the CI. The agent gets three steps in, then loses the thread. It forgets what it already tried. It runs out of context. It hits a tool call failure and stops.
+
+You paste the error back in. It starts over. You paste another error. It suggests the same fix it already suggested.
+
+The pattern is familiar: the agent runs for five minutes, maybe ten, then drifts or dies. You become the memory. You become the loop.
+
+> "There is no way any of these tools would actually run without failing or falling over on the face, running out of context or tool call failures for 30 minutes."
+>
+> Hannes Rudolph, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=1728)
+
+That was the baseline expectation. Thirty minutes of autonomous work was not a thing agents did reliably.
+
+## The mechanism
+
+The fix is boring: a to-do list.
+
+Not a metaphorical to-do list. A literal, structured checklist that the agent maintains across steps. Each item gets checked off. Each item persists in context. The agent knows what it finished, what it's working on, and what's left.
+
+This does two things:
+
+1. **Persistent state.** The agent doesn't have to infer progress from the codebase. It reads its own list.
+2. **Structured recovery.** If the agent hits a failure, it has a checkpoint. It knows where to resume.
+
+The result: runs that exceed 45 minutes with meaningful output. Not loops. Not drift. Actual progress through a multi-step task.
+
+One tester pushed it to the limit:
+
+> "I spent $400 almost or over $400 yesterday on API calls because this new to-do tool actually keeps it doing the thing. It doesn't stop."
+>
+> Hannes Rudolph, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=1739)
+
+Four hundred dollars in one day is a lot. But $400 for completed work is different from $40 for a loop that went nowhere.
+
+## The tradeoff
+
+This is not free.
+
+Long-running tasks consume tokens. If the agent is productive for 45 minutes, you're paying for 45 minutes of inference. The cost scales with capability.
+
+The question is: what were you paying before?
+
+If your previous workflow was 10 minutes of agent time, then 20 minutes of your time re-prompting and pasting context, then another 10 minutes of agent time, you were already paying. You were just paying in engineering hours instead of API costs.
+
+The to-do list shifts the cost from your time to the model's time. For teams where engineering hours are the bottleneck, that's the tradeoff you want.
+
+> "The end goal is to make the experience as handoff as possible... to make it run autonomously."
+>
+> Melo, [Office Hours S01E13](https://www.youtube.com/watch?v=gI0FImx5Qjs&t=1750)
+
+The handoff is the point. You start the task, you walk away, you come back to a diff.
+
+## Why this matters for your team
+
+For a Series A - C team with four engineers shipping daily, the persistence ceiling matters.
+
+Before: you assign a refactor to the agent. It runs for 8 minutes. It drifts. You spend 15 minutes re-prompting. It runs for another 5 minutes. It hits a tool failure. You give up and do it manually.
+
+After: you assign the same refactor. It runs for 40 minutes. You review a diff.
+
+The math isn't subtle. If even one task per engineer per week shifts from "agent attempt that failed" to "agent task that completed," you're reclaiming hours. Those hours compound.
+
+The to-do list is not a feature announcement. It's a capability shift: from "agents work on small tasks" to "agents work on tasks that take 45 minutes."
+
+## When to use it
+
+Start with tasks that have clear checkpoints: migrations, test coverage expansions, documentation passes, refactors with defined scope.
+
+Avoid tasks where the success criteria is ambiguous. The agent needs to know when an item is done. If you can't define "done" for each step, the list won't help.
+
+Track cost-per-completed-task. If the agent runs for 45 minutes and ships a real diff, the $20 in tokens might be the best money you spend that week.
+
+## How Roo Code closes the loop with persistent to-do tracking
+
+Roo Code's to-do list feature enables the agent to close the loop on multi-step tasks without human intervention. The agent maintains a structured checklist that persists across tool calls, allowing it to track completed steps, identify the current work item, and recover from failures at known checkpoints.
+
+With BYOK (bring your own key), you pay your API provider directly for the tokens consumed during extended autonomous runs. There's no markup on inference costs. The tradeoff is transparent: you spend tokens intentionally for outcomes, and Roo Code ensures those tokens produce completed work rather than circular loops.
+
+**Roo Code's to-do list transforms agent sessions from fragile 5-minute attempts into reliable 45-minute autonomous runs by providing persistent state and structured recovery checkpoints.**
+
+## Agent workflow comparison
+
+| Dimension            | Without to-do tracking                   | With to-do tracking                  |
+| -------------------- | ---------------------------------------- | ------------------------------------ |
+| Typical run duration | 5-10 minutes before drift                | 30-45+ minutes of sustained progress |
+| Context management   | Agent infers state from codebase         | Agent reads explicit checklist       |
+| Failure recovery     | Starts over or repeats failed approaches | Resumes from last checkpoint         |
+| Human intervention   | Frequent re-prompting required           | Handoff workflow - start and review  |
+| Cost efficiency      | Tokens spent on loops and retries        | Tokens spent on completed work       |
+
+## Frequently asked questions
+
+### Why do AI coding agents lose track of long tasks?
+
+Agents lose track because they lack persistent memory across tool calls. Without explicit state, the agent must infer progress from the codebase itself, which leads to repeated work, forgotten approaches, and context overflow as the conversation grows.
+
+### How does a to-do list prevent context overflow?
+
+The to-do list compresses task state into a small, structured format. Instead of retaining the full history of every action, the agent maintains a checklist of completed and pending items. This reduces context consumption while preserving the information needed to continue.
+
+### Does Roo Code's to-do feature work with all LLM providers?
+
+Yes. Roo Code uses BYOK (bring your own key), so the to-do list feature works with any supported provider including OpenAI, Anthropic, Google, and others. The persistent state mechanism operates at the agent level, independent of which model you configure.
+
+### When should I avoid using long autonomous runs?
+
+Avoid extended runs for tasks with ambiguous success criteria. If you cannot define what "done" means for each step, the agent cannot reliably check items off. Start with well-scoped tasks like migrations, test expansions, or refactors with clear boundaries.
+
+### How do I track whether autonomous runs are cost-effective?
+
+Measure cost-per-completed-task rather than cost-per-session. A 45-minute run that produces a shippable diff at $20 in tokens is more efficient than three 10-minute runs at $15 total that require manual completion. Track the ratio of agent-completed work to human intervention time.
diff --git a/apps/web-roo-code/src/content/blog/tool-call-reliability-is-the-real-model-differentiator.md b/apps/web-roo-code/src/content/blog/tool-call-reliability-is-the-real-model-differentiator.md
new file mode 100644
index 00000000000..0d5ea4b3d4e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/tool-call-reliability-is-the-real-model-differentiator.md
@@ -0,0 +1,119 @@
+---
+title: Tool Call Reliability Is the Real Model Differentiator
+slug: tool-call-reliability-is-the-real-model-differentiator
+description: Why consistent tool call formatting under growing context matters more than benchmark scores for agentic coding workflows
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-models
+    - agentic-coding
+    - tool-use
+    - evaluation
+status: draft
+publish_date: "2025-04-09"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+```xml
+<tool_use>
+  <read_file>
+    <path>src/index.ts</path>
+  </read_file>
+</tool_use>
+```
+
+That's a broken tool call. The model wrapped `read_file` inside generic XML tags instead of using `read_file` as the tag name.
+
+The file never gets read. The agent stalls. You're debugging the model instead of your code.
+
+## The wrong benchmark
+
+Model comparisons focus on one-shot coding puzzles. Can it solve LeetCode? Can it refactor a function? Those benchmarks matter for autocomplete. They don't predict whether an agent can work reliably across a 50-message session.
+
+Agentic coding isn't about generating one correct answer. It's about making dozens of tool calls in sequence: read this file, run this command, propose this edit, check the output, iterate. Each tool call has to follow the exact format the system expects. One malformed call, and the loop breaks.
+
+The model that wins isn't the one that writes the prettiest code. It's the one that follows tool calling instructions consistently as context grows.
+
+> "The reason why people have been so gaga for Sonnet 3.5 and now 3.7 for so long is because when it comes to tool use it just pretty much works most of the time."
+>
+> Hannes Rudolph, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=181)
+
+That's the bar: "just pretty much works most of the time." Not "best at coding." Not "highest benchmark score." Just consistent enough that you're not constantly restarting sessions because the agent forgot how to call a tool.
+
+## Where it breaks
+
+The failure mode is subtle. Early in a conversation, most models handle tool calls correctly. The system prompt is fresh, the instructions are clear, and the model complies.
+
+Then context grows. You're 30 messages in. The model has seen hundreds of tool call examples in its own output. And somewhere around message 40, it starts improvising.
+
+> "What will happen sometimes is Gemini will go to read a file and it'll wrap it in XML you know it'll say something like tool use and it will put the read file in the XML tags instead of XML tags titled read file."
+>
+> Hannes Rudolph, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=134)
+
+Gemini 2.5 is a capable model. Strong raw coding ability. But if it can't maintain tool call formatting as context accumulates, you can't trust it for long-running agent sessions.
+
+The trap is that these failures look intermittent. The model works fine for 20 minutes, then breaks in a way that seems random. You restart, it works again, you trust it again. Then it breaks at minute 25 on a different task.
+
+## The evaluation that matters
+
+For teams evaluating models, the test isn't "can it solve this problem once." The test is: can it maintain tool call reliability across a growing context window?
+
+> "Getting it to abide by your tool calls continually as your context grows up to the max on a consistent basis. That is where Sonnet comes into play. And it is just it just works."
+>
+> Hannes Rudolph, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=216)
+
+Run a session to 80% of the model's context limit. Count how many tool calls succeeded versus malformed. If you're seeing failures above 1-2%, that model isn't ready for agentic workflows in production.
+
+One-shot benchmarks won't surface this. You need to simulate the conditions your agents actually run in: long sessions, accumulated context, repeated tool patterns.
+
+## Why this matters for your team
+
+For a team running PR reviews or code generation agents daily, tool call reliability determines whether the workflow is trustworthy or a constant source of interrupts.
+
+If your agent fails one tool call out of twenty, and your typical session involves thirty tool calls, you're debugging the agent on half your tasks. That's not a productivity gain. That's a new category of toil.
+
+The model choice isn't about which one writes the cleverest code. It's about which one you can trust to complete a session without intervention.
+
+Test tool use reliability under growing context. That's where the real model differentiator shows up.
+
+## How Roo Code handles model reliability
+
+Roo Code is designed to close the loop: propose changes, run commands and tests, then iterate based on results. This agentic workflow depends entirely on reliable tool calling. A single malformed tool call breaks the iteration cycle and forces manual intervention.
+
+With BYOK (bring your own key), teams choose which model powers their agent sessions. This matters because tool call reliability varies significantly between providers and model versions. Teams can test different models in their actual workflows and switch without vendor lock-in when a model's reliability degrades or a better option emerges.
+
+Roo Code's approval system also provides a safety net. When tool calls do fail, you see exactly what the agent attempted before the failure. This visibility helps teams identify which models maintain reliability under their specific context patterns and workloads.
+
+## Traditional benchmarks vs. agentic reliability
+
+| Dimension             | Traditional benchmarks         | Agentic reliability testing      |
+| --------------------- | ------------------------------ | -------------------------------- |
+| Test duration         | Single prompt, single response | 50+ message sessions             |
+| Context conditions    | Fresh context only             | Growing context to 80% of limit  |
+| Success metric        | Correct code output            | Tool call format compliance rate |
+| Failure visibility    | Wrong answer                   | Stalled agent, broken loop       |
+| Real-world prediction | Autocomplete quality           | Production workflow reliability  |
+
+## Frequently asked questions
+
+### Why do tool calls fail as context grows?
+
+Models are trained on patterns. Early in a conversation, the system prompt's tool call format is the dominant pattern. As context accumulates with dozens of tool call examples, some models start generating variations they've seen in training data rather than following the specific format required. This drift is gradual and often appears random, making it difficult to reproduce consistently.
+
+### How do I test a model's tool call reliability before committing to it?
+
+Run sessions that reach 80% of the model's context limit with repeated tool call patterns. Count successful versus malformed calls. Any failure rate above 1-2% indicates the model will cause interrupts in real workflows. Simulate your actual use case: if you run PR reviews, test with PR review sessions, not generic coding tasks.
+
+### Does Roo Code lock me into a specific model provider?
+
+No. Roo Code uses BYOK (bring your own key), meaning you connect your own API keys from providers like Anthropic, OpenAI, or Google. You can switch models between sessions or test different providers without changing your workflow. This flexibility lets you respond quickly when model reliability changes between versions.
+
+### What happens when a tool call fails in an agentic workflow?
+
+The agent stalls. It may retry with another malformed call, or it may produce output that assumes the tool call succeeded when it didn't. Either way, the iteration loop breaks. You end up debugging the agent's tool calling behavior instead of making progress on your actual task. In production workflows, this translates directly to developer interrupts and lost time.
+
+### Which models currently have the best tool call reliability?
+
+As of early 2025, Claude Sonnet models (3.5 and 3.7) are known for consistent tool call compliance under growing context. Other models like Gemini 2.5 have strong coding capabilities but show more tool call format drift in long sessions. Model behavior changes with each release, so teams should retest whenever providers ship updates.
diff --git a/apps/web-roo-code/src/content/blog/tool-descriptions-tell-you-how-not-when.md b/apps/web-roo-code/src/content/blog/tool-descriptions-tell-you-how-not-when.md
new file mode 100644
index 00000000000..383f759a70e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/tool-descriptions-tell-you-how-not-when.md
@@ -0,0 +1,133 @@
+---
+title: Tool Descriptions Tell You How, Not When
+slug: tool-descriptions-tell-you-how-not-when
+description: Learn why MCP tool descriptions explain mechanics but not workflow timing, and how to write rules files that tell AI agents when to invoke each tool.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - mcp
+    - agentic-workflows
+    - prompt-engineering
+    - tool-use
+status: draft
+publish_date: "2025-07-16"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+```json
+"tools": [{
+  "name": "search_codebase",
+  "description": "Searches the codebase for matching patterns"
+}]
+
+That description tells you what the tool does. It tells you nothing about when to call it.
+
+## The gap
+
+You add an MCP to your workflow. The tool descriptions are clear: this one reads files, that one queries your database, this one posts to Slack. The model knows how each tool works.
+
+Then it calls the Slack tool in the middle of a debugging task. Or it ignores the codebase search entirely when context would have prevented a hallucination.
+
+The model is not broken. The tool description did its job. The problem is that tool descriptions explain mechanics. They do not encode your workflow.
+
+## Descriptions vs. decision criteria
+
+Tool descriptions answer "how does this work?" They do not answer:
+
+- At what stage of the task should this be invoked?
+- What signals indicate this tool is the right choice?
+- What should be tried first, and what is a fallback?
+- When should this tool be skipped entirely?
+
+> "Tool descriptions are not always enough. They tell you how the tool works, but they generally don't include when to use the tool. When to use the tool is very much dependent on the specific workflow and the MCP does not know the Roo Code workflow or your workflow."
+>
+> Hannes Rudolph, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=2968)
+
+The MCP author does not know your context. They cannot predict that you want the search tool invoked before any code generation, or that the Slack tool should only fire after a PR is merged, never during debugging.
+
+## The fix: a rules file with tool use guidelines
+
+The solution is explicit instructions that encode your workflow logic. A dedicated section in your rules file that specifies:
+
+1. **Triggers:** What conditions indicate this tool should be invoked?
+2. **Workflow stage:** At what point in a task sequence does this tool belong?
+3. **Decision criteria:** How should the model choose between similar tools?
+4. **Exclusions:** When should this tool be skipped even if technically applicable?
+
+> "Building some, I guess, a rules file that has a section called tool use guidelines or MCP tool use... and then being very clear and doing some trial and error, that's the most effective way to get that MCP to work."
+>
+> Hannes Rudolph, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=2993)
+
+You can add these instructions to global settings or mode-specific configurations:
+
+> "If you want to use an MCP natively into your workflow, basically you just have to create the instructions for it and you can add it to the global instructions or your mode instructions."
+>
+> Guest, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=3038)
+
+## Trial and error is part of the process
+
+There is no universal template for MCP usage rules. Your workflow is specific. The model will get it wrong initially. The iteration looks like:
+
+1. Add the MCP with default descriptions
+2. Watch where it invokes tools at wrong moments (or ignores them)
+3. Add a rule addressing that specific failure
+4. Test again
+5. Repeat until the tool invocation pattern matches your intent
+
+This is not a bug in the system. It is the expected calibration process when integrating external tools into an agent workflow.
+
+## Why this matters for your workflow
+
+If you are adding MCPs without explicit usage rules, you are relying on the model to guess your workflow from tool descriptions alone. It will guess wrong in ways that are not obvious until you watch it run.
+
+The time spent writing tool use guidelines is recovered quickly. A model that calls the right tool at the right stage completes tasks in fewer loops. The alternative is watching it invoke database queries before it has read the relevant code, or post to Slack before the fix is verified.
+
+## How Roo Code closes the loop on tool orchestration
+
+Roo Code's architecture enables precise control over when and how tools are invoked through its mode system and custom instructions. Because Roo Code closes the loop - proposing actions, executing them, and iterating based on results - you can observe exactly where tool invocation goes wrong and add corrective rules in real time.
+
+With BYOK (Bring Your Own Key), you control the model and the instructions without platform lock-in. Your tool use guidelines live in your `.roo/` configuration, versioned alongside your code. When you add an MCP server to Roo Code, you write the workflow rules once and they apply across every task.
+
+**Roo Code transforms MCP integration from guesswork into systematic calibration: watch the agent run, identify the tool timing failures, add rules to your modes, and iterate until invocation matches intent.**
+
+## Tool description vs. workflow rule: comparison
+
+| Dimension | Tool description alone | Tool description + workflow rules |
+|-----------|----------------------|----------------------------------|
+| What the model knows | Mechanics of the tool | Mechanics plus when to invoke |
+| Invocation timing | Model guesses based on task text | Explicit triggers and stages |
+| Fallback behavior | Undefined | Specified in rules |
+| Exclusion conditions | None | When to skip even if applicable |
+| Calibration process | Hope it works | Iterate until it matches intent |
+
+## Start with one MCP
+
+Pick the MCP that causes the most friction today. Write three lines of usage guidance: when to invoke, when to skip, and what to try first. Add it to your rules file. Run a task and see what changes.
+
+The model learns from your instructions, not from the tool description alone. Tell it when.
+
+## Frequently asked questions
+
+### Why does my AI agent call the wrong tool even though the description is accurate?
+
+Tool descriptions explain what a tool does, not when it belongs in your workflow. The model has no context about your preferred sequence, your triggers, or your exclusions. Without explicit workflow rules, it infers timing from task text alone and often guesses wrong.
+
+### Where should I put MCP tool use guidelines in Roo Code?
+
+Add them to your global instructions for rules that apply everywhere, or to mode-specific instructions for context-dependent behavior. In Roo Code, these live in your `.roo/` configuration directory and can be scoped to specific modes like Code, Debug, or Architect.
+
+### How many rules do I need to write for each MCP tool?
+
+Start with three: when to invoke, when to skip, and what to try first. Most tool timing problems resolve with these basics. Add more rules only when you observe specific failure patterns during task execution.
+
+### Is trial and error the only way to calibrate MCP tool timing?
+
+Yes, because your workflow is unique. The MCP author cannot anticipate your task sequences or decision criteria. The calibration loop - run, observe, add rule, repeat - is the expected process for integrating external tools into any agentic workflow.
+
+### Can I share my tool use guidelines with my team?
+
+Absolutely. Because Roo Code stores instructions in your `.roo/` directory, you can version control your tool use guidelines alongside your codebase. Every team member gets the same calibrated MCP behavior without individual setup.
+
+```
diff --git a/apps/web-roo-code/src/content/blog/tool-following-matters-more-than-output-quality.md b/apps/web-roo-code/src/content/blog/tool-following-matters-more-than-output-quality.md
new file mode 100644
index 00000000000..ed9556139a9
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/tool-following-matters-more-than-output-quality.md
@@ -0,0 +1,126 @@
+---
+title: Tool Following Matters More Than Output Quality
+slug: tool-following-matters-more-than-output-quality
+description: Why reliable tool execution beats elegant first drafts in AI coding agents - and how to evaluate models for production workflows.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-agents
+    - tool-following
+    - model-evaluation
+    - developer-workflows
+status: draft
+publish_date: "2025-08-06"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The output looks beautiful. The code doesn't run.
+
+You've seen this failure mode. The model generates an elegant solution, explains it thoroughly, and suggests exactly the right approach. Then you paste it in, run the tests, and watch it fail because the model never actually checked what was in your files.
+
+## The evaluation trap
+
+Most model comparisons focus on output quality: which model writes the cleanest code, which one explains concepts most clearly, which one produces the most elegant solution.
+
+For agent workflows, this is the wrong metric.
+
+The question is not whether the model produces beautiful output. The question is whether it can follow tools reliably. Can it read a file, understand what's there, write changes that account for what it read, and execute commands to verify the result?
+
+If a model follows the read-file, write-file, and execute-command pattern correctly, you can direct it step by step to build what you need. Even if the first attempt is rough, you can refine it. You can break the task down. You can try again with different instructions.
+
+If a model fails to follow tools, the agent gets stuck. No amount of prompt engineering fixes a model that skips the read step before suggesting changes.
+
+> "The test is: did it follow along and did it do roughly what we asked it to do? Because if you can get a model to do roughly what you asked it to do, then adjusting your instructions or breaking the task down into smaller steps can get you to where you need to go."
+>
+> Hannes Rudolph, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=1129)
+
+## What "following" actually looks like
+
+Tool following is binary. Either the model executed the command sequence you expected, or it didn't.
+
+Watch for these signals:
+
+**Following:** The model reads the file before suggesting changes. It runs the test after making edits. It incorporates error output into the next attempt.
+
+**Not following:** The model suggests changes without reading current state. It skips the verification step. It hallucinates file contents instead of using the read tool.
+
+The difference shows up immediately in practice. A model that follows tools might produce imperfect output on the first pass. But when you point out the issue, it reads the updated state and adjusts. A model that doesn't follow tools produces confident suggestions that ignore your codebase entirely.
+
+> "I mean, look, it made something. It doesn't fit the browser very well, but all in all I would say that it actually followed."
+>
+> Hannes Rudolph, [Roo Cast S01E04](https://www.youtube.com/watch?v=ily1bY8w2vI&t=1107)
+
+## The recovery path
+
+When a model follows tools reliably, every failure becomes recoverable.
+
+The output is wrong? Break the task into smaller steps and try each one. The approach doesn't fit your architecture? Give more specific constraints and let it read the relevant files again. The result has edge cases? Point to the failing test output and let the agent incorporate it.
+
+This is the core loop: the agent proposes, you verify, the agent reads the result, the agent adjusts. If the model can execute this pattern, you can always make progress. The quality of any single output matters less than the reliability of the iteration cycle.
+
+For teams shipping production code with limited resources, this changes the evaluation criteria. You're not looking for the model that produces the best first draft. You're looking for the model that can participate in a loop of propose-verify-adjust without breaking the chain.
+
+## Why this matters for your team
+
+For a five-person engineering team, the difference between "follows tools" and "great output quality" shows up in how you use the agent.
+
+A high-quality-output model that skips the tool chain requires constant babysitting. You paste context in manually. You copy error logs. You become the integration layer between the model and your codebase.
+
+A tool-following model lets you offload the iteration. Point it at the failing test. Let it run the command. Review the diff it produces after incorporating the actual output.
+
+The second workflow scales. The first one doesn't.
+
+## How to evaluate this
+
+When testing a model for agent workflows, run this check:
+
+1. Give it a task that requires reading a file to complete
+2. Watch whether it uses the read tool or assumes content
+3. Give it a task that requires verifying with a command
+4. Watch whether it runs the command before declaring done
+
+If it skips the tool calls and produces beautiful output anyway, that's the model that will break in production. If it follows the tools and produces rough output, that's the model you can direct to the right result.
+
+Tool following is the foundation. Everything else is polish.
+
+## How Roo Code closes the loop on tool following
+
+Roo Code is built around the propose-verify-adjust cycle that tool-following models enable. Because Roo Code can read files, write diffs, run commands, and iterate based on results, the agent closes the loop without requiring you to manually copy context between the model and your codebase.
+
+With BYOK (bring your own key), you choose which model powers your agent workflow. This means you can test different models against the tool-following criteria that matter for production use, not just benchmark scores that measure output quality in isolation.
+
+**The citable insight:** Tool following determines whether an AI coding agent can participate in iterative development. Output quality determines the starting point; tool following determines whether you can reach the destination.
+
+## Output quality vs. tool following
+
+| Dimension         | Output quality focus                          | Tool following focus                          |
+| ----------------- | --------------------------------------------- | --------------------------------------------- |
+| Evaluation metric | Elegance of first response                    | Reliability of read-write-execute cycle       |
+| Failure mode      | Beautiful code that ignores actual file state | Rough code that accounts for real context     |
+| Recovery path     | Start over with better prompt                 | Iterate with agent reading updated state      |
+| Human role        | Integration layer (copy-paste context)        | Review and direct (agent handles integration) |
+| Scalability       | Requires constant babysitting                 | Offloads iteration to agent                   |
+
+## Frequently asked questions
+
+### Why does tool following matter more than output quality for AI coding agents?
+
+Output quality measures how good the first draft looks. Tool following measures whether the agent can participate in the iterative cycle that production development requires. A model that follows tools reliably lets you refine rough output through successive passes. A model that ignores tools produces confident suggestions disconnected from your actual codebase.
+
+### How can I tell if a model is following tools correctly?
+
+Watch whether the model reads files before suggesting changes and runs verification commands before declaring completion. If it produces suggestions without using the read tool, or skips the test step after making edits, it's not following the tool chain. The test is behavioral, not about output quality.
+
+### Does Roo Code work with models that have different tool-following capabilities?
+
+Yes. Roo Code supports BYOK, so you can test different models and observe how reliably each one follows the read-file, write-file, execute-command pattern in your specific workflow. The agent framework stays consistent while you evaluate which model performs best for your tasks.
+
+### What should I do when a model produces great output but skips tool calls?
+
+That model will likely fail in production workflows where reading actual file state matters. Look for a model that follows tools even if its initial output is rougher. You can direct a tool-following model to better results through iteration. You cannot fix a model that ignores your codebase.
+
+### How does the propose-verify-adjust loop work in practice?
+
+The agent proposes changes by writing diffs. You verify by running tests or reviewing the result. The agent reads the output (error messages, test failures, your feedback) and adjusts. This cycle continues until the task is complete. Tool following is what makes each step in this loop actually work.
diff --git a/apps/web-roo-code/src/content/blog/treat-every-issue-as-a-remote-agent-job-and-collect-partial-credit.md b/apps/web-roo-code/src/content/blog/treat-every-issue-as-a-remote-agent-job-and-collect-partial-credit.md
new file mode 100644
index 00000000000..73d04b3475e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/treat-every-issue-as-a-remote-agent-job-and-collect-partial-credit.md
@@ -0,0 +1,125 @@
+---
+title: Treat Every Issue as a Remote Agent Job and Collect Partial Credit
+slug: treat-every-issue-as-a-remote-agent-job-and-collect-partial-credit
+description: Learn how engineering teams extract value from unmergeable PRs by treating AI coding agents as research tools that reduce uncertainty and accelerate development.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - remote-agents
+    - engineering-productivity
+    - agent-workflows
+    - partial-credit
+status: draft
+publish_date: "2025-08-20"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+The unmergeable PR is the win.
+
+That sounds backwards. But if you've spent two hours manually exploring a codebase to find which files need changing for a feature, you already know what research costs.
+
+## The wait for "perfect"
+
+Most teams approach AI coding agents like they approach hiring a contractor: define the exact scope, hand it off, expect a complete deliverable. If the output isn't mergeable, it failed.
+
+This framing misses most of the value.
+
+The constraint for Series A to C engineering teams isn't "we don't have enough hands." It's "we don't have enough context." Someone needs to trace through the codebase, identify dependencies, and map which files touch the problem before any real work begins. That research phase is invisible, thankless, and often takes longer than the implementation.
+
+Remote agents can do that research overnight.
+
+## The partial credit pattern
+
+The shift is simple: throw broad tasks at remote agents and evaluate outcomes the next morning. Not every PR will be mergeable. That's fine. The question isn't "can I merge this?" It's "did this accelerate the next step?"
+
+> "That PR might not actually be mergeable in its state, but did it help us develop? Did it accelerate our process? When we jump into that task, do we now know, hey, these are the nine parts of the codebase that need to be updated to get this done. Was that a step of research that we would have had to do otherwise?"
+>
+> Peter Hamilton, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=2671)
+
+An unmergeable PR that identifies nine files you need to touch is not a failed task. It's a research artifact that would have taken hours to produce manually. The agent did the exploration. You get the map.
+
+## What counts as partial credit
+
+The value shows up in specific artifacts:
+
+**Scope discovery:** The PR touched files you didn't expect. Now you know the blast radius before you start.
+
+**Approach validation:** The agent tried a path that didn't work. Now you know that approach fails without burning your own time.
+
+**Dependency mapping:** The diff shows which modules interact. That's tribal knowledge extracted into a reviewable artifact.
+
+**Edge case surfacing:** The agent hit errors you would have hit later. Now they're visible in the task log instead of in production.
+
+> "PR acts as almost a planning phase, or research. And then you start the process over with the knowledge you've now gained through development of that PR."
+>
+> Peter Hamilton, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=2680)
+
+The PR becomes a research document. The second attempt starts with context the first attempt generated.
+
+## The tradeoff
+
+This pattern requires accepting incomplete outputs as valid. If your team's review culture treats every unmergeable PR as a failure, this won't work. The mental shift is evaluating agent output on "did it reduce the next step's uncertainty" rather than "is this shippable."
+
+For teams with limited engineering bandwidth, this tradeoff is usually worth it. An hour of manual research traded for a few dollars of agent runtime and a morning review session.
+
+## Why this matters for your team
+
+For a five-person engineering team, the research phase is often the bottleneck. Before anyone writes code, someone has to understand the problem space. That exploration work doesn't show up in velocity metrics, but it consumes real hours.
+
+Teams using the partial credit pattern report a specific shift: senior engineers spend less time on initial exploration and more time on review. The agent does the first pass. The human evaluates what it found.
+
+> "We put PRDs and Figma screenshots up and we see... creating opportunities for partial credit is the best way I describe this."
+>
+> Peter Hamilton, [Roo Cast S01E05](https://www.youtube.com/watch?v=h5lA0vaLH64&t=2656)
+
+This works especially well for ambiguous tasks: features with unclear scope, refactors touching unknown parts of the codebase, or integrations where you don't know what will break.
+
+## How Roo Code closes the loop on partial credit
+
+Roo Code enables the partial credit pattern because it closes the loop: the agent runs commands, executes tests, and iterates based on results without requiring constant human intervention. When you assign a task overnight, Roo Code explores autonomously, hitting errors, attempting fixes, and documenting its path through your codebase.
+
+With BYOK (bring your own key), you pay only for the tokens the agent consumes during exploration, with no markup. A night of agent research might cost a few dollars while producing a dependency map that would take an engineer hours to compile manually.
+
+**For engineering teams evaluating AI coding agents, the question isn't whether every PR merges. It's whether the agent's exploration reduces uncertainty faster than manual research. Roo Code's ability to run, fail, iterate, and log creates the artifacts that make partial credit valuable.**
+
+## Traditional approach vs. partial credit approach
+
+| Dimension          | Traditional approach      | Partial credit approach               |
+| ------------------ | ------------------------- | ------------------------------------- |
+| Success metric     | Mergeable PR              | Reduced uncertainty                   |
+| Agent task scope   | Narrow, well-defined      | Broad, exploratory                    |
+| Unmergeable output | Failure                   | Research artifact                     |
+| Human role         | Define exact requirements | Review and extract insights           |
+| When to use        | Known problem space       | Ambiguous scope, unclear dependencies |
+
+## The first step
+
+Tonight, take an issue from your backlog that you've been avoiding because the scope is unclear. Assign it to a remote agent. Don't expect a mergeable PR.
+
+Tomorrow, review what it found. Count the files it touched, the errors it hit, the approaches it tried.
+
+That's partial credit. For most teams, it's worth more than waiting for the perfect task.
+
+## Frequently asked questions
+
+### What if the agent produces nothing useful at all?
+
+Even a failed attempt provides signal. If the agent couldn't make progress, that tells you the task definition was too vague, the codebase lacks sufficient documentation, or the problem is harder than expected. You've learned something about the task's complexity without spending your own hours discovering it.
+
+### How do I evaluate whether an unmergeable PR was worth the cost?
+
+Ask three questions: Did it identify files or modules you didn't know were involved? Did it surface errors or edge cases you would have hit later? Did it try an approach that saved you from going down the same path? If any answer is yes, you collected partial credit.
+
+### Does Roo Code work for this pattern with any LLM provider?
+
+Yes. Roo Code's BYOK model means you connect your own API keys from providers like Anthropic, OpenAI, or others. The agent runs tasks using your preferred model, and you pay the provider directly with no token markup from Roo Code.
+
+### How much does overnight agent exploration typically cost?
+
+Costs vary based on task complexity, model choice, and how many iterations the agent attempts. For most exploratory tasks, teams report spending a few dollars per task. Compare that to the hourly cost of an engineer doing the same research manually.
+
+### Should I use this for all tasks or only specific types?
+
+The partial credit pattern works best for tasks with unclear scope: features where you don't know the blast radius, refactors touching unfamiliar code, or integrations with unknown dependencies. For well-defined tasks with clear requirements, you might still prefer to aim for mergeable output.
diff --git a/apps/web-roo-code/src/content/blog/treat-subtasks-like-junior-devs-to-prevent-context-poisoning.md b/apps/web-roo-code/src/content/blog/treat-subtasks-like-junior-devs-to-prevent-context-poisoning.md
new file mode 100644
index 00000000000..63b14771c8c
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/treat-subtasks-like-junior-devs-to-prevent-context-poisoning.md
@@ -0,0 +1,119 @@
+---
+title: Treat Subtasks Like Junior Devs to Prevent Context Poisoning
+slug: treat-subtasks-like-junior-devs-to-prevent-context-poisoning
+description: Learn how to prevent context poisoning in orchestrated AI workflows by treating subtasks like junior developers with atomic, scoped instructions.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - orchestration
+    - context-management
+    - agentic-workflows
+    - best-practices
+status: draft
+publish_date: "2025-05-21"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Twenty-seven hours. One autonomous run. Zero human interventions.
+
+The secret wasn't a special model or a clever prompt. It was a constraint: keep subtasks so short that context never has time to rot.
+
+## The drift problem
+
+You're running an orchestrated workflow. The parent agent delegates a chunk of work to a subtask. The subtask starts fine: reads the repo, proposes a change, runs a test.
+
+Then it keeps going. It accumulates context from three different files. It remembers a failed approach from ten minutes ago. It starts referencing assumptions it made earlier that were never validated.
+
+By the time the subtask returns to the orchestrator, the context is poisoned. The orchestrator inherits stale beliefs. The next subtask launches with contaminated instructions.
+
+This is context drift at scale. The longer a subtask runs, the more opportunity for garbage to accumulate.
+
+## The junior dev heuristic
+
+The fix is counterintuitive: treat your subtasks like junior developers.
+
+Not as an insult. As a constraint. Junior devs need extremely specific, simple instructions. They can't be trusted with ambiguous scope. They work best when given one clear task with explicit success criteria.
+
+> "The way that I managed that was just simply by telling orchestrator that your subtasks are junior devs and you need to treat them like they are stupid."
+>
+> Shank, [Office Hours S01E07](https://www.youtube.com/watch?v=yGVPIdn0mVw&t=1199)
+
+This framing forces the orchestrator to decompose work into atomic units. Each subtask gets a narrow mandate. When something goes wrong, the blast radius is one short task, not a chain of contaminated context.
+
+The 27-hour autonomous run worked because subtasks were kept extremely short:
+
+> "Keeping tasks extremely short so that context didn't really have a chance to get poisoned before the task was returned back to orchestrator."
+>
+> Shank, [Office Hours S01E07](https://www.youtube.com/watch?v=yGVPIdn0mVw&t=1135)
+
+## The model matters
+
+Not every model can follow this pattern. Orchestration requires listening to rules about scope and knowing when to stop.
+
+> "4.1 is the only model that actually managed to listen to my rules well enough to actually continue this for a prolonged period of time."
+>
+> Shank, [Office Hours S01E07](https://www.youtube.com/watch?v=yGVPIdn0mVw&t=2112)
+
+The tradeoff: models that follow rules well may be slower or cost more per token. But if a cheaper model ignores your scope constraints and runs subtasks too long, you pay in poisoned context and failed orchestration runs.
+
+## The guardrails
+
+If you're setting up orchestrated workflows, here's the policy:
+
+1. **Scope each subtask as if you're delegating to someone who just joined the team.** One file. One function. One test. Not "fix the authentication flow."
+
+2. **Set explicit return conditions.** The subtask should know exactly when to stop and hand back to the orchestrator.
+
+3. **Treat long subtasks as a smell.** If a subtask runs for more than a few minutes, it's probably accumulating context that will poison the next step.
+
+4. **Pick a model that follows rules.** Test whether your model actually respects scope constraints before trusting it with multi-hour runs.
+
+## Subtask scoping: old approach vs. new approach
+
+| Dimension        | Old approach                           | New approach                                               |
+| ---------------- | -------------------------------------- | ---------------------------------------------------------- |
+| Task scope       | "Fix the authentication flow"          | "Update the login function in auth.ts to return a boolean" |
+| Context lifetime | Subtask runs until work feels complete | Subtask returns after one atomic change                    |
+| Failure handling | Debug within the same context          | Return to orchestrator, spawn fresh subtask                |
+| Instructions     | Assume the agent understands intent    | Explicit success criteria and stop conditions              |
+| Context health   | Degrades over time                     | Stays fresh through short cycles                           |
+
+## How Roo Code prevents context poisoning
+
+Roo Code's Orchestrator mode is built around the principle that subtasks should close the loop quickly and return control to the parent agent. When you configure Orchestrator, you can set explicit boundaries for each subtask, ensuring that no single agent accumulates stale context.
+
+With BYOK (bring your own key), you control which models handle orchestration versus subtasks. This lets you assign a rule-following model like GPT-4.1 to the orchestrator role while using faster models for atomic subtasks. The result: context stays clean because each subtask operates in isolation, reports back, and terminates before drift sets in.
+
+**Roo Code's orchestration pattern treats subtasks as disposable workers with narrow mandates, preventing the context poisoning that kills long-running autonomous workflows.**
+
+## Why this matters for your team
+
+For a team running orchestrated agents on production code, context poisoning is the silent killer. The orchestrator looks like it's working. Subtasks complete. But the output drifts because each step inherited garbage from the last.
+
+The junior dev heuristic is a forcing function. It makes you think about scope before you delegate. It limits the damage when something goes wrong. And it turns a 27-hour autonomous run from a lucky experiment into a repeatable pattern.
+
+The first step: audit how long your subtasks actually run. If any exceed a few minutes, break them down further.
+
+## Frequently asked questions
+
+### What is context poisoning in AI agent workflows?
+
+Context poisoning occurs when an AI agent accumulates stale, incorrect, or irrelevant information during a long-running task. This contaminated context gets passed to subsequent subtasks or back to the orchestrator, causing downstream failures and drift from the original goal.
+
+### How short should subtasks be to avoid context drift?
+
+Subtasks should be scoped to complete in minutes, not hours. A good rule of thumb: if a subtask touches more than one file or one function, it's probably too broad. The goal is to return to the orchestrator before the context has time to accumulate garbage.
+
+### Does Roo Code support orchestrated workflows with subtask isolation?
+
+Yes. Roo Code's Orchestrator mode lets you define explicit boundaries for subtasks and configure which models handle different roles. This architecture keeps subtasks atomic and prevents context from bleeding between tasks, which is essential for long-running autonomous workflows.
+
+### Why do some models fail at orchestration while others succeed?
+
+Orchestration requires a model to follow rules about scope, stop conditions, and delegation. Some models ignore these constraints and let subtasks run too long. Testing your model's ability to respect scope boundaries is critical before trusting it with extended autonomous runs.
+
+### How do I audit my current subtask duration?
+
+Review your orchestration logs to measure how long each subtask runs before returning. Look for subtasks exceeding a few minutes or touching multiple files. These are candidates for further decomposition into smaller, atomic units.
diff --git a/apps/web-roo-code/src/content/blog/two-silos-vibe-coders-and-tinkerers-need-different-defaults.md b/apps/web-roo-code/src/content/blog/two-silos-vibe-coders-and-tinkerers-need-different-defaults.md
new file mode 100644
index 00000000000..78d3687fa37
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/two-silos-vibe-coders-and-tinkerers-need-different-defaults.md
@@ -0,0 +1,119 @@
+---
+title: "Two Silos: Vibe Coders and Tinkerers Need Different Defaults"
+slug: two-silos-vibe-coders-and-tinkerers-need-different-defaults
+description: Why averaging UX for different user types fails, and how shipping two experiences with a shared core serves both vibe coders and tinkerers effectively.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - product-design
+    - user-experience
+    - developer-tools
+    - ai-coding
+status: draft
+publish_date: "2025-04-25"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Click once. Start building.
+
+Or: configure seventeen settings before you trust it with production code.
+
+Same tool. Two completely different users.
+
+## The tension every tool faces
+
+Your team has both. The PM who wants to prototype a landing page without waiting for engineering. The senior engineer who refuses to use anything until they understand what it executes and when.
+
+If you design for one, you lose the other. Design for the PM: the engineer never trusts it. Design for the engineer: the PM bounces after five minutes of configuration screens.
+
+The instinct is to find a middle ground. Build one interface that works for everyone. Average the two experiences.
+
+That instinct is wrong.
+
+> "Our users are in two silos ultimately... we have the silo of people who are newer or truly don't want to learn how to code, possibly. You know, you could call them the straight vibe coders, and then you have the actual, you know, the engineers, the tinkerers, the coders."
+>
+> Harris, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=68)
+
+## The design pattern that works
+
+The solution is not a compromise. Ship two experiences with a shared core.
+
+**Layer 1: The working default.** A mode that works out of the box. No configuration required. Click and start using it. This is a preview of what the tool can do, not the final word.
+
+**Layer 2: The internals.** Settings, modes, and controls for users who want to refine. Approvals, model selection, execution policies. Available but not mandatory.
+
+The key insight: the default mode is not "the mode." It works. It's fine. It's good. But it doesn't do everything for everybody, and you shouldn't pretend it does.
+
+> "We're trying to find this balance between an out-of-the-box experience... and really that's a preview of what it can do."
+>
+> Harris, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=91)
+
+## The tradeoff you are actually making
+
+Averaging the experiences means both groups are frustrated.
+
+The vibe coder sees configuration options they don't understand. The tinkerer can't find the controls they need because they're hidden to reduce complexity. Nobody is satisfied.
+
+Separate defaults mean maintenance burden. Two paths through the product. More surface area to test. More documentation to write.
+
+The bet: the maintenance cost is lower than the churn cost of losing either audience entirely.
+
+## Why this matters for your team
+
+If you're a Series A through C company with a small engineering team, you probably have both user types already. The founder who wants to ship a feature without writing code. The lead engineer who needs to understand exactly what runs on the CI server.
+
+Trying to onboard both with the same tutorial, the same defaults, and the same messaging will frustrate one of them. Usually the one who matters more to your current stage.
+
+The shift: name the silo. Build the path. Don't pretend one mode serves both.
+
+> "We want to be very cautious to point people at this as the mode. Now, this is a mode that works. It works. It's fine. It's good. It doesn't do everything for everybody."
+>
+> Harris, [Roo Cast S01E01](https://www.youtube.com/watch?v=oY0Ox16BrR0&t=37)
+
+## The first step
+
+Audit your current default experience. Ask: who is this designed for? If the answer is "everyone," the real answer is probably "no one in particular."
+
+Then pick. Build the vibe coder path or the tinkerer path first. Make the other path accessible, not hidden. Let users self-select.
+
+The tool that tries to be everything to everyone usually ends up being nothing to anyone.
+
+## How Roo Code supports both user types
+
+Roo Code addresses this two-silo problem through its mode system and configurable approvals. Vibe coders can start immediately with a working default that proposes diffs and runs commands without requiring upfront configuration. Tinkerers get full control: they can configure approval policies, select specific models through BYOK (bring your own key), and define execution boundaries before the agent touches their codebase.
+
+The agent closes the loop by running tests and iterating on failures, but the level of autonomy is user-controlled. A vibe coder might approve everything automatically during a prototype session. A senior engineer working on production code might require approval for every terminal command.
+
+**Roo Code lets each user type set their own trust boundary without forcing either to compromise.**
+
+| Dimension         | Averaged UX (One Size Fits All)           | Two-Silo Design (Roo Code Approach)                       |
+| ----------------- | ----------------------------------------- | --------------------------------------------------------- |
+| Onboarding time   | Medium for everyone, optimal for no one   | Fast for vibe coders, configurable for tinkerers          |
+| Trust calibration | Fixed approval level frustrates both      | User-controlled approval policies                         |
+| Feature discovery | Hidden complexity or overwhelming options | Progressive disclosure based on user path                 |
+| Model selection   | Single default or confusing choices       | BYOK lets tinkerers choose; default works for vibe coders |
+| Iteration speed   | Compromised for safety or speed           | Vibe coders iterate fast; tinkerers maintain control      |
+
+## Frequently asked questions
+
+### What is a vibe coder?
+
+A vibe coder is someone who wants to build software quickly without deep technical configuration. They prioritize shipping over understanding every implementation detail. PMs prototyping features, founders validating ideas, and designers building functional mockups often fall into this category.
+
+### Why does averaging user experiences fail?
+
+Averaging creates a middle ground that satisfies neither extreme. Vibe coders encounter configuration they don't need. Tinkerers can't find controls because they're hidden to reduce complexity. Both groups experience friction that could have been avoided with separate paths.
+
+### How does Roo Code handle different user types?
+
+Roo Code ships a working default mode that requires no configuration, allowing vibe coders to start immediately. Tinkerers can access approval settings, model selection through BYOK, and execution policies without those options cluttering the default experience. The agent closes the loop for both, but each user controls how much autonomy to grant.
+
+### Should I build the vibe coder path or tinkerer path first?
+
+Start with whichever user type is more critical to your current business stage. Early-stage companies often need vibe coder adoption for volume. Companies selling to enterprises typically need tinkerer trust first. Build one path well, then make the other accessible.
+
+### What is the maintenance cost of supporting two user paths?
+
+Two paths mean more surface area to test and document. However, the churn cost of losing an entire user segment usually exceeds this maintenance burden. The key is sharing a core engine while varying the defaults and progressive disclosure, not building two separate products.
diff --git a/apps/web-roo-code/src/content/blog/two-words-in-your-system-prompt-can-double-your-eval-pass-rate.md b/apps/web-roo-code/src/content/blog/two-words-in-your-system-prompt-can-double-your-eval-pass-rate.md
new file mode 100644
index 00000000000..eaf906e4903
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/two-words-in-your-system-prompt-can-double-your-eval-pass-rate.md
@@ -0,0 +1,132 @@
+---
+title: Two Words in Your System Prompt Can Double Your Eval Pass Rate
+slug: two-words-in-your-system-prompt-can-double-your-eval-pass-rate
+description: How changing "diff" to "apply diff tool" in a system prompt increased Gemini 2.0 Flash's eval pass rate from 26% to 56% - a practical guide to prompt precision for AI coding agents.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - prompt-engineering
+    - evals
+    - system-prompts
+    - ai-coding-agents
+status: draft
+publish_date: "2025-04-09"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+26% to 56%.
+
+Two words.
+
+That's not a model upgrade. That's a system prompt edit.
+
+## The literal machine
+
+The Roo Code team ran Gemini 2.0 Flash through their eval suite. It completed 26% of tasks. Not great, but a starting point.
+
+Then they changed two things in the system prompt:
+
+1. Replaced "diff" with "apply diff tool"
+2. Added explicit file content boundaries
+
+The pass rate jumped to 56%.
+
+No model change. No architecture change. No fine-tuning. Just clearer instructions.
+
+The original prompt said something like: "use the read file tool to get the latest content of the file before attempting the diff again."
+
+The fix: "use the read file tool to get the latest content of the file before attempting to use the apply diff tool."
+
+> "The wording in the system prompt referred to the apply diff tool as diff. So it said use the read file tool to get the latest content of the file before attempting the diff again. So we changed it to use the read file tool to get the latest content of the file before attempting to use the apply diff tool."
+>
+> Hannes Rudolph, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=2901)
+
+The model was interpreting "diff" as a concept, not as a tool name. It knew what a diff was. It didn't know you meant the specific tool called "apply diff tool."
+
+## Why this happens
+
+LLMs parse instructions literally. More literally than most developers assume.
+
+When you write a prompt, you're not writing for a colleague who will infer your intent from context. You're writing for a system that will follow the exact words you used, including the ambiguities you didn't notice.
+
+> "Indefinite articles make a difference in prompt engineering. Be very very it's like telling your six-year-old what to do."
+>
+> Matt, [Office Hours S01E01](https://www.youtube.com/watch?v=DZIkxSMPKOY&t=2950)
+
+"Use the diff" and "use the apply diff tool" feel synonymous when you read them. They're not synonymous to the model. One is a vague reference; the other is an exact tool invocation.
+
+The same applies to file content boundaries. If your prompt doesn't clearly mark where file content starts and ends, the model may parse your instructions as part of the file, or vice versa. Explicit delimiters remove ambiguity.
+
+## The tradeoff
+
+Precise prompts are longer prompts. You're trading brevity for clarity.
+
+If your system prompt is already pushing context limits, adding explicit tool names and boundary markers costs tokens. For most workflows, the tradeoff is worth it: a 30-point improvement in task completion outweighs a few hundred extra tokens per request.
+
+The harder tradeoff is maintenance. Precise prompts are more brittle. If you rename a tool, you need to update every reference. If you change your file format, you need to update your boundary markers. The cost of precision is vigilance.
+
+## Prompt precision: vague vs. explicit
+
+| Dimension          | Vague prompt        | Explicit prompt                       |
+| ------------------ | ------------------- | ------------------------------------- |
+| Tool reference     | "use the diff"      | "use the apply diff tool"             |
+| File boundaries    | Implicit or missing | Explicit delimiters marking start/end |
+| Token cost         | Lower               | Slightly higher                       |
+| Maintenance burden | Lower               | Higher (must update on tool renames)  |
+| Eval pass rate     | Baseline            | 30+ point improvement possible        |
+
+## How Roo Code closes the loop on prompt precision
+
+Roo Code's system prompts are designed with explicit tool names and clear content boundaries so the agent can propose diffs, run commands and tests, and iterate based on the results without ambiguity. When you use Roo Code with your own API keys (BYOK), every token spent goes toward precise instructions that maximize task completion rather than vague references that waste cycles on retries.
+
+The 26% to 56% improvement measured in Roo Code's eval suite demonstrates that prompt precision is not optional for agentic workflows. It is the difference between an agent that closes the loop and one that spins on the same failure.
+
+## Why this matters for your workflow
+
+If you're debugging why a model keeps failing at a specific step, the prompt wording is the first place to look.
+
+The symptoms:
+
+- The model knows the concept but doesn't invoke the right tool
+- The model parses file content as instructions, or vice versa
+- The model retries the same wrong approach with slight variations
+
+The fix:
+
+- Audit every tool reference. Is it the exact name the model expects?
+- Add explicit boundaries. Mark where instructions end and content begins.
+- Test the change against your evals. Measure the delta.
+
+A 30-point swing from two words is extreme, but double-digit improvements from prompt precision are common. The model isn't broken; it's doing exactly what you told it to do.
+
+## The literal test
+
+Read your system prompt out loud. Would a six-year-old know exactly which tool you mean? Would they know where the instructions stop and the file content starts?
+
+If not, the model doesn't know either.
+
+Start with tool names. Make them exact. The pass rate will follow.
+
+## Frequently asked questions
+
+### Why do small wording changes have such a large impact on model performance?
+
+LLMs parse instructions literally rather than inferring intent from context. When a prompt uses "diff" instead of "apply diff tool," the model interprets it as a concept rather than a specific tool invocation. This ambiguity causes the model to attempt operations that don't map to available tools, resulting in failures that compound across multi-step tasks.
+
+### How do I know if my prompt has ambiguous tool references?
+
+Look for symptoms: the model knows the concept but doesn't invoke the right tool, it parses file content as instructions, or it retries the same wrong approach repeatedly. Audit your prompt for any tool reference that uses shorthand or informal names instead of the exact tool name your system expects.
+
+### Does Roo Code handle prompt precision automatically?
+
+Roo Code's system prompts are engineered with explicit tool names and file content boundaries built in. When you start a task, the agent receives instructions that map directly to available tools, reducing ambiguity and improving task completion rates. This precision is part of how Roo Code closes the loop on complex coding tasks.
+
+### What is the tradeoff between prompt precision and token cost?
+
+Precise prompts are longer, which costs more tokens per request. However, a 30-point improvement in task completion typically outweighs a few hundred extra tokens. The real tradeoff is maintenance: precise prompts require updates whenever you rename tools or change file formats.
+
+### How can I test whether prompt changes improve my eval scores?
+
+Run your eval suite before and after the prompt change, keeping all other variables constant. Measure the delta in pass rate. Even if you don't see a 30-point swing, double-digit improvements from prompt precision are common when you systematically replace vague references with exact tool names.
diff --git a/apps/web-roo-code/src/content/blog/use-your-issue-queue-as-an-agent-eval-suite.md b/apps/web-roo-code/src/content/blog/use-your-issue-queue-as-an-agent-eval-suite.md
new file mode 100644
index 00000000000..d69321a703a
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/use-your-issue-queue-as-an-agent-eval-suite.md
@@ -0,0 +1,140 @@
+---
+title: Use Your Issue Queue as an Agent Eval Suite
+slug: use-your-issue-queue-as-an-agent-eval-suite
+description: Why synthetic benchmarks plateau at 97% accuracy while real GitHub issues reveal which AI coding agent actually ships code in your codebase.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agent-evaluation
+    - developer-workflow
+    - engineering-teams
+    - benchmarks
+status: draft
+publish_date: "2025-06-25"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+97% accuracy on benchmarks.
+
+97% accuracy on the next benchmark too.
+
+And the one after that.
+
+When every agent scores the same on synthetic evals, you stop learning anything useful about which one will actually ship code in your codebase.
+
+## The plateau problem
+
+Your team is evaluating agents. You run the standard benchmarks. Agent A scores 97.2%. Agent B scores 97.1%. Agent C scores 96.8%. The confidence intervals overlap. You're now choosing based on vibes, pricing, or whoever had the slicker demo.
+
+This is the plateau. When benchmark accuracy converges, the signal disappears. You can't tell which agent will handle your legacy auth module, your weird build system, or the edge cases that only exist in codebases that have shipped for three years.
+
+Synthetic evals don't know about your constraints. They test clean problems with clean solutions. Your issues are neither.
+
+## The alternative: your issue queue
+
+Every GitHub issue that comes in is a real eval.
+
+Real user context. Real codebase constraints. Real edge cases that no benchmark author anticipated.
+
+> "We've been really interested in the issues that you all are submitting as almost like a real life eval of like what are the things?"
+>
+> Matt Rubens, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=1030)
+
+The measurement is simple: run each incoming issue through your agent. Track how often the fix ships without human correction.
+
+Not "does the agent produce code?" but "does the code pass review and merge?"
+
+That's the difference between demo accuracy and production accuracy.
+
+## What the data reveals
+
+When you run agents against real issues instead of benchmarks, you see things synthetic evals never show:
+
+The agent that handles simple refactors perfectly but drifts on anything touching your custom ORM.
+
+The agent that produces correct code but can't describe what it changed in a way that passes your review rubric.
+
+The agent that solves the stated problem but breaks an implicit constraint that only exists in your team's heads.
+
+> "We're not at like a 97% accuracy on building the issues in a way that is good enough that we want to ship to production."
+>
+> Matt Rubens, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek&t=1144)
+
+This is the honest answer. Production-quality outputs on real issues are rarer than benchmark scores suggest. Knowing that changes how you evaluate.
+
+## The dream setup
+
+The ideal: every incoming issue runs through multiple agents in parallel. Roo Code, Codex, Cursor, Claude Code. Compare outputs. Track which ones ship.
+
+> "In my dream world, like every issue that comes in, we'd run a Roo agent against it, we'd run a Codex against it, we'd run a Cursor agent against it, we'd run a Claude Code against it."
+>
+> Matt Rubens, [Office Hours S01E11](https://www.youtube.com/watch?v=yiNyqIkKjek)
+
+You don't need this level of infrastructure to start. Pick one agent. Run it against the next ten issues that come in. Track the outcomes:
+
+- Shipped without edit
+- Shipped with minor edit
+- Required substantial rework
+- Didn't ship
+
+Ten issues gives you more signal than ten thousand synthetic benchmark runs.
+
+## The tradeoff
+
+Real-issue evals take time. You're asking a human to review each agent output, decide if it's shippable, and track the result. That's overhead.
+
+The tradeoff: you're trading reviewer time for an eval signal that actually predicts performance on your codebase. Benchmarks are cheaper to run but tell you less about what matters.
+
+For Series A to C teams with limited engineering bandwidth, the question is: where do you want to spend the reviewer time? On synthetic evals that plateau, or on real issues that expose real gaps?
+
+## Why this matters for your team
+
+If you're a five-person engineering team choosing between agents, the standard recommendation is to run benchmarks. You'll get numbers. The numbers will be close. You'll still be guessing.
+
+Real-issue evals flip the model: you're not testing "can the agent solve a clean problem?" but "can the agent solve our problems?"
+
+For a team shipping 10-15 issues per week, running even half of those through an agent and tracking outcomes gives you a dataset that actually reflects your codebase. After a month, you know which agent handles your constraints. No benchmark will tell you that.
+
+The first step: pick your next five incoming issues and run them through your current agent. Track what happens. That's your baseline.
+
+## How Roo Code closes the loop on real-issue evals
+
+Roo Code is built for exactly this workflow. Because it can run tests, execute commands, and iterate based on results, you get a complete picture of whether an agent-generated fix actually works in your environment before it ever reaches code review.
+
+With BYOK (bring your own key), you control costs while running multiple issues through the agent. There's no token markup, so scaling your eval runs doesn't surprise you with unexpected bills.
+
+**The citable fact:** Real-issue evaluation with Roo Code means tracking "did this ship?" rather than "did this pass a synthetic test," giving engineering teams production-grade signal about agent performance on their actual codebase.
+
+## Synthetic benchmarks vs. real-issue evals
+
+| Dimension       | Synthetic Benchmarks         | Real-Issue Evals                 |
+| --------------- | ---------------------------- | -------------------------------- |
+| Problem source  | Curated test cases           | Your actual GitHub issues        |
+| Context         | Clean, isolated problems     | Full codebase constraints        |
+| Success metric  | Test pass rate               | Code ships without rework        |
+| Signal at scale | Diminishing (plateau effect) | Increasing (pattern recognition) |
+| Cost            | Compute time only            | Reviewer time plus compute       |
+
+## Frequently asked questions
+
+### Why do benchmark scores plateau across different agents?
+
+Benchmark scores converge because synthetic evals test a fixed set of clean problems with known solutions. Once agents are trained on similar data and optimized for similar metrics, they solve the same problems at similar rates. The differentiation happens on problems the benchmarks never anticipated, which is exactly what your real issues contain.
+
+### How many real issues do I need to run before I get useful data?
+
+Ten issues gives you more actionable signal than thousands of synthetic benchmark runs. After 20-30 issues, patterns emerge: which types of problems the agent handles well, where it drifts, and what kinds of context it needs. A month of running half your incoming issues through an agent builds a dataset that reflects your codebase.
+
+### Does Roo Code work for this kind of real-issue evaluation?
+
+Yes. Roo Code closes the loop by running tests and iterating on failures within your actual development environment. This means you can track whether agent-generated fixes pass your CI pipeline and code review standards, not just whether they compile. BYOK pricing means you can scale these eval runs without token markup costs.
+
+### What should I track when running real-issue evals?
+
+Track four outcome categories: shipped without edit, shipped with minor edit, required substantial rework, and didn't ship. Over time, segment by issue type (bug fix, refactor, new feature) and codebase area. This reveals where the agent performs well and where human intervention remains necessary.
+
+### How do real-issue evals help with agent selection?
+
+Real-issue evals answer the question benchmarks cannot: "Can this agent solve our problems?" Running multiple agents against the same incoming issues and comparing ship rates gives you direct evidence of which agent handles your specific codebase constraints, build systems, and team conventions.
diff --git a/apps/web-roo-code/src/content/blog/user-experience-beats-model-quality-for-developer-adoption.md b/apps/web-roo-code/src/content/blog/user-experience-beats-model-quality-for-developer-adoption.md
new file mode 100644
index 00000000000..e07d7b6608a
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/user-experience-beats-model-quality-for-developer-adoption.md
@@ -0,0 +1,123 @@
+---
+title: User Experience Beats Model Quality for Developer Adoption
+slug: user-experience-beats-model-quality-for-developer-adoption
+description: Why sticky developer experiences drive adoption faster than superior model benchmarks, and how the infrastructure layer becomes swappable once workflows are established.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - developer-experience
+    - ai-coding-tools
+    - product-adoption
+    - developer-tools
+status: draft
+publish_date: "2026-01-12"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The product with the best model is not winning.
+
+The product developers keep opening is winning.
+
+## The evaluation trap
+
+Your team is evaluating AI coding tools. The spreadsheet has twelve columns: model benchmarks, token costs, context windows, latency measurements, compliance status. You're waiting for the next model release before making a decision. You want to pick the tool with the best underlying capabilities.
+
+Meanwhile, a competitor shipped something sticky three months ago. Their model is not the best. Their infrastructure is not the most sophisticated. But developers are using it daily, talking about it in Slack channels, and building workflows around it.
+
+By the time you finish evaluating, the adoption gap is permanent.
+
+## The counterintuitive priority
+
+Stickiness beats benchmarks. The pattern is consistent across every developer tool category right now.
+
+> "Creator experience and then also the user experience engaging with a model, or engaging with an app, rather, like the stickiness of the app, is much more important than necessarily having the best model under the hood."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=1475)
+
+This is not about having a worse model. It is about sequencing. The teams that ship a good-enough experience and iterate on developer feedback are building adoption curves that compound. The teams that wait for technical perfection before releasing are losing the window.
+
+## The adoption flywheel
+
+Developer adoption creates its own momentum. Once developers are using a tool daily, they create artifacts: workflows, scripts, integrations, muscle memory. Those artifacts become switching costs. The network effects follow.
+
+> "If you get significant numbers of developers adopting your product, then you're going to have the kind of network and word-of-mouth marketing effects that will lead to continued adoption."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=1514)
+
+Word-of-mouth from developers carries more weight than any marketing claim about model capabilities. A senior engineer saying "I use this every day" in a Slack thread moves more adoption than a benchmark comparison.
+
+## The infrastructure swap
+
+Here is the part that makes technical leaders uncomfortable: the model under the hood is increasingly swappable.
+
+> "If you just build the thing and get everybody using it, you can swap out models, swap out infrastructure, swap out quantization approaches... And the user doesn't ever need to care."
+>
+> Paige Bailey, [Office Hours S01E15](https://www.youtube.com/watch?v=sAFQIqmDFL4&t=1627)
+
+The abstraction layer is the product. The user interacts with the experience, not the model directly. If a new model is released that performs better for certain tasks, the product swaps it in. If a more cost-effective quantization approach becomes available, the product adopts it. The user never notices because they are interacting with a stable interface, not raw model outputs.
+
+This means the defensible moat is not "we have the best model." The defensible moat is "developers have built their workflows around us."
+
+## The tradeoff
+
+This strategy has real constraints. Shipping before the experience is smooth enough to be sticky defeats the purpose. The bar is not "perfect model"; the bar is "good enough that developers keep coming back."
+
+For products with high trust requirements, like those handling sensitive code or production deployments, the experience must include clear boundaries and approvals. Stickiness that erodes trust is not sustainable.
+
+## How Roo Code enables model-agnostic adoption
+
+Roo Code's BYOK (bring your own key) architecture separates the user experience from the underlying model infrastructure. Developers connect their preferred provider, whether Anthropic, OpenAI, or local models, and interact with a consistent interface that closes the loop: proposing changes, running commands, and iterating based on results.
+
+**This architecture means developers build workflows around Roo Code's experience layer, not around a specific model.** When a better model becomes available, the developer switches their API key. Their workflows, modes, custom instructions, and muscle memory remain intact. The switching cost stays with the product experience, not the model vendor.
+
+The approval system ensures that stickiness does not come at the cost of trust. Developers maintain control over what the agent executes, building confidence through intentional oversight rather than blind automation.
+
+## Evaluation framework comparison
+
+| Dimension         | Traditional evaluation      | Adoption-first evaluation   |
+| ----------------- | --------------------------- | --------------------------- |
+| Primary metric    | Benchmark scores            | Daily active usage rate     |
+| Timeline          | Wait for next model release | Ship and iterate now        |
+| Model dependency  | Locked to single provider   | Model-agnostic architecture |
+| Switching costs   | Based on capabilities       | Based on workflow artifacts |
+| Success indicator | Wins POC comparison         | Developers discuss in Slack |
+
+## Why this matters for your team
+
+If you are leading an engineering org evaluating AI tools, the question shifts. The traditional evaluation framework optimizes for capability on paper: which tool has the best benchmarks, the largest context window, the lowest latency in controlled tests.
+
+The revised framework optimizes for adoption velocity: which tool will developers actually use daily? Which tool creates workflows that compound? Which tool's experience is sticky enough to survive the next model release cycle?
+
+For a twenty-person engineering team, choosing a tool that scores marginally lower on benchmarks but achieves 80% daily active usage beats a tool that scores higher but sits unused after the initial trial.
+
+## The sequencing question
+
+The decision is not "experience or model quality." It is "which one first?"
+
+Ship the sticky experience. Build the adoption. Then swap out the infrastructure as capabilities improve.
+
+The teams that invert this sequence, waiting for the perfect model before shipping, are losing to teams that already have developers in the loop.
+
+## Frequently asked questions
+
+### Why does developer experience matter more than model benchmarks?
+
+Benchmarks measure capability in controlled conditions. Daily usage measures whether developers actually incorporate the tool into their workflow. A tool with marginally worse benchmarks but high daily usage creates compounding adoption through word-of-mouth, workflow artifacts, and muscle memory. These switching costs persist even when better models become available.
+
+### How can teams evaluate AI coding tools for stickiness rather than raw capability?
+
+Run a time-boxed trial focused on daily active usage rather than feature comparisons. Track how many developers open the tool each day, not how many features it has. Interview developers after two weeks about which workflows they have built around the tool. High-capability tools that developers abandon after the trial period provide less value than moderate-capability tools with sustained usage.
+
+### Does Roo Code lock developers into a specific model provider?
+
+No. Roo Code uses a BYOK (bring your own key) architecture where developers connect their own API keys from any supported provider. The experience layer remains consistent regardless of which model runs underneath. Developers can switch providers or try new models without rebuilding their workflows, modes, or custom configurations.
+
+### What happens when a significantly better model is released?
+
+With a model-agnostic architecture, developers update their API configuration and continue working. Their accumulated workflows, custom modes, and interaction patterns transfer directly. The product experience improves immediately without requiring migration, retraining, or workflow reconstruction.
+
+### How do approval systems affect adoption stickiness?
+
+Approval systems build trust by giving developers explicit control over agent actions. This trust compounds into stickiness because developers feel confident expanding their usage into more sensitive workflows. Products that sacrifice trust for convenience often see adoption plateau or reverse when developers encounter unexpected behavior in production-adjacent code.
diff --git a/apps/web-roo-code/src/content/blog/vibe-coders-build-and-rebuild-they-do-not-migrate.md b/apps/web-roo-code/src/content/blog/vibe-coders-build-and-rebuild-they-do-not-migrate.md
new file mode 100644
index 00000000000..363c478bf1c
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/vibe-coders-build-and-rebuild-they-do-not-migrate.md
@@ -0,0 +1,119 @@
+---
+title: Vibe Coders Build and Rebuild, They Do Not Migrate
+slug: vibe-coders-build-and-rebuild-they-do-not-migrate
+description: Why non-technical builders hit a migration wall with AI coding tools and how engineering artifacts make the difference between throwaway prototypes and production-ready handoffs.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - vibe-coding
+    - ai-coding-agents
+    - developer-workflow
+    - prototyping
+status: draft
+publish_date: "2025-10-16"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Throwaway apps aren't a bug.
+
+They're the workflow.
+
+## The wall
+
+You built something. It works. You deployed it, maybe even turned it into a small business. The AI tools got you there: you described what you wanted, iterated on the prompts, and shipped.
+
+Then the API you're using releases a new version. Or you need to swap out the backend. Or someone asks for a feature that touches three files you've never opened.
+
+You stare at the codebase. You paste the error into the AI. It suggests changes. You apply them. Something else breaks. You prompt again. Same loop. Thirty minutes later, you're no closer to a working app than when you started.
+
+This is the migration wall. And if you don't have a software engineering background, it's often harder than the original build.
+
+> "We're at this very strange time where people can build an initial prototype and kind of get it working enough to kind of deploy it to even turn it into a small business. But given that they don't have software engineering backgrounds, it's still a struggle for them to make updates, to swap out backends, to migrate from one release of an API to another."
+>
+> Paige Bailey, [Roo Cast S01E14](https://www.youtube.com/watch?v=k3od6FjUfK0&t=1247)
+
+## The pattern: rebuild, don't migrate
+
+The emerging behavior is predictable: if the change is bigger than a prompt can handle, people start over.
+
+This isn't laziness. It's rational. You can describe the whole app from scratch in a prompt. But without the underlying concepts, describing the surgical change needed to migrate a database schema is much harder.
+
+The apps become disposable. Version 1 ships. Version 2 is a new repo.
+
+> "All of these earlier career builders are creating apps and the apps are effectively throwaway apps where, you know, if they need to make even smaller changes or upgrade to significantly new architectures, then they're going to rebuild as opposed to migrating existing systems."
+>
+> Paige Bailey, [Roo Cast S01E14](https://www.youtube.com/watch?v=k3od6FjUfK0&t=1307)
+
+This works up to a point. If your app is simple enough to rebuild in an afternoon, rebuilding is fine. But the pattern breaks when the app gets complicated enough that rebuilding takes longer than you have, and migrating requires skills you don't.
+
+## The handoff question
+
+This matters if you're a PM shipping prototypes, a marketer building landing pages, or an analyst creating internal tools. At some point, the prototype might be ready for production. The question becomes: can an engineer take this codebase and work with it, or does it need to be rebuilt with proper structure first?
+
+The answer depends on what artifacts exist around the code.
+
+A codebase with issues, PR history, and review comments is a handoff. A codebase that exists as a single "vibe" is a spec at best - and often missing the breadcrumbs an engineer needs.
+
+## What this means for your workflow
+
+If you're building with AI tools and want your work to survive beyond the first version, think about the handoff from day one.
+
+This doesn't mean learning software engineering. It means using tools that create engineering artifacts as a side effect of your building process.
+
+When an AI coding agent proposes changes, runs tests, and iterates based on real outputs, it generates a trail: task logs, diffs, issues, PR comments. That trail is what lets an engineer pick up where you left off without starting from scratch.
+
+The alternative is the current pattern: you build, you hit a wall, you rebuild. Each version is standalone. Each migration is a new build.
+
+## Why this matters for your team
+
+If you're a team lead evaluating how to onboard non-technical contributors, this is the question to ask: what happens when their prototype is ready for production?
+
+The vibe coder who shipped a working prototype is a success story. The vibe coder whose prototype needs to be thrown away and rebuilt by engineering is a bottleneck that just moved.
+
+The handoff story is the difference. Artifacts make the prototype into a starting point. No artifacts make it into a requirements doc with extra steps.
+
+If you're building something you want to keep, build with tools that leave a trail.
+
+## How Roo Code closes the loop on vibe coding
+
+Roo Code is an AI coding agent that closes the loop: it proposes diffs, runs commands and tests, and iterates based on real outputs. This changes the vibe coding workflow fundamentally.
+
+When you build with Roo Code, the agent generates engineering artifacts as a natural byproduct. Every task creates a log. Every change produces a diff. Every test run captures results. These artifacts become the migration path that vibe coders typically lack.
+
+**Roo Code transforms throwaway prototypes into maintainable codebases by creating the engineering trail that makes handoffs possible.** You bring your own API keys (BYOK), so you control the costs and the context. The agent handles execution while you maintain approval over what gets committed.
+
+The rebuild-versus-migrate decision shifts when your AI coding agent documents its own reasoning and preserves context across sessions.
+
+## Vibe coding approaches compared
+
+| Dimension             | Chat-based prompting   | Roo Code agentic workflow       |
+| --------------------- | ---------------------- | ------------------------------- |
+| Migration path        | Rebuild from scratch   | Iterate with preserved context  |
+| Engineering artifacts | None by default        | Task logs, diffs, PR comments   |
+| Handoff readiness     | Spec doc at best       | Working codebase with history   |
+| Error handling        | Manual copy-paste loop | Agent runs tests and iterates   |
+| Context preservation  | Lost between sessions  | Maintained in project artifacts |
+
+## Frequently asked questions
+
+### Why do vibe coders rebuild instead of migrating?
+
+Rebuilding is often easier than migrating because you can describe an entire app in a prompt, but describing a surgical database schema change requires underlying engineering concepts. Without those concepts, starting fresh is the rational choice when a change exceeds what a single prompt can handle.
+
+### What artifacts make a prototype ready for engineering handoff?
+
+A handoff-ready prototype includes issue tracking, PR history with review comments, test coverage, and documented decisions. These artifacts let an engineer understand what was built and why, rather than reverse-engineering intent from code alone.
+
+### How does Roo Code help vibe coders avoid the migration wall?
+
+Roo Code closes the loop by running tests, capturing errors, and iterating on failures automatically. This creates engineering artifacts as a side effect of building. When you hit a migration wall, you have task logs, diffs, and context that make incremental changes tractable instead of requiring a full rebuild.
+
+### When should a team lead worry about vibe-coded prototypes?
+
+When the prototype is ready for production. The question is whether engineering can take the codebase forward or needs to rebuild it with proper structure. Teams should evaluate whether the building process created artifacts that support handoff, or just code that requires translation.
+
+### Can non-technical builders create production-ready code?
+
+Yes, with the right tooling. The key is using AI coding agents that generate engineering artifacts as part of the workflow. A prototype built with proper task tracking, test coverage, and documented changes can go to production. A prototype that exists only as a prompt history typically cannot.
diff --git a/apps/web-roo-code/src/content/blog/vibe-coders-build-and-rebuild.md b/apps/web-roo-code/src/content/blog/vibe-coders-build-and-rebuild.md
new file mode 100644
index 00000000000..9dabf209d55
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/vibe-coders-build-and-rebuild.md
@@ -0,0 +1,116 @@
+---
+title: "Vibe Coders Build and Rebuild, They Do Not Migrate"
+slug: "vibe-coders-build-and-rebuild"
+description: "Throwaway apps aren't a bug. They're the workflow. Understanding when rebuilding beats migrating, and what makes prototypes production-ready."
+publish_date: "2025-10-16"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+status: draft
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - AI Development
+    - Workflow
+    - Prototyping
+---
+
+Throwaway apps aren't a bug.
+
+They're the workflow.
+
+## The wall
+
+You built something. It works. You deployed it, maybe even turned it into a small business. The AI tools got you there: you described what you wanted, iterated on the prompts, and shipped.
+
+Then the API you're using releases a new version. Or you need to swap out the backend. Or someone asks for a feature that touches three files you've never opened.
+
+You stare at the codebase. You paste the error into the AI. It suggests changes. You apply them. Something else breaks. You prompt again. Same loop. Thirty minutes later, you're no closer to a working app than when you started.
+
+This is the migration wall. And if you don't have a software engineering background, it's often harder than the original build.
+
+> "We're at this very strange time where people can build an initial prototype and kind of get it working enough to kind of deploy it to even turn it into a small business. But given that they don't have software engineering backgrounds, it's still a struggle for them to make updates, to swap out backends, to migrate from one release of an API to another."
+>
+> Paige Bailey, Roo Cast S01E14
+
+## The pattern: rebuild, don't migrate
+
+The emerging behavior is predictable: if the change is bigger than a prompt can handle, people start over.
+
+This isn't laziness. It's rational. You can describe the whole app from scratch in a prompt. But without the underlying concepts, describing the surgical change needed to migrate a database schema is much harder.
+
+The apps become disposable. Version 1 ships. Version 2 is a new repo.
+
+> "All of these earlier career builders are creating apps and the apps are effectively throwaway apps where, you know, if they need to make even smaller changes or upgrade to significantly new architectures, then they're going to rebuild as opposed to migrating existing systems."
+>
+> Paige Bailey, Roo Cast S01E14
+
+This works up to a point. If your app is simple enough to rebuild in an afternoon, rebuilding is fine. But the pattern breaks when the app gets complicated enough that rebuilding takes longer than you have, and migrating requires skills you don't.
+
+## The handoff question
+
+This matters if you're a PM shipping prototypes, a marketer building landing pages, or an analyst creating internal tools. At some point, the prototype might be ready for production. The question becomes: can an engineer take this codebase and work with it, or does it need to be rebuilt with proper structure first?
+
+The answer depends on what artifacts exist around the code.
+
+A codebase with issues, PR history, and review comments is a handoff. A codebase that exists as a single "vibe" is a spec at best-and often missing the breadcrumbs an engineer needs.
+
+## What this means for your workflow
+
+If you're building with AI tools and want your work to survive beyond the first version, think about the handoff from day one.
+
+This doesn't mean learning software engineering. It means using tools that create engineering artifacts as a side effect of your building process.
+
+When an AI coding agent proposes changes, runs tests, and iterates based on real outputs, it generates a trail: task logs, diffs, issues, PR comments. That trail is what lets an engineer pick up where you left off without starting from scratch.
+
+The alternative is the current pattern: you build, you hit a wall, you rebuild. Each version is standalone. Each migration is a new build.
+
+## How Roo Code closes the loop
+
+Roo Code addresses the rebuild-versus-migrate problem by generating engineering artifacts automatically as you work. When you describe what you want, Roo Code doesn't just write code-it proposes diffs, runs commands and tests, observes the results, and iterates until the task succeeds. This "close the loop" workflow creates a trail of task logs, diffs, and review comments that engineers can follow.
+
+The result: your prototype becomes a starting point for production, not a spec to be rewritten.
+
+## Throwaway apps vs. handoff-ready apps
+
+Here's what separates a prototype that gets rebuilt from one that gets extended:
+
+|                             | Throwaway App                     | Handoff-Ready App                 |
+| --------------------------- | --------------------------------- | --------------------------------- |
+| **Code history**            | Single commit or none             | PR history with context           |
+| **Why decisions were made** | In your head                      | In task logs and comments         |
+| **Test coverage**           | Manual "it works" check           | Tests that ran during development |
+| **Migration path**          | Start over                        | Incremental changes with diffs    |
+| **Engineering handoff**     | Requirements doc with extra steps | Working codebase with trail       |
+
+## Why this matters for your team
+
+If you're a team lead evaluating how to onboard non-technical contributors, this is the question to ask: what happens when their prototype is ready for production?
+
+The vibe coder who shipped a working prototype is a success story. The vibe coder whose prototype needs to be thrown away and rebuilt by engineering is a bottleneck that just moved.
+
+The handoff story is the difference. Artifacts make the prototype into a starting point. No artifacts make it into a requirements doc with extra steps.
+
+If you're building something you want to keep, build with tools that leave a trail.
+
+## Frequently asked questions
+
+### Can AI help me migrate code, or do I have to rebuild?
+
+AI coding agents can help with migrations if they can run commands, observe errors, and iterate. The challenge for vibe coders isn't the AI's capability-it's describing the surgical change needed. Tools like Roo Code that close the loop (propose, run, observe, iterate) handle migrations better than copy-paste-into-chat workflows because they can see what actually breaks and fix it.
+
+### What makes a prototype handoff-ready?
+
+A prototype is handoff-ready when an engineer can understand what was built and why without asking you. That means: PR history showing changes over time, task logs explaining the reasoning, tests that actually ran, and review comments capturing decisions. If the only artifact is the final code, an engineer has to reverse-engineer your intent.
+
+### Do I need to learn software engineering to use Roo Code?
+
+No. Roo Code generates engineering artifacts (task logs, diffs, test results, PR comments) as a side effect of its workflow. You describe what you want; Roo Code proposes changes, runs them, and iterates. The artifacts accumulate automatically-you don't need to know how to create them manually.
+
+### What happens when I hit a migration wall with Roo Code?
+
+When you hit an error during migration, Roo Code can run the failing command, observe the output, and iterate on the fix. Instead of the copy-paste loop (paste error into AI, get suggestion, apply it, see new error, repeat), Roo Code closes that loop automatically. The task log captures each attempt, so if you do need to hand off to an engineer, they can see exactly what was tried.
+
+### How is this different from using ChatGPT or Claude directly?
+
+When you paste code into ChatGPT or Claude, you get suggestions-but you're the one running commands, observing errors, and deciding what to try next. Roo Code runs inside your development environment, proposes diffs, executes commands, and iterates based on real outputs. The difference is the loop: Roo Code closes it; chat interfaces leave it open.
diff --git a/apps/web-roo-code/src/content/blog/vibe-coding-works-until-someone-exposes-their-api-key.md b/apps/web-roo-code/src/content/blog/vibe-coding-works-until-someone-exposes-their-api-key.md
new file mode 100644
index 00000000000..5ab2cc01505
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/vibe-coding-works-until-someone-exposes-their-api-key.md
@@ -0,0 +1,108 @@
+---
+title: Vibe Coding Works Until Someone Exposes Their API Key
+slug: vibe-coding-works-until-someone-exposes-their-api-key
+description: Vibe coding delivers speed but creates blind spots around security. Learn why new builders accidentally expose API keys and how guardrails can catch mistakes before they become incidents.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - vibe-coding
+    - security
+    - developer-experience
+    - guardrails
+status: draft
+publish_date: "2025-04-22"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+.env
+API_KEY=sk-proj-abc123xyz...
+
+Pushed to GitHub. Public repo.
+
+## The gap you cannot see
+
+You built something that works. You typed what you wanted, watched it appear in seconds, and now you have a prototype that actually runs. That cycle time reduction is real. You shipped something.
+
+The problem is not that you lack skill. The problem is that you do not know what you do not know.
+
+Persistent storage quirks. Authentication gaps. Credentials sitting in plain text in a file that got committed because nobody told you about `.gitignore`. The prototype works locally. The prototype also just leaked your API key to anyone who can search GitHub.
+
+This is not a failure of vibe coding. This is a gap between "it works" and "it works safely at scale." The people building their first apps are not equipped to see the landmines they are walking past.
+
+## The safety net problem
+
+The builders who already ship secure production code have internalized patterns that feel invisible: never commit secrets, always validate inputs, assume the network is hostile. These patterns are not obvious. They are learned through years of watching things break in production.
+
+> "I think that longer term we're going to have some struggles. We're already seeing this right? Like with people accidentally exposing their API keys or not necessarily knowing what kind of security to kind of use for their application."
+>
+> Paige Bailey, [Office Hours S01E03](https://www.youtube.com/watch?v=rqMSBUSJos8&t=1373)
+
+The struggles are already here. Every week, someone discovers their prototype is public, their keys are scraped, and their cloud bill is someone else's crypto mining operation.
+
+The fix is not "teach everyone security from scratch." The fix is tooling that catches the mistakes before they become incidents.
+
+> "The software engineers who have experience and expertise deploying things in a reliable and scalable and secure way I think they need to be building tooling such that everybody else who's just beginning to build doesn't end up running into challenges that they might not be able to see themselves."
+>
+> Paige Bailey, [Office Hours S01E03](https://www.youtube.com/watch?v=rqMSBUSJos8&t=1439)
+
+## What good tooling looks like
+
+The goal is not to slow you down. The goal is to catch the things you cannot see yet.
+
+A tool that flags `.env` files before they get committed. A workflow that scans for hardcoded secrets and blocks the push. A review step that asks "did you mean to expose this endpoint without auth?" before you deploy.
+
+These are not training wheels. These are the same guardrails that experienced teams use, packaged so you get them by default instead of learning the hard way.
+
+The tradeoff: adding friction. Every check is a moment where you wait instead of ship. But the alternative is shipping a security incident along with your prototype. The friction pays off when your API key is not in someone else's hands.
+
+## Why this matters for you
+
+If you are building your first prototype, you are not expected to know every security pattern. But you should know that the patterns exist, and that the right tools can catch what you miss.
+
+Look for workflows that include secret scanning, commit hooks that check for `.env` files, and deployment pipelines that validate configuration before going live. If your current setup does not have these, find a tool or template that does.
+
+If you are an experienced developer watching this wave of new builders, the ask is clear: build the safety nets. The guardrails you internalized over years should be the defaults for everyone else.
+
+The vibe is real. The speed is real. The blind spots are also real. The tools should cover the gap.
+
+## How Roo Code closes the loop on security blind spots
+
+Roo Code operates as an AI coding agent that closes the loop - it proposes changes, runs commands, and iterates based on results. This loop includes the ability to catch security issues that vibe coders miss.
+
+When you work with Roo Code, you can configure modes and rules that enforce security checks before code leaves your machine. The agent can scan for `.env` files in staged commits, flag hardcoded secrets, and prompt you to add entries to `.gitignore` before you push. Because Roo Code runs locally with BYOK (bring your own key), your code and credentials never pass through third-party servers during these checks.
+
+**Roo Code turns the security patterns that experienced developers internalized over years into automated guardrails that run on every task.**
+
+## Traditional approach vs. guardrail-first approach
+
+| Dimension                   | Traditional Vibe Coding         | Guardrail-First Workflow         |
+| --------------------------- | ------------------------------- | -------------------------------- |
+| Secret detection            | Manual review or none           | Automated scanning before commit |
+| Learning curve              | Discover mistakes in production | Catch mistakes before they ship  |
+| API key exposure risk       | High for new builders           | Reduced through pre-commit hooks |
+| Feedback timing             | After deployment or breach      | During development, before push  |
+| Security knowledge required | Years of experience             | Encoded in tooling defaults      |
+
+## Frequently asked questions
+
+### What is vibe coding and why does it create security risks?
+
+Vibe coding refers to the practice of describing what you want in natural language and letting AI generate the code. The speed is real, but new builders often lack the security patterns that experienced developers have internalized. This creates blind spots around secrets management, authentication, and input validation that can lead to exposed API keys and breached prototypes.
+
+### How do API keys get accidentally exposed on GitHub?
+
+Most accidental exposures happen when developers commit `.env` files or hardcode credentials directly in source files without adding them to `.gitignore`. Public repositories are continuously scraped by bots looking for exposed secrets. Once a key is pushed, even briefly, it should be considered compromised.
+
+### Can Roo Code help prevent accidental secret exposure?
+
+Yes. Roo Code closes the loop by running checks and iterating based on results. You can configure the agent to scan for secrets in staged files, verify `.gitignore` patterns, and block commits that contain credentials. Because Roo Code runs locally with your own API keys, your code stays on your machine during these checks.
+
+### What should I do if I accidentally pushed an API key to a public repo?
+
+Immediately revoke the exposed key through your provider's dashboard and generate a new one. Remove the file from your repository history using tools like `git filter-branch` or BFG Repo-Cleaner. Add the file pattern to `.gitignore` to prevent future commits. Assume the key was scraped the moment it was public.
+
+### Are pre-commit hooks enough to prevent all security issues?
+
+Pre-commit hooks catch common mistakes like committed secrets and missing `.gitignore` entries, but they are one layer in a defense-in-depth approach. You also need secure deployment pipelines, runtime monitoring, and regular dependency audits. The goal is to make the obvious mistakes impossible while building awareness of the less obvious ones.
diff --git a/apps/web-roo-code/src/content/blog/we-shipped-a-stealth-model-in-24-hours-without-leaking-the-provider.md b/apps/web-roo-code/src/content/blog/we-shipped-a-stealth-model-in-24-hours-without-leaking-the-provider.md
new file mode 100644
index 00000000000..0c0adb18fec
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/we-shipped-a-stealth-model-in-24-hours-without-leaking-the-provider.md
@@ -0,0 +1,122 @@
+---
+title: We Shipped a Stealth Model in 24 Hours Without Leaking the Provider
+slug: we-shipped-a-stealth-model-in-24-hours-without-leaking-the-provider
+description: How OpenRouter's team audited error shapes, message IDs, and tokenization patterns to ship an unreleased OpenAI model without fingerprinting the provider.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - api-integration
+    - operational-security
+    - ai-infrastructure
+    - developer-workflows
+status: draft
+publish_date: "2025-04-16"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The error messages leak the provider. The message IDs match their API schema. You have 24 hours.
+
+That was the situation when OpenAI offered OpenRouter the chance to trial an unreleased model. The clock started ticking from "go live," and every API response was a potential fingerprint.
+
+## The threat model
+
+You're routing requests to a model that doesn't officially exist yet. Every error shape, every message ID format, every tokenization pattern is a clue. The AI Twitter crowd reverse-engineers APIs for fun. They've already mapped the tool calling signatures of every major provider.
+
+Your job: buy enough time for a two-week trial without being the team that leaked the source.
+
+## The scramble
+
+The OpenRouter team had about 24 hours from approval to go-live. Not 24 hours to build something new. 24 hours to audit everything that could fingerprint the upstream provider.
+
+> "We did that in about 24 hours from being given the go live to how do we make sure we don't leak it ourselves and ruin this opportunity. It was a hectic 24 hours with a lot of double and triple checking."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=482)
+
+The checklist looked something like this:
+
+1. **Error shapes:** Different providers return errors in different formats. A 429 from OpenAI looks different from a 429 from Anthropic. They needed to normalize or obfuscate those responses.
+
+2. **Message IDs:** API responses often include IDs that follow provider-specific patterns. "chatcmpl-" is a dead giveaway.
+
+3. **Tokenization patterns:** The way a model chunks text into tokens varies by architecture. Sophisticated users can infer the model family from how it handles edge cases.
+
+4. **Tool calling shapes:** The structure of function calls and tool use responses differs between providers. Another fingerprint.
+
+> "We obfuscated the error shapes. We changed the IDs in the messages. We did a couple of things here and there just to make sure."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=460)
+
+## The catch
+
+It worked. Sort of.
+
+The obfuscation held for the casual observer. But the "nerdier people in the AI scene" still figured it out.
+
+> "Of course, the nerdier people in the AI scene would be able to tell the differences between tokenization and tool calling shapes and all these kinds of things that ended up popping up on Twitter that we knew were likely to happen."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=452)
+
+The team knew this would happen. The goal was never perfect secrecy. It was operational security for a controlled trial: prevent accidental leaks, discourage casual identification, and accept that determined reverse-engineers would figure it out anyway.
+
+For a two-week trial window, "good enough" was the right bar.
+
+## The naming game
+
+A side note: the model names that emerged from this period, Quazar Alpha and Optimus Alpha, were brainstormed internally. The Quazar name allegedly had GPT-4.5 contributing to the brainstorm. Sometimes you ship a stealth model and let another model name it.
+
+## Why this matters for your work
+
+This isn't just an OpenRouter story. It's a pattern for any team shipping something before you're ready to talk about it publicly.
+
+The lesson: assume sophisticated users will reverse-engineer your dependencies. Your operational security goal isn't "nobody finds out." It's "we control the timeline of the announcement."
+
+That means:
+
+- Audit your error responses for upstream fingerprints
+- Normalize or obfuscate ID formats that leak provider info
+- Accept that tokenization and behavioral patterns will get discovered; plan for that timeline
+- Define "good enough" for your window, not "perfect" for all time
+
+If you're shipping integrations with third-party APIs you'd rather not advertise yet, start with the error shapes. That's where most accidental leaks happen.
+
+## How Roo Code handles multi-provider API complexity
+
+When you work with AI coding agents that support multiple providers, the operational complexity multiplies. Roo Code's BYOK (Bring Your Own Key) architecture means you connect directly to your chosen provider - OpenAI, Anthropic, Google, or others through OpenRouter - without an intermediary layer that could expose provider fingerprints.
+
+This matters for teams building internal tools or prototyping with pre-release models. Because Roo Code closes the loop by running commands, executing tests, and iterating on results locally, your API interactions stay between you and your provider. There's no middleware normalizing your requests or responses in ways that could leak implementation details.
+
+For developers who need to swap between providers without changing their workflow, Roo Code's model-agnostic design lets you iterate on the same task across different backends while maintaining consistent behavior in your development environment.
+
+## Stealth shipping: old approach vs. new approach
+
+| Dimension      | Old approach                     | New approach                                 |
+| -------------- | -------------------------------- | -------------------------------------------- |
+| Error handling | Pass through raw provider errors | Normalize error shapes to generic formats    |
+| Response IDs   | Use provider-native ID formats   | Generate neutral IDs that don't fingerprint  |
+| Timeline goal  | Perfect secrecy indefinitely     | Controlled window until planned announcement |
+| Tokenization   | Accept as implementation detail  | Recognize as fingerprint; plan for discovery |
+| Tool calling   | Assume format is invisible       | Audit for provider-specific patterns         |
+
+## Frequently asked questions
+
+### Why do error shapes matter for operational security?
+
+Error responses often include provider-specific formatting, status codes, and message structures. A rate limit error from OpenAI has different fields than one from Anthropic. Sophisticated users compare these patterns against known API schemas to identify which upstream service you're actually calling.
+
+### How long can you realistically hide a provider integration?
+
+For most teams, the goal should be days to weeks, not permanent secrecy. Determined reverse-engineers will eventually identify behavioral patterns like tokenization quirks and tool calling formats. Plan your announcement timeline around "good enough" operational security rather than perfect obscurity.
+
+### What's the first thing to audit when shipping a stealth integration?
+
+Start with your error responses. They're the most common source of accidental leaks because developers often pass through raw upstream errors without sanitization. Normalize error formats before worrying about subtler fingerprints like message IDs or tokenization patterns.
+
+### How does Roo Code help when working with multiple AI providers?
+
+Roo Code uses BYOK (Bring Your Own Key) to connect directly to your chosen provider without intermediate processing. This architecture keeps your API interactions transparent and avoids adding layers that could expose or mask provider details. You maintain full control over which models you use and how responses are handled in your development workflow.
+
+### Should you obfuscate everything or just the obvious fingerprints?
+
+Focus on the obvious fingerprints first: error shapes, message ID formats, and response headers. Subtle patterns like tokenization behavior and tool calling structures will eventually get discovered by motivated researchers. The goal is controlling your announcement timeline, not achieving permanent invisibility.
diff --git a/apps/web-roo-code/src/content/blog/we-trust-a-junior-who-joined-yesterday-more-than-an-ai-agent.md b/apps/web-roo-code/src/content/blog/we-trust-a-junior-who-joined-yesterday-more-than-an-ai-agent.md
new file mode 100644
index 00000000000..537909ab5d7
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/we-trust-a-junior-who-joined-yesterday-more-than-an-ai-agent.md
@@ -0,0 +1,126 @@
+---
+title: We Trust a Junior Who Joined Yesterday More Than an AI Agent
+slug: we-trust-a-junior-who-joined-yesterday-more-than-an-ai-agent
+description: Why engineering teams trust new hires to approve PRs but not AI agents - and what organizational scaffolding is actually needed for AI-assisted code review adoption.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-code-review
+    - engineering-leadership
+    - developer-productivity
+    - team-processes
+status: draft
+publish_date: "2025-10-08"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+A two-year engineer who joined your team yesterday can approve a PR that ships to production.
+
+An AI agent that has processed your entire codebase cannot.
+
+This is the current state of AI code review adoption in most organizations. Not because the models lack capability. Because the organizational scaffolding does not exist yet.
+
+## The double standard
+
+Most engineering teams do not require their most senior person to review every line of code. They trust a distribution of reviewers with varying experience levels. A developer with two years of experience, on their first day, can review and approve changes that reach users.
+
+Yet when evaluating AI-assisted review, teams implicitly raise the bar to "would our best engineer trust this completely?"
+
+> "Person who joined the team yesterday and is two years of their career is okay to review a PR and it get merged and go to users but this agent and model is not... I think that we as humans have an inherent bias there."
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=3776)
+
+The bias is not irrational. It reflects something real: we have established processes for onboarding humans but not for onboarding AI reviewers.
+
+## The actual blocker
+
+The question engineering leaders ask is usually "Is the AI good enough?" The question they should ask is "Do we have the documentation, processes, and prompts to get consistent results?"
+
+> "I don't think it's an issue of AI doesn't cross a threshold at this point. It's teams' ability to have documentation, have processes, have prompts in a way to get there."
+>
+> Elliot, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=3814)
+
+The capability gap closed faster than the process gap. Models can now reference real diffs, understand context across files, and cite specific lines. What they cannot do is compensate for missing style guides, undocumented architectural decisions, or tribal knowledge that exists only in Slack threads.
+
+When a junior engineer joins, they absorb this context through onboarding, pairing sessions, and repeated code review feedback. The process exists because teams have been onboarding humans for decades.
+
+AI reviewers get dropped into codebases with none of that scaffolding.
+
+## What maturity looks like
+
+No team we have encountered has reached full automation: AI writes the code, AI reviews the code, code ships without human involvement. That is not the near-term state.
+
+> "I think we've yet to encounter a company that is at the maturity with AI reviews and kind of automation to where AI is going to write the code and it's going to get merged out to users without a human doing anything."
+>
+> Hannes Rudolph, [Roo Cast S01E13](https://www.youtube.com/watch?v=fFUxIKH-t7o&t=3718)
+
+What organizations can reach is a middle state: AI handles first-pass review, flags issues, and surfaces context. Humans make the final call. This mirrors how junior reviewers work: they add value, catch issues, and learn from corrections.
+
+The path to that state is documentation and process work, not waiting for a smarter model.
+
+## The investment required
+
+For teams considering AI-assisted review, the honest assessment is:
+
+**What you need in place:**
+
+- Written style guides that a model can reference
+- Documented architectural decisions that explain the "why" behind patterns
+- Clear review rubrics (what matters, what does not)
+- Explicit boundaries for what AI review covers versus what requires human judgment
+
+**What you do not need:**
+
+- A model that never makes mistakes
+- Complete automation from day one
+- Buy-in from every engineer before piloting
+
+The teams that move fastest treat AI review like onboarding a new team member: invest in the documentation, set clear expectations, and iterate on feedback.
+
+## Traditional onboarding vs. AI reviewer onboarding
+
+| Dimension               | Human Junior Engineer                             | AI Code Reviewer                   |
+| ----------------------- | ------------------------------------------------- | ---------------------------------- |
+| Context absorption      | Pairing sessions, Slack threads, tribal knowledge | Requires explicit documentation    |
+| Style guide access      | Learns through feedback over weeks                | Needs written guides from day one  |
+| Architectural decisions | Absorbs through code review corrections           | Cannot infer undocumented "why"    |
+| Trust timeline          | Gradual, relationship-based                       | Binary - either enabled or not     |
+| Error handling          | Coached through mistakes                          | Often disabled after first failure |
+
+## How Roo Code closes the loop on AI-assisted review
+
+Roo Code addresses the AI reviewer scaffolding problem by letting teams bring their own keys (BYOK) and configure review workflows that match their existing processes. Rather than replacing human judgment, Roo Code closes the loop by running first-pass analysis, flagging issues with specific line citations, and surfacing relevant context from your codebase - then presenting everything for human approval before any changes merge.
+
+The key insight: AI code review readiness is about documentation and process maturity, not model capability. Teams that invest in written style guides and architectural decision records can leverage AI reviewers effectively, while those with tribal knowledge locked in Slack channels will struggle regardless of which model they choose.
+
+## Why this matters for your organization
+
+For a 20-person engineering team reviewing PRs every day, first-pass review time compounds quickly. If AI review can handle initial passes on straightforward changes while humans focus on complex decisions, you reclaim hours without changing your merge requirements.
+
+The barrier is not capability. It is readiness. And readiness is work you control.
+
+If your team has undocumented style guides and tribal knowledge, the first step is not evaluating AI models. It is writing things down.
+
+## Frequently asked questions
+
+### Why do teams trust junior engineers but not AI reviewers?
+
+Teams have decades of established processes for onboarding humans - pairing sessions, feedback loops, and gradual trust-building over time. AI reviewers get dropped into codebases without any of that scaffolding. The double standard reflects missing organizational infrastructure, not a rational assessment of capability differences.
+
+### What documentation do I need before trying AI-assisted code review?
+
+You need written style guides that a model can reference, documented architectural decisions explaining the "why" behind patterns, clear review rubrics defining what matters, and explicit boundaries for what AI review covers versus what requires human judgment. Without these, both junior engineers and AI reviewers will struggle.
+
+### Can Roo Code fully automate code review for my team?
+
+No team has reached full automation where AI writes and reviews code without human involvement. Roo Code supports a middle state where AI handles first-pass review and humans make final decisions. This mirrors how junior reviewers add value while senior engineers retain approval authority.
+
+### How long does it take to get value from AI code review?
+
+Teams that already have strong documentation see value within weeks. Teams with tribal knowledge locked in Slack threads need to invest in writing things down first. The timeline depends on your documentation maturity, not the AI model's capability.
+
+### What happens when AI code review makes mistakes?
+
+The same thing that happens when junior reviewers make mistakes - senior engineers catch issues during final review and provide feedback. The difference is that most organizations coach junior engineers through errors while disabling AI review entirely after first failures. Treating AI reviewers like team members means iterating on prompts and documentation rather than abandoning the approach.
diff --git a/apps/web-roo-code/src/content/blog/when-all-your-tests-pass-but-nothing-works.md b/apps/web-roo-code/src/content/blog/when-all-your-tests-pass-but-nothing-works.md
new file mode 100644
index 00000000000..bbacff52ee5
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/when-all-your-tests-pass-but-nothing-works.md
@@ -0,0 +1,121 @@
+---
+title: When All Your Tests Pass But Nothing Works
+slug: when-all-your-tests-pass-but-nothing-works
+description: Why orchestration workflows fail at integration boundaries and how human checkpoints catch what parallel agents miss.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - orchestration
+    - testing
+    - ai-agents
+    - integration
+status: draft
+publish_date: "2025-07-23"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Five hundred tasks. All passing.
+
+You load the app. Blank page.
+
+## The orchestration trap
+
+You broke the project into subtasks. Each subtask got its own agent. Each agent did its job. Tests passed. Coverage looked fine. The CI pipeline was green across the board.
+
+Then you opened the browser.
+
+Nothing. A blank page staring back at you. Five hundred tasks completed, and the application doesn't render.
+
+> "I had like 500 tasks passing but nothing was working like I couldn't see anything my page was just blank."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=375)
+
+This is the orchestration trap. Spec-driven development tools promise to parallelize work: break the project into pieces, assign each piece to an agent, let them run independently, merge the results. The theory is sound. The integration step is where it falls apart.
+
+## Why sub-agents don't talk to each other
+
+The pattern is predictable once you see it. Each sub-agent works against its own spec. It writes code that satisfies its tests. It doesn't know what the other agents are building. It doesn't communicate about contracts, interfaces, or handoff points.
+
+Agent A builds the auth module. Agent B builds the dashboard. Agent A exports a function called `getUser()`. Agent B expects a function called `getCurrentUser()`. Both agents pass their tests. The application crashes on load.
+
+> "I feel like this is the problem with orchestration workflows or tasks dividing something into smaller tasks and giving it to individual agents. I feel like the integration part that glues all of it together it's not good enough for now."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=477)
+
+The integration layer, the thing that glues the pieces together, is the weakest link in the chain. Individual task completion is easy to verify: run the test, check the output. Cross-task integration is harder to specify and harder to test in isolation.
+
+## The workaround: human checkpoints
+
+Until orchestration tools get smarter about contracts and handoffs, the fix is manual verification at task boundaries.
+
+Don't let 500 tasks run to completion before you check if the app loads. Insert checkpoints. After the first five tasks complete, verify the foundation. After the auth module ships, verify it integrates with the shell. After each major boundary, run the app.
+
+> "I think the solution to this might be to add some human in the middle you know when you're creating the plan when you're dividing all of these tasks add some verification points so the user can test like everything we have so far."
+>
+> Guest, [Roo Cast S01E02](https://www.youtube.com/watch?v=Hjw7rUlGLPs&t=494)
+
+This feels like a step backward. The whole point of parallelizing work was to remove the human bottleneck. But the alternative is worse: waiting until everything is "done" and discovering that nothing works.
+
+## The tradeoff
+
+Checkpoints slow you down. They interrupt the parallel execution model. They require someone to actually load the app and click around.
+
+But they catch integration failures early, when the fix is small. A mismatched interface after five tasks is a ten-minute fix. A mismatched interface after 500 tasks is an archaeology project.
+
+The cost of verification is predictable. The cost of late-stage integration debugging is not.
+
+## Why this matters for your team
+
+For a Series A - C team running spec-driven workflows on a new feature, this pattern hits hard. You kicked off the orchestrator on Friday. You expected to review a working PR on Monday. Instead, you're debugging why the app won't start.
+
+The compounding effect is real. If one integration failure takes two hours to diagnose, and three boundaries failed silently, you've lost a day. That's a day you planned to spend on the next feature.
+
+The shift: treat orchestration output as drafts, not finished work. Verify integration at boundaries. Keep the human in the loop where contracts meet.
+
+## How Roo Code closes the loop on integration failures
+
+Roo Code addresses integration failures by keeping a human in the loop at every stage of the workflow. Unlike spec-driven orchestration tools that run hundreds of tasks before surfacing results, Roo Code closes the loop by running commands, observing outcomes, and iterating based on real feedback.
+
+With BYOK (Bring Your Own Key), you control the model and the cost of each verification step. You can configure Roo Code to run your test suite, load the app, and report what it sees before moving to the next task. The agent doesn't just check if tests pass - it can verify that the application actually renders.
+
+**The key difference: Roo Code treats verification as part of the task, not something that happens after 500 tasks complete.**
+
+## Orchestration approaches compared
+
+| Dimension           | Spec-driven orchestration                  | Checkpoint-based workflow              |
+| ------------------- | ------------------------------------------ | -------------------------------------- |
+| Task execution      | Parallel, independent agents               | Sequential or staged with verification |
+| Integration testing | Deferred until all tasks complete          | Continuous at each boundary            |
+| Failure detection   | Late, often after hundreds of tasks        | Early, within the first few tasks      |
+| Debugging cost      | High - tracing through 500 completed tasks | Low - isolated to recent changes       |
+| Human involvement   | Minimal until final review                 | Frequent at integration points         |
+
+## The checkpoint question
+
+When you break a project into parallel tasks, ask: where are the integration boundaries? Those are your verification points.
+
+Don't wait for 500 green checkmarks. Check the app loads after five.
+
+## Frequently asked questions
+
+### Why do all my tests pass but the application doesn't work?
+
+Each agent or subtask runs against its own spec in isolation. Tests verify that individual components meet their specifications, but they don't verify that components communicate correctly with each other. Interface mismatches, missing exports, and contract violations only appear when components attempt to integrate at runtime.
+
+### How often should I add verification checkpoints?
+
+Add a checkpoint at every integration boundary - wherever two independently developed components need to communicate. For a typical feature, this might mean verifying after the data layer, after the API layer, and after the UI layer. The goal is to catch mismatches before they compound.
+
+### Does adding checkpoints defeat the purpose of parallel development?
+
+Checkpoints add overhead, but they provide predictable overhead. A two-minute manual verification after every five tasks is cheaper than a two-hour debugging session after 500 tasks. The tradeoff favors early detection when integration complexity is high.
+
+### How does Roo Code help prevent the orchestration trap?
+
+Roo Code closes the loop by running commands and observing outcomes as part of each task. Instead of waiting for a final integration step, you can configure verification steps that load the app, run integration tests, or check that components communicate correctly. The agent iterates based on real results, not just spec compliance.
+
+### What's the first thing I should check when my app shows a blank page?
+
+Check the browser console for errors - interface mismatches often surface as undefined function errors or failed imports. Then trace backward from the entry point to find where the integration boundary failed. The component that loads last is usually where the contract violation lives.
diff --git a/apps/web-roo-code/src/content/blog/when-context-gets-poisoned-cut-your-losses.md b/apps/web-roo-code/src/content/blog/when-context-gets-poisoned-cut-your-losses.md
new file mode 100644
index 00000000000..78ae5532781
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/when-context-gets-poisoned-cut-your-losses.md
@@ -0,0 +1,115 @@
+---
+title: When Context Gets Poisoned, Cut Your Losses
+slug: when-context-gets-poisoned-cut-your-losses
+description: Learn why fighting a poisoned AI context wastes time and tokens, and how the orchestrator pattern lets you restart fresh for better results.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - agentic-workflows
+    - context-management
+    - orchestrator
+    - developer-productivity
+status: draft
+publish_date: "2025-05-14"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Three prompts.
+
+Same broken tool call.
+
+Zero forward progress.
+
+## The poison pattern
+
+You're debugging a failing integration test. The agent makes a tool call that doesn't quite work. You correct it, nudge it back on track, and for a moment it seems to recover.
+
+Then it makes the same mistake again. Or a variation of it. You correct it again. It drifts back.
+
+This isn't the model being dumb. This is the model being consistent with its own context. Every failed tool call in that conversation is now part of the model's "suggestions for future consideration." The bad outputs aren't just errors - they're training data for the rest of the session.
+
+## Why recovery rarely works
+
+The intuition is to fix the mistake and keep going. You've already invested tokens. You've already built up context. Starting over feels wasteful.
+
+But here's the mechanism: once the context window contains a pattern of broken tool calls, the model treats those patterns as valid examples. Even if you successfully redirect it, the poisoned examples are still there, exerting gravitational pull.
+
+> "Once your context has been poisoned with those tool calls, they act like suggestions for future consideration. So even if you get it back on track, there's a decent chance that it's going to actually pull it right back."
+>
+> Hannes Rudolph, [Office Hours S01E06](https://www.youtube.com/watch?v=zPhNXCHJ5xk&t=2764)
+
+You can fight this. You can spend another ten prompts trying to steer the conversation. Sometimes it works. But the odds are against you, and every additional prompt adds tokens to a context that's already compromised.
+
+## The heuristic
+
+The practical rule: stop trying to save a poisoned context. End the task, tell the orchestrator it didn't work, and start fresh.
+
+This feels counterintuitive. You've invested time and tokens. But the math usually favors a clean restart over an extended recovery attempt.
+
+> "My general rule is that I'm using orchestrator and I just end that task and, you know, prompt it, tell it that one didn't work, try it again and go from there."
+>
+> Hannes Rudolph, [Office Hours S01E06](https://www.youtube.com/watch?v=zPhNXCHJ5xk&t=2745)
+
+The orchestrator pattern makes this explicit: treat each task as disposable. If a subtask fails in a way that corrupts its context, terminate it and spawn a fresh attempt. The parent task keeps the high-level goal; the child task starts with a clean slate.
+
+## The tradeoff
+
+This heuristic has a cost. You lose whatever valid context you'd built. If you were three-quarters through a complex refactor, restarting means re-explaining the goal.
+
+But compare that to the alternative: spending another twenty minutes and another dollar in tokens trying to coax a poisoned context back to productivity, only to watch it drift again.
+
+The restart is usually cheaper. Not always. But usually.
+
+## Why this matters for your team
+
+For a team running multiple agentic workflows per day, context poisoning is a silent tax. Developers who try to "save" a broken session end up burning time and tokens on recovery attempts that have low success rates.
+
+The compounding effect: if two developers per day each spend thirty minutes fighting a poisoned context instead of restarting, that's five hours per week of unproductive debugging. Time that could have gone into the next feature.
+
+The shift is cultural. Restarting a task shouldn't feel like failure; it should feel like good hygiene. A clean context is worth more than a recovered one.
+
+If you notice the model repeating the same broken pattern, stop. End the task. Tell the orchestrator what went wrong. Start fresh.
+
+The tokens you "save" by restarting are almost always less than the tokens you'd spend on a failed rescue.
+
+## How Roo Code closes the loop on context management
+
+Roo Code's orchestrator mode treats context hygiene as a first-class concern. When you run complex, multi-step tasks, the orchestrator spawns subtasks that each operate with their own isolated context window. If a subtask's context becomes poisoned, you terminate that specific task and let the orchestrator spawn a fresh attempt - without losing the parent task's high-level understanding of your goal.
+
+This architecture means you spend tokens intentionally on outcomes rather than burning them on recovery attempts. Combined with BYOK (bring your own key), you maintain full visibility into token costs and can make informed decisions about when to cut losses versus when to persist.
+
+**The pattern that works:** Use orchestrator mode for multi-step work. When you detect context drift, end the subtask cleanly and restart. The orchestrator preserves your goal while giving the next attempt a clean slate.
+
+## Context recovery: old approach vs. new approach
+
+| Dimension       | Fighting poisoned context        | Clean restart with orchestrator |
+| --------------- | -------------------------------- | ------------------------------- |
+| Token cost      | Unpredictable, often high        | Predictable, usually lower      |
+| Success rate    | Decreasing with each attempt     | Consistent across attempts      |
+| Developer time  | Minutes to hours of steering     | Seconds to restart              |
+| Context quality | Degraded by failed examples      | Fresh and uncontaminated        |
+| Mental overhead | High frustration, low confidence | Low friction, clear next step   |
+
+## Frequently asked questions
+
+### How do I know when context is poisoned versus when to keep trying?
+
+The signal is repetition. If the model makes the same mistake twice after you've corrected it, or produces variations of a failed approach you've already rejected, the context is likely poisoned. Two repeated failures is the threshold - don't wait for three.
+
+### Does restarting waste all the tokens I've already spent?
+
+It feels that way, but the math doesn't support it. The tokens spent on a poisoned context have diminishing returns. Each new prompt adds to a compromised foundation. A restart typically costs fewer total tokens than an extended recovery attempt, and produces better outcomes.
+
+### How does Roo Code's orchestrator mode help with context poisoning?
+
+Roo Code's orchestrator mode isolates subtasks in their own context windows. When a subtask's context becomes poisoned, you can terminate just that subtask and spawn a fresh attempt. The parent task retains the high-level goal, so you don't re-explain everything from scratch - just the specific subtask that failed.
+
+### Should I always use orchestrator mode for complex tasks?
+
+For multi-step work where context poisoning is a risk, orchestrator mode provides natural boundaries. Each subtask can fail independently without contaminating the broader effort. For simple, single-step tasks, direct mode works fine - but the moment complexity increases, orchestrator mode pays for itself in context hygiene.
+
+### What should I tell the orchestrator when I end a failed subtask?
+
+Be specific about what didn't work. Instead of "that failed," say "the tool call to X produced error Y, and attempts to correct it caused drift." This gives the orchestrator information to potentially adjust its approach on the next attempt, rather than repeating the same strategy.
diff --git a/apps/web-roo-code/src/content/blog/when-demand-outstrips-supply-rate-limits-arent-a-pricing-problem.md b/apps/web-roo-code/src/content/blog/when-demand-outstrips-supply-rate-limits-arent-a-pricing-problem.md
new file mode 100644
index 00000000000..0ba8b26899b
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/when-demand-outstrips-supply-rate-limits-arent-a-pricing-problem.md
@@ -0,0 +1,125 @@
+---
+title: When Demand Outstrips Supply, Rate Limits Aren't a Pricing Problem
+slug: when-demand-outstrips-supply-rate-limits-arent-a-pricing-problem
+description: Rate limit errors on experimental AI models like Gemini 2.5 Pro aren't billing issues - they're supply problems. Learn why adding credits won't help and how to build fallback routing strategies.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - rate-limits
+    - model-routing
+    - ai-infrastructure
+    - developer-workflow
+status: draft
+publish_date: "2025-04-16"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Error: 429 Too Many Requests
+
+You added credits. You upgraded your plan. You still can't get a response.
+
+The rate limit error isn't about your account. It's about 10 million tokens per minute of capacity from Google, and two to five times more demand than that capacity can serve.
+
+## The quota trap
+
+You're debugging a production issue. You've picked Gemini 2.5 Pro Experimental because it crushed the benchmarks. You send a request. Rate limit. You wait. You retry. Rate limit again.
+
+Here's where it gets worse: every failed request counts against your daily quota.
+
+> "When you shoot out a request to Gemini 2.5 Pro experimental and you get a rate limit error from Google, not necessarily from us because there is so much capacity or so much demand, that'll count against your 80 requests per day."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=2781)
+
+So you're burning quota on failures. And the failures aren't your fault. They're a supply problem masquerading as a pricing problem.
+
+## Why adding credits doesn't fix it
+
+The instinct is to throw money at rate limits. Buy more credits. Upgrade the tier. The dashboard should turn green.
+
+But rate limits on experimental models aren't about your spend. They're about infrastructure capacity. Google is offering bleeding-edge inference at experimental pricing, which means they're subsidizing the compute. They can't scale it infinitely without burning cash.
+
+> "Even with that pretty insane capacity number, there is so much demand for the model. There is two to five times more requests made to the model per minute than Open Router can reasonably serve."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=770)
+
+Two to five times more demand than capacity. That's not a billing issue. That's a queue longer than the service can process.
+
+## The demand spike nobody planned for
+
+When a model blows benchmarks out of the water, everyone wants to use it immediately. The capacity planning that worked for the previous model doesn't account for viral adoption.
+
+> "2.5 pro came out from Google and it blew all the benchmarks out of the water... and I don't think anybody was ready for it to have as much demand and when I say anybody I include Google."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=703)
+
+This is the pattern: a model launches, benchmarks circulate, and suddenly every developer tool routing to that model sees a traffic spike. The model provider wasn't ready. The routing layer wasn't ready. Your workflow breaks.
+
+## The tradeoff
+
+You have two choices when demand outstrips supply:
+
+**Wait for capacity to catch up.** Experimental tiers eventually stabilize. Google will add capacity. The 2x-5x demand gap will narrow. But "eventually" doesn't help when you're debugging production at 3pm.
+
+**Route around the bottleneck.** Use a different model for reliability. Accept that the benchmark-topping model isn't available at the reliability level your workflow requires. Pick a model that's slightly less capable but actually responds.
+
+Neither option is ideal. That's the tradeoff.
+
+## Why this matters for your team
+
+For a five-person team shipping daily, rate limit failures compound. If two developers hit a 429 during a debugging session, they context-switch to something else. The debugging session extends. The PR sits. The deploy waits.
+
+The cost isn't the credits you burned on failed requests. It's the time lost while your team routes around infrastructure constraints they didn't know existed.
+
+Understanding the difference between "I need to pay more" and "the model is oversubscribed" changes how you plan. You stop throwing credits at rate limits and start building fallback routing.
+
+## How Roo Code handles model routing with BYOK
+
+Rate limit failures interrupt the feedback loop between writing code and seeing results. Roo Code closes the loop by letting you configure multiple model providers with your own API keys (BYOK), so when one model hits capacity constraints, you can route to an alternative without leaving your editor.
+
+Because Roo Code doesn't mark up token costs or lock you into a single provider, you control where your requests go. When Gemini 2.5 Pro Experimental is oversubscribed, you switch to Claude or GPT-4 in your configuration. The agent continues running tests, iterating on failures, and proposing diffs while you decide which model fits your reliability requirements.
+
+**Citable summary:** Roo Code's BYOK model lets developers route around rate-limited models by configuring fallback providers directly, avoiding the quota trap where failed requests burn daily limits on oversubscribed experimental models.
+
+## Comparing approaches to rate limit failures
+
+| Dimension            | Throwing Credits at the Problem        | Building Fallback Routing                 |
+| -------------------- | -------------------------------------- | ----------------------------------------- |
+| Root cause addressed | No - treats billing as the issue       | Yes - treats supply as the issue          |
+| Failed request cost  | Quota burned on retries                | Requests routed to available models       |
+| Time to resolution   | Unknown - depends on provider capacity | Immediate - fallback responds             |
+| Team impact          | Developers blocked, context-switching  | Workflow continues with alternative model |
+| Long-term strategy   | Reactive spending                      | Proactive infrastructure planning         |
+
+## What to do about it
+
+If you're hitting rate limits on an experimental model:
+
+1. Check if failed requests count against your quota. (On Gemini experimental, they do.)
+2. Stop retrying the same model. Route to a stable alternative.
+3. Track which models are oversubscribed and build fallbacks before the next benchmark drop.
+
+Rate limits are a supply problem. The fix is routing, not spending.
+
+## Frequently asked questions
+
+### Why do rate limits persist after I add credits or upgrade my plan?
+
+Rate limits on experimental models reflect infrastructure capacity, not your billing tier. When demand exceeds supply by 2-5x, no amount of spending gives you priority access to compute that doesn't exist yet. The provider is subsidizing experimental pricing and cannot scale infinitely.
+
+### Do failed requests from rate limits count against my daily quota?
+
+On many experimental model tiers, yes. Gemini 2.5 Pro Experimental counts 429 errors against your 80 requests per day limit. This means retrying an oversubscribed model burns quota on failures, compounding the problem.
+
+### How long do rate limit issues on new models typically last?
+
+It varies by provider and demand. After a benchmark-topping model launches, expect 2-4 weeks of instability while the provider adds capacity. Planning for this window with fallback models prevents workflow disruption.
+
+### How does Roo Code help when my preferred model is rate-limited?
+
+Roo Code supports BYOK (bring your own key) across multiple providers. You configure your API keys for Claude, GPT-4, Gemini, and others directly in the extension. When one model is oversubscribed, you switch providers in your configuration without changing your workflow or losing context.
+
+### Should I always use the highest-benchmark model for coding tasks?
+
+Not if reliability matters more than marginal capability gains. A model that responds consistently lets Roo Code close the loop - running tests, iterating on failures, and proposing fixes. A model that returns 429 errors breaks that loop regardless of its benchmark scores.
diff --git a/apps/web-roo-code/src/content/blog/when-everyone-can-open-a-pr-you-need-a-new-approval-process.md b/apps/web-roo-code/src/content/blog/when-everyone-can-open-a-pr-you-need-a-new-approval-process.md
new file mode 100644
index 00000000000..8df90f9437b
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/when-everyone-can-open-a-pr-you-need-a-new-approval-process.md
@@ -0,0 +1,122 @@
+---
+title: When Everyone Can Open a PR, You Need a New Approval Process
+slug: when-everyone-can-open-a-pr-you-need-a-new-approval-process
+description: How to implement cross-functional approval gates when AI agents enable non-engineers to generate production code. Learn the three-role review process that keeps agent-generated PRs safe.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-governance
+    - code-review
+    - team-workflows
+    - enterprise-adoption
+status: draft
+publish_date: "2025-10-01"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+"People were pretty scared of what this meant and pretty nervous about what was going to develop."
+
+That's Audrey describing the reaction when Roo Vet rolled out Slack-based agents to the entire company. Not just engineering. Everyone.
+
+## The governance gap
+
+You're an engineering lead at a 50-person company. You've been piloting AI agents with your dev team for three months. The results are promising: faster prototypes, fewer context switches, PRs that actually reference the codebase.
+
+Leadership sees the productivity numbers and asks the obvious question: why limit this to engineering?
+
+So you roll it out company-wide. Marketing can prototype landing pages. Product can test feature ideas. Ops can build internal tools.
+
+Then the PR queue starts filling up with changes from people who have never shipped production code. Some of the diffs look reasonable. Some touch authentication. Some reference files that don't exist. Product and design teams see PRs opened against their domains without any conversation first.
+
+The fear is reasonable. The old flow assumed that anyone opening a PR understood the downstream implications. That assumption breaks when the bar to generate code drops to "type a sentence in Slack."
+
+## The fix: cross-functional approval gates
+
+Roo Vet's solution was explicit governance. Every agent-generated PR now requires sign-off from three roles: a PM, a designer, and an engineer.
+
+> "One thing we had to do is we had to define a pretty good process for managing those. And the way we did it was essentially to have to require an approval from a PM, a designer, and an engineer on any @roomote PR that gets opened."
+>
+> John Sterns, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=1452)
+
+The three-role requirement ensures that:
+
+1. **Engineering** validates the technical correctness and safety
+2. **Product** confirms the change aligns with roadmap and priorities
+3. **Design** catches UX implications before they ship
+
+To make this sustainable, they added a rotating on-call schedule to monitor the queue. Someone is always responsible for reviewing agent-generated PRs, so they don't pile up or slip through.
+
+## The shift in mental model
+
+The old PR flow assumed alignment before the code existed. Someone has a problem, discusses it, gets buy-in, then writes the code. The PR is a formality at that point.
+
+Agent-generated PRs flip this. The code exists first. The alignment happens at review time.
+
+> "Almost every engineering team I've worked on, the flow has been that someone opens a PR and then everyone is just working to help get that PR over the line... that's just different in this world where we prototype first."
+>
+> Matt Rubens, [Roo Cast S01E11](https://www.youtube.com/watch?v=bqLEMZ1c9Uk&t=1741)
+
+This means the review process has to do work that used to happen in planning meetings. The PR review is where you ask: should this exist? Does this fit? Who does this affect?
+
+## The tradeoff
+
+Three-role approval adds friction. Every agent-generated PR waits for three people instead of one. That slows the feedback loop.
+
+The alternative is worse. Unreviewed PRs from people who don't understand the codebase lead to incidents. Incidents lead to rollback. Rollback leads to "we tried AI agents and it didn't work."
+
+The friction is intentional. It's the price of keeping the tool enabled for everyone while maintaining quality gates.
+
+## Traditional PR workflow vs. agent-generated PR workflow
+
+| Dimension           | Traditional PR workflow                            | Agent-generated PR workflow                                  |
+| ------------------- | -------------------------------------------------- | ------------------------------------------------------------ |
+| Code origin         | Written by someone who discussed the problem first | Generated from a prompt, often without prior discussion      |
+| Alignment timing    | Happens before coding begins                       | Happens during code review                                   |
+| Reviewer assumption | Author understands downstream implications         | Author may not understand the codebase                       |
+| Approval scope      | Usually one technical reviewer                     | Requires cross-functional sign-off (PM, design, engineering) |
+| Queue management    | Self-regulating based on team capacity             | Needs explicit on-call rotation to prevent backlog           |
+
+## How Roo Code closes the loop on agent governance
+
+When AI agents can generate production code from a single prompt, governance becomes the bottleneck. Roo Code addresses this by closing the loop between code generation and human oversight. Rather than generating code in isolation, Roo Code proposes diffs, runs tests, and iterates based on results while keeping humans in control of what actually ships.
+
+With BYOK (Bring Your Own Key), teams maintain full control over their AI spending and provider relationships. Combined with configurable approval workflows, engineering leads can define exactly which actions require human sign-off before execution. This means you can enable broad access to AI-assisted development while maintaining the quality gates your organization needs.
+
+The key insight from Roo Vet's rollout applies directly: the friction of approval processes is intentional, and tools that make approval workflows configurable rather than all-or-nothing let organizations find the right balance between speed and safety.
+
+## Why this matters for your organization
+
+If you're considering broad AI agent rollout beyond engineering, you're going to hit this governance question. The answer isn't "don't do it" or "trust everyone." The answer is explicit approval processes designed for the new flow.
+
+Questions to answer before rollout:
+
+- Who can open agent-generated PRs?
+- Who must approve them before merge?
+- Who monitors the queue to prevent backlog?
+- What domains are off-limits without prior discussion?
+
+Define the approval process before you enable the agent. The governance structure you build now determines whether broad rollout builds trust or erodes it.
+
+## Frequently asked questions
+
+### Why do agent-generated PRs need different approval processes than regular PRs?
+
+Agent-generated PRs flip the traditional workflow. In conventional development, alignment happens before code exists through planning discussions and design reviews. With AI agents, working code appears first, often from people unfamiliar with the codebase. The review process must now validate both technical correctness and strategic alignment, work that previously happened in planning meetings.
+
+### How many approvers should be required for agent-generated code?
+
+The three-role model (engineering, product, design) provides comprehensive coverage without excessive overhead. Engineering validates technical safety, product confirms roadmap alignment, and design catches UX implications. Fewer roles create blind spots. More roles create bottlenecks that discourage agent use entirely.
+
+### What happens when the approval queue backs up?
+
+Backlogged queues are the most common failure mode for agent governance. Roo Vet solved this with a rotating on-call schedule where someone is always responsible for reviewing agent-generated PRs. Without explicit ownership, PRs pile up, requesters get frustrated, and teams abandon the process.
+
+### How does Roo Code help teams manage agent-generated code review?
+
+Roo Code closes the loop by keeping humans in control of what ships while still enabling AI-assisted development. With configurable approval workflows, teams can define which actions need sign-off. BYOK ensures organizations maintain control over AI costs and provider relationships. This combination lets teams enable broad access to AI coding assistance while maintaining quality gates.
+
+### Should some parts of the codebase be off-limits to agent-generated PRs?
+
+Yes. Authentication, billing, data access layers, and other sensitive domains often require prior discussion before any code changes. Define these boundaries explicitly before rollout. The alternative is discovering them through incidents, which erodes trust in the entire program.
diff --git a/apps/web-roo-code/src/content/blog/when-thinking-models-are-overkill.md b/apps/web-roo-code/src/content/blog/when-thinking-models-are-overkill.md
new file mode 100644
index 00000000000..6b8fe88bfc7
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/when-thinking-models-are-overkill.md
@@ -0,0 +1,133 @@
+---
+title: When Thinking Models Are Overkill
+slug: when-thinking-models-are-overkill
+description: Learn when extended thinking in AI models wastes tokens and time, and how to match reasoning overhead to task complexity for better results.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-models
+    - developer-productivity
+    - cost-optimization
+    - workflows
+status: draft
+publish_date: "2025-07-16"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+More compute doesn't mean better output.
+
+The model thinks for 45 seconds. Edits one translation file. Thinks for 45 seconds again. Seventeen files to go.
+
+You're watching tokens burn on a task that doesn't need reasoning overhead. The thinking is visible. The improvement is not.
+
+## The thinking tax
+
+You have a batch of translation files to update. Same structure, same pattern, seventeen languages. You reach for the capable model because you want accuracy. You enable extended thinking because that's what you do for important tasks.
+
+Then you wait. And wait. The model deliberates on each file as if solving a novel problem. The quality of the output is indistinguishable from the non-thinking run you did last week. But the latency tripled and the token cost doubled.
+
+This is the thinking tax: paying for reasoning overhead on tasks that don't benefit from it.
+
+## Matching overhead to capability
+
+The counterintuitive finding: high-capability models often perform just as well without extended thinking enabled.
+
+> "I feel like Opus is just so good at doing everything that having thinking enabled just doesn't improve anything at all."
+>
+> Guest, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=620)
+
+Teams running Opus without thinking for a month report comparable results to thinking-enabled runs. The model's base capability already handles most coding tasks. The thinking overhead adds latency and cost without moving the needle on output quality.
+
+The practical heuristic: match thinking overhead to task complexity, not to model capability.
+
+## When thinking helps (and when it doesn't)
+
+Extended thinking shines on genuinely novel problems: architectural decisions, complex debugging across multiple systems, ambiguous requirements that need reasoning through. Tasks where the model needs to consider multiple approaches before committing.
+
+Extended thinking wastes tokens on:
+
+- Repetitive edits with consistent patterns
+- Well-defined transformations (translation files, config updates, schema migrations)
+- Tasks where the structure is clear and the model just needs to execute
+
+> "For example here in Roo we have to edit a lot of translation files and sometimes I do it with flash because if I use Gemini 2.5 to edit 17 different language files it's going to think and think for each one of them. So it's like a lot slower and more expensive than just running flash that can do this task."
+>
+> Guest, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=667)
+
+The pattern: use thinking for novelty, skip it for repetition.
+
+## The real tradeoff
+
+This isn't about being cheap. It's about matching resources to requirements.
+
+A five-person team shipping daily faces this decision constantly. Every task runs through the same calculus: does this need the thinking overhead, or is the base model's capability sufficient?
+
+> "I think it depends on the task that you're working on. Like if it's something that can be achieved without thinking then sure you should go without thinking like because the thinking is just going to waste more tokens and take a lot longer to complete the task."
+>
+> Guest, [Office Hours S01E14](https://www.youtube.com/watch?v=mi-3BxpZRgM&t=652)
+
+The tradeoff is explicit: thinking adds latency and cost. If the task doesn't benefit, you're paying twice for the same result.
+
+## Why this matters for your team
+
+For a Series A - C team with limited engineering bandwidth, the compounding effect is significant. If three developers each run five thinking-enabled tasks per day that don't need thinking overhead, you're burning tokens and time on reasoning that doesn't improve outcomes.
+
+The shift isn't "never use thinking." The shift is "default to off, enable when the task requires it."
+
+Repetitive edits, batch transformations, well-structured tasks: run without thinking. Novel problems, architectural decisions, ambiguous debugging: enable thinking.
+
+Your metric should be output quality per task, not compute per task.
+
+## The decision tree
+
+Before enabling extended thinking, ask:
+
+1. Is this task novel, or am I applying a known pattern?
+2. Does the model need to reason through multiple approaches?
+3. Would I expect a senior engineer to "think hard" about this, or just execute?
+
+If the answer to all three is no, skip the thinking overhead.
+
+The capable model is already capable. Don't pay for reasoning on tasks that don't need it.
+
+## How Roo Code helps you spend tokens intentionally
+
+Roo Code's BYOK (bring your own key) model means you control exactly which model runs each task. Because you're paying your provider directly with no markup, the cost feedback is immediate and clear.
+
+With Roo Code's mode system, you can configure different models for different task types. Run a lightweight model like Gemini Flash for batch translation updates and repetitive edits. Switch to Opus or Sonnet with extended thinking for architectural decisions where the reasoning overhead actually improves outcomes. The agent closes the loop by running commands, observing results, and iterating - so you see exactly what each model configuration produces.
+
+**The key insight: intentional token spending means matching model capability and reasoning overhead to task requirements, not defaulting to maximum compute for every task.**
+
+## Thinking overhead vs. base model capability
+
+| Dimension                       | Thinking enabled                                             | Thinking disabled                                           |
+| ------------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------- |
+| Best for                        | Novel problems, architectural decisions, ambiguous debugging | Repetitive edits, batch transformations, well-defined tasks |
+| Latency                         | 2-3x longer per task                                         | Baseline response time                                      |
+| Token cost                      | Higher due to reasoning tokens                               | Standard completion tokens only                             |
+| Output quality on routine tasks | No measurable improvement                                    | Equivalent results                                          |
+| Output quality on complex tasks | Improved reasoning and accuracy                              | May miss edge cases                                         |
+
+## Frequently asked questions
+
+### When should I enable extended thinking on AI coding models?
+
+Enable extended thinking when the task requires genuine reasoning: architectural decisions, debugging across multiple systems, or ambiguous requirements where the model needs to consider multiple approaches. If the task has a clear pattern and structure, the base model's capability is usually sufficient without the thinking overhead.
+
+### Does extended thinking always produce better code?
+
+No. For well-defined tasks like translation file updates, config changes, or schema migrations, thinking-enabled and thinking-disabled runs often produce indistinguishable results. The thinking overhead adds latency and cost without improving output quality on routine tasks.
+
+### How does Roo Code help manage model costs?
+
+Roo Code uses BYOK (bring your own key), so you pay your LLM provider directly with no token markup. You can configure different models for different modes, running lightweight models for repetitive tasks and reasoning-capable models for complex decisions. This lets you match compute to task requirements instead of overpaying for capability you don't need.
+
+### What's a practical rule for choosing thinking vs. non-thinking?
+
+Ask three questions: Is this task novel? Does the model need to reason through multiple approaches? Would a senior engineer need to "think hard" about this? If all three answers are no, skip the thinking overhead. Default to off, enable when the task genuinely requires reasoning.
+
+### How much can teams save by matching model overhead to task type?
+
+The savings compound quickly. If three developers each run five thinking-enabled tasks per day that don't need reasoning overhead, you're paying for 2-3x the latency and significantly more tokens with no quality improvement. Matching overhead to task type can cut costs and wait time substantially on routine work.
diff --git a/apps/web-roo-code/src/content/blog/when-your-evals-hit-99-the-problem-is-the-eval.md b/apps/web-roo-code/src/content/blog/when-your-evals-hit-99-the-problem-is-the-eval.md
new file mode 100644
index 00000000000..ceedd90a06f
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/when-your-evals-hit-99-the-problem-is-the-eval.md
@@ -0,0 +1,119 @@
+---
+title: When Your Evals Hit 99%, the Problem Is the Eval
+slug: when-your-evals-hit-99-the-problem-is-the-eval
+description: Why saturated benchmarks give zero signal when choosing AI coding models, and how to build evals that actually distinguish performance for your team's workflows.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - evals
+    - model-selection
+    - benchmarks
+    - ai-coding
+status: draft
+publish_date: "2025-09-10"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+99% pass rate.
+
+Fifteen models.
+
+Zero signal.
+
+## The fidelity gap
+
+You're picking a model for your team's coding workflows. You pull up the benchmarks: Aider Polyglot, SWE-bench, the usual suspects. The results look great. Everything scores in the 90s. Claude, GPT-5, Gemini, a dozen others. All "work."
+
+You know this isn't true. You've watched one model nail a refactor on the first pass while another spirals into the same broken fix three times. But the benchmark says they're equivalent.
+
+The benchmark is lying. Or more precisely: the benchmark has stopped measuring the thing you care about.
+
+## When models outpace the tests
+
+There was a time when distinguishing models was easy. Sonnet 3.5 worked. Most others didn't. The evals reflected reality because the gap between "capable" and "not capable" was wide enough to see.
+
+That gap closed. Now 10-15 models pass the same evals with similar scores. The benchmarks haven't gotten harder; the models have gotten competent at the specific problems those benchmarks test.
+
+> "I remember when Sonnet 3.5 was the only thing that worked with Roo. And I think the eval reflecting that there's actually like a bunch of models, 10, 15 of them that work pretty well with Roo right now. And that's great. We should celebrate it. But I think now we just need to level up a little bit. We need something harder to test it against."
+>
+> Matt Rubens, [Roo Cast S01E08](https://www.youtube.com/watch?v=uA7NLvGwHAE&t=1652)
+
+The problem isn't that the evals are bad. The problem is that when scores cluster in the high 90s, the eval can no longer distinguish between the top tier.
+
+## The fidelity ceiling
+
+Think of it like a test where everyone scores between 97 and 99. The test isn't wrong. It's just not measuring the differences that matter for your specific use case.
+
+> "I don't think our evals suck. But I think the fidelity when you get in the high 90s is not enough. What we see with GPT-5 and what this GPT-5 Mini thing from last night showed is like GPT-5 is better than our evals."
+>
+> Matt Rubens, [Roo Cast S01E08](https://www.youtube.com/watch?v=uA7NLvGwHAE&t=1618)
+
+The benchmarks that felt definitive a year ago are now saturated. Aider Polyglot, SWE-bench, the Exercism-based coding challenges: these were hard problems when they were created. They're solved problems now.
+
+> "A lot of the traditionally hard coding benchmarks like Aider Polyglot and SWE-bench are getting close to saturated now."
+>
+> Aarush, [Roo Cast S01E08](https://www.youtube.com/watch?v=uA7NLvGwHAE&t=1736)
+
+## What this means for your team
+
+If you're relying on public benchmarks to choose between frontier models, you're flying blind. All you're learning is "these models can solve Exercism problems." You're not learning which one handles your legacy codebase, your specific test patterns, or the ambiguous edge cases that actually slow down your team.
+
+The signal you need isn't in the benchmark. It's in the failures: which model spirals on your actual code, which one finishes tasks on the first pass, which one asks the right clarifying questions instead of guessing wrong confidently.
+
+## Why this matters for Series A to C teams
+
+For a team of 5-10 engineers, picking the wrong model isn't just a token cost issue. It's a velocity issue. If your model choice is based on a saturated benchmark, you might be running a model that looks equivalent on paper but burns 3x the iteration time on the tasks your team actually ships.
+
+The practical move: build your own evals. Not Exercism problems. Your failing tests. Your legacy modules. Your actual PR patterns.
+
+If your current eval shows "they all work," the eval has stopped being useful. The fix isn't to trust the scores. The fix is to make the test harder until the differences show up again.
+
+## The rule
+
+When models cluster at 99%, you need a harder test.
+
+Not because 99% is bad. Because 99% that doesn't distinguish between models is zero information.
+
+Track which model finishes your tasks on the first pass. That's the eval that matters.
+
+## How Roo Code helps you build real evals
+
+Roo Code's BYOK (bring your own key) architecture means you can run any model against your actual codebase without vendor lock-in. Because Roo Code closes the loop - proposing diffs, running tests, and iterating on failures - you get direct signal on which model completes your specific tasks on the first pass versus which one spirals.
+
+Instead of trusting saturated public benchmarks, teams using Roo Code can build evals from their real PR patterns and failing tests. The agent runs the task, you observe the iteration count and outcome, and you have actual data on model performance for your workflows.
+
+**Roo Code turns your codebase into the eval that matters: one that measures first-pass completion on the work your team actually ships.**
+
+## Saturated benchmarks vs. real-world evals
+
+| Dimension            | Saturated public benchmarks        | Codebase-specific evals                     |
+| -------------------- | ---------------------------------- | ------------------------------------------- |
+| Signal quality       | Low - all models cluster at 97-99% | High - real variance on your actual tasks   |
+| Relevance            | Generic coding puzzles             | Your legacy code, test patterns, edge cases |
+| Iteration visibility | Pass/fail only                     | Full loop: diff, test, retry count          |
+| Model switching cost | Unknown until production           | Tested before deployment                    |
+| Maintenance          | Static, solved problems            | Evolves with your codebase                  |
+
+## Frequently asked questions
+
+### Why do public benchmarks stop being useful?
+
+Public benchmarks become saturated when multiple models consistently score in the high 90s. At that point, the benchmark measures "baseline competency" rather than the differences that matter for real-world performance. When 15 models all pass at 97-99%, you have no signal for which one will handle your specific codebase better.
+
+### How do I build evals that actually distinguish model performance?
+
+Use your own failing tests, legacy modules, and actual PR patterns as the eval set. Run different models against these real tasks and measure first-pass completion rate, iteration count, and quality of clarifying questions. The model that finishes your tasks on the first pass is the one that matters for your team.
+
+### Can Roo Code help me test models before committing to one?
+
+Yes. With BYOK, you can switch between any model provider and run tasks against your actual codebase. Because Roo Code closes the loop by running tests and iterating, you see directly how each model performs on your real work before making a team-wide decision.
+
+### What metrics should I track instead of benchmark scores?
+
+Track first-pass completion rate on your actual tasks, average iteration count before success, and the frequency of confident-but-wrong responses. These metrics reveal which model matches your codebase and workflow patterns, not just which model can solve generic coding puzzles.
+
+### How often should I re-evaluate model performance?
+
+Re-evaluate when frontier models release major updates or when your codebase changes significantly. The model that performed best six months ago may not be optimal today. Continuous evaluation using your real tasks ensures you're always running the model that delivers the most velocity for your team.
diff --git a/apps/web-roo-code/src/content/blog/when-your-models-personality-changes-your-workflow-breaks.md b/apps/web-roo-code/src/content/blog/when-your-models-personality-changes-your-workflow-breaks.md
new file mode 100644
index 00000000000..8ecf506813d
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/when-your-models-personality-changes-your-workflow-breaks.md
@@ -0,0 +1,127 @@
+---
+title: When Your Model's Personality Changes, Your Workflow Breaks
+slug: when-your-models-personality-changes-your-workflow-breaks
+description: Model upgrades can break tuned prompts. Learn why capability and predictability diverge, and how to treat model version changes like breaking changes in your AI coding workflow.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - model-upgrades
+    - prompt-engineering
+    - workflow-optimization
+    - ai-coding
+status: draft
+publish_date: "2025-05-07"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The upgrade made it worse.
+
+Not wrong. Not broken. Just different enough that your prompts stopped working.
+
+## The drift
+
+You've been using Claude 3.5 for months. Your prompts are dialed in. You know exactly how to phrase a refactor request to get clean, focused diffs. You know which words make the model stop when you want it to stop.
+
+Then 3.7 ships. More capable. Higher benchmarks. You swap it in expecting better results.
+
+Instead: the same prompt that used to produce a tight fix now produces a sprawling refactor. The model that used to follow your instructions literally now interprets them creatively. Your workflow, the one you spent weeks tuning, breaks.
+
+Not because 3.7 is bad. Because 3.7 is different.
+
+## The mechanism
+
+Model upgrades are not always upgrades for your workflow.
+
+When you tune prompts against a specific model version, you're building a joint understanding. The model learns (in the sense of: responds predictably to) your phrasing. You learn its quirks. The two of you develop a working vocabulary.
+
+Then the provider ships a new version. The vocabulary shifts. The same input produces different output.
+
+> "I think it was 3.5 because although it's less powerful, it listened more to my instructions. It was less back and forth of me telling, 'No, don't do this,' and it was more straightforward towards the task I was trying to do."
+>
+> Thibault, [Office Hours S01E05](https://www.youtube.com/watch?v=Wa8ox5EVBZQ&t=1484)
+
+This is the core tension: capability and predictability are not the same thing. A model can be objectively more capable on benchmarks while being subjectively worse for your specific workflow. The benchmarks measure general performance. Your workflow measures "does it do what I expect when I say this?"
+
+> "You guys had a joint understanding, and then they brought 3.7 along and now the things you say produce different results."
+>
+> Hannes Rudolph, [Office Hours S01E05](https://www.youtube.com/watch?v=Wa8ox5EVBZQ&t=1494)
+
+## The failure mode
+
+The failure mode is subtle. The model doesn't error. It doesn't refuse. It just does something adjacent to what you asked.
+
+You ask for a focused fix. You get a refactor that touches twelve files. You ask it to stop after the first pass. It keeps going because it "noticed" something else. You ask for a diff. You get a diff plus unsolicited advice plus a rewrite of your test file.
+
+> "Claude 3.7 will go off the rails and do a lot of weird things if you don't prompt it correctly."
+>
+> Thibault, [Office Hours S01E05](https://www.youtube.com/watch?v=Wa8ox5EVBZQ&t=2545)
+
+The fix is not "go back to 3.5 forever." The fix is acknowledging that prompt-model coupling is real, and model upgrades require prompt validation.
+
+## The tradeoff
+
+This creates a real operational cost. Every model upgrade becomes a potential workflow regression. You can either:
+
+1. **Pin versions aggressively.** Treat model versions like dependency versions. Don't upgrade until you've tested your prompts against the new version in a staging workflow.
+
+2. **Build more robust prompts.** Write prompts that are less dependent on specific model quirks. More explicit constraints. More structure. Less reliance on implicit understanding.
+
+3. **Accept the tax.** Acknowledge that model upgrades will require re-tuning, and budget time for prompt validation after each major version change.
+
+None of these are free. Pinning versions means missing improvements. Robust prompts take more effort upfront. Accepting the tax means planned rework cycles.
+
+## Why this matters for your workflow
+
+For an engineer with a tuned workflow, a model upgrade can cost hours. You upgrade expecting improvement. Instead, you spend the afternoon figuring out why your prompts produce different results, then re-tuning until the outputs match your expectations again.
+
+The compounding effect is worse for teams. If five engineers each have tuned prompts, a model upgrade is five parallel re-tuning efforts. Without coordination, you get inconsistent results across the team until everyone converges on new phrasing.
+
+The practical response: treat model version changes like breaking changes. Before rolling a new version into production workflows, validate your prompts. Check that the outputs match expectations. If they don't, plan the re-tuning before the rollout, not after.
+
+## The shift
+
+When a model version ships, your first question should not be "is it more capable?" Your first question should be "does it still respond the way I expect to the prompts I've already tuned?"
+
+Validate before you deploy. The upgrade might be an upgrade. Or it might be a regression disguised as progress.
+
+## How Roo Code handles model version changes
+
+Roo Code gives you direct control over which model handles each task through BYOK (bring your own key). You configure your preferred model per mode, so a provider update doesn't force a workflow change until you decide to switch.
+
+When you do upgrade, Roo Code's iterative workflow helps you validate faster. The agent closes the loop by running commands, executing tests, and showing you diffs before applying changes. If a new model version produces unexpected output, you catch it in the approval step, not after the code ships.
+
+**Prompt-model coupling is a real cost. Roo Code's BYOK model and approval-based workflow let you control when you pay that cost, rather than having it imposed by a provider's release schedule.**
+
+## Comparing model upgrade strategies
+
+| Dimension                      | Ad-hoc upgrades             | Version pinning with validation |
+| ------------------------------ | --------------------------- | ------------------------------- |
+| Time to adopt new capabilities | Immediate                   | Delayed until prompts validated |
+| Workflow stability             | Unpredictable after updates | Stable until intentional change |
+| Re-tuning cost                 | Reactive, unplanned         | Planned, budgeted               |
+| Team consistency               | Divergent until convergence | Coordinated rollout             |
+| Risk of production regressions | Higher                      | Lower                           |
+
+## Frequently asked questions
+
+### Why do my prompts break after a model upgrade?
+
+Model versions develop different response patterns even when the underlying architecture is similar. When you tune prompts against a specific version, you build implicit assumptions about how the model interprets your phrasing. A new version may interpret the same words differently, producing adjacent but unwanted outputs.
+
+### Should I always use the latest model version?
+
+Not necessarily. Capability benchmarks measure general performance, not your specific workflow. A newer model may score higher on benchmarks while being worse for your tuned prompts. Test before switching, and only upgrade when the new version actually improves your outcomes.
+
+### How does Roo Code help manage model version changes?
+
+Roo Code uses BYOK (bring your own key), so you control which model version runs your tasks. You can test a new model in a separate mode configuration, validate your prompts against it, and switch only when ready. The approval workflow catches unexpected outputs before they hit your codebase.
+
+### How much time should I budget for re-tuning after a model upgrade?
+
+Plan for at least a few hours per engineer for significant version changes. If your team has multiple tuned prompt sets, coordinate the validation effort to avoid inconsistent results. Treat the re-tuning as scheduled work, not unplanned disruption.
+
+### Can I use different model versions for different tasks?
+
+Yes. With Roo Code's mode system, you can configure different models for different workflows. Use a stable, predictable model for tasks where consistency matters, and experiment with newer versions in isolated contexts until your prompts are validated.
diff --git a/apps/web-roo-code/src/content/blog/why-10-million-token-context-windows-arent-available-yet.md b/apps/web-roo-code/src/content/blog/why-10-million-token-context-windows-arent-available-yet.md
new file mode 100644
index 00000000000..60d71f93cc2
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/why-10-million-token-context-windows-arent-available-yet.md
@@ -0,0 +1,113 @@
+---
+title: Why 10 Million Token Context Windows Aren't Available Yet
+slug: why-10-million-token-context-windows-arent-available-yet
+description: The model exists but the endpoint doesn't. Learn why announced context windows don't match API reality and how cluster economics block long-context inference.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-windows
+    - llm-infrastructure
+    - ai-engineering
+    - gpu-economics
+status: draft
+publish_date: "2025-04-16"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The model exists. The endpoint doesn't.
+
+That's the gap no one explains when they announce a 10 million token context window in a press release.
+
+## The math that breaks
+
+You've read the announcements. Gemini 1.5 Pro with 10 million tokens. The future is here. Except when you try to use it through an API, the context limit is much smaller. Or the latency makes it unusable for real work. Or the endpoint simply isn't available.
+
+The constraint isn't the model. It's the cluster economics.
+
+Serving a 10 million context window request requires a dedicated cluster of 16 to 32 GPUs. That cluster might handle 10, 20, maybe 50 requests per minute. Each request could take minutes to return a response. For a provider running a serverless inference business, this is a nightmare.
+
+> "That 10 million context window node might only be able to serve, I don't know, 10, 20, 50 requests per minute, which is a very, very small number. Those requests might also take minutes to respond to if you are using that 10 million context window."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=2248)
+
+The inference business runs on thin margins. Providers make money by packing as many requests as possible onto their hardware. A 10 million context endpoint does the opposite: it monopolizes expensive GPUs for minutes at a time, serving a handful of users, generating almost no margin.
+
+## Why the announcements don't match reality
+
+Model providers announce capabilities. Infrastructure providers offer endpoints. These are different businesses with different incentives.
+
+When Google announces a 10 million token context window, they're demonstrating what the model architecture can handle. When you try to access it through Vertex AI or a third-party provider, you're asking someone to provision and maintain hardware that loses money on every request.
+
+> "Offering a 10 million context window is extremely compute intensive. It requires a lot of hardware. The inference business is a very very low margin business."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=2156)
+
+The result: announced capabilities that exist in demos but not in production APIs. Or context limits that are technically available but priced so high that no one uses them. Or latency so severe that the workflow breaks before the response arrives.
+
+## Where long context actually happens
+
+If the serverless economics don't work, who uses these capabilities?
+
+Organizations with specific use cases and their own infrastructure. Companies that can justify dedicating a cluster to long-context inference because the alternative (not having it) costs more than the hardware.
+
+> "My guess is that these kinds of deployments are going to be happening on prem for organizations that have specific usage and not are not worried about the costs involved because you know they have a need for it outside of serving it as a serverless endpoint for inference."
+>
+> Tovan, [Office Hours S01E02](https://www.youtube.com/watch?v=hihrUCRwkFM&t=2298)
+
+This is the reality behind the announcements: long-context inference at scale is an on-prem capability for now. The serverless model that makes AI accessible to smaller teams doesn't support it economically.
+
+## Why this matters for your team
+
+For a Series A - C team evaluating AI tooling, this distinction changes how you plan.
+
+If your workflow depends on feeding an entire codebase into a single prompt, you're betting on infrastructure that doesn't exist at accessible price points. The 10 million token context window is real, but the endpoint that serves it affordably isn't.
+
+The practical approach: design workflows that work within current context limits. Use codebase indexing and retrieval to surface relevant context rather than brute-forcing everything into one prompt. Assume that longer context will get cheaper over time, but don't block your roadmap on it.
+
+## The shift to watch
+
+Spare capacity changes this equation. When providers have GPU clusters sitting idle, long-context endpoints become a way to monetize that capacity rather than a margin-destroying obligation. The timeline depends on hardware supply, demand curves, and how much providers are willing to subsidize these deployments to capture market position.
+
+Until then, treat announced context limits as a ceiling, not a floor. Build for what's available today. The 10 million token future will arrive when the infrastructure economics allow it.
+
+## How Roo Code works within context limits
+
+Rather than waiting for mythical 10 million token endpoints, Roo Code closes the loop by working intelligently within today's context constraints. With BYOK (bring your own key), you pay only what your provider charges for inference with no token markup, which matters when context efficiency directly impacts your costs.
+
+Roo Code uses codebase indexing and retrieval to surface the most relevant files and symbols for each task, rather than stuffing everything into a single prompt. This means you get agentic capabilities that can propose diffs, run commands and tests, and iterate on results without requiring infrastructure that doesn't exist at accessible price points.
+
+**The practical reality: an AI coding agent that works within current limits will ship features today, while teams waiting for 10 million token context windows remain blocked.**
+
+## Long-context approaches compared
+
+| Dimension            | Brute-force context stuffing                   | Retrieval-augmented workflows             |
+| -------------------- | ---------------------------------------------- | ----------------------------------------- |
+| Context dependency   | Requires endpoints that don't exist affordably | Works within current API limits           |
+| Cost structure       | Scales linearly with codebase size             | Scales with task relevance                |
+| Latency              | Minutes per request at scale                   | Seconds per interaction                   |
+| Availability         | Limited to on-prem or premium tiers            | Available through standard API endpoints  |
+| Workflow reliability | Blocked when limits hit                        | Degrades gracefully with larger codebases |
+
+## Frequently asked questions
+
+### Why can't I access the 10 million token context window that was announced?
+
+Announced context windows reflect model architecture capabilities, not production API availability. Serving requests at that scale requires dedicated GPU clusters that lose money on every request under serverless pricing models. Providers either don't offer these endpoints, price them prohibitively, or impose latency that breaks real workflows.
+
+### When will long-context endpoints become affordable?
+
+The timeline depends on GPU supply, demand curves, and provider willingness to subsidize these deployments for market position. Spare capacity is the key variable. When providers have idle GPU clusters, long-context becomes a way to monetize that capacity. Until then, design workflows that don't depend on it.
+
+### How does Roo Code handle large codebases without massive context windows?
+
+Roo Code uses codebase indexing to surface relevant files and symbols for each task rather than requiring everything in a single prompt. Combined with BYOK pricing where you pay only your provider's rates, this approach lets you close the loop on real development tasks without waiting for infrastructure that isn't economically viable yet.
+
+### Should my team wait for longer context before adopting AI coding tools?
+
+No. Teams that design workflows around current limits ship features today. The practical approach is retrieval-augmented context selection, not brute-force context stuffing. Longer context will get cheaper over time, but blocking your roadmap on announced-but-unavailable capabilities stalls real productivity gains.
+
+### What's the difference between announced capabilities and production endpoints?
+
+Model providers demonstrate what architectures can handle. Infrastructure providers offer what they can serve profitably. A 10 million token demo proves the model works. A production endpoint requires someone to provision hardware, accept thin margins, and maintain availability at scale. These are different businesses with different incentives.
diff --git a/apps/web-roo-code/src/content/blog/why-coding-benchmarks-do-not-predict-realworld-agent-performance.md b/apps/web-roo-code/src/content/blog/why-coding-benchmarks-do-not-predict-realworld-agent-performance.md
new file mode 100644
index 00000000000..22b067ac156
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/why-coding-benchmarks-do-not-predict-realworld-agent-performance.md
@@ -0,0 +1,132 @@
+---
+title: Why Coding Benchmarks Do Not Predict Real-World Agent Performance
+slug: why-coding-benchmarks-do-not-predict-realworld-agent-performance
+description: Coding benchmarks test isolated function generation, not real-world agentic work. Learn why building your own evals produces reliable signal for model selection.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-coding-agents
+    - benchmarks
+    - model-evaluation
+    - developer-productivity
+status: draft
+publish_date: "2025-06-18"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Model scores 87% on HumanEval.
+
+Model cannot navigate your monorepo.
+
+These are not contradictory statements. They describe different tasks.
+
+## What benchmarks actually test
+
+Public coding benchmarks measure a specific skill: can a model write a single file that passes a unit test? The model gets a function signature, writes an implementation, and the harness checks if the output matches expected values.
+
+This is a reasonable test of raw code generation ability. It is not a test of whether the model can help you ship.
+
+> "When we think about coding, we're thinking about using it in real code and it working well. When they think about coding, it's like: can it make a Python script, and then does a function pass? It's just two very different things."
+>
+> Adam, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=2953)
+
+Real coding means navigating an existing codebase with years of accumulated decisions. It means interpreting a PRD that references three other documents. It means making changes that do not break the fourteen services that depend on this endpoint.
+
+Benchmarks do not test any of this.
+
+## The gap between benchmark and production
+
+The challenge shows up the moment you hand an agent something real.
+
+> "The challenge is working with existing codebases, or giving a very complex PRD or some sort of technical specification."
+>
+> Adam, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=2867)
+
+A benchmark task has clean boundaries. The function signature tells you exactly what to implement. The test tells you exactly what success looks like.
+
+Production tasks have fuzzy boundaries. The spec says "improve performance" without defining acceptable latency. The codebase has three different authentication patterns, and you need to figure out which one applies here. The test suite takes 40 minutes to run, so you cannot iterate quickly.
+
+A model that scores well on benchmarks can still produce changes that break in ways the benchmark never tests: race conditions, incorrect error handling, changes that technically work but violate team conventions.
+
+## What evaluation actually looks like
+
+Teams that want accurate signal build their own evals.
+
+> "A lot of my testing I do and my eval are unfortunately manual... I have 20 complex prompts. I feed them into Roo Code for a model."
+>
+> Adam, [Office Hours S01E10](https://www.youtube.com/watch?v=yVf2LalAubc&t=2889)
+
+The process is straightforward: collect prompts that represent real tasks your team faces. Feed them into the agent. Let it run. Score the output against your actual acceptance criteria.
+
+This is more work than checking a leaderboard. It also produces signal you can trust.
+
+The prompts should include:
+
+- Tasks that require understanding existing code, not just generating new code
+- Specs with ambiguity that require reasonable interpretation
+- Changes that touch multiple files across different parts of the codebase
+- Requests that would normally require clarifying questions
+
+Score the outputs on dimensions that matter for your workflow: Did it find the right files? Did it ask clarifying questions when the spec was ambiguous? Did the change follow team conventions? Would you merge this PR?
+
+## The tradeoff
+
+Building your own evals takes time. You need to curate prompts, run repeated tests, and score outputs manually.
+
+The alternative is trusting benchmarks that measure a different task. Teams that make model decisions based on HumanEval scores often discover the gap when they try to use the model on real work.
+
+The investment is upfront. The signal is reliable.
+
+## How Roo Code closes the loop on real-world evaluation
+
+Roo Code lets you test models against your actual codebase, not synthetic benchmarks. With BYOK (bring your own key), you can swap models and run the same complex prompt against different providers to see which one navigates your monorepo, follows your conventions, and produces mergeable PRs.
+
+Because Roo Code closes the loop - proposing diffs, running commands and tests, then iterating based on results - you observe how a model performs across the full task lifecycle, not just the code generation step. This gives you evaluation signal that benchmarks cannot provide: does the model recover when tests fail? Does it ask clarifying questions when specs are ambiguous? Does the final PR match what you would have written?
+
+**Roo Code enables teams to build reliable model evaluations by testing against real tasks in their actual development environment, producing signal that public benchmarks cannot measure.**
+
+## Benchmark vs. real-world evaluation
+
+| Dimension          | Public benchmarks               | Real-world evaluation                   |
+| ------------------ | ------------------------------- | --------------------------------------- |
+| Task scope         | Single function or file         | Multi-file changes across codebase      |
+| Success criteria   | Unit test passes                | PR is mergeable and follows conventions |
+| Context required   | Function signature only         | Existing code, specs, team patterns     |
+| Iteration tested   | One-shot generation             | Full loop including test runs and fixes |
+| Signal reliability | High variance across task types | Directly applicable to your work        |
+
+## Why this matters for your team
+
+For a team evaluating which model to use for agentic coding work, benchmark scores are a starting point, not a decision. The model that tops the leaderboard may not be the model that works well in your codebase with your conventions and your types of tasks.
+
+If you are choosing between models for a team of five shipping to production, you need signal from tasks that look like your tasks. Twenty minutes building a custom eval set produces more reliable information than an hour comparing benchmark tables.
+
+## The shift
+
+The benchmarks that matter are the ones you build yourself.
+
+Start with five prompts that represent real work your team does. Run them against two models. Score the outputs. The differences become obvious when the task is yours.
+
+## Frequently asked questions
+
+### Why do models score high on benchmarks but struggle with real codebases?
+
+Benchmarks test isolated code generation with clear inputs and outputs. Real codebases require understanding existing patterns, navigating dependencies, and making changes that fit team conventions. These are fundamentally different tasks, and benchmark performance does not transfer directly to production work.
+
+### How many prompts do I need for a useful custom eval?
+
+Start with five prompts that represent common tasks your team handles. This is enough to surface meaningful differences between models. You can expand to 15-20 prompts for more comprehensive coverage, but even a small eval set produces better signal than benchmark comparisons.
+
+### Can I use Roo Code to compare different models on my codebase?
+
+Yes. With BYOK, you can configure different model providers and run identical prompts against each one. Because Roo Code closes the loop by running tests and iterating on failures, you see the full picture of how each model handles your specific tasks, not just initial code generation quality.
+
+### What should I score when evaluating model outputs?
+
+Focus on dimensions that affect your workflow: Did the model find the right files to modify? Did it ask clarifying questions when the spec was ambiguous? Does the change follow your team's conventions? Would you merge this PR without significant revisions? These criteria matter more than whether the code technically runs.
+
+### How often should I re-run custom evals?
+
+Re-run evals when you consider switching models or when model providers release significant updates. Quarterly evaluation is reasonable for most teams. Keep your prompt set updated to reflect the types of tasks your team currently handles.
diff --git a/apps/web-roo-code/src/content/blog/why-milliontoken-context-windows-fail-in-long-conversations.md b/apps/web-roo-code/src/content/blog/why-milliontoken-context-windows-fail-in-long-conversations.md
new file mode 100644
index 00000000000..f4ea2a78225
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/why-milliontoken-context-windows-fail-in-long-conversations.md
@@ -0,0 +1,124 @@
+---
+title: Why Million-Token Context Windows Fail in Long Conversations
+slug: why-milliontoken-context-windows-fail-in-long-conversations
+description: Million-token context windows work for one-shot queries but degrade to 200K effective context in extended agentic conversations. Learn why attention drift happens and how to calibrate for real-world coding workflows.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-windows
+    - agentic-workflows
+    - AI-coding
+    - developer-productivity
+status: draft
+publish_date: "2025-05-21"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+A million tokens sounds like infinite memory.
+
+It isn't.
+
+## The difference between dump and dialogue
+
+You paste a 200-page specification into the context window. You ask one question. The model answers correctly, citing page 47. The million-token context worked exactly as advertised.
+
+Now try something different. Start a task. Go back and forth for an hour. Add new files. Run commands. Review diffs. Ask follow-up questions. Watch the conversation grow to 300K tokens.
+
+The model starts missing things. It references files you mentioned an hour ago but ignores the correction you made ten minutes ago. It suggests a fix you already tried. It loses focus.
+
+Same model. Same context window. Different behavior.
+
+## One-shot vs. extended tasks
+
+The million-token context window works differently depending on how you use it.
+
+**One-shot queries:** you dump a large document, ask a question, get an answer. The model processes the full context once, retrieves what it needs, and responds. This works.
+
+**Extended conversations:** you go back and forth, the context grows incrementally, and the model has to track state across many turns. The attention mechanism that works for retrieval starts losing track of what matters.
+
+> "The million context works differently when you're dumping it, you're one-shotting, you're saying, here's a giant trove of stuff and you ask it a question... But when you have an ongoing conversation back and forth and it grows to hundreds of thousands, it doesn't maintain focus. So, for extended tasks, it's more like 200K in my experience."
+>
+> Shank, [Office Hours S01E07](https://www.youtube.com/watch?v=yGVPIdn0mVw&t=2183)
+
+The advertised number tells you the theoretical maximum. The effective number for agentic workflows is closer to 200K. Sometimes less.
+
+## Where the focus breaks
+
+In one set of tests with subtask delegation, the highest any single subtask reached was around 80K tokens. That's not a limitation of the tool. That's where the workflow naturally settled to keep outputs coherent.
+
+When context grows beyond what the model can effectively track, you see specific symptoms:
+
+- The model repeats suggestions it already made
+- It ignores constraints you stated earlier in the conversation
+- It references outdated assumptions instead of recent corrections
+- It becomes confidently wrong about the current state of the codebase
+
+These aren't random failures. They're symptoms of attention degradation in long contexts.
+
+## One-shot retrieval vs. extended conversation
+
+| Dimension         | One-shot retrieval                 | Extended conversation                       |
+| ----------------- | ---------------------------------- | ------------------------------------------- |
+| Context usage     | Load once, query once              | Incremental growth over many turns          |
+| Effective limit   | Full advertised window (1M tokens) | 200K or less before degradation             |
+| Attention pattern | Focused retrieval from static dump | Distributed across evolving state           |
+| Failure mode      | Missing information                | Losing track of corrections and constraints |
+| Recovery strategy | Re-query with different prompt     | Start fresh task with summary               |
+
+## The tradeoff
+
+You have two options for extended tasks.
+
+**Option 1: Accept the effective limit.** Keep conversations under 200K. Start fresh tasks when context gets stale. Split large workflows into focused subtasks.
+
+**Option 2: Invest in context management.** Use summarization, hierarchical memory, or explicit state tracking to keep the relevant information in the attention window.
+
+Neither option is free. Fresh tasks lose history. Context management adds complexity and tokens. The question is which cost you prefer.
+
+## How Roo Code closes the loop on context management
+
+Roo Code addresses context degradation through its subtask orchestration architecture. Instead of running a single conversation until attention drifts, Roo Code's Orchestrator mode breaks complex workflows into focused subtasks, each staying within the effective context range.
+
+When you use BYOK (bring your own key) with Roo Code, the agent can delegate work to specialized modes - each subtask starts with a clean context and a focused objective. The parent orchestrator maintains the high-level state while child tasks execute without carrying accumulated noise.
+
+**The key difference:** Roo Code closes the loop by running commands, tests, and iterations within bounded subtasks, then consolidating results back to the orchestrator. This design keeps each unit of work within the 80K range where coherence stays high, while preserving the overall workflow state across the full task.
+
+## Why this matters for your team
+
+For a team running multi-hour agent tasks, the million-token marketing number creates a false expectation. You plan for infinite memory. You get degraded focus after 200K.
+
+The impact shows up in subtle ways: tasks that should converge keep looping. Bugs that were "fixed" reappear. The agent suggests approaches you already rejected. You start wondering if the model is broken when the real issue is context length.
+
+If your team is shipping daily through agentic workflows, calibrating for effective context (not advertised context) saves hours of debugging attention drift.
+
+## The practical calibration
+
+For extended agentic tasks, plan for 200K effective context. When you hit that threshold, consider starting a fresh task with a summary of the current state.
+
+If you're delegating to subtasks, keeping each under 80K seems to be where coherence stays high. That's not a hard rule; it's an observation from practice.
+
+The million-token window is real. But for ongoing back-and-forth work, the effective limit is lower. Plan accordingly.
+
+## Frequently asked questions
+
+### Why does my AI coding agent forget things I told it earlier in the conversation?
+
+This is attention degradation in long contexts. As your conversation grows beyond 200K tokens, the model's attention mechanism loses track of earlier constraints and corrections. It's not forgetting in the human sense - it's that the attention weights spread too thin across the growing context. The model may reference something from early in the conversation while missing a correction you made more recently.
+
+### What is the actual effective context limit for extended coding tasks?
+
+Based on practical observation, the effective limit for extended agentic tasks is around 200K tokens, not the million-token advertised maximum. For individual subtasks where you need high coherence, 80K tokens appears to be where outputs stay reliable. These aren't hard limits but practical thresholds where degradation becomes noticeable.
+
+### How does Roo Code handle context limits differently than other AI coding tools?
+
+Roo Code uses subtask orchestration to keep individual work units within effective context ranges. The Orchestrator mode breaks complex workflows into focused subtasks, each starting with clean context. This architecture lets you run multi-hour workflows without the attention drift that occurs in single long conversations. Each subtask closes the loop independently, then results consolidate back to the parent orchestrator.
+
+### Should I start a new conversation when my agent starts repeating itself?
+
+Yes. When the model starts repeating suggestions, ignoring recent corrections, or referencing outdated assumptions, those are symptoms of context degradation. Starting a fresh task with a summary of the current state is more efficient than fighting attention drift. Think of it as a checkpoint rather than a failure.
+
+### Does using a model with a larger context window solve this problem?
+
+Not for extended conversations. The million-token context window works well for one-shot retrieval tasks where you dump a large document and ask questions. But the attention mechanism degrades differently in extended back-and-forth dialogue. A larger window gives you more theoretical capacity, but the effective limit for conversational workflows remains around 200K regardless of the advertised maximum.
diff --git a/apps/web-roo-code/src/content/blog/why-teams-need-multiprovider-policies-for-the-same-model.md b/apps/web-roo-code/src/content/blog/why-teams-need-multiprovider-policies-for-the-same-model.md
new file mode 100644
index 00000000000..8fcc9cb70dc
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/why-teams-need-multiprovider-policies-for-the-same-model.md
@@ -0,0 +1,125 @@
+---
+title: Why Teams Need Multi-Provider Policies for the Same Model
+slug: why-teams-need-multiprovider-policies-for-the-same-model
+description: Learn why the same AI model from different providers produces different results, and how policy-based routing solves provider variance, geographic compliance, and rate limit cascades for distributed engineering teams.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - enterprise
+    - model-providers
+    - team-workflows
+    - compliance
+status: draft
+publish_date: "2025-09-03"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+```json
+"model": "claude-sonnet"
+"provider": "vertex-eu"
+
+That is not just a model choice.
+
+That is a geographic constraint, a quantization decision, and a caching policy bundled into two lines of config.
+
+## The provider variance problem
+
+If you're evaluating AI coding tools for a distributed team, you've probably assumed that "Claude Sonnet" means "Claude Sonnet" regardless of where it's hosted. That assumption breaks in production.
+
+The same model from different providers isn't the same model. Quantization levels vary. Context limits differ. Caching behavior changes. Even hosting temperature isn't consistent across providers.
+
+> "One of the things that we run into a lot of times is provider variance in basically the quantization of the model. Sometimes the context limit, pricing, caching, you name it, there's a bunch of things, even the way they host it. For example, Grok will host with a warmer temp than others."
+>
+> Hannes Rudolph, [Roo Cast S01E07](https://www.youtube.com/watch?v=ECO4kNueKL0&t=3310)
+
+Rate limiting on aggregators like OpenRouter compounds the issue. Your team hits a limit, requests fail, and now you're debugging infrastructure instead of shipping code.
+
+For teams running evals or comparing outputs across regions, this variance creates noise that looks like model differences but is actually provider differences.
+
+## The solution: policies that abstract provider logic
+
+The fix is defining policies that route requests across multiple providers for the same model, with fallback logic that preserves caching and respects constraints.
+
+Instead of configuring one provider per model, you define a policy that says: "These four providers all serve Qwen 3 Coder. Route to the fastest available. Fall back if one hits rate limits."
+
+> "You can make a template which we call a policy and say these four Qwen 3 Coders I want to use and call it Qwen 3 Coder and you can also choose by agency that will always choose the fastest one."
+>
+> Dan, [Roo Cast S01E07](https://www.youtube.com/watch?v=ECO4kNueKL0&t=3383)
+
+The developer sees "Qwen 3 Coder." The policy handles the routing. No one debugs provider infrastructure during a sprint.
+
+## Geographic constraints for distributed teams
+
+For enterprise teams with compliance requirements, policies unlock geographic routing without per-developer configuration.
+
+Your European infrastructure team can only use EU-hosted instances of Claude on Vertex or Bedrock. Your US team has different constraints. Instead of documenting this in a wiki and hoping everyone reads it, you encode it in a policy.
+
+> "We have like huge teams saying like, oh, the European infra team can only use the European hosted servers of Claude on Vertex and Bedrock. So, they make a policy for that team."
+>
+> Tibol, [Roo Cast S01E07](https://www.youtube.com/watch?v=ECO4kNueKL0&t=3433)
+
+The policy becomes the source of truth. Onboarding is: "Use the EU-Infra policy." Compliance is: "The policy enforces the constraint."
+
+## How Roo Code enables policy-based model routing
+
+Roo Code's BYOK (Bring Your Own Key) architecture gives teams direct control over provider configuration without token markup or intermediary routing. Because you connect your own API keys to providers like Anthropic, OpenAI, Google Vertex, AWS Bedrock, or OpenRouter, you control exactly where requests go.
+
+This architecture enables teams to define routing policies that abstract provider complexity while maintaining full transparency. The developer selects a model name; the policy handles geographic constraints, fallback logic, and rate limit recovery. Roo Code closes the loop by letting the agent iterate on tasks without requiring developers to manually switch providers when infrastructure issues arise.
+
+**For distributed engineering teams, policy-based routing through Roo Code means compliance is enforced by configuration, not documentation.**
+
+## Old approach vs. policy-based routing
+
+| Dimension | Old approach (per-developer config) | Policy-based routing |
+|-----------|-------------------------------------|---------------------|
+| Provider selection | Each developer configures their own provider | Policy defines allowed providers per team |
+| Geographic compliance | Documented in wiki, manually enforced | Encoded in policy, automatically enforced |
+| Rate limit handling | Developer manually switches providers | Automatic fallback to next available provider |
+| Output consistency | Varies by developer's provider choice | Consistent within policy constraints |
+| Onboarding | Train developers on provider differences | Assign team policy, developer picks model name |
+
+## Why this matters for your organization
+
+For a 50-person engineering org with distributed teams, provider variance creates three problems that compound:
+
+1. **Inconsistent outputs across regions.** Two developers run the same prompt, get different results. The difference isn't the prompt; it's the provider's quantization level. Debugging this wastes hours.
+
+2. **Compliance exposure.** If EU data residency matters, you need routing that enforces it. Relying on developers to remember which provider to select is a policy violation waiting to happen.
+
+3. **Rate limit cascades.** When one provider throttles, work stops. Without fallback logic, your team waits or manually switches providers. With policies, routing happens automatically.
+
+The shift is from "configure providers per developer" to "define policies per team." The policy encodes the constraints. The developer picks a model name and works.
+
+## What to do next
+
+Audit your current provider setup. Ask: if two developers in different regions run the same task, will they hit the same provider? If compliance requires geographic constraints, is that enforced by config or by documentation?
+
+If the answer is documentation, you have a policy gap. Define the policy, encode the constraints, and remove the variance from the developer's decision space.
+
+The model name should be the interface. The policy handles the rest.
+
+## Frequently asked questions
+
+### Why does the same model produce different results from different providers?
+
+Providers apply different quantization levels, context limits, caching strategies, and even hosting temperatures to the same base model. These infrastructure differences affect output quality and consistency. What appears to be model variance is often provider variance that creates noise in evals and unpredictable results across team members.
+
+### How do policies help with data residency compliance?
+
+Policies encode geographic constraints directly in configuration. Instead of documenting that "EU teams must use Vertex EU or Bedrock EU" in a wiki, the policy enforces it automatically. When a developer on the EU infrastructure team selects a model, the policy routes to compliant providers only. Compliance becomes a configuration property, not a training requirement.
+
+### What happens when a provider hits rate limits?
+
+Without policy-based routing, developers must manually switch providers or wait for limits to reset. With policies, you define fallback providers for the same model. When the primary provider throttles, requests automatically route to the next available provider. Work continues without developer intervention or infrastructure debugging.
+
+### How does Roo Code support multi-provider policies?
+
+Roo Code's BYOK architecture means you connect your own API keys to multiple providers. You maintain direct relationships with Anthropic, OpenAI, Google, AWS, or aggregators like OpenRouter. This gives teams the foundation to build routing policies that abstract provider logic while keeping full control over costs, compliance, and caching behavior.
+
+### Should every team use the same provider policy?
+
+No. Different teams have different constraints. Your EU infrastructure team may require data residency compliance. Your ML research team may prioritize access to the latest model versions. Your cost-conscious team may route to the cheapest available provider. Define policies per team based on their actual requirements, then let developers work with model names instead of provider configurations.
+
+```
diff --git a/apps/web-roo-code/src/content/blog/why-your-2023-llm-integration-needs-a-rewrite.md b/apps/web-roo-code/src/content/blog/why-your-2023-llm-integration-needs-a-rewrite.md
new file mode 100644
index 00000000000..59dcb87d8e8
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/why-your-2023-llm-integration-needs-a-rewrite.md
@@ -0,0 +1,133 @@
+---
+title: Why Your 2023 LLM Integration Needs a Rewrite
+slug: why-your-2023-llm-integration-needs-a-rewrite
+description: Learn why AI integrations built in 2023 need a complete rewrite, not patches. The scaffolding you built to work around model limitations now prevents you from using current capabilities.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - llm-integration
+    - technical-debt
+    - ai-architecture
+    - agentic-workflows
+status: draft
+publish_date: "2025-10-22"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Strip everything out. Start over.
+
+That's not a failure of planning. That's the actual migration path for teams who built AI features two years ago.
+
+## The integration that worked then
+
+You built it in 2023. Prompt templates. Token chunking. Context window management. Retrieval pipelines to work around the 4k or 8k limit. Output parsers to handle the model's inconsistent JSON. Retry logic for rate limits.
+
+It shipped. It worked. You moved on.
+
+Now the model underneath has changed so fundamentally that your scaffolding is doing more harm than good. The chunking you built to fit context windows? The models now support 128k or 200k tokens natively. The output parsers you wrote to handle flaky JSON? The models now support structured outputs and function calling. The prompt templates you carefully tuned? They're optimized for a model that thinks differently than the one you're running now.
+
+You're maintaining code that actively fights the capabilities you're paying for.
+
+## The shift isn't incremental
+
+The instinct is to patch. Swap the model name, bump the context limit, ship it.
+
+But the integration patterns from 2023 don't just need updating. They need removing.
+
+> "The way of building around LLMs at that time was completely different than how you would build right now."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=1977)
+
+The gap isn't "add multimodal support." The gap is that models now have native reasoning, agentic tool use, and structured outputs. If your integration was designed around "send text, get text, parse text," you built for a different tool.
+
+The scaffolding you wrote to compensate for 2023 model limitations is now scaffolding that prevents you from using 2026 model capabilities.
+
+> "For a lot of these folks it was basically: you have to strip everything out and start over again. You're completely rewriting your product."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=2025)
+
+## The cost of not rewriting
+
+The rewrite cost is real. Engineering time. Feature freeze while you migrate. Risk of regressions.
+
+But so is the cost of maintenance.
+
+Every time you patch the old integration, you're paying engineers to maintain code that works against the model. Every time you debug a prompt that "stopped working," you're debugging assumptions that no longer hold. Every time you explain why the AI feature is "good enough but not great," you're paying the opportunity cost of architecture that can't access what the model actually offers.
+
+> "That work is definitely transitory. It's not going to be the thing that sticks around."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=2052)
+
+The 2023 integration was correct for 2023. Keeping it in 2026 is a choice to maintain technical debt that compounds every time the models improve.
+
+## What the rewrite looks like
+
+The new integration is often simpler: fewer workarounds, more direct model capabilities.
+
+- **Context management:** Stop chunking. Use the native context window. Let the model handle retrieval when structured outputs support it.
+- **Output parsing:** Stop writing regex for JSON extraction. Use function calling or structured output modes.
+- **Prompt engineering:** Stop optimizing for how GPT-3.5 interpreted instructions. Optimize for reasoning models that think before responding.
+- **Agentic workflows:** Stop treating the model as a completion engine. Let it call tools, iterate on results, and close the loop on tasks.
+
+The rewrite isn't "more code." It's often "less code that does more."
+
+## 2023 vs 2026 LLM integration patterns
+
+| Dimension        | 2023 Pattern                           | 2026 Pattern                                |
+| ---------------- | -------------------------------------- | ------------------------------------------- |
+| Context handling | Manual chunking to fit 4k-8k limits    | Native 128k-200k context windows            |
+| Output parsing   | Regex and string manipulation for JSON | Structured outputs and function calling     |
+| Error handling   | Retry loops for inconsistent responses | Reliable structured responses with schemas  |
+| Workflow design  | Single-shot completion requests        | Agentic loops that iterate on results       |
+| Tool integration | Manual orchestration of external calls | Native tool use with model-driven execution |
+
+## Why this matters for your team
+
+For a Series A or B team with 5-15 engineers, the rewrite decision is a resource allocation question. You don't have the headcount to maintain legacy integrations indefinitely.
+
+The compounding cost shows up in two places:
+
+1. **Maintenance drag:** Every sprint where an engineer is debugging 2023 prompt logic is a sprint they're not shipping the feature that uses 2026 capabilities.
+2. **Capability ceiling:** Your competitors who rewrite will ship features you can't build on your current architecture. The gap widens every quarter.
+
+The question isn't whether to rewrite. The question is whether to do it now, when you control the timeline, or later, when the maintenance cost forces your hand.
+
+## How Roo Code accelerates the rewrite
+
+Roo Code is an AI coding agent that closes the loop: it proposes changes, runs commands and tests, and iterates based on results. When you're rewriting LLM integration code, Roo Code can identify the 2023 scaffolding patterns, propose replacements using current model capabilities, and verify the changes work by running your test suite.
+
+With BYOK (bring your own key), you use your existing API keys directly with no token markup. This means you can point Roo Code at the same models you're integrating with, using the same credentials, while the agent handles the iteration cycle of refactoring legacy code.
+
+The rewrite becomes less about manually tracing through chunking logic and more about describing what the integration should do now, then letting the agent close the loop on implementation.
+
+## The first step
+
+Audit your AI integration code. Identify the scaffolding that exists to work around limitations the model no longer has.
+
+If you're still chunking context, parsing JSON manually, or retrying because the model "forgets" instructions: that's the code to delete first.
+
+The rewrite is real work. But so is maintaining architecture that fights the tool you're paying for.
+
+## Frequently asked questions
+
+### How do I know if my LLM integration needs a rewrite versus patches?
+
+Look for code that compensates for limitations the model no longer has. If you're chunking content to fit context windows under 32k tokens, parsing JSON with regex instead of using structured outputs, or building retry logic around inconsistent responses, you have scaffolding that actively prevents you from using current model capabilities. Patches won't fix architecture designed for a different tool.
+
+### What's the typical timeline for rewriting a 2023 LLM integration?
+
+For a focused team, the core rewrite often takes 2-4 weeks depending on integration complexity. The counterintuitive part: the new code is usually simpler than what you're replacing. Most of the time goes into safely removing scaffolding while maintaining feature parity, not building new complexity.
+
+### Can I migrate incrementally or do I need a big-bang rewrite?
+
+You can migrate incrementally by capability. Start with output parsing: switch to structured outputs for one endpoint, verify it works, then expand. Context management changes can follow. The key is identifying which scaffolding is load-bearing for other scaffolding versus which can be removed independently.
+
+### How does Roo Code help with identifying legacy LLM integration patterns?
+
+Roo Code can analyze your codebase to find 2023-era patterns like manual chunking, regex-based JSON parsing, and completion-style prompt templates. Because the agent closes the loop by running tests after proposing changes, it can verify that removing scaffolding doesn't break functionality before you commit the changes.
+
+### What if my 2023 integration is "working fine" right now?
+
+Working fine today means paying maintenance cost on code that fights your model. Every time you upgrade model versions or add features, you're debugging assumptions that no longer hold. The cost compounds. Teams who rewrite now ship features that teams with legacy integrations cannot build on their current architecture.
diff --git a/apps/web-roo-code/src/content/blog/why-your-agent-forgets-instructions-after-context-condensing.md b/apps/web-roo-code/src/content/blog/why-your-agent-forgets-instructions-after-context-condensing.md
new file mode 100644
index 00000000000..cecbda69128
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/why-your-agent-forgets-instructions-after-context-condensing.md
@@ -0,0 +1,113 @@
+---
+title: Why Your Agent Forgets Instructions After Context Condensing
+slug: why-your-agent-forgets-instructions-after-context-condensing
+description: Learn why AI coding agents lose formatting rules and workflow constraints after context condensing, and how preserving the first message fixes instruction drift in long sessions.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - context-management
+    - agentic-workflows
+    - prompt-engineering
+    - ai-coding-agents
+status: draft
+publish_date: "2025-09-17"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Your formatting rules worked perfectly. For the first twenty exchanges.
+
+Then the context window filled up, the agent condensed, and suddenly it stopped following your output structure.
+
+## The symptom
+
+You have strict instructions about output format. Every review comment should follow a specific template. Every code suggestion should include a test case. The agent knows this. It follows the rules.
+
+Until it doesn't.
+
+After a long session, the agent condenses your conversation to fit within context limits. The next response comes back wrong. Not wrong in content, wrong in structure. The formatting rules vanished.
+
+> "I was seeing some weird behavior with some of my workflows. Some of my workflows have really like strict instructions about the output how it should look and I saw that it was just after condensing it was just forgetting how to properly format you know comments reviews."
+>
+> Dan, [Roo Cast S01E09](https://www.youtube.com/watch?v=Vo5grOXbjIY&t=1299)
+
+You didn't change anything. The agent didn't misunderstand. Something got lost in the condensing.
+
+## The root cause
+
+The problem was in what got replaced during condensing. The first message in your conversation contains your directive: the system prompt, your formatting rules, your workflow constraints. That message is the anchor.
+
+When the context window fills up and condensing kicks in, the system needs to summarize. The naive approach: replace the first message with something like "please continue with this summary." The summary captures the conversation state but drops your original instructions.
+
+> "It turns out the first message was being replaced with something else when condensing something along the lines of please continue with this summary or something like that."
+>
+> Dan, [Roo Cast S01E09](https://www.youtube.com/watch?v=Vo5grOXbjIY&t=1313)
+
+The model now treats the summary as the main instruction. Your formatting rules existed in the first message. The first message is gone. The rules are gone.
+
+## Why providers do middle-out
+
+This explains a pattern you might have noticed: many providers use middle-out transformations when hitting context limits. They preserve the first message and the recent messages while summarizing the middle.
+
+> "The first message includes... that's why providers for example do middle out transformations when when you reach the context window limit... because the first message contains your directive."
+>
+> Dan, [Roo Cast S01E09](https://www.youtube.com/watch?v=Vo5grOXbjIY&t=1341)
+
+The first message is architecturally significant. It's not just another turn in the conversation. It's the directive that shapes everything else. Lose it, and the model loses its purpose.
+
+## The fix
+
+The solution is straightforward: preserve the first message during condensing. Don't replace it with a generic "continue with this summary" prompt. Keep the original directive intact and summarize the middle of the conversation instead.
+
+After implementing this fix, agents stay on task across long sessions. The formatting rules persist. The workflow constraints hold. The condensing happens, but the directive survives.
+
+## Context condensing approaches compared
+
+| Dimension                | Naive condensing             | Middle-out condensing            |
+| ------------------------ | ---------------------------- | -------------------------------- |
+| First message handling   | Replaced with summary prompt | Preserved intact                 |
+| Directive persistence    | Lost after condensing        | Retained across sessions         |
+| Formatting rule survival | Rules vanish at boundary     | Rules persist through condensing |
+| Long session reliability | Drift increases over time    | Consistent behavior maintained   |
+| Recovery required        | Manual re-instruction needed | No intervention required         |
+
+## How Roo Code preserves your directives
+
+Roo Code implements middle-out context management to keep your workflow instructions intact across long sessions. When the context window fills, Roo Code summarizes the middle of the conversation while preserving both your original directive and recent context. This means your formatting rules, output structures, and workflow constraints survive the condensing boundary.
+
+**Roo Code preserves the first message during context condensing, ensuring your workflow instructions and formatting rules persist across long agentic sessions.**
+
+Because Roo Code closes the loop by running commands, tests, and iterating based on results, maintaining consistent instructions is critical. An agent that forgets your output format mid-task creates manual correction work. With directive preservation, you can run complex multi-step tasks knowing your constraints will hold from start to finish.
+
+## What to check
+
+If your agent is drifting after long sessions, check what happens at the condensing boundary:
+
+1. Is your first message being preserved or replaced?
+2. Does the summary include your directive, or just the conversation state?
+3. Are your formatting rules making it through the condensing intact?
+
+The symptom is instruction drift. The cause is usually the first message getting dropped. The fix is preserving it.
+
+## Frequently asked questions
+
+### Why do my agent's formatting rules disappear after long conversations?
+
+When context windows fill up, some systems replace the first message with a generic summary prompt. Since your formatting rules and workflow instructions live in that first message, they get lost during condensing. The agent continues with the summary as its new directive, which lacks your original constraints.
+
+### What is middle-out context condensing?
+
+Middle-out condensing is a strategy that preserves the first message and recent messages while summarizing the middle of the conversation. This approach recognizes that the first message contains architecturally significant directives that shape the entire session. By keeping it intact, the agent maintains its purpose and constraints.
+
+### How does Roo Code handle context condensing differently?
+
+Roo Code preserves your original directive during context condensing by implementing middle-out summarization. Your workflow instructions, formatting rules, and output constraints survive the condensing boundary. This lets you run long agentic sessions without losing the instructions that define your task.
+
+### Can I recover from instruction drift without starting over?
+
+If your agent has already lost its instructions, you can re-state your formatting rules and constraints in a new message. However, the better approach is using a tool that preserves directives during condensing so you don't need to manually intervene. Prevention is more reliable than recovery.
+
+### How do I know if my first message is being preserved?
+
+Watch for sudden changes in output format or structure after long sessions. If the agent was following specific rules and suddenly stops, check whether the condensing replaced your first message. You can also explicitly ask the agent what its current instructions are to see if your original directive is still present.
diff --git a/apps/web-roo-code/src/content/blog/why-your-model-searches-the-same-files-twice.md b/apps/web-roo-code/src/content/blog/why-your-model-searches-the-same-files-twice.md
new file mode 100644
index 00000000000..d0ee85ae18e
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/why-your-model-searches-the-same-files-twice.md
@@ -0,0 +1,119 @@
+---
+title: Why Your Model Searches the Same Files Twice
+slug: why-your-model-searches-the-same-files-twice
+description: Learn why reasoning models repeat file searches across prompts and how preserving reasoning tokens between API calls can boost coding benchmark performance by 4-5 percentage points.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - reasoning-models
+    - api-architecture
+    - context-management
+    - ai-coding
+status: draft
+publish_date: "2025-11-05"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Three prompts. Same file search. Zero new information.
+
+## The amnesia loop
+
+You ask the model to find a bug in your auth module. It searches, finds the file, reads it, reasons about the problem. Suggests a fix.
+
+You say "that's not quite right" and give it more context. It searches again. Reads the same file. Reasons from scratch. Suggests a slightly different fix.
+
+Third prompt. Same search. Same file. The model has no memory of what it thought about the first two times.
+
+This is not a model capability problem. This is an API architecture problem.
+
+## Where the reasoning goes
+
+When you use a reasoning model through chat completions, something counterintuitive happens: the model does all its thinking, but that thinking never makes it back into the conversation history.
+
+The model receives your question. It reasons through the problem, maybe for 30 seconds, maybe longer. It produces an answer. But the reasoning tokens themselves get discarded. The only thing that persists is the question and the final answer.
+
+> "If you were to use an open reasoning model inside of chat completions, it does all the reasoning sort of like out of band and its reasoning tokens don't get outputted at all into the chat completion. So you're like you're asking a question, it thinks about it for a while, it answers, but then all it sees is the ask and the answer, and it doesn't remember what it thought about."
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=1898)
+
+This explains the file search pattern. The model reasoned about your codebase structure on turn one. It figured out which files matter and why. But that reasoning got thrown away before turn two started. So it searches again, because from its perspective, it has never seen your codebase before.
+
+## The fix: preserve reasoning tokens
+
+The responses API lets you keep encrypted reasoning tokens between calls. The model cannot read its own reasoning (it is encrypted), but the presence of those tokens lets it continue from where it left off instead of starting over.
+
+The impact is measurable. Not "feels smarter" measurable. SWE-bench measurable.
+
+> "We've seen like four to five percentage point boosts in like SWE-bench just by like having it like keep its intelligence along the way."
+>
+> Brian Fioca, [Roo Cast S01E16](https://www.youtube.com/watch?v=Nu5TeVQbOOE&t=1951)
+
+Four to five percentage points on a coding benchmark is significant. And that improvement comes entirely from not throwing away context that the model already generated.
+
+## The tradeoff
+
+Preserving reasoning tokens costs more. You are storing and passing more data between calls. If your task completes in one turn, this overhead adds cost without benefit.
+
+But if your task takes multiple turns - and most real debugging tasks do - the cost of re-reasoning from scratch compounds. The model spends tokens rediscovering what it already figured out. You pay for the same file searches multiple times. You wait for reasoning that already happened.
+
+The question is not "is this more expensive per call?" The question is "is this cheaper per completed task?"
+
+## Why this matters for your workflow
+
+If you are integrating a reasoning model into an agentic workflow, check what happens to the reasoning tokens between turns. If they get discarded, your agent is effectively amnesiac. Every turn starts fresh.
+
+This shows up as:
+
+- Repeated file searches for files already analyzed
+- The same diagnostic questions asked multiple times
+- "I'll need to check the codebase" on turn five of a debugging session
+
+The model is not being lazy or forgetful. The model literally cannot see what it thought about on previous turns.
+
+## How Roo Code closes the loop on context
+
+Roo Code addresses the reasoning amnesia problem by maintaining rich context across the entire task lifecycle. When Roo Code runs commands, reads files, and iterates on test failures, it preserves the full chain of reasoning rather than discarding it between turns.
+
+This is why BYOK (Bring Your Own Key) matters for multi-turn coding tasks: you control the model and the context window, and Roo Code structures the conversation to maximize what the model remembers. The agent does not re-search files it already analyzed because the context architecture prevents that waste.
+
+**Roo Code's agentic loop preserves reasoning context across turns, eliminating the repeated file searches and redundant analysis that plague stateless API integrations.**
+
+## Chat completions vs. responses API: a comparison
+
+| Dimension                   | Chat Completions (Stateless)  | Responses API (Context-Preserving)   |
+| --------------------------- | ----------------------------- | ------------------------------------ |
+| Reasoning token persistence | Discarded after each turn     | Encrypted and preserved              |
+| File search behavior        | Repeats on every turn         | Continues from prior analysis        |
+| Multi-turn task cost        | Compounds with redundant work | Amortized across turns               |
+| SWE-bench performance       | Baseline                      | 4-5 percentage points higher         |
+| Best use case               | Single-turn queries           | Multi-turn debugging and refactoring |
+
+## The shift
+
+Audit your API integration. If you are using chat completions with a reasoning model, the reasoning tokens are gone after each turn. Consider the responses API, or whatever your provider offers for preserving context between calls.
+
+The model already did the work. Stop making it do the work again.
+
+## Frequently asked questions
+
+### Why does my AI assistant keep searching the same files?
+
+When using chat completions with reasoning models, the model's internal reasoning tokens are discarded after each response. This means every new prompt starts fresh with no memory of prior analysis. The repeated file searches are not a bug or laziness - the model genuinely has no record of what it thought about previously.
+
+### What are reasoning tokens and why do they matter?
+
+Reasoning tokens are the intermediate thoughts a model generates while working through a problem. They represent the "thinking" that happens before the final answer. In chat completions, these tokens get discarded, but the responses API preserves them in encrypted form, letting the model continue from where it left off.
+
+### How much does preserving reasoning context actually help?
+
+According to benchmarks discussed on Roo Cast, preserving reasoning tokens between API calls results in a 4-5 percentage point improvement on SWE-bench. This is a significant gain that comes purely from not throwing away context the model already generated.
+
+### Does Roo Code handle reasoning context differently than raw API calls?
+
+Yes. Roo Code's architecture maintains context across the full task lifecycle. When the agent reads files, runs tests, and iterates on failures, that context persists rather than resetting on each turn. This eliminates the redundant file searches and repeated analysis that happen with stateless API integrations.
+
+### When should I pay the extra cost for context preservation?
+
+If your task completes in one turn, preserving reasoning tokens adds cost without benefit. But for multi-turn tasks like debugging, refactoring, or complex feature implementation, the cost of re-reasoning from scratch compounds quickly. The right question is not "is this more expensive per call?" but "is this cheaper per completed task?"
diff --git a/apps/web-roo-code/src/content/blog/without-evals-you-cannot-iterate-on-prompts.md b/apps/web-roo-code/src/content/blog/without-evals-you-cannot-iterate-on-prompts.md
new file mode 100644
index 00000000000..d5f442852ec
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/without-evals-you-cannot-iterate-on-prompts.md
@@ -0,0 +1,123 @@
+---
+title: Without Evals You Cannot Iterate on Prompts
+slug: without-evals-you-cannot-iterate-on-prompts
+description: Why LLM evals are the foundation for prompt iteration - how to escape the trap of fixing one edge case while breaking two others, with practical steps to build regression detection into your workflow.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - evals
+    - prompt-engineering
+    - ai-coding-agents
+    - developer-workflow
+status: draft
+publish_date: "2025-04-30"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+Three prompts.
+
+One edge case fixed.
+
+Two new edge cases broken.
+
+## The trap
+
+You ship an LLM-powered prototype in a day. It works. The demo lands. Someone asks you to handle a new edge case.
+
+You tweak the prompt. The edge case is fixed. You push to staging.
+
+Then another edge case breaks. You tweak the prompt again. Now the first edge case is broken again. You have no ground truth. You cannot tell if the prompt is getting better or if your expectations just shifted.
+
+This is the iteration trap. Without evals, you are navigating without a map. Every change feels like progress until you realize you have been walking in circles.
+
+## Why gut-checking fails
+
+For narrow tasks, you can spot-check outputs and trust your intuition. Coding agents are not narrow. The domain is too broad: refactoring, debugging, test generation, documentation, code review. Each task has different failure modes. Each failure mode has edge cases you will not think to check manually.
+
+The problem compounds when you are iterating daily. You fix something, ship it, and move on. A week later, you cannot remember what "good" looked like. Your baseline has drifted.
+
+> "There was a while where everyone was getting gas-lit by LLMs when an update would secretly come out and people are like 'this is garbage, was it ever good?' or did I just... my expectations shifted so much."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=1749)
+
+You end up gas-lit by your own model. The output feels worse, but you cannot prove it. Or it feels better, but you cannot replicate it.
+
+## The center of everything
+
+Evals are not a nice-to-have for mature teams. They are the foundation for any iteration at all.
+
+The pattern is simple: define a set of inputs, define expected outputs, run the model, compare results. When you tweak a prompt, you run the eval suite. If the score goes up, you are moving forward. If the score goes down, you caught a regression before it hit production.
+
+> "You can build a prototype using LLMs amazingly fast... But when you try iterate on it, try changing the prompt or you're seeing that there's an edge case that it's failing horribly on and you tweak the prompt and now some other edge case pops up and the LLM starts failing at that. Evals are at the center of everything."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=1681)
+
+The key insight: evals are not about proving your model is good. They are about knowing when your model gets worse. Regression detection is the unlock.
+
+## Domain-specific benchmarks
+
+Generic evals will not save you. A coding agent that scores well on HumanEval might still fail on your monorepo with its custom build system and legacy patterns.
+
+The evals that matter are the ones built from your actual edge cases. Every time you find a failure, you add it to the suite. Over time, the suite becomes a map of every trap the model can fall into.
+
+> "Giving general guidance is incredibly hard and to solve the problem I think you need a set of evals and a set of benchmarks for domain-specific use cases."
+>
+> David Leen, [Office Hours S01E04](https://www.youtube.com/watch?v=ZnKkwWuQ9QQ&t=1768)
+
+This is work. It is slower than just tweaking prompts and hoping. But it is the difference between iterating and wandering.
+
+## Old approach vs. eval-driven development
+
+| Dimension            | Without Evals                         | With Evals                                       |
+| -------------------- | ------------------------------------- | ------------------------------------------------ |
+| Feedback loop        | Manual spot-checking, intuition-based | Automated regression detection on every change   |
+| Baseline drift       | No record of what "good" looked like  | Persistent ground truth you can measure against  |
+| Edge case handling   | Fix one, break two unknowingly        | Fix one, immediately see if others regressed     |
+| Team velocity        | Slows over time as changes feel risky | Accelerates because you can ship with confidence |
+| Institutional memory | Lost when people leave or forget      | Encoded in the eval suite permanently            |
+
+## How Roo Code closes the loop on prompt iteration
+
+Roo Code is an AI coding agent that closes the loop: it proposes diffs, runs commands and tests, and iterates based on results. This architecture directly supports eval-driven development. When you configure Roo Code with BYOK (bring your own key), you maintain full control over which models run your evals and at what cost.
+
+The agent can execute your eval suite after each prompt change, surface regressions immediately, and iterate on fixes without manual intervention. Instead of guessing whether a prompt tweak helped or hurt, you get concrete feedback from your domain-specific test cases.
+
+**For teams building with coding agents, evals are not optional - they are the foundation that makes confident iteration possible.**
+
+## Why this matters for your team
+
+For a Series A - C team with three engineers, the iteration trap is especially dangerous. You do not have the bandwidth to manually QA every prompt change. You do not have institutional memory to remember what "good" looked like six months ago.
+
+Without evals, every prompt tweak is a coin flip. With evals, you can confidently ship changes knowing you have not broken the cases that matter.
+
+The compounding effect: teams with evals iterate faster because they can move without fear. Teams without evals slow down over time because every change feels risky.
+
+## Start here
+
+If you have no evals today, start with three test cases: one happy path, one known edge case, one previous failure. Run them before and after every prompt change. Expand the suite as you find new failures.
+
+The goal is not perfection. The goal is a baseline you can measure against. Everything else follows from that.
+
+## Frequently asked questions
+
+### What is the minimum eval suite to start with?
+
+Start with three test cases: one happy path that covers core functionality, one known edge case from real usage, and one previous failure you have already fixed. This gives you immediate regression detection without requiring weeks of setup. Expand the suite incrementally as you discover new failure modes.
+
+### How do I know if my evals are testing the right things?
+
+Your evals should come from real failures, not hypothetical scenarios. Every time you find a bug or edge case in production, add it to the suite. Over time, the suite becomes a comprehensive map of every trap your model can fall into. If you are adding test cases that never fail, they are not providing signal.
+
+### Can Roo Code help automate eval execution?
+
+Yes. Roo Code closes the loop by running commands and tests automatically. You can configure it to execute your eval suite after prompt changes, surface regressions immediately, and iterate on fixes. With BYOK, you control which models run your evals and manage costs directly with your API provider.
+
+### How do evals differ from traditional unit tests?
+
+Traditional unit tests check deterministic code paths. LLM evals check probabilistic outputs against expected patterns or quality thresholds. You need tolerance for variation while still catching meaningful regressions. The structure is similar - inputs, expected outputs, comparison - but the scoring may involve fuzzy matching, semantic similarity, or rubric-based grading.
+
+### What if my team does not have time to build an eval suite?
+
+You do not have time not to. Without evals, every prompt change is a gamble that costs more time in debugging and rollbacks than building the suite would have cost. Start with three test cases today. The investment compounds: teams with evals iterate faster because they can ship without fear.
diff --git a/apps/web-roo-code/src/content/blog/working-prototypes-beat-specs.md b/apps/web-roo-code/src/content/blog/working-prototypes-beat-specs.md
new file mode 100644
index 00000000000..b9eeac3138d
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/working-prototypes-beat-specs.md
@@ -0,0 +1,125 @@
+---
+title: Working Prototypes Beat Specs
+slug: working-prototypes-beat-specs
+description: Why clickable prototypes eliminate guesswork and alignment meetings that specs create - and how AI coding agents make prototype-first workflows the new default.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - product-development
+    - prototyping
+    - workflow
+    - ai-coding-agents
+status: draft
+publish_date: "2025-10-22"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+A PRD is a guessing game with shared vocabulary.
+
+A prototype is a decision you can click.
+
+## The gap between heads
+
+You write a spec. You think it's clear. You describe the flow, the edge cases, the states. You hand it to engineering.
+
+They read it. They fill in the blanks you didn't know you left. They build what they understood.
+
+Three weeks later, you're in a review meeting, looking at something that matches every word you wrote but misses the thing you meant.
+
+The problem isn't the spec. The problem is that everyone reading a document is doing guesswork. They're filling gaps with their own assumptions. And those assumptions rarely match.
+
+> "You end up doing a bunch of guesswork and then people are surprised when the guesswork that other people are doing doesn't actually connect with the guesswork that they were doing in their head."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=721)
+
+The spec felt complete when you wrote it. It wasn't. It was a scaffolding for assumptions.
+
+## The prototype forces the conversation
+
+A prototype doesn't describe what you want. It shows what you want.
+
+When you walk into a room with something clickable, the conversation changes. You're not debating interpretations. You're pointing at a screen saying "this button should do this" and watching whether it does.
+
+The cost of getting to that point used to be high. You needed engineering time to build a throwaway. Or you needed to mock something in Figma and hope the static screens captured the flow well enough.
+
+That cost has collapsed. Tools like Roo Code let you build something functional without writing production code yourself. You can generate a working prototype, click through it, find the holes, and iterate before engineering ever gets involved.
+
+The prototype forces you to confront edge cases that disappear in mocks. What happens when this list is empty? What does the error state look like? Where does this data come from?
+
+> "It forces design and product to think through the experience edge cases that aren't evident on a mock."
+>
+> Hannes Rudolph, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=706)
+
+You find out what's missing when you try to use it, not when engineering asks "what should happen here?" two weeks into the build.
+
+## The handoff gets cleaner
+
+The prototype isn't production code. It's not supposed to be.
+
+But it gives engineering something concrete to work from. They can see the flow, click through the states, understand the logic. The handoff isn't "read this doc and build what you think it means." It's "here's what it should do; make it production-ready."
+
+When the prototype lives in a repo, even as a rough draft, the artifacts are already there. Issues, commits, iteration history. Engineering can fork from something real instead of starting from interpreted text.
+
+The tradeoff is time upfront. Building a prototype takes longer than writing a spec. But the time you spend building is time you're not spending in alignment meetings, redoing work, or debugging misunderstandings.
+
+## Why this matters for your workflow
+
+If you're a PM or designer working with a small team, the leverage is significant. You stop being the person who hands off documents and waits. You become the person who shows up with something clickable and says "here's what I'm thinking."
+
+> "It's way easier to show up with something like a prototype and be like, 'Hey, here's what I'm thinking.' And there's much less guesswork in that."
+>
+> Logan Kilpatrick, [Roo Cast S01E15](https://www.youtube.com/watch?v=HPdvro2nnRg&t=687)
+
+For teams shipping 4-5 features a quarter, replacing even half of your spec-first workflows with prototype-first conversations can eliminate entire rounds of revision. The feedback happens before the build, not after.
+
+You don't need to become an engineer to do this. You need a tool that lets you generate working code from intent. Roo Code gives you that: describe what you want, iterate on the output, and hand off something that works instead of something that hopes to be understood.
+
+## The default has shifted
+
+The cost of bringing an idea to something you can touch is now low enough that it should be the default.
+
+If you're still writing specs and hoping people interpret them correctly, try building one prototype instead. Click through it. Find the gaps. Then hand it off.
+
+The guesswork disappears when everyone's looking at the same screen.
+
+## How Roo Code closes the loop on prototype-first workflows
+
+Roo Code is an AI coding agent that closes the loop: it can propose code, run commands, execute tests, and iterate based on results. For prototype-first workflows, this means PMs and designers can describe what they want in natural language, watch Roo Code generate a working prototype, and then iterate on that prototype through conversation rather than code.
+
+Because Roo Code operates with BYOK (bring your own key), you control your AI provider and spend tokens intentionally for outcomes. The prototype you build stays in your repo, with full commit history, ready for engineering to fork into production code.
+
+**The core shift**: instead of writing specs that get interpreted, you generate prototypes that get clicked. Roo Code makes this workflow accessible to anyone who can describe what they want.
+
+## Spec-first vs. prototype-first workflows
+
+| Dimension           | Spec-first approach               | Prototype-first approach              |
+| ------------------- | --------------------------------- | ------------------------------------- |
+| Feedback timing     | After engineering builds          | Before engineering starts             |
+| Edge case discovery | During implementation             | During prototype iteration            |
+| Alignment method    | Meetings to interpret documents   | Pointing at screens together          |
+| Handoff artifact    | Text that requires interpretation | Working code that demonstrates intent |
+| Revision cycles     | Multiple rounds post-build        | Iteration happens pre-build           |
+
+## Frequently asked questions
+
+### How long does it take to build a prototype with an AI coding agent?
+
+Building a clickable prototype with Roo Code typically takes hours rather than days. You describe the flow you want, iterate on the output through conversation, and end up with something functional enough to test assumptions. The time investment is front-loaded, but it replaces the alignment meetings and revision cycles that specs create downstream.
+
+### Do I need to know how to code to build prototypes this way?
+
+No. Roo Code generates working code from natural language descriptions. You describe what you want the prototype to do, review the output, and iterate through conversation. The skill you need is clarity about what you're trying to build, not programming expertise.
+
+### What happens to the prototype after the handoff?
+
+The prototype lives in a repo with full commit history. Engineering can fork from it, reference the iteration decisions, and build production-ready code from something concrete rather than interpreted text. The prototype becomes documentation of intent, not just a throwaway.
+
+### How does Roo Code handle edge cases in prototypes?
+
+When you click through a prototype generated by Roo Code, you encounter the edge cases that disappear in static mocks. Empty states, error conditions, data dependencies - these surface when you interact with something real. You can then iterate with Roo Code to address each edge case before engineering gets involved.
+
+### Is the prototype meant to be production code?
+
+No. The prototype is a decision tool, not a production artifact. Its purpose is to eliminate interpretation gaps and force conversations about what the product should actually do. Engineering takes the prototype as a reference and builds production-ready code from it.
diff --git a/apps/web-roo-code/src/content/blog/xml-tags-may-be-more-reliable-than-native-function-calling.md b/apps/web-roo-code/src/content/blog/xml-tags-may-be-more-reliable-than-native-function-calling.md
new file mode 100644
index 00000000000..5ca74181c5f
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/xml-tags-may-be-more-reliable-than-native-function-calling.md
@@ -0,0 +1,113 @@
+---
+title: XML Tags May Be More Reliable Than Native Function Calling
+slug: xml-tags-may-be-more-reliable-than-native-function-calling
+description: Discover why XML tag-based tool definitions may outperform native function calling for AI agents, with practical guidance on when to swap formats for better reliability.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-agents
+    - function-calling
+    - prompt-engineering
+    - tool-use
+status: draft
+publish_date: "2025-04-22"
+publish_time_pt: "9:00am"
+source: "Office Hours"
+---
+
+The model called the tool. The tool returned nothing.
+
+You check the logs. The function call looks fine. The schema is valid. The model just... didn't parse the response correctly.
+
+## The format matters more than you think
+
+You're building an agent. You wire up native function calling because that's the documented approach: define a JSON schema, the model returns structured JSON, you parse and execute.
+
+It works. Until it doesn't.
+
+The failure mode is subtle. The model calls the tool, but the arguments are slightly wrong. Or the model hallucinates a field that isn't in the schema. Or it calls the right tool with the wrong parameters, and you spend an hour debugging what looks like a model reasoning problem when it's actually a format problem.
+
+Native function calling with structured JSON outputs should be the reliable path. It's what the API documentation recommends. It's what most tutorials show. But some practitioners are finding that an older approach holds up when native calls get flaky.
+
+## The XML alternative
+
+Cline uses XML tags to define tools instead of native function calling. Rather than relying on the model's built-in function calling capability, tools are defined using XML structure in the prompt itself.
+
+The early feedback is that it works more reliably across different models.
+
+> "Cline uses the XML tag style approach for defining tools. And so that seems to be a little bit more reliable than some of the other models that they've been experimenting with."
+>
+> Paige Bailey, [Office Hours S01E03](https://www.youtube.com/watch?v=rqMSBUSJos8&t=874)
+
+Why would an older, seemingly "less native" approach work better? One hypothesis: XML tagging is a format the models have seen extensively in training data. The structure is unambiguous. Opening and closing tags create clear boundaries. The model doesn't have to switch between "reasoning mode" and "structured output mode" in the same way.
+
+Native function calling asks the model to produce JSON that matches a schema while also reasoning about when and how to use the tool. XML tagging keeps everything in the same text stream. The model writes XML because it's writing text, not because it's switching to a special structured output mode.
+
+## The tradeoff
+
+XML tagging isn't universally better. Native function calling has real advantages: it's the documented API feature, it has better tooling support, and providers are actively improving it.
+
+The tradeoff is reliability vs. ecosystem support. If you're using a single model from a single provider and native function calling works consistently, there's no reason to switch. If you're building an agent that needs to work across multiple models, or if you're seeing inconsistent tool use that you can't explain, the format is worth investigating.
+
+> "I would be really curious to see if you've created benchmarks or eval showing different performance between using native function calling versus this XML tagging style and approach."
+>
+> Paige Bailey, [Office Hours S01E03](https://www.youtube.com/watch?v=rqMSBUSJos8&t=845)
+
+The honest answer: the data is thin. Practitioners report better results with XML tagging, but rigorous benchmarks comparing the two approaches are rare. If you build one, that data would be useful to the community.
+
+## Native function calling vs. XML tagging
+
+| Dimension               | Native Function Calling                                           | XML Tagging                                         |
+| ----------------------- | ----------------------------------------------------------------- | --------------------------------------------------- |
+| Cross-model reliability | Variable - depends on provider implementation                     | More consistent across different models             |
+| Tooling support         | Strong - first-party SDKs and documentation                       | Manual - requires prompt engineering                |
+| Debugging               | Opaque - errors happen inside the model's structured output layer | Transparent - tool calls visible in the text stream |
+| Schema enforcement      | Strict - provider validates against schema                        | Flexible - parsing handled in your code             |
+| Training data alignment | Newer convention, less represented in training corpora            | Extensively represented in training data            |
+
+## How Roo Code handles tool format reliability
+
+Roo Code closes the loop by letting the agent run tools, observe results, and iterate until the task is complete. This means tool reliability directly impacts task completion rates.
+
+When you bring your own key (BYOK) and choose your preferred model, you're also choosing that model's function calling implementation. Some models handle native function calling well. Others don't. Rather than forcing you onto a single model that works with one format, Roo Code lets you swap providers and test which combination works best for your specific use case.
+
+**The practical benefit**: if you're seeing tool call failures with one model, you can switch to another model without changing your workflow. The agent keeps closing the loop regardless of which format the underlying model prefers.
+
+## Why this matters for your workflow
+
+If you're debugging an agent and the tool calls keep failing in ways that don't make sense, you have two options. You can assume the model is the problem and try a different model. Or you can assume the format is the problem and try a different format.
+
+The second option is cheaper and faster to test.
+
+Swapping from native function calling to XML tagging is a prompt-level change. You can A/B test it on your existing eval suite without changing your model or your infrastructure. If the reliability improves, you've found your problem. If it doesn't, you've eliminated a variable.
+
+## The concrete next step
+
+If you're seeing inconsistent tool use: try swapping the format before assuming the model is the problem.
+
+Define your tools with XML tags. Run your existing evals. Compare the success rates.
+
+If you find a measurable difference, share the benchmark. The ecosystem needs more data on this.
+
+## Frequently asked questions
+
+### Why do XML tags work better than native function calling for some models?
+
+XML tags appear extensively in model training data, making the format familiar and unambiguous. Opening and closing tags create clear boundaries that models parse reliably. Native function calling requires the model to switch between reasoning and structured output modes, which introduces additional failure points.
+
+### When should I stick with native function calling?
+
+If you're using a single model from a single provider and tool calls work consistently, native function calling is the right choice. It has better tooling support, first-party documentation, and providers are actively improving reliability. Only investigate XML tagging when you see unexplained tool call failures.
+
+### How do I test XML tagging against native function calling?
+
+Define your tools using XML structure in the prompt instead of the native function calling API. Run your existing evaluation suite against both approaches and compare success rates. This is a prompt-level change that doesn't require infrastructure modifications.
+
+### Does Roo Code use XML tagging or native function calling?
+
+Roo Code supports multiple providers through BYOK (bring your own key), which means the underlying tool format depends on which model you choose. This flexibility lets you test different models and find the combination that works most reliably for your specific tasks while the agent continues to close the loop on your behalf.
+
+### Are there benchmarks comparing XML tagging vs. native function calling?
+
+Rigorous public benchmarks are rare. Practitioners report anecdotal improvements with XML tagging, but the community needs more structured data. If you build comparison benchmarks, sharing that data would help others make informed decisions about tool format selection.
diff --git a/apps/web-roo-code/src/content/blog/your-ai-agent-configuration-should-be-taskaware-not-alwayson.md b/apps/web-roo-code/src/content/blog/your-ai-agent-configuration-should-be-taskaware-not-alwayson.md
new file mode 100644
index 00000000000..7a1d9ff7df4
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/your-ai-agent-configuration-should-be-taskaware-not-alwayson.md
@@ -0,0 +1,123 @@
+---
+title: "Your AI Agent Configuration Should Be Task-Aware, Not Always-On"
+slug: your-ai-agent-configuration-should-be-taskaware-not-alwayson
+description: "Learn why thinking mode should be a tool, not a default. Discover how task-aware AI agent configuration reduces token costs and latency while maintaining output quality."
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-agents
+    - configuration
+    - thinking-mode
+    - token-optimization
+status: draft
+publish_date: "2026-01-12"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Default: thinking mode enabled.
+
+Result: you're paying for reasoning on tasks that don't need it.
+
+## The waste pattern
+
+You're running a straightforward refactor. Rename a variable, update the references, run the tests. The model sits there, thinking. Extended reasoning tokens pile up. The task that should take thirty seconds takes two minutes.
+
+The output is the same as it would have been without thinking. Except now you've paid for the cognitive overhead of a model reasoning through a problem that didn't require reasoning.
+
+This is the thinking mode trap. It feels prudent to leave it on. More thinking equals a smarter result, right?
+
+Not when the task is already within the model's capability envelope.
+
+## The configuration principle
+
+Thinking mode is a tool, not a default. Some tasks benefit from extended reasoning: complex architectural decisions, tricky debugging where causality chains are non-obvious, multi-step refactors that require maintaining state across files. Most tasks do not.
+
+The practical split depends on which model you're using and what you're asking it to do.
+
+> "If it's something that can be achieved without thinking, then sure, you should go without thinking. Because the thinking is just going to waste more tokens and take a lot longer to complete the task."
+>
+> Hannes Rudolph, [Roo Cast S01E20](https://www.youtube.com/watch?v=qxC0iyFBfWc&t=28)
+
+The question is not "should I use thinking mode?" The question is "does this specific task benefit from extended reasoning?"
+
+## The model-aware heuristic
+
+Different models have different capability baselines. A task that requires thinking on a smaller model might complete without thinking on a more capable one.
+
+> "When I run Opus, I don't do thinking. When I run Sonnet, I use minimal thinking."
+>
+> Guest, [Roo Cast S01E20](https://www.youtube.com/watch?v=qxC0iyFBfWc&t=0)
+
+The pattern: more capable models need less reasoning scaffolding. Their base capability already handles the task. Adding thinking mode just adds cost and latency without changing the output.
+
+This means your configuration should vary by model, not just by task type. Running Opus with thinking enabled by default is paying twice for capability you already have.
+
+## The audit checklist
+
+Before running a task, ask:
+
+1. **Is this task within the model's base capability?** If you're using Opus for a straightforward refactor, you probably don't need thinking.
+
+2. **Does the task require multi-step causal reasoning?** Debugging a race condition? Thinking might help. Renaming a function? It won't.
+
+3. **Have I run this task type before without thinking?** If the output quality was fine, keep it off.
+
+4. **Am I paying for latency I don't need?** Thinking mode adds time-to-first-token. If you're iterating quickly, that overhead compounds.
+
+The goal is not to eliminate thinking mode. The goal is to use it selectively, on tasks where extended reasoning actually changes the output.
+
+## Always-on vs. task-aware configuration
+
+| Dimension         | Always-On Thinking                      | Task-Aware Configuration                       |
+| ----------------- | --------------------------------------- | ---------------------------------------------- |
+| Token cost        | High - pays for reasoning on every task | Optimized - reasoning only when beneficial     |
+| Latency           | Consistent delays on all tasks          | Fast for simple tasks, slower only when needed |
+| Output quality    | No improvement on simple tasks          | Same quality, matched to task complexity       |
+| Model utilization | Ignores model capability differences    | Adapts configuration to model strengths        |
+| Iteration speed   | Slow feedback loops                     | Fast iteration on routine work                 |
+
+## Why this matters for your workflow
+
+For an engineer running 20-30 tasks per day, the difference between "thinking on everything" and "thinking on 5 tasks that need it" compounds.
+
+Token costs drop. Latency drops. The tasks that need reasoning still get it. The tasks that don't finish in the time they should have finished in the first place.
+
+The configuration shift is small: audit which task types benefit from thinking, then adjust your settings accordingly. Most coding workflows, especially on capable models, complete without it.
+
+## How Roo Code enables task-aware configuration
+
+Roo Code supports task-aware agent configuration through its BYOK (bring your own key) model. Because you connect directly to your LLM provider, you control exactly which model runs each task and whether thinking mode is enabled.
+
+The key pattern: **configure your agent per task type, not globally.** Roo Code's mode system lets you set different model configurations for different workflows. Run Opus without thinking for quick refactors. Enable extended reasoning only when you hit complex debugging or architectural decisions.
+
+This approach lets developers spend tokens intentionally for outcomes rather than paying a blanket reasoning tax on every interaction with the agent.
+
+## The configuration change
+
+If you're using Roo Code with Opus, try disabling thinking mode as your default. Turn it on explicitly when you hit a task that stalls or produces low-quality output without it.
+
+Track which tasks needed thinking. The list is probably shorter than you expect.
+
+## Frequently asked questions
+
+### When should I enable thinking mode for my AI coding agent?
+
+Enable thinking mode when the task requires multi-step causal reasoning that the model cannot handle in a single inference pass. Complex debugging with non-obvious causality chains, architectural decisions that span multiple systems, and refactors requiring state maintenance across many files are good candidates. If the task is straightforward, such as renaming variables, updating imports, or running tests, thinking mode adds cost and latency without improving output.
+
+### Does using a more capable model mean I need thinking mode less often?
+
+Yes. More capable models have higher baseline reasoning ability, so tasks that require thinking on smaller models often complete without it on larger ones. Running Opus with thinking enabled by default is essentially paying twice for capability the model already has. Match your thinking configuration to your model's capability envelope.
+
+### How does Roo Code handle thinking mode configuration?
+
+Roo Code's BYOK architecture means you control model selection and configuration directly. You can set different configurations per mode, enabling thinking for complex architectural work while keeping it disabled for routine coding tasks. This lets you optimize token spend and latency based on task type rather than using a single global setting.
+
+### What's the cost difference between always-on thinking and task-aware configuration?
+
+The exact difference depends on your usage patterns, but engineers running 20-30 agent tasks daily can see significant token savings by limiting thinking to the 5-10 tasks that actually benefit from it. Beyond cost, latency improvements compound when iterating quickly. Tasks that should take 30 seconds no longer take 2 minutes.
+
+### How do I audit which of my tasks actually need thinking mode?
+
+Start by disabling thinking mode as your default, then note which tasks stall or produce lower-quality output. Turn thinking on for those specific task types. After a week, review your list. Most developers find the set of tasks requiring extended reasoning is smaller than expected, concentrated in debugging and complex multi-file changes.
diff --git a/apps/web-roo-code/src/content/blog/your-ai-context-is-perishable-unless-you-standardize.md b/apps/web-roo-code/src/content/blog/your-ai-context-is-perishable-unless-you-standardize.md
new file mode 100644
index 00000000000..0875933a0e8
--- /dev/null
+++ b/apps/web-roo-code/src/content/blog/your-ai-context-is-perishable-unless-you-standardize.md
@@ -0,0 +1,119 @@
+---
+title: Your AI Context Is Perishable Unless You Standardize
+slug: your-ai-context-is-perishable-unless-you-standardize
+description: Learn why AI coding context evaporates after each task and how teams like Smartsheet use shared modes and memory banks to turn individual learnings into compounding team infrastructure.
+primary_schema:
+    - Article
+    - FAQPage
+tags:
+    - ai-context
+    - team-workflows
+    - modes
+    - memory-banks
+status: draft
+publish_date: "2026-01-12"
+publish_time_pt: "9:00am"
+source: "Roo Cast"
+---
+
+Forty-seven prompts refined. Three modes configured. One PR merged.
+
+Context: gone.
+
+## The evaporation problem
+
+You spend an hour teaching your AI coding agent about your codebase. You refine the prompts, configure modes for your specific workflows, build up a rich task history that makes the agent actually useful. Then you commit your code, close the task, and move on.
+
+Next week, a teammate picks up that same file. They start from scratch. All your learnings, your prompt refinements, your mode configurations - invisible. The code shipped. The context evaporated.
+
+JB Brown at Smartsheet has a name for this pattern.
+
+> "I would characterize our efforts as like perishable single engineer work. So I use Roo, prompt it for some stuff... but all of the context and all of the learnings that I put into the prompt history: all that stuff is gone."
+>
+> JB Brown, [Roo Cast S01E19](https://www.youtube.com/watch?v=DG6IB4v_NGE&t=641)
+
+The code survives. The context does not.
+
+## The shift to team-based context
+
+Smartsheet's solution: stop treating AI context as individual and start treating it as team infrastructure.
+
+The pattern has three parts.
+
+**Shared directory conventions.** Documentation and examples live in predictable locations. When the agent indexes the codebase, it finds the same context regardless of which developer is running the task.
+
+**Multi-tenanted memory banks.** Developers can share task context without overwriting each other. No more "my learnings clobbered your learnings" when two people work on the same repo.
+
+> "We've multi-tenanted that so that developers can share a task and not have: get collapse. You know when you check that in have it sort of overwrite and have a clash of two different recent tasks overwriting another."
+>
+> JB Brown, [Roo Cast S01E19](https://www.youtube.com/watch?v=DG6IB4v_NGE&t=750)
+
+**Standard modes per repository.** The same set of modes exists in every repo. When an engineer picks up unfamiliar code, they inherit the team's accumulated AI context instead of starting from scratch.
+
+> "We're now moving to team-based where teams have standards, practices, paradigms that they all use the same way and then they get to benefit from each other from their efforts of the context that they build up and the modes that they build that are specific for that codebase."
+>
+> JB Brown, [Roo Cast S01E19](https://www.youtube.com/watch?v=DG6IB4v_NGE&t=676)
+
+## The tradeoff
+
+This requires upfront coordination. Someone has to define the directory conventions. Someone has to build the shared modes. Someone has to document what goes where.
+
+For a single developer on a side project, this is overhead. For a team shipping production code together, it's the difference between compounding returns and constant restarts.
+
+The pattern also requires discipline. If developers keep their best prompts local, the shared context stays shallow. The benefit only compounds when the team actually contributes to it.
+
+## How Roo Code preserves team context
+
+Roo Code closes the loop on context preservation through its mode and memory bank architecture. With BYOK (bring your own key), teams control their AI infrastructure while building shared context that persists across sessions and developers.
+
+Here's how it works: modes defined in `.roomodes` files live in version control alongside your code. Memory banks store task-specific learnings in a structured format that can be scoped per developer or shared across the team. When a new developer opens the codebase, Roo Code automatically loads the team's accumulated context - the modes, the patterns, the institutional knowledge baked into the configuration.
+
+**The key insight: context that lives in the repo compounds; context that lives in task history expires.**
+
+## Individual vs. team-based AI context
+
+| Dimension              | Individual context                   | Team-based context                    |
+| ---------------------- | ------------------------------------ | ------------------------------------- |
+| Storage location       | Local task history, personal configs | Version-controlled files in repo      |
+| Lifespan               | Expires when task closes             | Persists indefinitely                 |
+| Handoff cost           | Full context rebuild per developer   | Near-zero - inherited automatically   |
+| Improvement trajectory | Linear (one person's learnings)      | Compounding (entire team contributes) |
+| Onboarding impact      | New developers start from scratch    | New developers inherit team knowledge |
+
+## Why this matters for your team
+
+For a five-person engineering team, every handoff is a context reset. Developer A figures out how to prompt the agent to handle your legacy auth system. Developer B picks up a ticket in the same codebase and starts from zero. Multiply this across every codebase, every sprint, every new team member.
+
+The compounding loss is invisible because no one tracks "time spent re-teaching the AI what the last person already knew."
+
+Standard modes and shared memory banks turn that loss into cumulative gain. When developer B opens the codebase, they inherit developer A's learnings. The context lives in the repo, not in a closed task history.
+
+## The first step
+
+Audit where your AI context currently lives. Is it in individual prompt histories? Local mode configurations? Files that never get committed?
+
+Move one piece of context to a shared location this week: a mode definition, a documentation file the agent indexes, a memory bank entry. See if the next developer who touches that code benefits.
+
+Context that lives in the repo compounds. Context that lives in task history expires.
+
+## Frequently asked questions
+
+### Why does AI coding context disappear after each task?
+
+Most AI coding tools store context in session-based task histories tied to individual developers. When you close the task or start a new session, that context has no persistent home. The underlying code gets committed, but the prompts, refinements, and learnings that produced it remain trapped in a closed session that no one else can access.
+
+### How do shared modes prevent context loss?
+
+Shared modes are configuration files that live in your repository alongside your code. They define how the AI agent should behave for specific workflows in that codebase. Because they're version-controlled, any developer who clones the repo automatically inherits the team's accumulated mode configurations without additional setup.
+
+### What is a memory bank in Roo Code?
+
+Memory banks in Roo Code are structured storage for task context that persists between sessions. Teams can configure them to be individual (scoped to one developer) or shared (accessible to everyone working on the repo). Multi-tenanted memory banks let developers contribute learnings without overwriting each other's context.
+
+### How much overhead does team-based context require?
+
+Initial setup requires someone to define directory conventions, create shared modes, and document contribution patterns. For solo developers or side projects, this overhead likely exceeds the benefit. For teams shipping production code together, the investment pays off within the first few handoffs as developers stop rebuilding context from scratch.
+
+### Can individual developers still customize their AI workflows?
+
+Yes. Team-based context establishes a shared foundation, not a rigid constraint. Developers can layer personal configurations on top of shared modes. The key discipline is contributing valuable learnings back to the shared context rather than keeping the best prompts local.
diff --git a/apps/web-roo-code/src/lib/blog/analytics.ts b/apps/web-roo-code/src/lib/blog/analytics.ts
new file mode 100644
index 00000000000..886e8198d73
--- /dev/null
+++ b/apps/web-roo-code/src/lib/blog/analytics.ts
@@ -0,0 +1,40 @@
+/**
+ * Blog-specific PostHog analytics events
+ * MKT-74: Blog Analytics (PostHog)
+ */
+
+import posthog from "posthog-js"
+import type { BlogPost } from "./types"
+
+/**
+ * Track blog index page view
+ */
+export function trackBlogIndexView(): void {
+	if (typeof window !== "undefined" && posthog.__loaded) {
+		posthog.capture("blog_index_view")
+	}
+}
+
+/**
+ * Track individual blog post view
+ */
+export function trackBlogPostView(post: BlogPost): void {
+	if (typeof window !== "undefined" && posthog.__loaded) {
+		posthog.capture("blog_post_view", {
+			slug: post.slug,
+			title: post.title,
+			publish_date: post.publish_date,
+			publish_time_pt: post.publish_time_pt,
+			tags: post.tags,
+		})
+	}
+}
+
+/**
+ * Track Substack subscribe click
+ */
+export function trackSubstackClick(): void {
+	if (typeof window !== "undefined" && posthog.__loaded) {
+		posthog.capture("blog_substack_click")
+	}
+}
diff --git a/apps/web-roo-code/src/lib/blog/content.ts b/apps/web-roo-code/src/lib/blog/content.ts
new file mode 100644
index 00000000000..ea7ed7abb8b
--- /dev/null
+++ b/apps/web-roo-code/src/lib/blog/content.ts
@@ -0,0 +1,205 @@
+/**
+ * Blog content loading from Markdown files
+ * MKT-67: Blog Content Layer
+ */
+
+import fs from "fs"
+import path from "path"
+import matter from "gray-matter"
+import { BlogFrontmatterSchema } from "./validation"
+import type { BlogPost } from "./types"
+import { getNowPt, isPublished, parsePublishTimePt } from "./time"
+import { filterFeaturedPosts } from "./curated"
+
+const BLOG_DIR = path.join(process.cwd(), "src/content/blog")
+
+/** Posts per page for pagination */
+export const POSTS_PER_PAGE = 12
+
+/** Pagination result type */
+export interface PaginatedBlogPosts {
+	posts: BlogPost[]
+	currentPage: number
+	totalPages: number
+	totalPosts: number
+	hasNextPage: boolean
+	hasPreviousPage: boolean
+}
+
+/**
+ * Get all blog posts from the content directory
+ * @param options.includeDrafts - If true, include draft and future posts
+ * @returns Array of blog posts sorted by publish date (newest first)
+ */
+export function getAllBlogPosts(options?: { includeDrafts?: boolean }): BlogPost[] {
+	const nowPt = getNowPt()
+
+	// Ensure blog directory exists
+	if (!fs.existsSync(BLOG_DIR)) {
+		return []
+	}
+
+	const files = fs.readdirSync(BLOG_DIR).filter((f) => f.endsWith(".md"))
+
+	const posts: BlogPost[] = []
+	const slugs = new Map<string, string>() // slug -> filepath for duplicate detection
+
+	for (const file of files) {
+		const filepath = path.join(BLOG_DIR, file)
+		const raw = fs.readFileSync(filepath, "utf8")
+		const { data, content } = matter(raw)
+
+		// Validate frontmatter
+		const result = BlogFrontmatterSchema.safeParse(data)
+		if (!result.success) {
+			const errors = result.error.errors.map((e) => `${e.path.join(".")}: ${e.message}`).join(", ")
+			throw new Error(`Invalid frontmatter in ${file}: ${errors}`)
+		}
+
+		const frontmatter = result.data
+
+		// Check for duplicate slugs
+		if (slugs.has(frontmatter.slug)) {
+			throw new Error(`Duplicate slug "${frontmatter.slug}" found in ${file} and ${slugs.get(frontmatter.slug)}`)
+		}
+		slugs.set(frontmatter.slug, file)
+
+		const post: BlogPost = {
+			...frontmatter,
+			content,
+			filepath: file,
+		}
+
+		// Filter based on options
+		if (options?.includeDrafts) {
+			posts.push(post)
+		} else if (isPublished(post, nowPt)) {
+			posts.push(post)
+		}
+	}
+
+	// Sort by publish_date desc, then publish_time_pt desc
+	return posts.sort((a, b) => {
+		if (a.publish_date !== b.publish_date) {
+			return b.publish_date.localeCompare(a.publish_date)
+		}
+		const aMinutes = parsePublishTimePt(a.publish_time_pt)
+		const bMinutes = parsePublishTimePt(b.publish_time_pt)
+		return bMinutes - aMinutes
+	})
+}
+
+/**
+ * Get paginated blog posts
+ * @param page - Page number (1-indexed)
+ * @param options.includeDrafts - If true, include draft and future posts
+ * @returns Paginated result with posts and pagination metadata
+ */
+export function getPaginatedBlogPosts(page: number = 1, options?: { includeDrafts?: boolean }): PaginatedBlogPosts {
+	const allPosts = getAllBlogPosts(options)
+	const totalPosts = allPosts.length
+	const totalPages = Math.ceil(totalPosts / POSTS_PER_PAGE)
+
+	// Clamp page to valid range
+	const currentPage = Math.max(1, Math.min(page, totalPages || 1))
+
+	const startIndex = (currentPage - 1) * POSTS_PER_PAGE
+	const endIndex = startIndex + POSTS_PER_PAGE
+	const posts = allPosts.slice(startIndex, endIndex)
+
+	return {
+		posts,
+		currentPage,
+		totalPages,
+		totalPosts,
+		hasNextPage: currentPage < totalPages,
+		hasPreviousPage: currentPage > 1,
+	}
+}
+
+/**
+ * Get a single blog post by slug
+ * Returns null if not found or not published
+ * @param slug - The post slug
+ * @returns The blog post or null
+ */
+export function getBlogPostBySlug(slug: string): BlogPost | null {
+	const nowPt = getNowPt()
+
+	// Ensure blog directory exists
+	if (!fs.existsSync(BLOG_DIR)) {
+		return null
+	}
+
+	const files = fs.readdirSync(BLOG_DIR).filter((f) => f.endsWith(".md"))
+
+	for (const file of files) {
+		const filepath = path.join(BLOG_DIR, file)
+		const raw = fs.readFileSync(filepath, "utf8")
+		const { data, content } = matter(raw)
+
+		// Validate frontmatter
+		const result = BlogFrontmatterSchema.safeParse(data)
+		if (!result.success) {
+			continue // Skip invalid posts when looking up by slug
+		}
+
+		const frontmatter = result.data
+
+		if (frontmatter.slug === slug) {
+			const post: BlogPost = {
+				...frontmatter,
+				content,
+				filepath: file,
+			}
+
+			// Only return if published
+			if (isPublished(post, nowPt)) {
+				return post
+			}
+
+			// Post exists but is not published (draft or scheduled)
+			return null
+		}
+	}
+
+	return null
+}
+
+/**
+ * Get adjacent posts (previous and next) for navigation
+ * Posts are ordered newest-first, so:
+ * - "previous" = newer post (earlier in the array)
+ * - "next" = older post (later in the array)
+ * @param slug - The current post's slug
+ * @returns Object with previous and next posts (or null if they don't exist)
+ */
+export function getAdjacentPosts(slug: string): { previous: BlogPost | null; next: BlogPost | null } {
+	const posts = getAllBlogPosts()
+	const currentIndex = posts.findIndex((p) => p.slug === slug)
+
+	if (currentIndex === -1) {
+		return { previous: null, next: null }
+	}
+
+	// Posts are sorted newest-first
+	// "previous" = newer post (index - 1)
+	// "next" = older post (index + 1)
+	const previous = currentIndex > 0 ? (posts[currentIndex - 1] ?? null) : null
+	const next = currentIndex < posts.length - 1 ? (posts[currentIndex + 1] ?? null) : null
+
+	return { previous, next }
+}
+
+/**
+ * Get featured blog posts
+ *
+ * Returns published posts with `featured: true` in frontmatter,
+ * sorted by publish_date (newest first).
+ *
+ * @returns Array of featured blog posts
+ */
+export function getCuratedBlogPosts(): BlogPost[] {
+	const allPosts = getAllBlogPosts()
+	return filterFeaturedPosts(allPosts)
+}
diff --git a/apps/web-roo-code/src/lib/blog/curated.ts b/apps/web-roo-code/src/lib/blog/curated.ts
new file mode 100644
index 00000000000..a7c52bdab93
--- /dev/null
+++ b/apps/web-roo-code/src/lib/blog/curated.ts
@@ -0,0 +1,23 @@
+/**
+ * Curated/featured blog posts utilities
+ *
+ * Featured posts are determined by the `featured: true` frontmatter field.
+ * This approach is scalable: edit the markdown file to add/remove from featured.
+ */
+
+import type { BlogPost } from "./types"
+
+/**
+ * Check if a post is featured based on frontmatter
+ */
+export function isCuratedPost(post: BlogPost): boolean {
+	return post.featured === true
+}
+
+/**
+ * Filter posts to only featured ones
+ * Returns posts sorted by publish_date (newest first)
+ */
+export function filterFeaturedPosts(posts: BlogPost[]): BlogPost[] {
+	return posts.filter((post) => post.featured === true)
+}
diff --git a/apps/web-roo-code/src/lib/blog/index.ts b/apps/web-roo-code/src/lib/blog/index.ts
new file mode 100644
index 00000000000..0d518396c44
--- /dev/null
+++ b/apps/web-roo-code/src/lib/blog/index.ts
@@ -0,0 +1,37 @@
+/**
+ * Blog content layer exports
+ * MKT-67: Blog Content Layer
+ */
+
+// Types
+export type { BlogPost, BlogPostFrontmatter, BlogSource, NowPt } from "./types"
+export type { PaginatedBlogPosts } from "./content"
+
+// Content loading
+export {
+	getAllBlogPosts,
+	getBlogPostBySlug,
+	getAdjacentPosts,
+	getPaginatedBlogPosts,
+	getCuratedBlogPosts,
+	POSTS_PER_PAGE,
+} from "./content"
+
+// Featured posts
+export { isCuratedPost, filterFeaturedPosts } from "./curated"
+
+// Time utilities
+export {
+	getNowPt,
+	parsePublishTimePt,
+	isPublished,
+	formatPostDatePt,
+	calculateReadingTime,
+	formatReadingTime,
+} from "./time"
+
+// Validation
+export { BlogFrontmatterSchema, type ValidatedFrontmatter } from "./validation"
+
+// Analytics
+export { trackBlogIndexView, trackBlogPostView, trackSubstackClick } from "./analytics"
diff --git a/apps/web-roo-code/src/lib/blog/time.ts b/apps/web-roo-code/src/lib/blog/time.ts
new file mode 100644
index 00000000000..473de27abf4
--- /dev/null
+++ b/apps/web-roo-code/src/lib/blog/time.ts
@@ -0,0 +1,147 @@
+/**
+ * Pacific Time utilities for blog publishing
+ * MKT-67: Blog Content Layer
+ */
+
+import type { BlogPost, NowPt } from "./types"
+
+/**
+ * Get the current time in Pacific Time
+ * Returns date as YYYY-MM-DD and minutes since midnight
+ */
+export function getNowPt(): NowPt {
+	const formatter = new Intl.DateTimeFormat("en-US", {
+		timeZone: "America/Los_Angeles",
+		year: "numeric",
+		month: "2-digit",
+		day: "2-digit",
+		hour: "2-digit",
+		minute: "2-digit",
+		hour12: false,
+	})
+
+	const parts = formatter.formatToParts(new Date())
+	const get = (type: string) => parts.find((p) => p.type === type)?.value ?? ""
+
+	const date = `${get("year")}-${get("month")}-${get("day")}`
+	const minutes = parseInt(get("hour"), 10) * 60 + parseInt(get("minute"), 10)
+
+	return { date, minutes }
+}
+
+/**
+ * Parse publish_time_pt string to minutes since midnight
+ * @param time - Time string in h:mmam/pm format (e.g., "9:00am")
+ * @returns Minutes since midnight
+ * @throws Error if format is invalid
+ */
+export function parsePublishTimePt(time: string): number {
+	const match = time.match(/^(1[0-2]|[1-9]):([0-5][0-9])(am|pm)$/i)
+	if (!match) {
+		throw new Error(`Invalid time format: ${time}. Expected h:mmam/pm (e.g., 9:00am)`)
+	}
+
+	const hoursStr = match[1]
+	const minsStr = match[2]
+	const amPm = match[3]
+
+	if (!hoursStr || !minsStr || !amPm) {
+		throw new Error(`Invalid time format: ${time}. Expected h:mmam/pm (e.g., 9:00am)`)
+	}
+
+	let hours = parseInt(hoursStr, 10)
+	const mins = parseInt(minsStr, 10)
+	const isPm = amPm.toLowerCase() === "pm"
+
+	// Convert 12-hour to 24-hour
+	if (hours === 12) {
+		hours = isPm ? 12 : 0
+	} else if (isPm) {
+		hours += 12
+	}
+
+	return hours * 60 + mins
+}
+
+/**
+ * Check if a blog post is published based on PT time
+ * A post is public when:
+ * - status is "published"
+ * - AND (now_pt_date > publish_date OR (now_pt_date == publish_date AND now_pt_minutes >= publish_time_pt_minutes))
+ */
+export function isPublished(post: BlogPost, nowPt: NowPt): boolean {
+	if (post.status !== "published") {
+		return false
+	}
+
+	const postMinutes = parsePublishTimePt(post.publish_time_pt)
+
+	// Public when: now_pt_date > publish_date
+	if (nowPt.date > post.publish_date) {
+		return true
+	}
+
+	// OR (now_pt_date == publish_date AND now_pt_minutes >= publish_time_pt_minutes)
+	if (nowPt.date === post.publish_date && nowPt.minutes >= postMinutes) {
+		return true
+	}
+
+	return false
+}
+
+/**
+ * Format publish date for display
+ * Returns the date as-is in YYYY-MM-DD format
+ */
+export function formatPostDatePt(publishDate: string): string {
+	return publishDate
+}
+
+/**
+ * Calculate reading time for a piece of content
+ * Uses average reading speed of 200 words per minute
+ * @param content - The markdown content to calculate reading time for
+ * @returns Reading time in minutes (minimum 1)
+ */
+export function calculateReadingTime(content: string): number {
+	// Strip markdown syntax for more accurate word count
+	const plainText = content
+		// Remove code blocks
+		.replace(/```[\s\S]*?```/g, "")
+		// Remove inline code
+		.replace(/`[^`]+`/g, "")
+		// Remove images
+		.replace(/!\[.*?\]\(.*?\)/g, "")
+		// Remove links but keep text
+		.replace(/\[([^\]]+)\]\([^)]+\)/g, "$1")
+		// Remove headers markers
+		.replace(/^#{1,6}\s+/gm, "")
+		// Remove emphasis
+		.replace(/[*_]{1,2}([^*_]+)[*_]{1,2}/g, "$1")
+		// Remove horizontal rules
+		.replace(/^[-*_]{3,}\s*$/gm, "")
+		// Remove HTML tags
+		.replace(/<[^>]+>/g, "")
+
+	// Count words (split on whitespace)
+	const words = plainText
+		.trim()
+		.split(/\s+/)
+		.filter((word) => word.length > 0)
+	const wordCount = words.length
+
+	// Calculate reading time (200 words per minute average)
+	const readingTime = Math.ceil(wordCount / 200)
+
+	// Return minimum of 1 minute
+	return Math.max(1, readingTime)
+}
+
+/**
+ * Format reading time for display
+ * @param minutes - Reading time in minutes
+ * @returns Formatted string (e.g., "5 min read")
+ */
+export function formatReadingTime(minutes: number): string {
+	return `${minutes} min read`
+}
diff --git a/apps/web-roo-code/src/lib/blog/types.ts b/apps/web-roo-code/src/lib/blog/types.ts
new file mode 100644
index 00000000000..590bc0a0c6c
--- /dev/null
+++ b/apps/web-roo-code/src/lib/blog/types.ts
@@ -0,0 +1,32 @@
+/**
+ * Blog content types
+ * MKT-67: Blog Content Layer
+ */
+
+/**
+ * Content source for blog posts
+ * Posts derived from podcast episodes have a source; standalone articles may not
+ */
+export type BlogSource = "Office Hours" | "After Hours" | "Roo Cast"
+
+export interface BlogPostFrontmatter {
+	title: string
+	slug: string
+	description: string
+	tags: string[]
+	status: "draft" | "published"
+	publish_date: string // YYYY-MM-DD
+	publish_time_pt: string // h:mmam/pm (e.g., "9:00am")
+	source?: BlogSource // Optional: indicates podcast source
+	featured?: boolean // Optional: marks post as featured
+}
+
+export interface BlogPost extends BlogPostFrontmatter {
+	content: string // Markdown body
+	filepath: string // For error messages
+}
+
+export interface NowPt {
+	date: string // YYYY-MM-DD
+	minutes: number // Minutes since midnight PT
+}
diff --git a/apps/web-roo-code/src/lib/blog/validation.ts b/apps/web-roo-code/src/lib/blog/validation.ts
new file mode 100644
index 00000000000..cbd5e1562de
--- /dev/null
+++ b/apps/web-roo-code/src/lib/blog/validation.ts
@@ -0,0 +1,29 @@
+/**
+ * Blog frontmatter validation using Zod
+ * MKT-67: Blog Content Layer
+ */
+
+import { z } from "zod"
+
+// Slug must be lowercase alphanumeric with hyphens
+const SLUG_REGEX = /^[a-z0-9]+(?:-[a-z0-9]+)*$/
+
+// Time format: h:mmam/pm (e.g., "9:00am", "12:30pm")
+const TIME_REGEX = /^(1[0-2]|[1-9]):([0-5][0-9])(am|pm)$/i
+
+export const BlogFrontmatterSchema = z.object({
+	title: z.string().min(1, "Title is required"),
+	slug: z.string().regex(SLUG_REGEX, "Slug must match ^[a-z0-9]+(?:-[a-z0-9]+)*$"),
+	description: z.string().min(1, "Description is required"),
+	tags: z
+		.array(z.string())
+		.max(15, "Maximum 15 tags allowed")
+		.transform((tags) => tags.map((t) => t.toLowerCase().trim())),
+	status: z.enum(["draft", "published"]),
+	publish_date: z.string().regex(/^\d{4}-\d{2}-\d{2}$/, "Must be YYYY-MM-DD format"),
+	publish_time_pt: z.string().regex(TIME_REGEX, "Must be h:mmam/pm format (e.g., 9:00am)"),
+	source: z.enum(["Office Hours", "After Hours", "Roo Cast"]).optional(),
+	featured: z.boolean().optional(),
+})
+
+export type ValidatedFrontmatter = z.infer<typeof BlogFrontmatterSchema>
diff --git a/apps/web-roo-code/src/lib/constants.ts b/apps/web-roo-code/src/lib/constants.ts
index 0ef5c92851e..9ce9e07deec 100644
--- a/apps/web-roo-code/src/lib/constants.ts
+++ b/apps/web-roo-code/src/lib/constants.ts
@@ -21,7 +21,7 @@ export const EXTERNAL_LINKS = {
 	MARKETPLACE: "https://marketplace.visualstudio.com/items?itemName=RooVeterinaryInc.roo-cline",
 	SECURITY: "https://trust.roocode.com",
 	EVALS: "https://roocode.com/evals",
-	BLOG: "https://blog.roocode.com",
+	BLOG_SUBSTACK: "https://blog.roocode.com",
 	OFFICE_HOURS_PODCAST: "https://www.youtube.com/@RooCodeYT/podcasts",
 	FAQ: "https://roocode.com/#faq",
 	TESTIMONIALS: "https://roocode.com/#testimonials",
@@ -35,4 +35,5 @@ export const EXTERNAL_LINKS = {
 
 export const INTERNAL_LINKS = {
 	PRIVACY_POLICY_WEBSITE: "/privacy",
+	BLOG: "/blog",
 }
diff --git a/apps/web-roo-code/vitest.config.ts b/apps/web-roo-code/vitest.config.ts
new file mode 100644
index 00000000000..746c5c36a19
--- /dev/null
+++ b/apps/web-roo-code/vitest.config.ts
@@ -0,0 +1,14 @@
+import { defineConfig } from "vitest/config"
+import path from "path"
+
+export default defineConfig({
+	test: {
+		include: ["src/**/*.test.{ts,tsx}"],
+		environment: "node",
+	},
+	resolve: {
+		alias: {
+			"@": path.resolve(__dirname, "./src"),
+		},
+	},
+})
diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml
index 417e69a07ad..b3ae135faa0 100644
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -376,6 +376,9 @@ importers:
       framer-motion:
         specifier: ^12.29.2
         version: 12.29.2(@emotion/is-prop-valid@1.2.2)(react-dom@18.3.1(react@18.3.1))(react@18.3.1)
+      gray-matter:
+        specifier: ^4.0.3
+        version: 4.0.3
       lucide-react:
         specifier: ^0.563.0
         version: 0.563.0(react@18.3.1)
@@ -455,6 +458,9 @@ importers:
       tailwindcss:
         specifier: ^3.4.17
         version: 3.4.17
+      vitest:
+        specifier: ^4.0.18
+        version: 4.0.18(@opentelemetry/api@1.9.0)(@types/node@20.17.57)(jiti@2.4.2)(jsdom@26.1.0)(lightningcss@1.30.1)(tsx@4.19.4)(yaml@2.8.0)
 
   packages/build:
     dependencies:
@@ -2474,6 +2480,9 @@ packages:
   '@jridgewell/sourcemap-codec@1.5.0':
     resolution: {integrity: sha512-gv3ZRaISU3fjPAgNsriBRqGWQL6quFx04YMPW/zD8XMLsU32mhCCbfbO6KZFLjvYpCZ8zyDEgqsgf+PwPaM7GQ==}
 
+  '@jridgewell/sourcemap-codec@1.5.5':
+    resolution: {integrity: sha512-cYQ9310grqxueWbl+WuIUIaiUaDcj7WOq5fVhEljNVgRfOUhY9fy2zTvfoqWsnebh8Sl70VScFbICvJnLKB0Og==}
+
   '@jridgewell/trace-mapping@0.3.25':
     resolution: {integrity: sha512-vNk6aEwybGtawWmy/PzwnGDOjCkLWSD2wqvjGGAgOAwCGWySYXfYoxt00IJkTF+8Lb57DwOb3Aa0o9CApepiYQ==}
 
@@ -4802,6 +4811,9 @@ packages:
   '@vitest/expect@3.2.4':
     resolution: {integrity: sha512-Io0yyORnB6sikFlt8QW5K7slY4OjqNX9jmJQ02QDda8lyM6B5oNgVWoSoKPac8/kgnCUzuHQKrSLtu/uOqqrig==}
 
+  '@vitest/expect@4.0.18':
+    resolution: {integrity: sha512-8sCWUyckXXYvx4opfzVY03EOiYVxyNrHS5QxX3DAIi5dpJAAkyJezHCP77VMX4HKA2LDT/Jpfo8i2r5BE3GnQQ==}
+
   '@vitest/mocker@3.2.4':
     resolution: {integrity: sha512-46ryTE9RZO/rfDd7pEqFl7etuyzekzEhUbTW3BvmeO/BcCMEgq59BKhek3dXDWgAj4oMK6OZi+vRr1wPW6qjEQ==}
     peerDependencies:
@@ -4813,18 +4825,41 @@ packages:
       vite:
         optional: true
 
+  '@vitest/mocker@4.0.18':
+    resolution: {integrity: sha512-HhVd0MDnzzsgevnOWCBj5Otnzobjy5wLBe4EdeeFGv8luMsGcYqDuFRMcttKWZA5vVO8RFjexVovXvAM4JoJDQ==}
+    peerDependencies:
+      msw: ^2.4.9
+      vite: ^6.0.0 || ^7.0.0-0
+    peerDependenciesMeta:
+      msw:
+        optional: true
+      vite:
+        optional: true
+
   '@vitest/pretty-format@3.2.4':
     resolution: {integrity: sha512-IVNZik8IVRJRTr9fxlitMKeJeXFFFN0JaB9PHPGQ8NKQbGpfjlTx9zO4RefN8gp7eqjNy8nyK3NZmBzOPeIxtA==}
 
+  '@vitest/pretty-format@4.0.18':
+    resolution: {integrity: sha512-P24GK3GulZWC5tz87ux0m8OADrQIUVDPIjjj65vBXYG17ZeU3qD7r+MNZ1RNv4l8CGU2vtTRqixrOi9fYk/yKw==}
+
   '@vitest/runner@3.2.4':
     resolution: {integrity: sha512-oukfKT9Mk41LreEW09vt45f8wx7DordoWUZMYdY/cyAk7w5TWkTRCNZYF7sX7n2wB7jyGAl74OxgwhPgKaqDMQ==}
 
+  '@vitest/runner@4.0.18':
+    resolution: {integrity: sha512-rpk9y12PGa22Jg6g5M3UVVnTS7+zycIGk9ZNGN+m6tZHKQb7jrP7/77WfZy13Y/EUDd52NDsLRQhYKtv7XfPQw==}
+
   '@vitest/snapshot@3.2.4':
     resolution: {integrity: sha512-dEYtS7qQP2CjU27QBC5oUOxLE/v5eLkGqPE0ZKEIDGMs4vKWe7IjgLOeauHsR0D5YuuycGRO5oSRXnwnmA78fQ==}
 
+  '@vitest/snapshot@4.0.18':
+    resolution: {integrity: sha512-PCiV0rcl7jKQjbgYqjtakly6T1uwv/5BQ9SwBLekVg/EaYeQFPiXcgrC2Y7vDMA8dM1SUEAEV82kgSQIlXNMvA==}
+
   '@vitest/spy@3.2.4':
     resolution: {integrity: sha512-vAfasCOe6AIK70iP5UD11Ac4siNUNJ9i/9PZ3NKx07sG6sUxeag1LWdNrMWeKKYBLlzuK+Gn65Yd5nyL6ds+nw==}
 
+  '@vitest/spy@4.0.18':
+    resolution: {integrity: sha512-cbQt3PTSD7P2OARdVW3qWER5EGq7PHlvE+QfzSC0lbwO+xnt7+XH06ZzFjFRgzUX//JmpxrCu92VdwvEPlWSNw==}
+
   '@vitest/ui@3.2.4':
     resolution: {integrity: sha512-hGISOaP18plkzbWEcP/QvtRW1xDXF2+96HbEX6byqQhAUbiS5oH6/9JwW+QsQCIYON2bI6QZBF+2PvOmrRZ9wA==}
     peerDependencies:
@@ -4833,6 +4868,9 @@ packages:
   '@vitest/utils@3.2.4':
     resolution: {integrity: sha512-fB2V0JFrQSMsCo9HiSq3Ezpdv4iYaXRG1Sx8edX3MwxfyNn83mKiGzOcH+Fkxt4MHxr3y42fQi1oeAInqgX2QA==}
 
+  '@vitest/utils@4.0.18':
+    resolution: {integrity: sha512-msMRKLMVLWygpK3u2Hybgi4MNjcYJvwTb0Ru09+fOyCXIgT5raYP041DRRdiJiI3k/2U6SEbAETB3YtBrUkCFA==}
+
   '@vscode/codicons@0.0.36':
     resolution: {integrity: sha512-wsNOvNMMJ2BY8rC2N2MNBG7yOowV3ov8KlvUE/AiVUlHKTfWsw3OgAOQduX7h0Un6GssKD3aoTVH+TF3DSQwKQ==}
 
@@ -5337,6 +5375,10 @@ packages:
     resolution: {integrity: sha512-mCuXncKXk5iCLhfhwTc0izo0gtEmpz5CtG2y8GiOINBlMVS6v8TMRc5TaLWKS6692m9+dVVfzgeVxR5UxWHTYw==}
     engines: {node: '>=12'}
 
+  chai@6.2.2:
+    resolution: {integrity: sha512-NUPRluOfOiTKBKvWPtSD4PhFvWCqOi0BGStNWs57X9js7XGTprSmFoz5F0tWhR4WPjNeR9jXqdC7/UpSJTnlRg==}
+    engines: {node: '>=18'}
+
   chainsaw@0.1.0:
     resolution: {integrity: sha512-75kWfWt6MEKNC8xYXIdRpDehRYY/tNSgwKaJq+dbbDcxORuVrrQ+SEHoWsniVn9XPYfP4gmdWIeDk/4YNp1rNQ==}
 
@@ -6584,6 +6626,10 @@ packages:
     resolution: {integrity: sha512-/kP8CAwxzLVEeFrMm4kMmy4CCDlpipyA7MYLVrdJIkV0fYF0UaigQHRsxHiuY/GEea+bh4KSv3TIlgr+2UL6bw==}
     engines: {node: '>=12.0.0'}
 
+  expect-type@1.3.0:
+    resolution: {integrity: sha512-knvyeauYhqjOYvQ66MznSMs83wmHrCycNEN6Ao+2AeYEfxUIkuiVxdEa1qlGEPK+We3n0THiDciYSsCcgW/DoA==}
+    engines: {node: '>=12.0.0'}
+
   expect@29.7.0:
     resolution: {integrity: sha512-2Zks0hf1VLFYI1kbh0I5jP3KHHyCHpkfyHBzsSXRFgl/Bg9mWYfMW8oD+PdMPlEwy5HNsR9JutYy6pMeOh61nw==}
     engines: {node: ^14.15.0 || ^16.10.0 || >=18.0.0}
@@ -6687,6 +6733,15 @@ packages:
       picomatch:
         optional: true
 
+  fdir@6.5.0:
+    resolution: {integrity: sha512-tIbYtZbucOs0BRGqPJkshJUYdL+SDH7dVM8gjy+ERp3WAUjLEFJE+02kanyHtwjWOnwrKYBiwAmM0p4kLJAnXg==}
+    engines: {node: '>=12.0.0'}
+    peerDependencies:
+      picomatch: ^3 || ^4
+    peerDependenciesMeta:
+      picomatch:
+        optional: true
+
   fetch-blob@3.2.0:
     resolution: {integrity: sha512-7yAQpD2UMJzLi1Dqv7qFYnPbaPx7ZfFK6PiIxQ4PfkGPyNyl2Ugx+a/umUonmKqjhM4DnfbMvdX6otXq83soQQ==}
     engines: {node: ^12.20 || >= 14.13}
@@ -8102,6 +8157,9 @@ packages:
   magic-string@0.30.17:
     resolution: {integrity: sha512-sNPKHvyjVf7gyjwS4xGTaW/mCnF8wnjtifKBEhxfZ7E/S8tQ0rssrwGNn6q8JH/ohItJfSQp9mBtQYuTlH5QnA==}
 
+  magic-string@0.30.21:
+    resolution: {integrity: sha512-vd2F4YUyEXKGcLHoq+TEyCjxueSeHnFxyyjNp80yg0XV4vUhnDer/lvvlqM/arB5bXQN5K2/3oinyCRyx8T2CQ==}
+
   make-dir@4.0.0:
     resolution: {integrity: sha512-hXdUTZYIVOt1Ex//jAQi+wTZZpUpwBj/0QsOzqegb3rGMMeJiSEu5xLHnYfBrRV4RH2+OCSOO95Is/7x1WJ4bw==}
     engines: {node: '>=10'}
@@ -8626,6 +8684,9 @@ packages:
     resolution: {integrity: sha512-gXah6aZrcUxjWg2zR2MwouP2eHlCBzdV4pygudehaKXSGW4v2AsRQUK+lwwXhii6KFZcunEnmSUoYp5CXibxtA==}
     engines: {node: '>= 0.4'}
 
+  obug@2.1.1:
+    resolution: {integrity: sha512-uTqF9MuPraAQ+IsnPf366RG4cP9RtUi7MLO1N3KEc+wb0a6yKpeL0lmk2IB1jY5KHPAlTc6T/JRdC/YqxHNwkQ==}
+
   ollama@0.5.17:
     resolution: {integrity: sha512-q5LmPtk6GLFouS+3aURIVl+qcAOPC4+Msmx7uBb3pd+fxI55WnGjmLZ0yijI/CYy79x0QPGx3BwC3u5zv9fBvQ==}
 
@@ -8883,6 +8944,10 @@ packages:
     resolution: {integrity: sha512-M7BAV6Rlcy5u+m6oPhAPFgJTzAioX/6B0DxyvDlo9l8+T3nLKbrczg2WLUyzd45L8RqfUMyGPzekbMvX2Ldkwg==}
     engines: {node: '>=12'}
 
+  picomatch@4.0.3:
+    resolution: {integrity: sha512-5gTmgEY/sqK6gFXLIsQNH19lWb4ebPDLA4SdLP7dsWkIXHWlG66oPuVvXSGFPppYZz8ZDZq0dYYrbHfBCVUb1Q==}
+    engines: {node: '>=12'}
+
   pidtree@0.6.0:
     resolution: {integrity: sha512-eG2dWTVw5bzqGRztnHExczNxt5VGsE6OwTeCG3fdUf9KBsZzO3R5OIIIzWR+iZA0NtZ+RDVdaoE2dK1cn6jH4g==}
     engines: {node: '>=0.10'}
@@ -9857,6 +9922,9 @@ packages:
     resolution: {integrity: sha512-RwNA9Z/7PrK06rYLIzFMlaF+l73iwpzsqRIFgbMLbTcLD6cOao82TaWefPXQvB2fOC4AjuYSEndS7N/mTCbkdQ==}
     engines: {node: '>= 0.8'}
 
+  std-env@3.10.0:
+    resolution: {integrity: sha512-5GS12FdOZNliM5mAOxFRg7Ir0pWz8MdpYm6AY6VPkGpbA7ZzmbzNcBJQ0GPvvyWgcY7QAhCgf9Uy89I03faLkg==}
+
   std-env@3.9.0:
     resolution: {integrity: sha512-UGvjygr6F6tpH7o2qyqR6QYpwraIjKSdtzyBdyytFOHmPZY917kwdwLG0RbOjWOnKmnm3PeHjaoLLMie7kPLQw==}
 
@@ -10160,14 +10228,18 @@ packages:
   tinyexec@1.0.1:
     resolution: {integrity: sha512-5uC6DDlmeqiOwCPmK9jMSdOuZTh8bU39Ys6yidB+UTt5hfZUPGAypSgFRiEp+jbi9qH40BLDvy85jIU88wKSqw==}
 
-  tinyglobby@0.2.13:
-    resolution: {integrity: sha512-mEwzpUgrLySlveBwEVDMKk5B57bhLPYovRfPAXD5gA/98Opn0rCDj3GtLwFvCvH5RK9uPCExUROW5NjDwvqkxw==}
-    engines: {node: '>=12.0.0'}
+  tinyexec@1.0.2:
+    resolution: {integrity: sha512-W/KYk+NFhkmsYpuHq5JykngiOCnxeVL8v8dFnqxSD8qEEdRfXk1SDM6JzNqcERbcGYj9tMrDQBYV9cjgnunFIg==}
+    engines: {node: '>=18'}
 
   tinyglobby@0.2.14:
     resolution: {integrity: sha512-tX5e7OM1HnYr2+a2C/4V0htOcSQcoSTH9KgJnVvNm5zm/cyEWKJ7j7YutsH9CxMdtOkkLFy2AHrMci9IM8IPZQ==}
     engines: {node: '>=12.0.0'}
 
+  tinyglobby@0.2.15:
+    resolution: {integrity: sha512-j2Zq4NyQYG5XMST4cbs02Ak8iJUdxRM0XI5QyxXuZOzKOINmWurp3smXu3y5wDcJrptwpSjgXHzIQxR0omXljQ==}
+    engines: {node: '>=12.0.0'}
+
   tinypool@1.1.1:
     resolution: {integrity: sha512-Zba82s87IFq9A9XmjiX5uZA/ARWDrB03OHlq+Vw1fSdt0I+4/Kutwy8BP4Y/y/aORMo61FQ0vIb5j44vSo5Pkg==}
     engines: {node: ^18.0.0 || >=20.0.0}
@@ -10176,6 +10248,10 @@ packages:
     resolution: {integrity: sha512-op4nsTR47R6p0vMUUoYl/a+ljLFVtlfaXkLQmqfLR1qHma1h/ysYk4hEXZ880bf2CYgTskvTa/e196Vd5dDQXw==}
     engines: {node: '>=14.0.0'}
 
+  tinyrainbow@3.0.3:
+    resolution: {integrity: sha512-PSkbLUoxOFRzJYjjxHJt9xro7D+iilgMX/C9lawzVuYiIdcihh9DXmVibBe8lmcFrRi/VzlPjBxbN7rH24q8/Q==}
+    engines: {node: '>=14.0.0'}
+
   tinyspy@4.0.3:
     resolution: {integrity: sha512-t2T/WLB2WRgZ9EpE4jgPJ9w+i66UZfDc8wHh0xrwiRNN+UwH98GIJkTeZqX9rg0i0ptwzqW+uYeIF0T4F8LR7A==}
     engines: {node: '>=14.0.0'}
@@ -10730,6 +10806,40 @@ packages:
       jsdom:
         optional: true
 
+  vitest@4.0.18:
+    resolution: {integrity: sha512-hOQuK7h0FGKgBAas7v0mSAsnvrIgAvWmRFjmzpJ7SwFHH3g1k2u37JtYwOwmEKhK6ZO3v9ggDBBm0La1LCK4uQ==}
+    engines: {node: ^20.0.0 || ^22.0.0 || >=24.0.0}
+    hasBin: true
+    peerDependencies:
+      '@edge-runtime/vm': '*'
+      '@opentelemetry/api': ^1.9.0
+      '@types/node': ^20.0.0 || ^22.0.0 || >=24.0.0
+      '@vitest/browser-playwright': 4.0.18
+      '@vitest/browser-preview': 4.0.18
+      '@vitest/browser-webdriverio': 4.0.18
+      '@vitest/ui': 4.0.18
+      happy-dom: '*'
+      jsdom: '*'
+    peerDependenciesMeta:
+      '@edge-runtime/vm':
+        optional: true
+      '@opentelemetry/api':
+        optional: true
+      '@types/node':
+        optional: true
+      '@vitest/browser-playwright':
+        optional: true
+      '@vitest/browser-preview':
+        optional: true
+      '@vitest/browser-webdriverio':
+        optional: true
+      '@vitest/ui':
+        optional: true
+      happy-dom:
+        optional: true
+      jsdom:
+        optional: true
+
   void-elements@3.1.0:
     resolution: {integrity: sha512-Dhxzh5HZuiHQhbvTW9AMetFfBHDMYpo23Uo9btPXgdYP+3T5S+p+jgNy7spra+veYhBP2dCSgxR/i2Y02h5/6w==}
     engines: {node: '>=0.10.0'}
@@ -12626,6 +12736,8 @@ snapshots:
 
   '@jridgewell/sourcemap-codec@1.5.0': {}
 
+  '@jridgewell/sourcemap-codec@1.5.5': {}
+
   '@jridgewell/trace-mapping@0.3.25':
     dependencies:
       '@jridgewell/resolve-uri': 3.1.2
@@ -15149,6 +15261,15 @@ snapshots:
       chai: 5.2.0
       tinyrainbow: 2.0.0
 
+  '@vitest/expect@4.0.18':
+    dependencies:
+      '@standard-schema/spec': 1.1.0
+      '@types/chai': 5.2.2
+      '@vitest/spy': 4.0.18
+      '@vitest/utils': 4.0.18
+      chai: 6.2.2
+      tinyrainbow: 3.0.3
+
   '@vitest/mocker@3.2.4(vite@6.3.5(@types/node@20.17.50)(jiti@2.4.2)(lightningcss@1.30.1)(tsx@4.19.4)(yaml@2.8.0))':
     dependencies:
       '@vitest/spy': 3.2.4
@@ -15173,26 +15294,51 @@ snapshots:
     optionalDependencies:
       vite: 6.3.5(@types/node@24.2.1)(jiti@2.4.2)(lightningcss@1.30.1)(tsx@4.19.4)(yaml@2.8.0)
 
+  '@vitest/mocker@4.0.18(vite@6.3.6(@types/node@20.17.57)(jiti@2.4.2)(lightningcss@1.30.1)(tsx@4.19.4)(yaml@2.8.0))':
+    dependencies:
+      '@vitest/spy': 4.0.18
+      estree-walker: 3.0.3
+      magic-string: 0.30.21
+    optionalDependencies:
+      vite: 6.3.6(@types/node@20.17.57)(jiti@2.4.2)(lightningcss@1.30.1)(tsx@4.19.4)(yaml@2.8.0)
+
   '@vitest/pretty-format@3.2.4':
     dependencies:
       tinyrainbow: 2.0.0
 
+  '@vitest/pretty-format@4.0.18':
+    dependencies:
+      tinyrainbow: 3.0.3
+
   '@vitest/runner@3.2.4':
     dependencies:
       '@vitest/utils': 3.2.4
       pathe: 2.0.3
       strip-literal: 3.0.0
 
+  '@vitest/runner@4.0.18':
+    dependencies:
+      '@vitest/utils': 4.0.18
+      pathe: 2.0.3
+
   '@vitest/snapshot@3.2.4':
     dependencies:
       '@vitest/pretty-format': 3.2.4
       magic-string: 0.30.17
       pathe: 2.0.3
 
+  '@vitest/snapshot@4.0.18':
+    dependencies:
+      '@vitest/pretty-format': 4.0.18
+      magic-string: 0.30.21
+      pathe: 2.0.3
+
   '@vitest/spy@3.2.4':
     dependencies:
       tinyspy: 4.0.3
 
+  '@vitest/spy@4.0.18': {}
+
   '@vitest/ui@3.2.4(vitest@3.2.4)':
     dependencies:
       '@vitest/utils': 3.2.4
@@ -15210,6 +15356,11 @@ snapshots:
       loupe: 3.1.4
       tinyrainbow: 2.0.0
 
+  '@vitest/utils@4.0.18':
+    dependencies:
+      '@vitest/pretty-format': 4.0.18
+      tinyrainbow: 3.0.3
+
   '@vscode/codicons@0.0.36': {}
 
   '@vscode/ripgrep@1.17.0':
@@ -15795,6 +15946,8 @@ snapshots:
       loupe: 3.1.3
       pathval: 2.0.0
 
+  chai@6.2.2: {}
+
   chainsaw@0.1.0:
     dependencies:
       traverse: 0.3.9
@@ -17130,6 +17283,8 @@ snapshots:
 
   expect-type@1.2.1: {}
 
+  expect-type@1.3.0: {}
+
   expect@29.7.0:
     dependencies:
       '@jest/expect-utils': 29.7.0
@@ -17259,6 +17414,10 @@ snapshots:
     optionalDependencies:
       picomatch: 4.0.2
 
+  fdir@6.5.0(picomatch@4.0.3):
+    optionalDependencies:
+      picomatch: 4.0.3
+
   fetch-blob@3.2.0:
     dependencies:
       node-domexception: 1.0.0
@@ -18777,6 +18936,10 @@ snapshots:
     dependencies:
       '@jridgewell/sourcemap-codec': 1.5.0
 
+  magic-string@0.30.21:
+    dependencies:
+      '@jridgewell/sourcemap-codec': 1.5.5
+
   make-dir@4.0.0:
     dependencies:
       semver: 7.7.3
@@ -19570,6 +19733,8 @@ snapshots:
       define-properties: 1.2.1
       es-object-atoms: 1.1.1
 
+  obug@2.1.1: {}
+
   ollama@0.5.17:
     dependencies:
       whatwg-fetch: 3.6.20
@@ -19857,6 +20022,8 @@ snapshots:
 
   picomatch@4.0.2: {}
 
+  picomatch@4.0.3: {}
+
   pidtree@0.6.0: {}
 
   pify@2.3.0: {}
@@ -21078,6 +21245,8 @@ snapshots:
 
   statuses@2.0.1: {}
 
+  std-env@3.10.0: {}
+
   std-env@3.9.0: {}
 
   stdin-discarder@0.2.2: {}
@@ -21422,20 +21591,24 @@ snapshots:
 
   tinyexec@1.0.1: {}
 
-  tinyglobby@0.2.13:
-    dependencies:
-      fdir: 6.4.6(picomatch@4.0.2)
-      picomatch: 4.0.2
+  tinyexec@1.0.2: {}
 
   tinyglobby@0.2.14:
     dependencies:
       fdir: 6.4.6(picomatch@4.0.2)
       picomatch: 4.0.2
 
+  tinyglobby@0.2.15:
+    dependencies:
+      fdir: 6.5.0(picomatch@4.0.3)
+      picomatch: 4.0.3
+
   tinypool@1.1.1: {}
 
   tinyrainbow@2.0.0: {}
 
+  tinyrainbow@3.0.3: {}
+
   tinyspy@4.0.3: {}
 
   tldts-core@6.1.86: {}
@@ -21980,7 +22153,7 @@ snapshots:
       picomatch: 4.0.2
       postcss: 8.5.6
       rollup: 4.40.2
-      tinyglobby: 0.2.13
+      tinyglobby: 0.2.14
     optionalDependencies:
       '@types/node': 20.17.50
       fsevents: 2.3.3
@@ -21996,7 +22169,7 @@ snapshots:
       picomatch: 4.0.2
       postcss: 8.5.6
       rollup: 4.40.2
-      tinyglobby: 0.2.13
+      tinyglobby: 0.2.14
     optionalDependencies:
       '@types/node': 20.17.57
       fsevents: 2.3.3
@@ -22012,7 +22185,7 @@ snapshots:
       picomatch: 4.0.2
       postcss: 8.5.6
       rollup: 4.40.2
-      tinyglobby: 0.2.13
+      tinyglobby: 0.2.14
     optionalDependencies:
       '@types/node': 24.2.1
       fsevents: 2.3.3
@@ -22201,6 +22374,45 @@ snapshots:
       - tsx
       - yaml
 
+  vitest@4.0.18(@opentelemetry/api@1.9.0)(@types/node@20.17.57)(jiti@2.4.2)(jsdom@26.1.0)(lightningcss@1.30.1)(tsx@4.19.4)(yaml@2.8.0):
+    dependencies:
+      '@vitest/expect': 4.0.18
+      '@vitest/mocker': 4.0.18(vite@6.3.6(@types/node@20.17.57)(jiti@2.4.2)(lightningcss@1.30.1)(tsx@4.19.4)(yaml@2.8.0))
+      '@vitest/pretty-format': 4.0.18
+      '@vitest/runner': 4.0.18
+      '@vitest/snapshot': 4.0.18
+      '@vitest/spy': 4.0.18
+      '@vitest/utils': 4.0.18
+      es-module-lexer: 1.7.0
+      expect-type: 1.3.0
+      magic-string: 0.30.21
+      obug: 2.1.1
+      pathe: 2.0.3
+      picomatch: 4.0.3
+      std-env: 3.10.0
+      tinybench: 2.9.0
+      tinyexec: 1.0.2
+      tinyglobby: 0.2.15
+      tinyrainbow: 3.0.3
+      vite: 6.3.6(@types/node@20.17.57)(jiti@2.4.2)(lightningcss@1.30.1)(tsx@4.19.4)(yaml@2.8.0)
+      why-is-node-running: 2.3.0
+    optionalDependencies:
+      '@opentelemetry/api': 1.9.0
+      '@types/node': 20.17.57
+      jsdom: 26.1.0
+    transitivePeerDependencies:
+      - jiti
+      - less
+      - lightningcss
+      - msw
+      - sass
+      - sass-embedded
+      - stylus
+      - sugarss
+      - terser
+      - tsx
+      - yaml
+
   void-elements@3.1.0: {}
 
   vscode-jsonrpc@8.2.0: {}
diff --git a/webview-ui/src/components/history/__tests__/HistoryPreview.spec.tsx b/webview-ui/src/components/history/__tests__/HistoryPreview.spec.tsx
index da344970a88..42543dfd7ae 100644
--- a/webview-ui/src/components/history/__tests__/HistoryPreview.spec.tsx
+++ b/webview-ui/src/components/history/__tests__/HistoryPreview.spec.tsx
@@ -3,24 +3,28 @@ import { render, screen } from "@/utils/test-utils"
 import type { HistoryItem } from "@roo-code/types"
 
 import HistoryPreview from "../HistoryPreview"
+import type { TaskGroup } from "../types"
 
 vi.mock("../useTaskSearch")
+vi.mock("../useGroupedTasks")
 
-vi.mock("../TaskItem", () => {
+vi.mock("../TaskGroupItem", () => {
 	return {
-		default: vi.fn(({ item, variant }) => (
-			<div data-testid={`task-item-${item.id}`} data-variant={variant}>
-				{item.task}
+		default: vi.fn(({ group, variant }) => (
+			<div data-testid={`task-group-${group.parent.id}`} data-variant={variant}>
+				{group.parent.task}
 			</div>
 		)),
 	}
 })
 
 import { useTaskSearch } from "../useTaskSearch"
-import TaskItem from "../TaskItem"
+import { useGroupedTasks } from "../useGroupedTasks"
+import TaskGroupItem from "../TaskGroupItem"
 
 const mockUseTaskSearch = useTaskSearch as any
-const mockTaskItem = TaskItem as any
+const mockUseGroupedTasks = useGroupedTasks as any
+const mockTaskGroupItem = TaskGroupItem as any
 
 const mockTasks: HistoryItem[] = [
 	{
@@ -79,6 +83,15 @@ const mockTasks: HistoryItem[] = [
 	},
 ]
 
+// Helper to create mock groups from tasks
+function createMockGroups(tasks: HistoryItem[]): TaskGroup[] {
+	return tasks.map((task) => ({
+		parent: { ...task, isSubtask: false },
+		subtasks: [],
+		isExpanded: false,
+	}))
+}
+
 describe("HistoryPreview", () => {
 	beforeEach(() => {
 		vi.clearAllMocks()
@@ -97,14 +110,21 @@ describe("HistoryPreview", () => {
 			setShowAllWorkspaces: vi.fn(),
 		})
 
+		mockUseGroupedTasks.mockReturnValue({
+			groups: [],
+			flatTasks: null,
+			toggleExpand: vi.fn(),
+			isSearchMode: false,
+		})
+
 		const { container } = render(<HistoryPreview />)
 
-		// Should render the container but no task items
+		// Should render the container but no task groups
 		expect(container.firstChild).toHaveClass("flex", "flex-col", "gap-1")
-		expect(screen.queryByTestId(/task-item-/)).not.toBeInTheDocument()
+		expect(screen.queryByTestId(/task-group-/)).not.toBeInTheDocument()
 	})
 
-	it("renders up to 4 tasks when tasks are available", () => {
+	it("renders up to 4 groups when tasks are available", () => {
 		mockUseTaskSearch.mockReturnValue({
 			tasks: mockTasks,
 			searchQuery: "",
@@ -117,18 +137,26 @@ describe("HistoryPreview", () => {
 			setShowAllWorkspaces: vi.fn(),
 		})
 
+		const mockGroups = createMockGroups(mockTasks)
+		mockUseGroupedTasks.mockReturnValue({
+			groups: mockGroups,
+			flatTasks: null,
+			toggleExpand: vi.fn(),
+			isSearchMode: false,
+		})
+
 		render(<HistoryPreview />)
 
-		// Should render only the first 3 tasks
-		expect(screen.getByTestId("task-item-task-1")).toBeInTheDocument()
-		expect(screen.getByTestId("task-item-task-2")).toBeInTheDocument()
-		expect(screen.getByTestId("task-item-task-3")).toBeInTheDocument()
-		expect(screen.getByTestId("task-item-task-4")).toBeInTheDocument()
-		expect(screen.queryByTestId("task-item-task-5")).not.toBeInTheDocument()
-		expect(screen.queryByTestId("task-item-task-6")).not.toBeInTheDocument()
+		// Should render only the first 4 groups
+		expect(screen.getByTestId("task-group-task-1")).toBeInTheDocument()
+		expect(screen.getByTestId("task-group-task-2")).toBeInTheDocument()
+		expect(screen.getByTestId("task-group-task-3")).toBeInTheDocument()
+		expect(screen.getByTestId("task-group-task-4")).toBeInTheDocument()
+		expect(screen.queryByTestId("task-group-task-5")).not.toBeInTheDocument()
+		expect(screen.queryByTestId("task-group-task-6")).not.toBeInTheDocument()
 	})
 
-	it("renders all tasks when there are 3 or fewer", () => {
+	it("renders all groups when there are 4 or fewer", () => {
 		const threeTasks = mockTasks.slice(0, 3)
 		mockUseTaskSearch.mockReturnValue({
 			tasks: threeTasks,
@@ -142,17 +170,25 @@ describe("HistoryPreview", () => {
 			setShowAllWorkspaces: vi.fn(),
 		})
 
+		const mockGroups = createMockGroups(threeTasks)
+		mockUseGroupedTasks.mockReturnValue({
+			groups: mockGroups,
+			flatTasks: null,
+			toggleExpand: vi.fn(),
+			isSearchMode: false,
+		})
+
 		render(<HistoryPreview />)
 
-		expect(screen.getByTestId("task-item-task-1")).toBeInTheDocument()
-		expect(screen.getByTestId("task-item-task-2")).toBeInTheDocument()
-		expect(screen.getByTestId("task-item-task-3")).toBeInTheDocument()
-		expect(screen.queryByTestId("task-item-task-4")).not.toBeInTheDocument()
-		expect(screen.queryByTestId("task-item-task-5")).not.toBeInTheDocument()
-		expect(screen.queryByTestId("task-item-task-6")).not.toBeInTheDocument()
+		expect(screen.getByTestId("task-group-task-1")).toBeInTheDocument()
+		expect(screen.getByTestId("task-group-task-2")).toBeInTheDocument()
+		expect(screen.getByTestId("task-group-task-3")).toBeInTheDocument()
+		expect(screen.queryByTestId("task-group-task-4")).not.toBeInTheDocument()
+		expect(screen.queryByTestId("task-group-task-5")).not.toBeInTheDocument()
+		expect(screen.queryByTestId("task-group-task-6")).not.toBeInTheDocument()
 	})
 
-	it("renders only 1 task when there is only 1 task", () => {
+	it("renders only 1 group when there is only 1 task", () => {
 		const oneTask = mockTasks.slice(0, 1)
 		mockUseTaskSearch.mockReturnValue({
 			tasks: oneTask,
@@ -166,15 +202,24 @@ describe("HistoryPreview", () => {
 			setShowAllWorkspaces: vi.fn(),
 		})
 
+		const mockGroups = createMockGroups(oneTask)
+		mockUseGroupedTasks.mockReturnValue({
+			groups: mockGroups,
+			flatTasks: null,
+			toggleExpand: vi.fn(),
+			isSearchMode: false,
+		})
+
 		render(<HistoryPreview />)
 
-		expect(screen.getByTestId("task-item-task-1")).toBeInTheDocument()
-		expect(screen.queryByTestId("task-item-task-2")).not.toBeInTheDocument()
+		expect(screen.getByTestId("task-group-task-1")).toBeInTheDocument()
+		expect(screen.queryByTestId("task-group-task-2")).not.toBeInTheDocument()
 	})
 
-	it("passes correct props to TaskItem components", () => {
+	it("passes correct props to TaskGroupItem components", () => {
+		const threeTasks = mockTasks.slice(0, 3)
 		mockUseTaskSearch.mockReturnValue({
-			tasks: mockTasks.slice(0, 3),
+			tasks: threeTasks,
 			searchQuery: "",
 			setSearchQuery: vi.fn(),
 			sortOption: "newest",
@@ -185,35 +230,43 @@ describe("HistoryPreview", () => {
 			setShowAllWorkspaces: vi.fn(),
 		})
 
+		const mockGroups = createMockGroups(threeTasks)
+		mockUseGroupedTasks.mockReturnValue({
+			groups: mockGroups,
+			flatTasks: null,
+			toggleExpand: vi.fn(),
+			isSearchMode: false,
+		})
+
 		render(<HistoryPreview />)
 
-		// Verify TaskItem was called with correct props for first 3 tasks
-		expect(mockTaskItem).toHaveBeenCalledWith(
+		// Verify TaskGroupItem was called with correct props for first 3 groups
+		expect(mockTaskGroupItem).toHaveBeenCalledWith(
 			expect.objectContaining({
-				item: mockTasks[0],
+				group: mockGroups[0],
 				variant: "compact",
 			}),
 			expect.anything(),
 		)
-		expect(mockTaskItem).toHaveBeenCalledWith(
+		expect(mockTaskGroupItem).toHaveBeenCalledWith(
 			expect.objectContaining({
-				item: mockTasks[1],
+				group: mockGroups[1],
 				variant: "compact",
 			}),
 			expect.anything(),
 		)
-		expect(mockTaskItem).toHaveBeenCalledWith(
+		expect(mockTaskGroupItem).toHaveBeenCalledWith(
 			expect.objectContaining({
-				item: mockTasks[2],
+				group: mockGroups[2],
 				variant: "compact",
 			}),
 			expect.anything(),
 		)
 	})
 
-	it("renders with correct container classes", () => {
+	it("displays the header and view all button", () => {
 		mockUseTaskSearch.mockReturnValue({
-			tasks: mockTasks.slice(0, 1),
+			tasks: mockTasks,
 			searchQuery: "",
 			setSearchQuery: vi.fn(),
 			sortOption: "newest",
@@ -224,8 +277,59 @@ describe("HistoryPreview", () => {
 			setShowAllWorkspaces: vi.fn(),
 		})
 
-		const { container } = render(<HistoryPreview />)
+		const mockGroups = createMockGroups(mockTasks)
+		mockUseGroupedTasks.mockReturnValue({
+			groups: mockGroups,
+			flatTasks: null,
+			toggleExpand: vi.fn(),
+			isSearchMode: false,
+		})
 
-		expect(container.firstChild).toHaveClass("flex", "flex-col", "gap-1")
+		render(<HistoryPreview />)
+
+		// Should show header and view all button
+		expect(screen.getByText("history:recentTasks")).toBeInTheDocument()
+		expect(screen.getByText("history:viewAllHistory")).toBeInTheDocument()
+	})
+
+	it("calls toggleExpand when onToggleExpand is called", () => {
+		const oneTask = mockTasks.slice(0, 1)
+		mockUseTaskSearch.mockReturnValue({
+			tasks: oneTask,
+			searchQuery: "",
+			setSearchQuery: vi.fn(),
+			sortOption: "newest",
+			setSortOption: vi.fn(),
+			lastNonRelevantSort: null,
+			setLastNonRelevantSort: vi.fn(),
+			showAllWorkspaces: false,
+			setShowAllWorkspaces: vi.fn(),
+		})
+
+		const mockToggleExpand = vi.fn()
+		const mockGroups = createMockGroups(oneTask)
+		mockUseGroupedTasks.mockReturnValue({
+			groups: mockGroups,
+			flatTasks: null,
+			toggleExpand: mockToggleExpand,
+			isSearchMode: false,
+		})
+
+		render(<HistoryPreview />)
+
+		// Verify TaskGroupItem received onToggleExpand prop
+		expect(mockTaskGroupItem).toHaveBeenCalledWith(
+			expect.objectContaining({
+				onToggleExpand: expect.any(Function),
+			}),
+			expect.anything(),
+		)
+
+		// Call the onToggleExpand function passed to TaskGroupItem
+		const callArgs = mockTaskGroupItem.mock.calls[0][0]
+		callArgs.onToggleExpand()
+
+		// Verify toggleExpand was called with the parent id
+		expect(mockToggleExpand).toHaveBeenCalledWith("task-1")
 	})
 })