iCreatAI News
Back to main site
Skip to content
Only First party#Tutorials
  1. Claude Blog62

    Building always-on agents

    This post explains that always-on agents are stateful and proactive, running on the same core loop as other agents but surrounded by architecture built from five primitives: an event inbox, timers, memory, permissions, and an outbox. It describes how each primitive works, including inbox best practices, follow-up versus scheduled timers, memory types such as user instructions and task progress, credential proxying and deferred tool calls, and outbox delivery pacing. It concludes with how the primitives form a repeating cycle in which each brief run is triggered by an event and can set timers that wake the agent again later.

    Why it matters: Offers a concrete architectural blueprint for teams building proactive, stateful agents, with practical guidance on event handling, memory, permissions, and message pacing.

  1. OpenRouter Announcements60

    Reranking in RAG: How to Fix Bad Retrieval with a Reranker

    This guide explains that vector search often ranks near-miss chunks first because embeddings compress whole chunks into single vectors, and shows how adding a cross-encoder reranker over the top 30 candidates raised precision@1 from 81% to 97% on a 274-question synthetic benchmark at roughly $0.10 per 1,000 queries. It compares 11 rerankers (voyageai/rerank-3-lite and rerank-3 were the most accurate dedicated models and cheapest, while LLM rerankers like openai/gpt-6-luna hit 99.6% but took about 4 seconds per call), covers candidate-count tuning, input_type settings, and silent failures such as cohere/rerank-v3.5's 4,096-token limit. It includes a Python example using the embeddings and rerank APIs and notes that real-world gains depend on your own documents and evaluation set.

    Why it matters: Offers a measured, benchmark-backed walkthrough of adding reranking to a RAG pipeline, including cost, latency and failure-mode comparisons useful for teams tuning retrieval.

  2. vLLM Blog72

    DeepSeek-V4.1-Flash on Vera Rubin NVL72: 58x Throughput vs. GB300 NVL72 at 387 tokens/s

    On a single NVIDIA Vera Rubin NVL72 rack, vLLM serves DeepSeek-V4.1-Flash at 1.7M tokens/s per GPU with 387 tokens/s per user, 58x GB300 NVL72, reaching 2.52M at peak throughput and 1,810 tokens/s for a single user. The gains come from kernels tuned for Rubin's split memory domains and FP4 tensor cores, specialized low-latency decode kernels, and a rack-wide KV cache and Engram tables shared over NVLink. The post details four optimization groups and reports a 96.5–97% prefix hit rate at high concurrency with workload-aware routing.

    Why it matters: It offers a detailed, measurement-backed look at how Rubin-specific memory and MMA features translate into serving throughput and latency for a frontier open model.

  1. OpenRouter Announcements67

    MCP vs CLI vs Skills: What Each Costs in Context

    The article measures input-token costs for giving an agent GitHub access via the GitHub MCP server, the gh CLI, or a gh skill across Claude Haiku 5.5, Claude Sonnet 5.5, GPT-6 Luna, and Gemini 3.8 Flash; on Sonnet 5.5 the CLI used 1,421 tokens, the skill 3,315, and the MCP server 59,417 with its 46 default tools. It reports that the GitHub MCP server's 46 default tools add 19,436 tokens to every request on Sonnet 5.5, and that a single tool result (GitHub's release object) cost about 20,400 tokens. It also describes the beta Tool Search server tool, which cut the up-front cost of 46 tools to under 600 tokens and halved whole-task cost on Sonnet 5.5 while raising it on Haiku 5.5.

    Why it matters: It offers concrete, model-specific token and cost measurements for choosing between MCP, CLI, and skills, plus practical mitigations like scoping tools and trimming results.

  2. Pydantic AI Articles60

    Code mode is not a sandbox

    This post distinguishes code mode, where the model writes a short Python program calling your tools as functions via a single run_code tool, from a sandbox, which is an isolated environment where code runs. It describes three places a sandbox boundary can go (the whole agent, only the tools, or only the model-written code) and how Pydantic AI workspaces let you move that boundary without rewriting tools. It also covers Monty, a Rust-written Python interpreter that runs run_code next to the agent with no filesystem, network, or environment variables.

    Why it matters: Useful for teams deciding where to place isolation boundaries when combining code mode with sandboxed tool execution.

  3. OpenRouter Announcements60

    How to Get Structured Output from Any LLM: JSON Schema, Tool Calls, or a Decision Model

    The article compares three routes to reliable structured LLM output: a strict JSON Schema in response_format, a forced tool call whose parameters are the schema, and a decision model for label-only fields. In tests on 24 support messages across nine schema-supporting models plus GLM 5.3 FlashX, strict schemas returned 209 of 216 valid replies (all 7 misses from one provider that ignores the schema), while prompt-only JSON failed 18 times due to code fences. It recommends require_parameters: true, Response Healing for broken JSON, and always validating replies yourself.

    Why it matters: A practical, test-backed guide to choosing between schema, tool-call, and decision-model approaches for structured LLM output.

  4. OpenRouter Announcements64

    Best OCR Model for Scanned Documents, Measured

    The author tested 15 vision models plus Mistral OCR and Tesseract on eight synthetic scanned pages scored by character error rate and 264 key-value checks, finding Claude Opus 5.5 most accurate (262 of 264 at $16.42 per 1,000 pages) and Mistral OCR the best value (258 of 264 at $2.02). The post documents failure modes such as fabricated card digits, wifi passwords and server names on a faded receipt, and provides code for transcription, disabling reasoning, cross-checking two models from different labs, and using the mistral-ocr engine.

    Why it matters: It offers a reproducible benchmark with per-model costs and practical code for catching hallucinated values in OCR pipelines.

  5. Meta Engineering62

    How We Built TLX: A Hardware-Native GPU Compiler for Production ML at Scale

    Meta introduces Triton Low-Level Extensions (TLX), an extension to Triton that adds explicit warp-group and cluster-level orchestration so engineers can use modern GPU features like TMA, TMEM, and warp specialization while keeping Triton's programming model. TLX is in production across Meta workloads, with reported gains including 20-25% end-to-end MFU for GEM model training on thousands of NVIDIA Blackwell GPUs, up to two-thirds net-latency reduction in RecSys inference, and a distributed grouped GEMM kernel running in large-scale LLM pretraining. The post frames TLX as implementing a "MIMW" abstraction between CUDA's SIMT model and Triton's block-level model, and covers five extension areas: warp-group orchestration, synchronization, memory orchestration, cluster execution, and optional layouts.

    Why it matters: A detailed first-party account of a production GPU compiler, useful for engineers weighing Triton, CUTLASS, and CUDA for hardware-specific kernel work.

  1. Google Developers Blog60

    Agent Distraction

    The post reports that 13% of agent file-reading sessions expose the agent to inline TODO(bug/...) or FIXME(bug/...) references, and in 6% of encounters the agent takes follow-up action on that bug ID, 83% of which are unprompted by the developer. Cross-referencing these detours against live bug status, it finds 41% chase already-closed or obsolete tickets while 57% involve still-open bugs where the agent expanded scope, and a fixed-effects regression shows unprompted bug detours add 70% more steps, 77% more tokens and 105% more wait time per session. The authors built agents that scan codebases and remove confirmed-obsolete bug references, reporting thousands removed over six months with over 95% acceptance from human reviewers.

    Why it matters: Offers a quantified, data-backed look at how stale code comments misdirect coding agents, plus a concrete remediation approach.

  1. Trail of Bits Blog64

    Backporting security fixes at scale with Codex

    Trail of Bits describes using Codex with GPT-5.6 to backport security fixes into stable Linux kernel branches and distribution packages, reporting that by October 29 the project had delivered fixes for 149 distinct CVEs into stable kernel releases plus several Fedora and Ubuntu package fixes. The workflow has agents identify missing fixes, adapt patches, assemble validation evidence, run tests and prepare submission packets while engineers review and submit them, cutting preparation and review of a straightforward backport to about 30 minutes and a more involved case to around three hours. The post also presents counts of unfixed CVEs in stable kernel branches and in Debian 13 and Ubuntu 26.04, noting that regression testing and maintainer acceptance remain essential.

    Why it matters: It offers a concrete account of AI-assisted security backporting, including a described workflow, effort estimates and CVE backlog figures for stable Linux software.

  1. OpenRouter Announcements60

    Build an AI Code Reviewer with OpenRouter

    This guide presents a 233-line Python script (review.py) that uses the OpenRouter Responses API with the Files API, Shell server tool, and Apply Patch server tool to run changed files in a hosted Linux sandbox, confirm bugs by executing checks, and return fixes as V4A patches. It covers setup, a five-bug sample repository, a Git pre-push hook, and a GitHub Actions workflow, with benchmark results across four models (e.g., Claude Sonnet 5.5 fixing all five bugs at $0.0447 and 60 seconds). The script writes a report to .git/ai-review.json and exits 1 when a finding meets the --block-at severity threshold.

    Why it matters: It offers a concrete, reproducible implementation with cost and latency benchmarks, plus practical notes on API pitfalls, useful for developers building automated code review.

  1. OpenRouter Announcements62

    How to Build Your Own Always-On AI Agent

    This tutorial builds an always-on agent in TypeScript with the OpenRouter Agent SDK (@openrouter/agent 0.11.0) that checks Hacker News on a schedule, writes a digest of new relevant stories, remembers seen story IDs across restarts, and caps each run at six steps or five cents. Each check cost $0.0003 to $0.0012 with Claude Haiku 5.5 in the author's runs on October 13, 2026, roughly $0.86 to $3.46 a month at one check every 15 minutes. It also covers pausing a run for human approval before a tool posts to a team channel, resuming after a crash, and deploying on a VPS or scheduled job.

    Why it matters: It offers a concrete, cost-measured walkthrough of the practical pieces—scheduling, memory, spend limits, and approval—that separate a demo agent from one that runs unattended.

  1. OpenRouter Announcements60

    How Much Does Claude Code Cost? Real Session Costs by Model

    Claude Code is free to install, but users pay for the model it calls, either through a Claude subscription or per token on an API key. Median API-key session costs from OpenRouter data over the 30 days to October 18, 2026 were $0.31 for a 2–9-turn session and $1.39 for a 10–49-turn session on Claude Opus 5.5, versus $0.16 and $0.60 on Claude Sonnet 5.5. Most of the cost comes from Claude Code's own context written to the prompt cache on the first request and read back on later turns, so the article recommends Sonnet as default, Haiku for background jobs and sub-agents, shorter sessions, and a credit limit on the key.

    Why it matters: It gives concrete per-session cost medians by model and length, plus practical levers for controlling Claude Code spend.

  1. OpenRouter Announcements65

    How to Prevent Prompt Injection: 13 Attacks, Tested

    The article describes testing 13 self-written and 12 model-written prompt injection attacks against four current models in a document-summarizing assistant with an email tool, finding that text-only attacks rarely worked but that one model (GLM 5.3 Flash) sent 58 of 60 attack emails without defenses. It recommends labeling untrusted content as data (cutting attack emails from 60 to 13 of 720), using a guardrail with a model allowlist and budget limit, checking every tool call with Armor (which blocked all 73 attempted attack emails at about 0.3 seconds added latency), and keeping secrets out of the prompt. Armor blocked real work in one case: a user approving a document's request without naming the address.

    Why it matters: It offers a concrete, measured comparison of layered prompt-injection defenses, including where a tool-call guardrail blocks legitimate user requests.

  2. OpenRouter Announcements62

    How to Extract Tables from a PDF with an LLM

    The guide shows how to send a PDF to a file-reading model together with a strict JSON schema describing one row, so the model returns typed rows with cleanup such as parenthesized negatives and footnote markers handled by field descriptions. In tests over five PDFs (two scans, 644 cells), every model that read the PDF directly got all cells right, while failures came from the parser route and output token limits, including two silent failures. It recommends rejecting empty results and any response whose finish_reason is "length", and comparing routes on your own PDFs before choosing one.

    Why it matters: Offers a concrete, tested recipe with code for schema-driven PDF table extraction, plus specific guidance on silent failure modes worth knowing before building a pipeline.

  3. Pydantic AI Articles74

    Code mode: make your agents 2x faster and 2x cheaper on long tasks

    A benchmark of 5,276 graded runs across eight models on five small Pydantic AI apps found that code mode, where the model writes a program that calls tools inside a sandbox, cut cost by 58% and wall time by 51% on long tasks while raising success by 16 points. Gains grew with task length: at 200 items code mode was 47% to 75% cheaper and 42% to 67% faster, whereas at 5 items it cost 21% to 38% more on three of five tasks. The author attributes the win not to fewer round trips, since models already batch calls, but to less content per request, and runs the model's code in Monty, a Rust Python interpreter with no host access by default and 30-second, 256 MiB limits.

    Why it matters: Offers a detailed, methodology-heavy benchmark with per-model cost, latency and correctness numbers, plus an honest list of where code mode costs more.

You have reached the end