AI Intelligence

Photon Reprices Agent Search

7 stories · ~7 min read

Photon Reprices Agent Search

Listen

If You Only Read One Thing

At 230 milliseconds, a web search starts looking like an ordinary tool call. Search Becomes a Budget examines Perplexity’s Photon deployment; Waiting Leaves the Model examines Unreal Agent’s cheaper execution loop. Both reduce the expense of taking another step. That makes the stopping decision more consequential: cheaper steps can improve an answer, or simply finance a longer route to failure.

Search Becomes a Budget

Perplexity’s new search service changes the economics of agents that repeatedly consult the web. The important question is how much useful evidence a finished task buys, rather than how quickly one query returns.

The September 24 Photon report separates two improvements. Its internal retrieval-and-ranking engine now answers at roughly 65 milliseconds at the 99th percentile, versus 800 milliseconds previously. That excludes later search stages. The externally available Fast Search service returns 95% of search calls within 230 milliseconds. Neither number measures time to a correct final answer.

Tail latency is the slow end of a response-time distribution. Think of an agent checking several documents before making a claim: each slow search can delay everything that depends on it. Reducing those delays makes repeated investigation more practical. Call this the search waiting budget. Its importance grows when queries must happen sequentially because each answer determines the next question.

Photon reduces unnecessary data reads and overlaps disk waits. It also separates index construction from serving live queries, so updating the searchable collection need not compete with answering requests. The practitioner consequence is a tool that can return evidence sooner without changing the reasoning model.

The cheaper preset introduces a separate quality trade-off. Perplexity reports approximately 68% lower estimated model-plus-search spending across the same 3,554 selected tasks, with comparable aggregate quality. But its internal test of whether search returns an answer-bearing result falls from 59.6% to 56.7%. These are vendor measurements across different evaluations; the aggregate task result does not erase the retrieval loss.

That distinction matters most when evidence is scarce. A model may compensate for weaker ranking on a familiar question. It cannot reliably compensate for a missing document containing the one exception that changes the answer. Cheaper search therefore expands the affordable investigation budget, while leaving coverage as a separate constraint.

My inference is that search selection will increasingly resemble model selection: a fast path for ordinary requests, with deeper retrieval justified by ambiguity or missing evidence. Escalation itself needs testing; a model may not recognize what it failed to retrieve. The decisive deployment comparison is the rate of omitted answer-bearing sources on long-tail questions under a fixed total search budget.

Waiting Leaves the Model

The search waiting budget has an internal counterpart: tokens spent managing unfinished tools. An agent can consume fewer tokens without becoming a weaker reasoner when ordinary software takes over its waiting. Unreal Labs’ newly published runtime gives that proposition measurable support, although its headline savings need a narrower reading.

Unreal Agent’s September 22 release, circulating more widely this week, compares execution systems using the same GPT-6 Astra model at extra-high reasoning effort. Its largest advertised comparison puts total Terminal-Bench spending at $1,428 versus $2,350 for Codex, with equal reported pass rates. These are benchmark-run totals, not prices per task. That Codex figure is a leaderboard baseline, not a newly run matched control.

The mechanism is easy to picture. A conventional agent may repeatedly ask whether a long-running command has finished. Each check can bring the conversation back through the model. Unreal records that work is underway, runs the operation in the background, and delivers completion as an event. The model can schedule other useful work in the meantime. This is completion-driven execution: the result triggers the next reasoning step.

The open implementation makes the pattern inspectable. It separates persisted session history, tool requests and execution state. This extends September 17’s account of waiting-token consumption: the new contribution is a working alternative to repeated polling, rather than another observation that waiting costs tokens.

The report’s repository-question comparison makes the proposed saving more concrete: Unreal averages 16 model turns against Codex’s 22, and 898,000 input tokens per trial against 1.69 million. Those are vendor-reported averages, not an independent replication. The linked run records offer an audit path, but the comparison still needs matched task outcomes and separate accounting for cached input. Fewer processed tokens cannot be converted directly into the same percentage bill reduction. The reproducible question is how much reasoning disappears when software owns the wait.

There is also no isolated experiment attributing the gain solely to asynchronous execution. Smaller prompts and optimized tool outputs changed too. Some other providers rejected the running-then-final tool-result format, limiting portability.

