# Pulse · August 7, 2026

> Google confirms crawlers fire non-GET/POST requests for JavaScript, WordPress patches a pre-auth RCE-capable XSS, and OpenAI widens free ChatGPT access.

Canonical: https://brandonlazovic.dev/pulse/2026-08-07/  
Author: Brandon Lazovic  
Published: 2026-08-07

## BigQuery's short-query optimizations cut slot usage up to 10x for agentic workloads

Status: Confirmed  |  Topics: ai-data-stack, llm-models-agents

Google Cloud's August 6 recap details a year of BigQuery performance work built for agentic workloads: automatic history-based query optimization, vectorized execution up to 10x faster on qualifying queries, and short-query optimizations for high-concurrency BI and AI agents that cut slot usage up to 10x with sub-second P99 latency. The same gains now extend to Iceberg lakehouse tables, and none of it requires code changes.

In plain terms: A 'slot' is the unit of compute BigQuery bills for, so lower slot usage means the same query costs less; 'P99 latency' means 99 out of 100 queries finish that fast or faster; and Iceberg tables are an open file format that lets BigQuery run the same speedups on data stored outside BigQuery itself.

Why it matters: Teams running LLM agents or high-concurrency dashboards against BigQuery get these gains automatically, which shifts the per-query compute-cost math behind an agent pipeline without anyone touching a query.

Our take: The automatic-everything framing matters more than any single percentage: agent workloads generate query volumes and patterns humans never would, so infrastructure that self-tunes without a human deciding when to intervene is the actual prerequisite for running agents at scale. Watch whether the cost drop reaches real bills, since 'up to' figures in a vendor performance recap describe a ceiling, not an average.

- [Google Cloud Blog: BigQuery performance optimizations](https://cloud.google.com/blog/products/data-analytics/bigquery-performance-optimizations/)

## Google confirms its crawlers fire HEAD, OPTIONS, PUT, PATCH, and DELETE requests, and blames JavaScript

Status: Confirmed  |  Topics: crawling-indexing-rendering

Google's Gary Illyes said on LinkedIn that Google's crawlers send HTTP requests beyond GET and POST, including HEAD, OPTIONS, PUT, PATCH, and DELETE, though these account for less than 1.5% of all requests Google's crawlers send. Illyes attributed the behavior to JavaScript: client-side code initiates these requests during Google's separate JavaScript-rendering pass, not the initial crawl.

In plain terms: GET and POST are the two HTTP methods almost every website expects; OPTIONS, PUT, PATCH, and DELETE are methods browsers send behind the scenes, often to ask a server what's allowed or to submit an API update, and they only show up here because Google's rendering step runs a page's JavaScript the same way a browser would.

Why it matters: Edge security that locks a site down to GET and POST only, a default plenty of hosting stacks ship with, can silently drop the JavaScript calls a client-side render depends on, so the content behind them never reaches what Google's renderer captures.

Our take: I've written about the split between Google's initial crawl and its separate JavaScript-rendering queue, and this confirms what drives it: rendering a page the way a browser would means executing whatever fetch, PUT, or DELETE calls a script fires, not just following links. The 1.5% figure also means most sites will never notice, but the ones that do are usually blocking a method their own JavaScript depends on.

- [Gary Illyes on LinkedIn](https://www.linkedin.com/posts/garyillyes_for-some-reason-i-got-a-few-questions-the-share-7491064690840850432-zfgS/)
- [Search Engine Roundtable: Google Crawlers Send HTTP Requests](https://www.seroundtable.com/google-crawlers-head-options-put-patch-delete-41833.html)

## OpenAI gives ChatGPT free users unlimited GPT-5.6 Luna chats and a new Think button for harder questions

Status: Confirmed  |  Topics: chatgpt-assistants, llm-models-agents

OpenAI said August 6 it is updating ChatGPT's default free-tier model to GPT-5.6 Luna with unlimited text chats, plus a new Think button that gives free users access to higher reasoning on harder questions. For Plus and Pro users, GPT-5.6 Sol now powers both instant replies and deeper reasoning in one consistent model, with a slider to control how much thought goes into each response, and updates aimed at more focused, fact-reliable answers.

In plain terms: Sol is OpenAI's most capable model and Luna is its fastest, cheapest one; free users now get Luna by default with no daily limit on text chats, plus a Think button that borrows extra reasoning power for harder questions instead of always running the lighter model.

Why it matters: The model that answers by default for ChatGPT's roughly 1 billion weekly users just changed, and unlimited free access to it widens the population whose queries any AI-visibility tracking now has to account for.

Our take: Widening free access to a faster default model is a retention move as much as a capability one, and the Think-button pattern of manually escalating to more reasoning power is becoming the standard shape across chat products rather than an OpenAI-specific idea. What's worth watching is whether unlimited free Luna access shifts where casual research and shopping queries actually happen, since that population was previously rate-limited out of long sessions.

- [OpenAI: Improving GPT-5.6 Sol in ChatGPT, and expanding access to GPT-5.6 Luna for free users](https://openai.com/index/improving-gpt-5-6-sol-in-chatgpt)

## WordPress 7.0.3 patches a pre-auth XSS bug on the login screen that can lead to remote code execution

Status: Confirmed  |  Topics: crawling-indexing-rendering, platform-ecommerce

WordPress released version 7.0.3 on August 6, 2026, fixing 12 security issues. The most severe, CVE-2026-64638, is a pre-authentication reflected XSS on the login screen that can escalate to PHP code execution if a site administrator clicks a crafted link. Other fixes cover stored XSS in post content and Quick Edit, a multisite privilege-escalation issue, and server-side request forgery. WordPress.org recommends updating immediately. The release also backports patches to versions as old as 4.7.

In plain terms: A 'reflected XSS' bug means a malicious link can inject code into a page the moment an admin clicks it, rather than the attacker needing existing access to the site; 'pre-authentication' means the attacker doesn't need a login to trigger it, which is what makes this one more dangerous than a typical XSS bug.

Why it matters: Any WooCommerce or content site running WordPress is exposed until this update lands, and a compromised site risks the kind of Safe Browsing flag or hack cleanup that also tanks rankings and AI-citation trust.

Our take: WordPress powers a large enough share of e-commerce and content sites that a pre-auth, no-login-required XSS with an RCE path gets weaponized within days of disclosure, not months. The practical test for any site running WordPress isn't whether the update gets applied eventually, it's whether it happens before automated scanners start probing for CVE-2026-64638 specifically.

- [WordPress.org News: WordPress 7.0.3 Release](https://wordpress.org/news/2026/08/wordpress-7-0-3-release/)
- [Search Engine Journal: WordPress Security Release 7.0.3 Fixes High Severity XSS Vulnerability](https://www.searchenginejournal.com/wordpress-security-release-7-0-3-fixes-high-severity-xss-vulnerability/584927/)