Submission type

Most Valuable Feedback Prize — two GitHub issues with reproducers and drop-in patches, targeting the code paths that decide Paritok's own dashboard numbers and startup UX.

Feedback #1 — Token counter is wrong on every OpenAI model above gpt-4o

GitHub issue: Paritok-official/paritok-4b-v1#1

paritok/token_counter.py only maps gpt-4 / gpt-4o / gpt-4o-mini / gpt-3.5-turbo. Anything else falls through to "assume it's already an encoding name", so:

  1. count_tokens(text, "gpt-5") — and 8 other real model IDs already listed in pricing.py — raises ValueError: Unknown encoding gpt-5.
  2. Every internal call inside pipelines/compress.py, proxy/server.py:_tools_tokens, middleware/wrapper.py, strategies/chunking.py omits the model argument and silently uses cl100k_base. The /stats and hosted /meter savings numbers drift 5–15 % against a gpt-5 / gpt-4.1 user's real bill.

This directly affects the hackathon's own submission rubric ("Paritok's dashboard showing exactly how many tokens and how much cost you've saved") — judges evaluate savings on numbers this code produces.

The issue includes a failing reproducer, a complete patched _resolve_encoding with longest-prefix matching over gpt-5 / gpt-4.1 / o3 / o4-mini, and a second patch that threads upstream_model through the four token-counting call sites so /stats matches the user's real tokenizer.

Feedback #2 — Hosted GPU health probe drops the API key on startup

GitHub issue: Paritok-official/paritok-4b-v1#2

GpuServerStrategy.compress() correctly sends Authorization: Bearer <key> on /compress, but check() — the boot-time health probe on /test — sends no headers. On any auth-gated endpoint the probe 401s and the proxy warns "Compression will pass through uncompressed" at startup even though /compress would succeed on the same key.

For a hackathon entrant who just pasted PARITOK_API_KEY and ran paritok proxy, this looks like their key is broken — worst possible moment for a false negative. The issue includes a minimal Python + curl repro and a rewritten check() that sends the same auth header, distinguishes 401/403 from network errors, and surfaces the real HTTP status instead of the current single catch-all.

Why these two

Both bugs live on the code path that produces the numbers judges look at (dashboard savings) and the first output a user sees (startup health message). Both are one-file fixes with the patch code inlined. No hand-waving, no feature wishlist — actionable = shippable.

Happy to open PRs against a fork if the maintainers want to move on either fix.

Built With

Share this project:

Updates

Submission history