[GH-ISSUE #6772] [Bug] GGUF inspection rejects architecture keys emitted for GPT-OSS by the published GGUF writer #4127

Closed
opened 2026-10-31 00:47:00 +00:00 by bsakaguchi · 0 comments
Owner

Originally created by @coygeek on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6772

Before submitting

  • I searched the open and closed issues for a related report.
  • I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

The public CLI rejects a small GGUF v3 declaration containing general.architecture = "gpt-oss" and gpt-oss.context_length = 4096. It exits 1 with target_unavailable / file_format_rejected, saying metadata keys require lower-snake-case hierarchy components. The same layout using llama succeeds. A second hyphenated architecture, wavtokenizer-dec, fails identically.

These are independently constructed declaration-only fixtures. The production GGUF writer in the published llama.cpp v0.7.0 release defines both architecture names and constructs context-length keys from them. No complete model or inference runtime was tested.

Reproduction

From the source revision below, with locked dependencies installed and the runtime built, run this complete fixture builder and the three public CLI requests:

work_dir="$(mktemp -d)"
node --input-type=module - "$work_dir" <<'JS'
import { writeFileSync } from 'node:fs';
import { join } from 'node:path';
const out = process.argv[2];
const u32 = n => { const b = Buffer.alloc(4); b.writeUInt32LE(n); return b; };
const u64 = n => { const b = Buffer.alloc(8); b.writeBigUInt64LE(BigInt(n)); return b; };
const text = s => { const b = Buffer.from(s); return Buffer.concat([u64(b.length), b]); };
for (const arch of ['llama', 'gpt-oss', 'wavtokenizer-dec']) {
  const header = Buffer.concat([
    Buffer.from('GGUF'), u32(3), u64(0), u64(2),
    text('general.architecture'), u32(8), text(arch),
    text(`${arch}.context_length`), u32(4), u32(4096),
  ]);
  const bytes = Buffer.alloc(Math.ceil(header.length / 32) * 32);
  header.copy(bytes);
  writeFileSync(join(out, `${arch}.gguf`), bytes);
}
JS
node scripts/rea.mjs inspect-model-artifact "$work_dir/llama.gguf" --json
node scripts/rea.mjs inspect-model-artifact "$work_dir/gpt-oss.gguf" --json
node scripts/rea.mjs inspect-model-artifact "$work_dir/wavtokenizer-dec.gguf" --json

Each request was run once. All fixtures are 128 bytes with zero tensors, two metadata entries and correct 32-byte data-section alignment.

Expected behavior

Preserve the architecture-specific metadata keys used by the published producer and inspect their declarations. In the released constants, GPT_OSS maps to gpt-oss. The same file maps WAVTOKENIZER_DEC to wavtokenizer-dec and declares the context-length key template as {arch}.context_length. The released writer formats that template with the architecture supplied to it.

There is a documentation conflict to resolve: the GGUF specification linked by REA says keys use lower-snake-case components, while its actual ecosystem producer emits these hyphenated architecture prefixes. This report concerns compatibility with the published producer; it does not claim the written specification currently permits hyphens. REA advertises GGUF v2/v3 inspection without excluding those common architecture families.

Impact and scope

A hyphenated architecture-specific key stops the complete inspection before the tensor directory. The retained partial observation contains the preceding architecture entry, but not the rejected context-length entry or a completed model report. The observed impact is limited to the generated fixtures. Official producer source establishes that the key pattern is used in ordinary generation; real large model files and the prevalence of affected artifacts were not measured.

REA version

rea --version: 6.7.0. Source revision 99d2d7ad22bcbd780919760008aba6a88e7d1077, corresponding to the latest published rea-agents-6.7.0 supplied for the investigation.

Runtime and platform

Node.js v24.22.1, Linux x86_64. The public compiled CLI was used. No external analysis engine, Python model package or model runtime was used.

Target and artifact context

Generated GGUF v3 little-endian files, each 128 bytes, containing two scalar metadata declarations and no tensor payload. The llama control differs from the failing variants in the architecture value and corresponding context-length key.

Interface

CLI

Earliest failure stage

Capture or observation

Relevant output or evidence

Recorded results from the public CLI:

llama.gguf: exit 0
  format: gguf
  metadata[1].key: llama.context_length
  metadata[1].value: 4096
  coverage.header: complete

gpt-oss.gguf: exit 1
wavtokenizer-dec.gguf: exit 1
  code: target_unavailable
  category: unsupported_target
  details.constraint: file_format_rejected
  details.reason: GGUF metadata keys require ASCII lower-snake-case hierarchy components

The GPT-OSS error retained one preceding metadata row whose value is gpt-oss, with partial metadata/header coverage and tensors not started. The wavtokenizer error retained its own preceding architecture row with the same coverage state.

Evidence provenance: observed CLI outputs, plus source-derived producer compatibility. Local verification: reproduced. Reproduction completeness: complete for the reduced declaration fixtures; no full model was inspected.

Typed outcome or recovery expected

Return complete declaration Evidence for the released producer's architecture keys. Preserve the source key exactly; replacing the hyphen or editing an artifact copy changes the selected declarations and does not preserve the original artifact identity.

Analysis or suspected cause

Source-derived: GgufHeader.ts:288–294 at the tested revision permits alphanumeric and underscore characters in key components but rejects - before parsing the value. The failure occurs in the producing parser rather than selected-view projection.

Additional context

Open and closed issue searches covered GGUF with hyphen, gpt-oss, wavtokenizer, lower-snake-case, and metadata keys. No duplicate was found. Related #6569 concerns chat-template presence in summaries, not architecture-key admission. The previously reported numeric hierarchy support also addresses a different permitted character pattern.

The latest published upstream writer was source-inspected only; it was not executed because its NumPy dependency was unavailable. No package was installed to work around that limitation. Prepared with AI assistance.

Triage assessment

  • Impact level: P2
  • Assessment status: supported
  • Impact basis: Two ordinary producer-compatible architecture key patterns cause an observed typed refusal of the entire declaration inspection, while the control succeeds. This is a bounded compatibility failure; no target execution, modification, or data loss occurs.
  • Workaround status: unverified
  • Workaround basis: An independent GGUF reader could inspect the original declarations, but that workflow was not executed. Renaming the source keys changes the artifact and is not an identity-preserving workaround.
Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6772 ## Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ## Area Evidence, artifacts, or reconstruction ## Observed behavior The public CLI rejects a small GGUF v3 declaration containing `general.architecture = "gpt-oss"` and `gpt-oss.context_length = 4096`. It exits 1 with `target_unavailable` / `file_format_rejected`, saying metadata keys require lower-snake-case hierarchy components. The same layout using `llama` succeeds. A second hyphenated architecture, `wavtokenizer-dec`, fails identically. These are independently constructed declaration-only fixtures. The production GGUF writer in the published [llama.cpp v0.7.0 release](https://github.com/ggml-org/llama.cpp/releases/tag/v0.7.0) defines both architecture names and constructs context-length keys from them. No complete model or inference runtime was tested. ## Reproduction From the source revision below, with locked dependencies installed and the runtime built, run this complete fixture builder and the three public CLI requests: ```sh work_dir="$(mktemp -d)" node --input-type=module - "$work_dir" <<'JS' import { writeFileSync } from 'node:fs'; import { join } from 'node:path'; const out = process.argv[2]; const u32 = n => { const b = Buffer.alloc(4); b.writeUInt32LE(n); return b; }; const u64 = n => { const b = Buffer.alloc(8); b.writeBigUInt64LE(BigInt(n)); return b; }; const text = s => { const b = Buffer.from(s); return Buffer.concat([u64(b.length), b]); }; for (const arch of ['llama', 'gpt-oss', 'wavtokenizer-dec']) { const header = Buffer.concat([ Buffer.from('GGUF'), u32(3), u64(0), u64(2), text('general.architecture'), u32(8), text(arch), text(`${arch}.context_length`), u32(4), u32(4096), ]); const bytes = Buffer.alloc(Math.ceil(header.length / 32) * 32); header.copy(bytes); writeFileSync(join(out, `${arch}.gguf`), bytes); } JS node scripts/rea.mjs inspect-model-artifact "$work_dir/llama.gguf" --json node scripts/rea.mjs inspect-model-artifact "$work_dir/gpt-oss.gguf" --json node scripts/rea.mjs inspect-model-artifact "$work_dir/wavtokenizer-dec.gguf" --json ``` Each request was run once. All fixtures are 128 bytes with zero tensors, two metadata entries and correct 32-byte data-section alignment. ## Expected behavior Preserve the architecture-specific metadata keys used by the published producer and inspect their declarations. In [the released constants](https://github.com/ggml-org/llama.cpp/blob/v0.7.0/gguf-py/gguf/constants.py#L1466), `GPT_OSS` maps to `gpt-oss`. The same file maps `WAVTOKENIZER_DEC` to `wavtokenizer-dec` and declares the context-length key template as `{arch}.context_length`. The [released writer](https://github.com/ggml-org/llama.cpp/blob/v0.7.0/gguf-py/gguf/gguf_writer.py#L698) formats that template with the architecture supplied to it. There is a documentation conflict to resolve: the GGUF specification linked by REA says keys use lower-snake-case components, while its actual ecosystem producer emits these hyphenated architecture prefixes. This report concerns compatibility with the published producer; it does not claim the written specification currently permits hyphens. REA advertises GGUF v2/v3 inspection without excluding those common architecture families. ## Impact and scope A hyphenated architecture-specific key stops the complete inspection before the tensor directory. The retained partial observation contains the preceding architecture entry, but not the rejected context-length entry or a completed model report. The observed impact is limited to the generated fixtures. Official producer source establishes that the key pattern is used in ordinary generation; real large model files and the prevalence of affected artifacts were not measured. ## REA version `rea --version`: `6.7.0`. Source revision `99d2d7ad22bcbd780919760008aba6a88e7d1077`, corresponding to the latest published `rea-agents-6.7.0` supplied for the investigation. ## Runtime and platform Node.js v24.22.1, Linux x86_64. The public compiled CLI was used. No external analysis engine, Python model package or model runtime was used. ## Target and artifact context Generated GGUF v3 little-endian files, each 128 bytes, containing two scalar metadata declarations and no tensor payload. The `llama` control differs from the failing variants in the architecture value and corresponding context-length key. ## Interface CLI ## Earliest failure stage Capture or observation ## Relevant output or evidence Recorded results from the public CLI: ```text llama.gguf: exit 0 format: gguf metadata[1].key: llama.context_length metadata[1].value: 4096 coverage.header: complete gpt-oss.gguf: exit 1 wavtokenizer-dec.gguf: exit 1 code: target_unavailable category: unsupported_target details.constraint: file_format_rejected details.reason: GGUF metadata keys require ASCII lower-snake-case hierarchy components ``` The GPT-OSS error retained one preceding metadata row whose value is `gpt-oss`, with partial metadata/header coverage and tensors not started. The wavtokenizer error retained its own preceding architecture row with the same coverage state. Evidence provenance: observed CLI outputs, plus source-derived producer compatibility. Local verification: reproduced. Reproduction completeness: complete for the reduced declaration fixtures; no full model was inspected. ## Typed outcome or recovery expected Return complete declaration Evidence for the released producer's architecture keys. Preserve the source key exactly; replacing the hyphen or editing an artifact copy changes the selected declarations and does not preserve the original artifact identity. ## Analysis or suspected cause Source-derived: [GgufHeader.ts:288–294 at the tested revision](https://github.com/morluto/rea/blob/99d2d7ad22bcbd780919760008aba6a88e7d1077/src/model/GgufHeader.ts#L288-L294) permits alphanumeric and underscore characters in key components but rejects `-` before parsing the value. The failure occurs in the producing parser rather than selected-view projection. ## Additional context Open and closed issue searches covered `GGUF` with `hyphen`, `gpt-oss`, `wavtokenizer`, `lower-snake-case`, and `metadata keys`. No duplicate was found. Related #6569 concerns chat-template presence in summaries, not architecture-key admission. The previously reported numeric hierarchy support also addresses a different permitted character pattern. The latest published upstream writer was source-inspected only; it was not executed because its NumPy dependency was unavailable. No package was installed to work around that limitation. Prepared with AI assistance. ## Triage assessment - Impact level: P2 - Assessment status: supported - Impact basis: Two ordinary producer-compatible architecture key patterns cause an observed typed refusal of the entire declaration inspection, while the control succeeds. This is a bounded compatibility failure; no target execution, modification, or data loss occurs. - Workaround status: unverified - Workaround basis: An independent GGUF reader could inspect the original declarations, but that workflow was not executed. Renaming the source keys changes the artifact and is not an identity-preserving workaround.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
morluto/rea#4127
No description provided.