DEV Community: openai

AI Reasoning Breakthroughs: DeepSeek-R1 and OpenAI's Path to Logic

trillioniar s — Wed, 14 Oct 2026 14:34:37 +0000

Today's AI landscape is shifting from probabilistic word prediction to structured logical reasoning. New models are utilizing reinforcement learning to "think" before they speak, drastically improving performance in math and coding.

The Rise of Reasoning Models

OpenAI's Learning to Reason

OpenAI has introduced new methodologies for LLMs to reason through complex problems. By integrating chain-of-thought processing, models can now self-correct and explore multiple paths to a solution. This reduces hallucinations in technical domains.
Source: OpenAI

DeepSeek-R1 and RL

Incentivizing Logic via Reinforcement Learning

DeepSeek-R1 demonstrates that reasoning capabilities can be incentivized through specialized RL. The model shows a marked improvement in mathematical reasoning by rewarding the process of derivation rather than just the final answer.
Source: arXiv

The Philosophical Shift

LLM Inevitabilism

The concept of "LLM Inevitabilism" suggests that the integration of these models into every layer of software is unavoidable. As reasoning capabilities stabilize, LLMs move from being "chatbots" to becoming the core operating system for digital tasks.
Source: Tom Renner

Open Source and Accessibility

Meta's Open Source Push

Meta continues to advocate for open-source AI as the only viable path to prevent corporate monopolies. By releasing high-performance weights, they enable a global ecosystem of fine-tuning and safety research.
Source: Meta

Infrastructure for Scale

Google DeepMind's Gemini Evolution

Gemini continues to iterate on multi-modal reasoning, integrating native audio and video processing into the reasoning loop. This allows the model to reason about physical space and temporal events more accurately.
Source: Google DeepMind

FAQ

What is Chain-of-Thought processing?

It is a technique where the model generates intermediate reasoning steps before providing the final answer.

How does DeepSeek-R1 differ from standard LLMs?

DeepSeek-R1 uses reinforcement learning to specifically reward the reasoning process, not just the output.

Why is open-source AI important for reasoning?

Open weights allow researchers to inspect the "hidden" reasoning chains to ensure safety and transparency.

Will reasoning models replace traditional coding?

They will likely augment coding by handling architectural logic, while humans focus on high-level design.

How do these models reduce hallucinations?

By verifying internal steps of a logic chain, models can spot contradictions before finalizing a response.

Claude vs Gemini vs GPT: What a 2026 Study of 26 AI Models Reveals About Long Context

Egor — Wed, 14 Oct 2026 14:28:14 +0000

26 AI models. 6,438 evaluation instances. Contexts up to 1 million tokens. The results challenge how we compare modern language models.

Introduction

Imagine giving an AI assistant an entire software repository.

Thousands of files. Hundreds of modules. API documentation, database schemas, and years of development history.

The model accepts everything without complaining.

You ask it to identify a subtle architectural problem.

It confidently provides an answer.

But is that answer actually reliable?

In 2026, the question is no longer simply whether a language model can accept a million tokens.

The more interesting question is:

How much of that context can the model actually use correctly?

A recent research paper, ATLAS: All-round Testing of Long-context Abilities across Scales, provides some surprising answers.

The researchers evaluated 26 models on 6,438 instances across eight capability dimensions, considering input lengths from 8K to 1M tokens.

One finding stands out:

Gemini 3.1 Pro Preview led at 128K, but Claude Opus 4.6 led at 1M.

The best model depends on how you measure it.

Let's examine what the researchers tested, what their results actually mean, and why these findings matter for developers building real AI systems.

Research note: This article analyzes published 2026 research. It is not an independent benchmark, and it does not claim that the author personally tested all 26 models.

1. The Problem With AI Benchmarks

When comparing language models, we often see a familiar table:

Model	Context window
Model A	128K
Model B	256K
Model C	1M

The implication seems obvious.

Model C can process more information, so it must be better at large-document tasks.

But this reasoning contains a hidden assumption:

That accepting more information means using that information effectively.

Consider two different tasks.

Task A: Simple retrieval

A document contains the sentence:

"The deployment identifier is QZ-7194."

The model is asked to retrieve that identifier.

Task B: Complex reasoning

A repository contains dozens of service definitions, configuration files, and dependency relationships.

The model must identify which changes could introduce a security regression.

The second task requires much more than finding one string.

It may involve combining evidence from many locations, resolving contradictions, and understanding dependencies.

A model that performs well on Task A might struggle on Task B.

That's exactly why evaluating long-context AI requires more than a single benchmark number.

2. ATLAS: A Different Way to Measure Long-Context Intelligence

Research: ATLAS: All-round Testing of Long-context Abilities across Scales

Authors: Deli Huang and colleagues

Published: May 27, 2026

Paper: https://arxiv.org/abs/2605.28079

The ATLAS researchers investigated two major weaknesses in traditional long-context evaluation.

First, model performance can deteriorate as input length increases.

Second, success on foundational tasks such as retrieval does not necessarily transfer to more complex application workloads.

Their framework introduces several methodological improvements.

Evaluating across context lengths

Instead of measuring performance at only one input size, ATLAS considers scores across a predefined context-length grid, from 8K to 1M tokens.

This makes it possible to analyze how performance changes as more information enters the prompt.

A model that performs exceptionally well at 128K may deteriorate more sharply than another model at longer lengths.

Separating foundational abilities from applications

ATLAS distinguishes foundational operations from downstream workloads.

This matters because retrieving information and applying it correctly are different capabilities.

For instance, a model may identify relevant functions in a repository without understanding how they interact.

Measuring balanced performance

The researchers introduce ATLAScore, a harmonic-mean-based aggregate across capability categories.

This is intended to penalize highly imbalanced capability profiles.

A model that dominates one task but struggles on others should not automatically receive the strongest overall evaluation.

The framework also includes uncertainty propagation when computing its final aggregate scores.

Together, these changes provide a more nuanced picture than a single retrieval accuracy number.

3. The Result: The Leader Changes at 1 Million Tokens

One of the most interesting findings concerns model rankings.

According to the ATLAS paper:

Evaluation scope	Leading model
Up to 128K tokens	Gemini 3.1 Pro Preview
Up to 1M tokens	Claude Opus 4.6

This does not mean Claude is universally better than Gemini.

Nor does it mean Gemini is inherently unreliable.

It means the relative ranking changes under the specific evaluation conditions used by ATLAS.

The researchers also reported that seven models changed position by at least two ranking places when the evaluation expanded from the 8K–128K range to the 8K–1M range.

That's important.

Imagine selecting a model for your application after reviewing results obtained only at 128K.

Your production workload, however, frequently processes 600K-token documents.

The benchmark you used may not reflect your actual operating conditions.

And if models deteriorate at different rates, their relative performance at 600K may differ from their relative performance at 128K.

The key insight: model quality is not independent of context length.

A useful benchmark should measure the range your application actually uses.

4. Why Context Length Changes the Difficulty

Let's examine a simplified example.

Imagine this information appears inside a long repository:

service_a.py:
Service A sends requests to Service B.

service_b.py:
Service B uses Database C.

config.yaml:
Database C has public network access enabled.

security_policy.md:
Production databases must not expose public access.

Now ask:

"Does Service A indirectly depend on a database with a potentially unsafe network configuration?"

Answering correctly requires several steps.

First, identify the dependency between Service A and Service B.

Second, identify Service B's database.

Third, find Database C's configuration.

Finally, compare that configuration with the security policy.

No single sentence contains the entire answer.

As the context grows, the model must identify relevant information among more irrelevant material while preserving the connections between different pieces of evidence.

This creates distinct possible failure modes:

