# ZMLC+ Track 1: Local-First Token Router with Deterministic Gates and Fireworks Fallback

**URL:** <https://devcommunity.amd.com/t/zmlc-track-1-local-first-token-router-with-deterministic-gates-and-fireworks-fallback/695>\
**Category:** Artificial Intelligence (AI)\
**Created:** [July 9, 2026, 10:57am UTC](https://devcommunity.amd.com/t/zmlc-track-1-local-first-token-router-with-deterministic-gates-and-fireworks-fallback/695 "2026-07-09T10:57:17Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![Christian\_Quintino\_D](https://dub1.discourse-cdn.com/amd/user_avatar/devcommunity.amd.com/christian_quintino_d/32/878_2.png) [@Christian\_Quintino\_D](https://devcommunity.amd.com/u/Christian_Quintino_D)\
**Post date:** [July 9, 2026, 10:57am UTC](https://devcommunity.amd.com/t/zmlc-track-1-local-first-token-router-with-deterministic-gates-and-fireworks-fallback/695/1 "2026-07-09T10:57:17Z")

</div>

Hi everyone,

I’m sharing my Track 1 submission for the AMD Developer Hackathon ACT II: **ZMLC+ Local-First Token Router**.

The core idea is simple: not every benchmark task should be treated as open-ended LLM generation. Some tasks are deterministic or directly verifiable, such as arithmetic, exact JSON, sentiment, strict formatting, common reasoning patterns, and narrow code templates. ZMLC+ moves that safe slice out of the lossy remote-generation path and answers it with deterministic solvers, verifier checks, optional local Gemma/GGUF inference, and output normalization.

Only the remaining risky or genuinely lossy slice is routed to official allowed Fireworks models such as Kimi and Minimax, using compact task-specific prompts.

### What it does

- Handles deterministic/verifiable tasks with zero counted Fireworks tokens.
- Uses local inference when available through an OpenAI-compatible local endpoint.
- Applies verifier and parser guards before accepting local answers.
- Falls back to allowed Fireworks models only when needed.
- Implements the official Track 1 Docker batch contract: reads `/input/tasks.json`, writes `/output/results.json`.

### Current validation

### Fresh 12-task smoke results

I tested the current v2 router on a small fresh mixed set of 12 hand-written tasks, separate from the synthetic hard slice.

Task mix:

- 3 math tasks
- 4 QA tasks
- 2 strict-format tasks
- 2 code tasks
- 1 reasoning task

Result:

| System | Accuracy | Fireworks tokens/task | Parser pass | Verifier precision/recall | Crash-free |
| --- | --- | --- | --- | --- | --- |
| Remote-only | 0.8542 | 193.75 | 1.0 | 1.0 / 1.0 | 1.0 |
| ZMLC+ v2 | 0.8875 | 19.33 | 1.0 | 1.0 / 1.0 | 1.0 |

That run gave:

- `90.02%` fewer counted Fireworks tokens
- `+0.0333` accuracy delta versus remote-only
- `0` verifier false positives
- `0` wrong local-only accepts

This is a small smoke test, not the headline benchmark, but it checks the same behavior on fresh tasks: exact or verifiable work is handled locally/deterministically, while risky tasks still go to Fireworks.

On a hard 60-task proxy slice:

- Remote-only accuracy: `0.9117`
- ZMLC+ accuracy: `0.9225`
- Remote-only Fireworks tokens/task: `145.75`
- ZMLC+ Fireworks tokens/task: `47.68`
- Token reduction: `67.28%`
- Accuracy delta: `+0.0108`
- Parser pass, verifier precision/recall, and crash-free rate: `1.0`

On a separate fresh mixed smoke run, ZMLC+ reduced Fireworks tokens by `90.02%` with `+0.0333` proxy accuracy delta.

### 

````auto
Docker image:
```text
christiandeluca/zmlc-track1:v4

````