AyoubChLin / lfm2.5-2.6b-fable5-coding-agent

LFM2.5-2.6B Fable-5 Coding Agent

This model is a full-parameter supervised fine-tune of LiquidAI/LFM2.5-2.6B on saidutta69/fable-5-premium . It was trained to produce assistant responses, including reasoning-style text and tool-call patterns, from multi-turn chat conversations.

All 2,697,198,592 model parameters were trainable. This is a complete BF16 model checkpoint, not a LoRA, QLoRA, PEFT adapter, or quantized-weight checkpoint. The 8-bit optimizer affected optimizer-state storage only.

Model details

The model card does not assign a license. Users should review and comply with the licenses and terms of both the base model and training dataset before use or redistribution.

Intended use

The model is intended for research and evaluation of conversational assistants, coding-agent behavior, long-context supervised fine-tuning, and structured tool-call generation.

Suitable exploratory uses include:

• multi-turn assistant responses;
• code generation and explanation;
• tool-call pattern generation when the application supplies and validates compatible tools; and
• further evaluation or domain adaptation.

The model should not be treated as production-ready on the evidence available here. It has not been evaluated for factuality, security, instruction following, code correctness, tool-call validity, safety, bias, multilingual performance, or robustness.

Training data

The run loaded one Parquet copy of each published openai_chat split to avoid duplicate rows from parallel JSONL and Parquet representations.

Only assistant tokens contributed to the loss. System, user, tool-result, and padding tokens were masked with label -100 . Assistant tool calls remained supervised. Rows truncated before any assistant output would have been removed; no rows were removed in the recorded run.

Training procedure

The run completed approximately 537 optimizer steps, consistent with 5,728 training examples over three epochs at an effective batch size of 32. The inline comment beside GRADIENT_ACCUMULATION still says the effective batch is 8; the configured values and executed output both establish that the actual effective batch was 32.

Checkpoints were saved with save_only_model=True ; they can be evaluated or deployed but cannot exactly resume optimizer and scheduler state.

Results

Training completed in 9,400.4 seconds (about 2 hours 36 minutes 40 seconds), at 1.828 samples/second and 0.057 optimizer steps/second. The run reported approximately 2.05e18 floating-point operations.

Perplexity is calculated as exp(loss) . These losses cover only the assistant tokens selected by the masking procedure, so they are not directly comparable with full-sequence language-model losses. The training loss is averaged over the optimization trajectory, while validation and test losses were measured after training; their values should not be compared as if they were measured at the same checkpoint under identical conditions.

No pre-fine-tuning baseline, external benchmark, confidence interval, or repeated-seed result was recorded. Consequently, the results establish held-out token-loss performance for this run but do not by themselves demonstrate an improvement over the base model or general task quality.

Qualitative observation

On a prompt requesting a Python interval-merging function, the model produced a reasonable high-level plan and emitted a Write(...) tool call despite no explicit tool schema being supplied in the prompt. The generated program was not correct as written: one multiline assert was syntactically invalid, and an adjacency test contradicted the implementation's last_end + 1 merge rule.

This single example is illustrative, not an evaluation. It highlights three deployment requirements:

1. Do not expose reasoning traces when the product requires hidden internal reasoning.
2. Parse, authorize, and validate every tool call in a sandbox; never execute generated calls directly.
3. Execute generated code against tests; plausible structure and self-generated assertions do not establish correctness.

Inference

import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model_id = "AyoubChLin/lfm2.5-2.6b-fable5-coding-agent"

tokenizer = AutoTokenizer.from_pretrained(model_id)
model = AutoModelForCausalLM.from_pretrained(
    model_id,
    dtype=torch.bfloat16,
    device_map="auto",
)

messages = [
    {"role": "system", "content": "You are a careful coding assistant."},
    {"role": "user", "content": "Write a tested Python function that merges overlapping intervals."},
]

inputs = tokenizer.apply_chat_template(
    messages,
    tokenize=True,
    add_generation_prompt=True,
    return_tensors="pt",
    return_dict=True,
).to(model.device)

with torch.inference_mode():
    output = model.generate(
        **inputs,
        max_new_tokens=768,
        do_sample=True,
        temperature=0.2,
        top_k=50,
        repetition_penalty=1.1,
        pad_token_id=tokenizer.pad_token_id,
        eos_token_id=tokenizer.eos_token_id,
    )

new_tokens = output[0, inputs["input_ids"].shape[1]:]
print(tokenizer.decode(new_tokens, skip_special_tokens=False))

Use the base model's native chat template. If tool use is enabled, provide explicit tool definitions in the serving layer and validate generated calls before execution.

Reproducibility notes

The source run used an NVIDIA H200 with BF16 support. It normalized OpenAI-style tool calls, tokenized with the native LFM2.5 chat template, preserved thinking content, and trained on assistant tokens only. The held-out test split was not used for optimization or periodic validation.

The training notebook is the authoritative source for implementation details. Before reproducing the run, import TrainingArguments before inspecting its signature, correct the stale effective-batch comment, restart the kernel, and execute every cell in order so the source and outputs cannot diverge.