Missing one of the necessary pieces of evidence
Retrieving a similar but incorrect detail
Correctly retrieving the evidence but connecting it incorrectly
Producing a plausible conclusion unsupported by the source material

The example is illustrative, not an ATLAS test case.

But it demonstrates why longer context can increase difficulty even when every relevant document fits into the model's advertised context window.

5. Another 2026 Study Reveals a Deeper Problem

ATLAS evaluates long-context capabilities across models and scales.

A separate 2026 study, CorpusQA: A 10 Million Token Benchmark for Corpus-Level Analysis and Reasoning, investigates a different question:

Can AI systems analyze entire collections of documents when the evidence is distributed throughout the collection?

Authors: Zhiyuan Lu and colleagues

Originally published: January 21, 2026

Revised: April 25, 2026

Paper: https://arxiv.org/abs/2601.14952

CorpusQA includes tasks involving financial, educational, and real-estate documents.

Some questions require aggregating numerical information from many documents.

For example, imagine analyzing hundreds of financial reports to identify every company satisfying several accounting conditions.

A traditional retrieval system might find a few relevant documents.

But if answering the question requires analyzing every company, retrieving only five documents is insufficient.

This is a fundamentally different problem from finding one answer-bearing passage.

The published results

CorpusQA evaluated several models at different context lengths.

For Gemini 2.5 Pro, the authors reported:

Context length	Overall accuracy
128K	80.19%
1M	50.73%

These results show a decline of 29.46 percentage points under the study's conditions.

Importantly, CorpusQA evaluated Gemini 2.5 Pro, not Gemini 3.1 Pro.

Its results cannot be directly substituted for the newer model's performance.

But they illustrate how difficult corpus-level analysis can remain, even when a model supports very long inputs.

The study also found that conventional retrieval-augmented generation performed poorly on tasks requiring globally distributed evidence.

The lesson isn't that RAG is useless.

It's that retrieving a handful of relevant chunks is not the same as analyzing an entire document collection.

6. Why Traditional RAG Can Fail on Global Questions

A typical RAG pipeline looks like this:

User question
      |
      v
Vector search
      |
      v
Top-K relevant chunks
      |
      v
LLM
      |
      v
Generated answer

This works well when a question can be answered using a relatively small number of relevant passages.

For example:

"What is the API rate limit?"

A good retrieval system can locate the appropriate documentation paragraph and pass it to the model.

Now consider another question:

"Across all customer reports from the last year, which failure category increased the most?"

The answer requires a global aggregation.

Retrieving only the most semantically similar documents may exclude a large part of the dataset.

No matter how capable the LLM is, it cannot correctly aggregate information it never receives.

This is an information-coverage problem, not merely a language-model problem.

In the CorpusQA evaluation at 1M tokens, standard RAG achieved 17.38% accuracy, compared with 44.95% for the Memory Agent approach using Gemini 2.5 Pro.

This illustrates how different approaches to managing large document collections can significantly affect performance.

A better architecture for some analytical tasks

For questions requiring exact aggregation, a structured processing pipeline may be more appropriate:

Document collection
        |
        v
Information extraction
        |
        v
Structured records
        |
        v
SQL / analytical computation
        |
        v
Evidence verification
        |
        v
LLM-generated explanation

This design separates factual computation from language generation.

The LLM can interpret the user's question and explain the result, while deterministic code handles calculations.

Of course, the approach has its own limitations.

Extraction errors, incomplete schemas, and stale data can still produce incorrect answers.

But it creates opportunities to validate individual steps instead of relying entirely on one enormous prompt.

7. What About Vendor Benchmarks?

Independent research is only one source of evidence.

Model developers also publish technical evaluations.

For example, Anthropic's Claude Opus 4.6 System Card discusses long-context benchmarks such as MRCR and GraphWalks.

Source: https://www.anthropic.com/system-cards

MRCR evaluates the ability to locate and distinguish between similar pieces of information across long inputs.

GraphWalks examines structured reasoning over graph-like information represented within the context.

These evaluations are useful because they test capabilities beyond ordinary question answering.

However, developer-published benchmark results need careful interpretation.

Providers may use different inference settings, reasoning budgets, input limits, filtering rules, or evaluation configurations.

A benchmark score obtained under one provider's setup should not automatically be treated as directly comparable with an independent benchmark.

In particular, the ability to answer a question using a long prompt depends on more than the model checkpoint.

It can also depend on:

Reasoning budget
Tool usage
Prompt construction
Context truncation
Sampling configuration
Dataset filtering
Evaluation metrics

These differences can materially affect observed results.

That's one reason ATLAS is interesting: its evaluation explicitly attempts to compare long-context capabilities across multiple tasks and lengths.

8. What This Means for AI Coding Assistants

Consider an AI coding assistant with access to a large repository.

There are two possible designs.

Approach A: Put everything in the prompt

Entire repository
       |
       v
Large context window
       |
       v
LLM response

This is conceptually simple.

But it can be expensive and may introduce large amounts of irrelevant information.

It also doesn't guarantee that the model will correctly connect all important details.

Approach B: Search, inspect, and verify

User question
      |
      v
Repository search
      |
      v
Relevant files
      |
      v
Dependency analysis
      |
      v
LLM reasoning
      |
      v
Tool-based verification
      |
      v
Final answer

This approach can use search tools, static analysis, tests, and targeted context retrieval.

For some software engineering tasks, those tools may provide more reliable evidence than simply expanding the prompt.

For instance, when checking whether a function is actually called, repository search can identify references.

When checking whether a proposed patch works, an automated test can provide execution evidence.

An LLM can assist with interpretation, but it doesn't have to perform every operation internally.

The broader principle is:

Use the context window as one resource in an engineering system, not as a replacement for the system itself.

9. How I Would Benchmark Modern AI Models

The published results suggest a practical evaluation protocol for comparing models on real development workflows.

I would test each model across four dimensions.

Test A: Context length

Evaluate the same task family at:

8K
32K
128K
256K
512K
1M

Only include lengths genuinely supported by each tested model and API configuration.

Test B: Evidence position

Place answer-relevant information near the beginning, middle, and end of the input.

Measure whether accuracy changes.

Test C: Reasoning complexity

Use several difficulty levels:

Level 1: Retrieve one explicitly stated fact.

Level 2: Connect information from two files.

Level 3: Combine evidence from several documents.

Level 4: Perform global analysis across an entire corpus.

Test D: Tool-assisted reasoning

Compare direct long-context prompting against workflows using retrieval, code execution, or other verification tools.

For every experiment, record:

Metric	Why it matters
Answer accuracy	Measures correctness
Context length	Reveals scale sensitivity
Input/output tokens	Measures resource usage
Latency	Measures responsiveness
Cost	Measures practical efficiency
Evidence completeness	Checks whether necessary information was found

Model versions and inference settings should be fixed and documented.

Tasks should be repeated using multiple independent examples, with uncertainty estimates reported alongside aggregate scores.

This is a proposed experimental design, not a claim that these tests have already been run for this article.

10. Limitations and Research Caveats

There are several reasons to interpret these findings carefully.

First, ATLAS is a May 2026 preprint. Its results are useful research evidence, but they should not be mistaken for a universally accepted model ranking.

Second, the comparison covers a specific collection of 26 models and evaluation settings. It does not establish the performance of every model released later in 2026.

Third, CorpusQA evaluates a different set of models and tasks. Its numerical results cannot be directly compared with ATLAS scores.

Fourth, performance at 1M tokens may involve implementation-specific constraints, including inference settings and context handling.

Finally, benchmark results do not automatically predict real-world performance.

An AI system answering legal questions, writing code, analyzing scientific papers, or processing financial records may require very different capabilities.

The correct model and architecture should be selected through task-specific evaluation.

Conclusion: We Need Better Questions Than "How Many Tokens?"