For an existing multi-agent workflow, the useful refinement is below delegation: let deterministic execution code own waiting and completion. The adoption test is whether that change lowers cost per accepted task on long-tool workloads without losing cancellations, late results or human steering messages.

The Contrarian Take

Everyone says: Faster tools let agents finish sooner and cost less.

Here’s why that’s incomplete: Those gains assume the agent performs roughly the same amount of work. Cheaper search can encourage more searches; an asynchronous runtime can launch more operations before their results arrive. Perplexity’s weaker answer availability also means some apparent savings may require a second retrieval attempt. The right comparison holds the task’s acceptance standard constant while allowing the number of steps to change. A faster component earns its place when the whole task improves, including unsuccessful attempts and any correction work. Neither vendor has established that result for every workload, and the evidence does not justify treating speed as a universal quality improvement.

Under the Radar

  • A proof tool can strengthen the existing reviewer. Earlier this week, Boris Cherny reported 16 bug-fix pull requests after using Opus 5.5 to model Agent SDK behavior in Lean, a proof-checking language, with TLA+ used to examine concurrent state changes. The practical extension is to ask for machine-checked counterexamples to state-management assumptions; formal-methods practitioner Hillel Wayne’s objection identifies the boundary: a model can still choose inadequate properties to prove. The reported count is not a controlled measure of review improvement.

  • A confident user can derail a capable agent. DeepMind’s XYEval study, submitted September 20 and resurfacing this week, tests five models across six suites with plausible but misleading suggestions. Relative performance drops reach 46.7%; a warning in the system prompt only partly helps. For coding and research workflows, the implication is to distinguish the user’s intended outcome from the proposed implementation. A second reviewer given the same mistaken premise may preserve it, so model diversity alone does not address this failure.

Quick Takes

  • Local vision gets a faster completion path. Liquid AI’s September 24 DSpark release adds a small draft model that proposes output tokens for LFM2.5-VL-3B to verify. On an M5 Max, the company reports end-to-end speedups of 1.56–2.62 times, with integrations for MLX-VLM, llama.cpp and SGLang. This matters for local screenshot and document interpretation, but image processing and initial prompt processing are not accelerated; short answers may gain much less. (Source)

  • An empty refusal can now carry a bill. Anthropic’s September 24 change resumes billing for pre-output refusals in three categories: biology, frontier-model protection and reasoning extraction. Other pre-output refusal categories remain unbilled; fallback credit is unchanged. Production cost accounting must distinguish a rejected task from an uncharged request. Blindly retrying a refusal can multiply expenditure without producing another candidate answer, even when the application records no generated text. (Source)

  • A migration headline can hide a mixed production fleet. OpenAI’s September 23 Ringg case study reports approximately 90% lower model costs for selected real-time workloads moved to GPT-5.6 Luna. Yet the same account says GPT-4.1 still handles most voice and chat traffic. Historical-conversation evaluation followed by limited production rollout supports selective routing, not wholesale replacement. The claimed saving applies to migrated workloads, rather than Ringg’s entire operating bill. (Source)

The Thread

Cheap intermediate work can change how much work an agent attempts. That is the next question after September 20’s analysis of scheduling costs: once waiting and retrieval become cheaper, does the system stop at the old boundary or spend the saving on further exploration? A research agent could use the difference to check a contradictory source. A coding agent could run an additional diagnostic while tests execute. Both are useful only if the extra work changes the decision or catches a failure. My inference is that stopping behavior becomes a larger part of agent economics as individual operations get cheaper. Evaluation should therefore retain the rejected searches, abandoned branches and late-arriving results, not just the successful path. Otherwise the apparent improvement may describe one component while the complete workflow has quietly expanded around it.

Predictions

  • I predict: By October 25, Perplexity’s public Fast Search guidance will still distinguish latency-sensitive agent tasks from difficult or ambiguous searches that warrant the default preset. Its own retrieval-quality trade-off gives that distinction an engineering basis. (Confidence: medium; Check by: 2026-10-25)

Coming Next Week

The next question is when an agent should stop investigating. We’ll look for evidence that separates productive additional checks from repeated work, especially after cheaper tools change the cost of another attempt.


September 25, 2026 · 03:42 AM ET

Tomorrow morning in your inbox.

Subscribe for free. 10-minute read, every weekday.