> For the complete documentation index, see [llms.txt](https://docs.protoboard.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.protoboard.xyz/help/known-limitations.md).

# Known Limitations

Current product limitations, expected behavior boundaries, and workarounds.

Protoboard is in **alpha**. The core workflow (place parts, connect them, validate, export) is solid, but there are rough edges. This page documents the current limitations so you know what to expect and can plan around them.

{% hint style="warning" %}
**Alpha software.** Expect breaking changes between versions. We'll document significant changes in the [Changelog](/help/changelog.md) and try to migrate your data automatically, but back up important boards regularly.
{% endhint %}

***

## Parts library coverage

The parts library is growing but doesn't have every component. You may not find your specific part, especially for niche, very new, or region-specific components.

**Workaround:** Create a [blank part](/user-guide/parts-add-edit-custom.md) with the correct interfaces and resources. Blank parts work identically to library parts for DRC and BOM purposes. You can add manufacturer info and pricing manually.

{% hint style="info" %}
**Contributing parts:** The ProtoPart library is open source. If you create a well-defined blank part, consider contributing it back to the library so others can benefit.
{% endhint %}

***

## ProtoBot accuracy

ProtoBot's quality depends on the AI model you select and the specificity of your prompt. Lighter models are faster and cheaper (less energy) but may misunderstand complex requests. Heavier models handle nuance better but consume more Wh.

**What to expect:**

* Simple tasks (search, place, basic wiring) work reliably across most models
* Complex tasks (multi-step DRC diagnosis, architecture suggestions) benefit from more capable models
* ProtoBot may occasionally suggest incorrect fixes, so always review its changes before accepting

**Workaround:** Use specific, detailed prompts. Break complex tasks into smaller steps. Switch models if the current one isn't performing well. See [prompt patterns](/protobot/how-to-use.md#prompt-patterns) for tested prompts.

***

## No real-time collaboration

Only one user can edit a board at a time. There's no live cursor, no concurrent editing, and no conflict resolution for simultaneous changes.

**Workaround:** Coordinate with your team on who's editing which board. Use the Share feature for view-only access so others can review without risking conflicts. Duplicate boards if multiple people need to experiment independently.

***

## Export format limitations

The BOM currently exports to **CSV** and **PDF** only. There's no export to EDA formats like KiCad, Eagle, or Altium.

**What this means:** Protoboard validates your design and produces a parts list, but you'll need to recreate the schematic in your EDA tool of choice. EDA export is on the roadmap.

**Workaround:** Use the CSV export to import your parts list into your EDA tool's BOM manager. The part numbers and manufacturer data carry over cleanly.

***

## Domain validation depth

Electrical domain validation is the most mature. Thermal, mechanical, pneumatic, and hydraulic domain validation is more basic.

**What to expect:**

{% columns %}
{% column %}

### Strong validation (Electrical)

* Voltage domain compatibility
* Protocol matching (I2C, SPI, UART, etc.)
* Role complementarity
* Resource allocation and contention
* Bus capacity and addressing
  {% endcolumn %}

{% column %}

### Basic validation (Other domains)

* Interface pairing and role matching
* Basic resource allocation
* Limited cross-domain checks (e.g., thermal impact of electrical current draw)
  {% endcolumn %}
  {% endcolumns %}

**Workaround:** For mechanical, pneumatic, or thermal designs, use Protoboard for system-level architecture validation and rely on domain-specific tools (CAD, CFD) for detailed analysis.

***

## OpenAI models only

ProtoBot currently supports OpenAI models only (gpt-5.4 and gpt-5.5). Other providers are not available at this time.

***

## Energy consumption variability

Different AI models consume energy at very different rates. A complex request to a capable model might use 5-10x the energy of the same request to a lighter model.

**What to expect:** Your daily energy budget may last anywhere from a few dozen to a few hundred interactions, depending on your model choices and request complexity.

**Workaround:** Monitor your energy balance in the ProtoBot panel. Use lighter models for routine tasks (search, placement) and reserve heavier models for tasks that benefit from deeper reasoning (DRC diagnosis, architecture review). See [Usage, Energy, and Privacy](/protobot/usage-and-energy.md).

***

## Board complexity limits

Very large boards (50+ parts with complex interconnections) may experience slower canvas rendering and longer DRC run times.

**What to expect:** The canvas remains usable, but interactions may feel sluggish. DRC may take several seconds instead of being near-instant.

**Workaround:** Split very large systems into multiple boards organized by subsystem. This also makes designs easier to understand and maintain.

***

## Offline access

Protoboard requires an internet connection. You can't use it offline.

**What to expect:** If you lose connectivity mid-session, edits may not save. The autosave system helps prevent data loss, but it's not a substitute for a stable connection.

**Workaround:** Work on a stable connection. If you're in a low-connectivity environment, consider exporting your board data before going offline.

***

## Browser compatibility

Protoboard is optimized for Chromium-based browsers (Chrome, Edge, Brave). Firefox and Safari are generally supported but may have minor rendering differences, especially on the canvas.

**Workaround:** Use the latest version of Google Chrome for the best experience.

***

## Feature requests and roadmap

Have a feature in mind that would solve one of these limitations? Use the **feedback button** in the app. Feature requests directly inform the roadmap, and frequently requested features get prioritized.

***

## Related pages

* [**Changelog**](/help/changelog.md): See what's changed recently
* [**FAQ**](/help/faq.md): General questions and answers
* [**Troubleshooting**](/help/troubleshooting.md): Fixes for specific issues


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.protoboard.xyz/help/known-limitations.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
