Arkor
Fine-tune and Deploy Open-weight Models in TypeScript
195 followers
Fine-tune and Deploy Open-weight Models in TypeScript
195 followers
Start a real LLM training in 10 minutes. Tell Claude Code or Codex what the model is for; they prepare the datasets and create the training project. Click "Run Training" in the local studio. Arkor runs the training, and deploys the trained model as an OpenAI-compatible API. Think Next.js and Vercel for fine-tuning: code you can review, infrastructure you do not have to manage, and a model your app can call. No GPU setup. No ML expertise required. No Python training code to write.
Free
Launch Team / Built With
Render: Get up to $100K in startup creditsThe fastest way to launch and scale your startup in the cloud
Promoted
Hi Product Hunt! 👋
I’m Hina, one of the makers of Arkor.
We built Arkor because we kept running into the same gap: adding an AI feature to an application is easy, but adapting a model to a specific task still feels like joining an ML infrastructure team.
The moment you want to fine-tune, you often end up maintaining a separate Python project, converting datasets into unfamiliar formats, provisioning GPUs, and moving between scripts, notebooks, and dashboards.
We wanted model development to feel more like ordinary software development.
With Arkor, the workflow starts inside your existing repository:
Tell Claude Code or Codex what behavior you want from the model.
Your coding agent can find or prepare a dataset, write conversion scripts, create the TypeScript trainer, and add evaluation.
Review the generated code and changes.
The agent runs pnpm dev, and Arkor Studio opens locally at localhost:4000.
Click Run Training, monitor the loss and checkpoints, test the trained adapter, and deploy the result.
For example, you can give your coding agent a prompt like:
Arkor is not intended to be a magical prompt-to-model black box. It is a developer-controlled workflow where coding agents can handle much of the setup, while the training code, data transformations, evaluation, and final decisions remain visible and reviewable.
We’re especially interested in feedback on:
Whether the coding-agent workflow feels intuitive
Which parts of fine-tuning still feel unclear or intimidating
What you would need before using Arkor for a production model
Which models, datasets, and deployment workflows we should support next
Thanks for checking out Arkor. We’ll be here throughout the launch and would love to hear what you try building. 🙏
@thys_beesman Hey Brandon, I really appreciate your comments!
You’re right, and this is exactly the kind of failure a healthy-looking loss curve will not reveal.
Arkor Studio does not currently detect train/validation leakage, near-duplicate overlap, or insufficient deduplication automatically. Today, those checks have to be defined in the project’s dataset preparation and evaluation code.
For a framework intended to make fine-tuning accessible to developers who may not already know these failure modes, we do not think that is sufficient. Studio and the framework should provide a preflight layer before GPU time is spent, including split-overlap checks, exact and near-duplicate detection, malformed-example checks, and visibility into eval coverage.
We’re on it.
This is one of the clearest pieces of feedback we’ve received today, and it is helping us prioritize the right responsibility for Studio.
Would you expect these checks to block the run by default, or surface warnings and let the developer decide?
the eval/leakage question below is the big one, but there's a second thing nagging me: this workflow lives inside your existing repo, with the coding agent preparing the dataset alongside the code. does that mean the actual training examples end up committed to git history by default? if someone points this at a real support-ticket or user-message dataset to fine-tune on, that's real customer data now living in version control unless you go out of your way to gitignore it - feels like an easy footgun for anyone who isn't already thinking about data handling.
@galdayan Hey Gal, thank you for commenting!
Great point. The intended default is not to store raw training data in the repo. Arkor is designed to reference datasets hosted on Hugging Face, but we also support local JSONL files.
You’re right that local files create an easy footgun. Without the right safeguards, real support tickets or user messages could accidentally end up in Git history.
For a framework aimed at developers who may be new to fine-tuning, we should not leave that entirely to the user.
Adding dataset paths to .gitignore by default, warning when local training files are tracked, and surfacing data-handling checks before training are guardrails we should provide.
This is a genuinely helpful point.
Would a default ignore plus a warning for tracked dataset files address the main risk you’re thinking of, or would you expect stricter handling of local datasets?
@nhina default ignore plus a tracked-file warning would cover the main risk for me - that's the classic case of someone dragging a real ticket export into a local folder without thinking twice. stricter handling (like a content scan for anything that looks like PII) is probably overkill for v1 and would slow down the exact devs you're trying to onboard. this is a solid answer, thanks for taking the question seriously instead of brushing it off.
@galdayan
Hey Gal, thanks for replying back to me!
I agree that a default ignore plus a tracked-file warning is the right v1 scope. It addresses the most likely mistake without adding friction or pretending we can reliably classify every sensitive dataset.
We’ll treat local training data as something the framework should protect by default, rather than expecting every developer to remember the right Git hygiene. Really appreciate the concrete feedback.
@nhina that's the right way to think about it - protect by default beats hoping every dev remembers. good luck with the launch
curious about the "no ML expertise required" claim specifically - when Claude Code or Codex picks the hyperparameters and dataset splits, how do you know the fine-tune actually improved anything vs just memorized the training set? that eval step usually needs someone who knows what they're looking at, not just infra automation.
@omri_ben_shoham1 Hi Omri! That’s a fair challenge.
Studio lets you inspect training and validation loss, but loss alone cannot tell you whether the model generalized or simply memorized the training set.
You’re also right that “no ML expertise required” is too broad.
What Arkor removes today is the need to maintain a Python training stack, provision GPUs, and build the training and serving infrastructure yourself. A meaningful held-out eval set and task-specific success criteria still matter.
One reason we started with the Gemma 4 was to keep the initial use case focused.
A common workflow is to use a larger model to generate or label examples for a clearly defined task, then fine-tune a smaller model to reproduce that behavior. We think that can work well for application-level semantic tasks such as classification, extraction, routing, and rewriting.
We also think evaluation needs to become a first-class part of the Arkor framework. Projects should be able to define task-specific evals in code, while Studio surfaces base-vs-adapter comparisons, data leakage and duplicate checks, and signs of overfitting before deployment. We are not fully there yet, but this is an important direction for us.
Thanks for pushing on the claim. We're going to position this more clearly.
What would be the most useful first step for you: automated dataset checks, base-vs-adapter evaluation on a held-out set, or support for custom task-specific metrics?
The 'tell Claude Code what the model is for and it preps the dataset' handoff is the part people usually stall on, so nailing that is smart. When I hit Run Training in the local studio, is the GPU compute actually local to my machine, or does it provision remote GPUs behind that UI — and does the deployed OpenAI-compatible endpoint live self-hosted or on Arkor's side? Also curious how Claude Code/Codex actually drives the dataset prep: an MCP server, a CLI it shells out to, or just file conventions in the project?
@noctis06 Great questions.
Today, Arkor Studio is a local control surface, but the actual training runs on Arkor-managed remote GPUs. The deployed OpenAI-compatible endpoint is also hosted by Arkor.
We started fully managed so people could try the entire workflow without provisioning GPUs or setting up serving infrastructure.
That said, we do not want Arkor to become a vendor lock-in. Self-hosting and more portable deployment options are on the roadmap.
Claude Code or Codex works the same way it normally does: you ask it to use Arkor to build a model for a specific task, and it edits the files in your local project, prepares the dataset workflow, writes the training script, and runs the project commands. There is no special MCP-only workflow required.
For your use case, would you prefer bringing your own GPU for training, self-hosting inference, or both?
Fine-tuning open-weight models in TypeScript is kind of unusual approach, most tooling for this is Python heavy. Makes it much more accesible for JS devs though. What models are supported so far?
@abdurrahman_fakhrul Hi Abdurrahman, thanks for commenting!
You’re right that the underlying training stack still relies heavily on the Python ecosystem.
Arkor wraps that into a TypeScript framework and managed runtime, so JS and TypeScript developers can build the workflow in their own project and go from training to serving without maintaining a separate Python stack or managing GPUs themselves.
For the initial release, we’re intentionally starting with Gemma 4 so we can make the full experience reliable end-to-end.
We’re already hearing requests for smaller models for lower latency and local inference, and expanding model support is on the roadmap.
What would you want to fine-tune, and for what kind of use case? A specific model family or size would be especially helpful as we decide what to support next.
Looks super cool guys! Curious to know though, how much control do users have when choosing which llm they can fine tune?
@lucapiekarski Thanks, Luca!
We’re starting with Gemma 4 for the first release, mainly so we can make the full workflow reliable before expanding the model catalog.
We’re already hearing requests for smaller models for low-latency or local use, plus voice and vision models, so those are definitely areas we’re exploring.
What are you hoping to build, and which model would you want to fine-tune?