oyildirim

/

CyberStrike-OffSec-35B

like 38

it cant even find the bug in:

<?php
show_source(__FILE__);
$username = "this_is_secret";
$password = "this_is_not_known_to_you";
include("flag.php");//here I changed those two
$info = isset($_GET['info'])? $_GET['info']: "" ;
$data_unserialize = unserialize($info);
if ($data_unserialize['username']==$username&&$data_unserialize['password']==$password){
echo $flag;
}else{
echo "username or password error!";

}

?>

tool calling is broken. useless!

Hi @ChristopherKai @OsperRuben ,

Thanks for the feedback — this is actually a valid point and I appreciate you raising it.

The tool calling issue you're experiencing is most likely caused by not using the --jinja flag when starting the server. I had initially missed including this in the model card instructions (which has now been fixed).

The fix

When using llama-server, you must use --jinja to enable proper tool calling:

# Correct — tool calling works
./llama-server -m model.gguf --jinja -ngl 99 -c 131072

# Wrong — tool calls will be output as plain text
./llama-server -m model.gguf --chat-template chatml -ngl 99

For vLLM:

vllm serve oyildirim/CyberStrike-OffSec-35B \
  --enable-auto-tool-choice --tool-call-parser hermes

Without these flags, the model outputs <tool_call>...</tool_call> as raw text instead of structured JSON in the API response.

If it still doesn't work with --jinja

This model was fine-tuned using LoRA — the base model weights (Qwen3.6-35B-A3B) were not modified. Tool calling capability comes entirely from the base model. If you're still experiencing inconsistent tool calling behavior after using the correct flags, that would be a base model (Qwen3.6) limitation, not something introduced by the fine-tuning process.

That said, this is an interesting case — I'll investigate the tool calling consistency further across different inference configurations.

I've also updated the model card with a dedicated Tool Calling section and FAQ to cover these setup requirements. Please give it another try with the correct flags and let me know how it goes.

Thanks again for the comments.

Thanks for the update. I agree that --jinja is required for llama.cpp to apply the repository’s tool-aware chat template, and I’ll retest with it enabled.

However, I don’t agree that any remaining inconsistency must be a Qwen3.6 base-model limitation. A LoRA/SFT/DPO fine-tune changes the effective model behavior at inference time and can preserve, improve, or degrade tool selection and structured-call reliability depending on the training data and preference optimization.

I’ll test the following separately:

1. llama-server with --jinja and the repository template.
2. The original Qwen3.6 base under the exact same runtime and tools.
3. CyberStrike under the exact same runtime and tools.
4. Valid tool selection, JSON arguments, multi-turn tool results, and repeated-call consistency.

For vLLM, please also confirm which exact parser you validated against this repository’s JSON format and which vLLM version you used. Was it specifically the hermes parser, and did you test multi-turn tool responses rather than only raw generation?

That A/B comparison will show whether the issue was only server configuration or whether the fine-tune altered tool-use reliability.

Hi @OsperRuben ,

After running an A/B comparison (base Qwen3.6 vs CyberStrike, same runtime and tools), it looks like you're on the right track. I was treating the issues as loop/hallucination side effects and trying to handle them on the inference side with template fixes, but the root cause appears to be that the DPO dataset broke the tool call structure itself. Since LoRA only trains an adapter, I didn't expect it could shift preferences this much — but it clearly did.

I'll revisit the DPO dataset, retrain, and publish the updated model along with A/B test results. Thanks for pushing on this.