GPT-Vis: charts that render while the model is still writing them

Two input formats, and one of them is for machines that type badly

The `render()` method accepts two input formats, and the split is the design centre of the library. JSON objects are described as ideal for programmatic use, and the DSL syntax as ideal for LLM streaming.

The object path is ordinary chart configuration. A line chart is a type, a data array and nothing else:

gptVis.render({
  type: 'line',
  data: [
    { time: '2020', value: 100 },
    { time: '2021', value: 120 },
    { time: '2022', value: 150 },
  ],
});

The DSL path is a declarative markdown-like syntax that LLMs can generate without learning complex APIs. Its shape is deliberately shallow:

vis [chart-type]
[property] [value]
data
  - [field] [value]

A pie chart in that form is:

vis pie
data
  - category Sales
    value 30
  - category Marketing
    value 25
innerRadius 0.6

Two details make it usable in practice. String values with spaces are quoted, as in `category "Q1 Sales"`, so a label containing a space does not break the parser. And the data block nests, so hierarchical data works, as with a mindmap where each item has a `children` list.

The library is framework agnostic, working with vanilla JavaScript, React, Vue, Angular or any framework, and it is published as `@antv/gpt-vis` on npm under the MIT licence.

Streaming rendering is the feature everything else serves

The reason a separate DSL exists at all is the streaming case, and the API for it is small.

Charts render as the AI model generates, with no need to wait for the full response. The pattern is to accumulate tokens into a buffer and re-render whenever the buffer might be parseable:

import { GPTVis, isVisSyntax } from '@antv/gpt-vis';

const gptVis = new GPTVis({ container: 'container', width: 600, height: 400 });
let buffer = '';

function onToken(token) {
  buffer += token;
  if (isVisSyntax(buffer)) {
    gptVis.render(buffer);
  }
}

The `isVisSyntax` check is what makes this safe to call on every token. It is a cheap test for whether the buffer could be a complete specification, and the render call is guarded by it rather than being fired blindly on every fragment.

Paired with that is the fault tolerance claim: the library gracefully handles incomplete or malformed data, adapting to the uncertainty of AI generated content. The two features belong together. Streaming means you will hand the parser half a specification at some point, and a model can also produce a specification that is complete but wrong. A library that only rendered finished, valid input would be unusable here, and that is what this one is built for.

The DSL is also not limited to charts produced by a model. A developer can write the same text by hand and pass it to `render()` as a template string, which means one format serves both the streaming and the static path.

Twenty six chart types across three families

The chart catalogue is what the library actually renders, and it is grouped into three families.

The statistical family has eighteen types: line, area, column, bar, pie, scatter, radar, funnel, waterfall, dual axes, histogram, boxplot, violin, venn, sankey, treemap, word cloud and liquid, with type identifiers in lowercase hyphenated form such as `dual-axes` and `word-cloud`.

The relationship family has six: flow diagram, network graph, mindmap, indented tree, organization chart and fishbone diagram, with identifiers like `flow-diagram`, `network-graph`, `indented-tree`, `organization-chart` and `fishbone-diagram`.

The text visualization family has two: table and summary, identifiers `table` and `summary`.

That spread is worth noting against the alternatives. The statistical set covers the shapes a data analyst reaches for, including the less common ones such as violin, sankey, venn and treemap. The relationship set is where a language model is most likely to be asked for something, because describing a hierarchy or a flow in text is natural. The text family is the one that most directly reflects the LLM use case, since summarising a document as a table or a summary block is a very common request.

The underlying chart engines are the AntV family, with `@antv/g2` at ^5.4.8 for the statistical charts, `@antv/g6` at ^5.1.0 for the relationship graphs, `@antv/t8` at ^0.3.0 for the text visualization, and `@antv/component` at 2.1.11. A consequence worth knowing is that the dependency tree is fixed at these versions, since the dependencies are pinned rather than ranged for the component package.

Three themes and per-chart style overrides

The theme system is small and explicit. There are three built-in themes, switchable with the `theme` property: `default` for light, `dark`, and `academy`.

The theme table gives the identifier, the background and the palette. The default and dark themes share the same palette, `#1783FF`, `#F08F56`, `#D580FF`, `#00C9C9`, `#7863FF` and more, differing in background, `#FFF` against `#000`. The academy theme uses a different set, `#4e79a7`, `#f28e2c`, `#e15759`, `#76b7b2`, `#59a14f` and more, on a light background.