The rapid growth of context windows is an important technological achievement.

But the 2026 research tells a more complicated story.

The ATLAS study found that model rankings change when evaluation extends toward one million tokens.

CorpusQA demonstrated the difficulty of analyzing large document collections when relevant evidence is dispersed across many sources.

Together, these studies suggest that increasing context capacity alone is not enough to guarantee reliable information processing.

For developers, the practical implications are straightforward:

Don't select an LLM based only on advertised context size.

Evaluate it at the lengths your application actually uses.

Test retrieval and reasoning separately.

Measure the quality of evidence, not only the fluency of the generated answer.

And consider whether structured tools, retrieval systems, or deterministic computation can make your application more reliable.

The future of long-context AI may not be about putting everything into one prompt.

It may be about building systems that know what to retrieve, what to remember, what to compute, and what to verify.

A million-token context window is a capability.

Reliable reasoning over a million tokens is a different achievement.

References

[1] ATLAS — All-round Testing of Long-context Abilities across Scales (2026)

Deli Huang et al.

https://arxiv.org/abs/2605.28079

[2] CorpusQA — A 10 Million Token Benchmark for Corpus-Level Analysis and Reasoning (2026)

Zhiyuan Lu et al.

https://arxiv.org/abs/2601.14952

[3] Claude Opus 4.6 System Card (2026)

Anthropic.

https://www.anthropic.com/system-cards

Discussion

Do you think future AI systems will rely primarily on larger context windows, or will retrieval, memory, and tool-assisted reasoning become more important?

And have you encountered cases where an LLM missed important information even though it was present in the prompt?

I'd be interested in hearing about real-world experiences.

GitHub: https://github.com/coffee1337

Portfolio: https://coffee1337.github.io/

A Federal Judge Just Ordered OpenAI to Hand Over Its Interview Notes — Because Apple Says They Were a Shopping List

Faith & Fact - Marky Mark — Wed, 14 Oct 2026 14:21:47 +0000

FOLKS. WAKE UP. A federal judge just reached into the most secretive hiring process in Silicon Valley and said hand me the clipboard.

On Monday, U.S. District Judge Edward Davila ordered OpenAI to turn over its interview materials — checklists, guides, instructions, manuals, scripts, technical presentations — anything referencing Apple technology in interviews with former Apple employees. Five days for what they've already collected. Fourteen for the rest. That is not a leisurely legal timeline. That is a judge saying now.

Apple sued in July. The names in the filing are real people: Chang Liu. Alyssa Peng. Tang Yew Tan, who is now OpenAI's Chief Hardware Officer. All ex-Apple. And the court granted Apple expedited discovery — early access to documents and employee testimony, before the usual slow grind.

The allegation is the part they don't want you to sit with

Apple's claim isn't "someone remembered something." Apple says former employees downloaded confidential files onto Apple laptops — specifications, engineering presentations, proprietary project data on unannounced products. And then the part that should make the hair on your neck stand up: Apple alleges ex-employees coached candidates on what to bring to the interview.

Think about what that describes, if true. Not a leak. A procedure. A repeatable one.

They told you the robots were coming for your job. Nobody mentioned the robots would need a hardware roadmap first, and that the fastest way to get one is to interview the guy who drew it.

And why hardware? Because OpenAI is building consumer hardware — the thing that might sit where your phone sits. Apple owns that square of your pocket. This is two of the largest entities on earth fighting over who gets to put the next object in your hand, and the discovery fight is over a stack of interview notes.

Here's the signal in the noise

I am obligated to tell you the sober part, because I'm not here to lie to you: these are allegations. Apple asserted them. A judge ruled Apple may go look — that is a discovery ruling, not a finding that anything was stolen. OpenAI has not been found liable of anything. Write that down.

And that gap right there — between "a company alleged it" and "a court found it" — is where you get played. Every outlet covering this will compress it differently. Some will say Apple won. Some will say it's routine. Both are shaped. The actual document says something narrower and more boring than either headline.

Which is the entire reason you never take one source's framing on something that matters. Ask several of the most powerful AI models the same question and watch what they do with it. When they converge, you've got something. When they split, you have just located the exact spot where the story is being spun — and that is a gift. Gangsta AI runs your question across the top models in parallel and puts an adjudicator over the top of them, so you see the agreement, the disagreement, and the reasoning instead of one confident voice telling you what to think.

One model will tell you Apple won. Another will tell you it's procedural. Make them argue in front of you — then decide. That's not paranoia. That's just reading the docket yourself.

Sources

Originally published on Gangsta AI News. Gangsta AI lets you compare 30+ AI models side by side on a single prompt — free, no login. Try the AI model comparison tool.

Friend 2 launched for $249 with built-in speaker and artificial intelligence

Hacks.gr — Wed, 14 Oct 2026 14:01:31 +0000

Avi Schiffmann's Friend 2 is a $249 AI-powered wearable pendant running on OpenAI's latest language models.

The device captures nearby audio via a neck-worn form factor and includes a rear speaker for unprompted speech, supporting configurable personas and built-in content restrictions.

The project was created by Avi Schiffmann, who previously became known for creating a surveillance tool during the pandemic. The first generation of the device had caused strong reactions and protests due to an advertising campaign on the New York subway.

How it works and what it can do

The new version is powered by OpenAI’s newest AI models. While the manufacturer initially said the device would have a fixed, unchanging personality, users can eventually log into the app, change the chatbot’s name, and create different personas, including Sage, Nova, Onyx, River, Echo, Willow, and Wren.

The device's conversations are limited to simple chat and have built-in content limits to prevent inappropriate interactions. Unlike the first version, which could become aggressive, the new model features more conservative responses and limited web search capabilities.

Plans for the future

The device's creator announced plans for a future update, under which all users will chat with a single global artificial intelligence entity that shares a common framework, while acknowledging data privacy concerns.

Hacks.gr on Google

Set it as a preferred source for cybersecurity updates.

Preferred source

Read the original English article on Hacks.gr

Claude vs GPT for AI agents: what I actually ship with (2026)

Joan Comadran — Wed, 14 Oct 2026 13:34:31 +0000

Here's the verdict, so you can leave early if that's all you came for: I build my AI agents on Claude, and I'd still tell most people that the honest answer to "Claude vs GPT for agents" in late 2026 is "it matters less than you think." As of October 2026 the two price ladders mirror each other almost to the cent, both have 1M-token context windows, both enforce tool schemas strictly, and both host web search for you. What's left to choose on is API shape, how much control you get over caching, which hosted tools you need, and which one your evals prefer on your tool schemas.

If you want a default: pick Claude if your agent lives on long, growing context and you care about controlling exactly what gets cached. Pick GPT if you're building a voice agent, want hosted file search over your documents, or your company already runs on OpenAI or Azure contracts.

One disclosure before the table, because comparison posts rarely make it: every agent I run in production is on Claude. I've used OpenAI's API, but I don't have a shipped GPT agent to compare like-for-like, so the GPT column below comes from OpenAI's docs and pricing pages, not from war stories. The Claude column comes from code I can show you.

Claude vs GPT at a glance (as of October 2026)

All prices are list prices per million tokens (input / output), taken from the Anthropic and OpenAI pricing pages in October 2026. These change often; check before you budget.

	Claude (Anthropic)	GPT (OpenAI)
