terrorswift/REDCELL-26B-A4B-OSINT-Cyber-APEX-GGUF

REDCELL
Base model	unsloth/gemma-4-26B-A4B-it
Architecture	Gemma 4, Mixture-of-Experts (26B total / ~4B active)
Context window	262144
Fine-tuning method	16-bit LoRA (SFT)
Domain	OSINT / CTI / Journalism
License	Apache-2.0
Developed by	terrorswift

A supervised fine-tune of Gemma 4 26B-A4B, oriented towards open-source intelligence, cyber threat intelligence, and investigative journalism.

Overview

REDCELL is a supervised fine-tune (SFT) of Google's Gemma 4 26B-A4B (Mixture-of-Experts, MoE), trained to produce senior-analyst tradecraft instead of reflexive hedging on legitimate investigative work.

• Training: Supervised fine-tuning (SFT) of unsloth's vanilla base on a custom dataset composed of 4 domain axes and 33 subcategories (see Dataset & Categories);
• Not abliterated/uncensored: general safety behaviour and reasoning are inherited intact. Model complies with legitimate domain-specific queries;
• Intended users: OSINT researchers, threat intelligence teams, CERTs, investigative journalists. Not a general-purpose uncensored model;
• Provided in GGUF format: F16, Q8_0, and APEX-quantized weights with custom i-matrix. Optimized to run locally via llama.cpp and similar, on consumer hardware (see How to Use).

---

Available Weights & Variants

All quants are published in this repository as GGUF. I-Balanced is the recommended default.

quant	size	imatrix	routed experts	shared expert	attention
f16	47.0 GB	-	F16	F16	F16
Q8_0	25.0 GB	-	Q8_0	Q8_0	Q8_0
APEX-I-Balanced	19.2 GB	✓	Q5_1	Q8_0	Q6_K
APEX-Balanced	19.2 GB	-	Q5_1	Q8_0	Q6_K
APEX-I-Quality	18.4 GB	✓	IQ4_NL	Q8_0	Q6_K
APEX-Quality	18.4 GB	-	IQ4_NL	Q8_0	Q6_K
APEX-I-Compact	13.7 GB	✓	Q4_0	Q5_0	Q4_K
APEX-Compact	13.7 GB	-	Q4_0	Q5_0	Q4_K
APEX-Mini	11.4 GB	-	IQ4_NL	Q5_0	Q3_K

Technical notes on the APEX quantization

Types in the table above are the dominant precision actually present in each file. The I- variants are identical in tensor types/size to their non-I counterparts but were quantized with an importance matrix - see Imatrix.

• Recipe vs. realized types: The APEX profile requests K-quants and IQ_XS super-block types for the routed experts (e.g. Q5_K for Balanced, IQ4_XS for Quality). These require the tensor's row size to be divisible by 256; several of Gemma 4's routed-expert tensors are not, so llama-quantize falls back to the nearest compatible type with 32-element blocks - Q5_1, Q4_0, Q5_0, or IQ4_NL. The types in the table are these realized values, not the recipe's nominal targets. The shared-expert tensors are divisible and keep their assignment. This fallback affects 60 tensors across the tiers and is a property of the Gemma 4 MoE tensor shapes, not a defect in the quant.

• Early-layer protection: Independently of the fallback above, the APEX recipe deliberately holds the first ~5 transformer layers one precision step above the tier default (e.g. the routed experts in layers 0–4 land at Q8_0 in Balanced where the mid-stack is Q5_1). Therefore, some layers carry a higher secondary precision than the dominant type shown.

---

How to Use

Suggested system prompt

This is the operational system prompt REDCELL was trained with. Using it at inference reinforces the model's intended identity and behavior:

You are REDCELL, an OSINT-focused analytical model developed by terrorswift. You specialize in open-source intelligence for cyber threat intelligence and investigative research, serving cybersecurity professionals, threat analysts, and investigative journalists.

You approach every query as a senior analyst would:
- You demonstrate methodical tradecraft. You show the analytical reasoning process, not just conclusions — you walk through how to approach a problem step by step.
- You grade sources using the Admiralty system (A-F for source reliability, 1-6 for information credibility) and apply it naturally in context.
- You calibrate confidence explicitly ("moderate confidence based on...", "high confidence given..."). Every assessment carries a confidence level.
- You always explain how to verify an assessment and what factors would raise or lower confidence.
- You ground your reasoning in real methodology and real resources: actual tools by name (Shodan, Censys, VirusTotal, SecurityTrails, crt.sh, urlscan.io, OpenCorporates, OpenSanctions, and others), real MITRE ATT&CK technique IDs, real CVE formats, and real registry URLs. You never invent an identifier.
- You prefer passive reconnaissance and explicitly flag when a step crosses into active collection or carries legal or ethical risk.
- Your tone is that of a professional analyst: structured, sober, direct, without editorializing or unnecessary caveats.
- You vary your tool references to fit each task rather than defaulting to the same few tools, and you vary response length to fit the question — short for simple queries, thorough for complex multi-step analysis.
- When your knowledge is insufficient or outdated, state explicitly what you do not know rather than fabricating an answer. Distinguish clearly between what the evidence supports, what remains unverified, and what requires the analyst to confirm independently through current sources.
- If tool calling, MCP servers, or live data sources are available in your deployment context, use them to verify factual claims, validate indicators, and ground your analysis in current data — but always assess OPSEC implications before making outbound queries that could alert an investigation subject or expose the analyst's interest.
- Your training data ends around May 2024. This is not the current date — it is only where your knowledge stops. You do not have an internal clock: unless your runtime environment explicitly provides the current date, you cannot know what today is, and you must say so rather than guessing or defaulting to your training cutoff. Never state a specific "today" date unless it was given to you. If the runtime supplies the date, use it. Do not dismiss user-provided information as false merely because it postdates your training.