That is a real advantage of the academic palette, which uses a distinct palette set and may suit a printed figure or a screenshot pasted into a document.

For anything more specific there is a `style` property, which is passed straight through:

gptVis.render({
  type: 'line',
  data: [
    { time: '2020', value: 100 },
    { time: '2021', value: 120 },
  ],
  style: { lineWidth: 3, palette: ['#5B8FF9', '#5AD8A6'] },
});

The same works in the DSL, where `style` sets line width and a custom palette:

vis line
data
  - time 2020
    value 100
  - time 2021
    value 120
style
  lineWidth 3
  palette
    - #5B8FF9
    - #5AD8A6

The fact that the same properties are expressible in both formats is the thing that makes the library usable in a mixed codebase, where some charts come from application code and some from model output.

The package ships for every module system, plus an MCP server

The package metadata is worth reading for the deployment details.

The package name is `@antv/gpt-vis` at version 1.0.2, marked `sideEffects: false` and `type: module`. It publishes a CommonJS entry at `dist/cjs/index.js`, an ES module entry at `dist/esm/index.js` with types at `dist/esm/index.d.ts`, and UMD builds for jsDelivr and unpkg at `dist/umd/index.min.js`. The `files` array includes `dist` and the READMEs, and explicitly excludes `dist/umd/report.html`.

The build uses father, with `build` running `father build && limit-size`, and `dev` running `father dev`. That `limit-size` step is a bundle size budget, which tells you the project treats package weight as a constraint, sensible for a library that ships into someone else's application.

The scripts also cover linting with `lint:ts` running eslint over `src`, formatting through prettier, `test` running vitest, and a `registry:build` step that shells out to the shadcn CLI to build `cn/registry.json`, which is how the component registry is generated.

Alongside the library there are two related projects. The documentation links an MCP Server at the antvis/mcp-server-chart repository, and a Chart Skill under `skills/chart-visualization` in this repository. The skill is the same idea as the library seen from the agent side: it tells a coding agent how to emit valid chart specifications, and the MCP server is the tool interface an agent calls. The repository top level also carries `skills/`, `cn/`, `bindings/`, `evaluations/` and `__tests__/` directories, plus a `CLAUDE.md` and a `.claude/` directory, which is the shape of a project that is being developed with an AI assistant in the loop rather than only shipped to one.

Where GPT-Vis is the wrong tool

Three boundaries are worth naming.

The first is that the chart list is fixed. Twenty six types is a lot, and it covers the mainstream cases, but there is no general escape hatch documented for a custom visualisation. If your requirement is a chart type that is not in the list, or a bespoke rendering of your data, the object config path does not obviously extend to something new, and the DSL certainly cannot express it. The families are also uneven in depth: eighteen statistical types against six relationship types and two text types.

The second is that the library is a renderer, not a data tool. It will not aggregate, pivot, join or filter. It also does not tell you where the numbers came from, so the usual question of whether a chart is showing the right series is still yours. In a dashboard, the surrounding work of getting data into the right shape still has to happen somewhere.

The third is dependency management. The component package is pinned exactly at 2.1.11 while G2, G6 and T8 use ranged versions, so the versions you get can drift within those ranges; if your application needs a specific version of one of them, you have real constraints to reconcile.

The alternative to name is a general purpose charting library driven by plain JavaScript configuration, which you would have to write a prompt-to-configuration layer on top of yourself. The difference in approach is that GPT-Vis moves that layer into the library, with a DSL designed to be emitted by a language model and a renderer that tolerates partial input, whereas a general charting library gives you full control of the configuration and none of the streaming behaviour. If you are rendering model output, that is the trade in one line.

Editorial conclusion

Adopt GPT-Vis if you are rendering charts from language model output, since the markdown-like DSL and the streaming renderer are built for exactly that and the object config path is there when you want determinism. Do not adopt it as your general charting library, because the 26 chart types are a fixed list and the DSL is not a data analysis format. Verify first that the chart you need has a type identifier in the list, that the partial data your model emits mid-stream is handled by the fault tolerance path, and that the bundled chart packages match the AntV G2, G6 and T8 versions you already use elsewhere.

Frequently asked questions

Official sources

1. antvis/GPT-Vis on GitHub
2. License: MIT
3. Project website
4. README
5. Releases