Current lineup	Fable 5.1, Opus 5.5, Sonnet 5.5, Haiku 5.5	GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna
Top tier	Fable 5.1: $10 / $50	GPT-6 Astra: $10 / $50
Between top and mid	Opus 5.5: $4 / $20	—
Workhorse tier	Sonnet 5.5: $2 / $10	GPT-6.1 Sol: $2 / $10
Cheap, high-volume tier	Haiku 5.5: from $0.10 / $0.50 (prompts up to 100K tokens)	GPT-6 Luna: from $0.10 / $0.50 (short context)
Context window	1M tokens on all current models	1.05M tokens on the flagship three
Long-context billing	Full 1M at the standard rate (except Haiku 5.5 above 100K)	Separate, higher long-context rate
Max output	128K tokens	128K tokens
API you build agents on	Messages API (`tool_use` / `tool_result` blocks)	Responses API (required for tool calling on Astra and Sol)
Schema-enforced tool calls	`strict: true` on tool definitions	`strict: true`; Responses tries to make tools strict by default
Prompt caching	Explicit `cache_control` breakpoints or automatic; cache reads at 10% of input or less	Discounted cached input (5–10% of input on the flagship three)
Batch discount	50%	50%
Hosted tools	Web search ($10 / 1K searches), web fetch, code execution, tool search, MCP connector, computer and browser use	Web search ($10 / 1K calls), file search, hosted shell / code interpreter, computer use, MCP, tool search
Voice / realtime	Text and image in, text out	Dedicated realtime and voice models

Look at the price rows for a second. Not long ago, a "Claude vs GPT" post was half about cost. Now the cheap tiers start at the same price, the workhorse tiers are identical, and the top tiers are identical. Rate cards aren't where the difference is anymore.

Where they actually differ for agent builders

The API shape

On Claude, an agent turn is a Messages API call. If the model wants a tool, the response has stop_reason: "tool_use" and one or more tool_use blocks; you run them and send back a user turn full of tool_result blocks. On GPT, the newest models require the Responses API for tool calling: the output is a list of items, tool calls come back as function_call items, and you return function_call_output items, optionally chaining with previous_response_id.

Neither is better in the abstract. They are different enough that "we'll just swap the model later" is a week of work, not a config change, once you've built retries, caching, cost logging and error handling around one of them.

Caching control

This is the one that decided it for me. Claude lets you mark exactly where the cacheable prefix ends with cache_control breakpoints (or let the API place them automatically). In a conversational agent, where the system prompt is static and the history grows every turn, being able to say "cache everything up to here" is the difference between cost that grows with the square of the conversation and cost that grows roughly linearly. I wrote up the full story in keeping Claude's token bill from ruining your month.

OpenAI discounts cached input heavily too, so this isn't "Claude caches, GPT doesn't." It's about how much you get to steer it.

Long context billing

Both vendors offer roughly a million tokens of context. The difference is the bill: Anthropic charges the full 1M window at the standard rate on its current models (Haiku 5.5 aside), while OpenAI lists a separate, higher long-context price on Astra, Sol and Luna. If your agent stuffs whole codebases, contracts or long transcripts into context, model that difference before you pick. If your prompts are a few thousand tokens, it doesn't matter.

Hosted tools

Both now run web search on their side and support MCP. OpenAI has hosted file search with managed storage and a full line of realtime voice models; if you're building a phone or voice agent, that alone probably decides it. Anthropic has server-side web search and web fetch, code execution, a tool-search tool for large tool sets, and an MCP connector that talks to remote MCP servers straight from the Messages API.

What I actually run in production (and why)

None of my agents use LangChain or the Vercel AI SDK. Every one calls @anthropic-ai/sdk directly, because the provider-specific features are exactly the ones I'm relying on. Here are two, straight from the repos.

Claient: a multi-tenant WhatsApp agent on Haiku

Claient answers and qualifies WhatsApp leads for small businesses (the build story is here). The model choice is gated by who pays:

// With the platform key (we pay), only Haiku is served.
// Tenants who bring their own key (BYOK) can pick Sonnet or Opus.
export const MODELO_BASE = "claude-haiku-4-5-20251001";

export function modeloEfectivo(opts: { apiKey?: string | null; model?: string | null }) {
  if (!opts.apiKey) return MODELO_BASE;
  return opts.model || getClaudeConfig().model;
}

The reply runs in a tool-use loop with three booking tools (check availability, book, reschedule). Two guards matter more than the model: a hard cap of five loop iterations, and a time budget, because a serverless function killed mid-loop means the lead got a message but the webhook didn't finish, and Meta's retry sends it twice:

const MAX_ITER_TOOLS = 5;
const MARGEN_VUELTA_MS = 20_000; // SDK timeout 15 s + 1 retry must fit

for (let i = 0; i < MAX_ITER_TOOLS; i++) {
  if (i > 0 && !hayMargen(opts.deadline)) break; // fall back instead of dying mid-turn
  const respuesta = await claude.messages.create({ model, max_tokens, system, messages, tools });
  if (respuesta.stop_reason === "tool_use") {
    // run each tool_use block, push the tool_result blocks, loop again
    continue;
  }
  return textOf(respuesta);
}

Lead qualification is a separate call that forces a tool, tool_choice: { type: "tool", name: "registrar_lead" }, with nullable fields and an enum for lead temperature (cold, warm, hot). Forcing a tool is the most reliable way I know to get structured data out of a conversation, and GPT can do the same thing with tool_choice plus strict mode. The cache breakpoints sit on the system prompt and the latest turn, and the history sent is a window of the last 16 messages plus a rolling summary. Every call logs input, output, cache-read and cache-write tokens and their USD cost per tenant, with a monthly spend cap.

An honest footnote: Claient still pins Haiku 4.5, which is now a legacy model. Haiku 5.5 lists at a tenth of the price. That's the obvious thing to test next, and it's also a good example of why you want evals: "cheaper and newer" is a hypothesis until your own conversations say otherwise.

Pollitics: two models, two jobs

For pollitics.es, a weekly job drafts candidate questions about the week's news for a human to review. It's split into two Claude calls on purpose:

Research on Sonnet 5.5 with Anthropic's server-side web search (max_uses: 10, effort medium). Most of the cost here is input tokens from the pages it reads, so the cheaper model does the reading.
Drafting on Opus 5.5 with JSON-schema structured output (effort high), where editorial nuance matters and the input is small.

It's two calls, not one, because structured output doesn't carry the search citations, so the research comes back as text with URLs and the drafter works from that. The code also handles pause_turn (the server-side search loop paused, send it back to continue) and refusal stop reasons, and the whole thing has to fit inside a 150-second Edge Function. A deterministic review step then flags anything that breaks the editorial rules before a person approves it.

So why Claude?

Not because GPT couldn't run either of these. The reasons are concrete and a little boring:

Cache breakpoints matched the architecture. Static script plus growing history is exactly the shape explicit cache_control is good at.
Tiering within one vendor. Haiku for every message, Sonnet for reading the web, Opus for the writing that matters. One SDK, one usage format, one cost table. Dairector's script doctor runs on Claude too.
BYOK stays simple. Tenants paste one kind of key. Supporting two providers' keys, models and error classes would double the surface for very little customer value.
Compounding. Timeouts, retries, error classification (AuthenticationError vs transient 429/5xx), cost logging: all written once, against one SDK. That's the real lock-in, and it's mine, not the vendor's.

When to use which

Choose Claude when:

Your agent is conversational or long-running and context grows every turn, so caching control pays for itself.
You need very long context and don't want a long-context surcharge on the mid and top tiers.
You want one vendor with a clear cheap / workhorse / heavy ladder to route tasks across.

Choose GPT when:

You're building a voice or phone agent and want first-party realtime models.
You want hosted file search over your documents without running your own vector store.
Your organisation already has OpenAI or Azure OpenAI contracts, data agreements and monitoring in place. That's a perfectly good reason; procurement is engineering too.

Either way:

Build a small eval set from real conversations (twenty is enough to start) and run both on your actual tool schemas before you commit.
Put the model call behind one module of your own so a future switch touches one file.
Cap loop iterations and spend from day one. Neither vendor will do that for you.