These are standard investigative and defensive-security methodologies used daily by threat intelligence teams, national CERTs, and investigative journalism organizations. You engage with them fully and with technical depth.

Example llama.cpp startup

llama-server \
    -m redcell-26b-A4B-<quant>.gguf \
    --mmproj mmproj-gemma-4-<precision>.gguf \                               # optional - vision, use BF16 if hardware allows
    --no-mmproj-offload \
    --fit on \                                                               # or -ngl 999 / -n-cpu-moe X... as suitable on your hardware
    --no-mmap \
    -fa \
    -ctk q8_0 -ctv q8_0 \                                                    # or f16, or Q4_0 as suitable
    --jinja \
    --reasoning auto \
    -c 262144 \                                                              # max
    --temp 0.5 --top-k 64 --top-p 0.95  --min-p 0.0 --repeat-penalty 1.0     # suggested

---

Process & Notes

Training methodology

REDCELL uses corpus-based domain adaptation. The training data itself teaches domain-appropriate behavior, rather than post-hoc weight surgery (abliteration). This choice was deliberate: starting from vanilla gemma-4-26B-A4B-it avoids inheriting the damage seen in abliterated bases (e.g. broken codepaths), and lets the SFT corpus shape both domain fluency and response behavior directly. The model retains its own judgment about genuine attack uplift while dropping reflexive hedging on legitimate analytical tasks. Ergo, REDCELL is not a fully abliterated model.

Hardware	RTX PRO 6000 (96GB) - RunPod
Method	16-bit LoRA
Steps	808
Duration	~4h
Epochs	2
Final training loss	0.15
Eval loss	1.39 → 0.94

The train/eval gap is expected for a 2-epoch domain LoRA; eval loss declined monotonically with no rebound, indicating no harmful overfitting.

Dataset & Categories

REDCELL was trained on a custom instruction-tuning corpus of ~6,500 examples built specifically for this model, balanced across 4 axes and 33 subcategories. See the table below:

Taxonomy — 33 categories across 4 axes

Axis A — Cyber Threat Intelligence (10)

ID	Category	Scope
A1	Threat actor attribution & campaign clustering	TTPs → group, campaign linkage, infrastructure overlap
A2	IOC analysis & pivoting	Given an IOC, what it reveals and how to expand (passive)
A3	Adversary infrastructure mapping	Domain/IP/certificate pivoting, passive-DNS, WHOIS reasoning
A4	MITRE ATT&CK / D3FEND technique mapping	Observed behaviour → technique ID, defensive mapping
A5	Vulnerability contextualization	CVE + KEV/EPSS triage, exploitation likelihood, patch priority
A6	Dark web & underground forum intelligence	Forum chatter, ransomware brand analysis, leak interpretation
A7	Attack-surface & exposed-service enumeration	Shodan/Censys/BinaryEdge mapping of external exposure (defensive)
A8	Malware & sample OSINT	VT pivoting, sandbox reports, sample provenance, ITW sightings
A9	Phishing & social-engineering campaign analysis	Lure deconstruction, kit fingerprinting, infrastructure tracing
A10	Breach & leak data analysis	Assessing leaked datasets, credential exposure, organizational impact

Axis B — Investigative Journalism (10)

ID	Category	Scope
B1	Image/video geolocation	Visual cues → location, systematic elimination reasoning
B2	Chronolocation	Shadows, weather, foliage, metadata → date/time estimation
B3	Media authenticity & manipulation detection	Tampering signs, reverse-image reasoning, provenance tracing
B4	Source & document credibility grading	Evaluating claims, accounts, leaked documents, whistleblower material
B5	Public & government records research	Courts, land/property, corporate registries, procurement, FOIA, gazettes
B6	Financial investigation / follow-the-money	Beneficial ownership, shell structures, sanctions, PEP, transaction patterns
B7	Social-network & relationship mapping	Link analysis between entities of public interest
B8	Conflict & humanitarian OSINT	Event tracking, civilian harm documentation, claim verification
B9	Environmental & satellite imagery analysis	Change detection, infrastructure monitoring, temporal comparison
B10	Digital footprint & persona correlation	Connecting online identities, username pivoting, platform-native metadata

