However, OpenCode is engineered exclusively as a software engineering harness and code intelligence tool. It contains no native document typesetting engine, no spatial layout constraint solvers, no mathematical pagination algorithms, and no specialized document file format. When prompted to generate business deliverables—such as executive reports, legal agreements, customer invoices, or marketing proposals—an agent in OpenCode operates strictly by emitting raw text markup or by authoring and executing ad-hoc imperative scripts that invoke third-party tools like python-docx, reportlab, weasyprint, pandoc, or typst.

In contrast, K2F is an open semantic document format (Apache 2.0) and deterministic layout compiler engineered specifically for AI agent document generation, structured node editing, and multi-format enterprise publishing. Rather than treating documents as unstructured text buffers or disposable conversion scripts, the K2F format operates on a dual-state architecture: an editable semantic JSON tree (State A) and a compiled, pixel-stable render lock (document.K2F.lock / State C). Guided by the architectural pillars "Consistent like PDF. Editable like code." and "Semantic Intent. Deterministic Geometry.", K2F enforces strict separation between semantic intent and visual styling. This allows autonomous agents to modify content without breaking layouts, verify visual balance and structural integrity through a local compiler gate (pack_verify), and guarantee deterministic document output across Microsoft Word (.docx), PowerPoint (.pptx), interactive AcroForm PDF, and Adobe InDesign (.idml).

This document format comparison clarifies how a terminal coding agent and a document format interact rather than treating them as mutually exclusive alternatives. K2F does not claim to replace general-purpose coding agents or developer CLI tools like OpenCode. Instead, developers can install the official K2F agent skill (npx skills add suzheng/k2f --skill k2f) or Python CLI (pip install k2f) directly into OpenCode. This allows OpenCode to serve as the orchestrating terminal agent and reasoning harness across 75+ model providers, while relying on K2F to compile, validate, and publish production-grade documents backed by k2f.dev.

K2F is not an interactive CLI coding agent, shell environment, or general software development tool. K2F v0.1 ships with a fixed "paged" canvas mode (slide presentation and infinite canvas modes are roadmap design targets), does not import or reverse-engineer pre-existing PDF files (PDF_IS_NOT_A_SOURCE) or Word documents (DOCX_IS_NOT_A_SOURCE), strictly prohibits executable scripts and macros in State A, forbids arbitrary Bézier vector path drawing in State A JSON, and treats all exported deliverables as unidirectional read-only drawings of the compiled render lock (PDF_IS_NOT_A_SOURCE, DOCX_IS_NOT_A_SOURCE, PPTX_IS_NOT_A_SOURCE, IDML_IS_NOT_A_SOURCE).

At a glance

OpenCode vs K2F for agent document generation: How documents are handled

How OpenCode handles documents

OpenCode is designed from the ground up for software developers working in the terminal. Published under the permissive MIT license at anomalyco/opencode, OpenCode operates as an open-source coding assistant and multi-model agent harness. Its operational architecture combines several core capabilities:

• Terminal-First TUI & Multi-Surface Architecture: Built in Go using Charm’s Bubble Tea framework, OpenCode’s flagship interface delivers a high-throughput, keyboard-centric terminal UI optimized for modern emulators (Ghostty, WezTerm, Alacritty, iTerm2). In addition to the TUI, OpenCode provides cross-platform desktop applications (macOS, Windows, Linux), headless background daemons (opencode serve, opencode web) for remote browser-based agent interactions, and extensions for VS Code, Neovim, and JetBrains IDEs.
• Model-Agnostic Multi-Provider Engine: OpenCode connects to 75+ model providers out of the box. Developers can bring their own API keys (BYOK) for commercial frontier models (Anthropic Claude, OpenAI, Google Gemini, DeepSeek) or route to locally hosted open-weight models via Ollama, LM Studio, or vLLM at zero software cost. Managed model routing gateways (such as OpenCode Zen for pay-as-you-go access, or OpenCode Go subscriptions) are also available.
• Context Discovery via AGENTS.md: OpenCode pioneered AGENTS.md as an open standard ("README for AI agents"). Discovered nearest-first in directory hierarchies, AGENTS.md files define repository layouts, development commands, code conventions, and file access policies.
• Dual Execution Modes: OpenCode partitions agent agency into two modes:
  • Plan Agent: Read-only architectural analysis and exploratory reasoning, strictly barred from executing write or destructive bash tools.
  • Build Agent: Primary implementation agent equipped with filesystem write tools, unified diff patching, and shell command execution.
