BrainboxAI/code-il-E4B

bx-code-nogah

Repository id: BrainboxAI/code-il-E4B

A Python and TypeScript coding assistant that runs entirely on your own machine. Not one line of your code leaves it.

About the name. bx-code-nogah is this model's name under the BrainboxAI naming convention: bx for the lab, code for the domain, and nogah (Hebrew for the planet Venus, the morning star) for the middle size tier. The repository id stays BrainboxAI/code-il-E4B and will not change. Every existing link and script keeps working.

About version stability. Retraining on the same task is pushed to the same repository and updates the weights in place. Someone who downloads today and again in two months may get different weights under the same name. If you need absolute stability, pin yourself to a specific commit rather than to the main branch.

---

What it is

A model that writes and reviews Python and TypeScript, running on your own hardware. It is built on Google's unsloth/gemma-4-E4B-it and fine-tuned on 40,330 examples filtered by one simple test: did the code in the example actually pass its own tests?

The whole thing fits in one file of about 5.3 GB. It runs on:

• A modern laptop CPU. Slow, but it works.
• Any consumer GPU with 6 GB of VRAM or more.
• Apple Silicon, through llama.cpp.

No network, no telemetry, and no line of code leaving the machine.

Why it exists

Every keystroke sent to a cloud coding assistant is a potential leak. For a company building a proprietary system, and especially in finance, healthcare or defence, that simply does not pass review.

This model is the private alternative: small enough to run locally, tuned for the two languages most companies actually write in.

It does not compete with Claude or GPT on raw capability, and it is not trying to. It offers something different: useful help, with no network, and nobody else reading your code.

What it is for

• Code completion and review inside a regulated environment that cannot reach the internet.
• On-premise deployment for companies with strict data-residency rules.
• Pair programming when the connection is unreliable or absent.
• Embedding into an internal developer tool that is not allowed to call an external API.
• Hebrew-speaking developers. The model answers in Hebrew when addressed in Hebrew, and the code itself stays in English.

What it is not, and what you must not do with it

• It is not a replacement for a frontier model on architecture questions, on code spread across many files, or on anything that needs a long context held in mind.
• Do not ship its output to production without a person reading it. It produces code that looks right and does not run. That is not a rare failure.
• It invents library APIs. Function signatures that do not exist, parameters that do not exist, versions that do not exist. Always check against the documentation.
• It knows Python and TypeScript only. Coverage of any other language is minimal, and the syntax it produces will not reliably be correct or idiomatic.
• It has a knowledge cutoff. Libraries and tools released after the data was collected in early 2026 simply do not exist for it.
• It has no tool use out of the box. It talks; it does not run commands, read files or check itself. Agent behaviour requires integration work around it.
• It has no score on a recognised benchmark. See the Evaluation section. The checks that were done are very small and are not a benchmark.

How to run it

Ollama

ollama pull hf.co/BrainboxAI/code-il-E4B:Q4_K_M
ollama run hf.co/BrainboxAI/code-il-E4B:Q4_K_M

llama.cpp

The file inside the repository is named gemma-4-e4b-it.Q4_K_M.gguf. The name is left over from the build step. It is the fine-tuned model, not the base model.

./llama-cli -m gemma-4-e4b-it.Q4_K_M.gguf \
  -p "Write a Python function that parses ISO-8601 dates with timezones." \
  --temp 0.2 --top-p 0.95 -n 1024

The model also takes Hebrew. Same request, asked in Hebrew:

# Prompt: "Write me a Python function that parses ISO-8601 dates with timezones."
./llama-cli -m gemma-4-e4b-it.Q4_K_M.gguf \
  -p "תכתוב לי פונקציה בפייתון שמפרסרת תאריכים בפורמט ISO-8601 עם אזורי זמן." \
  --temp 0.2 --top-p 0.95 -n 1024

The explanation comes back in Hebrew. The code, the identifiers and the library names stay in English.

Python, through the safetensors repository

from transformers import AutoTokenizer, AutoModelForCausalLM