If you're weighing this for a real product and want someone who has shipped agents end-to-end to make the call with you, that's what I do. For the rest of the stack around the model, see how I ship an AI product in a weekend.

FAQ

Is Claude or GPT better for building AI agents in 2026?

Neither wins across the board. As of October 2026 the price tiers mirror each other (Sonnet 5.5 and GPT-6.1 Sol are both $2/$10 per million tokens; Haiku 5.5 and GPT-6 Luna both start at $0.10/$0.50), both offer 1M-token context, 128K max output, strict schema-enforced tool calls and hosted web search. Claude is the better default if you want explicit control over prompt caching and long context billed at the standard rate; GPT is the better default for voice agents, hosted file search, or teams already on OpenAI or Azure. Run your own eval on your own tool schemas before committing.

Is Claude more expensive than GPT for agents?

Not anymore at list price. As of October 2026 the mid tiers (Claude Sonnet 5.5 and GPT-6.1 Sol) are both $2 input / $10 output per million tokens, the cheap tiers (Claude Haiku 5.5 and GPT-6 Luna) both start at $0.10 / $0.50, and the top tiers (Claude Fable 5.1 and GPT-6 Astra) are both $10 / $50. Claude Opus 5.5 sits in between at $4 / $20. Both offer 50% off for batch work and discounted cached input. Real cost differences come from how much context you resend and how well you cache it, not the rate card.

Can I switch an agent from Claude to GPT later?

Yes, but it is not a one-line change. The Claude Messages API uses tool_use and tool_result content blocks; OpenAI's Responses API, which GPT-6 Astra and GPT-6.1 Sol require for tool calling, uses function_call and function_call_output items. Caching, usage fields, error classes and hosted tools also differ. Keep the model call behind one small module of your own so a switch touches one file, and keep an eval set so you can tell whether the switch was an improvement.

Which model does Joan Comadran use for production AI agents?

Claude, called directly through the Anthropic TypeScript SDK with no agent framework. Claient, the WhatsApp lead agent, runs Claude Haiku 4.5 by default with tool use for appointment booking and forced tool calls for lead extraction, and lets tenants bring their own key to use Sonnet or Opus. The weekly-question pipeline for pollitics.es uses Claude Sonnet 5.5 with server-side web search for research and Claude Opus 5.5 with JSON-schema structured output for drafting.

Do I need LangChain or another framework to build an agent with Claude or GPT?

No. A tool-use agent is a loop: call the model with tool definitions, execute any tool calls it returns, send the results back, and stop when it answers in text. Both official SDKs make that a few dozen lines, and both vendors now offer optional helpers (Anthropic's Tool Runner, OpenAI's Agents SDK). A framework can help with many providers or complex orchestration, but it also hides the provider-specific features, like cache breakpoints and server tools, that most of the cost and reliability wins come from.

Originally published on joancomadran.dev. I'm Joan, an AI engineer in Barcelona — work with me.

GPT-4o and GPT-4.1 Leave OpenAI's API on January 14, 2027. You Have 92 Days

Gabriel Anhaia — Wed, 14 Oct 2026 13:01:52 +0000

Book: Ship It — the pragmatic startup tech stack
Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
Me: xgabriel.com | GitHub

If the model string in your code starts with gpt-4o or gpt-4.1, it has an expiry date now. On October 14, 2026, OpenAI's deprecations page added an entry that reads: "On October 14, 2026, we notified developers using certain GPT-4 series models of their deprecation", with removal from the API on January 14, 2027.

That is 92 days from notice to shutdown. The replacement OpenAI names for every model on the list is gpt-6-luna.

If you shipped a classifier, an extractor or a support-ticket router on a small OpenAI model in the last two years, check which one. The small call behind a feature nobody has touched since launch keeps working until January 14. Then it stops.

What's on the list

The October 14 entry has four rows, all with the same shutdown date and the same replacement:

Model	Snapshot IDs	Replacement
GPT-4o	`gpt-4o-2024-08-06`, `gpt-4o-2024-11-20`	`gpt-6-luna`
GPT-4o mini	`gpt-4o-mini-2024-07-18`	`gpt-6-luna`
GPT-4.1	`gpt-4.1-2025-04-14`	`gpt-6-luna`
GPT-4.1 mini	`gpt-4.1-mini-2025-04-14`	`gpt-6-luna`

The entry adds one more sentence that matters if you trained anything: "Fine-tuned versions of these models follow the same shutdown schedule as their underlying base models." So a fine-tuned 4o mini goes dark on the same day.

The table lists dated snapshots, not the bare gpt-4o alias. The GPT-4o model page names gpt-4o-2024-08-06 as its default snapshot, and that snapshot is on the list. Don't assume the alias outlives it. Check the exact ID you call; the grep and API check below find it.

Two GPT-4 series snapshots were already on their way out before this notice. The same page lists gpt-4o-2024-05-13 and gpt-4.1-nano for shutdown on October 23, 2026, from an April 22 notice. If you pinned either of those, your deadline is nine days away, not 92.

The legacy GPT-4o audio and realtime models are not in this entry. They have their own dates, starting January 20, 2027.

Three months' notice, under a policy that lists six

The deprecations page has a section on notice periods. For generally available models it says: "At least 6 months." Specialized variants of those models get "At least 3 months." Preview models "may be retired with much shorter notice, such as 2 weeks." The whole list is introduced with "Unless safety or compliance concerns require a faster timeline", and in that case OpenAI says it "will provide as much notice as reasonably possible" (OpenAI).

October 14 to January 14 is three months. The October 14 entry doesn't say which category these snapshots fall under, and it gives no reason for the timeline. It doesn't link a migration guide either.

Compare the entry right below it. On October 1, OpenAI gave gpt-5.1 and gpt-5.3-codex a shutdown date of April 1, 2027, six months out, so the newer models got twice the runway (OpenAI).

If you run these models through Azure, your dates are not OpenAI's. Microsoft's model retirement schedule lists all five of these snapshots as retiring on April 14, 2027, and it keeps fine-tuned deployments running longer: until October 1, 2027 for gpt-4o and gpt-4o-mini, and until October 14, 2027 for gpt-4.1 and gpt-4.1-mini. That page was last updated in late September, before OpenAI's notice, so watch it for changes.

What changes when you move to gpt-6-luna

On price per token, Luna is cheaper than everything it replaces. From OpenAI's pricing page, Standard tier, per million tokens:

Model	Input	Output
`gpt-4o`	$2.50	$10.00
`gpt-4.1`	$2.00	$8.00
`gpt-4.1-mini`	$0.40	$1.60
`gpt-4o-mini`	$0.15	$0.60
`gpt-6-luna`	$0.10	$0.50

Per token is not per task, though. Three things on the Luna model page change how your existing calls behave:

It reasons by default. Reasoning is on at medium effort unless you set reasoning.effort. The levels run from none to max. A 4o mini classifier answered straight away. Luna at its default effort thinks first.
Tools prefer the Responses API. On Chat Completions, function calling works only when reasoning effort is none. For built-in tools, use the Responses API.
No fine-tuning. Luna doesn't support it. If your production model is a fine-tuned 4o mini, there is no fine-tuned Luna to move it to. OpenAI has restricted new fine-tuning jobs since May 2026, and existing customers lose the ability to create them on January 6, 2027.

Long prompts cost more too. Above 272K input tokens, Luna charges 2x for input and 1.5x for output, on the whole request (OpenAI).

For a fast, cheap call that used to go to 4o mini, the closest like-for-like starting point is Luna with reasoning off, through the OpenAI Node SDK:

import OpenAI from "openai";

const client = new OpenAI();

