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:
count_tokens(text, "gpt-5")— and 8 other real model IDs already listed inpricing.py— raisesValueError: Unknown encoding gpt-5.- Every internal call inside
pipelines/compress.py,proxy/server.py:_tools_tokens,middleware/wrapper.py,strategies/chunking.pyomits the model argument and silently usescl100k_base. The/statsand hosted/metersavings 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
- httpx
- paritok
- python
- tiktoken
Log in or sign up for Devpost to join the conversation.