Instructions to use fdtn-ai/antares-1b with libraries, inference providers, notebooks, and local apps. Follow these links to get started.
- Libraries
- Transformers
How to use fdtn-ai/antares-1b with Transformers:
# Use a pipeline as a high-level helper from transformers import pipeline pipe = pipeline("text-generation", model="fdtn-ai/antares-1b") messages = [ {"role": "user", "content": "Who are you?"}, ] pipe(messages)# Load model directly from transformers import AutoTokenizer, AutoModelForCausalLM tokenizer = AutoTokenizer.from_pretrained("fdtn-ai/antares-1b") model = AutoModelForCausalLM.from_pretrained("fdtn-ai/antares-1b", device_map="auto") messages = [ {"role": "user", "content": "Who are you?"}, ] inputs = tokenizer.apply_chat_template( messages, add_generation_prompt=True, tokenize=True, return_dict=True, return_tensors="pt", ).to(model.device) outputs = model.generate(**inputs, max_new_tokens=40) print(tokenizer.decode(outputs[0][inputs["input_ids"].shape[-1]:])) - Notebooks
- Google Colab
- Kaggle
- Local Apps Settings
- vLLM
How to use fdtn-ai/antares-1b with vLLM:
Install from pip and serve model
# Install vLLM from pip: pip install vllm # Start the vLLM server: vllm serve "fdtn-ai/antares-1b" # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:8000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "fdtn-ai/antares-1b", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker
docker model run hf.co/fdtn-ai/antares-1b
- SGLang
How to use fdtn-ai/antares-1b with SGLang:
Install from pip and serve model
# Install SGLang from pip: pip install sglang # Start the SGLang server: python3 -m sglang.launch_server \ --model-path "fdtn-ai/antares-1b" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "fdtn-ai/antares-1b", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }'Use Docker images
docker run --gpus all \ --shm-size 32g \ -p 30000:30000 \ -v ~/.cache/huggingface:/root/.cache/huggingface \ --env "HF_TOKEN=<secret>" \ --ipc=host \ lmsysorg/sglang:latest \ python3 -m sglang.launch_server \ --model-path "fdtn-ai/antares-1b" \ --host 0.0.0.0 \ --port 30000 # Call the server using curl (OpenAI-compatible API): curl -X POST "http://localhost:30000/v1/chat/completions" \ -H "Content-Type: application/json" \ --data '{ "model": "fdtn-ai/antares-1b", "messages": [ { "role": "user", "content": "What is the capital of France?" } ] }' - Docker Model Runner
How to use fdtn-ai/antares-1b with Docker Model Runner:
docker model run hf.co/fdtn-ai/antares-1b
Observations from LoRA fine-tuning and custom tool harness experiments
Hi, I've been experimenting with Antares-1B for vulnerability localization across several large OSS projects. Sharing some observations that might be useful for the community and the team.
Setup
- MLX 4-bit quantized on Apple Silicon (M-series, ~1GB model size)
- Tested on ~500 entries across multiple repos (TensorFlow, GitLab CE, Angular, Go stdlib, gVisor, protobuf)
- Built a custom v2 tool harness replacing the terminal interface with structured tools:
inspect(tree/symbols),search(literal/regex/sink),read(file,start,end),finish(files/reason) - Also trained LoRA adapters (rank=16, 16 layers) on ~400 correct trajectories
Key Findings
1. Performance varies dramatically by CWE type
| CWE Category | Correct Rate | Characteristic |
|---|---|---|
| CWE-208 (Timing), CWE-522 (Credential), CWE-367 (TOCTOU) | 75-100% | Sink has a clear keyword to search |
| CWE-20 (Input Val), CWE-125 (OOB Read), CWE-476 (NULL Deref) | 38-42% | Multiple patterns, needs context |
| CWE-190 (Integer Overflow), CWE-754 (Unusual Check), CWE-79 (XSS), CWE-444 (HTTP Smuggling) | 0-17% | Requires semantic understanding or cross-file comparison |
The model excels when the vulnerability has a searchable keyword (e.g., bytes.Compare, Proxy-Authorization). It struggles when the vulnerability requires comparing two code paths or understanding missing checks.
2. Structured tools improve speed but not accuracy on hard CWEs
The v2 tool harness reduced per-entry time from ~55s to ~20s (with KV cache reuse) and eliminated infinite loops (duplicate call detection + forced finish). However, accuracy on hard CWEs (190/754/79/444) remained low β the bottleneck is the model's search strategy, not the tool interface.
3. Large repos need scope limiting
On repos with 100K+ files (e.g., GitLab CE), the model gets lost even with MAX_FILES_SCAN limits. Scoping to a subsystem directory (~234 files) works much better. This matches real-world usage where you'd point the agent at a specific subsystem, not the entire monorepo.
4. LoRA v1 (terminal tools) doesn't transfer to v2 (structured tools)
LoRA trained on terminal-based trajectories doesn't work with structured tools β the model keeps trying to emit grep commands instead of using search(). Retraining with v2 trajectories is necessary.
Questions for the team
Is a 3B version planned? The 1B model's main limitation isn't tool use but search strategy on complex CWEs. Would 3B meaningfully improve the model's ability to reason about which patterns to search for?
Training data composition β Does the training data include negative examples (repos without the stated CWE)? The abstention issue from discussion #2 suggests it doesn't. We found that the model submits files 100% of the time, which aligns with Endraal's observation.
CWE-specific guidance β Have you experimented with injecting CWE-specific search strategies into the system prompt? We built a
SINK_DBmapping CWE IDs to regex patterns, which helps the model know what to search for. Curious if the training data already encodes this implicitly.Optimal turn budget β The paper mentions 15 terminal commands. We found that correct answers cluster at 3-5 turns (55% correct) while 15-turn entries are almost always wrong (2.8%). Is this expected? Should the budget be dynamic based on repo size?
Thanks for open-sourcing this β it's a genuinely useful foundation for security tooling even with these limitations.
Thanks for the thorough writeup, this is a genuinely useful analysis. The CWE-type breakdown especially: the split between keyword-searchable sinks (timing, credential, TOCTOU) and bugs that need cross-path or missing-check reasoning (integer overflow, XSS, smuggling) matches what we see, and it lines up with an IDOR/access-control case another user reported.
On your questions:
Antares-3B is coming soon. We can't share more of the roadmap, but your read is right that the interesting headroom on complex CWEs is in search strategy and reasoning rather than tool use, and that's exactly where more capacity helps.
Not yet, and you inferred that correctly from the large submit rate. Real abstention on patched code is the first thing on our priority list, it's an explicit behavior target for the next iteration rather than something we've solved.
Really cool direction, and no, there's no CWE-to-pattern injection at the search level. Our aim was for the model to internalize vulnerability-oriented search behavior and CWE reasoning directly, but seeding an LLM with something like your SINK_DB from the start is a genuinely interesting angle we hadn't framed that way.
That's expected, the 15 is a hard ceiling, not a target. We enable dynamic budgeting in our own benchmarks: the model can submit early or keep going, so the easy, cleanly-localizable cases resolve fast, which is why correct answers cluster early. Budgeting by repo size on top of that is a reasonable idea.
Thanks again for sharing all of this, experiments like yours are what help us prioritize.