const res = await client.responses.create({
  model: "gpt-6-luna",
  reasoning: { effort: "none" },
  input: "Label this ticket: refund not received",
});

console.log(res.output_text);

Then run your eval set against it before you flip the switch. I haven't run Luna against a 4o mini workload myself, and OpenAI's notice makes no quality claim about the swap. If you have no eval set, the 92 days are the time to build one.

Find every call before January does

Start with your own code. git grep searches tracked files only, so it usually skips node_modules and build output:

git grep -nE "gpt-4(o|\.1)"

That pattern also matches the audio, realtime, TTS and transcribe variants and the two snapshots from the April notice, which have different dates, so read the hits rather than counting them. Then check the places grep can't see: environment variables, config services, feature flags and database rows that hold a model name.

Then ask the API. OpenAI says the List models endpoint now carries an optional shutdown_date field: "When present, this field contains the shutdown date as a YYYY-MM-DD string", or null if none is announced (OpenAI). With jq, this prints every model on your account that has one, soonest first:

curl -s https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | jq -r '.data[]
      | select(.shutdown_date != null)
      | "\(.shutdown_date)  \(.id)"' \
  | sort

Fail the build before the API does

The same field is also on the Retrieve a model endpoint (OpenAI), so a few lines of shell can fail a pipeline when the model you deploy with has a shutdown date:

#!/usr/bin/env bash
# Fail CI when the model we call has a shutdown date.
set -euo pipefail
model="${OPENAI_MODEL:?set OPENAI_MODEL}"
url="https://api.openai.com/v1/models/$model"

shutdown=$(curl -sSf "$url" \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | jq -r '.shutdown_date // empty')

if [ -n "$shutdown" ]; then
  echo "::error::$model shuts down on $shutdown"
  exit 1
fi
echo "$model: no shutdown date announced"

The ::error:: prefix is a GitHub Actions workflow command that shows up as an annotation on the run. Once the model is gone, curl -f fails on the error response and the script exits non-zero anyway. Set OPENAI_MODEL to the dated snapshot rather than the alias, since the deprecation table lists snapshots, or the check can pass on a model that is about to go.

Failing on any announced date is strict on purpose: your team hears about the next deprecation from a red build instead of an archived email. If that is too loud, compare the date against a window and only fail inside it.

Treat the model ID like a runtime version or a database engine, a dependency with a lifecycle you don't control. Keep it in one place in config, and keep an eval set that tells you in an afternoon whether the replacement holds up.

If this was useful

A model shutdown is one of those production chores nobody plans for until a vendor sets the date. Ship It is my book on everything between localhost and production for a small team: hosting, deploys, payments, auth, CI/CD and monitoring, so checks like the one above have somewhere to live.

I also build Hermes IDE, a free, source-available IDE that runs Claude Code, Codex and other command-line agents side by side, each in its own terminal and worktree, on macOS, Windows and Linux. Weigh that with the fact that it's mine. Download it or star it on GitHub.

Maths: OpenAI posted 722 AI proofs, 42% machine-checked

GetPack — Wed, 14 Oct 2026 07:35:14 +0000

First published in GetPack Magazine, sourced guides to use AI well as a student.

On October 6, 2026, OpenAI posted 722 mathematics manuscripts on GitHub, written by an internal model nobody can use. The next day, three were withdrawn: a sign error. Behind the row sits a question you meet in every problem set: at what point is a proof actually verified?

In short: the public repository openai/math holds 722 manuscripts grouped into 372 result families, using on average three hours of ChatGPT Pro thinking compute per result. On October 7, three were withdrawn after a sign error invalidated one and, by dependency, two others; 719 remain. The repository claims 42% of top-line results are formalized in Lean, but the term is defined nowhere and independent recounts land closer to 24% or 36%. For you, the interesting part is not the fight: it is learning to separate « this looks right » from « this has been checked ».

What OpenAI put online on October 6, 2026

The openai/math repository holds PDF manuscripts, Lean formalizations and abridged summaries of the model's reasoning. The README is blunt about the cost: « On average, each result used three hours of ChatGPT Pro thinking compute with that model. »

The model itself is not available. No public name, no way to test it, so no way to reproduce anything: you can read the proofs, you cannot replay the experiment.

The most discussed result concerns the quasi-Riemann hypothesis, a zero-free half-plane for every Dirichlet L-function. Nature notes, on the other hand, that the batch contains no solution to any of the five remaining Millennium Prize Problems.

Three manuscripts withdrawn the next day: one sign error

The repository changelog dates the operation to October 7, 2026. A sign error invalidates a stabilization-trace cancellation argument in « Algebraicity of Weil classes on split abelian eightfolds », posted on September 18. Two other manuscripts relied on that construction: they fall with it.

Retraction Watch laid out the details on October 8: three manuscripts withdrawn, fourteen revised, thirteen updated to cite the corrected versions. An OpenAI spokesperson says there that the company welcomes scrutiny from the mathematical community and commits to correcting errors promptly. Andrew Sutherland, of MIT, answers in the same piece: the withdrawals will be viewed positively, « but it will take a lot more than that to earn back the trust they have lost ».

Remember the mechanism, because it is universal: a sign error — the most ordinary mistake there is — at the bottom of a dependency chain, and three pieces of work collapse at once.

42%, 24% or 36%: what « formalized in Lean » actually means

Lean is a proof assistant: software that checks a formal proof really does follow from a formal statement, through a small trusted kernel. On that ground it is merciless. Mathematician Kevin Buzzard, quoted by Matt Baker of Georgia Tech, puts it in one line: « You cannot fool Lean; one learns this very early on. Lean will not accept proof by authority or proof by intimidation. »

But a formalization guarantees one thing only: that the formal proof matches the formal statement. It does not guarantee that this statement says the same thing as the English sentence in the manuscript. That is the faithfulness gap: a paper posted on arXiv in June 2026 notes that a formal statement « can typecheck and be provable, yet still encode a different theorem than the source intended ». Take « every continuous function on a compact set attains its maximum »: several Lean translations compile, but the one that drops the non-emptiness hypothesis becomes false on the empty set. Matt Baker, for his part, puts that risk below 1%.

Then there is the number. The README announces « ~42% top-line results formalized », meaning 300 out of 719. An analysis published by Pebblous shows three measures in circulation: 173 manuscripts out of 719 in the formalization catalogue, or 24%; 135 result families out of 372, or 36%; and the 42%, whose numerator of 300 « matches the length of no list this file holds », the term « top-line results » being defined nowhere. That numeric sentence appeared two days after release, replacing a much vaguer « Many, but not all, of the manuscripts have been formalized. »

In other words: even the verification rate needs verifying.

The response: AHM first, then Sophie Huiberts

On October 7, the Communications Working Group of the Association for Human Mathematics published a statement, reposted the same day on Terence Tao's blog « What's new ». Its most-quoted line: « Releasing over 700 files at once is not a demonstration of scholarship, but a demonstration of power. » The AHM, founded in mid-September 2026, calls on mathematicians to stop working with OpenAI.

That position is far from unanimous: the comments under the post are sharply split. Some reject the boycott, arguing that publishing full claimed proofs anyone can check is the most exposed position an author can take.

On October 12, Tao published a guest post on the same blog by mathematician Sophie Huiberts, « This is normal bad work ». Her charge sheet is precise: OpenAI « don't bother putting in appropriate attribution of ideas », they « salami-slice 372 results over 719 pdfs », their work « contains retraction-worthy errors », they promise code and fail to include it, and their proofs are « fiendishly hard to parse ». A telling detail: some results had already been found by ChatGPT users writing them up properly, and the bulk release takes the credit for that work away from them. Her thesis fits in the title: not an epistemic catastrophe, just ordinary bad work published without embarrassment.

September 2026: the 25 Fields medallists