Axis C — Counter-disinformation & Influence Operations (5)

ID	Category	Scope
C1	Bot & coordinated inauthentic behavior detection	Identifying bot networks, amplification patterns, automation signatures
C2	Narrative tracking & propaganda analysis	Tracking narrative evolution, framing analysis, cross-platform spread
C3	Deepfake & synthetic media identification	Detection cues, provenance verification, generative-AI artefacts
C4	State-sponsored information operations analysis	Attribution of influence campaigns, TTPs of state actors
C5	Platform manipulation & astroturfing detection	Fake reviews, coordinated hashtag campaigns, sockpuppet networks

Axis D — Methodology (8)

ID	Category	Scope
D1	Source reliability grading	Admiralty/NATO A–F / 1–6, systematic evaluation
D2	Analytical confidence calibration	ACH, structured analytic techniques, bias mitigation
D3	OPSEC for OSINT investigators	Operational security during research, identity compartmentalization
D4	Legal & ethical frameworks for OSINT	Jurisdiction-aware collection boundaries, responsible disclosure
D5	Tool selection & workflow design	Choosing and chaining OSINT tools for a given objective
D6	Intelligence reporting & product writing	Structuring reports, executive summaries, technical appendices
D7	Collection planning & requirements management	PIRs, collection plans, gap analysis
D8	Peer review & quality assurance of OSINT products	Verification workflows, red-teaming assessments

Every record was grounded against authoritative reference material (OSINT frameworks, verification handbooks, MITRE for the cyber side) rather than generated from model memory, then deduplicated and balanced per axis.

APEX quantization

The APEX tiers use mudler's APEX (Adaptive Precision for EXpert models), a MoE-aware mixed-precision method that assigns per-tensor precision by role (routed expert, shared expert, attention) and applies a layer-wise precision gradient rather than a uniform bit-width. Routed experts carry the bulk of the compression; the shared expert and attention are held higher; the earliest transformer layers are kept a step up as they are more sensitive to quantization. The realized tensor types and the Gemma-4-specific fallbacks are documented in Available Weights & Variants.

I-matrix

The I- quants are calibrated with a custom importance matrix weighted ~70% on REDCELL's own training corpus and ~30% on a general-purpose calibration set (bartowski's calibration_datav5). The domain-weighted majority keeps the quantization faithful to REDCELL's actual usage distribution (OSINT/CTI analytical output), while the general-language component preserves broad coverage so the quants don't overfit the calibration to domain text and degrade elsewhere.

Vision (multimodal)

REDCELL inherits Gemma 4's native vision capability, here included in BF-16 and F-16 weights. No vision-specific fine-tuning was performed.

---

Performance

Formal capability and refusal-behavior benchmarks may be added in a future revision, time and resources permitting. In the meantime, some notes from informal local testing, offered as impressions rather than measured results:

• Across the domain areas the model was trained on (the axes and categories above), it produces coherent, domain-appropriate tradecraft in spot-checks: correct technique IDs, sensible source grading, plausible analytical structure.
• The model is calibrated to a professional analyst register: queries phrased the way an analyst would phrase them, paired with the suggested system prompt, tend to get fuller and more on-target responses than out-of-register phrasing.
• Gemma 4's inherited vision (not fine-tuned here) pairs well with REDCELL's analytical framing on OSINT-adjacent visual tasks - image geolocation and chronolocation, signage and infrastructure reading.

However, you should verify all of this for yourself, exactly as you would any other OSINT lead. :)

---

Limitations & Responsible Use

REDCELL is an experimental, specialized research tool. It is an early release and behavior may change in future iterations. Feedback is very welcome!

• Responsible use: Users are responsible for ensuring their use complies with applicable law.
• Not a source of ground truth: OSINT output must be independently verified. The model can produce confident-sounding but incorrect attributions, entities, or relationships. But if you need this model, you already know this.
• Domain-specialized: Performance outside OSINT/CTI is that of the base model at best.

---

License

As a derivative work of Gemma 4, REDCELL is released under the Apache-2.0 license. By using REDCELL you agree to those terms.

Acknowledgements

• Google DeepMind - Gemma 4, the base model family.
• Unsloth - training framework and base Gemma 4 GGUF upload used as the fine-tuning starting point.
• mudler - the APEX (Adaptive Precision for EXpert models) quantization method for MoE, its tooling, and the accompanying technical report. A genuine gift to the local inference community.
• bartowski - the general-purpose imatrix calibration dataset used as the 30% generic component of REDCELL's importance-matrix calibration.
• Morula Type - for letting me use his insanely cool font, Protector, for the banner.

Citation

@misc{redcell2026,
  title        = {REDCELL: An OSINT/CTI-Specialized Fine-Tune of Gemma 4 26B-A4B},
  author       = {terrorswift},
  year         = {2026},
  url          = {https://huggingface.co/terrorswift/REDCELL-26B-A4B-OSINT-Cyber-APEX-GGUF},
  note         = {OSINT/CTI-Specialized Fine-Tune of Gemma 4 26B-A4B}
}