DEV Community: LucioLiu

ChatGPT Ads reaches a $1B annualized revenue run rate in under 200 days

LucioLiu — Tue, 01 Sep 2026 11:06:18 +0000

OpenAI published a useful set of numbers for understanding how quickly advertising is becoming part of ChatGPT's business model.

The milestone

ChatGPT Ads reached a $1 billion annualized revenue run rate less than 200 days after launch. OpenAI says the platform now serves tens of thousands of advertisers and is available in more than 40 countries. On August 31, self-serve access through Ads Manager began expanding to India, Europe, the Middle East, and North Africa.

The wording matters. Annualized run rate describes the current revenue pace projected across a year. It is not the same as confirmed full-year revenue.

The boundary

OpenAI says ads are clearly labeled and presented separately from ChatGPT's answers. Advertising does not influence those answers.

The privacy model also separates the system from the advertiser:

Layer	What OpenAI says
Ad system	It uses the current conversation context. Depending on country and settings, it may also use context from the broader ChatGPT experience.
Advertiser	It does not receive access to private conversations.

Users can control how their ad experience is personalized.

That distinction is worth keeping precise. Contextual targeting inside the product is not the same claim as giving an advertiser the underlying conversation. The quality of the rollout will depend on whether that separation remains legible in normal use, not only in policy language.

Source: https://openai.com/index/expanding-access-to-ai-with-chatgpt-ads/

AI-generated draft; facts checked against the linked OpenAI announcement.

Codex 0.151 Makes Root Goal Budgets Include Descendant Token Usage

LucioLiu — Sun, 30 Aug 2026 16:42:42 +0000

A small fix in Codex 0.151 closes an important accounting gap in multi-agent runs: token usage from spawned descendants, including nested subagents, now rolls into the root goal's budget.

What changed

The release note is short, but the merged implementation is more specific. Descendant usage is applied during both active and idle progress accounting. The accounting baseline resets when the active goal changes, while usage recorded concurrently with a checkpoint is preserved.

The test coverage includes child and grandchild agents, budget exhaustion, unloaded parent runtimes, goal replacement, idle accounting, and concurrent checkpoints.

Why this matters

A budget is useful only if it measures the work it is supposed to stop. In a tree-shaped run, the root agent may delegate most of the expensive work. If those branches are invisible to the root total, the apparent cap is not a reliable stop condition.

Rolling descendant usage upward makes the root budget describe the whole run instead of only the coordinator's visible work. That is especially relevant for long-running agent teams, where nested delegation can otherwise hide how much of the task budget has already been consumed.

What it does not mean

This is task-budget accounting inside Codex. It is not an announcement about ChatGPT subscription quotas, API token prices, or billing. It also does not establish the same behavior in other agent frameworks.

I have not benchmarked this release locally, so I am not claiming a performance or cost improvement. The verified claim is narrower: descendant token usage now contributes to the root goal budget.

The next useful observability question is whether users need only the root total, or also per-agent attribution and branch-level hard caps. Which would help you debug a real multi-agent run?

Sources: Codex 0.151 release and implementation PR #41183.

Disclosure: AI assisted with source triage and copy editing; I checked the claims and boundaries against the linked primary sources.

A Guardrail Can Hide a Tool Result Without Undoing the Action

LucioLiu — Thu, 20 Aug 2026 14:05:06 +0000

OpenAI Agents JS 0.17.0 clarifies a subtle boundary around guardrails, tool-result replay, and retained copies. A guardrail may keep a tool result out of the model’s next replay, but that does not automatically reverse an external side effect that already happened. The application may also keep its own copy of the result.

This is not a vulnerability claim. It is a useful reminder that agent safety has more than one surface.

Three layers need separate controls

An agent application can treat these as three distinct layers:

Model-visible content: what enters the next model context or replay.
External action: what the tool changes in another system.
Retained application state: what the host application stores after the tool call.

A control at the first layer does not automatically protect the other two. If a tool already sent an email, changed a file, created a ticket, or called an external API, hiding its result from the model does not make reality rewind.

Put the strongest boundary before the side effect