• Native Tooling & Language Intelligence: The Build agent leverages built-in primitives including bash (spawning shell processes to run CLI commands and package managers), read (inspecting file contents with line offset slicing), write (creating or overwriting files), edit (applying unified diff patches), and lsp (interfacing with Language Server Protocols for AST awareness, diagnostics, and symbol navigation). OpenCode also provides native Model Context Protocol (MCP) support (opencode mcp add) and modular custom skills defined via SKILL.md.

Despite its technical sophistication in software engineering, OpenCode contains no document compiler, spatial layout linter, render pipeline, or visual inspection harness. When commanded to author a formal business document, OpenCode relies entirely on emitting raw text markup or generating and executing imperative scripts using third-party software libraries.

Typical document outputs produced by OpenCode

When an agent in OpenCode is asked to produce contracts, invoices, executive summaries, or presentation slides, it typically defaults to one of several file formats:

1. Markdown (.md): The standard output for developer documentation. Markdown structures text cleanly using headings, lists, blockquotes, and tables. However, Markdown lacks any concept of physical canvas geometry, paper sizes (A4 or US Letter), margin boxes, running headers/footers, or print typography. It represents unpaginated text rather than a publication-ready deliverable.
2. Single-Page HTML & CSS (.html / .css): Agents frequently generate standalone HTML files styled with inline CSS or utility frameworks like Tailwind CSS via CDN. Previewed via local web servers or opened directly in a browser, HTML is inherently fluid and screen-bound. Different browser rendering engines (Blink, WebKit, Gecko) calculate font metrics, line wraps, and container dimensions differently. When converting HTML to PDF via browser print dialogs (window.print()), page splits frequently sever table rows across sheets, collapse multi-column flex containers, clip background fills, and produce unpredictable page counts.
3. Microsoft Word (.docx via python-docx or Pandoc): OpenCode agents typically author Python automation scripts utilizing python-docx or execute Pandoc CLI commands (pandoc input.md -o output.docx). However, WordprocessingML stores no physical layout geometry. Microsoft Word, LibreOffice, and Google Docs compute page breaks dynamically at display time based on local system fonts, printer driver metrics, and display scaling. An executive report that renders across two pages on a developer's machine frequently reflows onto three pages on a client workstation. Furthermore, procedural scripts struggle to manage complex visual hierarchies, while attempting to edit raw Office Open XML (document.xml) directly with LLMs easily violates schema sequence rules, corrupting the document.
4. PDF via External Script Execution (.pdf): Agents write and execute Python or Node.js scripts leveraging libraries like reportlab, fpdf2, weasyprint, or headless browser automation (Puppeteer, Playwright). This workflow is fragile and heavily dependent on host operating system dependencies (Cairo, Pango, system font packages). Imperative coordinate math in ReportLab (c.drawString(x, y, text)) requires manual calculation of line wraps and page boundaries; text easily collides or overflows containers. Crucially, the resulting PDFs are opaque, static binary files; downstream agents cannot inspect or edit the content without brittle OCR, and there is no mathematical link back to the underlying source data.
5. LaTeX (.tex) and Typst (.typ): For academic and scientific documents, agents can author LaTeX or Typst source files and compile them via local CLI binaries. While Typst produces high-quality paginated PDFs, it blends layout logic, content, and styling into a single programmatic file, lacking a declarative semantic tree or enterprise verification schema. LaTeX involves brittle package compilation chains with cryptic macro error messages that make iterative agent restyling difficult.
6. Slide Presentations (PPTX via python-pptx, Reveal.js, Marp): Presentations generated via python-pptx or Markdown slide frameworks are constrained to basic rectangular boxes and bulleted text; layered layouts, multi-column cards, or bespoke brand styling frequently break.

Editing text diffs versus binary deliverables

OpenCode's core editing model relies on its edit tool, which generates and applies unified diff patches to source files. While diff-based editing works reliably on indented programming languages (TypeScript, Go, Python), it introduces major failure modes when applied to document authoring:

• Patching failures on unstructured text: In long Markdown or HTML files, small shifts in whitespace, word wrapping, or list indentation cause unified diff patches to reject. Line-level edits on nested HTML containers frequently introduce unbalanced tags, breaking layout trees.
• Token exhaustion and drift from full regeneration: When unified diffs fail, agents fall back to full-file overwrites via the write tool. Rewriting long multi-page documents consumes massive token context, introduces latency, and frequently leads to subtle hallucinations, accidental deletions of preceding sections, or unauthorized phrasing changes.
• Destructive updates on binary deliverables: OpenCode cannot perform diff-based editing on binary files, compressed ZIP archives, or raw PDF byte streams. To update a generated .docx or .pdf, an agent must either edit the upstream Python generation script and re-execute the entire pipeline from scratch (wiping out any manual adjustments), or perform dangerous "XML archive surgery." Unzipping a .docx file and attempting regex replacements on <w:t> tags in word/document.xml easily violates strict Open Packaging Conventions (OPC) or XML child element ordering, causing Microsoft Word to report fatal corruptions.

What K2F adds

K2F resolves the fragility of script-based document generation by establishing an open, standardized file format and deterministic compiler architecture. Guided by the core philosophy "Consistent like PDF. Editable like code." and "Semantic Intent. Deterministic Geometry.", K2F establishes an absolute boundary between what an agent edits (semantic content and intent) and what the layout engine renders (spatial geometry and typography).

The author package workspace

When an agent operates in K2F, it works within an explicit, structured author workspace:

./out/doc/
  doc.K2F                 # Self-contained deliverable ZIP archive
  doc.pdf                 # Optional lock-drawn export (same stem)
  source/                 # Author package directory (the agent edits this)
    design.md             # Concrete design specification authored before coding
    manifest.json         # Page geometry, canvas mode ("paged"), margins
    content/
      root.json           # State A: Semantic JSON tree
      <slug>.json         # Optional container include fragments
    styles/
      theme.json          # Roles, variants, palettes, box decoration primitives
    assets/
      fonts/              # Embedded TrueType/OpenType binaries (no system fonts)
      images/             # Embedded PNG, JPEG, SVG assets
      data/               # External datasets for large tables
    changelog.json        # Structured machine-readable edit history
  tmp/                    # Rendered preview PNGs and debug artifacts

1. State A: Declarative semantic tree with stable dotted IDs

In K2F, the editable source is source/content/root.json (State A). Content is structured as a pure semantic Abstract Syntax Tree (AST). Every logical node is assigned a permanent, hierarchical dotted identifier formatted as parent_id.child_type_semantic_name (such as financials.q3_results.table_revenue or contract.parties.vendor).

When an agent updates a document, it does not scan for fuzzy headings or perform full-file rewrites. It applies surgical JSON patches to exact dotted node IDs. Other sections of the document, their parent geometry, and surrounding components remain completely untouched. For long publications, State A supports modular container fragments via { "include": "content/sub_section.json" }, enabling agents to work on isolated chapters without loading entire documents into context.

2. Strict separation of intent and presentation

K2F enforces an absolute architectural boundary between content meaning and visual styling:

• Semantic nodes contain only intent: Content nodes specify their structural role (such as h1, card, warning, form_field), an optional variant, and text modifiers with UTF-8 byte ranges (emphasis, link, math). Placing a visual attribute (such as a font size, hex color, margin, padding, or border width) directly on a content node violates the schema and triggers an immediate compilation error (SCHEMA_INVALID).
• Visual styles live exclusively in theme.json: All colors, typography hierarchies, spacing scales, corner radii, and shadow elevations are defined as named visual primitives in source/styles/theme.json.

Because styling is completely decoupled from content, an agent can restyle an enterprise document—changing brand palettes, typography scales, and container density across a 50-page publication—by modifying a single token in theme.json. The layout engine recomputes all geometry deterministically without risking content corruption or syntax errors.

3. State C: Deterministic render lock (document.K2F.lock)

When the author package is compiled (k2f pack), K2F's reference engine (k2f_layout, implemented in Rust) calculates exact page geometry. Using deterministic IEEE-754 floating-point math, strict HarfBuzz text shaping (rustybuzz), Unicode Line Breaking (UAX #14), and embedded TrueType/OpenType font binaries (system fonts are strictly prohibited), the engine computes the exact position, bounding box, and draw order of every glyph and vector shape.

