Known limitations
What Ertas cannot do today, what is on the roadmap, and the workaround the docs recommend in the meantime.
Ertas is opinionated about what it ships. A small surface area that works well beats a large surface area that has rough edges, especially for a product whose output your users depend on. This page collects everything that the rest of the docs reference as "coming soon" into one place, with the workaround that lets you ship today and a sketch of what to expect when each item lands.
Items here are organised by where they affect you, not by team or priority. If a row says "Coming," it is genuinely on the roadmap. If a row says "Open question," it is being considered but not committed. If a row says "Not planned," it is not on the near horizon.
A page like this is only useful if it is honest in both directions, so it is checked against the shipped product rather than left to drift. Last reviewed against the product: 2026-07-25. When something here ships, it leaves this page and gains an entry in the changelog; if you find an entry that the product has already outgrown, that is a docs bug worth reporting.
Models and architectures
Mixture-of-experts (MoE) bases
Status: Not in the catalogue. Trainable by bring-your-own if it fits the GPU.
This entry used to say MoE was architecturally unsupported. That is no longer the constraint. Ertas resolves LoRA target modules by inspecting the model's own module tree rather than matching against a per-architecture table, so an MoE model's expert projections are detected the same way a dense model's are. The detection is covered in Configuring a run.
What remains true is narrower, and it is about size rather than architecture:
- No MoE model is in the catalogue. Every model in the Supported models picker is dense, so MoE means the bring-your-own path: paste the Hugging Face repo into the model picker.
- Total parameters are what must fit, not active parameters. This is the thing that catches people out with MoE. A model advertised as "8x7B" or "30B-A3B" is cheap at inference because only some experts fire per token, but training holds all of them in VRAM. Mixtral 8x7B is 47B total, which is far past what our largest GPU tier handles (A10G realistically caps near 13B at 4-bit with LoRA). It will not train here regardless of how small its active-parameter count looks.
- Small MoE bases are a different story. An MoE whose total parameter count sits inside the tier limit is a normal bring-your-own run.
Workaround: Check the total parameter count first, not the active count or the marketing name. If it is over roughly 13B total, pick a dense model from the catalogue instead: most use cases that point at Mixtral are well served by Mistral 7B Instruct or Qwen 2.5 7B Instruct. Models past the size threshold still queue, but they carry a warning and failed runs at that size are not refunded.
Vision-language models (VLMs)
Status: Text-only training.
Llava, Qwen 2.5 VL, and similar multimodal bases are not in the catalogue, and the constraint here is the training data rather than the model tree: Ertas trains on text datasets (JSONL format), so there is no way to supply images as training examples. Bringing a multimodal base by Hugging Face URL adapts its text stack only. The vision tower is excluded from adaptation by design, so you would be fine-tuning the language half of a model whose visual grounding you cannot train.
Workaround: For image-to-text use cases, use a separate OCR step (Vision Framework on iOS, ML Kit on Android) and feed the OCR output to a text-only fine-tune. The Structured data extraction recipe demonstrates this pattern.
Quantisation and export
Quantisation levels beyond Q4_K_M
Status: Coming.
Q4_K_M is the only export quantisation today. The roadmap items:
| Level | What it gets you | Expected GGUF size vs Q4_K_M |
|---|---|---|
| Q5_K_M | Slightly higher fidelity | ~25% larger |
| Q8_0 | Near-fp16 quality | ~2x size of Q4 |
| Q3_K_M | Smaller for low-end devices | ~25% smaller |
| Q2_K | Smallest possible | ~40% smaller, measurable quality drop |
Workaround: Local re-quantisation using llama-quantize. This got materially easier when full-model safetensors export shipped: turn on "Export full model" in Training Config and you get a merged 16-bit checkpoint straight from the run, so the merge-with-base step is no longer yours to do. Convert that to GGUF and quantise it at whatever level you want. The Quantization page walks through the steps, and Safetensors overview covers the artifact itself. On the Free plan, where full-model export is not available, the older path (download the LoRA, merge against the base yourself, then quantise) still applies.
ONNX export
Status: Open question.
The transformers.js browser path, ONNX Runtime Mobile, Apple Core ML conversion, and server-side ONNX Runtime deployments all want an ONNX export. The roadmap question is whether to make this a first-class export choice in Ertas or to leave it as a post-training conversion path users run locally.
Workaround: Conversion from a LoRA-merged checkpoint to ONNX via Hugging Face Optimum is well-trodden; the path is outside Ertas today.
Content hash on published GGUFs
Status: Coming.
Ertas does not publish a content hash (SHA-256 or equivalent) alongside the GGUF download today. Integrity verification on first download, change tracking between fine-tune iterations, and supply-chain audit all benefit from one.
Workaround: Compute the SHA-256 yourself on first download and ship the expected hash inside your app's binary. The Verifying exports page and the Ship: model delivery page both document this pattern.
Training and dataset tooling
DPO training
Status: Coming.
Ertas's Fine-Tune Action Module trains with SFT. DPO (Direct Preference Optimisation) is the natural follow-up that lets you train on (prompt, chosen, rejected) preference triples to push past SFT's quality ceiling. See SFT vs DPO.
Workaround: Strong SFT covers most use cases. For the structured-output use case where DPO would help most, the Structured data extraction recipe describes the dataset shape DPO will eventually consume.
Evaluation suite
Status: Coming.
In-app eval that runs your probe set against a trained model and produces a graded table is not yet built. Held-out split detection (auto-attaching an HF dataset's validation split as eval), mid-training eval passes, LLM-judge integration, and common benchmark runners (MMLU, HumanEval, MT-Bench) are all on the roadmap.
What does exist in Studio: when a run finishes, the expanded run view shows 3 inference samples, generated by putting a small fixed set of prompts through the freshly trained model. That is a smoke test, not an eval. The prompts are not yours, there is no grade attached, and nothing is compared against a held-out split. It tells you the model produces coherent, on-format text; it does not tell you the model is good. See Training.
Workaround: Read the 3 samples first as a free coherence check, then run a real probe set after export. Every recipe in the Cookbook ships with one. The Verifying exports page walks through the local-runtime version, and Evaluating a model covers the heavier approaches.
Dataset export from Data Craft
Status: Coming.
Once a dataset is uploaded into Data Craft, there is no one-click export back to JSONL. Edits made inside Ertas cannot leave Ertas in dataset form today.
Workaround: Keep your original upload as the source of truth, version-controlled outside Ertas. Treat Data Craft edits as transient until export ships.
Dataset cleaning view
Status: Coming.
Bulk detection and fix of common dataset quality issues (formatting drift, accidental refusals, missing fields, length outliers, near-duplicates) is not built. Cleaning today is one row at a time in the Data Craft workspace.
Workaround: Pre-clean datasets in a tool you control before upload (Python + pandas, a spreadsheet, your editor of choice). Ertas's preview helps spot issues; the fix lives upstream.
Run config diff view
Status: Coming.
Comparing two completed runs side by side (LR, batch size, dataset, final loss, runtime) is not built. The Run panel shows each run's config individually.
Workaround: Screenshot or copy the configs into your notes. Most teams pin a "configs" doc per project with the comparisons they care about.
Log download
Status: Not planned.
There is no "Download logs" button on the Run panel. Errors are surfaced inline; the support path for deeper diagnosis is to send the run ID and have an Ertas agent pull server-side logs.
Workaround: Inline errors in the Run panel are usually sufficient. For deeper issues, the support flow in the FAQ.
Dataset attestation audit surface
Status: Coming.
The Hugging Face dataset import requires a rights-attestation checkbox and persists the attestation in metadata, but there is no user-facing audit view to review past attestations. Per-dataset attestation history and account-level CSV export are on the roadmap.
Workaround: Keep a local record of imports. The Import from Hugging Face page flags this in its current state.
Studio surface
CLI
Status: Coming.
There is no Ertas CLI today. The CLI page sketches what is planned: auth, datasets, recipes, runs, artifacts, sweeps.
Workaround: The canvas covers every action a CLI will expose. For sweeps, drop multiple Action Modules on the canvas and run them in parallel.
API and webhooks
Status: Coming.
There is no public API today, so CI integration ("merge a recipe PR, trigger a fine-tune") is not possible. Webhooks for run lifecycle events (started, completed, failed) are part of the same roadmap item.
Workaround: Human-in-the-loop. Designated reviewers open the project and press play.
Multi-account real-time collaboration
Status: Coming.
Multiple accounts editing the same canvas at once, with presence indicators, is not built. Two people cannot work on one canvas simultaneously.
Workaround: Share links, which shipped in June. Share a canvas by link and anyone can preview it without signing in, then import it into their own workspace with an Ertas account. The share is a snapshot taken at share time, so it hands over a working copy rather than a live session, which covers review and handoff even though it does not cover co-editing. See Sharing a canvas. Sticky notes on the canvas still help with shared context across sessions; see Managing projects.
Team roles (Business plan)
Status: Coming.
Owner / Editor / Viewer roles scoped per project are part of the Business plan roadmap.
Workaround: Until roles ship, project access is all-or-nothing per teammate. For sensitive projects, isolate them in their own account.
Billing caps
Status: Coming.
Monthly soft caps (notify above a threshold) and hard caps (refuse new runs above the threshold; active runs are never killed mid-flight) are not built.
Workaround: The per-run estimate is the control surface. Every run is quoted before you submit it and charged upfront at that estimate, so the spend decision happens at the moment you press play rather than accruing quietly while the run executes. A run that fails for a reason covered by the refund policy is refunded, and the Billing activity feed names the run against each charge and refund. For long sweeps, run a small calibration first and multiply, and check the Train All estimate before submitting a whole canvas at once. See Credits and usage.
Search within dataset preview, random shuffle
Status: Coming.
The Data Craft dataset preview lists the first N rows in order, with no search field and no shuffle. Because dataset export is also unbuilt (see above), there is no way to pull the full set back out and audit it elsewhere either, so the file you uploaded is the only complete copy you can search.
The row-review table in Prompt Studio is paginated, so imported rows can be walked page by page there. That is review of a generation batch, not search across a saved dataset.
Workaround: Audit your dataset before upload, in a tool where you can grep it. Keep that file as your searchable copy. The in-app preview is for spot checks.