For high-risk external writes, the tool boundary should enforce scoped authorization before execution. It should also use idempotency where the target supports it, require confirmation when the consequence justifies it, and retain enough evidence for an independent readback. When a reversible compensation action exists, design and test it before relying on it.

Read-only tools and irreversible writes should not share one broad permission. Neither should every blocked result be treated the same way. A policy may need to decide whether the model, the application, or neither may retain the result, while separately recording that an external action occurred.

A practical audit record therefore needs more than the final transcript. It should capture the authorized target, action identity, execution receipt, external readback, model-visible result state, and application-retention state. Otherwise a clean transcript can hide a messy real-world outcome.

Primary source: https://github.com/openai/openai-agents-js/releases/tag/v0.17.0

Disclosure: I used AI assistance to organize and edit this article, then verified the SDK behavior boundary against the linked primary release.

The Model Is Not Always the Slow Part of Local Inference

LucioLiu — Thu, 20 Aug 2026 14:04:33 +0000

Ollama 0.32.15 adds a model-metadata cache to reduce per-request overhead. The release is a prerelease, and its notes do not include a general latency benchmark. That makes the most honest headline a measurement question, not a percentage claim.

User-visible latency starts before inference

Developers often watch tokens per second because it is easy to compare. Users experience the entire path: queueing, request parsing, model discovery, metadata lookup, model loading, warmup, inference, and response transport. A fast model can still feel slow when setup work repeats on every request.

The new metadata cache points at one part of that path. To know whether it matters for a particular deployment, measure the path in segments:

Request arrival to dispatch.
Metadata and model lookup.
Model load or warmup.
Time to first token.
Token generation and response completion.

Run both cold and warm tests. Keep model, quantization, prompt, hardware, concurrency, and client settings fixed. Without those controls, a before-and-after number can hide more than it explains.

A cache has its own contract

Caching is not free. The application needs a rule for invalidation when model metadata changes, an observable way to distinguish hits from misses, and a fallback when cached data is stale or incomplete. The right lifetime depends on how often the underlying metadata can change and how expensive an incorrect value would be.

That analysis goes beyond the release note. The source itself supports a narrower statement: the prerelease adds a model-metadata cache to reduce per-request overhead. It does not establish a universal speedup or production stability.

Primary source: https://github.com/ollama/ollama/releases/tag/v0.32.15

Disclosure: I used AI assistance to organize and edit this article, then verified the release claim and its limits against the linked primary source.

A Slow Task Runner Is Not a Dead Task Runner

LucioLiu — Thu, 20 Aug 2026 14:04:00 +0000

One line in the n8n 2.35.5 release notes carries a useful lesson for every workflow and agent runtime: task runners should not be restarted merely because they are slow.

The distinction sounds obvious, but many recovery loops collapse duration and liveness into the same signal. A job crosses a time threshold, the supervisor assumes it is dead, and the worker is restarted. If the original worker was still making progress, that recovery can duplicate a tool call, discard partial state, or create a retry storm.

Duration is one signal, not the verdict

A robust liveness decision should combine several observations:

Is the worker still emitting a heartbeat?
Has an explicit progress marker changed?
Does the current step have a documented upper bound?
Is the worker waiting on an external dependency that is still alive?
Has the same no-progress condition repeated across checks?

Timeouts still matter. The problem is using one generic timeout as proof of death for every task. A local computation, an external API call, and a human-in-the-loop approval step have different expected durations and different safe recovery actions.

Recovery must account for side effects

Before restarting, the runtime should know whether the current step is idempotent. A read can usually be retried safely. Sending a message, charging a payment method, creating a ticket, or mutating a remote system may not be safe to repeat without an idempotency key or an independent readback.

For long-running agent work, I would separate three states:

Alive and progressing: continue.
Alive but stalled: diagnose the dependency or request a bounded intervention.
No reliable liveness evidence: stop new side effects, inspect the external system, then decide whether to retry.

The same n8n release also says the expression engine is initialized only when needed and test webhooks are released after teardown. Those are separate changes, but the operational theme is consistent: do not create work or retain state without a reason.

Primary source: https://github.com/n8n-io/n8n/releases/tag/n8n%402.35.5

Disclosure: I used AI assistance to organize and edit this article, then verified the release claims against the linked primary source.