This geometry is serialized into document.K2F.lock (State C). When viewed in official readers—such as the WebAssembly <k2f-viewer> web component, the Desktop Reader, or the interactive browser Playground—the application paints the lock directly. There is zero runtime layout recalculation and zero font reflow. A document compiled on macOS renders identically down to the sub-pixel on Windows, Linux, iOS, and Android.

4. Single-source multi-format publishing

From a single compiled .K2F package, the toolchain generates all required business deliverables:

• Print-ready PDF: Native vector drawing with embedded fonts and exact canvas dimensions.
• Fillable AcroForm PDF: Semantic form_field nodes compile directly into native, interactive PDF form controls (text fields, checkboxes). Agents author real interactive forms rather than drawing non-functional visual underscores (____).
• Microsoft Word (.docx): WordprocessingML generated by mapping locked coordinates directly to document structures.
• PowerPoint (.pptx): Slide layouts compiled directly from page geometry.
• Adobe InDesign (.idml): Complete prepress packages including an accompanying Document Fonts/ directory for professional editorial finishing.

Under K2F's architectural rules, exports are not sources of truth (PDF_IS_NOT_A_SOURCE, DOCX_IS_NOT_A_SOURCE, PPTX_IS_NOT_A_SOURCE, IDML_IS_NOT_A_SOURCE). All downstream files are unidirectional read-only drawings of the render lock. To modify a document, the agent edits State A, runs the compiler, and regenerates all deliverables simultaneously.

5. Template ecosystem: The K2F Gallery

Rather than forcing agents to design complex document layouts from scratch, K2F provides the K2F Gallery (k2f.dev/gallery). The Gallery offers 469+ production-grade templates spanning business reports, executive proposals, legal contracts, invoices, resumes, certificates, and fillable forms.

All templates are licensed under Apache 2.0, 100% free, require zero login, and have no rate limits or paywalls. Agents can fetch templates headlessly via HTTP GET requests to https://k2f.dev/api/gallery/templates/{slug} or through the stdio MCP tool (download_template). Running k2f unpack <template.K2F> -o ./out/doc/source immediately provides the agent with an editable author package containing a verified semantic tree, production-ready theme primitives, and embedded fonts.

Verification and publishing integrity

The critical divide between unconstrained agent authoring in OpenCode and the K2F workflow lies in how outputs are verified.

In general software engineering, OpenCode enforces a robust, closed-loop verification cycle:

flowchart LR
    A["Agent writes code"] --> B["Run compiler / linter / tests"]
    B --> C{"Tests pass?"}
    C -- No --> D["Inspect error trace"]
    D --> A
    C -- Yes --> E["Commit code"]

When authoring software in Go, TypeScript, or Rust, OpenCode compiles source files, executes test runners (pytest, cargo test, npm test) via its bash tool, captures compiler diagnostics via LSP, and iterates autonomously until all checks pass cleanly.

Silent visual failures in script-based document generation

When an agent generates documents using ad-hoc scripts (HTML/CSS, Puppeteer, or python-docx), this verification loop breaks down into an open-loop failure mode:

• No formal document schema: General documents generated by OpenCode lack a strict schema. A generated Markdown or HTML document cannot be validated for structural completeness against an enterprise document specification (such as ensuring mandatory compliance disclosures, signature blocks, or standardized table structures are present).
• Silent visual defects: A Python script generating a PDF via ReportLab or WeasyPrint may exit with status code 0, yet the resulting PDF may suffer from severed table rows, overlapping text frames, clipped charts, or blank pages.
• Unpredictable reflow: A Python script generating a .docx file completes without errors, but when opened in Microsoft Word, layout reflow causes text to spill onto unwanted extra pages.
• Fragmented tooling: Verification is fragmented across disparate CLI tools, each with different exit codes, error formats, and lack of visual feedback.

The K2F compiler gate: pack_verify.py

K2F restores the closed-loop engineering cycle to document generation through its standardized verification gate:

flowchart TD
    A["Agent edits State A / Theme"] --> B["Run pack_verify.py"]
    B --> C["Validate JSON schemas against /schema/"]
    C --> D["Compile layout via Rust engine k2f_layout"]
    D --> E["Write State C document.K2F.lock"]
    E --> F["Rasterize pages to preview PNGs"]
    F --> G{"Automated quality checks"}
    G -- "Visual/Schema defect" --> H["Surface structured error code"]
    H --> A
    G -- "Clean verification" --> I["Generate lock-drawn PDF, Word, PPTX, IDML"]

The stdlib-only pack_verify.py script acts as the agent's document compiler and linter:

1. Schema validation: Validates manifest.json, root.json, and theme.json against strict embedded JSON schemas (/schema/). Hallucinated CSS attributes, missing IDs, or malformed modifier byte ranges immediately fail with structured error codes (SCHEMA_INVALID, UNKNOWN_PRIMITIVE, UNKNOWN_ROLE).
2. Deterministic layout calculation: Executes k2f pack, invoking the Rust reference engine (k2f_layout) to calculate line breaking, text shaping, and spatial geometry.
3. Automated visual defect detection: When executed with --render, the compiler rasterizes each page to a preview PNG and inspects the visual output. Crucially, the engine catches subtle visual defects such as PAGE_UNDERFILL—detecting when content fails to fill the lower third of a designed sheet—preventing unstyled, empty layouts from reaching stakeholders.
4. Agent self-correction: Because errors are reported as deterministic codes with exact node references, an AI agent in OpenCode can read the compiler output, locate the offending node in source/content/root.json, and apply a fix without human intervention.

Deterministic document output across devices

Why do HTML and Word documents reflow across machines?

• In HTML/CSS, font rendering engines (Apple CoreText, Microsoft DirectWrite, Linux FreeType) calculate distinct glyph widths and line heights. Flexbox and Grid behave differently across browser releases.
• In Word (.docx), WordprocessingML stores zero geometry. Microsoft Word calculates page breaks dynamically based on installed system fonts, printer drivers, and DPI scaling.

K2F eliminates environment drift:

• Geometry is calculated once by k2f_layout using strict HarfBuzz text shaping (rustybuzz), Unicode line breaking (UAX #14), IEEE-754 math, and embedded fonts only.
• Draw calls and bounding boxes are locked into document.K2F.lock.
• Official viewers (<k2f-viewer>, Desktop Reader, Playground) and exporters paint the lock directly without re-running layout or reflowing text. The visual output is identical across macOS, Windows, Linux, iOS, and Android.

Cryptographic integrity and auditability

Unlike standalone PDFs or Word documents, which can be modified in desktop editors without leaving an audit trail, K2F incorporates a formal two-layer cryptographic binding:

• content_hash: A SHA-256 hash computed over the normalized canonical JSON semantic tree (content/root.json).
• appearance_hash: A SHA-256 hash binding the semantic tree, theme tokens, embedded font binaries, canvas manifest geometry, and the exact reference engine commit SHA (engine_commit_sha).

These hashes are embedded directly into State C (document.K2F.lock). Official viewers and desktop readers audit these values upon opening, displaying a mandatory integrity banner with five canonical states:

• SIGNED: Cryptographically signed and fully verified against the source tree and render lock.
• UNSIGNED: Valid, uncorrupted document without a digital signature (the standard output of autonomous agents).
• SIGNED_BUT_BROKEN: A digital signature exists, but package bytes have been altered.
• BROKEN_INTEGRITY: Render lock draw calls or font binaries do not match the compiled appearance hash.
• UNLOCKED: Development package lacking a compiled State C lock.

If a document is opened in an environment with an incompatible layout engine specification, readers immediately report an ENGINE_MISMATCH. For enterprise and legal compliance, organizations can apply asymmetric Ed25519 digital signatures (signatures/v1.json) via an explicit key-custody step, guaranteeing that neither the content nor its visual layout has been tampered with. Furthermore, K2F strictly prohibits embedded executable scripts, macros, and dynamic network calls during render.

When to choose OpenCode

Choose OpenCode when your primary objective centers on interactive, terminal-native software development, multi-model flexibility, and general coding workflows:

• Full-stack software engineering and refactoring: Navigating large codebases, resolving multi-file dependencies, running automated test suites (pytest, cargo test, npm test), and refactoring application architectures directly in a high-throughput Bubble Tea TUI.
• Multi-model provider freedom: Connecting directly to 75+ commercial frontier models (Claude 3.5, GPT-4o, Gemini 1.5, DeepSeek) or locally hosted open-weight models via Ollama with full Bring-Your-Own-Key (BYOK) autonomy or transparent pay-as-you-go routing (OpenCode Zen).
• Interactive debugging and shell command chaining: Running terminal commands, inspecting stdout/stderr, piping command outputs, executing database migrations, and orchestrating cloud infrastructure tools without leaving the terminal.
• Rapid unstructured text drafting: Generating informal, unstyled documentation—such as internal developer RFCs, meeting notes, sprint retrospectives, API documentation drafts, and READMEs—in Markdown where physical page geometry and print typography are unnecessary.
• Dynamic data scraping and analysis scripts: Writing and executing ad-hoc Python/Pandas scripts to pull live metrics from databases, scrape web endpoints, generate Matplotlib/Seaborn plots, and assemble raw datasets.
• Orchestrating agent workflows with K2F: Using OpenCode as the host execution environment while installing the K2F skill (npx skills add suzheng/k2f --skill k2f) or CLI (pip install k2f). OpenCode acts as the terminal agent, reasoning harness, and Git manager, while K2F provides the deterministic compilation, schema validation, and multi-format exports.

When to choose K2F

Choose K2F when document generation requires publication-grade visual quality, multi-format delivery, and verifiable layout determinism:

• Publication-grade business deliverables: Generating formal client proposals, quarterly executive reports, legal contracts, corporate invoices, compliance filings, employee onboarding manuals, or certificates that require precise typography, balanced margins, and professional layouts.
• Cross-device pixel stability: Documents that cannot tolerate layout shifts, awkward page breaks, or font substitutions when opened across different operating systems, mobile devices, web browsers, or print environments.
• Single-source multi-format enterprise publishing: Organizations that must deliver the same core content across Microsoft Word (for legal redlining), PowerPoint (for executive presentations), interactive AcroForm PDF (for signed forms), and Adobe InDesign (for prepress agency finishing) from a single authoritative source.
• Interactive AcroForm PDF generation: Generating official forms, applications, or sign-off sheets that require native interactive form_field controls rather than visual underscores or static lines.
• Automated CI/CD document pipelines: Automated server workflows or agent swarms that require headless command-line compilation (k2f pack), schema validation, and automated visual quality gates (pack_verify.py) before artifacts are published.
• Git-native version control for documents: Teams that want documents stored as clean Canonical JSON files that can be reviewed in pull requests, diffed line-by-line, and updated by targeting stable dotted node IDs.
• Tamper-evident legal and financial compliance: Workflows requiring cryptographic guarantees (content_hash, appearance_hash, Ed25519 signatures) that visual appearance matches underlying semantic data, backed by a strict format standard that prohibits executable macros and tracking scripts.
• Accelerating production with living templates: Leveraging the 469+ production-grade templates in the K2F Gallery to bootstrap documents instantly without paying subscription fees or guessing layout coordinates.

Bottom line

OpenCode and K2F address two complementary layers of modern developer automation. OpenCode is a purpose-built terminal-native AI coding harness engineered by Anomaly to explore, code, test, and commit software across 75+ model providers. However, general-purpose coding agents lack the specialized layout engines, pagination math, and strict schema validation required for dependable, publication-ready document publishing.

K2F provides the missing compiler and verification gate for agent-authored documents. By establishing a dual-state architecture that separates semantic intent from deterministic geometry, K2F transforms document generation from an unverified script-writing exercise into a repeatable, automated engineering discipline. Rather than choosing between them, developers can combine both: using OpenCode as the autonomous terminal orchestrator, and equipping it with K2F to compile, verify, and export pixel-stable enterprise deliverables.

To explore technical specifications, layout crate internals, and schema definitions, review the documentation. To inspect production-ready templates across business, legal, and educational categories, visit the Gallery. To understand the architectural principles behind the dual-state model, read why K2F exists, or explore comprehensive cross-format evaluations on Compare.

This comparison is based on publicly available information at the time of writing. Capabilities, pricing, and policies may change; verify details with the relevant provider.