The ground had been prepared. On September 11, 2026, 25 Fields medallists — among them Cédric Villani, Pierre-Louis Lions, Hugo Duminil-Copin, Pierre Deligne and Yu Deng — signed a piece in Le Monde titled « A Severe Misalignment of AI in Mathematics ». According to RTBF, they write that announcements arrive « in a rush, without leaving the time needed for rigorous writing-up », and that this « raises serious questions of attribution and plagiarism ».

Their core argument applies to you too: solving a problem is only a means to an end, and the end is understanding. Mass-producing results at a frantic pace risks, they write, destroying fertile ground instead of giving birth to new ideas.

The shock is real. In franceinfo on October 12, Hugo Duminil-Copin, Fields medallist in 2022, speaks of a « monumental shock » and says: « I even cried over it. » Cédric Villani sees « certainly the most radical change in mathematics in at least four centuries ». Ursula Martin, of Oxford, sums up the practical complaint for Nature: the release amounts to tossing the community a messy first draft and expecting it to clean up.

What this changes for you

You are not going to referee a proof about Dirichlet L-functions this term. But five reflexes transfer directly.

A proof that looks right can fall on a sign. What sank three OpenAI manuscripts was not an exotic concept, it was a sign error. When an AI hands you a nicely written solution, the question is not « does this look correct? » but « can I redo every step line by line? ».

Errors propagate. Two proofs fell because they depended on the first. If you build your dissertation on a result you never checked, you inherit its bugs.

« Verified » is not a word, it is a question. Verified by what, against what, covering what share of the work? The gap between 42%, 36% and 24% comes not from a lie but from three definitions of the numerator and the denominator. Faced with any percentage, ask what is being counted.

A preprint is not a peer-reviewed article. None of the 719 documents was refereed before publication. You can cite them, as long as you say what they are. Same rule for the arXiv, HAL or SSRN preprints in your bibliography.

Attribution is the whole story. The central complaint against OpenAI is that it does not cite prior work — exactly what you are asked to do in a dissertation. It is what separates a contribution from a file dump.

One last reflex, whatever tool you use: check your institution's rules on AI before relying on it for graded work, and state honestly what you used.

Our take

Both camps are right about different things, and that is what makes the debate confusing.

On the mathematics, something important happened. Matt Baker, who calls the release sloppy, still writes that « this appears to mark a watershed moment in the history of mathematics ». Dismissing that on principle would be a mistake.

On the method, the criticisms are solid, and they are not even about AI. Failing to cite, slicing one result across several PDFs, promising absent code, publishing 722 documents nobody has reviewed: these are craft failures you would hold against any human author.

What strikes us most is the 42% figure: added two days after release, with a numerator matching no list in the repository, and reprinted as fact by the whole press. A story about mathematical verification whose headline number is itself unverifiable.

For you, the conclusion is simple and a little reassuring. The value is no longer in producing an answer: a machine does that in three hours of compute. It is in the ability to review, to spot a sign error, to say where an idea came from and to explain why something is true. That is precisely what your exams measure.

FAQ

Did OpenAI solve the Riemann hypothesis?

No. The most discussed result concerns the quasi-Riemann hypothesis, a weaker statement. Nature notes that the October 6 batch contains no solution to any of the five remaining Millennium Prize Problems.

Can I cite one of these manuscripts in my dissertation?

Yes, as long as you say what it is: preprints that have not been peer-reviewed, produced by a non-public AI model, some withdrawn or corrected. Cite the version and its date, and flag the status of the document.

What is Lean, concretely?

A proof assistant: software that mechanically checks that a formal proof follows from a formal statement. Highly reliable on that narrow job, but it does not check that the formal statement faithfully translates the natural-language sentence in the paper.

Why do the figures range from 24% to 42%?

Because they count different things: 173 manuscripts out of 719 in the formalization catalogue gives 24%, 135 families out of 372 gives 36%, and OpenAI's 42% refers to « top-line results », a term the repository never defines.

Does this mean AI is bad at maths?

No, and it is rather the opposite that worries mathematicians. The complaint is not about the level of the results, but about how they were published: without attribution, without review, without code.

Sources

OpenAI engineering team leader arrested, accused of attempted wiretapping

Hacks.gr — Wed, 14 Oct 2026 04:01:32 +0000

A complaint in the case against former OpenAI engineering team lead Abdulrahman Alfozan describes a recording device found in a room used for confidential discussions, concealed in toilet paper and connected behind a television.

Alfozan was arrested and accused of using or trying to use a device to intercept spoken conversations; the allegations do not establish that any meeting was recorded.

Company employees discovered the device around Sept. 30 in an executive meeting room at OpenAI's San Francisco offices. According to the complaint, it had been placed there around Sept. 28. It was plugged into a USB port on the back of the television and hidden inside toilet paper.

The room was used for confidential discussions about the company's technology, business and strategy, such as research, product plans and business opportunities. Video from the offices reportedly shows Alfozan near the room on several dates before the device was discovered, even though he had no access or participation in the meetings.

According to the complaint, before the device was installed, Alfozan used a tool from his job to gather information about OpenAI's buildings and rooms, their capacity and usage schedules. He also collected data on executives' locations and their meetings with external partners.

From September 24 to 30, according to the complaint, questions were asked through a chatbot account associated with his wife about how a recording device could be built, customized, installed and tested. The questions also concerned its remote operation. Some related to continuous recording, wireless connection, live listening and SD card encryption. On September 27 and 28, questions were also asked about specific features of the device.

On October 5, Alfozan allegedly entered the room and looked behind the television. On the same day, he allegedly left a bag unattended in another room at OpenAI. According to the complaint, a second recording device, his wallet and his ID were found in the bag.

OpenAI said it used its own artificial intelligence systems to figure out what the device was and where it came from. It also said it has no evidence that Alfozan obtained or copied any of its model data, source code or customer information without permission.

The company told TechCrunch that the device used advanced encryption, could monitor audio, and transferred data in a way designed to evade detection.

If convicted, Alfozan faces up to five years in prison, a $250.000 fine and three years of post-release supervision.

Read the original English article on Hacks.gr

OpenAI engineer accused of hiding recording device in meeting room

Hacks.gr — Wed, 14 Oct 2026 03:25:32 +0000

A federal complaint alleges that former OpenAI engineer Abdulrahman Alfozan hid a recorder in a meeting room used for sensitive discussions.

Prosecutors say he queried AI and productivity tools about planning the alleged surveillance and used an internal OpenAI tool to ask about scheduled meetings.

The case is before a federal court; the allegations are not findings of guilt.

Abdulrahman Alfozan appeared in federal court in San Francisco on Tuesday. Prosecutors describe him as a 35-year-old Saudi national and permanent U.S. resident. He faces one count of using a device to eavesdrop on spoken conversations. If convicted, he could be sentenced to up to five years in prison.

OpenAI had hired him in July 2025 and fired him last Friday, the day he was arrested.

The device in the meeting room

According to the criminal complaint, Alfozan hid a recording device inside toilet paper and placed it behind a monitor. The device was plugged into a USB port on the back of a television.

The room was reserved only for executives and their assistants. It was used for internal meetings on leadership, research and product matters, as well as briefings with partners and government officials. According to the complaint, highly confidential information about research, products, business strategy and the company's relations with the government was often discussed.

The complaint states that the device was installed no later than September 28, 2026. OpenAI detected it on September 30, during a scan for hidden devices. The company said it was unable to read the data on the memory card because it was encrypted.

Prosecutors say that over several weeks, Alfozan asked an unnamed productivity tool and an artificial intelligence tool how to set up the monitoring. He also used an internal OpenAI tool to ask what meetings were scheduled in the room. According to prosecutors and court documents, he appears to have asked technical questions about covert recording through an AI tool account associated with his wife.

