An inbox full of AI links looks like an editorial opportunity until you have to read every one. Some are genuine launches; others repackage an existing feature or announce something nobody can use yet. On October 22, 2026, OpenAI said its Decisions API had reached general availability. For an independent publisher, the promising use is to prioritize which signals a person should check today, not to let a model publish unverified claims.

OpenAI's API changelog confirms the date and updates: shared-input caching, images inside individual question instructions, structured evidence via input_json, and up to 400 questions per request rather than 200 in public beta. The Decisions guide says gpt-6-luna is currently the only supported model. The endpoint returns typed answers: a category choice, a true-or-false assessment, or a score against a rubric. It does not independently establish whether an announcement is factual.

What changes for an AI news radar?

Give each incoming signal one of three next steps: review for a potential story, test before writing, or skip for now. Supply the announcement text and ask a choice question. The response can contain a selected option, probabilities, and confidence. That is enough to build a small review queue. A human still needs to open the primary source and check the date, availability, limitations, and relevance to builders or creators. High confidence about promotional copy is not evidence that the promotion is true.

General availability makes this worth revisiting if your team avoided building on the beta. The new input_json content part also lets you pass a structured record containing a title, date, and product rather than flattening it into a paragraph. Images in per-question instructions could help compare candidate covers with a shared reference. Those are product capabilities, not measurements of editorial accuracy. OpenAI says Decisions can answer these kinds of questions roughly ten times faster than Responses; treat that as a provider claim and measure your own end-to-end workflow before promising a team-wide gain.

A small example you can adapt

This request follows the shape in the official guide. It needs a valid API key in OPENAI_API_KEY and can incur charges. Replace input with an actual signal you saved along with its original URL. This is a documented example; we did not run it against a private paid account.

curl https://api.openai.com/v1/decisions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gpt-6-luna",
    "input": "A provider announces a new API for classifying text and images. Its official changelog says it became generally available on October 22, 2026.",
    "questions": [{
      "type": "choice",
      "name": "next_review_step",
      "instructions": "Choose the next step for a practical AI editor. Use only the supplied text; do not claim to have verified external facts.",
      "choices": [
        {"value": "review", "description": "A concrete change worth checking against the primary source today."},
        {"value": "test", "description": "Usefulness depends on a reproducible test before writing."},
        {"value": "skip", "description": "No clear reader decision changes, or essential details are missing."}
      ]
    }]
  }'

Never connect this answer directly to published=true. Use it to create a review task that retains the original text, URL, and timestamp. Send ambiguous or low-confidence results to a person. Set thresholds from your own labeled examples; there is no universal cutoff. The model sees the evidence you provide and may confidently classify a polished but false claim.

How to find out whether it helps

1. Build a small sample. Collect 30 recent signals: useful releases, repeated announcements, and vague claims. Save each primary link and your editorial decision before calling the API.
2. Compare decisions. Run the same question on all 30 and count false positives (weak stories sent to review) and false negatives (valuable news sent to skip). Audit false negatives carefully; missing a meaningful launch can cost more than reviewing an extra link.
3. Measure the whole process. Track time from link received to human decision, cost per signal, and the share that becomes a real article or experiment. Endpoint latency alone is not editorial value.
4. Keep a human publication gate. Require a primary link, date, access details, limitations, a reproducible example, and an assigned cover before an article goes live. Decisions may prioritize the queue; it does not own factual or editorial responsibility.

The API also supports predicate and score questions. Start with one routing question so you can evaluate it clearly. If your application needs a long written summary or an object matching your own JSON schema, OpenAI recommends Structured Outputs with the Responses API for that job. A classification endpoint should not be stretched into an article writer.

Access and limits: OpenAI lists Decisions as generally available, supports gpt-6-luna today, and documents a maximum of 400 questions per request. Current prices and regional terms are in the official guide and may change. We have not measured latency, accuracy, or cost on SoyJB data. The next useful experiment is a week of real signals labeled by an editor before automating any routing, let alone publication.