Recommendation for Extraction

Structured Data Extraction

Our top recommendation for Structured Data Extraction, based on the public evidence we track, is OpenAI: GPT-5.6 Luna.[1][2][3][4] Use for high-volume extraction pipelines where cost and latency matter: it hit 24/24 valid JSON outputs in a strict router-prompt battery at 83% lower cost and 21% faster median latency than Haiku 4.5. Watch out: Watch for ordinal turn-tracking failures in multi-step workflows: switching from Gemini Flash to Luna broke 3 real end-to-end debate-coordinator tests due to unreliable step sequencing. Anthropic: Claude Sonnet 4.6 is the next-ranked alternative. Use when your orchestration layer requires declared structured-output features: Sonnet 4.6 is the sole Anthropic model in the Dify plugin with this flag, enabling native JSON schema handling.

About this recommendation

Updated
Sep 6, 2026
Evidence through
Sep 6, 2026
Sources
18
Revision
v60

Decision audit

Why this result

Inspect the inputs and the computed order behind the recommendation.

Models screened

20

live candidates

Evaluation feeds

6

task-weighted

Winner coverage

42%

intended feed weight

Largest provider share

4 of 8

Anthropic

Established source breadth. 15 citation families and 8 practitioner families support the top result; 2 cautionary threads is retained. The largest citation family contributes 16%.

Sources evaluated

The task sets these weights before any model is scored.

winner: GPT-5.6 Luna
Evaluation feedWeightWinner resultField measured
Structured-output evalunavailable
40%
feed unavailable0/20
LiveBench Data Analysis
20%
#1517/20
Berkeley Function Calling
15%
not measured4/20
LMArena Text
10%
#3819/20
price weight
10%
100/10020/20
OpenRouter usage
5%
99/10020/20

Provider concentration

Each exact model is scored separately; provider identity is not a ranking input.

Anthropic50%
  • Anthropic4 models
  • OpenAI2 models
  • Meta1 model
  • Z.ai1 model

Decision table

Every published model is shown in computed order. Practitioner sources are distinct community threads, not the citations repeated in the prose below.

RankModelRelative scoreCoveragePractitioner evidenceStrongest measured reason
01GPT-5.6 LunaOpenAI
65
42%8 threads · 8 families · 2 cautions#15 LiveBench Data Analysis · #38 LMArena Text
02Claude Sonnet 4.6Anthropic
59
42%5 threads · 4 families · 3 cautions#16 LiveBench Data Analysis · #22 LMArena Text
03GPT-5.6 SolOpenAI
58
42%1 threads · 1 families · 1 cautions#4 LiveBench Data Analysis · #12 LMArena Text
04Claude Fable 5Anthropic
58
42%2 threads · 1 families · 2 cautions#1 LMArena Text · #2 LiveBench Data Analysis
05GLM 5.2Z.ai
57
42%2 threads · 2 families · 0 cautions#22 LMArena Text · #25 LiveBench Data Analysis
06Muse Spark 1.2Meta
56
42%1 threads · 1 families · 0 cautions#5 LMArena Text · #18 LiveBench Data Analysis
07Claude Sonnet 4.5Anthropic
54
38%2 threads · 2 families · 1 cautions#2 Berkeley Function Calling · #35 LMArena Text
08Claude Opus 4.6Anthropic
54
42%no linked practitioner threads#2 LMArena Text · #36 LiveBench Data Analysis