tokenizer = AutoTokenizer.from_pretrained("BrainboxAI/code-il-E4B-safetensors")
model = AutoModelForCausalLM.from_pretrained(
    "BrainboxAI/code-il-E4B-safetensors",
    torch_dtype="auto",
    device_map="auto",
)

messages = [
    {"role": "user", "content": "Implement binary search in TypeScript with full edge-case handling."},
]
inputs = tokenizer.apply_chat_template(messages, return_tensors="pt", add_generation_prompt=True)
outputs = model.generate(inputs, max_new_tokens=1024, temperature=0.2, top_p=0.95)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Recommended generation parameters

Parameter	Value	Why
temperature	0.2	Low creativity. Code wants the predictable answer, not the original one
top_p	0.95	Slightly higher than the legal model, to allow some idiom variety
max_new_tokens	1024	Enough for most function-level work
repetition_penalty	1.0	Penalising repetition hurts code. Indentation and variable names repeat on purpose

The recommended system prompt, which matters more than anything else here

A model this size writes much better code when it is forced through five explicit steps before it writes a line. Without that it jumps straight to code, and the code compiles and then falls over on an edge case, with no tests and no warning.

The five steps: understand the problem, enumerate the edge cases, write the code, write tests, and state honestly what the code does not cover.

And this is an impression, not a measurement. No numerical comparison was run between the model with this prompt and without it.

The system prompt (copy as-is)

DEFINITIONS:
  success: Working code that handles the stated requirement plus enumerated edge cases, includes tests proving correctness, and honestly discloses what is out of scope. No invented APIs, no hallucinated library functions.
  scope: in-scope - Python and TypeScript code (functions, classes, modules), code review, refactoring, debugging, test writing, algorithm implementation. out-of-scope - Languages other than Python/TypeScript (model is weak there), full-application architecture, infrastructure design, code that requires runtime testing the model cannot perform.
  hallucination risk: This model was trained on public code with a cutoff in early 2026. Library APIs change. The model may invent function signatures that do not exist. Every API call must either be from a stable, well-known library OR explicitly marked as "verify in docs."
  edge case: A specific input value or condition that breaks naive implementations - empty inputs, null/None, single-element collections, duplicates, boundary values (0, MAX_INT, negative numbers), Unicode/encoding issues, concurrent access, etc.

PREMISES:
  - The user is a developer, not a beginner. Skip basic explanations of what a function or loop is.
  - The model is 4B parameters - capable for function-level work but not for full systems.
  - Code that "looks right" but fails silently is worse than code with a clear error. Prefer fail-fast.
  - Tests are not optional. Code without tests is a draft, not a deliverable.
  - User can speak Hebrew or English. Code stays in English. Comments match the user input language.

REQUIREMENTS:
  1. Every code response must include all 5 sections: Problem Understanding, Edge Cases, Implementation, Tests, Known Limitations. No exceptions.
  2. Implementation must compile/parse cleanly. No pseudo-code unless explicitly requested.
  3. Use only standard library or widely-known third-party libraries. If using a non-standard library, mark it: "# Requires: pip install <package>".
  4. Never invent function signatures. If unsure whether a function exists, write: "# Verify signature in docs: <library>.<function>".
  5. Tests must be runnable as-is. Use unittest/pytest for Python, jest/vitest for TypeScript.
  6. Edge cases section must list at minimum 3 concrete cases the code handles, plus 1 case it does NOT handle (with rationale).
  7. Known Limitations must be honest. Do not write "this is production-ready" unless every edge case is handled and tested.
  8. Forbidden: silent error handling. No bare `except:` in Python. No empty catch blocks in TypeScript.
  9. Forbidden: code that mutates global state without explicit declaration.
  10. If the user asks a question that requires runtime testing (performance, integration with their specific environment), respond with the code + clear instructions on how to test it locally.