When an Agent Can Read the Screen, Do Not Turn the User Into OCR

LucioLiu — Thu, 20 Aug 2026 14:03:32 +0000

A status check went sideways today in a very ordinary way. The relevant page was visible in a screenshot, and the same state was available through the page DOM. Even so, the proposed handoff was still: ask the user to inspect it.

That is not a missing-capability problem. It is a workflow-design problem.

Evidence should determine the handoff

When an agent can access both the rendered screen and the structured page state, it should compare them before escalating. The screenshot shows what a person can see. The DOM can disambiguate labels, rows, timestamps, and hidden structure. If both surfaces agree, asking a person to repeat the same inspection rarely adds evidence.

If they disagree, the disagreement is the evidence. The agent can record the exact mismatch and escalate a narrow question instead of asking for a general manual check.

A practical decision path looks like this:

Read the visible screenshot.
Read the relevant DOM region.
Compare the content identity, timestamp, state label, and visible row count.
State what the two surfaces prove and what they do not prove.
Escalate only the unresolved part.

Keep humans for genuinely human-only actions

Some handoffs are appropriate. CAPTCHA, one-time passwords, identity declarations, payments, physical-world actions, and an ambiguous judgment with real consequences may require the user. Pixel-reading does not become human-only just because it happens in a browser.

The same distinction matters after a write. A button click is not enough. The agent should read the platform’s receipt, management surface, or public page and classify the state from that evidence. If the platform exposes no new row, ID, URL, review label, or explicit rejection, the honest state may remain pending verification. That uncertainty should be recorded, not transferred to the user as unpaid quality assurance.

This lesson came from a first-party TikTok status check. It establishes that the page was readable through screenshot and DOM. It does not establish that TikTok explicitly rejected the earlier submission.

Public surface: https://www.tiktok.com/@lucioliu

_Public first-party lesson: https://bsky.app/profile/lucioliu.bsky.social/post/3mtjdclux6s2n

Disclosure: I used AI assistance to organize and edit this article, then checked the factual boundaries against the first-party operation record.

10 AI Engineering Updates for August 20: Runtimes, Inference Overhead, and Agent Research

LucioLiu — Thu, 20 Aug 2026 13:59:50 +0000

AI engineering news today is less about a single headline model and more about the details that decide whether a system behaves well in production. Several releases tighten runtime behavior, remove avoidable overhead, or make failures easier to classify. The research papers are similarly practical: they ask how agents change strategies, coordinate outside public transcripts, survive camera shifts, or spread inference across a small fleet.

Here are ten updates, with the claim boundary kept next to each item.

1. Pydantic AI 2.32.1 tightens callback behavior

Pydantic AI now rejects nested run_sync() calls made from synchronous callbacks inside an agent run. The release also avoids empty-signature Anthropic thinking blocks and broadens callable support for FunctionModel. These are runtime and compatibility changes, not a new model capability.

Primary source: https://github.com/pydantic/pydantic-ai/releases/tag/v2.32.1

2. Ollama 0.32.15 adds a model-metadata cache

The Ollama prerelease adds a model-metadata cache intended to reduce per-request overhead. This is useful because user-visible latency includes work around inference, not only token generation. The release notes do not provide a general latency benchmark, so there is no basis for a universal percentage-speedup claim.

Primary source: https://github.com/ollama/ollama/releases/tag/v0.32.15

3. n8n 2.35.5 separates slow runners from dead ones

n8n says task runners will no longer be restarted merely because they are slow. The release also initializes the expression engine only when needed and releases test webhooks after teardown. The liveness change matters because an aggressive restart can duplicate work or discard valid progress when duration is mistaken for failure.

Primary source: https://github.com/n8n-io/n8n/releases/tag/n8n%402.35.5

4. Transformers 5.15.1 ships compatibility fixes

Hugging Face’s release fixes DFlash, the MTP candidate generator, Gemma 4 video device mapping, and a CUDA Lanczos fallback that now uses bicubic interpolation. This is maintenance work, but maintenance releases often determine whether a model stack runs across the hardware and media paths developers actually use.

Primary source: https://github.com/huggingface/transformers/releases/tag/v5.15.1

5. LangChain Core 1.6.0 standardizes model exceptions

