tuieval 0.2.0.dev9__tar.gz → 0.2.0.dev10__tar.gz

{tuieval-0.2.0.dev9 → tuieval-0.2.0.dev10}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: tuieval
-Version: 0.2.0.dev9
+Version: 0.2.0.dev10
 Summary: Evaluate local and frontier LLMs on your own questions: accuracy, speed, tokens and PASS/FAIL verdicts, in the terminal.
 Project-URL: Homepage, https://github.com/ashe-wb/tuieval
 Project-URL: Issues, https://github.com/ashe-wb/tuieval/issues
@@ -28,9 +28,13 @@ Description-Content-Type: text/markdown
 
 **Find out which model you can trust with your work, on your own questions, in the terminal.**
 
-Run the same eval packs against local models (llama.cpp GGUFs, LM Studio, Ollama, vLLM; tiny, dense or MoE) and against any frontier model on OpenRouter, side by side. tuieval measures **accuracy, speed and token use** together, and gives a **PASS / FAIL / INCONCLUSIVE** verdict per use case. Grading is automatic; there's no LLM judge.
+Run the same eval packs against local models (llama.cpp GGUFs, LM Studio, Ollama, vLLM; tiny, dense or MoE) and against any frontier model on OpenRouter, side by side.
 
-Public benchmarks leak into training data and rarely look like your work, so tuieval ships with **no built-in benchmark**. Instead you build *eval packs* from what you actually do: questions with checkable answers, in your domain, with your rules. Then you get an answer to the questions that matter:
+tuieval measures **accuracy, speed and token use** together, and gives a **PASS / FAIL / INCONCLUSIVE** verdict per use case. Grading is automatic; there's no LLM judge.
+
+Public benchmarks leak into training data and You know your workload better than anyone. tuieval ships with **no built-in benchmark**.
+Instead you build *eval packs* from what you actually do: questions with checkable answers, in your domain, with your rules
+Then you get an answer to the questions that matter:
 
 - Is this local model good enough to replace the API I'm paying for?
 - Which frontier model is best for *my* domain, not on a leaderboard?

{tuieval-0.2.0.dev9 → tuieval-0.2.0.dev10}/README.md

@@ -2,9 +2,13 @@
 
 **Find out which model you can trust with your work, on your own questions, in the terminal.**
 
-Run the same eval packs against local models (llama.cpp GGUFs, LM Studio, Ollama, vLLM; tiny, dense or MoE) and against any frontier model on OpenRouter, side by side. tuieval measures **accuracy, speed and token use** together, and gives a **PASS / FAIL / INCONCLUSIVE** verdict per use case. Grading is automatic; there's no LLM judge.
+Run the same eval packs against local models (llama.cpp GGUFs, LM Studio, Ollama, vLLM; tiny, dense or MoE) and against any frontier model on OpenRouter, side by side.
 
-Public benchmarks leak into training data and rarely look like your work, so tuieval ships with **no built-in benchmark**. Instead you build *eval packs* from what you actually do: questions with checkable answers, in your domain, with your rules. Then you get an answer to the questions that matter:
+tuieval measures **accuracy, speed and token use** together, and gives a **PASS / FAIL / INCONCLUSIVE** verdict per use case. Grading is automatic; there's no LLM judge.
+
+Public benchmarks leak into training data and You know your workload better than anyone. tuieval ships with **no built-in benchmark**.
+Instead you build *eval packs* from what you actually do: questions with checkable answers, in your domain, with your rules
+Then you get an answer to the questions that matter:
 
 - Is this local model good enough to replace the API I'm paying for?
 - Which frontier model is best for *my* domain, not on a leaderboard?

{tuieval-0.2.0.dev9 → tuieval-0.2.0.dev10}/src/tuieval/_version.py

@@ -18,7 +18,7 @@ version_tuple: tuple[int | str, ...]
 commit_id: str | None
 __commit_id__: str | None
 
-__version__ = version = '0.2.0.dev9'
-__version_tuple__ = version_tuple = (0, 2, 0, 'dev9')
+__version__ = version = '0.2.0.dev10'
+__version_tuple__ = version_tuple = (0, 2, 0, 'dev10')
 
 __commit_id__ = commit_id = None