OpenEik.org
The open building model for AI agents. The building, stored as a code base.
BIM coordination for the agentic era.
One open building model that every discipline and every AI assistant works on together. Agents draft the changes, people review exactly what changed, and the whole team works against the same current model.
Ask
Tell Claude, ChatGPT or Copilot what you need. Your assistant edits the model directly: walls, doors, beams, loads.
See the change
Every edit is a readable diff: the door that moved, and nothing else.
Check and review
Checks run before anything merges, and the discipline that owns the part approves it.
Everyone is current
Architect, engineer, contractor and client work on the same model the moment it merges.
IFC won't cut it.
IFC stores what a building looks like, not what it is. A wall arrives as a mesh with its door holes already cut. Ask an AI agent to change it and it edits dead geometry.
- Move a door, and the old hole stays in the wall.
- Move a column, and it no longer stacks.
- Shorten a corner, and the walls no longer meet.
of IFC editing tasks fully solved, at best. Seven current models, 324 tasks.
BIM-Edit, June 2026[1]
One change, many places
A window is not one record. It is a placement, an opening cut in the host wall, and the relations that tie them together. Move the window and the opening must move with it[1]. Miss one, and the file stays valid while the building is wrong.
Positions are chains
Every placement is relative to another placement, often several levels up. Agents lose track of coordinates and relative placement[2].
A numbered graph, not a text
A real building is hundreds of thousands of lines that point to each other by number. No line makes sense on its own, so the agent has to query the model with code, and it under-explores what is nested deep[3].
Valid is not right
A schema check only proves that the file is well formed. It says nothing about whether the door is where it should be. In our runs, every failing agent reported success.
On BIM-Edit, the first shared benchmark for editing IFC, the best of seven current models averages 49.5%, and none fully solves more than 3.4% of its 324 tasks[1]. An agent building IFC models through MCP and IfcOpenShell wrote schema-valid files in every run, yet reached only 40% and 49% model success on two of its six test cases[2]. Even reading IFC is hard: the best agent on ifc-bench v2 answers 56.6% of questions, which its authors call insufficient for unsupervised use in safety-critical work[3].
Code review works because a diff shows exactly what changed. IFC cannot give you that. A model from leading BIM software, exported twice with nothing changed, differed in 18,659 lines. After five objects were removed and five added, about 295,000 of its 297,000 lines changed[4].
The reason is in the format. IFC is a graph written out as a list, and an exporter is free to number and order it differently every time, so an identical building can come out as a totally different file[4]. In OpenEik every element is its own small file, so the diff of a moved door is the moved door.
of the file rewritten after five objects were removed and five added.
lines changed between two exports of the same, unchanged model.
Liu, Gao, Gu, EG-ICE 2023[4]
We measured it ourselves on the L-house sample: one window moved 50 cm along its wall.
OpenEik: git diff
architecture/level-0/window/study-window-east.json - "along": 1100, + "along": 1600, - "revision": 2, + "revision": 3,
One file, named after the window. Two lines: the position in millimetres, and the revision that marks the record as changed.
IFC: git diff
house.ifc | 4724 ++++++++++---------- -#2088=IFCINDEXEDPOLYGONALFACE((8,7,28,27,6,5)); +#2092=IFCINDEXEDPOLYGONALFACE((8,7,28,27,6,5)); -#2093=IFCINDEXEDPOLYGONALFACE((27,28,25,24)); +#2097=IFCINDEXEDPOLYGONALFACE((27,28,25,24)); -#2095=IFCINDEXEDPOLYGONALFACE((15,18,19,22)); +#2099=IFCINDEXEDPOLYGONALFACE((15,18,19,22)); -#2096=IFCINDEXEDPOLYGONALFACE((29,32,36,33)); +#2100=IFCINDEXEDPOLYGONALFACE((29,32,36,33)); -#2099=IFCINDEXEDPOLYGONALFACE((39,40,38,37)); +#2103=IFCINDEXEDPOLYGONALFACE((39,40,38,37)); … and 4,714 more changed lines
The same faces under new numbers. The move itself is a corner point that went from (12000, 4000, 900) to (12000, 3500, 900), somewhere in between.
L-house sample, measured on 14 and 15 October 2026 · the whole comparison on /why
- Nithyanantham, Kujat, Sesterhenn, Telgmann, Nedungadi, Plönnigs, Bartelt, Lüdtke. BIM-Edit: Benchmarking Large Language Models for IFC-Based Building Information Modeling. arXiv:2606.20146, 2026.
- Heimig-Elschner, Du, Scheuvens, Borrmann, Beetz. A Modular Reference Architecture for MCP-Servers Enabling Agentic BIM Interaction. arXiv:2601.00809, 2025.
- Hellin, Jang, Fuchs, Nousias, Borrmann. BIM Information Extraction Through LLM-based Adaptive Exploration. arXiv:2605.01698, 2026.
- Liu, Gao, Gu. A Parallel IFC Normalization Algorithm for Incremental Storage and Version Control. EG-ICE 2023, pp. 511–520 (arXiv:2312.14931).
- Autodesk. Export a PDF File. Revit 2026 Help.
- Autodesk. Issue a Revision. Revit 2026 Help.
LLMs are amazing at code bases.
They search, read the few files that matter, change one line and run the checks. So we made the building a code base.
One record per file, in meaningful folders. Intent instead of meshes. Bodies, joins, openings and quantities are derived by an engine that checks every change before it is saved.
Right every time. And four times faster.
Benchmark on the public L-house sample, 15 October 2026: the same 18 edits in each format, made by Claude Sonnet agents with live tools and judged by geometry against the engine. The IFC agents got every edit right as well, but took 6 to 11 times as long to move or delete a door or a window, because an exported wall carries its holes cut into its mesh. On two large client buildings (internal, 10 October 2026), they got 7 of 18 right; OpenEik got all 18.
Everything software has had for decades. Now for buildings.
Diffs
See exactly what changed: the door that moved, and nothing else.
~ doors/D-104.json x 4200 → 4800Merges
Two people change different parts of the building, and the changes merge cleanly, because every element is its own file.
merge option-b → main · 0 conflictsFull history
Every change, who made it, when and why, back to the first sketch. Any version can be brought back.
git log struct/L3/columns/C-12.jsonDisciplines, side by side
Architecture, structure and MEP work in the same model at the same time, each in its own part of the tree.
arch/ struct/ mep/ site/Many users
Everyone works on a branch. Changes are reviewed and merged, the way a software team works.
change #42 · approved by structureForks
Try a whole alternative design on a fork without touching the main model, and keep the better one.
fork main → timber-frameWhat changed? Read it, in the model and on every drawing.
Revit, the leading BIM software, keeps a model in one closed file and sends its drawings out as PDFs, so a change is found by eye. OpenEik writes the change down, in 3D and in 2D, for people and for AI.
study-window-east, moved 500 mm along its wall, glowing where it is now beside an outline of where it was. Open it live on EikHub. EikHub is one hub built on OpenEik, and the X-ray is its own look; the change it shows is in the open files.Revit
The model is one binary .rvt file: no text that a person or an AI can diff.
A drawing leaves as a PDF, and Revit's PDF export has no option for the elements behind its lines[5]. Two issues are compared as pictures laid over each other.
Marking a revision Issued locks its row in the table of revisions[6], not the drawing, and nothing built in tells which drawings a model change affects.
OpenEik: openeik drawing diff
A-101, P01 to P02 changed study-viewport-0/study-wall-1 changed study-viewport-0/study-window-east changed study-viewport-1/study-wall-1 changed study-viewport-4/study-wall-1 changed study-viewport-4/study-window-east
In 3D the moved window is a two-line diff of its own file. In 2D every line of an issued drawing names its element, so the drawing's diff names the same window, and the wall it moved in, in the plan, the section and the east facade.
Before anyone merges, the drawings a change makes stale are known, and each sign-off is signed over the exact bytes it approves.
For reviews, people read the change instead of hunting for it. For contracts, the files say exactly what changed and who approved which drawing, and anyone can check it. The 2D diff is the prototype's A-101, compared element by element · Part XIV · more on /why
Review a drawing like code.
See what changed on a drawing, because you can see what changed in the building.
study-window-east, moved 500 mm along its wall between P01 and P02: 6.67 mm of paper. Computed from the prototype's two issued revisions of this L-house sheet, in the X-ray look EikHub is building. An illustration, not a drawing in the format.Every line knows its element
An issued drawing is an SVG whose derived lines carry the id of the element that drew them. A review pairs two revisions by element, and explains each change from the model.
study-window-east along 1100 → 1600Stale before you merge
Each issue keeps what it was drawn from: the version, the view and the records it read. So any change, even an unmerged proposal, shows which issued drawings it makes stale.
A-101, A-104 stale · 2 currentApprove the exact bytes
Where a sign-off is needed, it is a signed statement over the drawing's digest, which anyone can check without the host. Reviews and sign-offs are files in the format, so the building keeps the conclusion.
signed · sha256 of A-101 P02Part of OpenEik 0.2 as Part XIV, decided on 15 October 2026 and prototyped on the L-house. Hashes of what each sheet was drawn from flagged the two changed sheets of four in about 20 ms, and missed none. Authoring tools change the building and issue its drawings; a hub runs the review, and the authoring tool saves its conclusion into the building with the next revision. EikHub is one such hub and is building this review; its 3D compare between versions is live: the L-house review example on EikHub, with its issued drawings.
Finally, one model.
Always up to date.
For everyone.
No more hundreds of drawings and PDFs drifting out of step. One BIM model is the single source of truth that every discipline works against, and it is right there in ChatGPT, Claude or Copilot.
Move the stair core 600 mm east.
Which beams changed since Monday?
How much façade is left to order on level 3?
What is the opening height at grid C4?
Show me the flats with south-facing balconies.
Build it. Change it. Measure it. Check it.
An agent reads a model in tenths of a second and changes it with a validated command.
Every write is checked against the whole model. A change that would break it is refused with a reason.
The standard and its engine core are open. IFC stays as a bridge for export and import.
EikHub
Where buildings branch, get reviewed and merge, the way software does.
OpenEik works today and is in testing with early users. The current version is OpenEik 0.4; 0.3, 0.2 and 0.1 are kept as they were. It opens to the public at a release whose date is not set yet: the specification, the engine core and the benchmark.
Where the standard stands, and what comes next: the roadmap →
Show it.
Put the badge on your site or in your README when your tool reads and writes OpenEik folders that pass ek validate. The full conformance suite comes with the public release.
See the apps that already work with OpenEik →
<a href="https://openeik.org"><img src="https://openeik.org/badge/openeik-compatible-light.svg" alt="OpenEik compatible" height="40"></a>[](https://openeik.org)