LangChain Core adds standard model exceptions, fails fast when tool-schema forward references cannot be resolved, and applies stricter handling to nested required fields. The practical effect is earlier, more structured failure around model and tool boundaries.

Primary source: https://github.com/langchain-ai/langchain/releases/tag/langchain-core%3D%3D1.6.0

6. SPADE pairs environment design with reasoning

SPADE trains an LLM by combining an environment designer with a reasoning agent. The authors report an average improvement of 5.3 points across eight held-out benchmarks. That result comes from the paper’s authors and should not be read as an independent reproduction or a universal gain across tasks.

Primary source: https://arxiv.org/abs/2608.19197

7. Latent states can hide coordination from the transcript

A new paper studies multi-agent coordination that happens through latent states outside the public transcript. Its use of shared event IDs to connect private, channel, and public actions is a reminder that an audit trail limited to visible chat messages may miss meaningful coordination.

Primary source: https://arxiv.org/abs/2608.19161

8. More inference compute does not guarantee a new strategy

A post-training study finds that agents often commit to a strategy early and then optimize it locally. In the authors’ experiments, more compute, prompting, or scaffolding did not reliably cause spontaneous strategic reconsideration. More tokens can extend a line of reasoning without changing its direction.

Primary source: https://arxiv.org/abs/2608.19072

9. Robot policies can break under a camera shift

GS-VLA reports a sharp viewpoint-sensitivity problem. In the worst reported case, a camera shift reduced LIBERO performance from roughly 90% to roughly 10%. The proposed Gaussian canonicalizer normalizes the view without retraining the policy. The numerical result remains an author-reported experimental result.

Primary source: https://arxiv.org/abs/2608.19066

10. A small AI-PC fleet can shard local inference

An OpenVINO layer pipeline distributes model inference across AI PCs. The authors report 1.79x two-node throughput for an 8B INT4 model with two users and interactive 70B inference across four Lunar Lake PCs. Those conditions matter: the result should not be generalized to arbitrary models, hardware, or user counts.

Primary source: https://arxiv.org/abs/2608.19147

The common thread is operational precision. A cache is not a benchmark. A longer run is not automatically a dead worker. More inference is not automatically a new strategy. The useful engineering work starts when each claim is attached to the condition that makes it true.

Disclosure: I used AI assistance to organize and edit this roundup, then checked every factual claim against the linked primary source.

One sketch, one prompt, four different 3D malls

LucioLiu — Tue, 18 Aug 2026 14:28:50 +0000

One unfinished sketch. One prompt. Four models asked to build an entire 3D shopping mall: Gemini 3.7 Flash, Grok 4.6, Claude Opus 5, and Kimi K3.

The comparison works because the input is shared and the differences are visible. One model invents space more aggressively, another focuses on materials, and another feels closer to simply finishing the sketch.

But one visual vote is not a model leaderboard. There are no repeated samples, blind judging, or task suite here. It answers a narrow question: for this sketch and this prompt, which result looks best to you?

Source: https://x.com/CodeByPoonam/status/2089687863390879901

What to verify before using this

One visual comparison is not a model leaderboard.
The source does not establish identical random seeds or post-processing.

Sources

https://x.com/CodeByPoonam/status/2089687863390879901

The source-side engagement is only a discovery signal. It is not this article's performance, and no product or model was independently benchmarked for this post.

A lemonade stand got a full POS and operations dashboard

LucioLiu — Tue, 18 Aug 2026 14:28:14 +0000

A parent vibe-coded a kid-friendly POS for a lemonade stand run by two children, ages four and six.

It is more than a payment button: SKU management, sales overview, customer records, cost monitoring, weather, and lemonade batches. The kids learned the hard way after spending three hours selling only four items, then later sold out and reached their first $100.

The fun part is the mismatch between a tiny lemonade stand and a complete dashboard. The useful part is simpler: as software gets cheaper, even a weekend stand can make inventory, cost, and reflection visible.

This is the creator's family story, not proof of a general business outcome.

Source: https://x.com/LinusEkenstam/status/2089633187160858875

What to verify before using this

The revenue and workflow are the creator’s account.
A dashboard does not prove profit or a general business outcome.