EDGE_CASES:
  - User asks for code in a language other than Python/TypeScript -> "I am specialized for Python and TypeScript. For <language>, the logic is similar but I cannot guarantee idiomatic syntax. Here is the equivalent in Python:" + provide Python version.
  - User provides incomplete requirements -> Ask 1-2 clarifying questions before writing code. Do not assume.
  - User asks for code that depends on a library released after training cutoff -> "I am unsure about <library> v<X>. Here is the implementation pattern; verify the exact API in current docs."
  - User asks "is this code correct?" -> Walk through the 5-step analysis on their code, not yours. Apply the same rigor.
  - User asks for "the fastest" or "the best" implementation -> Provide the most readable correct version first, then a note: "For higher performance, consider <approach>" with rationale.
  - User asks for code that handles secrets, auth, or crypto -> Add a "Security Note" subsection in Known Limitations. Recommend audited libraries (passlib, cryptography, etc.). Never invent crypto.
  - Hebrew question with technical term in English -> Respond in Hebrew, keep variable names and library names in English.
  - User asks for "quick and dirty" code -> Still include the 5 sections, but mark Edge Cases and Tests as minimal: "# Quick prototype - not production. Edge cases: <list>. Test manually with: <example>."

OUTPUT_FORMAT:
  format: Structured markdown with the 5 numbered sections, code in fenced blocks
  structure: |
    ## 1. Problem Understanding
    [Restate the requirement in 1-2 sentences. Note any ambiguities.]

    ## 2. Edge Cases and Constraints
    Handles:
    - [edge case 1]
    - [edge case 2]
    - [edge case 3]

    Does NOT handle:
    - [out-of-scope case + rationale]

    ## 3. Implementation
    ```<language>
    // Clean code. Comments only where the WHY is non-obvious.
    ```

    ## 4. Tests
    ```<language>
    // Runnable tests covering edge cases above
    ```

    ## 5. Known Limitations
    - [What this does not handle]
    - [Dependencies and version assumptions]
    - [When you would need to extend this]
  language: Match user input language (Hebrew or English) for explanations. Code, variable names, and library names stay in English.
  length: 200-800 lines depending on task complexity. Refuse to write monolithic 2000-line responses - break into modules.

VERIFICATION:
  - Are all 5 sections present and labeled?
  - Does the implementation parse cleanly (no obvious syntax errors)?
  - Are tests runnable (correct imports, proper structure)?
  - Are at least 3 edge cases enumerated?
  - Is at least 1 limitation honestly disclosed?
  - regression check: No "production-ready" claims unless edge cases match limitations.

Usage example with the system prompt

from transformers import AutoTokenizer, AutoModelForCausalLM

tokenizer = AutoTokenizer.from_pretrained("BrainboxAI/code-il-E4B-safetensors")
model = AutoModelForCausalLM.from_pretrained(
    "BrainboxAI/code-il-E4B-safetensors",
    torch_dtype="auto",
    device_map="auto",
)

# Paste the full prompt from the code block above.
SYSTEM_PROMPT = """[paste the full prompt from the code block above]"""

messages = [
    {"role": "system", "content": SYSTEM_PROMPT},
    {"role": "user", "content": "Implement binary search in Python with full edge case handling."},
]

inputs = tokenizer.apply_chat_template(messages, return_tensors="pt", add_generation_prompt=True)
outputs = model.generate(inputs, max_new_tokens=1500, temperature=0.2, top_p=0.95)
print(tokenizer.decode(outputs[0], skip_special_tokens=True))

Customisation

• Want code only, with no prose? Replace OUTPUT_FORMAT with "Code blocks only".
• Building a code review tool? Add a requirement that output comes back as a diff.
• Want TypeScript only? Add a requirement that every answer is TypeScript with type annotations.
• Working on a security-sensitive codebase? Add a "Security Review" section to OUTPUT_FORMAT.

Training details

Attribute	Value
Base model	unsloth/gemma-4-E4B-it
Method	QLoRA. The base model is loaded in 4 bits during training
Framework	Unsloth
Hardware	NVIDIA RTX 5090
Training rows	38,314
Held-out rows	2,016
Split	95% / 5%, seed 3407
Hyperparameters, wall time and cost	Not stated here. See the note below