Relative score combines normalized benchmark quality and signal coverage; independent practitioner evidence and freshness are bounded tie-breakers. It is an ordering score, not an absolute quality percentage. The writing model receives this order and cannot change it.

  1. GPT-5.6 Luna delivers validated JSON in 24/24 strict fixture calls with 21/24 accuracy.

    Best when: Use for high-volume extraction pipelines where cost and latency matter: it hit 24/24 valid JSON outputs in a strict router-prompt battery at 83% lower cost and 21% faster median latency than Haiku 4.5.

    Tips

    • Use for high-volume extraction pipelines where cost and latency matter: it hit 24/24 valid JSON outputs in a strict router-prompt battery at 83% lower cost and 21% faster median latency than Haiku 4.5.
      Source 1
      Parent epic: #6842 ## Context Small screening runs are promising but not sufficient for provider decisions: - Exact router-prompt battery, 24 calls/model: Haiku 4.5 and GPT-5.6 Luna both produced valid JSON 24/24 and scored 21/24 against the strict fixture. Luna was about 83% cheaper and 21% faster at median latency. - Full-prompt Gemini 3.7 Flash screen: useful visible answers in 10/12 cases; two malformed function-call failures mapped to Anthropic-specific orchestration. - Production comparis…
    • Deploy as a fallback for unreliable free tiers: production teams automatically escalate to Luna when Nemotron 3 Ultra hits rate limits, with full backlog processing costing approximately $4.
      Source 5
      > *This was generated by AI during triage.* ## Parent #205 ## What to build A client module that takes document text and returns validated extraction records conforming to the schema in `docs/protocols/extraction-schema-by-document-type.md`. Two models: **Nemotron 3 Ultra (free)** as default, **GPT-5.6-Luna (~$4 for the full backlog)** as automatic fallback on rate-limit or unavailability. Via OpenRouter. Four things that already bit during evaluation and must be handled: 1. **Retry with backof…

    Watch out for

    • Watch for ordinal turn-tracking failures in multi-step workflows: switching from Gemini Flash to Luna broke 3 real end-to-end debate-coordinator tests due to unreliable step sequencing.
      Source 2
      ## Background While implementing #14 (renaming the Gemini-branded OpenRouter node), changing `OPENROUTER_MODEL`'s default from `google/gemini-3.5-flash-lite` to `openai/gpt-5.6-luna` broke 3 existing real end-to-end debate-coordinator tests. Investigation (running the real debate flow manually, see PR history for tickets #15/#16) found two distinct behavior differences from the prior default: 1. **Ordinal turn-tracking is unreliable.** Given a topic instructing "Step 1 (now)... Step 2 (on your…
    • Account for judge skew when evaluating outputs: Luna promotes borderline citations to explicit status 63% versus 27% in reverse, inflating strict-match scores in comparative benchmarks.
      Source 6
      ## Amendment (from the parallel 70B session's findings) Two corrections that affect this spec's validity, both measured rather than assumed. **1. Judge skew is real and directional — comparisons must be Luna-vs-Luna.** Comparing gpt-5.5 and gpt-5.6-luna judgments over the same stored 70B generations, disagreements are asymmetric: 63 hedged→explicit versus 27 explicit→hedged. Luna promotes borderline citations to `explicit`, inflating `v_strict`. Observed consequence: the speech-act run's author…
  2. Claude Sonnet 4.6 is the only Anthropic model in its plugin with declared structured-output support, enabling native JSON schema paths in orchestration tools.

    Best when: Use when your orchestration layer requires declared structured-output features: Sonnet 4.6 is the sole Anthropic model in the Dify plugin with this flag, enabling native JSON schema handling.

    Tips

    • Use when your orchestration layer requires declared structured-output features: Sonnet 4.6 is the sole Anthropic model in the Dify plugin with this flag, enabling native JSON schema handling.
      Source 3
      Hi @Mabdurahman68! I'm [Dosu](https://go.dosu.dev/dosubot) and I'm helping the Dify team. Your analysis is confirmed by the code. `claude-sonnet-4-6.yaml` is the only model file in the Anthropic plugin that declares `structured-output` in its features list [[1]](https://github.com/langgenius/dify-official-plugins/blob/93f1deb4fa4d06fcf81f7843fd55a7fbd6ce2b27/models/anthropic/models/llm/claude-sonnet-4-6.yaml#L5-L11), while `claude-sonnet-4-5-20250929.yaml` and other models do not [[2]](https://…
      dosubot[bot]Open original ↗
      Source 4
      Concrete instance filed separately: langgenius/dify-official-plugins#3671 `claude-sonnet-4-6` in `langgenius/anthropic` v0.3.26 declares `structured-output` in its model YAML while `models/llm/llm.py` contains no handling for it — zero matches for `json_schema`, `output_format`, `structured`, or `structured-outputs-2025-11-13`. That is what makes the branch above observable today: the declaration is sufficient to take the native path, the plugin never reads the schema, and the fallback has alre…
      Mabdurahman68Open original ↗
    • Deploy for complex analysis workflows requiring evidence-backed reasoning: the model powers a single-call analysis pipeline that reasons backwards from file state to user intent with structured outputs for summary, hypothesis, ruled_out, working_set, and next_step.
      Source 7
      ## What `src/analyze.ts` — the single network call in the entire tool. Takes a `CapturedState`, sends it to `claude-sonnet-4-6`, and returns an `Analysis`: `summary`, `hypothesis`, `ruled_out[]`, `working_set[]`, `next_step`. ## Why This is the point of the project. Everything else is plumbing around one question: *why* were those files open? **The prompt is the product.** It explicitly instructs the model to reason backwards from evidence to intent, and tells it that a mechanical description o…

    Watch out for

    • Verify your plugin version actually implements the declared feature: the structured-output declaration exists in YAML but the plugin's Python handler contains zero matches for json_schema, output_format, or structured handling, meaning the native path may not materialize.
      Source 4
      Concrete instance filed separately: langgenius/dify-official-plugins#3671 `claude-sonnet-4-6` in `langgenius/anthropic` v0.3.26 declares `structured-output` in its model YAML while `models/llm/llm.py` contains no handling for it — zero matches for `json_schema`, `output_format`, `structured`, or `structured-outputs-2025-11-13`. That is what makes the branch above observable today: the declaration is sufficient to take the native path, the plugin never reads the schema, and the fallback has alre…
      Mabdurahman68Open original ↗
  3. GPT-5.6 Sol ranks #5 on LiveBench Data Analysis with 79.84% accuracy on table joining and reformatting tasks, though teams are actively migrating away to Luna for unified pipelines.

    Best when: Use for data-heavy extraction involving table manipulation: it scores 79.84% on LiveBench Data Analysis (#5 of 52), covering table joining and reformatting tasks that often precede JSON serialization.

    Tips

    • Use for data-heavy extraction involving table manipulation: it scores 79.84% on LiveBench Data Analysis (#5 of 52), covering table joining and reformatting tasks that often precede JSON serialization.
      Source 8
      Scores 79.84% on LiveBench Data Analysis (#5 of 52), including table joining and reformatting tasks.
      LiveBench Data AnalysisOpen original ↗

    Watch out for

    • Avoid starting new projects on Sol: multiple production teams have deprecated it in favor of GPT-5.6 Luna High for all structured output calls, removing automatic routing and fallback logic entirely.
      Source 9
      ## 概要 本リポジトリで行うすべての OpenAI Responses API 呼び出しを、次の固定構成へ全面移行する。 `gpt-5-mini`、GPT-5.4 系、GPT-5.5 系、GPT-5.6 Sol、GPT-5.6 Terraを含む旧構成・代替モデル・フォールバックモデルは今後使用しない。 モデルの自動ルーティング、用途別モデル切り替え、失敗時の上位モデルへのエスカレーションも導入しない。通常計画、低確信度時の確認、障壁通知、失敗後の再計画を含め、LLMを呼ぶ全経路を GPT-5.6 Luna High に統一する。 --- ## 決定事項 - 採用モデルIDは `gpt-5.6-luna` とする。 - 推論強度は常に `high` とする。 - `reasoning.effort` を省略してAPI既定値へ委ねない。 - `gpt-5.6` エイリアスは Sol を指すため使用しない。 - `text.verbosity` は `low` を標準とする。構造化出力に必要なフィールドはJSON Schemaで担保する。 - `reasoning.mode: pro`、…
      stillshore-chirpOpen original ↗
  4. Claude Fable 5 leads LMArena overall rankings and scores 80.54% on LiveBench Data Analysis.

    Best when: Use for data analysis extraction where human preference alignment matters: it ranks #1 on LMArena overall (Elo 1507) and scores 80.54% on LiveBench Data Analysis (#3 of 52) for table tasks.

    Tips

    • Use for data analysis extraction where human preference alignment matters: it ranks #1 on LMArena overall (Elo 1507) and scores 80.54% on LiveBench Data Analysis (#3 of 52) for table tasks.
      Source 10
      Ranks #1 of 144 on LMArena's overall text arena (Elo 1507), based on blind human preference votes.
      LMArena text arenaOpen original ↗
      Source 11
      Scores 80.54% on LiveBench Data Analysis (#3 of 52), including table joining and reformatting tasks.
      LiveBench Data AnalysisOpen original ↗

    Watch out for

    • Do not use for biomedical or chemistry extraction: it refuses the majority of questions in LifeSciBench Gold, GeneBench Pro, and MedChemBench evaluations.
      Source 12
      "Claude Fable 5 and 5.1 are not included in LifeSciBench Gold v1, GeneBench Pro v13, and MedChemBench because they refuse the majority of questions in these evaluations.12" Sounds about right. Alignment is important, but also being able to do mundane tasks is important too.
    • Find an alternative for API-chain workflows: unlike earlier Opus versions, Fable 5 does not support structured outputs, breaking reliable pass-through to downstream APIs and libraries.
      Source 13
      I dont get why Opus 4.7, 4.8, and now Fable all stopped supporting structured outputs? Does no one else care about that? I find it incredibly useful to reliably pass LLM output directly to other APIs libraries
  5. GLM 5.2 is an open-weight option that parsed 4/4 real resume-to-JD extraction tasks in production trials, though no structured-output-specific benchmarks exist.

    Best when: Use as an open-weight alternative for document parsing pipelines: in live /resume route trials with real prompts and rubrics, it parsed 4/4 outputs across two job descriptions versus Claude's comparable results.

    Tips

    • Use as an open-weight alternative for document parsing pipelines: in live /resume route trials with real prompts and rubrics, it parsed 4/4 outputs across two job descriptions versus Claude's comparable results.
      Source 14
      Filed from a job-hunt-agent session (per repo-boundary convention: JHA sessions file issues rather than modify this repo). Four items, all settled with the owner on 2026-07-29. ## 1. Railway prod env — model switch (no code) Rationale — best-of-2 trials through the live `/resume` route (real prompt, thoughts enrichment, rubric) on two real JDs from the 2026-07-28 shortlist: | Model | Tabs JD | ExpertVoice JD | Parses | |---|---|---|---| | z-ai/glm-5.2 | **4.11 ✓** | **4.29 ✓** | 4/4 | | anthrop…
  6. Muse Spark 1.2 serves as a second-stage validator in production extraction pipelines, catching list-form omissions and weakened statements that primary extraction misses.

    Best when: Use as a validation layer for complex document extraction: in a two-stage pipeline, it scans source text for list-form or named-property omissions missed by primary extraction, then corrects weakened statements against original text verbatim.

    Tips

    • Use as a validation layer for complex document extraction: in a two-stage pipeline, it scans source text for list-form or named-property omissions missed by primary extraction, then corrects weakened statements against original text verbatim.
      Source 15
      ## Problem Statement 当前 Entry Module 单阶段提取在 5 案例上均值 ~36.2(Sol 等效),距 flawless 档(≥40)差 4 分。剩余扣分第一来源是漏提取与陈述弱化:Skein1 的函子公理清单、RT 的 handle-slide 命名性质等以 prose 清单/命名性质形式存在的内容被跳过;部分已提取条目的平衡张量积记号被弱化、或幻觉出原文没有的边界条件。连续 4 个提示词单变量实验(v1.32–1.35)证明在同一容量内加规则只会搬分数,净零。 ## Solution 在现有工作流(MinerU → v1.31 提取 → 确定性合并 → 产物)后新增第二阶段:用 muse-spark-1.2 对初版产物做校验补漏。阶段二输入为初版产物 + 源文本全文,仅做两件事:1) 扫描源文本中以清单/命名性质形式存在但被初版遗漏的条目,补 1–3 条;2) 逐条比对初版中被评委判为弱化的陈述与源文本原文,逐字订正。不改提示词,不改窗口。 ## User Stories 1. As a benchmark operator, I want the…
    • Deploy for data analysis preprocessing: it scores 76.46% on LiveBench Data Analysis (#21 of 52) for table joining and reformatting tasks.
      Source 16
      Scores 76.46% on LiveBench Data Analysis (#21 of 52), including table joining and reformatting tasks.
      LiveBench Data AnalysisOpen original ↗
  7. Claude Sonnet 4.5 scores 73.24% on BFCL tool-calling benchmarks but lacks declared structured-output support in orchestration plugins, requiring strict mode enforcement for type guarantees.

    Best when: Use for multi-turn tool calling workflows: it ranks #2 on BFCL overall with strong performance on format-sensitive tool calls, though latency averages 4.31s.

    Tips

    • Use for multi-turn tool calling workflows: it ranks #2 on BFCL overall with strong performance on format-sensitive tool calls, though latency averages 4.31s.
      Source 17
      Scores 73.24% overall on BFCL (#2 of 32), measuring single-turn, multi-turn, web-search, memory, hallucination, and format-sensitive tool calling; mean latency was 4.31s.
      Berkeley Function-Calling LeaderboardOpen original ↗

    Watch out for

    • Always enable strict mode on tool schemas: without strict: true, Bedrock Converse returns type violations like string instead of array for sections, causing PageDecodeError in production.
      Source 18
      ## 背景 #111 で経路 B の応答を tool use で受け取るようにしたが、2026-08-22 23:09 の再投入 (2608.17950v1) で 12 ページ目がモデルの出力 `sections` が配列ではなく文字列で返り、`PageDecodeError` になった (#113 の再試行でも同じ)。 tool use の `inputSchema` は `strict` を付けないと型を保証しない。公式ドキュメントは「strict なしでは型の不一致や必須欠落が起こり得る」と述べ、解決策として `strict: true` (constrained decoding) を提示している。 Claude Sonnet 4.5 は Bedrock Converse (`bedrock-runtime`、cross-region inference 含む) で対象。 - [ToolSpecification API Reference](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime…
    • Do not expect native structured-output paths: unlike Sonnet 4.6, the 4.5 model file lacks the structured-output feature declaration, forcing fallback handling in orchestration layers.
      Source 3
      Hi @Mabdurahman68! I'm [Dosu](https://go.dosu.dev/dosubot) and I'm helping the Dify team. Your analysis is confirmed by the code. `claude-sonnet-4-6.yaml` is the only model file in the Anthropic plugin that declares `structured-output` in its features list [[1]](https://github.com/langgenius/dify-official-plugins/blob/93f1deb4fa4d06fcf81f7843fd55a7fbd6ce2b27/models/anthropic/models/llm/claude-sonnet-4-6.yaml#L5-L11), while `claude-sonnet-4-5-20250929.yaml` and other models do not [[2]](https://…
      dosubot[bot]Open original ↗
  8. Anthropic: Claude Opus 4.6 ranks #2 of 144 on LMArena's overall text arena (Elo 1505), based on blind human preference votes.

    Best when: Consider only after reviewing the cited caution.

Frequently asked

What is the top-ranked model for Structured Data Extraction?
OpenAI: GPT-5.6 Luna ranks first in the current evidence-weighted comparison. Use for high-volume extraction pipelines where cost and latency matter: it hit 24/24 valid JSON outputs in a strict router-prompt battery at 83% lower cost and 21% faster median latency than Haiku 4.5.[1]
What should I watch out for with OpenAI: GPT-5.6 Luna?
Watch for ordinal turn-tracking failures in multi-step workflows: switching from Gemini Flash to Luna broke 3 real end-to-end debate-coordinator tests due to unreliable step sequencing.[2]
What is an alternative to OpenAI: GPT-5.6 Luna?
Anthropic: Claude Sonnet 4.6 is the next-ranked option. Use when your orchestration layer requires declared structured-output features: Sonnet 4.6 is the sole Anthropic model in the Dify plugin with this flag, enabling native JSON schema handling.[3][4]

Sources

  1. 1

    Parent epic: #6842 ## Context Small screening runs are promising but not sufficient for provider decisions: - Exact router-prompt battery, 24 calls/model: Haiku 4.5 and GPT-5.6 Luna both produced valid JSON 24/24 and scored 21/24 against the strict fixture. Luna was about 83% cheaper and 21% faster at median latency. - Full-prompt Gemini 3.7 Flash screen: useful visible answers in 10/12 cases; two malformed function-call failures mapped to Anthropic-specific orchestration. - Production comparis…

    bokelley · GitHub · Aug 25, 2026
  2. 2

    ## Background While implementing #14 (renaming the Gemini-branded OpenRouter node), changing `OPENROUTER_MODEL`'s default from `google/gemini-3.5-flash-lite` to `openai/gpt-5.6-luna` broke 3 existing real end-to-end debate-coordinator tests. Investigation (running the real debate flow manually, see PR history for tickets #15/#16) found two distinct behavior differences from the prior default: 1. **Ordinal turn-tracking is unreliable.** Given a topic instructing "Step 1 (now)... Step 2 (on your…

    Weilun2022 · GitHub · Jul 28, 2026
  3. 3

    Hi @Mabdurahman68! I'm [Dosu](https://go.dosu.dev/dosubot) and I'm helping the Dify team. Your analysis is confirmed by the code. `claude-sonnet-4-6.yaml` is the only model file in the Anthropic plugin that declares `structured-output` in its features list [[1]](https://github.com/langgenius/dify-official-plugins/blob/93f1deb4fa4d06fcf81f7843fd55a7fbd6ce2b27/models/anthropic/models/llm/claude-sonnet-4-6.yaml#L5-L11), while `claude-sonnet-4-5-20250929.yaml` and other models do not [[2]](https://…

    dosubot[bot] · GitHub · Aug 18, 2026
  4. 4

    Concrete instance filed separately: langgenius/dify-official-plugins#3671 `claude-sonnet-4-6` in `langgenius/anthropic` v0.3.26 declares `structured-output` in its model YAML while `models/llm/llm.py` contains no handling for it — zero matches for `json_schema`, `output_format`, `structured`, or `structured-outputs-2025-11-13`. That is what makes the branch above observable today: the declaration is sufficient to take the native path, the plugin never reads the schema, and the fallback has alre…

    Mabdurahman68 · GitHub · Aug 18, 2026
  5. 5

    > *This was generated by AI during triage.* ## Parent #205 ## What to build A client module that takes document text and returns validated extraction records conforming to the schema in `docs/protocols/extraction-schema-by-document-type.md`. Two models: **Nemotron 3 Ultra (free)** as default, **GPT-5.6-Luna (~$4 for the full backlog)** as automatic fallback on rate-limit or unavailability. Via OpenRouter. Four things that already bit during evaluation and must be handled: 1. **Retry with backof…

    alexwolson · GitHub · Aug 6, 2026
  6. 6

    ## Amendment (from the parallel 70B session's findings) Two corrections that affect this spec's validity, both measured rather than assumed. **1. Judge skew is real and directional — comparisons must be Luna-vs-Luna.** Comparing gpt-5.5 and gpt-5.6-luna judgments over the same stored 70B generations, disagreements are asymmetric: 63 hedged→explicit versus 27 explicit→hedged. Luna promotes borderline citations to `explicit`, inflating `v_strict`. Observed consequence: the speech-act run's author…

    redagavin · GitHub · Jul 29, 2026
  7. 7

    ## What `src/analyze.ts` — the single network call in the entire tool. Takes a `CapturedState`, sends it to `claude-sonnet-4-6`, and returns an `Analysis`: `summary`, `hypothesis`, `ruled_out[]`, `working_set[]`, `next_step`. ## Why This is the point of the project. Everything else is plumbing around one question: *why* were those files open? **The prompt is the product.** It explicitly instructs the model to reason backwards from evidence to intent, and tells it that a mechanical description o…

    kishuxz · GitHub · Aug 17, 2026
  8. 8

    Scores 79.84% on LiveBench Data Analysis (#5 of 52), including table joining and reformatting tasks.

    LiveBench Data Analysis · Benchmark · Jun 25, 2026
  9. 9

    ## 概要 本リポジトリで行うすべての OpenAI Responses API 呼び出しを、次の固定構成へ全面移行する。 `gpt-5-mini`、GPT-5.4 系、GPT-5.5 系、GPT-5.6 Sol、GPT-5.6 Terraを含む旧構成・代替モデル・フォールバックモデルは今後使用しない。 モデルの自動ルーティング、用途別モデル切り替え、失敗時の上位モデルへのエスカレーションも導入しない。通常計画、低確信度時の確認、障壁通知、失敗後の再計画を含め、LLMを呼ぶ全経路を GPT-5.6 Luna High に統一する。 --- ## 決定事項 - 採用モデルIDは `gpt-5.6-luna` とする。 - 推論強度は常に `high` とする。 - `reasoning.effort` を省略してAPI既定値へ委ねない。 - `gpt-5.6` エイリアスは Sol を指すため使用しない。 - `text.verbosity` は `low` を標準とする。構造化出力に必要なフィールドはJSON Schemaで担保する。 - `reasoning.mode: pro`、…

    stillshore-chirp · GitHub · Jul 31, 2026
  10. 10

    Ranks #1 of 144 on LMArena's overall text arena (Elo 1507), based on blind human preference votes.

    LMArena text arena · Benchmark · Sep 2, 2026
  11. 11

    Scores 80.54% on LiveBench Data Analysis (#3 of 52), including table joining and reformatting tasks.

    LiveBench Data Analysis · Benchmark · Jun 25, 2026
  12. 12

    "Claude Fable 5 and 5.1 are not included in LifeSciBench Gold v1, GeneBench Pro v13, and MedChemBench because they refuse the majority of questions in these evaluations.12" Sounds about right. Alignment is important, but also being able to do mundane tasks is important too.

    HDBaseT · Hacker News · Sep 3, 2026
  13. 13

    I dont get why Opus 4.7, 4.8, and now Fable all stopped supporting structured outputs? Does no one else care about that? I find it incredibly useful to reliably pass LLM output directly to other APIs libraries

    coreylane · Hacker News · Jun 9, 2026
  14. 14

    Filed from a job-hunt-agent session (per repo-boundary convention: JHA sessions file issues rather than modify this repo). Four items, all settled with the owner on 2026-07-29. ## 1. Railway prod env — model switch (no code) Rationale — best-of-2 trials through the live `/resume` route (real prompt, thoughts enrichment, rubric) on two real JDs from the 2026-07-28 shortlist: | Model | Tabs JD | ExpertVoice JD | Parses | |---|---|---|---| | z-ai/glm-5.2 | **4.11 ✓** | **4.29 ✓** | 4/4 | | anthrop…

    yuens1002 · GitHub · Jul 29, 2026
  15. 15

    ## Problem Statement 当前 Entry Module 单阶段提取在 5 案例上均值 ~36.2(Sol 等效),距 flawless 档(≥40)差 4 分。剩余扣分第一来源是漏提取与陈述弱化:Skein1 的函子公理清单、RT 的 handle-slide 命名性质等以 prose 清单/命名性质形式存在的内容被跳过;部分已提取条目的平衡张量积记号被弱化、或幻觉出原文没有的边界条件。连续 4 个提示词单变量实验(v1.32–1.35)证明在同一容量内加规则只会搬分数,净零。 ## Solution 在现有工作流(MinerU → v1.31 提取 → 确定性合并 → 产物)后新增第二阶段:用 muse-spark-1.2 对初版产物做校验补漏。阶段二输入为初版产物 + 源文本全文,仅做两件事:1) 扫描源文本中以清单/命名性质形式存在但被初版遗漏的条目,补 1–3 条;2) 逐条比对初版中被评委判为弱化的陈述与源文本原文,逐字订正。不改提示词,不改窗口。 ## User Stories 1. As a benchmark operator, I want the…

    cyw6130 · GitHub · Aug 21, 2026
  16. 16

    Scores 76.46% on LiveBench Data Analysis (#21 of 52), including table joining and reformatting tasks.

    LiveBench Data Analysis · Benchmark · Jun 25, 2026
  17. 17

    Scores 73.24% overall on BFCL (#2 of 32), measuring single-turn, multi-turn, web-search, memory, hallucination, and format-sensitive tool calling; mean latency was 4.31s.

    Berkeley Function-Calling Leaderboard · Benchmark · Sep 6, 2026
  18. 18

    ## 背景 #111 で経路 B の応答を tool use で受け取るようにしたが、2026-08-22 23:09 の再投入 (2608.17950v1) で 12 ページ目がモデルの出力 `sections` が配列ではなく文字列で返り、`PageDecodeError` になった (#113 の再試行でも同じ)。 tool use の `inputSchema` は `strict` を付けないと型を保証しない。公式ドキュメントは「strict なしでは型の不一致や必須欠落が起こり得る」と述べ、解決策として `strict: true` (constrained decoding) を提示している。 Claude Sonnet 4.5 は Bedrock Converse (`bedrock-runtime`、cross-region inference 含む) で対象。 - [ToolSpecification API Reference](https://docs.aws.amazon.com/bedrock/latest/APIReference/API_runtime…

    tamaco489 · GitHub · Aug 22, 2026

Rankings synthesized from community evidence and open benchmarks. See methodology. Not driven by vendor marketing.