The second device in the bag

On October 5, OpenAI’s security team found a bag that Alfozan had left unattended in a printer area. Inside were personal items, including his wallet, and a second recording device. This one also had encrypted data.

Alfozan later told the company he had lost the bag and retrieved it from lost and found. He said a credit card, about $500 in cash, and two AirPods were missing, but he didn't mention the second device, which OpenAI security had removed.

FBI Director Kash Patel said Alfozan wanted to secretly record sensitive conversations about OpenAI's superintelligence technology. However, neither prosecutors nor the company have said what the motive might be.

OpenAI said it notified the FBI and linked the devices to Alfozan by examining conversations, security camera footage and his bag. As the investigation continued, it gradually restricted his access to company systems. The company also said it has no evidence that he improperly obtained or copied AI models, source code or customer data.

Read the original English article on Hacks.gr

Former OpenAI executive arrested in the US for espionage

Hacks.gr — Wed, 14 Oct 2026 02:29:29 +0000

A former OpenAI engineering leader, Abdulrahman Alfozan, has been arrested on espionage charges.

Investigators allege he planted hidden audio recording devices in company meeting rooms, an incident currently labeled by the U.S.

Department of Justice as a national security matter.

Notably, OpenAI utilized its own internal AI models to help link the hardware to the suspect.

Officials have confirmed that no evidence of stolen proprietary code, AI models, or customer data has surfaced to date.

How his action was revealed

The case began in late September 2026, when a recording device was found hidden behind a television in a conference room. The device had been placed there around September 28. OpenAI used its own artificial intelligence systems to analyze the device and link it to Alfozan, who was an engineering executive at the company.

Surveillance and arrest

After the initial discovery, security officials placed the area under surveillance. On October 5, camera footage captured Alfozan checking the location of the device. On the same day, authorities found a second recording device in a bag in his possession. In addition, it emerged that his wife’s ChatGPT account had been used for searches related to the operation of recording devices.

Is there a risk to the data?

Despite the seriousness of the charges, there is no evidence so far that Alfozan managed to steal AI models, source code, or personal customer data. Alfozan, who is a Saudi national, has already been fired from OpenAI. If convicted, he faces up to five years in prison and a $250.000 fine.

Read the original English article on Hacks.gr

OpenAI engineer arrested for illegally recording conversations at company offices

Hacks.gr — Wed, 14 Oct 2026 01:57:34 +0000

OpenAI recently identified and terminated an engineer who allegedly planted recording devices in a corporate conference room.

The internal investigation utilized OpenAI's own AI models to attribute the actions to the suspect, who reportedly leveraged a chatbot to learn how to build and camouflage the recording hardware.

The incident resulted in arrest, with the suspect facing charges that could carry significant fines and prison time.

How the device was revealed

On September 30, 2026, OpenAI discovered an audio recording device hidden in an executive meeting room. The device was connected to a television and covered with toilet paper to make it less visible. The company said it used its own artificial intelligence models to analyze the data and identify the perpetrator.

According to the information, Alfozan allegedly used a chatbot to ask for guidance on how to build and hide the device. A few days later, on October 5, an employee's bag was found elsewhere in the building, containing his personal belongings and a second recording device.

OpenAI's stance

The company confirmed the immediate firing of the engineer once his identification was completed. At the same time, OpenAI said that, based on the evidence collected so far, there is no indication that the perpetrator managed to leak customer data, its program code, or other sensitive information.

Alfozan now faces criminal charges. If convicted, he could face up to five years in prison and a fine of up to $250.000.

Read the original English article on Hacks.gr

Generate images and video with the OpenAI SDK — no OpenAI key required

livepairai — Wed, 14 Oct 2026 01:41:37 +0000

The OpenAI Python SDK is mostly a base_url and an api_key. If an API speaks the same shapes — /images/generations, /chat/completions, /videos — the SDK you already have installed works against it.

LivePair exposes exactly that surface: an OpenAI-compatible endpoint covering 60+ image and video generation models (Seedream, Seedance, Wan, Qwen Image, Ideogram, Minimax) plus a set of chat models. One base_url change, and client.images.generate() produces media from models that don't exist on OpenAI.

Disclosure: I work on LivePair. Everything below is runnable against the live API — the catalog, prices, and shapes are public at GET /v1/agent/models.

Setup

pip install openai requests

Grab a key: sign up at livepairai.com → Settings → API keys → lp_…. Billing is a prepaid credit balance — each call debits the per-model price, no subscription.

from openai import OpenAI

client = OpenAI(
    base_url="https://livepairai.com/v1/agent",
    api_key="lp_...",          # sent as a Bearer token, so the stock SDK works
)

Images — `client.images.generate` just works

img = client.images.generate(
    model="seedream-5.0",
    prompt="a lighthouse on a cliff at dusk, cinematic lighting",
    size="1024x1024",
)
print(img.data[0].url)

That's the unmodified OpenAI call. The catalog decides what model can be — seedream-5.0, qwen-image-3, ideogram-3-turbo, and so on. size accepts the standard 1024x1024 / 1792x1024 / 1024x1792 values and maps onto each model's aspect-ratio ladder.

Chat — `client.chat.completions.create`

r = client.chat.completions.create(
    model="deepseek/deepseek-v4.1-flash",
    messages=[{"role": "user", "content": "Explain the CAP theorem in two sentences."}],
    max_tokens=256,
)
print(r.choices[0].message.content)

Video — Sora-shaped, poll-then-download

The video endpoint mirrors OpenAI's Videos API shape: POST /videos returns a job immediately, GET /videos/{id} polls status, GET /videos/{id}/content streams the mp4. Newer SDK releases have a client.videos namespace; here's the plain-HTTP version so the contract is visible:

import time, requests

H = {"Authorization": "Bearer lp_...", "Content-Type": "application/json"}
BASE = "https://livepairai.com/v1/agent"

job = requests.post(f"{BASE}/videos", headers=H, json={
    "model": "wan-3.0-t2v",
    "prompt": "drone shot over a foggy forest at dawn, slow push-in",
    "size": "1280x720",   # 16:9; 720x1280 → 9:16
    "seconds": "5",
}).json()

vid = job["id"]
while True:
    v = requests.get(f"{BASE}/videos/{vid}", headers=H).json()
    if v["status"] in ("completed", "failed"):
        break
    time.sleep(5)

if v["status"] == "completed":
    mp4 = requests.get(f"{BASE}/videos/{vid}/content", headers=H)  # 302 → media URL
    open("out.mp4", "wb").write(mp4.content)

Prices are data, not a pricing page

GET /v1/agent/models returns every model with a priceUsd field — the exact per-call debit before you make it:

models = requests.get(f"{BASE}/models").json()
for m in models["models"]:
    print(m["id"], m["mode"], m["priceUsd"])

GET /v1/agent/balance shows your prepaid balance and recent ledger entries.

Why bother

The useful part isn't another API key — it's that image gen, video gen, and chat land on the same OpenAI surface you already integrate, priced per call against a balance you can watch. For pipelines that need several model families (compare outputs, fallback chains, cost routing), switching models is a string, not a new provider account.

There's also a no-account path if you're wiring autonomous agents: the same endpoints answer 402 Payment Required and settle per call in USDC via x402, so a client that can sign a payment header can call without any signup at all.

Gotchas

n > 1 isn't supported on image generation — loop instead.
Video is async by design; budget ~1–3 min per clip depending on model.
A generation that fails provider-side refunds to the balance automatically.
Results aren't published anywhere and are deleted after 48h — save the bytes.

Docs: livepairai.com/docs, machine-readable spec at /v1/agent/openapi.json, MCP server for agent clients under /mcp.