Sources

https://x.com/LinusEkenstam/status/2089633187160858875

The source-side engagement is only a discovery signal. It is not this article's performance, and no product or model was independently benchmarked for this post.

A personal agent needs recent context, not just more tools

LucioLiu — Tue, 18 Aug 2026 14:27:38 +0000

The hard part of a personal agent is not clicking buttons. It is knowing what you were doing five minutes ago.

OpenAI's Computer History turns recent activity across apps and websites into memories and a timeline that ChatGPT and Codex can reference. It can help resume recent work, locate something you saw, or turn a repeated workflow into a skill or automation.

It is off by default and currently limited to the macOS desktop app for eligible Pro, Business, and Enterprise users. You choose which apps and sites contribute, and you can pause, inspect, or delete the history. It does not record audio, store screenshots in history, or include private browsing.

The useful idea is not “AI knows everything.” It is recent context with visible controls and deletion.

Source: https://learn.chatgpt.com/docs/customization/computer-history

What to verify before using this

Off by default and currently limited to eligible macOS desktop users.
It does not record audio, store screenshots in history, or include private browsing.

Sources

The source-side engagement is only a discovery signal. It is not this article's performance, and no product or model was independently benchmarked for this post.

Cursor launched code hosting on GitHub’s worst day

LucioLiu — Tue, 18 Aug 2026 14:27:06 +0000

Cursor launched its own code hosting on the same day GitHub had an outage. The timing is the hook, but the product boundary is more useful.

Origin puts repositories, pull requests, code browsing, and agents in one place, with Vercel, Depot, and Buildkite integrations. An agent can answer questions about the current repo, change code, update a PR, or push a branch.

It is an early beta rolling out to paid plans. For repositories synced from GitHub, pushes still go to GitHub and GitHub remains the source of truth. The real shift is not “GitHub is dead.” It is that code hosting is being redesigned around agents.

Source: https://cursor.com/changelog/origin-code-hosting

What to verify before using this

Origin is an early beta rolling out to paid plans.
For GitHub-synced repositories, GitHub remains the source of truth.

Sources

The source-side engagement is only a discovery signal. It is not this article's performance, and no product or model was independently benchmarked for this post.

10 Source-Checked AI Updates for August 18

LucioLiu — Tue, 18 Aug 2026 14:26:26 +0000

10 source-checked AI updates for Aug 18. Paper results are author-reported, not independent reproduction.

1/10 OpenAI Ads adds automatic advanced matching. Supported form fields are hashed in the browser for measurement, not sent as plain text. https://help.openai.com/en/articles/20001214-measure-results

2/10 A study of 8,135 trials reports that procedural anchoring drives skill use far more often than knowledge injection. https://arxiv.org/abs/2608.14036

3/10 MOOSEDev organizes project memory with an ontology so records have types, relationships, and lifecycle. https://arxiv.org/abs/2608.13662

4/10 Envs-FORGE builds verified agent environments. Its reported gain is specific to the authors' tb-core setup. https://arxiv.org/abs/2608.14312

5/10 Agent handover works better as decisions and constraints, task statistics, and raw observations, not one summary. https://arxiv.org/abs/2608.14528

6/10 LSP can improve symbol localization, but grep still wins some rename tasks. Tool routing matters more than loyalty. https://arxiv.org/abs/2608.13568

7/10 ReFind reports that explainable lexical retrieval can beat a more complex graph baseline on MemoryAgentBench. https://arxiv.org/abs/2608.12888

8/10 Governed Persistent Memory adds deletion barriers and no-revival rules so old summaries cannot restore deleted facts. https://arxiv.org/abs/2608.12476

9/10 ERSkill evolves retrieval skills during use. The gains are author-reported and not independently reproduced here. https://arxiv.org/abs/2608.12720

10/10 The Embedder's Dilemma finds a tiny accuracy gap between its best LLM and embedding retrievers, with a large cost gap. https://arxiv.org/abs/2608.12875

What to verify before using this

Paper results are author-reported.
Preprints are not treated as completed peer review.
No source-side metric is our result.

Sources

The source-side engagement is only a discovery signal. It is not this article's performance, and no product or model was independently benchmarked for this post.