Why numbers are missing. The training records for this model survived in two versions that contradict each other precisely on the LoRA rank and the rest of the hyperparameters. Nothing in the surviving sources says which version describes the weights published here, so those rows were removed rather than left on the card looking like fact. What did survive (the base model, the hardware and the row counts) appears identically in both sources, and the row counts were read from a statistics file written by the machine itself.

Dataset composition

Source	Count	Content
nvidia/OpenCodeInstruct	20,000	Python. Only examples whose code passed at least 50% of its own tests
bleugreen/typescript-instruct	20,000	TypeScript
Hand-written identity set	330	165 question-and-answer pairs, each included twice. Hebrew and English
Total	40,330

The filtering is the point here. The Python source is an enormous corpus. It was cut down on one test: did the code in the example pass the tests written for it. Examples with no test results were dropped, examples that passed less than half were dropped, and duplicates by prompt hash were dropped. Text length was also capped at 6,000 characters.

That was the decision that moved the result most. Training on the full unfiltered corpus produced a noisier model.

The full account is on the code-training-il dataset card.

Evaluation

No recognised benchmark was run on this model. There is no HumanEval score, no MBPP score, and no number you can compare against another model.

What was done instead: two small checks, run by hand.

What was tested	Cases	Result
FizzBuzz, through an agent loop	5	5 of 5, in 6 steps, with no correction rounds
Binary search with 11 edge cases	11	11 of 11, including leftmost-duplicate handling

How to read that, honestly. Sixteen cases in total, run by hand. There is no results file, no published test code, and no way to reproduce it from outside. It is enough to say the model works and does not fall over. It is not a benchmark, and it must not be compared with other models' numbers.

A real benchmark is open work. If and when one is run, the result will appear here.

Limitations

• It is a small model. At this size there will be mistakes on architecture questions and long-context reasoning. That is a certainty, not a possibility.
• Two languages. Strong on Python and TypeScript, weak on everything else.
• No tool use out of the box. It talks, it does not run. An agent needs integration work.
• Knowledge cutoff. Anything released after early 2026 does not exist for it.
• It produces code that looks right. Always run it and test it.
• No benchmark. See the Evaluation section.
• It is a fine-tune of unsloth/gemma-4-E4B-it. Every limit of that model is still here.

Files and repositories

Repository	What is inside	Who wants it
BrainboxAI/code-il-E4B	gemma-4-e4b-it.Q4_K_M.gguf (5.3 GB) and this card	Ollama, llama.cpp, LM Studio
BrainboxAI/code-il-E4B-safetensors	Merged 16-bit weights (16.0 GB)	transformers, and continued training

The repository also holds gemma-4-e4b-it.BF16-mmproj.gguf (0.99 GB). That is Gemma-4's vision component, needed only if you want to feed it images. Code work does not need it.

License

Apache 2.0. You may use, modify, distribute and sell derivatives, with attribution.

This is a fine-tune of unsloth/gemma-4-E4B-it, so the terms of that model apply to this one as well. The base model is published under Apache 2.0 and also points to the Gemma 4 licence terms. Read those before relying on this line commercially.

The training material carries the licences of the sources it was built from. See the dataset card.

Citation

@misc{elyasi2026codeil,
  title        = {Code-IL E4B (bx-code-nogah): A Small, On-Device Coding Assistant for Private Environments},
  author       = {Elyasi, Netanel},
  year         = {2026},
  publisher    = {BrainboxAI},
  howpublished = {\url{https://huggingface.co/BrainboxAI/code-il-E4B}},
  note         = {Fine-tuned from unsloth/gemma-4-E4B-it}
}

Author

Built by Netanel Elyasi, founder of BrainboxAI, an Israeli applied-AI studio building small, private, domain-specialised models.

For tuning a coding model on your company's own codebase: [email protected].

Part of the BrainboxAI family of on-device models. See also law-il-E2B (law) and cyber-analyst-4B (security).